From nobody Wed Feb 1 03:33:32 2017 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 50A2E129D18 for ; Wed, 1 Feb 2017 03:33:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3gyfUOUpqvT for ; Wed, 1 Feb 2017 03:33:29 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::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 91C78126B6D for ; Wed, 1 Feb 2017 03:33:29 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id 96so293821997uaq.3 for ; Wed, 01 Feb 2017 03:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3JPLbR0NzS/C8foAjT0bZQhppL0iHJLLWMIhey5M87I=; b=abCZGrLSWm0sizhP+wwmBxc7awo7DOy19YW/KcTyhXnHqoEnV8zAs7nk6UVr7nJrLG byXcIa+LhyPWS5DPj2LTHlCKDT9wIsuvIm0082pt/FpQcIxs0o/nApyneSHGd0JJ1un5 uAxGP4iNEGgjK0Uig/dD5mUAAkQbYC/8RcRIE/ovKckhjCmd306ls3bzq6HLEFzGB/bB FY450zDa+lkPg0u5eymp5ACxHRjpYxVnAxaSQuS0fPuojSN/06qZ8dMxYGwr+vU/Ctmm 4UVQkTp5pV9zKo6sxsHDpB6Q8ig39xbnInmHYETEerS0GdaBOELFZ+NgVMjgJrhA1itF Ue2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3JPLbR0NzS/C8foAjT0bZQhppL0iHJLLWMIhey5M87I=; b=eJlKG2drPMBoAO12izEx0yhMhzLcZHS02elS8EUB+bOnRrRnxG1ZoF5/MNQgU9IvHt PRQkaYz22r2I2innDLmDj7x5K6VE+QQKbZ5RmfkdOcO+n0tRkc5Eocwv0Q8vbBt5Je/E zvRzGa7vJEw0mX139C049VO7X5+Akz0AZtw7iJJ95zMUvzCaumv6LWhLok62rnxBH7BE ONj6RZjSvywq0dgZdTCw8RfH8PAQsAb24G/QReqXYSzNuC2AgelA1mE69DGA2Qj+vEhN 3JdM2oURtPXZW6aQAE0pWRBhfFnYez8QmZmUXKNzhDcG3mwG9l+s5KUlG69gmO9pXJHW jqmA== X-Gm-Message-State: AIkVDXKgRoDK9YgHMdjsi8EPwueJ2j5Z0FPUGmXCLcZQYh+n0rtMXmIZHzAI4a9CTZIKm9/tVHpH+vgOe4wGHg== X-Received: by 10.159.38.73 with SMTP id 67mr846009uag.155.1485948808576; Wed, 01 Feb 2017 03:33:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.67.68 with HTTP; Wed, 1 Feb 2017 03:33:28 -0800 (PST) In-Reply-To: References: From: Dragana Damjanovic Date: Wed, 1 Feb 2017 12:33:28 +0100 Message-ID: Subject: Re: Performance/safety trade-off To: Watson Ladd Content-Type: multipart/alternative; boundary=001a114950dce3ca330547766aba Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 11:33:31 -0000 --001a114950dce3ca330547766aba Content-Type: text/plain; charset=UTF-8 This is the similar problem as with a lost ClientHello and 0RTT packets. What if we send a clear text ack for 0RTT packet if the clientHello is lost (to actually inform the client that the ClienHello has been lost) and a cleartext ack of 1RTT packet when a client finish message is lost. This ack can be use only for retransmissions but not for marking packets as acked? These ack are clear text but they should not be(acks for 0RTT and 1RTT packes should be encrypted), so we can distinguish them from proper acks. 0RTT can be just a noise, they cannot be verified, so maybe not acking them. dragana On Wed, Feb 1, 2017 at 12:36 AM, Watson Ladd wrote: > > > On Jan 31, 2017 3:23 PM, "Martin Thomson" > wrote: > > The security analyses of TLS assume receipt and verification of the > Finished message. It's an obvious intuition that keys depend on the > content of the message, therefore tampering would be easily detected. > > > I think someone who is more experienced/familiar with the analysis should > chime in. My understanding is that the ROM quickly gives high probability > of the keys being different and hence the MAC failing, and the Finished > message is there to give an explicit confirmation property. > > > That said, we've learned that intuition is often wrong in this space, > sometimes disastrously. We don't have an analysis of TLS that ignores > the client Finished message. So unless and until we do, I don't want > to write down anything that isn't known to be safe. > > I know that this sucks in subtle ways, particularly in the way that > Ian observed with respect to acknowledgments. Because we require that > the Finished is acknowledged with protected keys, we lose the ability > to generate acknowledgments for them. > > I see three possible approaches: > > 1. As I originally suggested, suck it up and don't let the server send. > > 2. Don't protect the Finished (it's protected with TLS handshake keys > anyway). That would allow for acknowledgment in the clear. That > requires a tweak to the way that keys are shared, but it's a fairly > simple tweak. The major downside is that we now have an extra packet > to send, because you can't collapse the Finished message with other > things (like requests). > > 3. In the hackiest possible way, generate a redundant ACK for the > ClientHello in the clear. If that could trigger retransmission of the > first encrypted packet(s), then we'd be OK. (Sorry, I haven't > internalized the loss recovery stuff, so I'm not sure if this even > works, we could be back into RTO space here.) > > Maybe option 2 is more appealing than appalling. > > > On 1 February 2017 at 04:17, Jana Iyengar wrote: > > Since the keys cannot be the same if the ClientHello were to be modified, > > what is the risk we are talking about here? I don't know about the crypto > > analyses of the TLS handshake, so some insight here would be helpful. > But I > > agree that having the server process 1-RTT data would help with loss > > detection. If there's no real security implication, I'd be in favor of > > letting the server process this data. > > > > On Tue, Jan 31, 2017 at 8:27 AM, Watson Ladd > wrote: > >> > >> On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson > >> wrote: > >> > In PR #39, there is a choice: > >> > > >> > https://github.com/quicwg/base-drafts/pull/39 > >> > > >> > If a server receives 1-RTT-protected packets before it receives the > >> > client Finished message, it could use them. It has the keys. > >> > > >> > Obviously, if the server depends on certificate-based client > >> > authentication it will wait. But that's still a relatively rare > >> > occurrence. > >> > > >> > However, using 1-RTT data before verifying the Finished message could > >> > leave the server more vulnerable to an attack where the ClientHello is > >> > modified by an attacker. This is something that TLS 1.3 protects > >> > against, but only indirectly. The traffic keys are dependent on the > >> > content of the ClientHello and so it is likely that modifications of > >> > the ClientHello would result in being unable to communicate. But this > >> > isn't a strong assertion. The various forms of analysis of the TLS > >> > 1.3 handshake have all (I think) assumed that verification of the > >> > Finished message is what provides integrity for the handshake. > >> > >> I don't believe the finished message is necessary for ensuring > >> manipulation of the client hello message is detected. > >> > > >> > In #39, I opted to forbid use of the client 1-RTT data until the > >> > handshake completes. I'd like to confirm that this is acceptable. > >> > > >> > In addition to confirming this, I'd like input on what level of > >> > justification is necessary for this in the document. If we believe > >> > that this is the right decision, do we need to do anything to prevent > >> > someone from pulling out a false start hack because they disagree with > >> > this analysis? > >> > > >> > >> > >> > >> -- > >> "Man is born free, but everywhere he is in chains". > >> --Rousseau. > >> > > > > > --001a114950dce3ca330547766aba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is the similar problem as with a lost = ClientHello and 0RTT packets.

What if we send a clear text ack= for 0RTT packet if the clientHello is lost (to actually inform the client = that the ClienHello has been lost) and a cleartext ack of 1RTT packet when = a client finish message is lost. This ack can be use only for retransmissio= ns but not for marking packets as acked? These ack are clear text but they = should not be(acks for 0RTT and 1RTT packes should be encrypted), so we can= distinguish them from proper acks.
0RTT can be just a noise, the= y cannot be verified, so maybe not acking them.

dragana


On Wed, Feb 1, 2017 at 12:36 AM, Watson Ladd = <watsonbladd@= gmail.com> wrote:


On Jan 31, 2017 3:23 PM, "Martin Thomson" <= martin.thomso= n@gmail.com> wrote:
The security analyses of TLS assume receipt and veri= fication of the
Finished message.=C2=A0 It's an obvious intuition that keys depend on t= he
content of the message, therefore tampering would be easily detected.

I think someone who is more experienced/familiar with the analysis s= hould chime in. My understanding is that the ROM quickly gives high probabi= lity of the keys being different and hence the MAC failing, and the Finishe= d message is there to give an explicit confirmation property.


That said, we've learned that intuition is often wrong in this space, sometimes disastrously.=C2=A0 We don't have an analysis of TLS that ign= ores
the client Finished message.=C2=A0 So unless and until we do, I don't w= ant
to write down anything that isn't known to be safe.

I know that this sucks in subtle ways, particularly in the way that
Ian observed with respect to acknowledgments.=C2=A0 Because we require that=
the Finished is acknowledged with protected keys, we lose the ability
to generate acknowledgments for them.

I see three possible approaches:

1. As I originally suggested, suck it up and don't let the server send.=

2. Don't protect the Finished (it's protected with TLS handshake ke= ys
anyway).=C2=A0 That would allow for acknowledgment in the clear.=C2=A0 That=
requires a tweak to the way that keys are shared, but it's a fairly
simple tweak.=C2=A0 The major downside is that we now have an extra packet<= br> to send, because you can't collapse the Finished message with other
things (like requests).

3. In the hackiest possible way, generate a redundant ACK for the
ClientHello in the clear.=C2=A0 If that could trigger retransmission of the=
first encrypted packet(s), then we'd be OK.=C2=A0 (Sorry, I haven't=
internalized the loss recovery stuff, so I'm not sure if this even
works, we could be back into RTO space here.)

Maybe option 2 is more appealing than appalling.


On 1 February 2017 at 04:17, Jana Iyengar <jri@google.com> wrote:
> Since the keys cannot be the same if the ClientHello were to be modifi= ed,
> what is the risk we are talking about here? I don't know about the= crypto
> analyses of the TLS handshake, so some insight here would be helpful. = But I
> agree that having the server process 1-RTT data would help with loss > detection. If there's no real security implication, I'd be in = favor of
> letting the server process this data.
>
> On Tue, Jan 31, 2017 at 8:27 AM, Watson Ladd <watsonbladd@gmail.com> wrote:<= br> >>
>> On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson
>> <= martin.thomson@gmail.com> wrote:
>> > In PR #39, there is a choice:
>> >
>> > https://github.com/quicwg/base-draft= s/pull/39
>> >
>> > If a server receives 1-RTT-protected packets before it receiv= es the
>> > client Finished message, it could use them.=C2=A0 It has the = keys.
>> >
>> > Obviously, if the server depends on certificate-based client<= br> >> > authentication it will wait.=C2=A0 But that's still a rel= atively rare
>> > occurrence.
>> >
>> > However, using 1-RTT data before verifying the Finished messa= ge could
>> > leave the server more vulnerable to an attack where the Clien= tHello is
>> > modified by an attacker.=C2=A0 This is something that TLS 1.3= protects
>> > against, but only indirectly.=C2=A0 The traffic keys are depe= ndent on the
>> > content of the ClientHello and so it is likely that modificat= ions of
>> > the ClientHello would result in being unable to communicate.= =C2=A0 But this
>> > isn't a strong assertion.=C2=A0 The various forms of anal= ysis of the TLS
>> > 1.3 handshake have all (I think) assumed that verification of= the
>> > Finished message is what provides integrity for the handshake= .
>>
>> I don't believe the finished message is necessary for ensuring=
>> manipulation of the client hello message is detected.
>> >
>> > In #39, I opted to forbid use of the client 1-RTT data until = the
>> > handshake completes.=C2=A0 I'd like to confirm that this = is acceptable.
>> >
>> > In addition to confirming this, I'd like input on what le= vel of
>> > justification is necessary for this in the document.=C2=A0 If= we believe
>> > that this is the right decision, do we need to do anything to= prevent
>> > someone from pulling out a false start hack because they disa= gree with
>> > this analysis?
>> >
>>
>>
>>
>> --
>> "Man is born free, but everywhere he is in chains".
>> --Rousseau.
>>
>


--001a114950dce3ca330547766aba-- From nobody Wed Feb 1 05:26:03 2017 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 98B22129435 for ; Wed, 1 Feb 2017 05:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G40NFF-sBsUF for ; Wed, 1 Feb 2017 05:25:59 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 164DD1293F5 for ; Wed, 1 Feb 2017 05:25:57 -0800 (PST) X-AuditID: c1b4fb30-13a0498000007085-e4-5891e1e35186 Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by (Symantec Mail Security) with SMTP id 89.2D.28805.3E1E1985; Wed, 1 Feb 2017 14:25:56 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.72) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 1 Feb 2017 14:24:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=P6IFWanCs8JAZmOOfMI5wt8PfvirOoCUxelezkQMQS8=; b=h8/mLteRjCPZPBOdlaDZhsMky3cSI9lnoI5KlEMEAjzQu1nEN8RjdfgUaeNMw+qmijLz+wgOZWNiumrHrMvoduJ5vS6kLmvBqzPbGwlSRiJ8P4KAPmDqAeLl1uCwQOG6XXh9zW+Y+yadhCBkXpDVfBCj21/Ar7AXPoXmL9M7Q2c= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Wed, 1 Feb 2017 13:24:57 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0888.016; Wed, 1 Feb 2017 13:24:57 +0000 From: Ingemar Johansson S To: "gorry@erg.abdn.ac.uk" , marcelo bagnulo braun Subject: RE: about draft-johansson-quic-ecn-00 Thread-Topic: about draft-johansson-quic-ecn-00 Thread-Index: AQHSd7hAuGVD/TJHuEGnPsqrrJ7jGKFS9/SAgAEkbWA= Date: Wed, 1 Feb 2017 13:24:56 +0000 Message-ID: References: <79bfa1c0-ff80-8a98-0e50-bc03d5a96b30@it.uc3m.es> <5890DDCF.6010507@erg.abdn.ac.uk> In-Reply-To: <5890DDCF.6010507@erg.abdn.ac.uk> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.85] x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:j6zkFRba6A3YmsYe3Ib9ULefwQRJ3kN+ZxMEILOxRqxG0j7kUnabZvAucdOsDBrku11k8kIFft6ZUL+d3SxlWWxDoG0Dh3qkQBfJOOEbc3U216YmhGnv/vL0GbQH2OGef2+6ByWtNZ0YEqLT4IvLNF7N7y2jNfRr0ouuaZKSMrkswdiiU96NvkI9pD3KzHkKa1I3qkU8zZ+hCBZ8JOekaIGrXykES4U4k9RBnPTISDkOquuqTRDNWrh3kPSFT/NCSa5GHQ+74tUn0oeshFKitGAPx4UqWP6f1wPEiq6/qStwQN/kL9WxGztmWv74EJ5ndcXus4BQsNWSjyOyACSLxhyPiN16m2rGZ17wCGloytQc4wdA1D9GfMjQV7F/ldw02h9+9yD7obotzEUXfvjc8+qQ8WxjxP0fn8Ek84c4ve9rVHullO6ADLve89B3eB/NK1kKAmvAlEUpVUIuxBfRXCApd1uz05pUC6XkdKo9BmhQAB8+Sn1ZUIoFcKSglEtqPLAJ3HB42rI8XmbsY8L5tz3mx3xIMdvJe9+QTYFWxFcj9uAbqQe+8ED7E1wRWbu0 x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(189002)(13464003)(199003)(24454002)(51914003)(38730400001)(68736007)(77096006)(54356999)(81156014)(305945005)(76176999)(8676002)(81166006)(6436002)(50986999)(106116001)(229853002)(8936002)(25786008)(105586002)(230783001)(5660300001)(2501003)(122556002)(7696004)(6506006)(2900100001)(99286003)(106356001)(54906002)(55016002)(92566002)(101416001)(345774005)(66066001)(86362001)(5001770100001)(9686003)(74316002)(7736002)(97736004)(3280700002)(3660700001)(53936002)(2906002)(102836003)(6116002)(4326007)(2950100002)(4001430100002)(189998001)(107886002)(3846002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: b013ae12-c865-43bc-f11b-08d44aa5b762 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB345; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 0205EDCD76 received-spf: None (protection.outlook.com: ericsson.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-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2017 13:24:57.0074 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHeXbvnXez4eNUPKwEvUXQKDWJspIyiBCyshBaSupVb27kG7tm qX3wi8J0yjQN3zUapuZbvmVWSlMpHaEfxKzQJb7O+pAvJDWQvN4Fffud//9wnv85PDShNFAq WpeawelT2WRGKicrNS/Dji3Ol2gC12tkwd/zq1Fw3lKLNNjY4BpKhBk3VyVhZvNvSdivTy+o CCJKHpLIJesyOX3AuTi5trgzPH3k+oNX3+xkLuq/VoBoGvAJ2JnkCpCcVuJ2BFNPjYRYvEdQ PNHnIhQkLiKg29aBRKdMAi3rq6RYjCJomnm068hoKQ6BZsv2HnviWDAsN5ECE/g21JkLpQJ7 YH/4OtBKiT0BMFo7IhFyeOIzUN6uE2QSH4I/hWN7sgJHQUVDrCArMQtN082EwLLdKdaJcReB EfYB2/ac8yVv+LJYLxEYMAbzmwlCZC+wL+xQYn8CbHwuosTtfWG+96qwCeBNEvqsP0mxv04K pkknXwFbV4lzTjgUzVilIusgt2vRqUfDYOkwEgdVSODJj3xniAOwWtpIiQtw8KwtD4lnUMHs lAGZkLrqv9xVu5kIfAQ6BgJE2Q/KCuddBFZgdxirXCQbENmCvHiOj09JCgry5/S6BJ5PS/VP 5TK60O4HedfjCOxH9pULFoRpxOxTdM6ZNEqKzeSzUiwIaILxVPjMlmiUikQ2K5vTp8Xq7yVz vAXtp0nGW3Gy2XZTiZPYDO4ux6Vz+n+uhJapctFDba2DGVoymJhTfhHDqhi73dCrNVKS6IrI gZWM6ajB8hhrmnorqyBQnnKx1eJozKde+y50h2rw5Vt1NzzW1sY/zNeczjm74s5Ux92pv/92 uedjfSTjcB1yje++VDW9dTR4ssbsZXu8cbiyt7NEnd32PDGn56DDrWNb4caej2RIXsseVxN6 nv0Lp3pd5RwDAAA= Archived-At: Cc: Ingemar Johansson S , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 13:26:01 -0000 SGkgR29ycnkgYW5kIE1hcmNlbG8gKyBvdGhlcnMNCg0KVGhhbmtzIGZvciB0aGUgcmV2aWV3IGFu ZCBjb21tZW50cy4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlIG5lZ290aWF0aW9uIHBoYXNlIGlzIHRo ZSBtb3JlIHByb2JsZW1hdGljIGFzcGVjdC4NCg0KVGhlIHByb3Bvc2VkIEVDTiBmcmFtZSBzb3Vu ZHMgbGlrZSBhIGdvb2QgaWRlYSBhcyB0aGlzIG1ha2VzIGl0IHBvc3NpYmxlIHRvIGRvIHRoZSBF Q04gbmVnb3RpYXRpb24gd2l0aG91dCBkZWxheWluZyB0aGUgY29ubmVjdGlvbiBzZXR1cCAoaW4g Y2FzZSBFQ04gZmFpbHMpLiBUaGUgcG9zc2libGUgZHJhd2JhY2sgaXMgdGhhdCAibm9uLUVDTiBj YXBhYmxlIiBjb25uZWN0aW9uIHNldHVwIHBhY2tldHMgbWF5IGJlIGRpc2NhcmRlZCBvdmVyIGEg Y29uZ2VzdGVkIEVDTiBjYXBhYmxlIHBhdGggYW5kIHRoYXQgbWF5IGRlbGF5IHRoZSBjb25uZWN0 aW9uIHNldHVwIHRvby4NClNvIGlmIEkgdW5kZXJzdGFuZCB0aGUgRUNOIGZyYW1lIGNvcnJlY3Rs eS4gSXQgd291bGQgYmUgb2YgYSBnaXZlbiBzaXplICh+TVRVPykgYW5kIGhhdmUgdGhlIEVDTiBi aXRzIHNldCAoPUNFPykuIA0KVGhlIHJlY2VpdmVyIGNhbiByZXBseSBpbiB0d28gd2F5cy4NCjEp IFVzaW5nIHRoZSBFQ04gZWNobyBpbiB0aGUgQUNLIGZyYW1lLCBhc3N1bWVzIHRoYXQgdGhlIEVD TiBmcmFtZSBoYXMgYSBzZXF1ZW5jZSBudW1iZXINCjIpIFVzaW5nIGFuIEVDTiBmcmFtZSBpbiB0 aGUgcmV2ZXJzZSBkaXJlY3Rpb24gKHRoZSBFQ04gZnJhbWUgY2FuIHRoZW4gaW5kaWNhdGUgdGhl IEVDTiBiaXQpDQoNCg0KTW9yZSBjb21tZW50cyBpbmxpbmUgYmVsb3cNCg0KL0luZ2VtYXINCg0K PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBHb3JyeSBGYWlyaHVyc3QgW21h aWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51a10NCj4gU2VudDogZGVuIDMxIGphbnVhcmkgMjAxNyAx OTo1Ng0KPiBUbzogbWFyY2VsbyBiYWdudWxvIGJyYXVuIDxtYXJjZWxvQGl0LnVjM20uZXM+DQo+ IENjOiBxdWljQGlldGYub3JnOyBJbmdlbWFyIEpvaGFuc3NvbiBTDQo+IDxpbmdlbWFyLnMuam9o YW5zc29uQGVyaWNzc29uLmNvbT4NCj4gU3ViamVjdDogUmU6IGFib3V0IGRyYWZ0LWpvaGFuc3Nv bi1xdWljLWVjbi0wMA0KPiANCj4gSSdkIGFsc28gbGlrZSB0byB0aGFuayB5b3UgZm9yIHRoaXMg Y29uc2lkZXJhdGlvbiBvZiB3aGVyZSBFQ04gZml0cyB3aXRoaW4gUVVJQy4NCj4gSSBoYXZlIGEg ZmV3IGNvbW1lbnRzLCBzZWUgYmVsb3c6DQo+IA0KPiBJIHJlYWxseSBkbyBzZWUgbWVyaXQgaW4g cmVxdWlyaW5nIGltcGxlbWVudGF0aW9uIG9mIHRoZSByZWNlaXZlciBmdW5jdGlvbmFsaXR5Lg0K PiBUaGlzIHRvIG1lIGlzIGluZGVwZW5kZW50IG9mIGEgZGVjaXNpb24gd2hldGhlciB0byB1c2Ug dGhlIEVDTiBmdW5jdGlvbmFsaXR5DQo+IGF0IHRoZSBzZW5kZXIuIEnigJlkIHN1cHBvcnQgaXQg YmVpbmcgbWFuZGF0b3J5IHRvIGltcGxlbWVudCAqYXQgbGVhc3QqIGJhc2ljDQo+IEVDTiByZWNl aXZlciBzdXBwb3J0ICh3aGljaCBJIHRoaW5rIGlzIHNpbWlsYXIgdG8gd2hhdCBtYXJjZWxvIHNh aWQpLg0KPiANCj4gZHJhZnQtaWV0Zi10c3Z3Zy1yZmM1NDA1YmlzIChub3cgaW4gUkZDLUVEIHF1 ZXVlKSwgcHJvdmlkZXMgYSBjaGVja2xpc3QgZm9yDQo+IFVEUCBzdXBwb3J0IGZvciBFQ04sIHRo ZSBjdXJyZW50IGxpc3QgaW4gdGhlIGRyYWZ0IHNlZW1zIHNpbWlsYXIsIGJ1dCBpcyBub3QNCj4g cXVpdGUgdGhlIHNhbWUuIEkgdGhpbmsgc2luY2UgcmZjNTQwNWJpcyBpcyBzY2hlZHVsZWQgZm9y IEJDUCwgaXQgd291bGQgYmUgZ29vZA0KPiB0byBjaXRlIHRoaXMgYW5kIGFsaWduIHdoZXJlIHBv c3NpYmxlLg0KW0lKXSBUb3RhbGx5IG1pc3NlZCB0aGlzLCBzb3JyeSBmb3IgdGhlIGlnbm9yYW5j ZSwgc2hvdWxkIGRlZmluaXRlbHkgYmUgcmVmZXJlbmNlZC4NCg0KPiANCj4gVGhlIGRlY2lzaW9u IHdoZXRoZXIgYSBzZW5kZXIgY2hvb3NlcyB0byBtYXJrIHVzaW5nIEVDVCgwKSBvciBFQ1QoMSkg b3INCj4gbmVpdGhlciBuZWVkcyB0byBiZSBiYXNlZCBvbiB1bmRlcnN0YW5kaW5nIG9mIHdoZXRo ZXIgdGhlIGNvbWJpbmVkIHNlbmQNCj4gYW5kIHJlY2VpdmUgc3RhY2tzIGFuZCBuZXR3b3JrIGRl dmljZXMgY3VycmVudGx5IHByb3ZpZGUgc3VwcG9ydCAob3IgbW9yZQ0KPiBsaWtlbHkgbWVhc3Vy ZW1lbnQpLCBtb25pdG9yaW5nIGFzIGRlc2NyaWJlZCBpbiAyLjYgKGkuZS4sIHRoaXMgaXMgYSBw ZXItcGF0aA0KPiBydW4tdGltZSBkZWNpc2lvbikuIE9uZSB0aGluZyBhIFFVSUMgIHJlY2VpdmVy IG1heSBhbHJlYWR5IGtub3cgaXMgd2hldGhlcg0KPiBhIHJlY2VpdmUgc3RhY2sgaGFzIHN1cHBv cnQgZm9yIEVDTi4NCltJSl0gWWVzLCBpdCBzaG91bGQgYmUgcG9zc2libGUgZm9yIGEgc3RhY2sg dG8gc2VuZCBwYWNrZXRzIG92ZXIgdGhlIGxvY2FsIGludGVyZmFjZSAoMTI3LjAuMC4xKSBhbmQg Y2hlY2sgdGhlIHN0YXR1cyBvZiB0aGUgRUNOIGJpdHMuDQoNCg0KPiANCj4gSSBzdWdnZXN0IHRo aXMgcGxhY2VzIHJlcXVpcmVtZW50cyBvbiB0aGUgZmVlZGJhY2sgbWV0aG9kOg0KPiANCj4gQSBz ZW5kZXIgbWF5IG5lZWQgdG8gdW5kZXJzdGFuZCBob3cgdGhlIG5ldHdvcmsgZm9yd2FyZHMgRUNU KHgpIG1hcmtzDQo+IG9uIHRoZSBmb3J3YXJkIHBhdGggLSAoQWx0IDMgc2hvd3Mgc29tZSBmdW5j dGlvbmFsaXR5IGZvciB0aGlzKS4gIHRoaXMgY2FuDQo+IGNvbmZpcm0gd2hldGhlciBFQ1QoeCkg bWFya3MgYXJlIHJlY2VpdmVkLiBJIGV4cGVjdCB0aGlzIHdpbGwgYmUgbmVlZGVkIHRvDQo+IGtu b3cgdGhhdCBFQ1QgYW5kIEVDTi1DRSBtYXJrcyBhcmUgYWN0dWFsbHkgYmVpbmcgc2VudCBhY3Jv c3MgdGhlIGVudGlyZQ0KPiBwYXRoLCBhbmQgYXJlIG5vdCBjbGVhcmVkIGF0IHNvbWUgbWlkcG9p bnQsIGVyYXNpbmcgdGhlIGNvbmdlc3Rpb24NCj4gaW5mb3JtYXRpb24uICBJIHRoaW5rIGl0IGlz IGFsc28gd291bGQgYmUgdXNlZnVsIHRvIGtub3cgdGhhdA0KPiBFQ1QoMSkgaXMgYWN0dWFsbHkg dHJhdmVyc2luZyBhIHBhdGggd2hlbiB1c2luZyBuZXcgRUNUKDEpIHNlbWFudGljcyBhcw0KPiBk ZXNjcmliZWQgaW4gdGhlIHRzdndnIGRyYWZ0IChha2EgbGlrZSBMNFMpLg0KPiANCj4gSSBjYW4g c2VlIHJlYWwgYWR2YW50YWdlcyBpZiAgYWx0LTEsIGFsdC0yIGF0IGxlYXN0IHByb3ZpZGVzIGEg Y291bnQgdG8gaW5kaWNhdGUNCj4gdGhlIG51bWJlciBvZiBwYWNrZXRzIChieXRlcz8pIHJlY2Vp dmVkIHdpdGggbm90LUVDVDsgRUNUKDApOyBhbmQgRUNUKDEpLg0KW0lKXSBJIHdvdWxkIHNheSB0 aGF0IHlvdSB3aWxsIGdldCB0aGUgc2FtZSBpbmZvcm1hdGlvbiB3aXRoIGFsbCB0aGUgdGhyZWUg bWV0aG9kcywgIGluIHRoZSBjYXNlIG9mIGFsdCAxIGFuZCAyIHRoZSBidXJkZW4gdG8gY29tcHV0 ZSB0aGUgbnVtYmVyIG9mIG5vdC1FQ1QsIEVDVCgwKSBhbmQgRUNUKDEpIGlzIG9uIHRoZSBzZW5k ZXIgc2lkZSwgd2hpbGUgd2l0aCBhbHQgMyB0aGUgYnVyZGVuIGlzIG9uIHRoZSByZWNlaXZlciBz aWRlIChidXQgdGhlIGNvc3QgaXMgYWRtaXR0ZWRseSBxdWl0ZSBsb3cpLiANCg0KPiANCj4gS25v d2luZyByZWNlaXZlIGNvZGUgcG9pbnQgaW5mb3JtYXRpb24gd291bGQgYWxzbyBwcm92aWRlIG9w cG9ydHVuaXRpZXMgdG8NCj4gZGV0ZWN0IGFuZCByZWFjdCBhcHByb3ByaWF0ZWx5IHRvIG1pc2Jl aGF2aW5nIHJlY2VpdmVycy9wYXRocyAoaW5jbHVkaW5nDQo+IHNlbmRlciBjb250cm9sIHRvIHNl dCB0aGUgbWFyayB2YWx1ZSkgLSBhbHRob3VnaCBhdCBsZWFzdCB3aGlsZSB0aGUNCj4gcGF0aC9y ZWNlaXZlciBpcyBiZWluZyB2ZXJpZmllZCB0aGUgc2VuZGVyIHdpbGwgbGlrZWx5IGFsc28gYmUg bmVlZGVkIHRvIGtub3cNCj4gKndoaWNoKiBwYWNrZXRzIGNhcnJpZWQgYSBzcGVjaWZpYyBtYXJr LiAoYXMgbm90ZWQgYWx0LTMgbWF5IG5vdCBwcm92aWRlDQo+IHRoaXMpLiBIb3cgd2Ugc2hvdWxk IGRvIHRoaXMsIEkgYW0gbm90IHN1cmUgLSB2YXJpb3VzIHdheXMgZXhpc3QgLSBidXQNCj4gZGVz aWduaW5nIGEgdHJhbnNwb3J0IHRoYXQgY2FuIGFsbG93IHRoaXMgc2hvdWxkIGJlIHBvc3NpYmxl Lg0KW0lKXSBZZXMsIGFsdCAzLCBkb2VzIG5vdCBhbGxvdyB0byBkZXRlcm1pbmUgd2hpY2ggcGFj a2V0cyBoYXZlIHdoaWNoIEVDTiBtYXJrLCBpdCBpcyB1bmNsZWFyIHRob3VnaCB0byBtZSBob3cg aW1wb3J0YW50IHRoaXMgaXMuDQoNCj4gDQo+IEdvcnJ5DQo+IA0KPiANCj4gDQo+IE9uIDI2LzAx LzIwMTcgMTA6NDAsIG1hcmNlbG8gYmFnbnVsbyBicmF1biB3cm90ZToNCj4gPiBIaSwNCj4gPg0K PiA+IEkgaGF2ZSByZWFkIHRoZSBkcmFmdCBhbmQgaSB0aGluayBpdCBpcyBhIGdvb2Qgc3RhcnRp bmcgcG9pbnQgZm9yIHRoaXMNCj4gPiBpc3N1ZS4gdGhhbmtzIGZvciB3cml0aW5nIGl0Lg0KPiA+ DQo+ID4gTXkgbWFpbiBjb21tZW50IGlzIGFib3V0IHRoZSBFQ04gbmVnb3RpYXRpb24uIEkgYW0g dW5jb252aW5jZWQgdGhhdA0KPiA+IHRoZSBxdWljIHZlcnNpb24gbmVnb3RpYXRpb24gaXMgdGhl IHJpZ2h0IGFwcHJvYWNoIGZvciB0aGlzLg0KPiA+DQo+ID4gSSBtZWFuLCBhZmFpdSwgcXVpYyB2 ZXJzaW9uIG5lZ290aWF0aW9uIGltcG9zZXMgYW4gZXh0cmEgUlRUIHdoZW4gdGhlDQo+ID4gbmV3 IHZlcnNpb24gaXMgbm90IHN1cHBvcnRlZC4gSSB0aGluayB0aGlzIGlzIG9rIGZvciBtYWpvciB2 ZXJzaW9uDQo+ID4gY2hhbmdlcywgYnV0IEkgZG9udCB0aGluayB0aGlzIGlzIGFwcHJvcHJpYXRl IGZvciBmZWF0dXJlIG5lZ290aWF0aW9uDQo+ID4gc3VjaCBhcyBFQ04uDQo+ID4NCj4gPiBJIG1l YW4sIHVubGVzcyBFQ04gaXMgc3VwcG9ydGVkIGJ5IGRlZmF1bHQgaW4gdGhlIGZpcnN0IHF1aWMg dmVyc2lvbiwNCj4gPiBJIHRoaW5rIHVzaW5nIHF1aWMgdmVyc2lvbiBuZWdvdGlhdGlvbiBmb3Ig IEVDTiBzdXBwb3J0IHdvdWxkIGJlIGFuDQo+ID4gb2JzdGFjbGUgaW4gRUNOIGFkb3B0aW9uIGlu IHF1aWMuIEkgbWVhbiwgaWYgd2UgZW5kIHVwIGluIHRoZQ0KPiA+IHNpdHVhdGlvbiB0aGF0IHRo ZSBmaXJzdCAod2lkZWx5IGRlcGxveWVkKSBxdWljIHByb3RvY29sIHNwZWNpZmljYXRpb24NCj4g PiBkb2VzIG5vdCBzdXBwb3J0IEVDTiBieSBkZWZhdWx0LCB0aGVuIGhhdmluZyBFQ04gbmVnb3Rp YXRpb24gdXNpbmcNCj4gPiBxdWljIHZlcnNpb24gd2lsbCBpbXBseSB0aGF0IGlmIGEgY2xpZW50 IHdhbnRzIHRvIHRyaWVzIHRvIHNlZSBpZiB0aGUNCj4gPiBzZXJ2ZXIgc3VwcG9ydHMgRUNOLCBp dCByaXNrcyB0byBoYXZlIGEgZXh0cmEgUlRUIHBlbmFsdHkuIChpDQo+ID4gdW5kZXJzdGFuZCB0 aGUgY2xpZW50IGNhbiBjYWNoZSB3aGljaCBzZXJ2ZXJzIHN1cHBvcnQgRUNOLCBidXQgd2UgYXJl DQo+ID4gYmFjayBpbnRvIHdvcmtpbmcgYXJvdW5kIHRoZXNlIGRpZmZpY3VsdGllcyB0aGF0IG1h a2UgZWNuIGFkb3B0aW9uDQo+ID4gaGFyZGVyKS4NCltJSl0gUXVpdGUgY29udmluY2luZyBhcmd1 bWVudHMgSSBtdXN0IHNheS4NCg0KPiA+DQo+ID4gVGhlIG90aGVyIHByb2JsZW0gaXMgcmVsYXRl ZCB0byB0aGUgYmxvY2tpbmcgb2YgRUNOIGJpdHMgaW4gdGhlIElQDQo+ID4gaGVhZGVyLiBJZGVh bGx5LCBJIGd1ZXNzLCB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIGxlYXJuIGlmIHRoZQ0K PiA+IEVDTiBiaXRzIGFyZSBibG9ja2VkIGR1cmluZyB0aGUgbmVnb3RpYXRpb24gcGhhc2UgaS5l LiB0aGUgbmVnb3RpYXRpb24NCj4gPiBjYW4gZmFpbCBlaXRoZXIgYmVjYXVzZSB0aGUgc2VydmVy IGRvZXNudCBzdXBwb3J0IGl0IG9yIGJlY2F1c2UgdGhlDQo+ID4gbmV0d29yayBkb2VzbnQgc3Vw cG9ydCBpdC4gQmVjYXVzZSBvZiB0aGlzLCBJIHdvdWxkIGFyZ3VlIHRoYXQgdGhlDQo+ID4gZ29v ZCBhcHByb2FjaCBpcyB0byBoYXZlIHRoZSBFQ04gYml0cyBzZXQgaW4gdGhlIElQIGhlYWRlciBv ZiB0aGUNCj4gPiBwYWNrZXQgY2FycnlpbmcgdGhlIEVDTiBuZWdvdGlhdGlvbi4NCltJSl0gT0sN Cg0KPiA+DQo+ID4gU28sIHdpdGggYWxsIHRoaXMsIEkgdGhpbmsgaXQgbWF5IGJlIGEgYmV0dGVy IGFwcHJvYWNoIHRvIG1ha2UgRUNODQo+ID4gbmVnb3RpYXRpb24gdG8gYmUgZG9uZSB1c2luZyBh IG5ldyBmcmFtZSB0eXBlIHRoYXQgaXMgc2VudCBpbiB0aGUNCj4gPiBzdHJlYW0gMS4gVGhpcyB3 b3VsZCBiZSBhIG1lc3NhZ2UgdGhhdCB0aGUgc2VuZGVyIGlzc3VlcywgYWZ0ZXIgdGhlDQo+ID4g Y29ubmVjdGlvbiBoYXMgYmVlbiBlc3RhYmxpc2hlZCwgdG8gcmVxdWVzdCBFQ04gc3VwcG9ydCBm cm9tIHRoZSBvdGhlcg0KPiA+IGVuZHBvaW50LiBUaGlzIG1lc3NhZ2Ugd291bGQgYmUgc2VudCBp biBhbiBFQ04gbWFya2VkIHBhY2tldCwgdG8NCj4gPiB2ZXJpZnkgdGhhdCB0aGUgbmV0d29yayBk ZWxpdmVycyB0aGUgbWVzc2FnZS4gVGhlIG90aGVyIGVuZHBvaW50IGNhbg0KPiA+IHJlcGx5IHdp dGggYW5vdGhlciBtZXNzYWdlIGFjY2VwdGluZyBvZiBub3QgdGhlIEVDTiBzdXBwb3J0IGZvciB0 aGUNCj4gPiBjb25uZWN0aW9uLg0KW0lKXSBZZXMsIGFub3RoZXIgbWVzc2FnZSBvciB0byBzaW1w bHkgaW5kaWNhdGUgaXQgaW4gdGhlIEFDSyBmcmFtZS4NCg0KPiA+DQo+ID4gSSB0aGluayB0aGlz IGFwcHJvYWNoIGhhcyB0aGUgYmVuZWZpdCBvZiBub3QgaW1wb3NpbmcgZXh0cmEgbGF0ZW5jeQ0K PiA+IGZvciB0aG9zZSB3aG8gd2FudCB0byBjaGVjayBpZiBFQ04gaXMgc3VwcG9ydGVkIGFuZCBh dCB0aGUgc2FtZSB0aW1lDQo+ID4gdmVyaWZpZXMgdGhhdCB0aGUgbmV0d29yayBpcyBhYmxlIHRv IGRlbGl2ZXIgRUNOIG1hcmtlZCBwYWNrZXRzLiBJZg0KPiA+IGFueSBvZiB0aGVzZSBjb25kaXRp b25zIGZhaWwsIHRoZSBuZWdvdGlhdGlvbiBmYWlsLiBNb3Jlb3ZlciwgaSB0aGluaw0KPiA+IHRo ZXNlIG1lc3NhZ2VzIGNhbiBiZSB1c2VkIHRvIGRpc2FibGUgRUNOIGluIHRoZSBtaWRkbGUgb2Yg dGhlDQo+ID4gY29ubmVjdGlvbi4gT25lIGNhc2Ugd2hlcmUgdGhpcyBjYW4gYmUgdXNlZnVsIGlz IGluIGEgbW9iaWxpdHkNCj4gPiBzY2VuYXJpbywgd2hlcmUgb25lIG9mIHRoZSBlbmRwb2ludHMg bW92ZSBhbmQgaW4gb3JkZXIgdG8gY2hlY2sgaWYgdGhlDQo+ID4gbmV3IHBhdGggc3RpbGwgc3Vw cG9ydHMgRUNOLCB0aGV5IGNhbiByZXNlbmQgdGhlIG9wdGlvbiBhbmQgc2VlIGlmIHRoZQ0KPiA+ IHBhY2tldHMgc3RpbGwgbWFrZSBpdC4gSSBndWVzcyBtb3JlIGNvbXBsaWNhdGVkIHZlcmlmaWNh dGlvbiBtZXRob2RzDQo+ID4gY291bGQgYmUgYnVpbHQgaW50byB0aGlzLg0KPiA+DQo+ID4gdGhv dWdodHM/DQpbSUpdIFNvdW5kcyBxdWl0ZSByZWFzb25hYmxlLCBJIGEgYml0IHVuY2VydGFpbiBp ZiBpdCBzaG91bGQgYmUgYW4gRUNOIGZyYW1lIHRoYXQgaXMgYWNrbm93bGVkZ2VkIGJ5IGFuIEVD TiBmcmFtZSBvciBpZiB0aGUgQUNLIGZyYW1lIHdpdGggYW4gRUNOIGZpZWxkIGlzIHN1ZmZpY2ll bnQuICANCg0KPiA+DQo+ID4gcmVnYXJkcywgbWFyY2Vsbw0KPiA+DQoNCg== From nobody Wed Feb 1 05:58:20 2017 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 149D0129460 for ; Wed, 1 Feb 2017 05:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iadt2DU1tlNj for ; Wed, 1 Feb 2017 05:58:17 -0800 (PST) Received: from mail-wj0-x229.google.com (mail-wj0-x229.google.com [IPv6:2a00:1450:400c:c01::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 E94BE12943C for ; Wed, 1 Feb 2017 05:58:16 -0800 (PST) Received: by mail-wj0-x229.google.com with SMTP id la6so10595229wjc.0 for ; Wed, 01 Feb 2017 05:58:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=6kSOJCcKcL8zlRsgLUXpOdFs5Ab1UujDyxPhntFafj4=; b=qVdhhMiA1x+ZJxAhoc2eOSDTpH33LskYUeD3pr01C/hgeytYd/JOP/eCihRr4epzzD 80ql/thRcdoj8TW/VaT4TRnHM+xhF89ZrBeDkghy941XXqL5e8BA9dBvNIs22x1C+cxi fwddoOv2W4a3Kd1mZrZaEg0Zk3YBq6dCC1uHGTpvscu4GvUi75Ljgk/MnbF/dcLB+bLl eYCmdGI9rkgL5MUMH3i0LQ0S1ivNswqXXww0e6alNncY7GxpCvSZaYCVp9uDKIw2SPaV YekHIbQ678EL2G5X+5buy0PMnnN+aI5vk0/eCDV8l2JyPx2/a2vNQqzoyjtPD5mWeN3M JEfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=6kSOJCcKcL8zlRsgLUXpOdFs5Ab1UujDyxPhntFafj4=; b=QVeK3YUliuTpytMKef+MTaR460Ct492DjOnpZ2VKgexvpHnNpm46B2Tfn/h5rQvlrT wAmjVaNbVjWB8Ve62J5sUBJOyeDxO+M3H3qvFZJStymXzQepNWUf0eCjIY7uTaVcePNp 6Mv++sudfaRM05aotAeAFPH60CngUmp1bvoEv+DxSFhxUTaBhfZn19OGwvEh384aQSXk LXZnUX+Nut4IHQZENNUwoT/g9NffxZ3txsdwPLtk8zkDTw3Nfc9C9+93MtkuEKq7BrfJ 4qEXhjJB7oicHjcR9Do3vkBsBlzLErEvbxcgyf8gg9MztDpjKzSOcAc+1I+zgB7JKHSb uCIQ== X-Gm-Message-State: AIkVDXKdtUhZBQfGrKCtoNhEyGe7lzTmdDIcz1SFuyGY6kjDD6EcCnO6WUxxAMCniw5q1R1o X-Received: by 10.223.163.30 with SMTP id c30mr2761451wrb.40.1485957495283; Wed, 01 Feb 2017 05:58:15 -0800 (PST) Received: from Macintosh-6.local ([2001:720:410:1010:3cda:de98:9364:cd47]) by smtp.gmail.com with ESMTPSA id s26sm33953657wra.26.2017.02.01.05.58.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 05:58:13 -0800 (PST) Subject: Re: about draft-johansson-quic-ecn-00 To: Ingemar Johansson S , "gorry@erg.abdn.ac.uk" References: <79bfa1c0-ff80-8a98-0e50-bc03d5a96b30@it.uc3m.es> <5890DDCF.6010507@erg.abdn.ac.uk> From: marcelo bagnulo braun Message-ID: Date: Wed, 1 Feb 2017 14:58:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 13:58:20 -0000 inline... El 01/02/17 a las 14:24, Ingemar Johansson S escribió: > Hi Gorry and Marcelo + others > > Thanks for the review and comments. I understand that the negotiation phase is the more problematic aspect. > > The proposed ECN frame sounds like a good idea as this makes it possible to do the ECN negotiation without delaying the connection setup (in case ECN fails). The possible drawback is that "non-ECN capable" connection setup packets may be discarded over a congested ECN capable path and that may delay the connection setup too. I dont think we should prevent the quic handshake packets to be ECT marked. (funny enough, if i understand correctly stream 1 packets are not constrained by congestion control, so there wouldnt be needed to feed the CE back, since the sender is not supposed to react to this, if i understand this correctly) > So if I understand the ECN frame correctly. It would be of a given size (~MTU?) and have the ECN bits set (=CE?). i am not sure why it should carry more than one byte for the frame type and an extra byte for signalling The packet carrying this one would contain the ECT codepoint, i would say > The receiver can reply in two ways. > 1) Using the ECN echo in the ACK frame, assumes that the ECN frame has a sequence number > 2) Using an ECN frame in the reverse direction (the ECN frame can then indicate the ECN bit) > but there is a difference between having received the ECN frame correctly and the server actually accpeting the use of ECN in the connection. that is why i think we need to use one of the bits in the ECN flag to confirm that the receiver wants to use ECN for this connection, no? regards, marcelo > More comments inline below > > /Ingemar > >> -----Original Message----- >> From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] >> Sent: den 31 januari 2017 19:56 >> To: marcelo bagnulo braun >> Cc: quic@ietf.org; Ingemar Johansson S >> >> Subject: Re: about draft-johansson-quic-ecn-00 >> >> I'd also like to thank you for this consideration of where ECN fits within QUIC. >> I have a few comments, see below: >> >> I really do see merit in requiring implementation of the receiver functionality. >> This to me is independent of a decision whether to use the ECN functionality >> at the sender. I’d support it being mandatory to implement *at least* basic >> ECN receiver support (which I think is similar to what marcelo said). >> >> draft-ietf-tsvwg-rfc5405bis (now in RFC-ED queue), provides a checklist for >> UDP support for ECN, the current list in the draft seems similar, but is not >> quite the same. I think since rfc5405bis is scheduled for BCP, it would be good >> to cite this and align where possible. > [IJ] Totally missed this, sorry for the ignorance, should definitely be referenced. > >> The decision whether a sender chooses to mark using ECT(0) or ECT(1) or >> neither needs to be based on understanding of whether the combined send >> and receive stacks and network devices currently provide support (or more >> likely measurement), monitoring as described in 2.6 (i.e., this is a per-path >> run-time decision). One thing a QUIC receiver may already know is whether >> a receive stack has support for ECN. > [IJ] Yes, it should be possible for a stack to send packets over the local interface (127.0.0.1) and check the status of the ECN bits. > > >> I suggest this places requirements on the feedback method: >> >> A sender may need to understand how the network forwards ECT(x) marks >> on the forward path - (Alt 3 shows some functionality for this). this can >> confirm whether ECT(x) marks are received. I expect this will be needed to >> know that ECT and ECN-CE marks are actually being sent across the entire >> path, and are not cleared at some midpoint, erasing the congestion >> information. I think it is also would be useful to know that >> ECT(1) is actually traversing a path when using new ECT(1) semantics as >> described in the tsvwg draft (aka like L4S). >> >> I can see real advantages if alt-1, alt-2 at least provides a count to indicate >> the number of packets (bytes?) received with not-ECT; ECT(0); and ECT(1). > [IJ] I would say that you will get the same information with all the three methods, in the case of alt 1 and 2 the burden to compute the number of not-ECT, ECT(0) and ECT(1) is on the sender side, while with alt 3 the burden is on the receiver side (but the cost is admittedly quite low). > >> Knowing receive code point information would also provide opportunities to >> detect and react appropriately to misbehaving receivers/paths (including >> sender control to set the mark value) - although at least while the >> path/receiver is being verified the sender will likely also be needed to know >> *which* packets carried a specific mark. (as noted alt-3 may not provide >> this). How we should do this, I am not sure - various ways exist - but >> designing a transport that can allow this should be possible. > [IJ] Yes, alt 3, does not allow to determine which packets have which ECN mark, it is unclear though to me how important this is. > >> Gorry >> >> >> >> On 26/01/2017 10:40, marcelo bagnulo braun wrote: >>> Hi, >>> >>> I have read the draft and i think it is a good starting point for this >>> issue. thanks for writing it. >>> >>> My main comment is about the ECN negotiation. I am unconvinced that >>> the quic version negotiation is the right approach for this. >>> >>> I mean, afaiu, quic version negotiation imposes an extra RTT when the >>> new version is not supported. I think this is ok for major version >>> changes, but I dont think this is appropriate for feature negotiation >>> such as ECN. >>> >>> I mean, unless ECN is supported by default in the first quic version, >>> I think using quic version negotiation for ECN support would be an >>> obstacle in ECN adoption in quic. I mean, if we end up in the >>> situation that the first (widely deployed) quic protocol specification >>> does not support ECN by default, then having ECN negotiation using >>> quic version will imply that if a client wants to tries to see if the >>> server supports ECN, it risks to have a extra RTT penalty. (i >>> understand the client can cache which servers support ECN, but we are >>> back into working around these difficulties that make ecn adoption >>> harder). > [IJ] Quite convincing arguments I must say. > >>> The other problem is related to the blocking of ECN bits in the IP >>> header. Ideally, I guess, the client should be able to learn if the >>> ECN bits are blocked during the negotiation phase i.e. the negotiation >>> can fail either because the server doesnt support it or because the >>> network doesnt support it. Because of this, I would argue that the >>> good approach is to have the ECN bits set in the IP header of the >>> packet carrying the ECN negotiation. > [IJ] OK > >>> So, with all this, I think it may be a better approach to make ECN >>> negotiation to be done using a new frame type that is sent in the >>> stream 1. This would be a message that the sender issues, after the >>> connection has been established, to request ECN support from the other >>> endpoint. This message would be sent in an ECN marked packet, to >>> verify that the network delivers the message. The other endpoint can >>> reply with another message accepting of not the ECN support for the >>> connection. > [IJ] Yes, another message or to simply indicate it in the ACK frame. > >>> I think this approach has the benefit of not imposing extra latency >>> for those who want to check if ECN is supported and at the same time >>> verifies that the network is able to deliver ECN marked packets. If >>> any of these conditions fail, the negotiation fail. Moreover, i think >>> these messages can be used to disable ECN in the middle of the >>> connection. One case where this can be useful is in a mobility >>> scenario, where one of the endpoints move and in order to check if the >>> new path still supports ECN, they can resend the option and see if the >>> packets still make it. I guess more complicated verification methods >>> could be built into this. >>> >>> thoughts? > [IJ] Sounds quite reasonable, I a bit uncertain if it should be an ECN frame that is acknowledged by an ECN frame or if the ACK frame with an ECN field is sufficient. > >>> regards, marcelo >>> From nobody Wed Feb 1 06:07:30 2017 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 C00F0129481 for ; Wed, 1 Feb 2017 06:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IFFatZ-YkEjw for ; Wed, 1 Feb 2017 06:07:27 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D7C129460 for ; Wed, 1 Feb 2017 06:07:27 -0800 (PST) X-AuditID: c1b4fb2d-e76b398000007e3d-5b-5891eb9d502f Received: from ESESSHC011.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id 64.FF.32317.D9BE1985; Wed, 1 Feb 2017 15:07:25 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.51) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 1 Feb 2017 15:07:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=TQSmjOu31rR3FOJkWw6sq1BfZNREoMtRvvQW7+mBN18=; b=dLt044P46AWVMqT5gLmcxHp6w3kAEYy/PpHSXj4YxCnLKWFkPCwT/2sXtuzTdqA0dUQ3zBAQva7RAhEw2bA4L8fug/XZJ9zebnKc4tDXpmhnr7RVUOxzLfraySmSis0w2RYwwThWpBbwo0subDIpPF8YsifgoIV6WQuF7edp69o= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Wed, 1 Feb 2017 14:07:15 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0888.016; Wed, 1 Feb 2017 14:07:15 +0000 From: Ingemar Johansson S To: marcelo bagnulo braun , "gorry@erg.abdn.ac.uk" Subject: RE: about draft-johansson-quic-ecn-00 Thread-Topic: about draft-johansson-quic-ecn-00 Thread-Index: AQHSd7hAuGVD/TJHuEGnPsqrrJ7jGKFS9/SAgAEkbWCAABqlgIAAASVw Date: Wed, 1 Feb 2017 14:07:15 +0000 Message-ID: References: <79bfa1c0-ff80-8a98-0e50-bc03d5a96b30@it.uc3m.es> <5890DDCF.6010507@erg.abdn.ac.uk> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-office365-filtering-correlation-id: efe30017-2ea1-4be7-ceef-08d44aaba049 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB346; x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 7:n7QPVyEPnvON420H+pToxnN+mNhCzjB/z3XR1oKNoDaGrhmM4/OVxPYDZvLzWRFQhEZUykU8GGky5PAlFhZ4TeTMFilQwhp8eb3v8cJAM6QJPGYZXLdydjDIwMhNZTsKtazdy9A5uAjjmRMerkZqjHcBaN70jkClw3W6Dg0t3Kqo151JKvw/l1GeRilT4pc1Up8CQq1ZhxlZNrhVbdCtIbN5WJLOfk4w0ru0eQItEgWOnV+2J+tYzEjX5kzA0Gk7EzHM9dkeWYc5PnoQ5uZ01+5f0l2pQJPaqXGt/HKxdAmwfaSOEou/XuOaLgDAFV+XCHtKaUGMSzlZbOgt0Snoea3k5R42Cqpx64RYAv/0PFt5mA85JmhiyRreB3b4n2WKx/kAq/O+j0dBQxk8O2UA5xu4PF0EyQptGuczyMX3yTVHQ/EFNZmFGdElUR7g5pRaijk8y76N1AXf22lQJgSOnSGPd9nAZ/jfpqilhJMyE0rMuvETYcFRWz2xC8b1tbB8p54p13sPGnTVd+OcG/qq0HT7wO+/Ns5wSsbxZODzDKZne1jHzA/NeSJpcvNOxhc3 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123558025)(20161123564025)(20161123560025)(20161123562025)(20161123555025)(6072148); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 0205EDCD76 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(51914003)(24454002)(189002)(13464003)(199003)(50986999)(8676002)(8936002)(105586002)(6436002)(55016002)(7736002)(25786008)(106116001)(106356001)(54356999)(305945005)(68736007)(2900100001)(6506006)(99286003)(74316002)(345774005)(3660700001)(76176999)(189998001)(3280700002)(93886004)(77096006)(101416001)(38730400001)(33656002)(9686003)(7696004)(229853002)(2906002)(81166006)(81156014)(4326007)(102836003)(122556002)(53936002)(5660300001)(230783001)(92566002)(66066001)(5001770100001)(86362001)(2950100002)(2501003)(6116002)(97736004)(3846002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.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-MS-Exchange-CrossTenant-originalarrivaltime: 01 Feb 2017 14:07:15.4446 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGObv3zut0dVqKL2ZQyz9q4dQ+zEIsDcTApA8oscCG3nSoU3aX pkgZqKFpOZHQmSg1Kk2bWavUWWwqFiIpCZJfc6WmWCmaE7Gibceg/368z8P7vOfhsJSkjPFl lSoNp1Yp0qRCEV0d9zsvoHZeGxe0YPALnS+qQaGF043C0NJ6j2NUdOnyrCBar18TRNuHnzGn qHhRWBKXpszi1IHhl0Qpy+O9KPPz5asdLweZfFSeVILcWcAHwDRcIChBIlaCDQgG7usopyDB vQhWFzc7BRqXUTBVWkMTV6UAbhitbsTVg0Bff9zJQhwGDZZV5GQvnADWt3rXJgrvgsq+fMbJ W7EcRtubGOIJhJ7abgHhKBjv/OXaSWN/0LYUCZ0sxvFws8eCSPAMgtm2bleAOw4HY2cv7WSE t4N1dYImYT4wMlUnIG/DoDd9oAh7w9yXPwzxJ8LSpzIHs475DrAZY4nlJFQZ7G6EY2B9uMnN mQt4mYa7XaMMEZSwZu8TEr4Abyq6EDFVCcBuu7MR5gezFQ8ZItgZ+DFo2qiLg0fNhYhU4Qvj Q8WoHMl0/x2ucxxF4T1gaA8k451QecvmpnOVsQXeV0/R9YhuRN48x/Ppyfv2yzm1MpHnM1Ry FadpRY5PYn6xHvAaPZmPsCDMIqmnuGWiPE7CKLL4nHQLApaSeonHZrVxEnGSIieXU2ckqK+k cbwFbWNpqY84pMF6XoKTFRouleMyOfU/VcC6++YjsSikY1XWlMgmf/9mrju0N/fp3NiDguzM Eas8YzDi8JHJ2ODnfGqMvNXvJ+t9MV7T1bgerDldExmQnTzoHzUtvmZpPnFmpvh2ODWk+hr8 +Lp3jEeRrN/4btOiLu/jdEW/MXJJcm+l0DNSKz1q6zG9GmicPrcS1HZwYfdkytlOs1lK8ymK YBml5hV/AeDFSRIgAwAA Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 14:07:29 -0000 SGkNCg0KSW5saW5lDQovSQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IG1hcmNlbG8gYmFnbnVsbyBicmF1biBbbWFpbHRvOm1hcmNlbG9AaXQudWMzbS5lc10NCj4gU2Vu dDogZGVuIDEgZmVicnVhcmkgMjAxNyAxNDo1OA0KPiBUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8 aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+Ow0KPiBnb3JyeUBlcmcuYWJkbi5hYy51 aw0KPiBDYzogcXVpY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogYWJvdXQgZHJhZnQtam9oYW5z c29uLXF1aWMtZWNuLTAwDQo+IA0KPiBpbmxpbmUuLi4NCj4gDQo+IEVsIDAxLzAyLzE3IGEgbGFz IDE0OjI0LCBJbmdlbWFyIEpvaGFuc3NvbiBTIGVzY3JpYmnDszoNCj4gPiBIaSBHb3JyeSBhbmQg TWFyY2VsbyArIG90aGVycw0KPiA+DQo+ID4gVGhhbmtzIGZvciB0aGUgcmV2aWV3IGFuZCBjb21t ZW50cy4gSSB1bmRlcnN0YW5kIHRoYXQgdGhlIG5lZ290aWF0aW9uDQo+IHBoYXNlIGlzIHRoZSBt b3JlIHByb2JsZW1hdGljIGFzcGVjdC4NCj4gPg0KPiA+IFRoZSBwcm9wb3NlZCBFQ04gZnJhbWUg c291bmRzIGxpa2UgYSBnb29kIGlkZWEgYXMgdGhpcyBtYWtlcyBpdCBwb3NzaWJsZQ0KPiB0byBk byB0aGUgRUNOIG5lZ290aWF0aW9uIHdpdGhvdXQgZGVsYXlpbmcgdGhlIGNvbm5lY3Rpb24gc2V0 dXAgKGluIGNhc2UNCj4gRUNOIGZhaWxzKS4gVGhlIHBvc3NpYmxlIGRyYXdiYWNrIGlzIHRoYXQg Im5vbi1FQ04gY2FwYWJsZSIgY29ubmVjdGlvbiBzZXR1cA0KPiBwYWNrZXRzIG1heSBiZSBkaXNj YXJkZWQgb3ZlciBhIGNvbmdlc3RlZCBFQ04gY2FwYWJsZSBwYXRoIGFuZCB0aGF0IG1heQ0KPiBk ZWxheSB0aGUgY29ubmVjdGlvbiBzZXR1cCB0b28uDQo+IEkgZG9udCB0aGluayB3ZSBzaG91bGQg cHJldmVudCB0aGUgcXVpYyBoYW5kc2hha2UgcGFja2V0cyB0byBiZSBFQ1QNCj4gbWFya2VkLg0K PiAoZnVubnkgZW5vdWdoLCBpZiBpIHVuZGVyc3RhbmQgY29ycmVjdGx5IHN0cmVhbSAxIHBhY2tl dHMgYXJlIG5vdCBjb25zdHJhaW5lZA0KPiBieSBjb25nZXN0aW9uIGNvbnRyb2wsIHNvIHRoZXJl IHdvdWxkbnQgYmUgbmVlZGVkIHRvIGZlZWQgdGhlIENFIGJhY2ssDQo+IHNpbmNlIHRoZSBzZW5k ZXIgaXMgbm90IHN1cHBvc2VkIHRvIHJlYWN0IHRvIHRoaXMsIGlmIGkgdW5kZXJzdGFuZCB0aGlz DQo+IGNvcnJlY3RseSkNCj4gDQo+ID4gU28gaWYgSSB1bmRlcnN0YW5kIHRoZSBFQ04gZnJhbWUg Y29ycmVjdGx5LiBJdCB3b3VsZCBiZSBvZiBhIGdpdmVuIHNpemUNCj4gKH5NVFU/KSBhbmQgaGF2 ZSB0aGUgRUNOIGJpdHMgc2V0ICg9Q0U/KS4NCj4gDQo+IGkgYW0gbm90IHN1cmUgd2h5IGl0IHNo b3VsZCBjYXJyeSBtb3JlIHRoYW4gb25lIGJ5dGUgZm9yIHRoZSBmcmFtZSB0eXBlIGFuZA0KPiBh biBleHRyYSBieXRlIGZvciBzaWduYWxsaW5nIFRoZSBwYWNrZXQgY2FycnlpbmcgdGhpcyBvbmUg d291bGQgY29udGFpbiB0aGUNCj4gRUNUIGNvZGVwb2ludCwgaSB3b3VsZCBzYXkNCg0KW0lKXSBZ ZXMsIGl0IHNob3VsZCBiZSBzdWZmaWNpZW50IHdpdGggYSBzbWFsbCBFQ04gZnJhbWUsIGEgdGhv dWdodCB0aGF0IHN0cnVjayBtZSBpcyB0aGF0IGlmIHRoZXJlIGlzIHNvbWUgbWFnaWMgZGlmZmVy ZW50aWF0aW9uIGJldHdlZW4gc21hbGwgYW5kIGxhcmdlIHBhY2tldHMgaW4gdGhlIG5ldHdvcmss IGJ1dCBwZXJoYXBzIHRoaXMgaXMgYSBsb25nIHNob3QuLi4NCg0KPiANCj4gPiBUaGUgcmVjZWl2 ZXIgY2FuIHJlcGx5IGluIHR3byB3YXlzLg0KPiA+IDEpIFVzaW5nIHRoZSBFQ04gZWNobyBpbiB0 aGUgQUNLIGZyYW1lLCBhc3N1bWVzIHRoYXQgdGhlIEVDTiBmcmFtZSBoYXMNCj4gPiBhIHNlcXVl bmNlIG51bWJlcg0KPiA+IDIpIFVzaW5nIGFuIEVDTiBmcmFtZSBpbiB0aGUgcmV2ZXJzZSBkaXJl Y3Rpb24gKHRoZSBFQ04gZnJhbWUgY2FuIHRoZW4NCj4gPiBpbmRpY2F0ZSB0aGUgRUNOIGJpdCkN Cj4gPg0KPiANCj4gYnV0IHRoZXJlIGlzIGEgZGlmZmVyZW5jZSBiZXR3ZWVuIGhhdmluZyByZWNl aXZlZCB0aGUgRUNOIGZyYW1lIGNvcnJlY3RseQ0KPiBhbmQgdGhlIHNlcnZlciBhY3R1YWxseSBh Y2NwZXRpbmcgdGhlIHVzZSBvZiBFQ04gaW4gdGhlIGNvbm5lY3Rpb24uIHRoYXQgaXMNCj4gd2h5 IGkgdGhpbmsgd2UgbmVlZCB0byB1c2Ugb25lIG9mIHRoZSBiaXRzIGluIHRoZSBFQ04gZmxhZyB0 byBjb25maXJtIHRoYXQgdGhlDQo+IHJlY2VpdmVyIHdhbnRzIHRvIHVzZSBFQ04gZm9yIHRoaXMg Y29ubmVjdGlvbiwgbm8/DQo+IHJlZ2FyZHMsIG1hcmNlbG8NCltJSl0gWWVzLCBJIGFzc3VtZSB0 aGF0IHlvdSBtZWFuIGEgcG9zc2libGUgRUNOIGZsYWcgaW4gdGhlIEFDSyBmcmFtZSA/LiBBbHRl cm5hdGl2ZWx5IGFuIEVDTiBmcmFtZSBjYW4gYmUgdXNlZCBpbiB0aGUgcmV2ZXJzZSBkaXJlY3Rp b24gLg0KDQo+IA0KPiANCj4gPiBNb3JlIGNvbW1lbnRzIGlubGluZSBiZWxvdw0KPiA+DQo+ID4g L0luZ2VtYXINCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9t OiBHb3JyeSBGYWlyaHVyc3QgW21haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51a10NCj4gPj4gU2Vu dDogZGVuIDMxIGphbnVhcmkgMjAxNyAxOTo1Ng0KPiA+PiBUbzogbWFyY2VsbyBiYWdudWxvIGJy YXVuIDxtYXJjZWxvQGl0LnVjM20uZXM+DQo+ID4+IENjOiBxdWljQGlldGYub3JnOyBJbmdlbWFy IEpvaGFuc3NvbiBTDQo+ID4+IDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4NCj4g Pj4gU3ViamVjdDogUmU6IGFib3V0IGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMA0KPiA+Pg0K PiA+PiBJJ2QgYWxzbyBsaWtlIHRvIHRoYW5rIHlvdSBmb3IgdGhpcyBjb25zaWRlcmF0aW9uIG9m IHdoZXJlIEVDTiBmaXRzIHdpdGhpbg0KPiBRVUlDLg0KPiA+PiBJIGhhdmUgYSBmZXcgY29tbWVu dHMsIHNlZSBiZWxvdzoNCj4gPj4NCj4gPj4gSSByZWFsbHkgZG8gc2VlIG1lcml0IGluIHJlcXVp cmluZyBpbXBsZW1lbnRhdGlvbiBvZiB0aGUgcmVjZWl2ZXINCj4gZnVuY3Rpb25hbGl0eS4NCj4g Pj4gVGhpcyB0byBtZSBpcyBpbmRlcGVuZGVudCBvZiBhIGRlY2lzaW9uIHdoZXRoZXIgdG8gdXNl IHRoZSBFQ04NCj4gPj4gZnVuY3Rpb25hbGl0eSBhdCB0aGUgc2VuZGVyLiBJ4oCZZCBzdXBwb3J0 IGl0IGJlaW5nIG1hbmRhdG9yeSB0bw0KPiA+PiBpbXBsZW1lbnQgKmF0IGxlYXN0KiBiYXNpYyBF Q04gcmVjZWl2ZXIgc3VwcG9ydCAod2hpY2ggSSB0aGluayBpcyBzaW1pbGFyIHRvDQo+IHdoYXQg bWFyY2VsbyBzYWlkKS4NCj4gPj4NCj4gPj4gZHJhZnQtaWV0Zi10c3Z3Zy1yZmM1NDA1YmlzIChu b3cgaW4gUkZDLUVEIHF1ZXVlKSwgcHJvdmlkZXMgYQ0KPiA+PiBjaGVja2xpc3QgZm9yIFVEUCBz dXBwb3J0IGZvciBFQ04sIHRoZSBjdXJyZW50IGxpc3QgaW4gdGhlIGRyYWZ0DQo+ID4+IHNlZW1z IHNpbWlsYXIsIGJ1dCBpcyBub3QgcXVpdGUgdGhlIHNhbWUuIEkgdGhpbmsgc2luY2UgcmZjNTQw NWJpcyBpcw0KPiA+PiBzY2hlZHVsZWQgZm9yIEJDUCwgaXQgd291bGQgYmUgZ29vZCB0byBjaXRl IHRoaXMgYW5kIGFsaWduIHdoZXJlIHBvc3NpYmxlLg0KPiA+IFtJSl0gVG90YWxseSBtaXNzZWQg dGhpcywgc29ycnkgZm9yIHRoZSBpZ25vcmFuY2UsIHNob3VsZCBkZWZpbml0ZWx5IGJlDQo+IHJl ZmVyZW5jZWQuDQo+ID4NCj4gPj4gVGhlIGRlY2lzaW9uIHdoZXRoZXIgYSBzZW5kZXIgY2hvb3Nl cyB0byBtYXJrIHVzaW5nIEVDVCgwKSBvciBFQ1QoMSkNCj4gPj4gb3IgbmVpdGhlciBuZWVkcyB0 byBiZSBiYXNlZCBvbiB1bmRlcnN0YW5kaW5nIG9mIHdoZXRoZXIgdGhlIGNvbWJpbmVkDQo+ID4+ IHNlbmQgYW5kIHJlY2VpdmUgc3RhY2tzIGFuZCBuZXR3b3JrIGRldmljZXMgY3VycmVudGx5IHBy b3ZpZGUgc3VwcG9ydA0KPiA+PiAob3IgbW9yZSBsaWtlbHkgbWVhc3VyZW1lbnQpLCBtb25pdG9y aW5nIGFzIGRlc2NyaWJlZCBpbiAyLjYgKGkuZS4sDQo+ID4+IHRoaXMgaXMgYSBwZXItcGF0aCBy dW4tdGltZSBkZWNpc2lvbikuIE9uZSB0aGluZyBhIFFVSUMgIHJlY2VpdmVyIG1heQ0KPiA+PiBh bHJlYWR5IGtub3cgaXMgd2hldGhlciBhIHJlY2VpdmUgc3RhY2sgaGFzIHN1cHBvcnQgZm9yIEVD Ti4NCj4gPiBbSUpdIFllcywgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIGZvciBhIHN0YWNrIHRvIHNl bmQgcGFja2V0cyBvdmVyIHRoZSBsb2NhbA0KPiBpbnRlcmZhY2UgKDEyNy4wLjAuMSkgYW5kIGNo ZWNrIHRoZSBzdGF0dXMgb2YgdGhlIEVDTiBiaXRzLg0KPiA+DQo+ID4NCj4gPj4gSSBzdWdnZXN0 IHRoaXMgcGxhY2VzIHJlcXVpcmVtZW50cyBvbiB0aGUgZmVlZGJhY2sgbWV0aG9kOg0KPiA+Pg0K PiA+PiBBIHNlbmRlciBtYXkgbmVlZCB0byB1bmRlcnN0YW5kIGhvdyB0aGUgbmV0d29yayBmb3J3 YXJkcyBFQ1QoeCkNCj4gbWFya3MNCj4gPj4gb24gdGhlIGZvcndhcmQgcGF0aCAtIChBbHQgMyBz aG93cyBzb21lIGZ1bmN0aW9uYWxpdHkgZm9yIHRoaXMpLg0KPiA+PiB0aGlzIGNhbiBjb25maXJt IHdoZXRoZXIgRUNUKHgpIG1hcmtzIGFyZSByZWNlaXZlZC4gSSBleHBlY3QgdGhpcw0KPiA+PiB3 aWxsIGJlIG5lZWRlZCB0byBrbm93IHRoYXQgRUNUIGFuZCBFQ04tQ0UgbWFya3MgYXJlIGFjdHVh bGx5IGJlaW5nDQo+ID4+IHNlbnQgYWNyb3NzIHRoZSBlbnRpcmUgcGF0aCwgYW5kIGFyZSBub3Qg Y2xlYXJlZCBhdCBzb21lIG1pZHBvaW50LA0KPiA+PiBlcmFzaW5nIHRoZSBjb25nZXN0aW9uIGlu Zm9ybWF0aW9uLiAgSSB0aGluayBpdCBpcyBhbHNvIHdvdWxkIGJlDQo+ID4+IHVzZWZ1bCB0byBr bm93IHRoYXQNCj4gPj4gRUNUKDEpIGlzIGFjdHVhbGx5IHRyYXZlcnNpbmcgYSBwYXRoIHdoZW4g dXNpbmcgbmV3IEVDVCgxKSBzZW1hbnRpY3MNCj4gPj4gYXMgZGVzY3JpYmVkIGluIHRoZSB0c3Z3 ZyBkcmFmdCAoYWthIGxpa2UgTDRTKS4NCj4gPj4NCj4gPj4gSSBjYW4gc2VlIHJlYWwgYWR2YW50 YWdlcyBpZiAgYWx0LTEsIGFsdC0yIGF0IGxlYXN0IHByb3ZpZGVzIGEgY291bnQNCj4gPj4gdG8g aW5kaWNhdGUgdGhlIG51bWJlciBvZiBwYWNrZXRzIChieXRlcz8pIHJlY2VpdmVkIHdpdGggbm90 LUVDVDsgRUNUKDApOw0KPiBhbmQgRUNUKDEpLg0KPiA+IFtJSl0gSSB3b3VsZCBzYXkgdGhhdCB5 b3Ugd2lsbCBnZXQgdGhlIHNhbWUgaW5mb3JtYXRpb24gd2l0aCBhbGwgdGhlIHRocmVlDQo+IG1l dGhvZHMsICBpbiB0aGUgY2FzZSBvZiBhbHQgMSBhbmQgMiB0aGUgYnVyZGVuIHRvIGNvbXB1dGUg dGhlIG51bWJlciBvZg0KPiBub3QtRUNULCBFQ1QoMCkgYW5kIEVDVCgxKSBpcyBvbiB0aGUgc2Vu ZGVyIHNpZGUsIHdoaWxlIHdpdGggYWx0IDMgdGhlIGJ1cmRlbg0KPiBpcyBvbiB0aGUgcmVjZWl2 ZXIgc2lkZSAoYnV0IHRoZSBjb3N0IGlzIGFkbWl0dGVkbHkgcXVpdGUgbG93KS4NCj4gPg0KPiA+ PiBLbm93aW5nIHJlY2VpdmUgY29kZSBwb2ludCBpbmZvcm1hdGlvbiB3b3VsZCBhbHNvIHByb3Zp ZGUNCj4gPj4gb3Bwb3J0dW5pdGllcyB0byBkZXRlY3QgYW5kIHJlYWN0IGFwcHJvcHJpYXRlbHkg dG8gbWlzYmVoYXZpbmcNCj4gPj4gcmVjZWl2ZXJzL3BhdGhzIChpbmNsdWRpbmcgc2VuZGVyIGNv bnRyb2wgdG8gc2V0IHRoZSBtYXJrIHZhbHVlKSAtDQo+ID4+IGFsdGhvdWdoIGF0IGxlYXN0IHdo aWxlIHRoZSBwYXRoL3JlY2VpdmVyIGlzIGJlaW5nIHZlcmlmaWVkIHRoZQ0KPiA+PiBzZW5kZXIg d2lsbCBsaWtlbHkgYWxzbyBiZSBuZWVkZWQgdG8ga25vdw0KPiA+PiAqd2hpY2gqIHBhY2tldHMg Y2FycmllZCBhIHNwZWNpZmljIG1hcmsuIChhcyBub3RlZCBhbHQtMyBtYXkgbm90DQo+ID4+IHBy b3ZpZGUgdGhpcykuIEhvdyB3ZSBzaG91bGQgZG8gdGhpcywgSSBhbSBub3Qgc3VyZSAtIHZhcmlv dXMgd2F5cw0KPiA+PiBleGlzdCAtIGJ1dCBkZXNpZ25pbmcgYSB0cmFuc3BvcnQgdGhhdCBjYW4g YWxsb3cgdGhpcyBzaG91bGQgYmUgcG9zc2libGUuDQo+ID4gW0lKXSBZZXMsIGFsdCAzLCBkb2Vz IG5vdCBhbGxvdyB0byBkZXRlcm1pbmUgd2hpY2ggcGFja2V0cyBoYXZlIHdoaWNoIEVDTg0KPiBt YXJrLCBpdCBpcyB1bmNsZWFyIHRob3VnaCB0byBtZSBob3cgaW1wb3J0YW50IHRoaXMgaXMuDQo+ ID4NCj4gPj4gR29ycnkNCj4gPj4NCj4gPj4NCj4gPj4NCj4gPj4gT24gMjYvMDEvMjAxNyAxMDo0 MCwgbWFyY2VsbyBiYWdudWxvIGJyYXVuIHdyb3RlOg0KPiA+Pj4gSGksDQo+ID4+Pg0KPiA+Pj4g SSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBpIHRoaW5rIGl0IGlzIGEgZ29vZCBzdGFydGluZyBw b2ludCBmb3INCj4gPj4+IHRoaXMgaXNzdWUuIHRoYW5rcyBmb3Igd3JpdGluZyBpdC4NCj4gPj4+ DQo+ID4+PiBNeSBtYWluIGNvbW1lbnQgaXMgYWJvdXQgdGhlIEVDTiBuZWdvdGlhdGlvbi4gSSBh bSB1bmNvbnZpbmNlZCB0aGF0DQo+ID4+PiB0aGUgcXVpYyB2ZXJzaW9uIG5lZ290aWF0aW9uIGlz IHRoZSByaWdodCBhcHByb2FjaCBmb3IgdGhpcy4NCj4gPj4+DQo+ID4+PiBJIG1lYW4sIGFmYWl1 LCBxdWljIHZlcnNpb24gbmVnb3RpYXRpb24gaW1wb3NlcyBhbiBleHRyYSBSVFQgd2hlbg0KPiA+ Pj4gdGhlIG5ldyB2ZXJzaW9uIGlzIG5vdCBzdXBwb3J0ZWQuIEkgdGhpbmsgdGhpcyBpcyBvayBm b3IgbWFqb3INCj4gPj4+IHZlcnNpb24gY2hhbmdlcywgYnV0IEkgZG9udCB0aGluayB0aGlzIGlz IGFwcHJvcHJpYXRlIGZvciBmZWF0dXJlDQo+ID4+PiBuZWdvdGlhdGlvbiBzdWNoIGFzIEVDTi4N Cj4gPj4+DQo+ID4+PiBJIG1lYW4sIHVubGVzcyBFQ04gaXMgc3VwcG9ydGVkIGJ5IGRlZmF1bHQg aW4gdGhlIGZpcnN0IHF1aWMNCj4gPj4+IHZlcnNpb24sIEkgdGhpbmsgdXNpbmcgcXVpYyB2ZXJz aW9uIG5lZ290aWF0aW9uIGZvciAgRUNOIHN1cHBvcnQNCj4gPj4+IHdvdWxkIGJlIGFuIG9ic3Rh Y2xlIGluIEVDTiBhZG9wdGlvbiBpbiBxdWljLiBJIG1lYW4sIGlmIHdlIGVuZCB1cA0KPiA+Pj4g aW4gdGhlIHNpdHVhdGlvbiB0aGF0IHRoZSBmaXJzdCAod2lkZWx5IGRlcGxveWVkKSBxdWljIHBy b3RvY29sDQo+ID4+PiBzcGVjaWZpY2F0aW9uIGRvZXMgbm90IHN1cHBvcnQgRUNOIGJ5IGRlZmF1 bHQsIHRoZW4gaGF2aW5nIEVDTg0KPiA+Pj4gbmVnb3RpYXRpb24gdXNpbmcgcXVpYyB2ZXJzaW9u IHdpbGwgaW1wbHkgdGhhdCBpZiBhIGNsaWVudCB3YW50cyB0bw0KPiA+Pj4gdHJpZXMgdG8gc2Vl IGlmIHRoZSBzZXJ2ZXIgc3VwcG9ydHMgRUNOLCBpdCByaXNrcyB0byBoYXZlIGEgZXh0cmENCj4g Pj4+IFJUVCBwZW5hbHR5LiAoaSB1bmRlcnN0YW5kIHRoZSBjbGllbnQgY2FuIGNhY2hlIHdoaWNo IHNlcnZlcnMNCj4gPj4+IHN1cHBvcnQgRUNOLCBidXQgd2UgYXJlIGJhY2sgaW50byB3b3JraW5n IGFyb3VuZCB0aGVzZSBkaWZmaWN1bHRpZXMNCj4gPj4+IHRoYXQgbWFrZSBlY24gYWRvcHRpb24g aGFyZGVyKS4NCj4gPiBbSUpdIFF1aXRlIGNvbnZpbmNpbmcgYXJndW1lbnRzIEkgbXVzdCBzYXku DQo+ID4NCj4gPj4+IFRoZSBvdGhlciBwcm9ibGVtIGlzIHJlbGF0ZWQgdG8gdGhlIGJsb2NraW5n IG9mIEVDTiBiaXRzIGluIHRoZSBJUA0KPiA+Pj4gaGVhZGVyLiBJZGVhbGx5LCBJIGd1ZXNzLCB0 aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIGxlYXJuIGlmIHRoZQ0KPiA+Pj4gRUNOIGJpdHMg YXJlIGJsb2NrZWQgZHVyaW5nIHRoZSBuZWdvdGlhdGlvbiBwaGFzZSBpLmUuIHRoZQ0KPiA+Pj4g bmVnb3RpYXRpb24gY2FuIGZhaWwgZWl0aGVyIGJlY2F1c2UgdGhlIHNlcnZlciBkb2VzbnQgc3Vw cG9ydCBpdCBvcg0KPiA+Pj4gYmVjYXVzZSB0aGUgbmV0d29yayBkb2VzbnQgc3VwcG9ydCBpdC4g QmVjYXVzZSBvZiB0aGlzLCBJIHdvdWxkDQo+ID4+PiBhcmd1ZSB0aGF0IHRoZSBnb29kIGFwcHJv YWNoIGlzIHRvIGhhdmUgdGhlIEVDTiBiaXRzIHNldCBpbiB0aGUgSVANCj4gPj4+IGhlYWRlciBv ZiB0aGUgcGFja2V0IGNhcnJ5aW5nIHRoZSBFQ04gbmVnb3RpYXRpb24uDQo+ID4gW0lKXSBPSw0K PiA+DQo+ID4+PiBTbywgd2l0aCBhbGwgdGhpcywgSSB0aGluayBpdCBtYXkgYmUgYSBiZXR0ZXIg YXBwcm9hY2ggdG8gbWFrZSBFQ04NCj4gPj4+IG5lZ290aWF0aW9uIHRvIGJlIGRvbmUgdXNpbmcg YSBuZXcgZnJhbWUgdHlwZSB0aGF0IGlzIHNlbnQgaW4gdGhlDQo+ID4+PiBzdHJlYW0gMS4gVGhp cyB3b3VsZCBiZSBhIG1lc3NhZ2UgdGhhdCB0aGUgc2VuZGVyIGlzc3VlcywgYWZ0ZXIgdGhlDQo+ ID4+PiBjb25uZWN0aW9uIGhhcyBiZWVuIGVzdGFibGlzaGVkLCB0byByZXF1ZXN0IEVDTiBzdXBw b3J0IGZyb20gdGhlDQo+ID4+PiBvdGhlciBlbmRwb2ludC4gVGhpcyBtZXNzYWdlIHdvdWxkIGJl IHNlbnQgaW4gYW4gRUNOIG1hcmtlZCBwYWNrZXQsDQo+ID4+PiB0byB2ZXJpZnkgdGhhdCB0aGUg bmV0d29yayBkZWxpdmVycyB0aGUgbWVzc2FnZS4gVGhlIG90aGVyIGVuZHBvaW50DQo+ID4+PiBj YW4gcmVwbHkgd2l0aCBhbm90aGVyIG1lc3NhZ2UgYWNjZXB0aW5nIG9mIG5vdCB0aGUgRUNOIHN1 cHBvcnQgZm9yDQo+ID4+PiB0aGUgY29ubmVjdGlvbi4NCj4gPiBbSUpdIFllcywgYW5vdGhlciBt ZXNzYWdlIG9yIHRvIHNpbXBseSBpbmRpY2F0ZSBpdCBpbiB0aGUgQUNLIGZyYW1lLg0KPiA+DQo+ ID4+PiBJIHRoaW5rIHRoaXMgYXBwcm9hY2ggaGFzIHRoZSBiZW5lZml0IG9mIG5vdCBpbXBvc2lu ZyBleHRyYSBsYXRlbmN5DQo+ID4+PiBmb3IgdGhvc2Ugd2hvIHdhbnQgdG8gY2hlY2sgaWYgRUNO IGlzIHN1cHBvcnRlZCBhbmQgYXQgdGhlIHNhbWUgdGltZQ0KPiA+Pj4gdmVyaWZpZXMgdGhhdCB0 aGUgbmV0d29yayBpcyBhYmxlIHRvIGRlbGl2ZXIgRUNOIG1hcmtlZCBwYWNrZXRzLiBJZg0KPiA+ Pj4gYW55IG9mIHRoZXNlIGNvbmRpdGlvbnMgZmFpbCwgdGhlIG5lZ290aWF0aW9uIGZhaWwuIE1v cmVvdmVyLCBpDQo+ID4+PiB0aGluayB0aGVzZSBtZXNzYWdlcyBjYW4gYmUgdXNlZCB0byBkaXNh YmxlIEVDTiBpbiB0aGUgbWlkZGxlIG9mIHRoZQ0KPiA+Pj4gY29ubmVjdGlvbi4gT25lIGNhc2Ug d2hlcmUgdGhpcyBjYW4gYmUgdXNlZnVsIGlzIGluIGEgbW9iaWxpdHkNCj4gPj4+IHNjZW5hcmlv LCB3aGVyZSBvbmUgb2YgdGhlIGVuZHBvaW50cyBtb3ZlIGFuZCBpbiBvcmRlciB0byBjaGVjayBp Zg0KPiA+Pj4gdGhlIG5ldyBwYXRoIHN0aWxsIHN1cHBvcnRzIEVDTiwgdGhleSBjYW4gcmVzZW5k IHRoZSBvcHRpb24gYW5kIHNlZQ0KPiA+Pj4gaWYgdGhlIHBhY2tldHMgc3RpbGwgbWFrZSBpdC4g SSBndWVzcyBtb3JlIGNvbXBsaWNhdGVkIHZlcmlmaWNhdGlvbg0KPiA+Pj4gbWV0aG9kcyBjb3Vs ZCBiZSBidWlsdCBpbnRvIHRoaXMuDQo+ID4+Pg0KPiA+Pj4gdGhvdWdodHM/DQo+ID4gW0lKXSBT b3VuZHMgcXVpdGUgcmVhc29uYWJsZSwgSSBhIGJpdCB1bmNlcnRhaW4gaWYgaXQgc2hvdWxkIGJl IGFuIEVDTiBmcmFtZQ0KPiB0aGF0IGlzIGFja25vd2xlZGdlZCBieSBhbiBFQ04gZnJhbWUgb3Ig aWYgdGhlIEFDSyBmcmFtZSB3aXRoIGFuIEVDTiBmaWVsZCBpcw0KPiBzdWZmaWNpZW50Lg0KPiA+ DQo+ID4+PiByZWdhcmRzLCBtYXJjZWxvDQo+ID4+Pg0KDQo= From nobody Wed Feb 1 08:17:02 2017 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 5D012129494 for ; Wed, 1 Feb 2017 08:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LM5JzCowHrQN for ; Wed, 1 Feb 2017 08:16:58 -0800 (PST) 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 AEB5912944B for ; Wed, 1 Feb 2017 08:16:57 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id r141so45383058wmg.1 for ; Wed, 01 Feb 2017 08:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=jXcqsh/vDam9nY7sRerB7jvs0IH9yeHxbPu96KDAk/s=; b=TDnkYfKgygDAnDAkyEGjwPgJrHILtB5e/st/uihXeMDJ5U9aCov36wSgDX1orNh21S NbYrOMT/snokFlLWp/td8P2fJrnEGJNDk9EMNRhFDuC4wBuuIQf1Ns+CLMHINqSWgpH/ /pFZeOC0+PdIE/ByjbIJDrwwFkmoqda9h26E58jKbpwJA9D7v1vWT1wUBqHvjMt0oTcB ohPgNoEEYLwPnGPPymUgRps5FzdA/UcSo0GqWRdA3WV96VSCRAp0hA5V/6D0QxVkZBq9 lEVF2Y6U9RRgc67cndRyqCEe8OB8e5dCPF7c80gXjYhvExLQdqNJfdtp3hLlvw7XlKcW Onvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=jXcqsh/vDam9nY7sRerB7jvs0IH9yeHxbPu96KDAk/s=; b=AO2I2LGjoLKA0CBByb8o7wAdt9iJITemqiRcw+U9i7U16cf2+YbuYaM8y4UUoAYZCr cyxAUkAMRJ6+NTlrrpVSLjaN+bD0G6dsVWrGsiu9M6WGBXQHXpK2ajZft9uWuDCGp9G/ U/quj/h7eMuhovZlng0X/2se9tEMptt3IMYXqTOkc8RcDxR3toRy1Iek295xh5wiu4Ll ccWA9bX33Kxw/XvM6iter5jOGSCf2s+PRBesX5gmKbnqfWBaVeYMal5EuQIg5AKtbS2V RmyV4gs2D0bcn1I44vK+sS3YfttZeErywOtEnzh0Z11YNfjFKc+kyWFZKKdJ9UwPpRpx /wbw== X-Gm-Message-State: AIkVDXIGJNgLMpQXbPc0pDhF0u7DmBW4V/45YBdy93jc0w5g7qSsyTogiEguCZZpt73kCPkF X-Received: by 10.28.50.135 with SMTP id y129mr3495586wmy.2.1485965815852; Wed, 01 Feb 2017 08:16:55 -0800 (PST) Received: from Macintosh-6.local (33.18.219.87.dynamic.jazztel.es. [87.219.18.33]) by smtp.gmail.com with ESMTPSA id i29sm9549581wrc.25.2017.02.01.08.16.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Feb 2017 08:16:55 -0800 (PST) Subject: Re: about draft-johansson-quic-ecn-00 To: Ingemar Johansson S , "gorry@erg.abdn.ac.uk" References: <79bfa1c0-ff80-8a98-0e50-bc03d5a96b30@it.uc3m.es> <5890DDCF.6010507@erg.abdn.ac.uk> From: marcelo bagnulo braun Message-ID: <1b31166f-fecc-3813-7980-e7f2422b3ea6@it.uc3m.es> Date: Wed, 1 Feb 2017 17:16:53 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 16:17:00 -0000 El 01/02/17 a las 15:07, Ingemar Johansson S escribió: > [IJ] Yes, I assume that you mean a possible ECN flag in the ACK frame ?. Alternatively an ECN frame can be used in the reverse direction . I would keep the ECN separated, so, i mean to also use the ECN frame in the reverse direction >> >>> More comments inline below >>> >>> /Ingemar >>> >>>> -----Original Message----- >>>> From: Gorry Fairhurst [mailto:gorry@erg.abdn.ac.uk] >>>> Sent: den 31 januari 2017 19:56 >>>> To: marcelo bagnulo braun >>>> Cc: quic@ietf.org; Ingemar Johansson S >>>> >>>> Subject: Re: about draft-johansson-quic-ecn-00 >>>> >>>> I'd also like to thank you for this consideration of where ECN fits within >> QUIC. >>>> I have a few comments, see below: >>>> >>>> I really do see merit in requiring implementation of the receiver >> functionality. >>>> This to me is independent of a decision whether to use the ECN >>>> functionality at the sender. I’d support it being mandatory to >>>> implement *at least* basic ECN receiver support (which I think is similar to >> what marcelo said). >>>> draft-ietf-tsvwg-rfc5405bis (now in RFC-ED queue), provides a >>>> checklist for UDP support for ECN, the current list in the draft >>>> seems similar, but is not quite the same. I think since rfc5405bis is >>>> scheduled for BCP, it would be good to cite this and align where possible. >>> [IJ] Totally missed this, sorry for the ignorance, should definitely be >> referenced. >>>> The decision whether a sender chooses to mark using ECT(0) or ECT(1) >>>> or neither needs to be based on understanding of whether the combined >>>> send and receive stacks and network devices currently provide support >>>> (or more likely measurement), monitoring as described in 2.6 (i.e., >>>> this is a per-path run-time decision). One thing a QUIC receiver may >>>> already know is whether a receive stack has support for ECN. >>> [IJ] Yes, it should be possible for a stack to send packets over the local >> interface (127.0.0.1) and check the status of the ECN bits. >>> >>>> I suggest this places requirements on the feedback method: >>>> >>>> A sender may need to understand how the network forwards ECT(x) >> marks >>>> on the forward path - (Alt 3 shows some functionality for this). >>>> this can confirm whether ECT(x) marks are received. I expect this >>>> will be needed to know that ECT and ECN-CE marks are actually being >>>> sent across the entire path, and are not cleared at some midpoint, >>>> erasing the congestion information. I think it is also would be >>>> useful to know that >>>> ECT(1) is actually traversing a path when using new ECT(1) semantics >>>> as described in the tsvwg draft (aka like L4S). >>>> >>>> I can see real advantages if alt-1, alt-2 at least provides a count >>>> to indicate the number of packets (bytes?) received with not-ECT; ECT(0); >> and ECT(1). >>> [IJ] I would say that you will get the same information with all the three >> methods, in the case of alt 1 and 2 the burden to compute the number of >> not-ECT, ECT(0) and ECT(1) is on the sender side, while with alt 3 the burden >> is on the receiver side (but the cost is admittedly quite low). >>>> Knowing receive code point information would also provide >>>> opportunities to detect and react appropriately to misbehaving >>>> receivers/paths (including sender control to set the mark value) - >>>> although at least while the path/receiver is being verified the >>>> sender will likely also be needed to know >>>> *which* packets carried a specific mark. (as noted alt-3 may not >>>> provide this). How we should do this, I am not sure - various ways >>>> exist - but designing a transport that can allow this should be possible. >>> [IJ] Yes, alt 3, does not allow to determine which packets have which ECN >> mark, it is unclear though to me how important this is. >>>> Gorry >>>> >>>> >>>> >>>> On 26/01/2017 10:40, marcelo bagnulo braun wrote: >>>>> Hi, >>>>> >>>>> I have read the draft and i think it is a good starting point for >>>>> this issue. thanks for writing it. >>>>> >>>>> My main comment is about the ECN negotiation. I am unconvinced that >>>>> the quic version negotiation is the right approach for this. >>>>> >>>>> I mean, afaiu, quic version negotiation imposes an extra RTT when >>>>> the new version is not supported. I think this is ok for major >>>>> version changes, but I dont think this is appropriate for feature >>>>> negotiation such as ECN. >>>>> >>>>> I mean, unless ECN is supported by default in the first quic >>>>> version, I think using quic version negotiation for ECN support >>>>> would be an obstacle in ECN adoption in quic. I mean, if we end up >>>>> in the situation that the first (widely deployed) quic protocol >>>>> specification does not support ECN by default, then having ECN >>>>> negotiation using quic version will imply that if a client wants to >>>>> tries to see if the server supports ECN, it risks to have a extra >>>>> RTT penalty. (i understand the client can cache which servers >>>>> support ECN, but we are back into working around these difficulties >>>>> that make ecn adoption harder). >>> [IJ] Quite convincing arguments I must say. >>> >>>>> The other problem is related to the blocking of ECN bits in the IP >>>>> header. Ideally, I guess, the client should be able to learn if the >>>>> ECN bits are blocked during the negotiation phase i.e. the >>>>> negotiation can fail either because the server doesnt support it or >>>>> because the network doesnt support it. Because of this, I would >>>>> argue that the good approach is to have the ECN bits set in the IP >>>>> header of the packet carrying the ECN negotiation. >>> [IJ] OK >>> >>>>> So, with all this, I think it may be a better approach to make ECN >>>>> negotiation to be done using a new frame type that is sent in the >>>>> stream 1. This would be a message that the sender issues, after the >>>>> connection has been established, to request ECN support from the >>>>> other endpoint. This message would be sent in an ECN marked packet, >>>>> to verify that the network delivers the message. The other endpoint >>>>> can reply with another message accepting of not the ECN support for >>>>> the connection. >>> [IJ] Yes, another message or to simply indicate it in the ACK frame. >>> >>>>> I think this approach has the benefit of not imposing extra latency >>>>> for those who want to check if ECN is supported and at the same time >>>>> verifies that the network is able to deliver ECN marked packets. If >>>>> any of these conditions fail, the negotiation fail. Moreover, i >>>>> think these messages can be used to disable ECN in the middle of the >>>>> connection. One case where this can be useful is in a mobility >>>>> scenario, where one of the endpoints move and in order to check if >>>>> the new path still supports ECN, they can resend the option and see >>>>> if the packets still make it. I guess more complicated verification >>>>> methods could be built into this. >>>>> >>>>> thoughts? >>> [IJ] Sounds quite reasonable, I a bit uncertain if it should be an ECN frame >> that is acknowledged by an ECN frame or if the ACK frame with an ECN field is >> sufficient. >>>>> regards, marcelo >>>>> From nobody Wed Feb 1 14:40:52 2017 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 314641295CB for ; Wed, 1 Feb 2017 14:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lm1LSrPgVx_v for ; Wed, 1 Feb 2017 14:40:49 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 12C7212953B for ; Wed, 1 Feb 2017 14:40:49 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id w20so216480363qtb.1 for ; Wed, 01 Feb 2017 14:40:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qVhAQ9WWT1g9VYYqUsXKEzG2EESsWDkPfELBuDfUhTA=; b=aIZt5PJ3GFEZKY25OgzEG6TZRm3fAlKRvB0g+NOtIM5dd8XDQ1i5zixTtCNcDynEco AiXtidqJMr12bk7cOzwip1c0JgB9KW1AjPm9TiZruTqj/GSg5q5BeRiylWWNuBi0aRdR DENlst/3OyH7XNs0AazFu+MPN52EfzMsGDDUo5HnuyjY2mIOQgSzpqA6wXZcU/rODU6g 3hT2rY2KfyrbNUYwQ7K8BArZZVeMdAzZX8p2ZYysp2FOUXgUOFijIEUpVtADXlV+OIbj L38fsvpJNdqwQ2zb/nNt7IXERIyMSMQURzhWFu2L3cRwXMBakfM2ZQKpqcYIj/BPVSOu 9FGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qVhAQ9WWT1g9VYYqUsXKEzG2EESsWDkPfELBuDfUhTA=; b=NgT+uhbLvsNSOPU+zmgS4EvjW3gdngMJ+hbCRCBX4uSSOIzX1O/ra1ZNRXEaf7YOGQ Xr3KhWXkE7UMRoCM9QGtViBo0tvPZDPPsz8TvnAcIbfZFlxZMA3eHTe+PK468A+n4mnG kyjzmQ0Mzf1ITw7+1yn6UxblZkNVOA3lDLOCdFL6+6seKJrQlXfofSpXZtHzJThmSKlM RuxswvRKvYZel7sC+T7el1Kbw0YGaGssWJrg7AcixFA82sGvGfDm0q9LOfwR6QVg7OGU Y0KCikL3EEvwkPJBnyUztC1fQNXc4jwz9KQrVZMGaxO0oJgscb8gtg05Zz57n3Xbpogw OtdQ== X-Gm-Message-State: AIkVDXK0Nxjeo54nr6QJ3MkhqHCgpxrmc1LF7LM6Z1/ns5o6CqcSYyXwNVJgydUMnHcHEKAmtrYWugkixxt5bA== X-Received: by 10.200.57.199 with SMTP id v65mr5085806qte.13.1485988847776; Wed, 01 Feb 2017 14:40:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Feb 2017 14:40:47 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 2 Feb 2017 09:40:47 +1100 Message-ID: Subject: Re: Performance/safety trade-off To: Dragana Damjanovic Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Watson Ladd , IETF QUIC WG , Jana Iyengar X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 22:40:51 -0000 Yeah, given that a packet containing 0-RTT is essentially line noise when it is received (it will contain what appears to be pure randomness), acknowledging it would be unwise. We generally save acknowledgments for stuff that makes sense. It means that 0-RTT can't be used to improve ClientHello reliability, but at least we're not worse off in this case. On 1 February 2017 at 22:33, Dragana Damjanovic wrote: > This is the similar problem as with a lost ClientHello and 0RTT packets. > > What if we send a clear text ack for 0RTT packet if the clientHello is lost > (to actually inform the client that the ClienHello has been lost) and a > cleartext ack of 1RTT packet when a client finish message is lost. This ack > can be use only for retransmissions but not for marking packets as acked? > These ack are clear text but they should not be(acks for 0RTT and 1RTT > packes should be encrypted), so we can distinguish them from proper acks. > 0RTT can be just a noise, they cannot be verified, so maybe not acking them. > > dragana > > > On Wed, Feb 1, 2017 at 12:36 AM, Watson Ladd wrote: >> >> >> >> On Jan 31, 2017 3:23 PM, "Martin Thomson" >> wrote: >> >> The security analyses of TLS assume receipt and verification of the >> Finished message. It's an obvious intuition that keys depend on the >> content of the message, therefore tampering would be easily detected. >> >> >> I think someone who is more experienced/familiar with the analysis should >> chime in. My understanding is that the ROM quickly gives high probability of >> the keys being different and hence the MAC failing, and the Finished message >> is there to give an explicit confirmation property. >> >> >> That said, we've learned that intuition is often wrong in this space, >> sometimes disastrously. We don't have an analysis of TLS that ignores >> the client Finished message. So unless and until we do, I don't want >> to write down anything that isn't known to be safe. >> >> I know that this sucks in subtle ways, particularly in the way that >> Ian observed with respect to acknowledgments. Because we require that >> the Finished is acknowledged with protected keys, we lose the ability >> to generate acknowledgments for them. >> >> I see three possible approaches: >> >> 1. As I originally suggested, suck it up and don't let the server send. >> >> 2. Don't protect the Finished (it's protected with TLS handshake keys >> anyway). That would allow for acknowledgment in the clear. That >> requires a tweak to the way that keys are shared, but it's a fairly >> simple tweak. The major downside is that we now have an extra packet >> to send, because you can't collapse the Finished message with other >> things (like requests). >> >> 3. In the hackiest possible way, generate a redundant ACK for the >> ClientHello in the clear. If that could trigger retransmission of the >> first encrypted packet(s), then we'd be OK. (Sorry, I haven't >> internalized the loss recovery stuff, so I'm not sure if this even >> works, we could be back into RTO space here.) >> >> Maybe option 2 is more appealing than appalling. >> >> >> On 1 February 2017 at 04:17, Jana Iyengar wrote: >> > Since the keys cannot be the same if the ClientHello were to be >> > modified, >> > what is the risk we are talking about here? I don't know about the >> > crypto >> > analyses of the TLS handshake, so some insight here would be helpful. >> > But I >> > agree that having the server process 1-RTT data would help with loss >> > detection. If there's no real security implication, I'd be in favor of >> > letting the server process this data. >> > >> > On Tue, Jan 31, 2017 at 8:27 AM, Watson Ladd >> > wrote: >> >> >> >> On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson >> >> wrote: >> >> > In PR #39, there is a choice: >> >> > >> >> > https://github.com/quicwg/base-drafts/pull/39 >> >> > >> >> > If a server receives 1-RTT-protected packets before it receives the >> >> > client Finished message, it could use them. It has the keys. >> >> > >> >> > Obviously, if the server depends on certificate-based client >> >> > authentication it will wait. But that's still a relatively rare >> >> > occurrence. >> >> > >> >> > However, using 1-RTT data before verifying the Finished message could >> >> > leave the server more vulnerable to an attack where the ClientHello >> >> > is >> >> > modified by an attacker. This is something that TLS 1.3 protects >> >> > against, but only indirectly. The traffic keys are dependent on the >> >> > content of the ClientHello and so it is likely that modifications of >> >> > the ClientHello would result in being unable to communicate. But >> >> > this >> >> > isn't a strong assertion. The various forms of analysis of the TLS >> >> > 1.3 handshake have all (I think) assumed that verification of the >> >> > Finished message is what provides integrity for the handshake. >> >> >> >> I don't believe the finished message is necessary for ensuring >> >> manipulation of the client hello message is detected. >> >> > >> >> > In #39, I opted to forbid use of the client 1-RTT data until the >> >> > handshake completes. I'd like to confirm that this is acceptable. >> >> > >> >> > In addition to confirming this, I'd like input on what level of >> >> > justification is necessary for this in the document. If we believe >> >> > that this is the right decision, do we need to do anything to prevent >> >> > someone from pulling out a false start hack because they disagree >> >> > with >> >> > this analysis? >> >> > >> >> >> >> >> >> >> >> -- >> >> "Man is born free, but everywhere he is in chains". >> >> --Rousseau. >> >> >> > >> >> > From nobody Wed Feb 1 15:51:54 2017 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 C1B9F1295F2 for ; Wed, 1 Feb 2017 15:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.898 X-Spam-Level: X-Spam-Status: No, score=-5.898 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=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 nly8blSFN-OP for ; Wed, 1 Feb 2017 15:51:51 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 E022B12952F for ; Wed, 1 Feb 2017 15:51:50 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id u68so30828ywg.0 for ; Wed, 01 Feb 2017 15:51:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/Ar/1qqrDou/pZOmas+R7rqcQxdNOm2PwsQMXpP/Pq8=; b=CjW2CzixwhCrf0TCdUdg4qv7npJEC5QD2WLEHV8g9p4ObQKpXkx2pGokunSaNue1u7 l6cy0Y1Alb1ueK+qj+bUyIQtr8uQZx9siyEHlPKg9E0mwq8C2g7n9bT2ljnq/baeFAjV zqAf2iYtfcGAvAgNzBvzmlhwi3XXmE3fiW3I4yhqp8KOnNrugPyQ/38Oo6CEDLAc6lXi eLS5jBcuzm1vonLLFvBLgzWkFGMuKnd90J9sb4RCz6xjJDtGTvnYdoJdijFTFmJ0anqX ZQCBB+j8n1zZr5pgAfxbAuXRPaHg7eEm3wgo87VwfVxHkK1bD+87OhDI/m+fBD1SRiQ7 lkiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/Ar/1qqrDou/pZOmas+R7rqcQxdNOm2PwsQMXpP/Pq8=; b=WEWY6wggbMxw+L7Z5xMEhzkUva2HQA7bTKFs70sxgj52qCfmjbC1TXoJRr2pzDJKEf 2oiORN1kAt5GAQfJBX7LCBuqUuBU7ZvZIAPsIc2eX+9YVdewuKEKsDQKC5d4csz0kruV Or8wkA2qzyAQKDu+DCb4n8EC3tg7ezIk7Ce27h/BzSbH/N6ITWyfolWtbNpyiRtYcDZe 79UsvvI18oQq1qlfX40eTl7xunkTQse1+k1xEqgzgQMgveNWTJgSzZA//IJVOF4/4bvW 5nq2P9DYi1SAMGSlZxmoJOY82wUXnMry738E28EgiX53gpcfTqg/wrNg+/uf9zCSbcKj iHtQ== X-Gm-Message-State: AIkVDXLZvZvmlBEhRFeTocl5W5hO9jNqePxmBrLJp9fsJ1iUqQwDvBbBWo0U9UMseS+JHGU0u+nXMpBmVR7oyk6q X-Received: by 10.129.125.84 with SMTP id y81mr3553019ywc.120.1485993109992; Wed, 01 Feb 2017 15:51:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Wed, 1 Feb 2017 15:51:29 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Wed, 1 Feb 2017 18:51:29 -0500 Message-ID: Subject: Re: Performance/safety trade-off To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114928ba75f6be054780bbd7 Archived-At: Cc: Watson Ladd , IETF QUIC WG , Dragana Damjanovic , Jana Iyengar X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 23:51:53 -0000 --001a114928ba75f6be054780bbd7 Content-Type: text/plain; charset=UTF-8 I agree that acking packets we haven't decrypted feels very wrong. If there are critical security reasons why the 1RTT data can't be used before the finished message, we should determine how much real world impact this has on handshake and application latency. BTW, what's in the finished message? Possibly it could not even exist for QUIC and be implicit now that QUIC has a key phase bit? On Wed, Feb 1, 2017 at 5:40 PM, Martin Thomson wrote: > Yeah, given that a packet containing 0-RTT is essentially line noise > when it is received (it will contain what appears to be pure > randomness), acknowledging it would be unwise. We generally save > acknowledgments for stuff that makes sense. It means that 0-RTT can't > be used to improve ClientHello reliability, but at least we're not > worse off in this case. > > On 1 February 2017 at 22:33, Dragana Damjanovic > wrote: > > This is the similar problem as with a lost ClientHello and 0RTT packets. > > > > What if we send a clear text ack for 0RTT packet if the clientHello is > lost > > (to actually inform the client that the ClienHello has been lost) and a > > cleartext ack of 1RTT packet when a client finish message is lost. This > ack > > can be use only for retransmissions but not for marking packets as acked? > > These ack are clear text but they should not be(acks for 0RTT and 1RTT > > packes should be encrypted), so we can distinguish them from proper acks. > > 0RTT can be just a noise, they cannot be verified, so maybe not acking > them. > > > > dragana > > > > > > On Wed, Feb 1, 2017 at 12:36 AM, Watson Ladd > wrote: > >> > >> > >> > >> On Jan 31, 2017 3:23 PM, "Martin Thomson" > >> wrote: > >> > >> The security analyses of TLS assume receipt and verification of the > >> Finished message. It's an obvious intuition that keys depend on the > >> content of the message, therefore tampering would be easily detected. > >> > >> > >> I think someone who is more experienced/familiar with the analysis > should > >> chime in. My understanding is that the ROM quickly gives high > probability of > >> the keys being different and hence the MAC failing, and the Finished > message > >> is there to give an explicit confirmation property. > >> > >> > >> That said, we've learned that intuition is often wrong in this space, > >> sometimes disastrously. We don't have an analysis of TLS that ignores > >> the client Finished message. So unless and until we do, I don't want > >> to write down anything that isn't known to be safe. > >> > >> I know that this sucks in subtle ways, particularly in the way that > >> Ian observed with respect to acknowledgments. Because we require that > >> the Finished is acknowledged with protected keys, we lose the ability > >> to generate acknowledgments for them. > >> > >> I see three possible approaches: > >> > >> 1. As I originally suggested, suck it up and don't let the server send. > >> > >> 2. Don't protect the Finished (it's protected with TLS handshake keys > >> anyway). That would allow for acknowledgment in the clear. That > >> requires a tweak to the way that keys are shared, but it's a fairly > >> simple tweak. The major downside is that we now have an extra packet > >> to send, because you can't collapse the Finished message with other > >> things (like requests). > >> > >> 3. In the hackiest possible way, generate a redundant ACK for the > >> ClientHello in the clear. If that could trigger retransmission of the > >> first encrypted packet(s), then we'd be OK. (Sorry, I haven't > >> internalized the loss recovery stuff, so I'm not sure if this even > >> works, we could be back into RTO space here.) > >> > >> Maybe option 2 is more appealing than appalling. > >> > >> > >> On 1 February 2017 at 04:17, Jana Iyengar wrote: > >> > Since the keys cannot be the same if the ClientHello were to be > >> > modified, > >> > what is the risk we are talking about here? I don't know about the > >> > crypto > >> > analyses of the TLS handshake, so some insight here would be helpful. > >> > But I > >> > agree that having the server process 1-RTT data would help with loss > >> > detection. If there's no real security implication, I'd be in favor of > >> > letting the server process this data. > >> > > >> > On Tue, Jan 31, 2017 at 8:27 AM, Watson Ladd > >> > wrote: > >> >> > >> >> On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson > >> >> wrote: > >> >> > In PR #39, there is a choice: > >> >> > > >> >> > https://github.com/quicwg/base-drafts/pull/39 > >> >> > > >> >> > If a server receives 1-RTT-protected packets before it receives the > >> >> > client Finished message, it could use them. It has the keys. > >> >> > > >> >> > Obviously, if the server depends on certificate-based client > >> >> > authentication it will wait. But that's still a relatively rare > >> >> > occurrence. > >> >> > > >> >> > However, using 1-RTT data before verifying the Finished message > could > >> >> > leave the server more vulnerable to an attack where the ClientHello > >> >> > is > >> >> > modified by an attacker. This is something that TLS 1.3 protects > >> >> > against, but only indirectly. The traffic keys are dependent on > the > >> >> > content of the ClientHello and so it is likely that modifications > of > >> >> > the ClientHello would result in being unable to communicate. But > >> >> > this > >> >> > isn't a strong assertion. The various forms of analysis of the TLS > >> >> > 1.3 handshake have all (I think) assumed that verification of the > >> >> > Finished message is what provides integrity for the handshake. > >> >> > >> >> I don't believe the finished message is necessary for ensuring > >> >> manipulation of the client hello message is detected. > >> >> > > >> >> > In #39, I opted to forbid use of the client 1-RTT data until the > >> >> > handshake completes. I'd like to confirm that this is acceptable. > >> >> > > >> >> > In addition to confirming this, I'd like input on what level of > >> >> > justification is necessary for this in the document. If we believe > >> >> > that this is the right decision, do we need to do anything to > prevent > >> >> > someone from pulling out a false start hack because they disagree > >> >> > with > >> >> > this analysis? > >> >> > > >> >> > >> >> > >> >> > >> >> -- > >> >> "Man is born free, but everywhere he is in chains". > >> >> --Rousseau. > >> >> > >> > > >> > >> > > > > --001a114928ba75f6be054780bbd7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree that acking packets we haven't decrypted feels= very wrong.=C2=A0 If there are critical security reasons why the 1RTT data= can't be used before the finished message, we should determine how muc= h real world impact this has on handshake and application latency. =C2=A0
BTW, what's in the finished message?=C2=A0 Possibly i= t could not even exist for QUIC and be implicit now that QUIC has a key pha= se bit?

On Wed, Feb 1, 2017 at 5:40 PM, Martin Thomson <martin.thomson@gm= ail.com> wrote:
Yeah, given= that a packet containing 0-RTT is essentially line noise
when it is received (it will contain what appears to be pure
randomness), acknowledging it would be unwise.=C2=A0 We generally save
acknowledgments for stuff that makes sense.=C2=A0 It means that 0-RTT can&#= 39;t
be used to improve ClientHello reliability, but at least we're not
worse off in this case.

On 1 February 2017 at 22:33, Dragana Damjanovic
<dragana.damjano@gmail.com> wrote:
> This is the similar problem as with a lost ClientHello and 0RTT packet= s.
>
> What if we send a clear text ack for 0RTT packet if the clientHello is= lost
> (to actually inform the client that the ClienHello has been lost) and = a
> cleartext ack of 1RTT packet when a client finish message is lost. Thi= s ack
> can be use only for retransmissions but not for marking packets as ack= ed?
> These ack are clear text but they should not be(acks for 0RTT and 1RTT=
> packes should be encrypted), so we can distinguish them from proper ac= ks.
> 0RTT can be just a noise, they cannot be verified, so maybe not acking= them.
>
> dragana
>
>
> On Wed, Feb 1, 2017 at 12:36 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
>>
>>
>>
>> On Jan 31, 2017 3:23 PM, "Martin Thomson" <martin.thomson@gmail.com>
>> wrote:
>>
>> The security analyses of TLS assume receipt and verification of th= e
>> Finished message.=C2=A0 It's an obvious intuition that keys de= pend on the
>> content of the message, therefore tampering would be easily detect= ed.
>>
>>
>> I think someone who is more experienced/familiar with the analysis= should
>> chime in. My understanding is that the ROM quickly gives high prob= ability of
>> the keys being different and hence the MAC failing, and the Finish= ed message
>> is there to give an explicit confirmation property.
>>
>>
>> That said, we've learned that intuition is often wrong in this= space,
>> sometimes disastrously.=C2=A0 We don't have an analysis of TLS= that ignores
>> the client Finished message.=C2=A0 So unless and until we do, I do= n't want
>> to write down anything that isn't known to be safe.
>>
>> I know that this sucks in subtle ways, particularly in the way tha= t
>> Ian observed with respect to acknowledgments.=C2=A0 Because we req= uire that
>> the Finished is acknowledged with protected keys, we lose the abil= ity
>> to generate acknowledgments for them.
>>
>> I see three possible approaches:
>>
>> 1. As I originally suggested, suck it up and don't let the ser= ver send.
>>
>> 2. Don't protect the Finished (it's protected with TLS han= dshake keys
>> anyway).=C2=A0 That would allow for acknowledgment in the clear.= =C2=A0 That
>> requires a tweak to the way that keys are shared, but it's a f= airly
>> simple tweak.=C2=A0 The major downside is that we now have an extr= a packet
>> to send, because you can't collapse the Finished message with = other
>> things (like requests).
>>
>> 3. In the hackiest possible way, generate a redundant ACK for the<= br> >> ClientHello in the clear.=C2=A0 If that could trigger retransmissi= on of the
>> first encrypted packet(s), then we'd be OK.=C2=A0 (Sorry, I ha= ven't
>> internalized the loss recovery stuff, so I'm not sure if this = even
>> works, we could be back into RTO space here.)
>>
>> Maybe option 2 is more appealing than appalling.
>>
>>
>> On 1 February 2017 at 04:17, Jana Iyengar <jri@google.com> wrote:
>> > Since the keys cannot be the same if the ClientHello were to = be
>> > modified,
>> > what is the risk we are talking about here? I don't know = about the
>> > crypto
>> > analyses of the TLS handshake, so some insight here would be = helpful.
>> > But I
>> > agree that having the server process 1-RTT data would help wi= th loss
>> > detection. If there's no real security implication, I'= ;d be in favor of
>> > letting the server process this data.
>> >
>> > On Tue, Jan 31, 2017 at 8:27 AM, Watson Ladd <watsonbladd@gmail.com>
>> > wrote:
>> >>
>> >> On Mon, Jan 30, 2017 at 10:29 PM, Martin Thomson
>> >> <martin.th= omson@gmail.com> wrote:
>> >> > In PR #39, there is a choice:
>> >> >
>> >> > https://github.com/quicwg/b= ase-drafts/pull/39
>> >> >
>> >> > If a server receives 1-RTT-protected packets before = it receives the
>> >> > client Finished message, it could use them.=C2=A0 It= has the keys.
>> >> >
>> >> > Obviously, if the server depends on certificate-base= d client
>> >> > authentication it will wait.=C2=A0 But that's st= ill a relatively rare
>> >> > occurrence.
>> >> >
>> >> > However, using 1-RTT data before verifying the Finis= hed message could
>> >> > leave the server more vulnerable to an attack where = the ClientHello
>> >> > is
>> >> > modified by an attacker.=C2=A0 This is something tha= t TLS 1.3 protects
>> >> > against, but only indirectly.=C2=A0 The traffic keys= are dependent on the
>> >> > content of the ClientHello and so it is likely that = modifications of
>> >> > the ClientHello would result in being unable to comm= unicate.=C2=A0 But
>> >> > this
>> >> > isn't a strong assertion.=C2=A0 The various form= s of analysis of the TLS
>> >> > 1.3 handshake have all (I think) assumed that verifi= cation of the
>> >> > Finished message is what provides integrity for the = handshake.
>> >>
>> >> I don't believe the finished message is necessary for= ensuring
>> >> manipulation of the client hello message is detected.
>> >> >
>> >> > In #39, I opted to forbid use of the client 1-RTT da= ta until the
>> >> > handshake completes.=C2=A0 I'd like to confirm t= hat this is acceptable.
>> >> >
>> >> > In addition to confirming this, I'd like input o= n what level of
>> >> > justification is necessary for this in the document.= =C2=A0 If we believe
>> >> > that this is the right decision, do we need to do an= ything to prevent
>> >> > someone from pulling out a false start hack because = they disagree
>> >> > with
>> >> > this analysis?
>> >> >
>> >>
>> >>
>> >>
>> >> --
>> >> "Man is born free, but everywhere he is in chains&qu= ot;.
>> >> --Rousseau.
>> >>
>> >
>>
>>
>


--001a114928ba75f6be054780bbd7-- From nobody Wed Feb 1 15:59:18 2017 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 571C21295F8 for ; Wed, 1 Feb 2017 15:59:17 -0800 (PST) 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 2KNvproxLkl5 for ; Wed, 1 Feb 2017 15:59:16 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B6C0129577 for ; Wed, 1 Feb 2017 15:59:16 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id x49so223406qtc.2 for ; Wed, 01 Feb 2017 15:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rrxZhzxG4yRPn+z+ItMYZZUENcfgvYuSP5dj3coRDUk=; b=rDybJRiZFVOuR2yDpALTrK1N62OANMAB5IHdndLhGifDNV0V6eEkvWc1J6R9MLKRv9 E7a6Nb3FG4GeFBAXnwe1W9qVhQcEjKnvFrZi+ACWujldbWy44xbo0oPOOk5GOHTszCsX /V8gWXl7c2ENZ5lJnHhXhqzgbDV2MXimdxMnURPjicj3glG1/TVLETzGAVAWCnMYNjKC 4qojxpcuy3AvpOLvVywwRHFiZbwrOuqkEjrX+YdwM7EkzYlngjbXfVM9buVD3s4bH9Mb SYtDVsVOE6Xs/WKgoic1eXWQ1skzCfcNHCvCkEtci+JAmEbGwxxKpd+opOucVtKo2KG1 lsuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rrxZhzxG4yRPn+z+ItMYZZUENcfgvYuSP5dj3coRDUk=; b=Wi7I5rI9l+DGJYrI+HccvetTu/DDSI/20/P3zMae04bOW6YPmGZL6g7kT31uksnMVv JCcYZptKBGuw0WK+xGSpK4rNO2CTOL510QzkxvIEC78d/6os7Tjtaty+A9XmFL0Y1Wf5 N6ouyZEXsvN24/KWukzG+djpOT8hidmtEcA9v0fRzZ5quvfxge4Gwy7zMbWUSjlYbEl8 8dC9lvCuin+cac9OV9S1/ye07tAeIh1D3zJu2jWZ8gEZ5k51syAt34YCNIzH/8ewqDn0 JCrGZxhzuO8s6cxE4nrJRozPCKmuoBhXvpsKJRoQv62fgsk7enBYAzIDkKSlyb8RME0g xZyQ== X-Gm-Message-State: AIkVDXJ8/DOsd4CNznXrkl3jCDQ3QJ9PhaPT9O/yVDMeXqaF9WIupeQcrq8ceLuu/e/iT8GozOPz6zjDFXAy3w== X-Received: by 10.200.39.200 with SMTP id x8mr5303895qtx.159.1485993555284; Wed, 01 Feb 2017 15:59:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Feb 2017 15:59:14 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 2 Feb 2017 10:59:14 +1100 Message-ID: Subject: Re: Performance/safety trade-off To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Watson Ladd , IETF QUIC WG , Dragana Damjanovic , Jana Iyengar X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 23:59:17 -0000 On 2 February 2017 at 10:51, Ian Swett wrote: > I agree that acking packets we haven't decrypted feels very wrong. Well, it's more than a feeling :) You can't take back an ACK. And if you later find that you can't decrypt the packet, you might find yourself in a terrible bind. > BTW, what's in the finished message? Possibly it could not even exist for > QUIC and be implicit now that QUIC has a key phase bit? The TLS Finished contains a MAC that provides key confirmation. That's saying that producing and verifying it provides proof that the handshake was successful and that the two endpoints agree about the link between the handshake and the keys that it produced (caveat: I am not a cryptographer, so please don't rely on my definition). Key phase doesn't help here. Finished is not a signal about the transition from handshake to application data, it is critical to the handshake *being* complete. From nobody Wed Feb 1 16:12:49 2017 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 24C8A1295F2 for ; Wed, 1 Feb 2017 16:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-3.199, 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 dW_mGC4Z84AT for ; Wed, 1 Feb 2017 16:12:46 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A2112960A for ; Wed, 1 Feb 2017 16:12:46 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id l19so226380ywc.2 for ; Wed, 01 Feb 2017 16:12:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+icIb7Q1De5CTQ5L7Smk1AUMKRxweLHFuo29k5rdoDQ=; b=V06KRL8OY8AtnwSZ6W7caWhXV1MXO+zy8PQmqIrQKE8ekZX8owfcZHgvEQk5J47wK4 +8jtjmwfMZZdBGgCJK4SthShqoGq/rLa618PN6fsRo5E6M9E1qkYenHtFvqIktYCF0Tr yK2FdmGZQR+OYu3prTyYzWgKZCjpYDK2XIYZbv2dJPY2DmXKFK+dTpFBrTuwQY647Tl3 aieF3jTJB3VgnCHmbDyeV15WM2HI7BCAqfp5/wxU7UIQg3MxviGUOczdF7t7MQvkrPYw 9YTJHYWPJUyeGdqpfjTO8w9iNJryY1RuLACwVd7SEnZfeZADAC+n+8SogRtIu2CSJk6g MyfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+icIb7Q1De5CTQ5L7Smk1AUMKRxweLHFuo29k5rdoDQ=; b=QnTnIc4E69c12hQt/VkwNgICy2yzb5QF6mzZri4XHkWLiVLfNukM10MK2+9/8qobPg b8DUo18UTybfJ8wjx7GIqsK1X1kLdrC/WNfaQF/iQXCisywFmG6PwbEcKxUv7JSZveNE kkwJKb4PU2hrl57EU2XeopXo1SYYrALOIwb62AwI/+wYz8Xw2iUzG8ez58AeCQ7OyB83 INFg4nmjCRZpIeeroe82TiUwn+S7uCniE8BTriNVa5vmYJWqGKg8egivwPp5uQKQDPor eGY4s0KxSMNPACK6okz7N5Z+G2F3ZT7qhBSPv3VUGb0bPxUuVECCImI5dnAcGizreHUs Vx4w== X-Gm-Message-State: AIkVDXJ2Np0A8pOmSTSM7GdTAL14bEXBIdLMrcug0otlYCGkYEYfXX7ix0wLyvMs0DS/Ofc0qE20oMMBCj20FypW X-Received: by 10.129.110.70 with SMTP id j67mr3668642ywc.7.1485994365875; Wed, 01 Feb 2017 16:12:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Wed, 1 Feb 2017 16:12:25 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Wed, 1 Feb 2017 19:12:25 -0500 Message-ID: Subject: Re: Performance/safety trade-off To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1149252851426805478106ea Archived-At: Cc: Watson Ladd , IETF QUIC WG , Dragana Damjanovic , Jana Iyengar X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:12:48 -0000 --001a1149252851426805478106ea Content-Type: text/plain; charset=UTF-8 On Wed, Feb 1, 2017 at 6:59 PM, Martin Thomson wrote: > On 2 February 2017 at 10:51, Ian Swett wrote: > > I agree that acking packets we haven't decrypted feels very wrong. > > Well, it's more than a feeling :) You can't take back an ACK. And if > you later find that you can't decrypt the packet, you might find > yourself in a terrible bind. > > I believe the proposal was to ack the undecrypted packets in an unencrypted ack, have the peer see the ack, but not trust it(since it's unencrypted), but still engage loss recovery for any packets that were unencrypted less than the encrypted packets? But yes, we clearly can't trust unencrypted acks for encrypted packets, as we've discussed. > > BTW, what's in the finished message? Possibly it could not even exist > for > > QUIC and be implicit now that QUIC has a key phase bit? > > The TLS Finished contains a MAC that provides key confirmation. > That's saying that producing and verifying it provides proof that the > handshake was successful and that the two endpoints agree about the > link between the handshake and the keys that it produced (caveat: I am > not a cryptographer, so please don't rely on my definition). > > Key phase doesn't help here. Finished is not a signal about the > transition from handshake to application data, it is critical to the > handshake *being* complete. > Ok, so the question(which I can't answer), is whether encrypting data with the resulting keys could be considered functionally equivalent to key confirmation? --001a1149252851426805478106ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 1, 2017 at 6:59 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
= On 2 February 2017 at 10:51, Ian Swett <ianswett@google.com> wrote:
> I agree that acking packets we haven't decrypted feels very wrong.=

Well, it's more than a feeling :)=C2=A0 You can't take back = an ACK.=C2=A0 And if
you later find that you can't decrypt the packet, you might find
yourself in a terrible bind.


I believe the = proposal was to ack the undecrypted packets in an unencrypted ack, have the= peer see the ack, but not trust it(since it's unencrypted), but still = engage loss recovery for any packets that were unencrypted less than the en= crypted packets?=C2=A0 But yes, we clearly can't trust unencrypted acks= for encrypted packets, as we've discussed.
=C2=A0
> BTW, what's in the finished message?=C2=A0 Possibly it could not e= ven exist for
> QUIC and be implicit now that QUIC has a key phase bit?

The TLS Finished contains a MAC that provides key confirmation.
That's saying that producing and verifying it provides proof that the handshake was successful and that the two endpoints agree about the
link between the handshake and the keys that it produced (caveat: I am
not a cryptographer, so please don't rely on my definition).

Key phase doesn't help here.=C2=A0 Finished is not a signal about the transition from handshake to application data, it is critical to the
handshake *being* complete.

Ok, so the question= (which I can't answer), is whether encrypting data with the resulting k= eys could be considered functionally equivalent to key confirmation?
<= /div> --001a1149252851426805478106ea-- From nobody Wed Feb 1 16:17:47 2017 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 105921295F2 for ; Wed, 1 Feb 2017 16:17:46 -0800 (PST) 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 AuScuGAraeWv for ; Wed, 1 Feb 2017 16:17:43 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D01129602 for ; Wed, 1 Feb 2017 16:17:43 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id v23so1098179qtb.0 for ; Wed, 01 Feb 2017 16:17:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6f1XFyDfLr11LzwKYIWWXgzkfJc5A/3qL11TwTu5EH8=; b=aIjogGE+UlkHBMNtITAOXelkSwsF/TtdYMJxpYgqKCPrwtVazpDjq8MByt1FGsAApP luXDkC0xNuVkouhy1thzD3e8hTDPKq90NgO5y3v4AV7aDUxMLxnLcmeMDpRBaPJTIooL 44vClHKnO6t0CynkpTZ+9BCdtm+us/PYYbg1t6tt4RoZe9fYZhZ1KZm5W02wUBZ+6P37 XBb1Z8OP8ZlGaBtXA91573lv+63PiiiHj86QLiSX9d39NMlmzUgoI3r+lS7pV1/Ed9N7 akmZkTwnlOkGe3Bmjv+AJLPnu0c/V+OjmxoZ2bYFahX/bBvT3f6LSOlAZGBAoMK0T3u4 vN7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6f1XFyDfLr11LzwKYIWWXgzkfJc5A/3qL11TwTu5EH8=; b=D5g6pTIhI9ZBbT9dd6eOekkq5uf2Xz5tiMJnQF3DBUh2Twr3quHOqHgIic95r2gnK0 1BR7fEu1rS188XD7mIaf1nbVoo2vRrF7Zf9UvCegfwNbj16kyLSmIw8MGfDF5X9g3E01 mFwZ1P58wLHKE8gkmaVymQFbOJGbjhlb6w8JVMDl11nu+bv/jqGEON4BRIWYXpLPeAMp A+o2M6pj//J9dl1SscG7NQmpnaKy/oJhPdZP6DbIKtS4Xkoz5BRQjQyOs3CerSSuPNlb dns4wBc3EZzqRgLOMtIKfsiYmXeK4tt7i/KojgzZP7S6wMnFBKtmWY4K5arDxi/lHVRe nezw== X-Gm-Message-State: AMke39l4yRFghap7cTWsZrg04b5epHYnz1nZ3ErwLnbgYIH2RKLpogoo47HUBZCmcaFhw/aXQr09+7UdKu5/Ig== X-Received: by 10.55.21.84 with SMTP id f81mr5830503qkh.5.1485994662714; Wed, 01 Feb 2017 16:17:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 1 Feb 2017 16:17:42 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 2 Feb 2017 09:17:42 +0900 Message-ID: Subject: Re: Performance/safety trade-off To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Watson Ladd , IETF QUIC WG , Dragana Damjanovic , Jana Iyengar X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:17:46 -0000 On 2 February 2017 at 09:12, Ian Swett wrote: > Ok, so the question(which I can't answer), is whether encrypting data with > the resulting keys could be considered functionally equivalent to key > confirmation? This is the crux of the thread. As Watson observes, the answer is probably yes. But we don't have a proof that confirms that. Analysis of TLS has mostly kept handshake and record protection separate. From nobody Wed Feb 1 16:29:28 2017 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 287B4129618 for ; Wed, 1 Feb 2017 16:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-3.199, 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 cPcMN7DxMetf for ; Wed, 1 Feb 2017 16:29:25 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2990129626 for ; Wed, 1 Feb 2017 16:29:24 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id v200so382420ywc.3 for ; Wed, 01 Feb 2017 16:29:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LBql/7bHuJxW7kceuTWvenkgOD7+y7iE0wd3QOxpSMA=; b=noKxACKXDZfwt55wmcB9sagMgoF81b4kefWh8gys4vDv7HZ0c+aU8GRQ85lpK21Yxm RohwiMQnIE991xpU5mRNG23WSHfWkzzTd/RgQhB/iRVcHUjbe89mYRs+qE4BYQjlsnij fHoTXEHpuACaVHfwPbN2qZHV09ROLdj82VNhnVAUF/e0y9JW/LqVdY6m0P3qi0ZwoVB2 Knz7h8ju+497MObz3Z+En9sK3JO32gzymO2KhpV+sTvmxUVU/+ALk38MKVI/yi8Sk2FA 0ExC9ssgXbMPD6M1YH4XgMdZmRzFm5yIOLmAlmO/uv/RdfX+w0Uyh3Qv1qAfEbWqjvh+ /qPw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LBql/7bHuJxW7kceuTWvenkgOD7+y7iE0wd3QOxpSMA=; b=Z6GMk16BRQ8DihJ8NjBz98GiCyU1icm+lAA7XQziQejIxCoRfjlwMmADCTGwdaIDcr 5nCf0Jp6k26XjusSo9bf/lX5set7b49gnqD+fK+Ak1KXYfJ6Sx5eIM+/j8MyeapZa82V NETRUDWz3B/RoZvMCC1CYLyudy1dSM1fWQ2Ch8WKcLyqr4qsuXqMUtxYJKawRoXtoc4k SivrSLWEX6c42rjRkvGWkq+UEMHJEcKTvafbbxK/v2DvMqMDD3QmZnx7CKLMDau2hxEL oB6e3YmWokUZuAAjgAKkiqH8+kHGebMFBcTvaCCfUVEx9PFMODWWGBXMopXGJn8SCirr KPIA== X-Gm-Message-State: AIkVDXLaAKQpCY+j3nlM4h61TQDrSN++Lo5g0W8ljiRvHUmFNRZwQ5DpiZ/tJ+AC/OstWXkT1zyVz/WH3Uzql3Hq X-Received: by 10.129.152.77 with SMTP id p74mr3544166ywg.177.1485995363995; Wed, 01 Feb 2017 16:29:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Wed, 1 Feb 2017 16:29:03 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Wed, 1 Feb 2017 19:29:03 -0500 Message-ID: Subject: Re: Performance/safety trade-off To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c0bbf56cf5b8f05478141d6 Archived-At: Cc: Watson Ladd , IETF QUIC WG , Dragana Damjanovic , Jana Iyengar X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 00:29:26 -0000 --94eb2c0bbf56cf5b8f05478141d6 Content-Type: text/plain; charset=UTF-8 So TLDR; 1) Yes, we'd like to decrypt 1RTT packets before the confirmation is received for all the reasons above. 2) It's not absolutely critical to QUIC's existence 3) We need to ask cryptographers, who are likely not on this thread. 4) If it is sufficient, it'd be nice to never send the finished message, since that creates two ways a handshake can complete(and sends an extra packet). On Wed, Feb 1, 2017 at 7:17 PM, Martin Thomson wrote: > On 2 February 2017 at 09:12, Ian Swett wrote: > > Ok, so the question(which I can't answer), is whether encrypting data > with > > the resulting keys could be considered functionally equivalent to key > > confirmation? > > This is the crux of the thread. As Watson observes, the answer is > probably yes. But we don't have a proof that confirms that. Analysis > of TLS has mostly kept handshake and record protection separate. > --94eb2c0bbf56cf5b8f05478141d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
So TLDR;
=C2=A01) Yes, we'd like to decrypt 1RTT p= ackets before the confirmation is received for all the reasons above.
=
=C2=A02) It's not absolutely critical to QUIC's existence
=C2=A03) We need to ask cryptographers, who are likely not on this th= read.
=C2=A04) If it is sufficient, it'd be nice to never sen= d the finished message, since that creates two ways a handshake can complet= e(and sends an extra packet).

On Wed, Feb 1, 2017 at 7:17 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 2 February 2017 at 09:12, Ian Swett <ianswett@google.com> wrote:
> Ok, so the question(which I can't answer), is whether encrypting d= ata with
> the resulting keys could be considered functionally equivalent to key<= br> > confirmation?

This is the crux of the thread.=C2=A0 As Watson observes, the answer= is
probably yes.=C2=A0 But we don't have a proof that confirms that.=C2=A0= Analysis
of TLS has mostly kept handshake and record protection separate.

--94eb2c0bbf56cf5b8f05478141d6-- From nobody Thu Feb 2 01:38:49 2017 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 38109129651 for ; Thu, 2 Feb 2017 01:38:43 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1BX6hqDwG5zx for ; Thu, 2 Feb 2017 01:38:39 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 24F2912964A for ; Thu, 2 Feb 2017 01:38:38 -0800 (PST) X-AuditID: c1b4fb3a-d5ffb70000004068-29-5892fe1b5eb0 Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.183.57]) by (Symantec Mail Security) with SMTP id CD.E6.16488.B1EF2985; Thu, 2 Feb 2017 10:38:37 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.57) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 2 Feb 2017 10:38:35 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6rGfd5dWP2uRwtgwj9zYHegvGlaXVvUOzCLM5xQXwm4=; b=QhdKEJhciPzII6zzHgEMS7zSZG5hv8UVaP+Ld09J251ECHSkEJywSuSx9p35jwOqwaEpqEsQ8XmIZxHQoyrUco31RQYR8V1mY2ypHjrHi0pVBUIqBL0WwoWpn5TXUioWCRLf1yxzUJHM/cnNoI3oxdHpQLDvWckTfdvu5WjhXL8= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.5; Thu, 2 Feb 2017 09:38:34 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0888.016; Thu, 2 Feb 2017 09:38:34 +0000 From: Ingemar Johansson S To: marcelo bagnulo braun , "gorry@erg.abdn.ac.uk" Subject: RE: about draft-johansson-quic-ecn-00 Thread-Topic: about draft-johansson-quic-ecn-00 Thread-Index: AQHSd7hAuGVD/TJHuEGnPsqrrJ7jGKFS9/SAgAEkbWCAABqlgIAAASVwgAAll4CAARApoIAADGQAgAAFVPA= Date: Thu, 2 Feb 2017 09:38:34 +0000 Message-ID: References: <79bfa1c0-ff80-8a98-0e50-bc03d5a96b30@it.uc3m.es> <5890DDCF.6010507@erg.abdn.ac.uk> <1b31166f-fecc-3813-7980-e7f2422b3ea6@it.uc3m.es> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-office365-filtering-correlation-id: 81e4ed58-6243-432f-9297-08d44b4f41fe x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB348; x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 7:yr7ILpiWRz4io9VznmzX+7HwXsvMLOTux835T7I/VJw5AHIlTL0yMAP4Q+0hfv4/CaIc1GDq4VUBHxM/n5Kh/K6MSUbFDBGE1Orq7emTyDyq3jOq9EIcGmLz/zf02/KceNtDy0h22W6nXzdRIM1phtEvn/gjrpb1rT81NyFbXu7RFa3GYlfjJxUzkNf+ORN7XalX2MRlIci1B0IX1RftBMmfqAx/ejFnX6XKsrNrYT3vkDzLjA1OBxdcwKjLSDievPLb9mOAR0BQy30z7UnfO7U5+HQEJ7utUEGo3Pl5fkolR4le4S7fQy0AYBFJUYuXzfTspudOzqHLCH1Sdd5uUtC2s5oOp4hhHhzmGKBtL8+FZswSlNnJ4raZi60tuR6WGA5Acpbyv/feg2i/jNbiIaIYy5RtelDq/KoQ+039lnLN+/pb4yqKV21DDwQUMz8/+PuCH1C8Aq0Uy2RdHamiI4aMYOi/7hFS2MV9KTz12tkOjvM2j4DMn4lYHGiXROAQBroYG2I/aWeqhIIa8G0UYg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(158342451672863)(72170088055959)(258700866769666); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(20161123562025)(6072148); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB348; x-forefront-prvs: 02065A9E77 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(199003)(189002)(13464003)(81156014)(97736004)(50986999)(122556002)(5660300001)(5001770100001)(93886004)(106356001)(7736002)(345774005)(230783001)(101416001)(2950100002)(66066001)(106116001)(9686003)(105586002)(189998001)(33656002)(68736007)(76176999)(3660700001)(7696004)(54356999)(99286003)(3846002)(55016002)(229853002)(6436002)(6116002)(6506006)(2501003)(77096006)(86362001)(305945005)(6306002)(25786008)(2900100001)(8936002)(8676002)(74316002)(53936002)(102836003)(3280700002)(81166006)(92566002)(2906002)(4326007)(38730400001); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB348; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.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-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2017 09:38:34.7104 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB348 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHe3bv3e6s1ePSPGpCLRMUUpMULdH6lIJWJNQYwVp609Gccq9a 65NZWr4sRPdBV5bB8I0ss8V8yWJzlmJk4EpSTMWZmaCi1DDJcrsL+vY75/9/nvPCoQmpngqi 1doChtWqNDKhD1kvtyQcCtmskUffse+KXyy7h+JL59qE8VWN248TKVVr3wQpJtO6IOXn2DPq DKHwScxiNOoiho1KuuiTU9s5JMqvy772bnBcUIzsWRWIpgEfgcEZaQXyoaX4CYJX3x0UH7xF cNs47QlIrCfgo7NRxCsGAcw5Zwk+GEBQ/mYcVSAxLcSJ0GpzedgPK2HqtYlwM4EPgGG4mHLz bhwJEz2PKd4TBQMNdgHPl+CPcdHjJ3EoWEb6hW6WYAX0fWoi3SzFKwS4+tLcLMZJ0FxZ66mF cAhMub6QfK0AGHc+9PwJGIPp5QjBsz8szG5SvD8TVj/rKX7+fTDz4hRvSYeyyjHv0zRYvtUi dM8IeJiE35YOES+ooexrF8mzBibM7QRvqhPAescNr2kvdN597hV+UGC5v+adgIHm9lLEbyII Jh3lqBpFGP9r3LjVFIHD4WlPFJ/eD4bKGZHRswtfGKp3ko2IbEP+HMNxudkxMZEMq87kuDxt pJYp6ERbR2I1bxztQtb5EzaEaSTbIYmOrpFLKVURp8u1IaAJmZ9EvLGVkmSpdNcZNk/JFmoY zoaCaVIWIIlrnTovxdmqAuYKw+Qz7D9VQIuDihHbkBEnP6kb3Se7YInVmgdzz6U7kt4nLwcm 75k+mEqsGpRXreXm9XRhZrTyw2UV3U+LCd+Wom5re9dOfYlL8mhYoWhvCQhrWsqY6G+eNKX2 5ujmF83JfnRC7y97anhKIRlaWxK6ba5pafSY4+bKQrDxQffp8KXCs2HVzbH1gTKSy1EdjiBY TvUXIwdELiADAAA= Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 09:38:43 -0000 SGkNClllcywgYWRkZWQgYSBzZWN0aW9uIG9uIG1vbml0b3JpbmcgaW4gdGhlIGRyYWZ0LCBjdXJy ZW50bHkgaXQgaXMgbW9yZSBvciBsZXNzIGp1c3QgYSBzdHViLiBOb3Qgc3VyZSBpZiB0aGVyZSBp cyBhbnkgUVVJQyB3b3JrIGl0ZW0gdGhhdCBjb3ZlcnMgbW9uaXRvcmluZyAgQlRXLiANCkEgbW9y ZSByZWNlbnQgRUNOIHRyZWF0bWVudCBwYXBlciBpcyBodHRwczovL2NzcGVya2lucy5vcmcvcHVi bGljYXRpb25zLzIwMTUvMTAvbWNxdWlzdGluMjAxNWVjbi11ZHAucGRmIA0KDQovSW5nZW1hcg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IG1hcmNlbG8gYmFnbnVsbyBi cmF1biBbbWFpbHRvOm1hcmNlbG9AaXQudWMzbS5lc10NCj4gU2VudDogZGVuIDIgZmVicnVhcmkg MjAxNyAxMDoxNQ0KPiBUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3Nv bkBlcmljc3Nvbi5jb20+Ow0KPiBnb3JyeUBlcmcuYWJkbi5hYy51aw0KPiBTdWJqZWN0OiBSZTog YWJvdXQgZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAwDQo+IA0KPiBhZ3JlZQ0KPiANCj4gT3Ro ZXIgaW5mb3JtYXRpb24sIEkgd2FzIHJlYWRpbmcgU3RldmUgQmF1ZXIncyBwYXBlciBvbiBtZWFz dXJpbmcgRUNOIChzZWUNCj4gbGluayBiZWxvdykgYW5kIHRoZXkgc2VlbSB0byBjbGFpbSB0aGF0 IHRoZXkgZG9udCBzZWUgbXVjaCBkaWZmZXJlbmNlIGluDQo+IHRyZWF0bWVudCBvZiBFQ04gbWFy a2VkIHBhY2tldHMgYnkgdGhlIG5ldHdvcmsgd2hldGhlciB0aGV5IGFyZSB0Y3Agb3INCj4gdWRw LCB3aGljaCBpIGd1ZXNzIGl0IGlzIGdvb2QsIGJ1dCBtYXliZSBpdCB3b3VsZCBiZSB3b3J0aHdo aWxlIHRvIG1lYXN1cmUNCj4gaXQ/DQo+IA0KPiANCj4gKGh0dHBzOi8vd3d3LmFrYW1haS5jb20v Y24vemgvbXVsdGltZWRpYS9kb2N1bWVudHMvdGVjaG5pY2FsLQ0KPiBwdWJsaWNhdGlvbi9tZWFz dXJpbmctdGhlLXN0YXRlLW9mLWVjbi1yZWFkaW5lc3MtaW4tc2VydmVycy1jbGllbnRzLWFuZC0N Cj4gcm91dGVycy10ZWNobmljYWwtcHVibGljYXRpb24ucGRmKQ0KPiANCj4gRWwgMDIvMDIvMTcg YSBsYXMgMDk6MzIsIEluZ2VtYXIgSm9oYW5zc29uIFMgZXNjcmliacOzOg0KPiA+IE9LLCB0aGFu a3MsIGl0IGlzIHBlcmhhcHMgdGhlIG1vc3QgY2xlYW4gY3V0IG9wdGlvbiB0byB1c2UgdGhlIEVD TiBmcmFtZSBpbg0KPiBib3RoIGRpcmVjdGlvbnMuDQo+ID4gL0kNCj4gPg0KPiA+PiAtLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBtYXJjZWxvIGJhZ251bG8gYnJhdW4gW21h aWx0bzptYXJjZWxvQGl0LnVjM20uZXNdDQo+ID4+IFNlbnQ6IGRlbiAxIGZlYnJ1YXJpIDIwMTcg MTc6MTcNCj4gPj4gVG86IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25A ZXJpY3Nzb24uY29tPjsNCj4gPj4gZ29ycnlAZXJnLmFiZG4uYWMudWsNCj4gPj4gQ2M6IHF1aWNA aWV0Zi5vcmcNCj4gPj4gU3ViamVjdDogUmU6IGFib3V0IGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVj bi0wMA0KPiA+Pg0KPiA+PiBFbCAwMS8wMi8xNyBhIGxhcyAxNTowNywgSW5nZW1hciBKb2hhbnNz b24gUyBlc2NyaWJpw7M6DQo+ID4+DQo+ID4+PiBbSUpdIFllcywgSSBhc3N1bWUgdGhhdCB5b3Ug bWVhbiBhIHBvc3NpYmxlIEVDTiBmbGFnIGluIHRoZSBBQ0sgZnJhbWUgPy4NCj4gPj4gQWx0ZXJu YXRpdmVseSBhbiBFQ04gZnJhbWUgY2FuIGJlIHVzZWQgaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9u IC4NCj4gPj4NCj4gPj4gSSB3b3VsZCBrZWVwIHRoZSBFQ04gc2VwYXJhdGVkLCBzbywgaSBtZWFu IHRvIGFsc28gdXNlIHRoZSBFQ04gZnJhbWUNCj4gPj4gaW4gdGhlIHJldmVyc2UgZGlyZWN0aW9u DQo+ID4+DQo+ID4+Pj4+IE1vcmUgY29tbWVudHMgaW5saW5lIGJlbG93DQo+ID4+Pj4+DQo+ID4+ Pj4+IC9JbmdlbWFyDQo+ID4+Pj4+DQo+ID4+Pj4+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiA+Pj4+Pj4gRnJvbTogR29ycnkgRmFpcmh1cnN0IFttYWlsdG86Z29ycnlAZXJnLmFiZG4u YWMudWtdDQo+ID4+Pj4+PiBTZW50OiBkZW4gMzEgamFudWFyaSAyMDE3IDE5OjU2DQo+ID4+Pj4+ PiBUbzogbWFyY2VsbyBiYWdudWxvIGJyYXVuIDxtYXJjZWxvQGl0LnVjM20uZXM+DQo+ID4+Pj4+ PiBDYzogcXVpY0BpZXRmLm9yZzsgSW5nZW1hciBKb2hhbnNzb24gUw0KPiA+Pj4+Pj4gPGluZ2Vt YXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPg0KPiA+Pj4+Pj4gU3ViamVjdDogUmU6IGFib3V0 IGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMA0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEknZCBhbHNv IGxpa2UgdG8gdGhhbmsgeW91IGZvciB0aGlzIGNvbnNpZGVyYXRpb24gb2Ygd2hlcmUgRUNODQo+ ID4+Pj4+PiBmaXRzIHdpdGhpbg0KPiA+Pj4+IFFVSUMuDQo+ID4+Pj4+PiBJIGhhdmUgYSBmZXcg Y29tbWVudHMsIHNlZSBiZWxvdzoNCj4gPj4+Pj4+DQo+ID4+Pj4+PiBJIHJlYWxseSBkbyBzZWUg bWVyaXQgaW4gcmVxdWlyaW5nIGltcGxlbWVudGF0aW9uIG9mIHRoZSByZWNlaXZlcg0KPiA+Pj4+ IGZ1bmN0aW9uYWxpdHkuDQo+ID4+Pj4+PiBUaGlzIHRvIG1lIGlzIGluZGVwZW5kZW50IG9mIGEg ZGVjaXNpb24gd2hldGhlciB0byB1c2UgdGhlIEVDTg0KPiA+Pj4+Pj4gZnVuY3Rpb25hbGl0eSBh dCB0aGUgc2VuZGVyLiBJ4oCZZCBzdXBwb3J0IGl0IGJlaW5nIG1hbmRhdG9yeSB0bw0KPiA+Pj4+ Pj4gaW1wbGVtZW50ICphdCBsZWFzdCogYmFzaWMgRUNOIHJlY2VpdmVyIHN1cHBvcnQgKHdoaWNo IEkgdGhpbmsgaXMNCj4gPj4+Pj4+IHNpbWlsYXIgdG8NCj4gPj4+PiB3aGF0IG1hcmNlbG8gc2Fp ZCkuDQo+ID4+Pj4+PiBkcmFmdC1pZXRmLXRzdndnLXJmYzU0MDViaXMgKG5vdyBpbiBSRkMtRUQg cXVldWUpLCBwcm92aWRlcyBhDQo+ID4+Pj4+PiBjaGVja2xpc3QgZm9yIFVEUCBzdXBwb3J0IGZv ciBFQ04sIHRoZSBjdXJyZW50IGxpc3QgaW4gdGhlIGRyYWZ0DQo+ID4+Pj4+PiBzZWVtcyBzaW1p bGFyLCBidXQgaXMgbm90IHF1aXRlIHRoZSBzYW1lLiBJIHRoaW5rIHNpbmNlDQo+ID4+Pj4+PiBy ZmM1NDA1YmlzIGlzIHNjaGVkdWxlZCBmb3IgQkNQLCBpdCB3b3VsZCBiZSBnb29kIHRvIGNpdGUg dGhpcw0KPiA+Pj4+Pj4gYW5kIGFsaWduIHdoZXJlDQo+ID4+IHBvc3NpYmxlLg0KPiA+Pj4+PiBb SUpdIFRvdGFsbHkgbWlzc2VkIHRoaXMsIHNvcnJ5IGZvciB0aGUgaWdub3JhbmNlLCBzaG91bGQN Cj4gPj4+Pj4gZGVmaW5pdGVseSBiZQ0KPiA+Pj4+IHJlZmVyZW5jZWQuDQo+ID4+Pj4+PiBUaGUg ZGVjaXNpb24gd2hldGhlciBhIHNlbmRlciBjaG9vc2VzIHRvIG1hcmsgdXNpbmcgRUNUKDApIG9y DQo+ID4+Pj4+PiBFQ1QoMSkgb3IgbmVpdGhlciBuZWVkcyB0byBiZSBiYXNlZCBvbiB1bmRlcnN0 YW5kaW5nIG9mIHdoZXRoZXINCj4gPj4+Pj4+IHRoZSBjb21iaW5lZCBzZW5kIGFuZCByZWNlaXZl IHN0YWNrcyBhbmQgbmV0d29yayBkZXZpY2VzDQo+ID4+Pj4+PiBjdXJyZW50bHkgcHJvdmlkZSBz dXBwb3J0IChvciBtb3JlIGxpa2VseSBtZWFzdXJlbWVudCksDQo+ID4+Pj4+PiBtb25pdG9yaW5n IGFzIGRlc2NyaWJlZCBpbiAyLjYgKGkuZS4sIHRoaXMgaXMgYSBwZXItcGF0aCBydW4tdGltZQ0K PiA+Pj4+Pj4gZGVjaXNpb24pLiBPbmUgdGhpbmcgYSBRVUlDICByZWNlaXZlciBtYXkgYWxyZWFk eSBrbm93IGlzIHdoZXRoZXINCj4gPj4+Pj4+IGEgcmVjZWl2ZSBzdGFjayBoYXMNCj4gPj4gc3Vw cG9ydCBmb3IgRUNOLg0KPiA+Pj4+PiBbSUpdIFllcywgaXQgc2hvdWxkIGJlIHBvc3NpYmxlIGZv ciBhIHN0YWNrIHRvIHNlbmQgcGFja2V0cyBvdmVyDQo+ID4+Pj4+IHRoZSBsb2NhbA0KPiA+Pj4+ IGludGVyZmFjZSAoMTI3LjAuMC4xKSBhbmQgY2hlY2sgdGhlIHN0YXR1cyBvZiB0aGUgRUNOIGJp dHMuDQo+ID4+Pj4+PiBJIHN1Z2dlc3QgdGhpcyBwbGFjZXMgcmVxdWlyZW1lbnRzIG9uIHRoZSBm ZWVkYmFjayBtZXRob2Q6DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4gQSBzZW5kZXIgbWF5IG5lZWQgdG8g dW5kZXJzdGFuZCBob3cgdGhlIG5ldHdvcmsgZm9yd2FyZHMgRUNUKHgpDQo+ID4+Pj4gbWFya3MN Cj4gPj4+Pj4+IG9uIHRoZSBmb3J3YXJkIHBhdGggLSAoQWx0IDMgc2hvd3Mgc29tZSBmdW5jdGlv bmFsaXR5IGZvciB0aGlzKS4NCj4gPj4+Pj4+IHRoaXMgY2FuIGNvbmZpcm0gd2hldGhlciBFQ1Qo eCkgbWFya3MgYXJlIHJlY2VpdmVkLiBJIGV4cGVjdCB0aGlzDQo+ID4+Pj4+PiB3aWxsIGJlIG5l ZWRlZCB0byBrbm93IHRoYXQgRUNUIGFuZCBFQ04tQ0UgbWFya3MgYXJlIGFjdHVhbGx5DQo+ID4+ Pj4+PiBiZWluZyBzZW50IGFjcm9zcyB0aGUgZW50aXJlIHBhdGgsIGFuZCBhcmUgbm90IGNsZWFy ZWQgYXQgc29tZQ0KPiA+Pj4+Pj4gbWlkcG9pbnQsIGVyYXNpbmcgdGhlIGNvbmdlc3Rpb24gaW5m b3JtYXRpb24uICBJIHRoaW5rIGl0IGlzIGFsc28NCj4gPj4+Pj4+IHdvdWxkIGJlIHVzZWZ1bCB0 byBrbm93IHRoYXQNCj4gPj4+Pj4+IEVDVCgxKSBpcyBhY3R1YWxseSB0cmF2ZXJzaW5nIGEgcGF0 aCB3aGVuIHVzaW5nIG5ldyBFQ1QoMSkNCj4gPj4+Pj4+IHNlbWFudGljcyBhcyBkZXNjcmliZWQg aW4gdGhlIHRzdndnIGRyYWZ0IChha2EgbGlrZSBMNFMpLg0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IEkg Y2FuIHNlZSByZWFsIGFkdmFudGFnZXMgaWYgIGFsdC0xLCBhbHQtMiBhdCBsZWFzdCBwcm92aWRl cyBhDQo+ID4+Pj4+PiBjb3VudCB0byBpbmRpY2F0ZSB0aGUgbnVtYmVyIG9mIHBhY2tldHMgKGJ5 dGVzPykgcmVjZWl2ZWQgd2l0aA0KPiA+Pj4+Pj4gbm90LUVDVDsgRUNUKDApOw0KPiA+Pj4+IGFu ZCBFQ1QoMSkuDQo+ID4+Pj4+IFtJSl0gSSB3b3VsZCBzYXkgdGhhdCB5b3Ugd2lsbCBnZXQgdGhl IHNhbWUgaW5mb3JtYXRpb24gd2l0aCBhbGwNCj4gPj4+Pj4gdGhlIHRocmVlDQo+ID4+Pj4gbWV0 aG9kcywgIGluIHRoZSBjYXNlIG9mIGFsdCAxIGFuZCAyIHRoZSBidXJkZW4gdG8gY29tcHV0ZSB0 aGUNCj4gPj4+PiBudW1iZXIgb2Ygbm90LUVDVCwgRUNUKDApIGFuZCBFQ1QoMSkgaXMgb24gdGhl IHNlbmRlciBzaWRlLCB3aGlsZQ0KPiA+Pj4+IHdpdGggYWx0IDMgdGhlIGJ1cmRlbiBpcyBvbiB0 aGUgcmVjZWl2ZXIgc2lkZSAoYnV0IHRoZSBjb3N0IGlzIGFkbWl0dGVkbHkNCj4gcXVpdGUgbG93 KS4NCj4gPj4+Pj4+IEtub3dpbmcgcmVjZWl2ZSBjb2RlIHBvaW50IGluZm9ybWF0aW9uIHdvdWxk IGFsc28gcHJvdmlkZQ0KPiA+Pj4+Pj4gb3Bwb3J0dW5pdGllcyB0byBkZXRlY3QgYW5kIHJlYWN0 IGFwcHJvcHJpYXRlbHkgdG8gbWlzYmVoYXZpbmcNCj4gPj4+Pj4+IHJlY2VpdmVycy9wYXRocyAo aW5jbHVkaW5nIHNlbmRlciBjb250cm9sIHRvIHNldCB0aGUgbWFyayB2YWx1ZSkNCj4gPj4+Pj4+ IC0gYWx0aG91Z2ggYXQgbGVhc3Qgd2hpbGUgdGhlIHBhdGgvcmVjZWl2ZXIgaXMgYmVpbmcgdmVy aWZpZWQgdGhlDQo+ID4+Pj4+PiBzZW5kZXIgd2lsbCBsaWtlbHkgYWxzbyBiZSBuZWVkZWQgdG8g a25vdw0KPiA+Pj4+Pj4gKndoaWNoKiBwYWNrZXRzIGNhcnJpZWQgYSBzcGVjaWZpYyBtYXJrLiAo YXMgbm90ZWQgYWx0LTMgbWF5IG5vdA0KPiA+Pj4+Pj4gcHJvdmlkZSB0aGlzKS4gSG93IHdlIHNo b3VsZCBkbyB0aGlzLCBJIGFtIG5vdCBzdXJlIC0gdmFyaW91cw0KPiA+Pj4+Pj4gd2F5cyBleGlz dCAtIGJ1dCBkZXNpZ25pbmcgYSB0cmFuc3BvcnQgdGhhdCBjYW4gYWxsb3cgdGhpcyBzaG91bGQg YmUNCj4gcG9zc2libGUuDQo+ID4+Pj4+IFtJSl0gWWVzLCBhbHQgMywgZG9lcyBub3QgYWxsb3cg dG8gZGV0ZXJtaW5lIHdoaWNoIHBhY2tldHMgaGF2ZQ0KPiA+Pj4+PiB3aGljaCBFQ04NCj4gPj4+ PiBtYXJrLCBpdCBpcyB1bmNsZWFyIHRob3VnaCB0byBtZSBob3cgaW1wb3J0YW50IHRoaXMgaXMu DQo+ID4+Pj4+PiBHb3JyeQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+DQo+ID4+Pj4+Pg0KPiA+Pj4+Pj4g T24gMjYvMDEvMjAxNyAxMDo0MCwgbWFyY2VsbyBiYWdudWxvIGJyYXVuIHdyb3RlOg0KPiA+Pj4+ Pj4+IEhpLA0KPiA+Pj4+Pj4+DQo+ID4+Pj4+Pj4gSSBoYXZlIHJlYWQgdGhlIGRyYWZ0IGFuZCBp IHRoaW5rIGl0IGlzIGEgZ29vZCBzdGFydGluZyBwb2ludA0KPiA+Pj4+Pj4+IGZvciB0aGlzIGlz c3VlLiB0aGFua3MgZm9yIHdyaXRpbmcgaXQuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBNeSBtYWlu IGNvbW1lbnQgaXMgYWJvdXQgdGhlIEVDTiBuZWdvdGlhdGlvbi4gSSBhbSB1bmNvbnZpbmNlZA0K PiA+Pj4+Pj4+IHRoYXQgdGhlIHF1aWMgdmVyc2lvbiBuZWdvdGlhdGlvbiBpcyB0aGUgcmlnaHQg YXBwcm9hY2ggZm9yIHRoaXMuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiBJIG1lYW4sIGFmYWl1LCBx dWljIHZlcnNpb24gbmVnb3RpYXRpb24gaW1wb3NlcyBhbiBleHRyYSBSVFQNCj4gPj4+Pj4+PiB3 aGVuIHRoZSBuZXcgdmVyc2lvbiBpcyBub3Qgc3VwcG9ydGVkLiBJIHRoaW5rIHRoaXMgaXMgb2sg Zm9yDQo+ID4+Pj4+Pj4gbWFqb3IgdmVyc2lvbiBjaGFuZ2VzLCBidXQgSSBkb250IHRoaW5rIHRo aXMgaXMgYXBwcm9wcmlhdGUgZm9yDQo+ID4+Pj4+Pj4gZmVhdHVyZSBuZWdvdGlhdGlvbiBzdWNo IGFzIEVDTi4NCj4gPj4+Pj4+Pg0KPiA+Pj4+Pj4+IEkgbWVhbiwgdW5sZXNzIEVDTiBpcyBzdXBw b3J0ZWQgYnkgZGVmYXVsdCBpbiB0aGUgZmlyc3QgcXVpYw0KPiA+Pj4+Pj4+IHZlcnNpb24sIEkg dGhpbmsgdXNpbmcgcXVpYyB2ZXJzaW9uIG5lZ290aWF0aW9uIGZvciAgRUNOIHN1cHBvcnQNCj4g Pj4+Pj4+PiB3b3VsZCBiZSBhbiBvYnN0YWNsZSBpbiBFQ04gYWRvcHRpb24gaW4gcXVpYy4gSSBt ZWFuLCBpZiB3ZSBlbmQNCj4gPj4+Pj4+PiB1cCBpbiB0aGUgc2l0dWF0aW9uIHRoYXQgdGhlIGZp cnN0ICh3aWRlbHkgZGVwbG95ZWQpIHF1aWMNCj4gPj4+Pj4+PiBwcm90b2NvbCBzcGVjaWZpY2F0 aW9uIGRvZXMgbm90IHN1cHBvcnQgRUNOIGJ5IGRlZmF1bHQsIHRoZW4NCj4gPj4+Pj4+PiBoYXZp bmcgRUNOIG5lZ290aWF0aW9uIHVzaW5nIHF1aWMgdmVyc2lvbiB3aWxsIGltcGx5IHRoYXQgaWYg YQ0KPiA+Pj4+Pj4+IGNsaWVudCB3YW50cyB0byB0cmllcyB0byBzZWUgaWYgdGhlIHNlcnZlciBz dXBwb3J0cyBFQ04sIGl0DQo+ID4+Pj4+Pj4gcmlza3MgdG8gaGF2ZSBhIGV4dHJhIFJUVCBwZW5h bHR5LiAoaSB1bmRlcnN0YW5kIHRoZSBjbGllbnQgY2FuDQo+ID4+Pj4+Pj4gY2FjaGUgd2hpY2gg c2VydmVycyBzdXBwb3J0IEVDTiwgYnV0IHdlIGFyZSBiYWNrIGludG8gd29ya2luZw0KPiA+Pj4+ Pj4+IGFyb3VuZCB0aGVzZSBkaWZmaWN1bHRpZXMgdGhhdCBtYWtlIGVjbiBhZG9wdGlvbiBoYXJk ZXIpLg0KPiA+Pj4+PiBbSUpdIFF1aXRlIGNvbnZpbmNpbmcgYXJndW1lbnRzIEkgbXVzdCBzYXku DQo+ID4+Pj4+DQo+ID4+Pj4+Pj4gVGhlIG90aGVyIHByb2JsZW0gaXMgcmVsYXRlZCB0byB0aGUg YmxvY2tpbmcgb2YgRUNOIGJpdHMgaW4gdGhlDQo+ID4+Pj4+Pj4gSVAgaGVhZGVyLiBJZGVhbGx5 LCBJIGd1ZXNzLCB0aGUgY2xpZW50IHNob3VsZCBiZSBhYmxlIHRvIGxlYXJuDQo+ID4+Pj4+Pj4g aWYgdGhlIEVDTiBiaXRzIGFyZSBibG9ja2VkIGR1cmluZyB0aGUgbmVnb3RpYXRpb24gcGhhc2Ug aS5lLg0KPiA+Pj4+Pj4+IHRoZSBuZWdvdGlhdGlvbiBjYW4gZmFpbCBlaXRoZXIgYmVjYXVzZSB0 aGUgc2VydmVyIGRvZXNudA0KPiA+Pj4+Pj4+IHN1cHBvcnQgaXQgb3IgYmVjYXVzZSB0aGUgbmV0 d29yayBkb2VzbnQgc3VwcG9ydCBpdC4gQmVjYXVzZSBvZg0KPiA+Pj4+Pj4+IHRoaXMsIEkgd291 bGQgYXJndWUgdGhhdCB0aGUgZ29vZCBhcHByb2FjaCBpcyB0byBoYXZlIHRoZSBFQ04NCj4gPj4+ Pj4+PiBiaXRzIHNldCBpbiB0aGUgSVAgaGVhZGVyIG9mIHRoZSBwYWNrZXQgY2FycnlpbmcgdGhl IEVDTiBuZWdvdGlhdGlvbi4NCj4gPj4+Pj4gW0lKXSBPSw0KPiA+Pj4+Pg0KPiA+Pj4+Pj4+IFNv LCB3aXRoIGFsbCB0aGlzLCBJIHRoaW5rIGl0IG1heSBiZSBhIGJldHRlciBhcHByb2FjaCB0byBt YWtlDQo+ID4+Pj4+Pj4gRUNOIG5lZ290aWF0aW9uIHRvIGJlIGRvbmUgdXNpbmcgYSBuZXcgZnJh bWUgdHlwZSB0aGF0IGlzIHNlbnQNCj4gPj4+Pj4+PiBpbiB0aGUgc3RyZWFtIDEuIFRoaXMgd291 bGQgYmUgYSBtZXNzYWdlIHRoYXQgdGhlIHNlbmRlciBpc3N1ZXMsDQo+ID4+Pj4+Pj4gYWZ0ZXIg dGhlIGNvbm5lY3Rpb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQsIHRvIHJlcXVlc3QgRUNODQo+ID4+ Pj4+Pj4gc3VwcG9ydCBmcm9tIHRoZSBvdGhlciBlbmRwb2ludC4gVGhpcyBtZXNzYWdlIHdvdWxk IGJlIHNlbnQgaW4NCj4gPj4+Pj4+PiBhbiBFQ04gbWFya2VkIHBhY2tldCwgdG8gdmVyaWZ5IHRo YXQgdGhlIG5ldHdvcmsgZGVsaXZlcnMgdGhlDQo+ID4+Pj4+Pj4gbWVzc2FnZS4gVGhlIG90aGVy IGVuZHBvaW50IGNhbiByZXBseSB3aXRoIGFub3RoZXIgbWVzc2FnZQ0KPiA+Pj4+Pj4+IGFjY2Vw dGluZyBvZiBub3QgdGhlIEVDTiBzdXBwb3J0IGZvciB0aGUgY29ubmVjdGlvbi4NCj4gPj4+Pj4g W0lKXSBZZXMsIGFub3RoZXIgbWVzc2FnZSBvciB0byBzaW1wbHkgaW5kaWNhdGUgaXQgaW4gdGhl IEFDSyBmcmFtZS4NCj4gPj4+Pj4NCj4gPj4+Pj4+PiBJIHRoaW5rIHRoaXMgYXBwcm9hY2ggaGFz IHRoZSBiZW5lZml0IG9mIG5vdCBpbXBvc2luZyBleHRyYQ0KPiA+Pj4+Pj4+IGxhdGVuY3kgZm9y IHRob3NlIHdobyB3YW50IHRvIGNoZWNrIGlmIEVDTiBpcyBzdXBwb3J0ZWQgYW5kIGF0DQo+ID4+ Pj4+Pj4gdGhlIHNhbWUgdGltZSB2ZXJpZmllcyB0aGF0IHRoZSBuZXR3b3JrIGlzIGFibGUgdG8g ZGVsaXZlciBFQ04NCj4gPj4+Pj4+PiBtYXJrZWQgcGFja2V0cy4gSWYgYW55IG9mIHRoZXNlIGNv bmRpdGlvbnMgZmFpbCwgdGhlIG5lZ290aWF0aW9uIGZhaWwuDQo+ID4+Pj4+Pj4gTW9yZW92ZXIs IGkgdGhpbmsgdGhlc2UgbWVzc2FnZXMgY2FuIGJlIHVzZWQgdG8gZGlzYWJsZSBFQ04gaW4NCj4g Pj4+Pj4+PiB0aGUgbWlkZGxlIG9mIHRoZSBjb25uZWN0aW9uLiBPbmUgY2FzZSB3aGVyZSB0aGlz IGNhbiBiZSB1c2VmdWwNCj4gPj4+Pj4+PiBpcyBpbiBhIG1vYmlsaXR5IHNjZW5hcmlvLCB3aGVy ZSBvbmUgb2YgdGhlIGVuZHBvaW50cyBtb3ZlIGFuZA0KPiA+Pj4+Pj4+IGluIG9yZGVyIHRvIGNo ZWNrIGlmIHRoZSBuZXcgcGF0aCBzdGlsbCBzdXBwb3J0cyBFQ04sIHRoZXkgY2FuDQo+ID4+Pj4+ Pj4gcmVzZW5kIHRoZSBvcHRpb24gYW5kIHNlZSBpZiB0aGUgcGFja2V0cyBzdGlsbCBtYWtlIGl0 LiBJIGd1ZXNzDQo+ID4+Pj4+Pj4gbW9yZSBjb21wbGljYXRlZCB2ZXJpZmljYXRpb24gbWV0aG9k cyBjb3VsZCBiZSBidWlsdCBpbnRvIHRoaXMuDQo+ID4+Pj4+Pj4NCj4gPj4+Pj4+PiB0aG91Z2h0 cz8NCj4gPj4+Pj4gW0lKXSBTb3VuZHMgcXVpdGUgcmVhc29uYWJsZSwgSSBhIGJpdCB1bmNlcnRh aW4gaWYgaXQgc2hvdWxkIGJlIGFuDQo+ID4+Pj4+IEVDTiBmcmFtZQ0KPiA+Pj4+IHRoYXQgaXMg YWNrbm93bGVkZ2VkIGJ5IGFuIEVDTiBmcmFtZSBvciBpZiB0aGUgQUNLIGZyYW1lIHdpdGggYW4N Cj4gPj4+PiBFQ04gZmllbGQgaXMgc3VmZmljaWVudC4NCj4gPj4+Pj4+PiByZWdhcmRzLCBtYXJj ZWxvDQo+ID4+Pj4+Pj4NCg0K From nobody Thu Feb 2 08:48:30 2017 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 BE21A1294B7 for ; Thu, 2 Feb 2017 08:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 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=-3.199, 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 7bZV9G0_W51T for ; Thu, 2 Feb 2017 08:48:28 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 1BEC512949E for ; Thu, 2 Feb 2017 08:48:28 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id 35so15557288uak.1 for ; Thu, 02 Feb 2017 08:48:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5IjSoZtgqGtfwWCEBB4WbNWfZCahKllRUO6jhdIhq3Q=; b=hfb8gltpHm0z6Ga2oL5ZxroVmOy2gBVX64g9Tol1lUL7/pTVRCvaXuDOknf0nK/3b8 QMFQNQZQUoCsLLR9e2dh18wsZNNnSe/nwlYzL4i6Oz7F3Yq2lETMc40A/vM8j1FX7J4M T7RBKtOj4H6SSPy4Z93anWTLGpXxxedAxrAEqd3yLZaDdHXzXEs9Ul6IK97rcymymj1/ 15AvQ49Ds33bFKsmAtafHM5Ikcm20Mjqgbb7q+QWj3JzsMJslligYIGPSZFMQIkTho6w zoovwZaJSdG1TzWSjjgotAvRVFREs45gwX6Qp9ZEAFiVE/HWQTvDHcKgkD8wSZoiwwa0 AnGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5IjSoZtgqGtfwWCEBB4WbNWfZCahKllRUO6jhdIhq3Q=; b=fJbgs0SYe3x6fWO2X498pNskvH4l5e5HllfpxkK6pH6HIBi/B7OJJ9I9MZybvILADD 8GqV8+u7IiYuLz5z68l2lIlbOWw87Wm8Ie1O2dC8zFoNBfJN5yFk0YBx8t9hfEl5MLO9 KkQ2ek3dns/IoeV42WW3K5vTsLukOfDvq6hE0e51F/tbqnSoAUc5ChYfT6zP10pEOX8D w6la7dgHfe9UbFVBzQq3CgADB0D6Jp3J4TpAm+wkO5vu3JBeST+dnv4AzqcE6CXRWdtu hpLbYHJv6s7uxWraBbkX3y7LTXj0AUEcL2NCqPmYX1BSm6wlR18qRvmMXAybqkJ8cha0 Ovyw== X-Gm-Message-State: AIkVDXKBnlier1Lzef3BBV8j3U/a6cucyyrsQd0AuLNVYKZ0Dxo1GkjxveWAXyjTbJi7aZdyuVhF5yUnFBJDXRNM X-Received: by 10.159.54.205 with SMTP id p71mr3743693uap.61.1486054106871; Thu, 02 Feb 2017 08:48:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 2 Feb 2017 08:48:26 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 2 Feb 2017 08:48:26 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: Ian Swett Content-Type: multipart/alternative; boundary=94eb2c03d92a28ffe405478eefa4 Archived-At: Cc: Dragana Damjanovic , IETF QUIC WG , Martin Thomson , Watson Ladd X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 16:48:29 -0000 --94eb2c03d92a28ffe405478eefa4 Content-Type: text/plain; charset=UTF-8 None of us are cryptographers, so I'd like to recommend that we pull in one before we go one way or the other. Can anyone pull in a cryptographer? Hugo, perhaps? On Wed, Feb 1, 2017 at 4:29 PM, Ian Swett wrote: > So TLDR; > 1) Yes, we'd like to decrypt 1RTT packets before the confirmation is > received for all the reasons above. > 2) It's not absolutely critical to QUIC's existence > 3) We need to ask cryptographers, who are likely not on this thread. > 4) If it is sufficient, it'd be nice to never send the finished message, > since that creates two ways a handshake can complete(and sends an extra > packet). > > On Wed, Feb 1, 2017 at 7:17 PM, Martin Thomson > wrote: > >> On 2 February 2017 at 09:12, Ian Swett wrote: >> > Ok, so the question(which I can't answer), is whether encrypting data >> with >> > the resulting keys could be considered functionally equivalent to key >> > confirmation? >> >> This is the crux of the thread. As Watson observes, the answer is >> probably yes. But we don't have a proof that confirms that. Analysis >> of TLS has mostly kept handshake and record protection separate. >> > > --94eb2c03d92a28ffe405478eefa4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
None of us are cryptographers, so I'd like to recommen= d that we pull in one before we go one way or the other. Can anyone pull in= a cryptographer? Hugo, perhaps?

On Wed, Feb 1, 2017 at 4:29 PM, Ian Swett <ianswett= @google.com> wrote:
So TLDR;
=C2=A01) Yes, we'd like to decrypt 1RTT packets = before the confirmation is received for all the reasons above.
= =C2=A02) It's not absolutely critical to QUIC's existence
=C2=A03) We need to ask cryptographers, who are likely not on this thread.=
=C2=A04) If it is sufficient, it'd be nice to never send the= finished message, since that creates two ways a handshake can complete(and= sends an extra packet).

On Wed, Feb 1, 2= 017 at 7:17 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 2 February 2017 at 0= 9:12, Ian Swett <ianswett@google.com> wrote:
> Ok, so the question(which I can't answer), is whether encrypting d= ata with
> the resulting keys could be considered functionally equivalent to key<= br> > confirmation?

This is the crux of the thread.=C2=A0 As Watson observes, the answer= is
probably yes.=C2=A0 But we don't have a proof that confirms that.=C2=A0= Analysis
of TLS has mostly kept handshake and record protection separate.


--94eb2c03d92a28ffe405478eefa4-- From nobody Thu Feb 2 11:53:48 2017 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 90FEE129522 for ; Thu, 2 Feb 2017 11:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.5 X-Spam-Level: X-Spam-Status: No, score=-7.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfX9hYwbfpBi for ; Thu, 2 Feb 2017 11:53:45 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60E1E1294E3 for ; Thu, 2 Feb 2017 11:53:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 1A5C1BE38; Thu, 2 Feb 2017 19:53:43 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wh0brcwDHUbp; Thu, 2 Feb 2017 19:53:41 +0000 (GMT) Received: from [10.87.48.75] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 0ECB3BE2E; Thu, 2 Feb 2017 19:53:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1486065221; bh=4z7wh973v/TpISxSfuYVafyUdKS1y7vJdZoMKJRB9BE=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=A9hClIlpoLImm83hNwjWGzW2MRSgUuSPArJpgD2F6HaNc0zmLFaHU2byxMFZogG+N g27NC2GkOXaTP53P+kn2oq7+1N1Le0wn5AGPvYQ0j7zlRsVGFXxGz7tOoJ6Oz2nzXx MKDF6r2LgNxICGWf2RsXjGPj/O5MUdsB/AYXiE5Q= Subject: Re: Performance/safety trade-off To: Jana Iyengar , Ian Swett References: From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Thu, 2 Feb 2017 19:53:40 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms010407040600010508040500" Archived-At: Cc: Martin Thomson , IETF QUIC WG , Dragana Damjanovic , Watson Ladd X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2017 19:53:47 -0000 This is a cryptographically signed message in MIME format. --------------ms010407040600010508040500 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 02/02/17 16:48, Jana Iyengar wrote: > None of us are cryptographers, so I'd like to recommend that we pull in= one > before we go one way or the other. Can anyone pull in a cryptographer? > Hugo, perhaps? Someone could also craft the question carefully and send it to cfrg asking for opinions. Asking informally will probably be enough but sometimes WGs ask more formally (via their chairs) which tends to ensure someone does send an answer, but is generally slower. S >=20 > On Wed, Feb 1, 2017 at 4:29 PM, Ian Swett wrote: >=20 >> So TLDR; >> 1) Yes, we'd like to decrypt 1RTT packets before the confirmation is >> received for all the reasons above. >> 2) It's not absolutely critical to QUIC's existence >> 3) We need to ask cryptographers, who are likely not on this thread. >> 4) If it is sufficient, it'd be nice to never send the finished messa= ge, >> since that creates two ways a handshake can complete(and sends an extr= a >> packet). >> >> On Wed, Feb 1, 2017 at 7:17 PM, Martin Thomson >> wrote: >> >>> On 2 February 2017 at 09:12, Ian Swett wrote: >>>> Ok, so the question(which I can't answer), is whether encrypting dat= a >>> with >>>> the resulting keys could be considered functionally equivalent to ke= y >>>> confirmation? >>> >>> This is the crux of the thread. As Watson observes, the answer is >>> probably yes. But we don't have a proof that confirms that. Analysi= s >>> of TLS has mostly kept handshake and record protection separate. >>> >> >> >=20 --------------ms010407040600010508040500 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNzAyMDIx OTUzNDBaMC8GCSqGSIb3DQEJBDEiBCCcVLoq2MdaiT/AZ4k26Gt4zwGPc54koD8VrnCyPHij YjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAN5S2s6M4c+Mce06pb9Q1FJERtKoH2l1k6P9MCLL/+bxJ8vhLxT/N7 FsRhBtKD4HxY4En0D5dLw4HGTarVRfbA2Kve6nCbHcUAVTu9lcEw6c5TevVKwuGcZCuZoeqH qXsMVDeK0wYmg6SseB2ZzayxE9FO9LU0KR2QawT9hYgYnOec90q9J8jvjAva1zvbe8TIGDbW UosxY3GPqJ+nAWiyqpgr38euT9LBz1X2o13CCRowsPLypdYd8YV51pKMtf9tAJQwDrbCexS5 HPKhQnLoANx3VIyRrOs5LaccDz8jizB9ylzdAgzBucwF0tRy4WZbralkBzPUUiuEjaAYjHVG AAAAAAAA --------------ms010407040600010508040500-- From nobody Thu Feb 2 16:02:39 2017 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 1814C12960D for ; Thu, 2 Feb 2017 16:02:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 AhLQtVUVxn2G for ; Thu, 2 Feb 2017 16:02:20 -0800 (PST) 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 BAEC41295E1 for ; Thu, 2 Feb 2017 16:02:19 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id v200so2300388ywc.3 for ; Thu, 02 Feb 2017 16:02:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V5k3aM5LFFcJINAJvFvCd6IN8jnVZU7ljMFnWmNx2sc=; b=YulbXipAVjiCNfhFzvmeWuqDwwfk9Nf/Qkc67mKIBAirAOefeL66mp723SGc2Xr+yc ktSmZdw7YILHKP8BPNVFpy2E+n0cFJrIdYitqCJqCsAzXQ43WZCe6Qq3KC7ReqVYRGdl moIYhkrt1y3EgABgiYQ+5T85x3A1N4CCuzTr3X2XvQToX6UQ+BXnqqkOZxOrjUcm6svx LYfPqYbrKPcUueFaJxdRsXZL4CXkIcmonJpuZ985IXvgTc3hLP1+2DjCK/KQkkJi6XKX oUtXJDNLt35GllTC+gGGKYNvNKl186jMrtCeI6B4KcgepmT8jYb7H2JrlKK0Lbxbhcoj eTtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V5k3aM5LFFcJINAJvFvCd6IN8jnVZU7ljMFnWmNx2sc=; b=tpBowh3DGtchXvqECcpdjhESW89+5slJLTtpfjUuLhG2d62aT/CzxWE4gHNcZB4PKZ TtbY4EG78oS1itnapDLtAztGjTSEZXzWcdyvJF+TlIjLG3YVCWpXvzFBSKQOYUPzdnIZ VqK3mevOJXdQpMyLND0X3Xmqnb5QCk5j1DePGrU4gVcwBNFDz41TfebRx5XyrrMd4ube Fmu5tqWyBmxjmlvbyRYodrcZ862qg3rR8A/7mG2sWQhIMAnUap71WCU2YHcSY13nCWTt Wxn69qe4Aj2790XA7u3C72ZlJmLpttCrDsNyNiCqSVYAS7/OH6ZnTe5rbRuNFFBAryrw Oi/A== X-Gm-Message-State: AIkVDXJGYzfqZjCmCn9zWNLXKAwfOkXlKNaDHIuacn18M0EY9xYBXgYGbfEUXgqx595E6vSjWpUwcCxdJKApqQ== X-Received: by 10.129.137.129 with SMTP id z123mr8563498ywf.327.1486080138824; Thu, 02 Feb 2017 16:02:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 2 Feb 2017 16:01:38 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 3 Feb 2017 01:01:38 +0100 Message-ID: Subject: Re: Performance/safety trade-off To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c06bf38c89e19054794fefa Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 00:02:22 -0000 --94eb2c06bf38c89e19054794fefa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sorry for the delay. It's been a long week of meetings. Here's my understanding of the situation, focusing on the one-way authentication version of TLS; I think we all agree that in the mutually authenticated version, the server needs to wait for the client's Finished. The scenario of interest here is one where the server has sent its complete flight and then receives an AEAD-encrypted message from the client in advance of receiving the client's Finished (which we can model as a handshake without a client Finished). Informally, there are two potential properties we might be interested in here: 1. The integrity of the handshake. 2. "Key confirmation", namely a demonstration that there is a counterparty on the other side who knows the key. Note that this is somewhat complicated by PSK-resumption, but for now consider the full handshake with DHE. One important consideration is that we would like to be able to establish these properties only with reference to the handshake, without relying on the record layer. This allows you to analyze the handshake and then compose it with an arbitrary record layer, rather than relying on the type of combined analysis that was necessary for TLS 1.2. Indeed, that's what we're doing with QUIC, where we are using a record layer that's slightly different from that in TLS 1.3. With that in mind, upon receiving the client's Finished, the server knows that the (anonymous) entity which sent it the ClientHello actually knew the corresponding private DHE share and that the handshake was un-tampered. Note that this guarantee would apply even if the handshake were entirely unencrypted and indeed even if AES-GCM (for instance) were completely broken. Of course, you still don't know who you are talking to. Krawczyk and Wee show in [0] that you actually get a secure one-way protocol even if the client doesn't send a Finished message. Intuitively, the server signs and MACs the entire transcript, so any tampering is detected at the client and the client will not accept the handshake unless it is un-tampered, so the client will also not accept data from the server or send data to the server. The server can of course send 0.5 RTT data, but as it doesn't know who the client is, any tampering is largely irrelevant (See below for the resumption case). Here's what Krawczyk and Wee say: TLS 1.3 include s a mandatory third message in the handshake in which the client sends a MAC value (client=E2=80=99s Finished) computed o= n the prior transcript similar to the one sent by the server in the second message. As our analysis shows this is not needed for the basic key exchange security in the case of server-only authentication. Yet, this message serves several purposes that are valuable in the TLS 1.3 setting. It serves as the confirmation from the client that both server and client have the same view of the transcript, including keying material, server identity and negotiated security parameters (part of the hello messages). Interestingly, the sending of this message has been shown in [21] to =E2=80=9Cupgrade" security from the indistinguishability-based model we use here to universally-composable security. Without the Finished, the server only gets any confirmation that the client has the same view when it decrypts the client's first message. However, as I said, you only get this property via the record layer, which means that your analysis now needs to take that into account, whereas if you have the Finished you can get key confirmation purely by analyzing the handshake. Now, as Watson says, there's a pretty straight line from "received AEAD-encrypted data from the client" to "client successfully completed the handshake", but it's not the cleanest analytical situation. The situation seems a bit more complicated when you are doing resumption because now you actually care about talking to a specific counterparty, especially if you have attached state information the the ticket/PSK pair. I don't believe that this mostly matters in the Krawczyk/Wee analysis, except that it's important not to over-commit to what you know prior to receiving any information from the client's second flight. Specifically, until you receive either Finished or some AEAD-encrypted data, you don't know that you have a fresh connection from the client as opposed to a replayed CH. That's generally true in the full 1-RTT case, you just don't care because the clients are interchangeable. With all that said, the situation really is a lot cleaner if we leave the Finished in place (that's why it's there after all), so I'd like to spend some time seeing if we can do that. It occurs to me that perhaps there's a way to improve Martin's hacky #2 version where we don't encrypt the Finished. Specifically, we're already discussing having a much longer header for "special" packets, which this would be. If we simply decree that special packets also have an explicit length rather than extending them to the end of the UDP datagram, then we can pack multiple packets into a datagram, which lets you send the Finished and requests together, albeit with a little bit of overhead in terms of headers. -Ekr [0] http://eprint.iacr.org/2015/978.pdf On Thu, Feb 2, 2017 at 8:53 PM, Stephen Farrell wrote: > > > On 02/02/17 16:48, Jana Iyengar wrote: > > None of us are cryptographers, so I'd like to recommend that we pull in > one > > before we go one way or the other. Can anyone pull in a cryptographer? > > Hugo, perhaps? > > Someone could also craft the question carefully and send it to cfrg > asking for opinions. Asking informally will probably be enough but > sometimes WGs ask more formally (via their chairs) which tends to > ensure someone does send an answer, but is generally slower. > > S > > > > > > On Wed, Feb 1, 2017 at 4:29 PM, Ian Swett wrote: > > > >> So TLDR; > >> 1) Yes, we'd like to decrypt 1RTT packets before the confirmation is > >> received for all the reasons above. > >> 2) It's not absolutely critical to QUIC's existence > >> 3) We need to ask cryptographers, who are likely not on this thread. > >> 4) If it is sufficient, it'd be nice to never send the finished > message, > >> since that creates two ways a handshake can complete(and sends an extr= a > >> packet). > >> > >> On Wed, Feb 1, 2017 at 7:17 PM, Martin Thomson < > martin.thomson@gmail.com> > >> wrote: > >> > >>> On 2 February 2017 at 09:12, Ian Swett wrote: > >>>> Ok, so the question(which I can't answer), is whether encrypting dat= a > >>> with > >>>> the resulting keys could be considered functionally equivalent to ke= y > >>>> confirmation? > >>> > >>> This is the crux of the thread. As Watson observes, the answer is > >>> probably yes. But we don't have a proof that confirms that. Analysi= s > >>> of TLS has mostly kept handshake and record protection separate. > >>> > >> > >> > > > > --94eb2c06bf38c89e19054794fefa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for the delay. It's been a long week of mee= tings.

Here's my understanding of the situatio= n, focusing on the one-way
authentication version of TLS; I think= we all agree that in the
mutually authenticated version, the ser= ver needs to wait for the
client's Finished.

The scenario of interest here is one where the server has sent
its complete flight and then receives an AEAD-encrypted message
from the client in advance of receiving the client's Finished
(which we can model as a handshake without a client Finished).
=

Informally, there are two potential properties we might= be interested
in here:

1. The integrity= of the handshake.
2. "Key confirmation", namely a demo= nstration that there is a
=C2=A0 =C2=A0counterparty on the other = side who knows the key. Note that
=C2=A0 =C2=A0this is somewhat c= omplicated by PSK-resumption, but for
=C2=A0 =C2=A0now consider t= he full handshake with DHE.
=C2=A0 =C2=A0
One important= consideration is that we would like to be able to
establish thes= e properties only with reference to the handshake,
without relyin= g on the record layer. This allows you to analyze the
handshake a= nd then compose it with an arbitrary record layer, rather
than re= lying on the type of combined analysis that was necessary for
TLS= 1.2. Indeed, that's what we're doing with QUIC, where we are using=
a record layer that's slightly different from that in TLS 1.= 3.=C2=A0 With
that in mind, upon receiving the client's Finis= hed, the server knows
that the (anonymous) entity which sent it t= he ClientHello actually
knew the corresponding private DHE share = and that the handshake was
un-tampered. Note that this guarantee = would apply even if the
handshake were entirely unencrypted and i= ndeed even if AES-GCM (for
instance) were completely broken. Of c= ourse, you still don't know who
you are talking to.

Krawczyk and Wee show in [0] that you actually get a secure= one-way
protocol even if the client doesn't send a Finished<= /div>
message. Intuitively, the server signs and MACs the entire transc= ript,
so any tampering is detected at the client and the client w= ill not
accept the handshake unless it is un-tampered, so the cli= ent will also
not accept data from the server or send data to the= server. The server
can of course send 0.5 RTT data, but as it do= esn't know who the client
is, any tampering is largely irrele= vant (See below for the resumption
case). Here's what Krawczy= k and Wee say:

=C2=A0 TLS 1.3 include s a mandator= y third message in the handshake in
=C2=A0 which the client sends= a MAC value (client=E2=80=99s Finished) computed on
=C2=A0 the p= rior transcript similar to the one sent by the server in the
=C2= =A0 second message. As our analysis shows this is not needed for the
<= div>=C2=A0 basic key exchange security in the case of server-only
=C2=A0 authentication. Yet, this message serves several purposes that are<= /div>
=C2=A0 valuable in the TLS 1.3 setting. It serves as the confirma= tion from
=C2=A0 the client that both server and client have the = same view of the
=C2=A0 transcript, including keying material, se= rver identity and
=C2=A0 negotiated security parameters (part of = the hello
=C2=A0 messages). Interestingly, the sending of this me= ssage has been shown
=C2=A0 in [21] to =E2=80=9Cupgrade" sec= urity from the indistinguishability-based
=C2=A0 model we use her= e to universally-composable security.

Without the = Finished, the server only gets any confirmation that the
client h= as the same view when it decrypts the client's first message.
However, as I said, you only get this property via the record layer,
=
which means that your analysis now needs to take that into account,
whereas if you have the Finished you can get key confirmation purel= y
by analyzing the handshake. Now, as Watson says, there's a = pretty
straight line from "received AEAD-encrypted data from= the client" to
"client successfully completed the hand= shake", but it's not the
cleanest analytical situation.<= /div>

The situation seems a bit more complicated when yo= u are doing
resumption because now you actually care about talkin= g to a specific
counterparty, especially if you have attached sta= te information the
the ticket/PSK pair. I don't believe that = this mostly matters in the
Krawczyk/Wee analysis, except that it&= #39;s important not to over-commit
to what you know prior to rece= iving any information from the client's
second flight. Specif= ically, until you receive either Finished or some
AEAD-encrypted = data, you don't know that you have a fresh connection
from th= e client as opposed to a replayed CH. That's generally true in
the full 1-RTT case, you just don't care because the clients are
interchangeable.

With all that said, the sit= uation really is a lot cleaner if we leave
the Finished in place = (that's why it's there after all), so I'd like
to spe= nd some time seeing if we can do that.

It occurs t= o me that perhaps there's a way to improve Martin's hacky
#2 version where we don't encrypt the Finished. Specifically, we'r= e
already discussing having a much longer header for "specia= l" packets,
which this would be. If we simply decree that sp= ecial packets also
have an explicit length rather than extending = them to the end of the
UDP datagram, then we can pack multiple pa= ckets into a datagram, which
lets you send the Finished and reque= sts together, albeit with a little
bit of overhead in terms of he= aders.

-Ekr


[0] http://eprint.iacr.or= g/2015/978.pdf

On Thu, Feb 2, 2017 at 8:53 PM, Stephen Farrell= <stephen.farrell@cs.tcd.ie> wrote:


On 02/02/17 16:48, Jana Iyengar wrote:
> None of us are cryptographers, so I'd like to recommend that we pu= ll in one
> before we go one way or the other. Can anyone pull in a cryptographer?=
> Hugo, perhaps?

Someone could also craft the question carefully and send it to cfrg<= br> asking for opinions. Asking informally will probably be enough but
sometimes WGs ask more formally (via their chairs) which tends to
ensure someone does send an answer, but is generally slower.

S


>
> On Wed, Feb 1, 2017 at 4:29 PM, Ian Swett <ianswett@google.com> wrote:
>
>> So TLDR;
>>=C2=A0 1) Yes, we'd like to decrypt 1RTT packets before the con= firmation is
>> received for all the reasons above.
>>=C2=A0 2) It's not absolutely critical to QUIC's existence<= br> >>=C2=A0 3) We need to ask cryptographers, who are likely not on this= thread.
>>=C2=A0 4) If it is sufficient, it'd be nice to never send the f= inished message,
>> since that creates two ways a handshake can complete(and sends an = extra
>> packet).
>>
>> On Wed, Feb 1, 2017 at 7:17 PM, Martin Thomson <martin.thomson@gmail.com>
>> wrote:
>>
>>> On 2 February 2017 at 09:12, Ian Swett <ianswett@google.com> wrote:
>>>> Ok, so the question(which I can't answer), is whether = encrypting data
>>> with
>>>> the resulting keys could be considered functionally equiva= lent to key
>>>> confirmation?
>>>
>>> This is the crux of the thread.=C2=A0 As Watson observes, the = answer is
>>> probably yes.=C2=A0 But we don't have a proof that confirm= s that.=C2=A0 Analysis
>>> of TLS has mostly kept handshake and record protection separat= e.
>>>
>>
>>
>


--94eb2c06bf38c89e19054794fefa-- From nobody Thu Feb 2 16:42:20 2017 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 7F882129A4E for ; Thu, 2 Feb 2017 16:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 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=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 fSp7rVU8w0bT for ; Thu, 2 Feb 2017 16:42:17 -0800 (PST) Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c: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 B8A45129A4C for ; Thu, 2 Feb 2017 16:42:16 -0800 (PST) Received: by mail-vk0-x229.google.com with SMTP id x75so3162570vke.2 for ; Thu, 02 Feb 2017 16:42:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XbBPFIF7gxNk/2ePWB/iY3ytmSI61EY4hht243FSepU=; b=WPmE0btTWktQuDFAmBOLOzLgPxQzTJcoxG4ED9/oq9wwtzzXHVEeLnUgzT8nmEk6+B sLZV6pmNLIge/6kA/cPFZybUWkicArIKdEEVkvhTQ0kXtrZIppgPnCd0++zw9KZlJFEF zy3iLVWDtUMYcFjxUcrPSo3AEBV+Z3lM1pDuYM04f/VE+cVb5OpjIJXqjBgvdjwuMj8M ifBsBuGvmZLUloimqFXKeaKsERXN6WcmdStpyvnpdMXliu3TPQ9Gb07KuzYkdGOQQBlr vQnDM5CsMEk61v/xjiAuur1NOGMii3i/A15P2XtS80Stt1TSCwPDy0hlHZPGABmNVGg1 0iGQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XbBPFIF7gxNk/2ePWB/iY3ytmSI61EY4hht243FSepU=; b=LsLh0yCHS1BNLPLPbjTiElwILelqLp1hJjGkCH5c91WiNV4AYCBDasgqQwVdbWgQVR JKLkBIL6FLENEg8RxeBCOALgipU8+5lycSc8tOH1pMgJooOlRIh1PwzvL/5OwQ1s6s8X YKJhKywvZsj2uSNl2NY28Rtz1Mh5rjRMUeoEtj1qSwtaGmJeqL0ilWztu/L9sxQW6v2g zyNIjrZfVLbGun7Th/PaUVNidCIskECFS34Okz8pZX3CiE/+LUXUiiwdxlAebYlRTRb3 DRc2it5qZUyMdvRQyONsMLQCbo4m7GVQT0nZR20WTL80glG+opIgIeRg+aGVqfbtMHNG vLSA== X-Gm-Message-State: AIkVDXLVDXSO9Z/YrIQqDQEa0+J8YN3pGrwfbVAdw/RIRoa/RG4pEHq1Q3wq9vTXk9aavKy6EGsgumnO/Ved+aLm X-Received: by 10.31.89.197 with SMTP id n188mr4345241vkb.58.1486082535379; Thu, 02 Feb 2017 16:42:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 2 Feb 2017 16:42:14 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 2 Feb 2017 16:42:14 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a114e19b0a133a10547958dce Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , IETF QUIC WG , Martin Thomson , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 00:42:19 -0000 --001a114e19b0a133a10547958dce Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable (I'm on thin ice with my understanding of crypto, so please correct me if I'm missing something.) IIUC, using Finished vs. using decryptability of AEAD data is really the same, but proving them to be equivalent is analysis we don't have. While it doesn't matter for TLS 1.3 / TCP (since ordered delivery of Finished followed by data), it seems to me that QUIC's unordered delivery makes it a more interesting problem. Ekr: do you think it's worth asking the cryptographers if using simple decryptability (which if I understand your email correctly, is called the "indistinguishability-based model") is a bad idea? I understand that requiring Finished has been recommended for TLS1.3/TCP, which, again, makes sense since it's obvious that AEAD records arrive after the Finished message, so we might as well use the Finished message to separate analysis. It's less obvious to me however that the requirement for Finished would have existed had the transport underneath been one that allowed unordered delivery. That said, David Benjamin suggested a similar but different variant of Ekr's idea earlier: we could simply include the Finished message (as an additional STREAM frame) in all packets during the 1-RTT round, to ensure that any packet that is received at the server includes the Finished message. A caveat is that the Finished message would be encrypted under the 1-RTT key, but that should be fine, right? On Thu, Feb 2, 2017 at 4:01 PM, Eric Rescorla wrote: > Sorry for the delay. It's been a long week of meetings. > > Here's my understanding of the situation, focusing on the one-way > authentication version of TLS; I think we all agree that in the > mutually authenticated version, the server needs to wait for the > client's Finished. > > The scenario of interest here is one where the server has sent > its complete flight and then receives an AEAD-encrypted message > from the client in advance of receiving the client's Finished > (which we can model as a handshake without a client Finished). > > Informally, there are two potential properties we might be interested > in here: > > 1. The integrity of the handshake. > 2. "Key confirmation", namely a demonstration that there is a > counterparty on the other side who knows the key. Note that > this is somewhat complicated by PSK-resumption, but for > now consider the full handshake with DHE. > > One important consideration is that we would like to be able to > establish these properties only with reference to the handshake, > without relying on the record layer. This allows you to analyze the > handshake and then compose it with an arbitrary record layer, rather > than relying on the type of combined analysis that was necessary for > TLS 1.2. Indeed, that's what we're doing with QUIC, where we are using > a record layer that's slightly different from that in TLS 1.3. With > that in mind, upon receiving the client's Finished, the server knows > that the (anonymous) entity which sent it the ClientHello actually > knew the corresponding private DHE share and that the handshake was > un-tampered. Note that this guarantee would apply even if the > handshake were entirely unencrypted and indeed even if AES-GCM (for > instance) were completely broken. Of course, you still don't know who > you are talking to. > > Krawczyk and Wee show in [0] that you actually get a secure one-way > protocol even if the client doesn't send a Finished > message. Intuitively, the server signs and MACs the entire transcript, > so any tampering is detected at the client and the client will not > accept the handshake unless it is un-tampered, so the client will also > not accept data from the server or send data to the server. The server > can of course send 0.5 RTT data, but as it doesn't know who the client > is, any tampering is largely irrelevant (See below for the resumption > case). Here's what Krawczyk and Wee say: > > TLS 1.3 include s a mandatory third message in the handshake in > which the client sends a MAC value (client=E2=80=99s Finished) computed= on > the prior transcript similar to the one sent by the server in the > second message. As our analysis shows this is not needed for the > basic key exchange security in the case of server-only > authentication. Yet, this message serves several purposes that are > valuable in the TLS 1.3 setting. It serves as the confirmation from > the client that both server and client have the same view of the > transcript, including keying material, server identity and > negotiated security parameters (part of the hello > messages). Interestingly, the sending of this message has been shown > in [21] to =E2=80=9Cupgrade" security from the indistinguishability-bas= ed > model we use here to universally-composable security. > > Without the Finished, the server only gets any confirmation that the > client has the same view when it decrypts the client's first message. > However, as I said, you only get this property via the record layer, > which means that your analysis now needs to take that into account, > whereas if you have the Finished you can get key confirmation purely > by analyzing the handshake. Now, as Watson says, there's a pretty > straight line from "received AEAD-encrypted data from the client" to > "client successfully completed the handshake", but it's not the > cleanest analytical situation. > > The situation seems a bit more complicated when you are doing > resumption because now you actually care about talking to a specific > counterparty, especially if you have attached state information the > the ticket/PSK pair. I don't believe that this mostly matters in the > Krawczyk/Wee analysis, except that it's important not to over-commit > to what you know prior to receiving any information from the client's > second flight. Specifically, until you receive either Finished or some > AEAD-encrypted data, you don't know that you have a fresh connection > from the client as opposed to a replayed CH. That's generally true in > the full 1-RTT case, you just don't care because the clients are > interchangeable. > > With all that said, the situation really is a lot cleaner if we leave > the Finished in place (that's why it's there after all), so I'd like > to spend some time seeing if we can do that. > > It occurs to me that perhaps there's a way to improve Martin's hacky > #2 version where we don't encrypt the Finished. Specifically, we're > already discussing having a much longer header for "special" packets, > which this would be. If we simply decree that special packets also > have an explicit length rather than extending them to the end of the > UDP datagram, then we can pack multiple packets into a datagram, which > lets you send the Finished and requests together, albeit with a little > bit of overhead in terms of headers. > > -Ekr > > > [0] http://eprint.iacr.org/2015/978.pdf > > > On Thu, Feb 2, 2017 at 8:53 PM, Stephen Farrell > wrote: > >> >> >> On 02/02/17 16:48, Jana Iyengar wrote: >> > None of us are cryptographers, so I'd like to recommend that we pull i= n >> one >> > before we go one way or the other. Can anyone pull in a cryptographer? >> > Hugo, perhaps? >> >> Someone could also craft the question carefully and send it to cfrg >> asking for opinions. Asking informally will probably be enough but >> sometimes WGs ask more formally (via their chairs) which tends to >> ensure someone does send an answer, but is generally slower. >> >> S >> >> >> > >> > On Wed, Feb 1, 2017 at 4:29 PM, Ian Swett wrote: >> > >> >> So TLDR; >> >> 1) Yes, we'd like to decrypt 1RTT packets before the confirmation is >> >> received for all the reasons above. >> >> 2) It's not absolutely critical to QUIC's existence >> >> 3) We need to ask cryptographers, who are likely not on this thread. >> >> 4) If it is sufficient, it'd be nice to never send the finished >> message, >> >> since that creates two ways a handshake can complete(and sends an ext= ra >> >> packet). >> >> >> >> On Wed, Feb 1, 2017 at 7:17 PM, Martin Thomson < >> martin.thomson@gmail.com> >> >> wrote: >> >> >> >>> On 2 February 2017 at 09:12, Ian Swett wrote: >> >>>> Ok, so the question(which I can't answer), is whether encrypting da= ta >> >>> with >> >>>> the resulting keys could be considered functionally equivalent to k= ey >> >>>> confirmation? >> >>> >> >>> This is the crux of the thread. As Watson observes, the answer is >> >>> probably yes. But we don't have a proof that confirms that. Analys= is >> >>> of TLS has mostly kept handshake and record protection separate. >> >>> >> >> >> >> >> > >> >> > --001a114e19b0a133a10547958dce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(I'm on thin ice with my understanding of crypto,= so please correct me if I'm missing something.)

IIUC, using Finished vs. using decryptability of AEAD data is really the= same, but proving them to be equivalent is analysis we don't have.

While it doesn't matter for TLS 1.3 / TCP (since = ordered delivery of Finished followed by data), it seems to me that QUIC= 9;s unordered delivery makes it a more interesting problem. Ekr: do you thi= nk it's worth asking the cryptographers if using simple decryptability = (which if I understand your email correctly, is called the "indistingu= ishability-based model") is a bad idea? I understand that requiring Fi= nished has been recommended for TLS1.3/TCP, which, again, makes sense since= it's obvious that AEAD records arrive after the Finished message, so w= e might as well use the Finished message to separate analysis. It's les= s obvious to me however that the requirement for Finished would have existe= d had the transport underneath been one that allowed unordered delivery.

That said, David Benjamin suggested a similar but di= fferent variant of Ekr's idea earlier: we could simply include the Fini= shed message (as an additional STREAM frame) in all packets during the 1-RT= T round, to ensure that any packet that is received at the server includes = the Finished message. A caveat is that the Finished message would be encryp= ted under the 1-RTT key, but that should be fine, right?



On Thu, Feb 2, 2017 at 4:01 PM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank">ekr@rtfm.com> wrote:
Sorry for = the delay. It's been a long week of meetings.

= Here's my understanding of the situation, focusing on the one-way
=
authentication version of TLS; I think we all agree that in the
<= div>mutually authenticated version, the server needs to wait for the
<= div>client's Finished.

The scenario of interes= t here is one where the server has sent
its complete flight and t= hen receives an AEAD-encrypted message
from the client in advance= of receiving the client's Finished
(which we can model as a = handshake without a client Finished).

Informally, = there are two potential properties we might be interested
in here= :

1. The integrity of the handshake.
2. = "Key confirmation", namely a demonstration that there is a
<= div>=C2=A0 =C2=A0counterparty on the other side who knows the key. Note tha= t
=C2=A0 =C2=A0this is somewhat complicated by PSK-resumption, bu= t for
=C2=A0 =C2=A0now consider the full handshake with DHE.
=C2=A0 =C2=A0
One important consideration is that we would = like to be able to
establish these properties only with reference= to the handshake,
without relying on the record layer. This allo= ws you to analyze the
handshake and then compose it with an arbit= rary record layer, rather
than relying on the type of combined an= alysis that was necessary for
TLS 1.2. Indeed, that's what we= 're doing with QUIC, where we are using
a record layer that&#= 39;s slightly different from that in TLS 1.3.=C2=A0 With
that in = mind, upon receiving the client's Finished, the server knows
= that the (anonymous) entity which sent it the ClientHello actually
knew the corresponding private DHE share and that the handshake was
=
un-tampered. Note that this guarantee would apply even if the
handshake were entirely unencrypted and indeed even if AES-GCM (for
=
instance) were completely broken. Of course, you still don't know = who
you are talking to.

Krawczyk and Wee= show in [0] that you actually get a secure one-way
protocol even= if the client doesn't send a Finished
message. Intuitively, = the server signs and MACs the entire transcript,
so any tampering= is detected at the client and the client will not
accept the han= dshake unless it is un-tampered, so the client will also
not acce= pt data from the server or send data to the server. The server
ca= n of course send 0.5 RTT data, but as it doesn't know who the client
is, any tampering is largely irrelevant (See below for the resumpti= on
case). Here's what Krawczyk and Wee say:

=C2=A0 TLS 1.3 include s a mandatory third message in the handshake= in
=C2=A0 which the client sends a MAC value (client=E2=80=99s F= inished) computed on
=C2=A0 the prior transcript similar to the o= ne sent by the server in the
=C2=A0 second message. As our analys= is shows this is not needed for the
=C2=A0 basic key exchange sec= urity in the case of server-only
=C2=A0 authentication. Yet, this= message serves several purposes that are
=C2=A0 valuable in the = TLS 1.3 setting. It serves as the confirmation from
=C2=A0 the cl= ient that both server and client have the same view of the
=C2=A0= transcript, including keying material, server identity and
=C2= =A0 negotiated security parameters (part of the hello
=C2=A0 mess= ages). Interestingly, the sending of this message has been shown
= =C2=A0 in [21] to =E2=80=9Cupgrade" security from the indistinguishabi= lity-based
=C2=A0 model we use here to universally-composable sec= urity.

Without the Finished, the server only gets = any confirmation that the
client has the same view when it decryp= ts the client's first message.
However, as I said, you only g= et this property via the record layer,
which means that your anal= ysis now needs to take that into account,
whereas if you have the= Finished you can get key confirmation purely
by analyzing the ha= ndshake. Now, as Watson says, there's a pretty
straight line = from "received AEAD-encrypted data from the client" to
= "client successfully completed the handshake", but it's not t= he
cleanest analytical situation.

The si= tuation seems a bit more complicated when you are doing
resumptio= n because now you actually care about talking to a specific
count= erparty, especially if you have attached state information the
th= e ticket/PSK pair. I don't believe that this mostly matters in the
Krawczyk/Wee analysis, except that it's important not to over-com= mit
to what you know prior to receiving any information from the = client's
second flight. Specifically, until you receive eithe= r Finished or some
AEAD-encrypted data, you don't know that y= ou have a fresh connection
from the client as opposed to a replay= ed CH. That's generally true in
the full 1-RTT case, you just= don't care because the clients are
interchangeable.

With all that said, the situation really is a lot cleaner = if we leave
the Finished in place (that's why it's there = after all), so I'd like
to spend some time seeing if we can d= o that.

It occurs to me that perhaps there's a= way to improve Martin's hacky
#2 version where we don't = encrypt the Finished. Specifically, we're
already discussing = having a much longer header for "special" packets,
whic= h this would be. If we simply decree that special packets also
ha= ve an explicit length rather than extending them to the end of the
UDP datagram, then we can pack multiple packets into a datagram, which
lets you send the Finished and requests together, albeit with a lit= tle
bit of overhead in terms of headers.

-Ekr




On Thu, Feb 2, = 2017 at 8:53 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ; wrote:


On 02/02/17 16:48, Jana Iyengar wrote:
> None of us are cryptographers, so I'd like to recommend that we pu= ll in one
> before we go one way or the other. Can anyone pull in a cryptographer?=
> Hugo, perhaps?

Someone could also craft the question carefully and send it to cfrg<= br> asking for opinions. Asking informally will probably be enough but
sometimes WGs ask more formally (via their chairs) which tends to
ensure someone does send an answer, but is generally slower.

S


>
> On Wed, Feb 1, 2017 at 4:29 PM, Ian Swett <ianswett@google.com> wrote:
>
>> So TLDR;
>>=C2=A0 1) Yes, we'd like to decrypt 1RTT packets before the con= firmation is
>> received for all the reasons above.
>>=C2=A0 2) It's not absolutely critical to QUIC's existence<= br> >>=C2=A0 3) We need to ask cryptographers, who are likely not on this= thread.
>>=C2=A0 4) If it is sufficient, it'd be nice to never send the f= inished message,
>> since that creates two ways a handshake can complete(and sends an = extra
>> packet).
>>
>> On Wed, Feb 1, 2017 at 7:17 PM, Martin Thomson <martin.thomson@gmail.com= >
>> wrote:
>>
>>> On 2 February 2017 at 09:12, Ian Swett <ianswett@google.com> wrote: >>>> Ok, so the question(which I can't answer), is whether = encrypting data
>>> with
>>>> the resulting keys could be considered functionally equiva= lent to key
>>>> confirmation?
>>>
>>> This is the crux of the thread.=C2=A0 As Watson observes, the = answer is
>>> probably yes.=C2=A0 But we don't have a proof that confirm= s that.=C2=A0 Analysis
>>> of TLS has mostly kept handshake and record protection separat= e.
>>>
>>
>>
>



--001a114e19b0a133a10547958dce-- From nobody Thu Feb 2 16:53:57 2017 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 86C51129A5C for ; Thu, 2 Feb 2017 16:53:55 -0800 (PST) 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 CipmdpMVwNZO for ; Thu, 2 Feb 2017 16:53:54 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71AB6129A59 for ; Thu, 2 Feb 2017 16:53:54 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id k15so9506911qtg.3 for ; Thu, 02 Feb 2017 16:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zE8bHtFEjSb4/Q3E34lFmmQWV1UuQPF11UGTvW0p+T8=; b=qVbJnOwe5YpU4+Y3dHK3QukPFfP+P8Uf9KbzT1NOeQjnjxGIObZlDZ/4CC3ZLtW6Cx sY7/l9gUZ4l199gdLgRF5P/ssCneuGtpfRs/lbFzaJWfzv8//6+LV6QWVNqEREzcfoYX xsZ9ysIkA/hbIHdtP2PaOg7AHxLAPiRjcBjv/LsICoGy816DLuhiwSwyp46lYF/Zt0eR 2BeFcixFQJYlKBV1ftb5/vO0ePn6CmYacyFjIN1FfIVIQT1WDpT8ad8suYkYUbXKyOKa 0zQo0gE44Xtp3lEK+Ne92i8r+pcyHoU93SLw90HZsRxqEF7HJ8RuPb1G08K5IGhXUA+k VHmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zE8bHtFEjSb4/Q3E34lFmmQWV1UuQPF11UGTvW0p+T8=; b=o3HGHSE5BFjkj1oJMfMS3HIwLV47ccLn9iURyo8vRkt43VLUPj7AlCghuPgr4tk6df Y0vdBbdcVDMMxkbgMBrZd2CubZqWurcqg0OgokUH+Vc3gqxxt+EKA9pzBLSHHPU0TQhI BbS3UQF6bp8uFnMtEw7QcH6q409BBAxixcyLlRJs4lxwnPIayxYM+SLKnyOzm9gB0PuK Bt3fMpWE+kehqrhuc5JN4nVYCN3Lkrpx/DbNJoG62R8gwX5N2LeyqTel9d6/r/NBnNX6 UN5VUcEcKE2JqSIBfH8b69UtoDAqMOYT6620Zcopy9LLAWOSwIZbre0vBdr9eZss/Wtx g0kA== X-Gm-Message-State: AIkVDXLVl5Oz/+WmOh/roMIsLiTv7EtVhoV0hR6dThP0EKy0KANSQ0ZrDVsuow+vx7cgpfSfP4Oh+Juwfdondg== X-Received: by 10.200.57.199 with SMTP id v65mr10840891qte.13.1486083233474; Thu, 02 Feb 2017 16:53:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 2 Feb 2017 16:53:52 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 3 Feb 2017 11:53:52 +1100 Message-ID: Subject: Re: Performance/safety trade-off To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Eric Rescorla , Watson Ladd , Ian Swett , Dragana Damjanovic , IETF QUIC WG , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 00:53:55 -0000 On 3 February 2017 at 11:42, Jana Iyengar wrote: > That said, David Benjamin suggested a similar but different variant of Ekr's > idea earlier: we could simply include the Finished message (as an additional > STREAM frame) in all packets during the 1-RTT round, to ensure that any > packet that is received at the server includes the Finished message. A > caveat is that the Finished message would be encrypted under the 1-RTT key, > but that should be fine, right? As in, aggressively "retransmit" those stream 1 frames on every packet until any one of those packets is acknowledged? That works, and avoids having to design a way to cram two different levels of packet protection into the same packet. The rule would be "if you don't provide a client certificate, retransmit all unacknowledged stream 1 data in every packet you send". It's not a lot of bytes (about 40), so maybe that's an elegant solution. From nobody Thu Feb 2 17:09:08 2017 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 2BA61129A64 for ; Thu, 2 Feb 2017 17:09:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 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=-3.199, 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 h4VwJ9Oe9hDf for ; Thu, 2 Feb 2017 17:09:05 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 A6B1E1295F2 for ; Thu, 2 Feb 2017 17:09:05 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id i68so3756257uad.0 for ; Thu, 02 Feb 2017 17:09:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/wPoHBmDIJ9YfHrFO1r/h3UIn38NdjKaA93VTIcEEys=; b=DaQNJ9BKW83dko4j76rA3NWzBOU9+VQi+wIIhK8T4K/3Ovv3KfMu0+5waAkiCWzANx yNSzwN7B54tW5TdQ6ehBTIBhr2OTIAiK2ZgSrapJgGSAdWKS2icjWtkjvsdDsEDvbIki 8/kqZl3RxUv6R9MjS6KtwuXddet/0HVb473+W74XJPVaKBWhosxbk6UXDfmdUZcRDk4O nCyx13GYGuLex9m7vJYZJBLBhe0vWHDyqRXvY9OJzDy0KyZo9KtOhey93TeZz4JHVM2Z vIScDu6M5JG2OFKD3u3YfkfkAdlTR5v6rl8dSmtc7izI4hDB86Wa/P3Darq8dpWLlgXO m1RQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/wPoHBmDIJ9YfHrFO1r/h3UIn38NdjKaA93VTIcEEys=; b=cB1gBzImcCeBSsI7zLbiC2TwScO2J0ANsud8AhksEj0WgNV7MAYIA0vr4nlIPBRvdm Q1xXTzPqo5NqCFabPIXxwCLIl2OMHYLidoR2ZDpE9ehKPfyx9P5R9d4Mu5nwrZYKNQR5 kiIyD3A8IeAlRrAP/xh3ugkWmTeRqes95DqoOIZCIXaBJDlAullsp8uKcVlR+oVFWPX4 WRQHMqy0B2ZDH5eWNCEd0ev5xJnXdK1+mRiGi68oyNUvk5EdYPN2AhhNzMorQOX2ts4T POx9onEbkB07qYOTRpQNNlSwOqb82Tgmt0y8NrxNswGWDMhRMMkRFGBXovgHF6C7cIMm /Qvw== X-Gm-Message-State: AIkVDXI418ZsqfDqaTQ2c7TF8lDuzOvtf0Yg9N5Ic6mvkjIOnN8F7W4NnvnPhVfNZOM+WwrFi55CNmRYz9zELR5S X-Received: by 10.176.83.153 with SMTP id k25mr4870495uaa.141.1486084144452; Thu, 02 Feb 2017 17:09:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 2 Feb 2017 17:09:03 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 2 Feb 2017 17:09:03 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045dd7ec8abf00054795ed3d Archived-At: Cc: Eric Rescorla , Watson Ladd , Ian Swett , Dragana Damjanovic , IETF QUIC WG , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 01:09:07 -0000 --f403045dd7ec8abf00054795ed3d Content-Type: text/plain; charset=UTF-8 On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson wrote: > On 3 February 2017 at 11:42, Jana Iyengar wrote: > > That said, David Benjamin suggested a similar but different variant of > Ekr's > > idea earlier: we could simply include the Finished message (as an > additional > > STREAM frame) in all packets during the 1-RTT round, to ensure that any > > packet that is received at the server includes the Finished message. A > > caveat is that the Finished message would be encrypted under the 1-RTT > key, > > but that should be fine, right? > > As in, aggressively "retransmit" those stream 1 frames on every packet > until any one of those packets is acknowledged? That works, and > avoids having to design a way to cram two different levels of packet > protection into the same packet. > > The rule would be "if you don't provide a client certificate, > retransmit all unacknowledged stream 1 data in every packet you send". > It's not a lot of bytes (about 40), so maybe that's an elegant > solution. > Yeah, that's the idea. Except we'd make it a MAY retransmit, so that a client can choose how often to send it. For instance, a client could choose to only send it only if it's actually going to cause HoL blocking such as in every packet that contains a STREAM frame with offset 0. --f403045dd7ec8abf00054795ed3d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 2, 2017 at 4:53 PM, Martin Thomson <martin.thomson@gmail.co= m> wrote:
= On 3 February 2017 at 11:42, Jana Iyengar <jri@google.com> wrote:
> That said, David Benjamin suggested a similar but different variant of= Ekr's
> idea earlier: we could simply include the Finished message (as an addi= tional
> STREAM frame) in all packets during the 1-RTT round, to ensure that an= y
> packet that is received at the server includes the Finished message. A=
> caveat is that the Finished message would be encrypted under the 1-RTT= key,
> but that should be fine, right?

As in, aggressively "retransmit" those stream 1 frames on = every packet
until any one of those packets is acknowledged?=C2=A0 That works, and
avoids having to design a way to cram two different levels of packet
protection into the same packet.

The rule would be "if you don't provide a client certificate,
retransmit all unacknowledged stream 1 data in every packet you send".=
It's not a lot of bytes (about 40), so maybe that's an elegant
solution.

Yeah, that's th= e idea. Except we'd make it a MAY retransmit, so that a client can choo= se how often to send it. For instance, a client could choose to only send i= t only if it's actually going to cause HoL blocking such as in every pa= cket that contains a STREAM frame with offset 0.

--f403045dd7ec8abf00054795ed3d-- From nobody Thu Feb 2 17:16:55 2017 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 464DB129A67 for ; Thu, 2 Feb 2017 17:16:54 -0800 (PST) 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 lRAtwnvvdufn for ; Thu, 2 Feb 2017 17:16:53 -0800 (PST) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 D4C9B129A66 for ; Thu, 2 Feb 2017 17:16:52 -0800 (PST) Received: by mail-qt0-x22e.google.com with SMTP id k15so10316546qtg.3 for ; Thu, 02 Feb 2017 17:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xrWOpJ525/IXOKSB5NBfJMGzWL8/4PSZOFHj/FMNgwg=; b=Bkp8Ck0wY16IqSpwhRmHkgzN8PUV9vHns+fwURDJWAHOX+oy/QfnvB51u4fjQQl8xV NB/zWlWU3XRmiM7FqkP3XHiuBv/nnFzC2L+rIiRNaw3aMBz8hwvsiZRk8GPOnBRYiVue K0bTVZ79jAz+SZ+itxFnP9B6FAFrufQLBM/cHyPxhIk1jwDrBA1+M5hUO9OU2PGghChx 1Q2QGXmGDYw+k/r0nlVf9EV8sgGP/9MUYbtDZzq6aD0J4nwX2IHnl/9MKq9HNS2SPhOh /tTAKVo8O/raWA8Q+3WVjtD/cx1dyBBydcrUmrVt022nkezhw+BDSs6zMM5FTBR7SF7n ElGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xrWOpJ525/IXOKSB5NBfJMGzWL8/4PSZOFHj/FMNgwg=; b=ESDZ8Alf62Hirf73DH77jjhdUfATYZlBS0MKLd5Rwtr8CbFWxLlMhGDZTk9dnCcs48 aJJnbgJWKypcb43cvxgE1pBWoUr6tDa31wQP8w1n8T6LASExptd+lUObcRncXu0uZyUt hH3RMdjgK/DUGb2qg3QuHvVdtRTf0ZQEWRlaRw6lpsLD/rrvbDQOPTqWvdoFRmcJ7NbK 60hmns32XLEapZ8PbSj27Pji5+NfVhVZPm7x+/Jb/0+humSYkuIw865c2LS71/dRTGU5 /h8gnUrdUndKFTUzK0g+SZivNn7JAC274Z0Gt9M83TpKsEPF14Rk4sYRhFk2DKD5gsef HIJA== X-Gm-Message-State: AIkVDXK8AD5HFfTExaZ3UuhJLiDEGXGj9TgnUskKG5FD3zWNi6te0c5qAsgo9QqSO2Pms7wuyefBoxbrZ3d/Qw== X-Received: by 10.200.55.112 with SMTP id p45mr11535480qtb.278.1486084611993; Thu, 02 Feb 2017 17:16:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 2 Feb 2017 17:16:51 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 3 Feb 2017 12:16:51 +1100 Message-ID: Subject: Re: Performance/safety trade-off To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Eric Rescorla , Watson Ladd , Ian Swett , Dragana Damjanovic , IETF QUIC WG , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 01:16:54 -0000 I'm happy to take that suggestion, as opposed to asking difficult questions of cryptographers. I find that if you ask a difficult question, all you tend to get is more difficulty in understanding the answer. I will write proposed text for this. On 3 February 2017 at 12:09, Jana Iyengar wrote: > On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson > wrote: >> >> On 3 February 2017 at 11:42, Jana Iyengar wrote: >> > That said, David Benjamin suggested a similar but different variant of >> > Ekr's >> > idea earlier: we could simply include the Finished message (as an >> > additional >> > STREAM frame) in all packets during the 1-RTT round, to ensure that any >> > packet that is received at the server includes the Finished message. A >> > caveat is that the Finished message would be encrypted under the 1-RTT >> > key, >> > but that should be fine, right? >> >> As in, aggressively "retransmit" those stream 1 frames on every packet >> until any one of those packets is acknowledged? That works, and >> avoids having to design a way to cram two different levels of packet >> protection into the same packet. >> >> The rule would be "if you don't provide a client certificate, >> retransmit all unacknowledged stream 1 data in every packet you send". >> It's not a lot of bytes (about 40), so maybe that's an elegant >> solution. > > > Yeah, that's the idea. Except we'd make it a MAY retransmit, so that a > client can choose how often to send it. For instance, a client could choose > to only send it only if it's actually going to cause HoL blocking such as in > every packet that contains a STREAM frame with offset 0. > From nobody Thu Feb 2 19:29:02 2017 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 53790129B54 for ; Thu, 2 Feb 2017 19:29:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKbbKrvWcQWe for ; Thu, 2 Feb 2017 19:29:00 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A3D129B53 for ; Thu, 2 Feb 2017 19:28:59 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id w20so14119271qtb.1 for ; Thu, 02 Feb 2017 19:28:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZJU0HXnvQrNqJ4yqUb/oLPcMYrAXe+q42jHaSosdm6o=; b=DmhYbj/Tws4k3km+X5skCVEzsKfczsk+GNpaQCbJlmqyXucNz/GoLeUZcdO5HRPkVH CdfhIoSMFcJymu9774ygkxDnzCDePB1FBpaaZt5kJxay6Y+iq6IgaZvSL+QYysTEmPFQ F4OOtU8SP8oB28mp/v0WJnbKoQiSkloAvgqDsTvin29RAPVoWdwJywRIzUJ8lKITOzPX uq3uznJ7jSwmlwXpbsGsbqWwcLWxJdXswsnu0gc4YCqyuQJL5WEHC8lrRpZ1EIV0lRod U9tdjw72809wP4uw46VyhGnTyxmzB47SyeOLpZQQac9X7JetSpfQZmrXn4Vv2Os17CR2 INFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZJU0HXnvQrNqJ4yqUb/oLPcMYrAXe+q42jHaSosdm6o=; b=nQsUZQE05UGpm3bjUjK2cvbfbf5VPhcmDD4mEv9be9OfH6+o3a8c8tHVFT4PV72jfz FJPn9Uygl5fJg6n2OsP98LVjlag67iWkpqrBulEUCqij6sr6csb7/5SG2BvSy/dIf9Vx YcYZYxC7dgk70AQqVXeCSXzeP62KWI2gOoXUgsI1e9bqHfyU5trK/hByDj0Qfu9/DCEO cc2Rt7/z0Mjbt6RJrdWzCvDA0PO6asI4GNIuRpR9jErAfmNE+9Wy9igDsN6DxpWqXCJz duGuPol4/9XMqGi+jYnuDQpNnZxsfFt23jfF6qw+SXzF6ADgxxKawSw4Fjzp2tXVqMrR ruhQ== X-Gm-Message-State: AIkVDXKs/8BD3b9AYzDzyl9rK1PzFYx59W8kT7rZylXkzibNiziF4m3Dt92Q9yEdYtl278WR8+2WsBnvjGY/rA== X-Received: by 10.55.185.131 with SMTP id j125mr11366639qkf.115.1486092538933; Thu, 02 Feb 2017 19:28:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 2 Feb 2017 19:28:58 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 3 Feb 2017 14:28:58 +1100 Message-ID: Subject: Re: Performance/safety trade-off To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Eric Rescorla , Watson Ladd , Ian Swett , Dragana Damjanovic , IETF QUIC WG , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 03:29:01 -0000 https://github.com/quicwg/base-drafts/pull/260 opened. The text already assumed that you need to wait for finished. I will merge #39 at the same time as this (assuming that there aren't objections). On 3 February 2017 at 12:16, Martin Thomson wrote: > I'm happy to take that suggestion, as opposed to asking difficult > questions of cryptographers. I find that if you ask a difficult > question, all you tend to get is more difficulty in understanding the > answer. > > I will write proposed text for this. > > On 3 February 2017 at 12:09, Jana Iyengar wrote: >> On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson >> wrote: >>> >>> On 3 February 2017 at 11:42, Jana Iyengar wrote: >>> > That said, David Benjamin suggested a similar but different variant of >>> > Ekr's >>> > idea earlier: we could simply include the Finished message (as an >>> > additional >>> > STREAM frame) in all packets during the 1-RTT round, to ensure that any >>> > packet that is received at the server includes the Finished message. A >>> > caveat is that the Finished message would be encrypted under the 1-RTT >>> > key, >>> > but that should be fine, right? >>> >>> As in, aggressively "retransmit" those stream 1 frames on every packet >>> until any one of those packets is acknowledged? That works, and >>> avoids having to design a way to cram two different levels of packet >>> protection into the same packet. >>> >>> The rule would be "if you don't provide a client certificate, >>> retransmit all unacknowledged stream 1 data in every packet you send". >>> It's not a lot of bytes (about 40), so maybe that's an elegant >>> solution. >> >> >> Yeah, that's the idea. Except we'd make it a MAY retransmit, so that a >> client can choose how often to send it. For instance, a client could choose >> to only send it only if it's actually going to cause HoL blocking such as in >> every packet that contains a STREAM frame with offset 0. >> From nobody Fri Feb 3 04:05:14 2017 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 51581129C53 for ; Fri, 3 Feb 2017 04:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 Yj1JjHprrdsq for ; Fri, 3 Feb 2017 04:05:12 -0800 (PST) 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 07C8A129C5B for ; Fri, 3 Feb 2017 04:05:12 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id l19so9783359ywc.2 for ; Fri, 03 Feb 2017 04:05:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8sYWLNYtQGt76JzKbtZHFU0bK6dbaKS5XoJ+Iu36dKM=; b=I3kIn6aT8kN3IjG5D7ujjQ8wzutAYTQFicAQYRhM7e/p5bn5ZGsQ8m3D7/krgQDdx8 58GdDlNGEPN9/xC8Z86gWxpQVogXvHvVJ6lb7kQMwjO2nnmYhZatUDtDWj48pNQ+zg+F yxS49yWX3XXzo+Re+8IQaXQk0jGHaKdjD6NBiI3H0nd1TBpebKtqp7Cqck+VMl9iGKHh GpRBmoJz4Wv1NXLhJJamZA7BIdY7AnUup1v+ancFcEnUGgcwjrIeSHM9AWY5A48m8g9g buRo1iPP1tTjtJh6+8qfnuziBAem1FRhhDuVvTvv2ZLlCriyZ0/7TBXSSBVq5unBP63v OVdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8sYWLNYtQGt76JzKbtZHFU0bK6dbaKS5XoJ+Iu36dKM=; b=oOTDPxKiuabnb+vxpJz8DV/r2caVSSt+OcQzg5g0/sI4bVvN+gq2TmT+uerPp4wIv/ Z1x3N0kB50XTbXWY74aQEY6s4hFJNrdj1BJm8ENKA0JO/Yc38qfqFjMkuimhqQA7V9jv VMT//IUi14ajIrG0zFpd8XJwbOFX7/Y0DGsZx3BRHJEr8kOZxuo+2/vGs8Zow+2YN4cZ zqfSFmI47SCcsYCL6d5BkDXMAGFMOR8eNCJtd/Wc6oy96X8zz1EMF7CStpRAn5NHptvU JOEki+n3UKa4Ftr9GXbxdRTIgm3wJH/rbROZ0SYWr0CDNL37eExoT6QbsZIJFEMc8ij7 TTmQ== X-Gm-Message-State: AIkVDXLYZ7rwE8s7XvHEQt+rLOMYJVH/wDN1dshni0nFtexmEiFCQIASP/U/3HaRosnBIWL5/548ZWMuPQNgMw== X-Received: by 10.129.162.130 with SMTP id z124mr10517787ywg.276.1486123511262; Fri, 03 Feb 2017 04:05:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 3 Feb 2017 04:04:30 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 3 Feb 2017 04:04:30 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c129292fb739d05479f1760 Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , Jana Iyengar , IETF QUIC WG , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 12:05:13 -0000 --94eb2c129292fb739d05479f1760 Content-Type: text/plain; charset=UTF-8 Unfortunately, if you encrypt the Finished with the keys you then use for traffic, this breaks key separation, which we went to quite some trouble to have (this is why TLS 1.3 uses a different handshake key than traffic key.) However, if you combine my proposal with David's, I believe that that resolves all the issues. -Ekr On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson wrote: > On 3 February 2017 at 11:42, Jana Iyengar wrote: > > That said, David Benjamin suggested a similar but different variant of > Ekr's > > idea earlier: we could simply include the Finished message (as an > additional > > STREAM frame) in all packets during the 1-RTT round, to ensure that any > > packet that is received at the server includes the Finished message. A > > caveat is that the Finished message would be encrypted under the 1-RTT > key, > > but that should be fine, right? > > As in, aggressively "retransmit" those stream 1 frames on every packet > until any one of those packets is acknowledged? That works, and > avoids having to design a way to cram two different levels of packet > protection into the same packet. > > The rule would be "if you don't provide a client certificate, > retransmit all unacknowledged stream 1 data in every packet you send". > It's not a lot of bytes (about 40), so maybe that's an elegant > solution. > --94eb2c129292fb739d05479f1760 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Unfortunately, if you encrypt the Finished with the keys y= ou then use for traffic, this
breaks key separation, which we went to q= uite some trouble to have (this is why
TLS 1.3 uses a different h= andshake key than traffic key.) However, if you
combine my propos= al with David's, I believe that that resolves all the issues.

-Ekr

<= br>
On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomso= n <martin.thomson@gmail.com> wrote:
On 3 February 2017 at 11:42, Jana Iyenga= r <jri@google.com> wrote:
> That said, David Benjamin suggested a similar but different variant of= Ekr's
> idea earlier: we could simply include the Finished message (as an addi= tional
> STREAM frame) in all packets during the 1-RTT round, to ensure that an= y
> packet that is received at the server includes the Finished message. A=
> caveat is that the Finished message would be encrypted under the 1-RTT= key,
> but that should be fine, right?

As in, aggressively "retransmit" those stream 1 frames on = every packet
until any one of those packets is acknowledged?=C2=A0 That works, and
avoids having to design a way to cram two different levels of packet
protection into the same packet.

The rule would be "if you don't provide a client certificate,
retransmit all unacknowledged stream 1 data in every packet you send".=
It's not a lot of bytes (about 40), so maybe that's an elegant
solution.

--94eb2c129292fb739d05479f1760-- From nobody Fri Feb 3 06:20:37 2017 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 939D8129D63 for ; Fri, 3 Feb 2017 06:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVG1atdgsHA9 for ; Fri, 3 Feb 2017 06:20:35 -0800 (PST) Received: from mail-ot0-x231.google.com (mail-ot0-x231.google.com [IPv6:2607:f8b0:4003:c0f::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 37148129D2E for ; Fri, 3 Feb 2017 06:20:35 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id 32so15136486oth.3 for ; Fri, 03 Feb 2017 06:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TosJYwBwP+EQM7uMmT7QM9hVkrB7EdlQATNJ3kWWcM4=; b=WSwK6Q8rJv22+RmemRA7EH21W6KlQBchGEV26so2r8DV5AQ4/EOT83x8vaQQ2IP2Oc Pduy4RmXw1nm/3TTNI99qU9kTxW4NOVEZIMgR5+H4TNUxJ4Dh9kDTjAN5CJL3tBH7Wwq fbn9CABBNF0ndXo6a9fdhFPEVrp1maxr1zcPuCLU4DrZ81uYd2WqwXHBEanYOkDFn5LY 51oY3+5uF91pn/cpMaxoMRoivKm81gmowNGWWWvEWHLXqDG0g+t87RLFfuPnnGK4SQ5k rWuOnQSZpx8Tfo99Rr/67PoR5RX1DmGr4bqfGTF7XqMzqKBJhdERXFracfpHZb02ogHc O5/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TosJYwBwP+EQM7uMmT7QM9hVkrB7EdlQATNJ3kWWcM4=; b=m8tBTsY4niU58NOilZCbUGz2VaWNoOgmMUQYlmhanGaCYEI3a/pxw9uKyCcE4tvPEV Tnnz472wlgvDOkrDjd/Q2zpFFHqqRlCG3z570LzbVfpg2VEdhbpS0n0qXjvZojd7Naxf lcYogrwTnrTLrLwuUm42KWtP41/VoAUOJJkXgKWdJyNlpADi2O07VJPm5mxVyINKxZbj RYwKLyMaRp/RwdL7bV/Y2iNk2Im0Bi1hkQHNVoyHHBHiHUp83dcuuP/9QwE0UNM40mVJ 2FKh2WyyZMZm4rXprxiSJHM5gIfBWVF7txVqqRnkDYfdHFYhTtl7RjIV2Z8Ix5v2Ca1N Ylug== X-Gm-Message-State: AIkVDXJgrQTVoy+ZPLjrcpTE58gAZO0rkF+zJ4AVfPZNHiGQhZJba3nGyYLMhDec5Cu4e0u/q0MK85G5kb3v/Q== X-Received: by 10.157.24.40 with SMTP id b37mr7865403ote.245.1486131634576; Fri, 03 Feb 2017 06:20:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.173.78 with HTTP; Fri, 3 Feb 2017 06:20:34 -0800 (PST) In-Reply-To: References: From: Matt Holdrege Date: Fri, 3 Feb 2017 15:20:34 +0100 Message-ID: Subject: Re: Performance/safety trade-off To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1136f63c2b24610547a0fcb4 Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , Jana Iyengar , IETF QUIC WG , Martin Thomson , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 14:20:36 -0000 --001a1136f63c2b24610547a0fcb4 Content-Type: text/plain; charset=UTF-8 Hi, Can I ask the newbie question was RFC 3436 and especially section 1.1 of RFC 6083 considered as lessons learned for security for QUIC? Thanks, -Matt On Fri, Feb 3, 2017 at 1:04 PM, Eric Rescorla wrote: > Unfortunately, if you encrypt the Finished with the keys you then use for > traffic, this > breaks key separation, which we went to quite some trouble to have (this > is why > TLS 1.3 uses a different handshake key than traffic key.) However, if you > combine my proposal with David's, I believe that that resolves all the > issues. > > -Ekr > > > On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson > wrote: > >> On 3 February 2017 at 11:42, Jana Iyengar wrote: >> > That said, David Benjamin suggested a similar but different variant of >> Ekr's >> > idea earlier: we could simply include the Finished message (as an >> additional >> > STREAM frame) in all packets during the 1-RTT round, to ensure that any >> > packet that is received at the server includes the Finished message. A >> > caveat is that the Finished message would be encrypted under the 1-RTT >> key, >> > but that should be fine, right? >> >> As in, aggressively "retransmit" those stream 1 frames on every packet >> until any one of those packets is acknowledged? That works, and >> avoids having to design a way to cram two different levels of packet >> protection into the same packet. >> >> The rule would be "if you don't provide a client certificate, >> retransmit all unacknowledged stream 1 data in every packet you send". >> It's not a lot of bytes (about 40), so maybe that's an elegant >> solution. >> > > --001a1136f63c2b24610547a0fcb4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=

Can I ask the newbie que= stion was RFC 3436 and especially section 1.1 of RFC 6083 considered as les= sons learned for security for QUIC?=C2=A0

Thanks,
-Matt


= On Fri, Feb 3, 2017 at 1:04 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:
Unfortunately, if you= encrypt the Finished with the keys you then use for traffic, this
brea= ks key separation, which we went to quite some trouble to have (this is why=
TLS 1.3 uses a different handshake key than traffic key.) Howeve= r, if you
combine my proposal with David's, I believe that th= at resolves all the issues.

-Ekr


On Thu, Feb 2, 2017 at 4:53 PM, Martin Thom= son <martin.thomson@gmail.com> wrote:
On 3 February 2017 at 11:42, Jana Iyengar <jri@google.com> wrot= e:
> That said, David Benjamin suggested a similar but different variant of= Ekr's
> idea earlier: we could simply include the Finished message (as an addi= tional
> STREAM frame) in all packets during the 1-RTT round, to ensure that an= y
> packet that is received at the server includes the Finished message. A=
> caveat is that the Finished message would be encrypted under the 1-RTT= key,
> but that should be fine, right?

As in, aggressively "retransmit" those stream 1 frames on = every packet
until any one of those packets is acknowledged?=C2=A0 That works, and
avoids having to design a way to cram two different levels of packet
protection into the same packet.

The rule would be "if you don't provide a client certificate,
retransmit all unacknowledged stream 1 data in every packet you send".=
It's not a lot of bytes (about 40), so maybe that's an elegant
solution.


--001a1136f63c2b24610547a0fcb4-- From nobody Fri Feb 3 07:35:39 2017 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 BAD35129432 for ; Fri, 3 Feb 2017 07:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xAkBzrBf5MMm for ; Fri, 3 Feb 2017 07:35:35 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 A7531127078 for ; Fri, 3 Feb 2017 07:35:35 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id s140so1457257qke.0 for ; Fri, 03 Feb 2017 07:35:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ASTMUEwGePFbplGPOn2FFC8c0L5iykaqcYZpWAid1h4=; b=KeX5OtwEGTWfeKQB0wNI1V1RiDNqmysT977SqkgtLxLP52BfZmNNQzp5/YxDt0BnRP nMsltj2XCCpizHvrhw655YjwuaNa0Y+SWBUQjmZusw6p1JIUohl1mC6NC5mpioC3Yprz F3gKXNGZnVu+OiPMD9ubrTSTo9iMeebKaGNd0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ASTMUEwGePFbplGPOn2FFC8c0L5iykaqcYZpWAid1h4=; b=h6z8NKUZ6i47xNtcSGr3HolXFoxBIXbjaY0+IXPi0Agqbdl6MNv1q/vi8IC+dQEI9U FKVTUKuKbhjPgFb0zlte1lspFkU38oLLsTl/hwQWFIXQ7y7ZxX2YCXvTBUK8SCkeIZLX KPgKH+vf/UqAZfSM2SsRCuRs7Nn7qynYQ+XGy1rc2GjnuJBa/Y7BpBSZWB6wNqBazui3 meR2ZywaRsbhYXVLX85n/klG1crHln07ABsOhYTQV178wLhYdt0MFWcb/Ta1mlIS9Xnm GTtbCqT52ldwQ6jZK/IFjVq4RL6mHKXxdRFOUlSg7tPpqDkiN62blG3iOut3s64KaXY4 uUYA== X-Gm-Message-State: AIkVDXI/dFCncHIZym0SfGXBqo37nYfKPi/xZlsWRRQBR2j/6ZPa+LEmyPKKDPgWtGxQDzOmbCUbdHWQiEkUYIuz X-Received: by 10.55.16.11 with SMTP id a11mr14942310qkh.3.1486136134551; Fri, 03 Feb 2017 07:35:34 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Fri, 03 Feb 2017 15:35:24 +0000 Message-ID: Subject: Re: Performance/safety trade-off To: Eric Rescorla , Martin Thomson Content-Type: multipart/alternative; boundary=001a11475cbc63bde40547a20816 Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , Jana Iyengar , IETF QUIC WG , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 15:35:38 -0000 --001a11475cbc63bde40547a20816 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 7:05 AM Eric Rescorla wrote: Unfortunately, if you encrypt the Finished with the keys you then use for traffic, this breaks key separation, which we went to quite some trouble to have (this is why TLS 1.3 uses a different handshake key than traffic key.) However, if you combine my proposal with David's, I believe that that resolves all the issues. I admit I do not know the formal requirements here (should we summon a cryptographer?), but I find this claim puzzling. The Finished message is still encrypted with the TLS-level handshake keys. If our theoretical framework for TLS's security really cares about any additional encoding (which does not reuse any TLS-level keys) we add on top, I feel that framework needs work. Going by this diagram, are we not already doing this? This suggests the Finished and EndOfEarlyData are encrypted with QUIC 1-RTT keys: https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#rfc.section.4.1 David -Ekr On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson wrote: On 3 February 2017 at 11:42, Jana Iyengar wrote: > That said, David Benjamin suggested a similar but different variant of Ekr's > idea earlier: we could simply include the Finished message (as an additional > STREAM frame) in all packets during the 1-RTT round, to ensure that any > packet that is received at the server includes the Finished message. A > caveat is that the Finished message would be encrypted under the 1-RTT key, > but that should be fine, right? As in, aggressively "retransmit" those stream 1 frames on every packet until any one of those packets is acknowledged? That works, and avoids having to design a way to cram two different levels of packet protection into the same packet. The rule would be "if you don't provide a client certificate, retransmit all unacknowledged stream 1 data in every packet you send". It's not a lot of bytes (about 40), so maybe that's an elegant solution. --001a11475cbc63bde40547a20816 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 3, 2017 at= 7:05 AM Eric Rescorla <ekr@rtfm.com> wrote:
Unfortunately, if you encrypt the Finished with the keys you then us= e for traffic, this
breaks key separation, which we= went to quite some trouble to have (this is why
TLS 1.3 uses a different handshake key than traffic key.) However, if y= ou
combine my proposal with David's, I be= lieve that that resolves all the issues.

I admit I do not know the formal requirements here (should we summon = a cryptographer?), but I find this claim puzzling. The Finished message is = still encrypted with the TLS-level handshake keys. If our theoretical frame= work for TLS's security really cares about any additional encoding (whi= ch does not reuse any TLS-level keys) we add on top, I feel that framework = needs work.

Going by this diagram, are we not already doing this?= This suggests the Finished and EndOfEarlyData are encrypted with QUIC 1-RT= T keys:
https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.ht= ml#rfc.section.4.1

David=
=C2=A0
-Ekr


On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson <= span dir=3D"ltr" class=3D"gmail_msg"><martin.thomson@gmail.com> wrote:
On 3 February 2017 at 11:42, Jana Iyenga= r <jri@google.com> wrote:
> That said, David Benjamin suggested a similar but different variant of= Ekr's
> idea earlier: we could simply include the Finished message (as an addi= tional
> STREAM frame) in all packets during the 1-RTT round, to ensure that an= y
> packet that is received at the server includes the Finished message. A=
> caveat is that the Finished message would be encrypted under the 1-RTT= key,
> but that should be fine, right?

As in, aggressively "retransmit" those stream 1 frames on = every packet
until any one of those packets is acknowledged?=C2=A0 That works, and
avoids having to design a way to cram two different levels of packet
protection into the same packet.

The rule would be "if you don't provide a client certificate,
retransmit all unacknowledged stream 1 data in every packet you send".=
It's not a lot of bytes (about 40), so maybe that's an elegant
solution.

--001a11475cbc63bde40547a20816-- From nobody Fri Feb 3 07:59:07 2017 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 9699A12964F for ; Fri, 3 Feb 2017 07:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 0L_K-89BQGtQ for ; Fri, 3 Feb 2017 07:59:03 -0800 (PST) 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 749DF129462 for ; Fri, 3 Feb 2017 07:59:03 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id w75so14443846ywg.1 for ; Fri, 03 Feb 2017 07:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ejEux6iXl/JBzlkbGCFrXSw1YN1FzMDTwGZU7DGJIZo=; b=kac1vgmPNvJqXKD9GRo4JzwmhLCg301AFpcd18ugIPhnOhTm+3VfMv58UmbdNFkGSX r+e/cmNjgKZC+NmAhVy+308tS4l2f3AQq0AAFrybwYZQlXBTDuq/8CHUQ+a0jWfCVccT 0Ur4+wZ2ZMOTFiwwEcgLKTR6/pepJq3qn/bDTkxz+s0FbHhy08iJsNS0LNQ3AHHce7aP 7d+DcBr79ksZOrE7j3ahY7zVHcs4Hre3+Mr8wXbvfG8m4qmGbu7LCl/oVMl1CP4nNo4T EUsOESO4tP6LLvgmnQEo7fvz1XlHIl8ws2wMHSkM9DhndepWz3tq0zMwnGYNN0bA/WVP 4e5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ejEux6iXl/JBzlkbGCFrXSw1YN1FzMDTwGZU7DGJIZo=; b=T+Vx1LWktHhjY8mvOdwd5iWZqQTsrfdZIMd5J/Rkzc1rJhvdSeQlsVTio1IlgtBsvO c66pmea8qIDsFtEsYdjV3Y7v0z5y6Bd7Jk8tMtpRWqkQMmNoinkl7W52xzQpnrrql0HT VBryL/oSkMrDzyHvnybqjPTIvIIe2XXSHMNTM5ncjPTo67Foh9RtURVb7ZWYnCtexySK 9TVloiDXsuq+SHWiX3yK36LOQnBLYi2tsdjXv9Tpck+j81dd0bkZMQR4TZRMt63ygy94 FmN5LE17+MAH+e+HUHmsGo0fxvp7UkLqWmk5XRs2U7ylQ79jyqtkJ5CATwuGXev+IcBB +x3g== X-Gm-Message-State: AIkVDXJoyC7QKAyZSiROlb2eC80vBCTbYw5z9w/y6+8FEeM2ZMHWqViMHumRgpUYQ9h3uCqsPkln0IoQrBkAog== X-Received: by 10.129.132.77 with SMTP id u74mr9918371ywf.125.1486137542729; Fri, 03 Feb 2017 07:59:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 3 Feb 2017 07:58:22 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 3 Feb 2017 07:58:22 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: David Benjamin Content-Type: multipart/alternative; boundary=001a114f0996529a4a0547a25ce7 Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , Jana Iyengar , IETF QUIC WG , Martin Thomson , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 15:59:05 -0000 --001a114f0996529a4a0547a25ce7 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 7:35 AM, David Benjamin wrote: > On Fri, Feb 3, 2017 at 7:05 AM Eric Rescorla wrote: > > Unfortunately, if you encrypt the Finished with the keys you then use for > traffic, this > breaks key separation, which we went to quite some trouble to have (this > is why > TLS 1.3 uses a different handshake key than traffic key.) However, if you > combine my proposal with David's, I believe that that resolves all the > issues. > > > I admit I do not know the formal requirements here (should we summon a > cryptographer?), > Maybe. This was discussed extensively about a year ago under the topic of "key separation". Some of that is in the TLS archives. I can provide some more detailed references offline if you like. > but I find this claim puzzling. The Finished message is still encrypted > with the TLS-level handshake keys. If our theoretical framework for TLS's > security really cares about any additional encoding (which does not reuse > any TLS-level keys) we add on top, I feel that framework needs work. > Quite possibly. However, one of the design objectives was to build something which was readily analyzable with the tools we have. As I alluded to, some (though not all) of those tools are designed to analyze the handshake and record layer separately and so if you have to use the record layer keys to complete the handshake, then that is no longer possible. It's certainly true that the use of exporter keys to encrypt the Finished message does not threaten the security of the TLS handshake. What it does, as I understand it, is make it problematic to separately analyze the QUIC record layer from the TLS handshake (in the same way as encrypting the TLS handshake with the application layer record keys makes it problematic to analyze the TLS handshake separately from the TLS application layer, which is why TLS 1.3 is designed the way it is). Going by this diagram, are we not already doing this? This suggests the > Finished and EndOfEarlyData are encrypted with QUIC 1-RTT keys: > https://quicwg.github.io/base-drafts/draft-ietf-quic-tls. > html#rfc.section.4.1 > Yes. Apologies for not catching this sooner. -Ekr > > David > > > -Ekr > > > On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson > wrote: > > On 3 February 2017 at 11:42, Jana Iyengar wrote: > > That said, David Benjamin suggested a similar but different variant of > Ekr's > > idea earlier: we could simply include the Finished message (as an > additional > > STREAM frame) in all packets during the 1-RTT round, to ensure that any > > packet that is received at the server includes the Finished message. A > > caveat is that the Finished message would be encrypted under the 1-RTT > key, > > but that should be fine, right? > > As in, aggressively "retransmit" those stream 1 frames on every packet > until any one of those packets is acknowledged? That works, and > avoids having to design a way to cram two different levels of packet > protection into the same packet. > > The rule would be "if you don't provide a client certificate, > retransmit all unacknowledged stream 1 data in every packet you send". > It's not a lot of bytes (about 40), so maybe that's an elegant > solution. > > > --001a114f0996529a4a0547a25ce7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Feb 3, 2017 at 7:35 AM, David Benjamin <davidben@chromium.= org> wrote:
On Fri, Feb 3, 2017 at 7:05 AM Eric Rescorla <ekr@rtfm.com> wrote:
Unfortunately, if you encrypt the Finished with the keys y= ou then use for traffic, this
breaks key separation, which we went to quite some trouble to have (t= his is why
TLS 1.3= uses a different handshake key than traffic key.) However, if you
combine my proposal with D= avid's, I believe that that resolves all the issues.

I admit I do not know the formal requirements here (should we= summon a cryptographer?),

Maybe. This was discussed extensively about a year ago under the t= opic of "key separation".
Some of that is in the TLS ar= chives. I can provide some more detailed references offline
if yo= u like.

=C2=A0
but = I find this claim puzzling. The Finished message is still encrypted with th= e TLS-level handshake keys. If our theoretical framework for TLS's secu= rity really cares about any additional encoding (which does not reuse any T= LS-level keys) we add on top, I feel that framework needs work.
=

Quite possibly. However, one o= f the design objectives was to build something which was
readily = analyzable with the tools we have. As I alluded to, some (though not all) o= f those
tools are designed to analyze the handshake and record la= yer separately and so if you
have to use the record layer keys to= complete the handshake, then that is no longer possible.

It's certainly true that the use of exporter keys to encrypt th= e Finished message does not
threaten the security of the TLS hand= shake. What it does, as I understand it, is make
it problematic t= o separately analyze the QUIC record layer from the TLS handshake
(in the same way as encrypting the TLS handshake with the application laye= r record
keys makes it problematic to analyze the TLS handshake s= eparately from the TLS
application layer, which is why TLS 1.3 is= designed the way it is).


Going by this diagram, are we not already doing this? This suggests= the Finished and EndOfEarlyData are encrypted with QUIC 1-RTT keys:
<= div class=3D"gmail-m_8309976798964129816gmail_msg">https://quicwg.gith= ub.io/base-drafts/draft-ietf-quic-tls.html#rfc.section.4.1

Yes. Apologies for no= t catching this sooner.

-Ekr

<= div>

=

David
=C2=A0
-Ekr<= /div>


O= n Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson <m= artin.thomson@gmail.com> wrote:
On 3 February 2017 at 11:42, Jana Iyengar <jri@google.com> wrote:
> That said, David Benjamin suggested a similar but different variant of= Ekr's
> idea earlier: we could simply include the Finished message (as an addi= tional
> STREAM frame) in all packets during the 1-RTT round, to ensure that an= y
> packet that is received at the server includes the Finished message. A=
> caveat is that the Finished message would be encrypted under the 1-RTT= key,
> but that should be fine, right?

As in, aggressively "retransmit" those stream 1 frames on = every packet
until any one of those packets is acknowledged?=C2=A0 That works, and
avoids having to design a way to cram two different levels of packet
protection into the same packet.

The rule would be "if you don't provide a client certificate,
retransmit all unacknowledged stream 1 data in every packet you send".=
It's not a lot of bytes (about 40), so maybe that's an elegant
solution.


--001a114f0996529a4a0547a25ce7-- From nobody Fri Feb 3 08:04:16 2017 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 92696129C32 for ; Fri, 3 Feb 2017 08:04:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.897 X-Spam-Level: X-Spam-Status: No, score=-5.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xEk42fk6Bf5u for ; Fri, 3 Feb 2017 08:04:13 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8736E129BC5 for ; Fri, 3 Feb 2017 08:04:13 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id v23so42864520qtb.0 for ; Fri, 03 Feb 2017 08:04:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VpbwLnoyAei/PgADlgouH2lzuxszZcfKa9P+DBuSmLw=; b=Az9DeUJYj8XVae0XVd3WA8Epb60FzQTRBpoC6crRGb6kPc54DKcCczRdnML1FO/vi7 cfsIzd684/4P9XSBLNZ+smFVHYXEOT4Pj3Qf2W6s7123/Fveq9MLkbIMkcBPsnuuKBRe svutGauJx4r3uQoGtOe9Gla1wNeCyfwJnU20Y= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VpbwLnoyAei/PgADlgouH2lzuxszZcfKa9P+DBuSmLw=; b=NDgc2N9ZqoHBdMbzbKnIstiTI1zilnjHTSJscQLh5Z3OYLI/73ezwKfCc8vq9Ni0Sw 8U0zWeO7JwZyFUfC30PuezjwmNC6fWNCp0MFwjspDK5IWH4DzoUATdI90qf3wLJ1OsgO JEmsNEZmdWYgLN6HOxXkj3u4ZIxaeCpIG7zesXiNMq+Tv5/d1ZsFsZFpuma+HBL/F0hl 4Wcrfa9jlZUEF4ffQM/QpTk5TXyXWvb0rJqlQxAz95IvDzsHWAMDJgF72YXDdtFW2ARy TpTmqvZrt23WLmrRxbq/I5oBkxGuaqnKLwgGUYQt3ids8n4ZUZqpjV2CWOJpUkhgx9NH xQTA== X-Gm-Message-State: AIkVDXKN3Uv8qjKIANAv88ylgUSljXyy4TrjSotMHxlOYr64BMaF2x9L2WOrYCAuTppB3pI6E8YZvUIrUGL4WKrJ X-Received: by 10.237.35.1 with SMTP id h1mr14486883qtc.276.1486137852448; Fri, 03 Feb 2017 08:04:12 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Benjamin Date: Fri, 03 Feb 2017 16:04:02 +0000 Message-ID: Subject: Re: Performance/safety trade-off To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1135c7b2c8cfe00547a26e7d Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , Jana Iyengar , IETF QUIC WG , Martin Thomson , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:04:15 -0000 --001a1135c7b2c8cfe00547a26e7d Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 10:59 AM Eric Rescorla wrote: On Fri, Feb 3, 2017 at 7:35 AM, David Benjamin wrote: On Fri, Feb 3, 2017 at 7:05 AM Eric Rescorla wrote: Unfortunately, if you encrypt the Finished with the keys you then use for traffic, this breaks key separation, which we went to quite some trouble to have (this is why TLS 1.3 uses a different handshake key than traffic key.) However, if you combine my proposal with David's, I believe that that resolves all the issues. I admit I do not know the formal requirements here (should we summon a cryptographer?), Maybe. This was discussed extensively about a year ago under the topic of "key separation". Some of that is in the TLS archives. I can provide some more detailed references offline if you like. but I find this claim puzzling. The Finished message is still encrypted with the TLS-level handshake keys. If our theoretical framework for TLS's security really cares about any additional encoding (which does not reuse any TLS-level keys) we add on top, I feel that framework needs work. Quite possibly. However, one of the design objectives was to build something which was readily analyzable with the tools we have. As I alluded to, some (though not all) of those tools are designed to analyze the handshake and record layer separately and so if you have to use the record layer keys to complete the handshake, then that is no longer possible. It's certainly true that the use of exporter keys to encrypt the Finished message does not threaten the security of the TLS handshake. What it does, as I understand it, is make it problematic to separately analyze the QUIC record layer from the TLS handshake (in the same way as encrypting the TLS handshake with the application layer record keys makes it problematic to analyze the TLS handshake separately from the TLS application layer, which is why TLS 1.3 is designed the way it is). Ah, I see. Thanks! There's the disconnect. The worry was it being difficult to analyze QUIC's record layer independent of the handshake, rather than the other way around. The inverse claim made no sense to me, but this one sounds more plausible. Going by this diagram, are we not already doing this? This suggests the Finished and EndOfEarlyData are encrypted with QUIC 1-RTT keys: https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#rfc.section.4.1 Yes. Apologies for not catching this sooner. -Ekr David -Ekr On Thu, Feb 2, 2017 at 4:53 PM, Martin Thomson wrote: On 3 February 2017 at 11:42, Jana Iyengar wrote: > That said, David Benjamin suggested a similar but different variant of Ekr's > idea earlier: we could simply include the Finished message (as an additional > STREAM frame) in all packets during the 1-RTT round, to ensure that any > packet that is received at the server includes the Finished message. A > caveat is that the Finished message would be encrypted under the 1-RTT key, > but that should be fine, right? As in, aggressively "retransmit" those stream 1 frames on every packet until any one of those packets is acknowledged? That works, and avoids having to design a way to cram two different levels of packet protection into the same packet. The rule would be "if you don't provide a client certificate, retransmit all unacknowledged stream 1 data in every packet you send". It's not a lot of bytes (about 40), so maybe that's an elegant solution. --001a1135c7b2c8cfe00547a26e7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Fri, Feb 3, 2017 at= 10:59 AM Eric Rescorla <ekr@rtfm.com> wrote:
<= /div>
On Fri, Feb 3, 2017 at 7:35 AM, David Benjamin <davidben@chromium.org> wrote:
On Fri, Feb 3, 2017 at 7:05 AM Eric Rescorla <ekr@rtfm.c= om> wrote:
Unfortunately, if you encrypt the Finished with the keys you then = use for traffic, this
breaks key separation, w= hich we went to quite some trouble to have (this is why
TLS 1.3 uses a different handshake key than traffic key.) H= owever, if you
combine my proposal with = David's, I believe that that resolves all the issues.

I admit I do not kno= w the formal requirements here (should we summon a cryptographer?),
<= /div>

Maybe. This was discussed extensively about a year ago under= the topic of "key separation".
Som= e of that is in the TLS archives. I can provide some more detailed referenc= es offline
if you like.

=C2=A0
but I find= this claim puzzling. The Finished message is still encrypted with the TLS-= level handshake keys. If our theoretical framework for TLS's security r= eally cares about any additional encoding (which does not reuse any TLS-lev= el keys) we add on top, I feel that framework needs work.
=

<= /div>
Quite possibly. However, one of the design objectives was to build somet= hing which was
readily analyzable with the to= ols we have. As I alluded to, some (though not all) of those
tools are designed to analyze the handshake and record laye= r separately and so if you
have to use the re= cord layer keys to complete the handshake, then that is no longer possible.=

It's certainly true that the use of exporter keys to encrypt= the Finished message does not
threaten the s= ecurity of the TLS handshake. What it does, as I understand it, is make
it problematic to separately analyze the QUIC re= cord layer from the TLS handshake
(in the sam= e way as encrypting the TLS handshake with the application layer record
keys makes it problematic to analyze the TLS han= dshake separately from the TLS
application la= yer, which is why TLS 1.3 is designed the way it is).

Ah, I see. Thanks! There's the disconnec= t. The worry was it being difficult to analyze QUIC's record layer inde= pendent of the handshake, rather than the other way around. The inverse cla= im made no sense to me, but this one sounds more plausible.


Going by this diagram, are we not already doing this? This suggests the= Finished and EndOfEarlyData are encrypted with QUIC 1-RTT keys:
https://quicwg.github.io/base-drafts/draft-ietf-quic-tls.html#rfc.s= ection.4.1

Yes. Apologies for not catching this soo= ner.

-Ekr




David<= /div>
<= div class=3D"gmail_quote m_7522622031895072056m_-4120164011416293916gmail-m= _8309976798964129816gmail_msg gmail_msg">
=C2= =A0
<= div dir=3D"ltr" class=3D"m_7522622031895072056m_-4120164011416293916gmail-m= _8309976798964129816gmail_msg gmail_msg">
-Ekr=


On Thu, Feb 2, 2017 at 4:53 PM, Mar= tin Thomson <mart= in.thomson@gmail.com> wrote:
On 3 February 2017 at 11:42, Jana Iyengar <jri@google= .com> wrote:
> That said, David Benjamin suggested a similar but different variant of= Ekr's
> idea earlier: we could simply include the Finished message (as an addi= tional
> STREAM frame) in all packets during the 1-RTT round, to ensure that an= y
> packet that is received at the server includes the Finished message. A=
> caveat is that the Finished message would be encrypted under the 1-RTT= key,
> but that should be fine, right?

As in, aggressively "retransmit" those stream 1 frames on = every packet
until any one of those packets is acknowledged?=C2=A0 That works, and
avoids having to design a way to cram two different levels of packet
protection into the same packet.

The rule would be "if you don't provide a client certificate,
retransmit all unacknowledged stream 1 data in every packet you send".=
It's not a lot of bytes (about 40), so maybe that's an elegant
solution.

--001a1135c7b2c8cfe00547a26e7d-- From nobody Fri Feb 3 08:45:17 2017 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 9F587129692 for ; Fri, 3 Feb 2017 08:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 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=-3.199, 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 Gbt714krPuQN for ; Fri, 3 Feb 2017 08:45:14 -0800 (PST) Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 07F19129691 for ; Fri, 3 Feb 2017 08:45:13 -0800 (PST) Received: by mail-ua0-x230.google.com with SMTP id y9so17808311uae.2 for ; Fri, 03 Feb 2017 08:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mMDS3UCKKrzBIRsKqqmxnaIU9txPM2jOb0jKPT1tccQ=; b=vf0/QMIldRYsj0ybK+tXMRIA2tPc9Q2DqezcWGx3YF5sdelKSyKngb19zWw/crW02a Ipomgk94AmC2FVAoLvQ9EXUhcGZIcpaFJeqbtRNv9LaW+p3JhJ3VishduAGakxhuYpH9 Da5qtkOLloEvAmPZFSJbWowi2I/c0gace+ERRbgmbhy8w4s6aJYPOLLK4xItU7Ch/gnv cSxBHhwlIvwa2uug5tYNWYdaXGIVi46mzJNkpKmreKTSHN2HC0lm+LoQaaUqBamFIa2V xMZyuLCY/4K4XJGRIT/gQZ8zHch6I4RprkIhVyFvKTjqRl/Q6CEKzAxBVD3vk7McGlJb TM0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mMDS3UCKKrzBIRsKqqmxnaIU9txPM2jOb0jKPT1tccQ=; b=ag7Mq1nqeaQStSKmzVhjcQzFh71OXk1RW+UVxIG0fSm9qSx9sEcs/lPPPxfHMlOY9M B+YypK/c/EwEiuauva4Ga1s3+a/RJUI95NjIOrDJEWa76pZp3KsWF5LDdouqi9xbNCCp 7F/NHpXbDj0E8LcjH854XmXxLNNvu067UpxibUfHZoAo0hHnfsvHed5gRE+rwGK0lGef s1y3/st7pxa9qyGyy8DtRIf55qDueV/GIl2NsuVFJ0YNZK369/C36Xji9uJ5qKzycZhG DG1JcOpOOOIndaghMMpu9uVrWDSg5LZpG4l/2GBoBlOk/gcZDfTE4ZWi74lnwrv1tjP3 9PcQ== X-Gm-Message-State: AIkVDXIslUavVBUPoe4M29cKjwmmxdNkiHeukvgvKny6QGg2go0YwQfgeDjErGzEUyem8ofh2odt2yZMIl9wKr3M X-Received: by 10.159.38.73 with SMTP id 67mr6188433uag.155.1486140312646; Fri, 03 Feb 2017 08:45:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Fri, 3 Feb 2017 08:45:11 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Fri, 3 Feb 2017 08:45:11 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: David Benjamin Content-Type: multipart/alternative; boundary=001a114950dc6cbff30547a30151 Archived-At: Cc: Eric Rescorla , Watson Ladd , Ian Swett , Dragana Damjanovic , IETF QUIC WG , Martin Thomson , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:45:15 -0000 --001a114950dc6cbff30547a30151 Content-Type: text/plain; charset=UTF-8 > > Quite possibly. However, one of the design objectives was to build > something which was > readily analyzable with the tools we have. As I alluded to, some (though > not all) of those > tools are designed to analyze the handshake and record layer separately > and so if you > have to use the record layer keys to complete the handshake, then that is > no longer possible. > > So there are tools that can analyze the handshake and record layer together? If so, why don't we employ those? I'd be interested in an analysis of TLS1.3 + QUIC anyways -- do we have folks who'd be willing to do this? --001a114950dc6cbff30547a30151 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Quite possibly. However, one of the design objectives was to build= something which was
readily analyzable with the tools we= have. As I alluded to, some (though not all) of those
tools are designed to analyze the handshake = and record layer separately and so if you
have to use the record layer keys to complete the handsha= ke, then that is no longer possible.

So there are tools = that can analyze the handshake and record layer together? If so, why don= 9;t we employ those? I'd be interested in an analysis of TLS1.3 + QUIC = anyways -- do we have folks who'd be willing to do this?
--001a114950dc6cbff30547a30151-- From nobody Fri Feb 3 08:57:46 2017 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 4C8CD129486 for ; Fri, 3 Feb 2017 08:57:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.199 X-Spam-Level: X-Spam-Status: No, score=-5.199 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=-3.199, 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 qARUazK6Eh_f for ; Fri, 3 Feb 2017 08:57:44 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 2B19812947A for ; Fri, 3 Feb 2017 08:57:44 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id 35so18074264uak.1 for ; Fri, 03 Feb 2017 08:57:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FtYfqPfBZ0yQbPMYbGY1LNrMmODm10Dl+XTuOxhIaDQ=; b=V9iUpAUSepgp6gl8KRJinLCPJqWS35lixMd9/pJapmbtvIdkit5nOEadohKsB1bdjP U/LRSz1FYTBrEP7UPJ13EOPSEzjZptbVPMbZPFghw8TLOfSlGjGP0hIY1FKeNNePb2L0 jBAUngDgUmZ+iAeFERzcFRKowtNP4hXhxOzyQBUjaLQybYYosPqTQQhSVovO+EZyP1UQ uvATHwqaVhHcuyxb+vp32BQyEFSbdVM2ImsNI+G8eTg9ChQFA7GmvOdh74XOh4HSJce8 t/7194s0HzzayCYqlP9LbpQ4VeXd1pbBmJBVwoTya6Lq00rlFjNKY3HUl1hwEV0/yNas zFEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FtYfqPfBZ0yQbPMYbGY1LNrMmODm10Dl+XTuOxhIaDQ=; b=O0bAT3CysVItGh30Jyq5b2sjfy0ydxWjjbcXGHfs94f3qWySSt0Jk5AlQqqKQksAlK SLbdV3UP6l1bPA/CGcf4iVi5oIUyzle457POU4pxU2Oi51iwYxAre5HhyYn1/A7uuZxO /H9CjO0MAfYGLfTjIyeZCRBL0a7x7yPo48Kp7pc4wBeqwAOCiDJ081t55FXJ3gW40VB3 tK2zfEF/vH+lTjhdq+yBnChPgU6xvxHfKlVovPKbmYRztMY2OKjaeAan6iHn6/yclX+V jN7yMui2NpIrDJQFwbez4PBIpzsYEMRTJDG/UceW8U52CgGv/CyI/NkZbQWET1wiTbMD S4mg== X-Gm-Message-State: AIkVDXInXvYwRPJJh/Bkm7WCMt4gTJmweAOLozrlnqWKGVy9vwfrGDJ+fg4+TuIEk6PO+tFZOBjLmKVVE2APYa2g X-Received: by 10.159.38.73 with SMTP id 67mr6214415uag.155.1486141062842; Fri, 03 Feb 2017 08:57:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Fri, 3 Feb 2017 08:57:42 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Fri, 3 Feb 2017 08:57:42 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: David Benjamin Content-Type: multipart/alternative; boundary=001a114950dc23b2290547a32e65 Archived-At: Cc: Eric Rescorla , Watson Ladd , Ian Swett , Dragana Damjanovic , IETF QUIC WG , Martin Thomson , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 16:57:45 -0000 --001a114950dc23b2290547a32e65 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 8:45 AM, Jana Iyengar wrote: > Quite possibly. However, one of the design objectives was to build >> something which was >> readily analyzable with the tools we have. As I alluded to, some (though >> not all) of those >> tools are designed to analyze the handshake and record layer separately >> and so if you >> have to use the record layer keys to complete the handshake, then that is >> no longer possible. >> >> > So there are tools that can analyze the handshake and record layer > together? If so, why don't we employ those? I'd be interested in an > analysis of TLS1.3 + QUIC anyways -- do we have folks who'd be willing to > do this? > Apologies for not being clear: I was asking about analyzing the handshake when we don't use the Finished message before using the 1-RTT keys in the case where there's no client authentication. That said, this is a bit of a bummer because of the possibility of HoL blocking, but I don't think this is a show stopper. We could simply say that the server MUST receive the Finished message before using the 1-RTT keys and come back to this when we have more analysis of the handshake. --001a114950dc23b2290547a32e65 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 3, 2017 at 8:45 AM, Jana Iyengar <jri@google.com> wrote= :
Quite possibly. However, one of th= e design objectives was to build something which was
readily analyzable with the tools we have. As I alluded to, some (though n= ot all) of those
tools are designed to analyze the handshake and record layer s= eparately and so if you
have to use the record layer keys to complete the hands= hake, then that is no longer possible.
=

So there a= re tools that can analyze the handshake and record layer together? If so, w= hy don't we employ those? I'd be interested in an analysis of TLS1.= 3 + QUIC anyways -- do we have folks who'd be willing to do this?
=

Apologies for not b= eing clear: I was asking about analyzing the handshake when we don't us= e the Finished message before using the 1-RTT keys in the case where there&= #39;s no client authentication.

<= div class=3D"gmail_extra">That said, this is a bit of a bummer because of t= he possibility of HoL blocking, but I don't think this is a show stoppe= r. We could simply say that the server MUST receive the Finished message be= fore using the 1-RTT keys and come back to this when we have more analysis = of the handshake.
--001a114950dc23b2290547a32e65-- From nobody Fri Feb 3 09:00:59 2017 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 17CA4129678 for ; Fri, 3 Feb 2017 09:00:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 mWWbD9Guqsr8 for ; Fri, 3 Feb 2017 09:00:57 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::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 0DAA2129458 for ; Fri, 3 Feb 2017 09:00:57 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id j82so7795095ybg.1 for ; Fri, 03 Feb 2017 09:00:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G8arkXFhsgCAlcg9+NtZn62VfCvx2rY9m7zx1EGtVcU=; b=cCvYcMwnB8vX/DdTNHadX4woCdFIkmt1QcSdGqVf8QroP+aS2/KdwGdUV9tD8nO0YK SzbYoToNWHJJ5Cc9J1whDFA3fQxALFwGppiLM53AZ3qqH6YR2M6wTPg9+ipSJn+JDk2C 74x9L6XNEo/143HEOJ3RByf2JO2fIgU1Vj8JOpt611I0Yvqa6Gy3kK3mpLR/FRr4A9NH RdDPsbbSGe2+irrOh+D0SW2ePkP7umxOhm4hJnfv37tI8lTezvFwtZ00qghE/XJIt1Ym c+GTYuJaTNvwMx2dxISVaBiRHaozLNv/dvO5xmlT2/uF2xZJh0LrYi7ASLLi6KN2457U 5Y0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G8arkXFhsgCAlcg9+NtZn62VfCvx2rY9m7zx1EGtVcU=; b=t+H2Tw81c8BmwbeWFzHD0AlCiA2mFDBowUj0uptDDpjPfydV1nhoSp/0JaEdwKvrZc mjfzteZgRkUfyzskbUuOGB6Z1zJ0VlF5OEQtJoKhPiqKwEU0BwEpfHRhOu7YIoo6kSfK Y0ba8GoQDdR+4+VjDMy+umIlZu9e5BY4I3xqskYq1nZB2OU7eOnPX2Lsm/CYOsaJbejG lVdTq1PhggnSnfOCSnBAckvJh16jrGKX1sqDBK0ANE1Y2XDaS4alFf+IuOPLihznjqq8 Jjw/0dxS4OMRhzw5qqP3I91VlAF8YQ3OcwhOMuF3ZJBF5wrI9FZ++BD5SWNuwpxCR/0j N2TA== X-Gm-Message-State: AIkVDXLfNO0/d6nXvuZkIydDUKLTRf9G6nlQUqaqFSNIzK9UTpzOcDdYIHLVOV1unP6wP1lzmm9d/07jaGQuZw== X-Received: by 10.37.14.69 with SMTP id 66mr6988515ybo.64.1486141255802; Fri, 03 Feb 2017 09:00:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Fri, 3 Feb 2017 09:00:14 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 3 Feb 2017 09:00:14 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a113e930ca3baf30547a33954 Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , David Benjamin , IETF QUIC WG , Martin Thomson , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:00:58 -0000 --001a113e930ca3baf30547a33954 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 8:45 AM, Jana Iyengar wrote: > Quite possibly. However, one of the design objectives was to build >> something which was >> readily analyzable with the tools we have. As I alluded to, some (though >> not all) of those >> tools are designed to analyze the handshake and record layer separately >> and so if you >> have to use the record layer keys to complete the handshake, then that is >> no longer possible. >> >> > So there are tools that can analyze the handshake and record layer > together? If so, why don't we employ those? I'd be interested in an > analysis of TLS1.3 + QUIC anyways -- do we have folks who'd be willing to > do this? > I may have given a confusing impression of the situation here. The state of play of analysis for this kind of protocol is that we have a bunch of different tools [0] that can analyze the protocol from different angles and together they give a sort of composite picture of the security of the system. Some of these tools do OK with combined analysis of handshake and record and some do not, but it's not like we just need to hit it with a bigger hammer and we'll know everything, at least not at the current level of available tooling. -Ekr [0] And some of these "tools" are just analysis methodology, not software. --001a113e930ca3baf30547a33954 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 3, 2017 at 8:45 AM, Jana Iyengar <jri@google.com> wrote= :
Quite possibly. However, on= e of the design objectives was to build something which was
readily analyzable with the tools we have. As I alluded to, som= e (though not all) of those
tools are designed to analyze the handshake and re= cord layer separately and so if you
have to use the record layer keys to compl= ete the handshake, then that is no longer possible.
=

So there are tools that can analyze the handshake and record layer toget= her? If so, why don't we employ those? I'd be interested in an anal= ysis of TLS1.3 + QUIC anyways -- do we have folks who'd be willing to d= o this?

I may have = given a confusing impression of the situation here.

The state of play of analysis for this kind of protocol is that we have a= bunch of different tools [0]
that can analyze the protocol from = different angles and together they give a sort of composite
pictu= re of the security of the system. Some of these tools do OK with combined a= nalysis of
handshake and record and some do not, but it's not= like we just need to hit it with a bigger
hammer and we'll k= now everything, at least not at the current level of available tooling.

-Ekr

[0] And some of these &= quot;tools" are just analysis methodology, not software.
=C2= =A0


=C2=A0

--001a113e930ca3baf30547a33954-- From nobody Fri Feb 3 09:05:17 2017 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 1BB2E129458 for ; Fri, 3 Feb 2017 09:05:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-3.199, 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 y0de2NKYoF3L for ; Fri, 3 Feb 2017 09:05:15 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 32A8B129669 for ; Fri, 3 Feb 2017 08:59:28 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id x75so16853619vke.2 for ; Fri, 03 Feb 2017 08:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pHAyu4aPPxrs/AB7Bg8B33etdkwmj9GRWFk1bM07X34=; b=P5t97hsiDS/1JtmtPGkPJ+ZN6xnZJX1yNbY7t8WpxGyCuMvpwC+nCz9xBOlZfXcVnR zmBiPgKhwKyWDhJl3bvX7sjm/HdCAgV9CSIX+alc5cThcTiUqGOLWoyiRQ40cAJTgM7m dd2WDTrSWZv6UEpwCw+8A+dNnBYszG6h32YdVN3RFxFJv06FKG1iVMZRfyYrHFBVwtL0 FSBig2rPB0Qr3sZROb7gQ/FyeuexQVxo5XgfFFIuJjxnRmipSunQ8h1vavPyp5nymah5 R8dCoippMfGjdjQlJVRnQkuHIWoS+9ym5UoX7cBd+CbhpLoyHtdAUR69CqE6A5ND/Qss L8TA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pHAyu4aPPxrs/AB7Bg8B33etdkwmj9GRWFk1bM07X34=; b=nYRZOYUW5btWvp445MTyrefDPog92UWCNrJj+v4FsglNvFpK8MM21GamW5+QgMwnto nNOgBpSGgOGKJUG6JqPDJvKPeZrH1SBacj4MDnFB/jU3zhYfwaZSZNeWphu+U7nuxU/t k5wgr0CVLRntu2bS/tvNs46npGHZUow+FgA9F5tVH094hflinfT9ucG9qTgtbxenKbkz ZTJvbTYWAxfIyjEd/3MWLMECpsUIjmIouKHqcX0K9Fa5Pu2vWp+kKUv+NYMOarE+prEG 7yWABncx6h1YEI+OJ22E/9jNnbCgKdXTlAtRiuqcmTIQIPsd9VQWntgEgjnHd443iPiS BLpQ== X-Gm-Message-State: AIkVDXLhl/Jg8zC1pBz4k06xQ0LDARtW97y/9O4OSb32kvAhmxXEqNHeksmNfHyXfZ+sskxYFmUw0gFXuXj6KFNO X-Received: by 10.31.107.74 with SMTP id g71mr5882695vkc.116.1486141167083; Fri, 03 Feb 2017 08:59:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Fri, 3 Feb 2017 08:59:26 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Fri, 3 Feb 2017 08:59:26 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: David Benjamin Content-Type: multipart/alternative; boundary=001a1147910059e8e60547a33473 Archived-At: Cc: Eric Rescorla , Watson Ladd , Ian Swett , Dragana Damjanovic , IETF QUIC WG , Martin Thomson , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:05:16 -0000 --001a1147910059e8e60547a33473 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 8:57 AM, Jana Iyengar wrote: > On Fri, Feb 3, 2017 at 8:45 AM, Jana Iyengar wrote: > >> Quite possibly. However, one of the design objectives was to build >>> something which was >>> readily analyzable with the tools we have. As I alluded to, some (though >>> not all) of those >>> tools are designed to analyze the handshake and record layer separately >>> and so if you >>> have to use the record layer keys to complete the handshake, then that >>> is no longer possible. >>> >>> >> So there are tools that can analyze the handshake and record layer >> together? If so, why don't we employ those? I'd be interested in an >> analysis of TLS1.3 + QUIC anyways -- do we have folks who'd be willing to >> do this? >> > > Apologies for not being clear: I was asking about analyzing the handshake > when we don't use the Finished message before using the 1-RTT keys in the > case where there's no client authentication. > > That said, this is a bit of a bummer because of the possibility of HoL > blocking, but I don't think this is a show stopper. We could simply say > that the server MUST receive the Finished message before using the 1-RTT > keys and come back to this when we have more analysis of the handshake. > ... and we can add ekr's+davidben's modification as a potential optimization that a client could employ. --001a1147910059e8e60547a33473 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 3, 2017 at 8:57 AM, Jana Iyengar <jri@google.com> wrote= :
On Fri, Feb 3, 2017 = at 8:45 AM, Jana Iyengar <jri@google.com> wrote:
Quite possibly. However, one of the design objectives wa= s to build something which was
readily = analyzable with the tools we have. As I alluded to, some (though not all) o= f those
tools are designed to analyze the handshake and r= ecord layer separately and so if you
have to use the reco= rd layer keys to complete the handshake, then that is no longer possible.

So there are tools that can analyze the handshake = and record layer together? If so, why don't we employ those? I'd be= interested in an analysis of TLS1.3 + QUIC anyways -- do we have folks who= 'd be willing to do this?

Apologi= es for not being clear: I was asking about analyzing the handshake when we = don't use the Finished message before using the 1-RTT keys in the case = where there's no client authentication.

That said, this is a bit of a bummer = because of the possibility of HoL blocking, but I don't think this is a= show stopper. We could simply say that the server MUST receive the Finishe= d message before using the 1-RTT keys and come back to this when we have mo= re analysis of the handshake.

... and we can add = ekr's+davidben's modification as a potential optimization that a cl= ient could employ.
--001a1147910059e8e60547a33473-- From nobody Fri Feb 3 09:07:14 2017 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 E822E129463 for ; Fri, 3 Feb 2017 09:07:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.198 X-Spam-Level: X-Spam-Status: No, score=-5.198 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=-3.199, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 uk12SuZXilvr for ; Fri, 3 Feb 2017 09:07:11 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 AA6DC129449 for ; Fri, 3 Feb 2017 09:07:11 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id y9so18299173uae.2 for ; Fri, 03 Feb 2017 09:07:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WyBc9k/G4MXPh9GcTFmrpoEMQAlxQvPJgU7VD6X7TJU=; b=aZgWmfinZOGXiDe8qhqvo4wzHr+z7dE03lVOtv8rW9qljY53iobp27ECnUI1E5Gby0 j6rNLYq8Wn25C+l5wgtpO+qmUGeFfX3+f1oSSeed82kk0PU3F/1aSSuTk65dpVDndwpo gxX3ZnIL9HUmx0sg1ltiFGI7CCfHsuYbqCCli6FZQuYjCimUpT2izX5hxbSdUbgJp2O0 eWB6iZFFG6HWCI4JbEjztmIEMfOHz7RGoRo4FgD2fVmkwUsdjpbnBK66LkkA9K+hMbZy Qkmd9pmtgjXl/Fv9x7qTcyVpHl9cQGLWu7jAlQB99aT+Xsx3ysz6a6U85/8nEmTK6XvH TVHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WyBc9k/G4MXPh9GcTFmrpoEMQAlxQvPJgU7VD6X7TJU=; b=XnDXI4QwEi+R+X23YX+ZfmIDFjpsuAYlCi+UTFjHSVgr3UsQtI8J6L6KryTESc6RfR oVsITCmcr8GweRfkEvxedu5Ax1Bto99cF8EtIZ6JRPhhjoitQJNBsp0cZW8/piGqNroh oiAfCVSTRDLohD5kBf/3RqK9oInY94JODsoiGYBPF7NDED5Zmf/h4bT38Fv7Ko15LSsu tba8U2lnZWfiaLZFrDYB217xBji68vkTxhqcF7oQ+6QaI21DB0fKjqF5HyaoCUlWEGNa DQIi+KGXK7/9+EXnXYDluHuvTmx/vXlTMNarBeye+PWCXE/kMZr2r223qOY0xG/rVe5L /Hsg== X-Gm-Message-State: AIkVDXJHuM2FCrv5Ygl68/CTjZslzK5lJFV2yD3uUOvYLf2/0AS9GfVkTuOUYOkSBZ9rScCwBFX0+LcT4UpRcAaQ X-Received: by 10.176.83.153 with SMTP id k25mr6378225uaa.141.1486141630462; Fri, 03 Feb 2017 09:07:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Fri, 3 Feb 2017 09:07:09 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Fri, 3 Feb 2017 09:07:09 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: Eric Rescorla Content-Type: multipart/alternative; boundary=f403045dd7ecf8fd400547a34f12 Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , David Benjamin , IETF QUIC WG , Martin Thomson , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 17:07:13 -0000 --f403045dd7ecf8fd400547a34f12 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 3, 2017 at 9:00 AM, Eric Rescorla wrote: > On Fri, Feb 3, 2017 at 8:45 AM, Jana Iyengar wrote: > >> Quite possibly. However, one of the design objectives was to build >>> something which was >>> readily analyzable with the tools we have. As I alluded to, some (though >>> not all) of those >>> tools are designed to analyze the handshake and record layer separately >>> and so if you >>> have to use the record layer keys to complete the handshake, then that >>> is no longer possible. >>> >>> >> So there are tools that can analyze the handshake and record layer >> together? If so, why don't we employ those? I'd be interested in an >> analysis of TLS1.3 + QUIC anyways -- do we have folks who'd be willing to >> do this? >> > > I may have given a confusing impression of the situation here. > > The state of play of analysis for this kind of protocol is that we have a > bunch of different tools [0] > that can analyze the protocol from different angles and together they give > a sort of composite > picture of the security of the system. Some of these tools do OK with > combined analysis of > handshake and record and some do not, but it's not like we just need to > hit it with a bigger > hammer and we'll know everything, at least not at the current level of > available tooling. > Gotcha -- thanks for clarifying. It seems like we probably want to go forward with requiring Finished and not encrypting it with 1-RTT keys then. Does that sound right? - jana > -Ekr > > [0] And some of these "tools" are just analysis methodology, not software. > > > > > > --f403045dd7ecf8fd400547a34f12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 3, 2017 at 9:00 AM, Eric Rescorla <ekr@rtfm.com> wrote:
On Fri, Feb 3, 2017 at 8:45 A= M, Jana Iyengar <jri@google.com> wrote:
<= div dir=3D"ltr">
<= blockquote class=3D"gmail_quote m_-2369287708377545351m_4370479663985021680= m_6286091209518275386gmail_msg" style=3D"margin:0 0 0 .8ex;border-left:1px = #ccc solid;padding-left:1ex">
Quite possibly. However, one = of the design objectives was to build something which was
=
readily analyzable with the tools we have. As I allu= ded to, some (though not all) of those
tools are designe= d to analyze the handshake and record layer separately and so if you
<= div class=3D"m_-2369287708377545351m_4370479663985021680m_62860912095182753= 86gmail_msg">have to use the record layer keys to complete the handshake, t= hen that is no longer possible.
<= /div>

So there are tool= s that can analyze the handshake and record layer together? If so, why don&= #39;t we employ those? I'd be interested in an analysis of TLS1.3 + QUI= C anyways -- do we have folks who'd be willing to do this?
<= /div>

I may have given a = confusing impression of the situation here.

The st= ate of play of analysis for this kind of protocol is that we have a bunch o= f different tools [0]
that can analyze the protocol from differen= t angles and together they give a sort of composite
picture of th= e security of the system. Some of these tools do OK with combined analysis = of
handshake and record and some do not, but it's not like we= just need to hit it with a bigger
hammer and we'll know ever= ything, at least not at the current level of available tooling.
=

Gotcha -- thanks for clarifyin= g. It seems like we probably want to go forward with requiring Finished and= not encrypting it with 1-RTT keys then. Does that sound right?
<= br>
- jana
=C2=A0
<= div dir=3D"ltr">
= -Ekr

[0] And some of these "tools" are j= ust analysis methodology, not software.
=C2=A0


=C2=A0


--f403045dd7ecf8fd400547a34f12-- From nobody Fri Feb 3 22:08:03 2017 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 E26041294A1 for ; Fri, 3 Feb 2017 22:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.899 X-Spam-Level: X-Spam-Status: No, score=-5.899 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=-3.199, 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 tE7WjQnRide9 for ; Fri, 3 Feb 2017 22:08:00 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::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 A15D3129488 for ; Fri, 3 Feb 2017 22:08:00 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id w20so60891802qtb.1 for ; Fri, 03 Feb 2017 22:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HxKABbTTB9wc4upmVznWleP1PcBLG2E/hsCAEfDgYLQ=; b=qsgGBmqZJlUs1+h4br7Vp6xHJ5PrrfcLJxizJ9InARSofalFP9Y5RHJzi2BG2u/nWS mabetHXr7QcY9tcoilGSP8E53O8FUwtb1Pf8U/2Ljj9fyWxyfIRIyaeUB5GkjGx4Nm04 yPG3OsTRnOcHUBWiWgEJpO81G7WlNs/GC/8S25AyzgJ3nAiys7odALxF7Q4PJhirxZbb KuSux66vbLghnzd0tvKypBNsEStz7SudM8KrbqCL6SL5UEplaevhk5T+gwZq2MwKWPGK 2Yaj6MTYovxe5OXqq/CzDUelP14TDf8IFdHYxx7jJsRr/woC41Qmhd5SEz850IGLO1gD vonQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HxKABbTTB9wc4upmVznWleP1PcBLG2E/hsCAEfDgYLQ=; b=hTTznEFEP3Qwt3TxFX2oWWbJq5iJL2gV+cqqptoJq8Ts2Uy1d/xUQRfoui+J9WgkKs XHd+zEFCANT6YsmPjy/KvPVVXVM3SyOAwJwLoQwo478AwZ+Hf4MGk+bZoI87gOE3IoQ3 PLCMjWZV0NC3oS2FgIXSen7Z8pFBA4ZjbZ7LOEBpTtEZfNx/TKfUy7KFL26hFWhUQbN1 2ONx/dnf43WpMifxP3GzsTU4m5b6UE7WPMc7SvGAXJeejRYnqwRWqwe8ZEA+pEcaMtcq suZCIvPECUd6KK2ytqzfTiWMESeZjOlgxi4hodtRmTMAkuo/KiqlhAiUElSlhr1vIRT7 plgw== X-Gm-Message-State: AMke39kRtuwPOqc4z8++FjXH5czDuLSOOstmUyycZv8tWLGbpwDeUqmsiIbL77ZGEeC2AzR3UHGgtHwyiUWoob2Q X-Received: by 10.237.37.185 with SMTP id x54mr573690qtc.256.1486188479481; Fri, 03 Feb 2017 22:07:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.47.4 with HTTP; Fri, 3 Feb 2017 22:07:58 -0800 (PST) In-Reply-To: References: From: Victor Vasiliev Date: Sat, 4 Feb 2017 01:07:58 -0500 Message-ID: Subject: Re: Performance/safety trade-off To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a113f495a63e0340547ae3880 Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , Jana Iyengar , IETF QUIC WG , Martin Thomson , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 06:08:03 -0000 --001a113f495a63e0340547ae3880 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thank you for the analysis. I was trying to write my own, but yours is better than what I would end up writing anyways :) I am still not entirely convinced of the "handshake should not depend on record layer" approach. Security of QUIC+TLS depends on (1) handshake being secure, and (2) record layer being secure provided the keys derived from the handshake. If we are not sure our record layer provides the security guarantees that w= e want, that would be very concerning. If there are pieces other than the handshake and the record layer, their security has to be verified independently anyways. So I would not be that hesitant to rely on record layer security assumptions. Now, since (1) the client and the server are the only parties which know the secret, (2) the client traffic key is only used by the client, (3) the AEAD data is protected by a MAC, and (4) the MAC used is at least weakly unforgeable, receiving any message authenticated with the MAC from the client proves tha= t client possesses the same key as the server. Of course, this is not *strictly* equivalent to the Finished message since the Finished message is an HMAC of the entire handshake with a somewhat different key (actually, it's MAC'd twice with different similarly-derived keys, but let's not talk about this). Still, this does confirm key possession, and unless you are concerned that your MAC could have been downgraded to something insecure during the handshake while the HMAC is still secure (which I assume is an issue for the security analysis of th= e protocol anyways, since the same AEAD scheme protects your handshake), I don't really see how confirming the key via a MAC existing is worse than confirming the key via a MAC of the handshake. The exporter key is derived from the same transcript that is being MAC'd in the Finished message, so if the client derives the same key, it has seen the same handshake. I do agree that it would be really nice to reuse the existing formal analysis, if only for the fact that I wouldn't want to formalize the paragraph above myself :) Yet from a pragmatic engineering perspective, since I do not expect formal code verification to be widespread in QUIC libraries for the foreseeable future, the simplicity of the implementation (both in terms of wire protocol and prescribed behavior) should be prioritized over the simplicity of the proofs. This thread has had some interesting workarounds for the HOL blocking issue, but they all sound overly complicated for solving a problem which might not be that much of an issue given that: (1) It's not clear HOL blocking is a noticeable performance hit here. I seem to recall we used to have a similar problem with SHLO loss, and concluded that the workaround was not really worth it. (2) It's not clear that not waiting for client Finished is actually depriving us of any security guarantees TLS normally promises (as far as I have read, it never explicitly promises aliveness verification for the peer). (3) It's not clear that the protocol does not provide the desired extra security properties as-is via the record layer. These three points together make me feel like adding an extra packet format variation just to deal with client Finished HOL blocking is somewhat far-fetched at this point. On Thu, Feb 2, 2017 at 7:01 PM, Eric Rescorla wrote: > Sorry for the delay. It's been a long week of meetings. > > Here's my understanding of the situation, focusing on the one-way > authentication version of TLS; I think we all agree that in the > mutually authenticated version, the server needs to wait for the > client's Finished. > > The scenario of interest here is one where the server has sent > its complete flight and then receives an AEAD-encrypted message > from the client in advance of receiving the client's Finished > (which we can model as a handshake without a client Finished). > > Informally, there are two potential properties we might be interested > in here: > > 1. The integrity of the handshake. > 2. "Key confirmation", namely a demonstration that there is a > counterparty on the other side who knows the key. Note that > this is somewhat complicated by PSK-resumption, but for > now consider the full handshake with DHE. > > One important consideration is that we would like to be able to > establish these properties only with reference to the handshake, > without relying on the record layer. This allows you to analyze the > handshake and then compose it with an arbitrary record layer, rather > than relying on the type of combined analysis that was necessary for > TLS 1.2. Indeed, that's what we're doing with QUIC, where we are using > a record layer that's slightly different from that in TLS 1.3. With > that in mind, upon receiving the client's Finished, the server knows > that the (anonymous) entity which sent it the ClientHello actually > knew the corresponding private DHE share and that the handshake was > un-tampered. Note that this guarantee would apply even if the > handshake were entirely unencrypted and indeed even if AES-GCM (for > instance) were completely broken. Of course, you still don't know who > you are talking to. > > Krawczyk and Wee show in [0] that you actually get a secure one-way > protocol even if the client doesn't send a Finished > message. Intuitively, the server signs and MACs the entire transcript, > so any tampering is detected at the client and the client will not > accept the handshake unless it is un-tampered, so the client will also > not accept data from the server or send data to the server. The server > can of course send 0.5 RTT data, but as it doesn't know who the client > is, any tampering is largely irrelevant (See below for the resumption > case). Here's what Krawczyk and Wee say: > > TLS 1.3 include s a mandatory third message in the handshake in > which the client sends a MAC value (client=E2=80=99s Finished) computed= on > the prior transcript similar to the one sent by the server in the > second message. As our analysis shows this is not needed for the > basic key exchange security in the case of server-only > authentication. Yet, this message serves several purposes that are > valuable in the TLS 1.3 setting. It serves as the confirmation from > the client that both server and client have the same view of the > transcript, including keying material, server identity and > negotiated security parameters (part of the hello > messages). Interestingly, the sending of this message has been shown > in [21] to =E2=80=9Cupgrade" security from the indistinguishability-bas= ed > model we use here to universally-composable security. > > Without the Finished, the server only gets any confirmation that the > client has the same view when it decrypts the client's first message. > However, as I said, you only get this property via the record layer, > which means that your analysis now needs to take that into account, > whereas if you have the Finished you can get key confirmation purely > by analyzing the handshake. Now, as Watson says, there's a pretty > straight line from "received AEAD-encrypted data from the client" to > "client successfully completed the handshake", but it's not the > cleanest analytical situation. > > The situation seems a bit more complicated when you are doing > resumption because now you actually care about talking to a specific > counterparty, especially if you have attached state information the > the ticket/PSK pair. I don't believe that this mostly matters in the > Krawczyk/Wee analysis, except that it's important not to over-commit > to what you know prior to receiving any information from the client's > second flight. Specifically, until you receive either Finished or some > AEAD-encrypted data, you don't know that you have a fresh connection > from the client as opposed to a replayed CH. That's generally true in > the full 1-RTT case, you just don't care because the clients are > interchangeable. > > With all that said, the situation really is a lot cleaner if we leave > the Finished in place (that's why it's there after all), so I'd like > to spend some time seeing if we can do that. > > It occurs to me that perhaps there's a way to improve Martin's hacky > #2 version where we don't encrypt the Finished. Specifically, we're > already discussing having a much longer header for "special" packets, > which this would be. If we simply decree that special packets also > have an explicit length rather than extending them to the end of the > UDP datagram, then we can pack multiple packets into a datagram, which > lets you send the Finished and requests together, albeit with a little > bit of overhead in terms of headers. > > -Ekr > > > [0] http://eprint.iacr.org/2015/978.pdf > > > On Thu, Feb 2, 2017 at 8:53 PM, Stephen Farrell > wrote: > >> >> >> On 02/02/17 16:48, Jana Iyengar wrote: >> > None of us are cryptographers, so I'd like to recommend that we pull i= n >> one >> > before we go one way or the other. Can anyone pull in a cryptographer? >> > Hugo, perhaps? >> >> Someone could also craft the question carefully and send it to cfrg >> asking for opinions. Asking informally will probably be enough but >> sometimes WGs ask more formally (via their chairs) which tends to >> ensure someone does send an answer, but is generally slower. >> >> S >> >> >> > >> > On Wed, Feb 1, 2017 at 4:29 PM, Ian Swett wrote: >> > >> >> So TLDR; >> >> 1) Yes, we'd like to decrypt 1RTT packets before the confirmation is >> >> received for all the reasons above. >> >> 2) It's not absolutely critical to QUIC's existence >> >> 3) We need to ask cryptographers, who are likely not on this thread. >> >> 4) If it is sufficient, it'd be nice to never send the finished >> message, >> >> since that creates two ways a handshake can complete(and sends an ext= ra >> >> packet). >> >> >> >> On Wed, Feb 1, 2017 at 7:17 PM, Martin Thomson < >> martin.thomson@gmail.com> >> >> wrote: >> >> >> >>> On 2 February 2017 at 09:12, Ian Swett wrote: >> >>>> Ok, so the question(which I can't answer), is whether encrypting da= ta >> >>> with >> >>>> the resulting keys could be considered functionally equivalent to k= ey >> >>>> confirmation? >> >>> >> >>> This is the crux of the thread. As Watson observes, the answer is >> >>> probably yes. But we don't have a proof that confirms that. Analys= is >> >>> of TLS has mostly kept handshake and record protection separate. >> >>> >> >> >> >> >> > >> >> > --001a113f495a63e0340547ae3880 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you for the analysis.=C2=A0 I was trying to wri= te my own, but yours is better
than what I would end up writing a= nyways :)

I am still not entirely convinced of the= "handshake should not depend on record
layer" approach= .=C2=A0 Security of QUIC+TLS depends on (1) handshake being secure,
and (2) record layer being secure provided the keys derived from the han= dshake.
If we are not sure our record layer provides the security= guarantees that we
want, that would be very concerning.=C2=A0 If= there are pieces other than the
handshake and the record layer, = their security has to be verified independently
anyways.=C2=A0 So= I would not be that hesitant to rely on record layer security
as= sumptions.

Now, since
=C2=A0 (1) the cli= ent and the server are the only parties which know the secret,
= =C2=A0 (2) the client traffic key is only used by the client,
=C2= =A0 (3) the AEAD data is protected by a MAC, and
=C2=A0 (4) the M= AC used is at least weakly unforgeable,
receiving any message aut= henticated with the MAC from the client proves that
client posses= ses the same key as the server.=C2=A0 Of course, this is not *strictly*
equivalent to the Finished message since the Finished message is an = HMAC of the
entire handshake with a somewhat different key (actua= lly, it's MAC'd twice with
different similarly-derived ke= ys, but let's not talk about this).=C2=A0 Still, this
does co= nfirm key possession, and unless you are concerned that your MAC could
have been downgraded to something insecure during the handshake while= the HMAC
is still secure (which I assume is an issue for the sec= urity analysis of the
protocol anyways, since the same AEAD schem= e protects your handshake), I don't
really see how confirming= the key via a MAC existing is worse than confirming
the key via = a MAC of the handshake. The exporter key is derived from the same
transcript that is being MAC'd in the Finished message, so if the clie= nt
derives the same key, it has seen the same handshake.

I do agree that it would be really nice to reuse the exist= ing formal analysis,
if only for the fact that I wouldn't wan= t to formalize the paragraph above myself :)
Yet from a pragmatic= engineering perspective, since I do not expect formal code
verif= ication to be widespread in QUIC libraries for the foreseeable future, the<= /div>
simplicity of the implementation (both in terms of wire protocol = and prescribed
behavior) should be prioritized over the simplicit= y of the proofs.=C2=A0 This thread
has had some interesting worka= rounds for the HOL blocking issue, but they all
sound overly comp= licated for solving a problem which might not be that much of
an = issue given that:
=C2=A0 (1) It's not clear HOL blocking is a= noticeable performance hit here.=C2=A0 I seem
=C2=A0 =C2=A0 =C2= =A0 to recall we used to have a similar problem with SHLO loss, and conclud= ed
=C2=A0 =C2=A0 =C2=A0 that the workaround was not really worth = it.
=C2=A0 (2) It's not clear that not waiting for client Fin= ished is actually depriving
=C2=A0 =C2=A0 =C2=A0 us of any securi= ty guarantees TLS normally promises (as far as I have
=C2=A0 =C2= =A0 =C2=A0 read, it never explicitly promises aliveness verification for th= e peer).
=C2=A0 (3) It's not clear that the protocol does not= provide the desired extra
=C2=A0 =C2=A0 =C2=A0 security properti= es as-is via the record layer.
These three points together make m= e feel like adding an extra packet format
variation just to deal = with client Finished HOL blocking is somewhat
far-fetched at this= point.


On Thu, Feb 2, 2017 at 7:01 PM, Eric Rescorla = <ekr@rtfm.com><= /span> wrote:
Sorry= for the delay. It's been a long week of meetings.

=
Here's my understanding of the situation, focusing on the one-way<= /div>
authentication version of TLS; I think we all agree that in the
mutually authenticated version, the server needs to wait for the
client's Finished.

The scenario of in= terest here is one where the server has sent
its complete flight = and then receives an AEAD-encrypted message
from the client in ad= vance of receiving the client's Finished
(which we can model = as a handshake without a client Finished).

Informa= lly, there are two potential properties we might be interested
in= here:

1. The integrity of the handshake.
2. "Key confirmation", namely a demonstration that there is a
=C2=A0 =C2=A0counterparty on the other side who knows the key. Not= e that
=C2=A0 =C2=A0this is somewhat complicated by PSK-resumptio= n, but for
=C2=A0 =C2=A0now consider the full handshake with DHE.=
=C2=A0 =C2=A0
One important consideration is that we w= ould like to be able to
establish these properties only with refe= rence to the handshake,
without relying on the record layer. This= allows you to analyze the
handshake and then compose it with an = arbitrary record layer, rather
than relying on the type of combin= ed analysis that was necessary for
TLS 1.2. Indeed, that's wh= at we're doing with QUIC, where we are using
a record layer t= hat's slightly different from that in TLS 1.3.=C2=A0 With
tha= t in mind, upon receiving the client's Finished, the server knows
=
that the (anonymous) entity which sent it the ClientHello actually
knew the corresponding private DHE share and that the handshake was<= /div>
un-tampered. Note that this guarantee would apply even if the
handshake were entirely unencrypted and indeed even if AES-GCM (for<= /div>
instance) were completely broken. Of course, you still don't = know who
you are talking to.

Krawczyk an= d Wee show in [0] that you actually get a secure one-way
protocol= even if the client doesn't send a Finished
message. Intuitiv= ely, the server signs and MACs the entire transcript,
so any tamp= ering is detected at the client and the client will not
accept th= e handshake unless it is un-tampered, so the client will also
not= accept data from the server or send data to the server. The server
can of course send 0.5 RTT data, but as it doesn't know who the clie= nt
is, any tampering is largely irrelevant (See below for the res= umption
case). Here's what Krawczyk and Wee say:
=C2=A0 TLS 1.3 include s a mandatory third message in the hand= shake in
=C2=A0 which the client sends a MAC value (client=E2=80= =99s Finished) computed on
=C2=A0 the prior transcript similar to= the one sent by the server in the
=C2=A0 second message. As our = analysis shows this is not needed for the
=C2=A0 basic key exchan= ge security in the case of server-only
=C2=A0 authentication. Yet= , this message serves several purposes that are
=C2=A0 valuable i= n the TLS 1.3 setting. It serves as the confirmation from
=C2=A0 = the client that both server and client have the same view of the
= =C2=A0 transcript, including keying material, server identity and
=C2=A0 negotiated security parameters (part of the hello
=C2=A0 = messages). Interestingly, the sending of this message has been shown
<= div>=C2=A0 in [21] to =E2=80=9Cupgrade" security from the indistinguis= hability-based
=C2=A0 model we use here to universally-composable= security.

Without the Finished, the server only g= ets any confirmation that the
client has the same view when it de= crypts the client's first message.
However, as I said, you on= ly get this property via the record layer,
which means that your = analysis now needs to take that into account,
whereas if you have= the Finished you can get key confirmation purely
by analyzing th= e handshake. Now, as Watson says, there's a pretty
straight l= ine from "received AEAD-encrypted data from the client" to
<= div>"client successfully completed the handshake", but it's n= ot the
cleanest analytical situation.

Th= e situation seems a bit more complicated when you are doing
resum= ption because now you actually care about talking to a specific
c= ounterparty, especially if you have attached state information the
the ticket/PSK pair. I don't believe that this mostly matters in the<= /div>
Krawczyk/Wee analysis, except that it's important not to over= -commit
to what you know prior to receiving any information from = the client's
second flight. Specifically, until you receive e= ither Finished or some
AEAD-encrypted data, you don't know th= at you have a fresh connection
from the client as opposed to a re= played CH. That's generally true in
the full 1-RTT case, you = just don't care because the clients are
interchangeable.

With all that said, the situation really is a lot clea= ner if we leave
the Finished in place (that's why it's th= ere after all), so I'd like
to spend some time seeing if we c= an do that.

It occurs to me that perhaps there'= ;s a way to improve Martin's hacky
#2 version where we don= 9;t encrypt the Finished. Specifically, we're
already discuss= ing having a much longer header for "special" packets,
= which this would be. If we simply decree that special packets also
have an explicit length rather than extending them to the end of the
UDP datagram, then we can pack multiple packets into a datagram, whic= h
lets you send the Finished and requests together, albeit with a= little
bit of overhead in terms of headers.

=
-Ekr




On Thu, F= eb 2, 2017 at 8:53 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie<= /a>> wrote:


On 02/02/17 16:48, Jana Iyengar wrote:
> None of us are cryptographers, so I'd like to recommend that we pu= ll in one
> before we go one way or the other. Can anyone pull in a cryptographer?=
> Hugo, perhaps?

Someone could also craft the question carefully and send it to cfrg<= br> asking for opinions. Asking informally will probably be enough but
sometimes WGs ask more formally (via their chairs) which tends to
ensure someone does send an answer, but is generally slower.

S


>
> On Wed, Feb 1, 2017 at 4:29 PM, Ian Swett <ianswett@google.com> wrote:
>
>> So TLDR;
>>=C2=A0 1) Yes, we'd like to decrypt 1RTT packets before the con= firmation is
>> received for all the reasons above.
>>=C2=A0 2) It's not absolutely critical to QUIC's existence<= br> >>=C2=A0 3) We need to ask cryptographers, who are likely not on this= thread.
>>=C2=A0 4) If it is sufficient, it'd be nice to never send the f= inished message,
>> since that creates two ways a handshake can complete(and sends an = extra
>> packet).
>>
>> On Wed, Feb 1, 2017 at 7:17 PM, Martin Thomson <martin.thomson@gmail.com= >
>> wrote:
>>
>>> On 2 February 2017 at 09:12, Ian Swett <ianswett@google.com> wrote: >>>> Ok, so the question(which I can't answer), is whether = encrypting data
>>> with
>>>> the resulting keys could be considered functionally equiva= lent to key
>>>> confirmation?
>>>
>>> This is the crux of the thread.=C2=A0 As Watson observes, the = answer is
>>> probably yes.=C2=A0 But we don't have a proof that confirm= s that.=C2=A0 Analysis
>>> of TLS has mostly kept handshake and record protection separat= e.
>>>
>>
>>
>



--001a113f495a63e0340547ae3880-- From nobody Sat Feb 4 01:09:56 2017 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 EC26B12957A for ; Sat, 4 Feb 2017 01:09:54 -0800 (PST) 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 iTfOyp-b_o_z for ; Sat, 4 Feb 2017 01:09:53 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 AECBB1293DF for ; Sat, 4 Feb 2017 01:09:53 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id s140so13548520qke.0 for ; Sat, 04 Feb 2017 01:09:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eB0bD/eADjQFTbDXlYX4fGUtTkTndbkmIDk/nLO3NDA=; b=WVDs1Aj0+VsuEoshEtz9BbX6jPttUw3e9Roj5liZOXxre7C3DtV4bMf4mwtTXifvxX Oejz1wlZc0SaoE4k9ddNKWuHDoyempamwLR8gets2U90iw4nfq2HeOyHANp0ewWgC4X4 tLtCATt0EjF5ijOeA7lUUJg1DNr85NgeUrEp52UiIegETxQk1iBz12D5Jy/lsbACuZII Aa1YIWkDOChKKqDr15n8oBCS3WAkjKNKER3o0TGoSJeViTsMpY+yHPK8Y+deBd0b56I1 6Ji3Y/uAWvvXXCAoFvj7L/EFXkNiMMkf7RC+aVmnQTgk9oF8KSv6IqKYo4SpbPvrtZe/ FDDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eB0bD/eADjQFTbDXlYX4fGUtTkTndbkmIDk/nLO3NDA=; b=dcywdJrd5OONBBXXcKx/Jsw+4RHVoZ3ldVAYA4C3PW9O7nrxC7k/4AAAfz6bDkCWsL At6DC6qcv+wB1tdALSUi8ttEPrrigLFoQyWFpyc76Z3Bh8P3YcQGf5CMs8rxgSQ+8wji JX3u/GLcOvC95m1JjJTflo7ObITV3qr2s3eDVffo89ZdgPUji8Rf/92Q/fhaltDhNAFO JNYAFykNym72UTwKo1B1kYQ3oZBbfRqHccaQNdaJIHbR5gbYltINqG8Olsmns7Qa1qvT L+ckY0LQhoWPOBXRxFYUHwVoiAwa4zbiB3QubrurGzOy6wvdDIrL8EfWA6cBCuYWWIUj m7Ig== X-Gm-Message-State: AMke39l0m9dJH/pKsyILArazVAdQHcE+gCAgNtteduKxvC08IOHLNnE0tRQgQg5SX7rStbPyNIHRB0V/+ALKCQ== X-Received: by 10.233.235.66 with SMTP id b63mr1074556qkg.144.1486199392751; Sat, 04 Feb 2017 01:09:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Sat, 4 Feb 2017 01:09:51 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Sat, 4 Feb 2017 20:09:51 +1100 Message-ID: Subject: Re: Performance/safety trade-off To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Watson Ladd , Ian Swett , Dragana Damjanovic , Jana Iyengar , IETF QUIC WG , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2017 09:09:55 -0000 On 3 February 2017 at 23:04, Eric Rescorla wrote: > Unfortunately, if you encrypt the Finished with the keys you then use for > traffic, this > breaks key separation, which we went to quite some trouble to have (this is > why > TLS 1.3 uses a different handshake key than traffic key.) *facepalm* of course. > However, if you > combine my proposal with David's, I believe that that resolves all the > issues. That's not so simple. We'll have to be very careful with this one. I have an idea, but it depends on having "special packets" more fully fleshed out. From nobody Mon Feb 6 11:25:16 2017 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 95AF21294BA for ; Mon, 6 Feb 2017 11:25:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f5kxfmiI2QIR for ; Mon, 6 Feb 2017 11:25:12 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7805D129471 for ; Mon, 6 Feb 2017 11:25:12 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id s186so65723051qkb.1 for ; Mon, 06 Feb 2017 11:25:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3X4XYo9RgxVa04TE1Qq9SfxdTeNFRSUWAgNURH01Abw=; b=atz1h4iuvAlfZawEE4sJBtIzYEfX2V3pgWSnt360xQY+VbxALihsMxkGENcjchcUik yH0nahqanT4SFLookI+6gPdQYnSgN4o03aIUUxtGnXkb7huac7CUDKWDryLz2p9F2bQl MyahQTJ5XSr3aYythULyCmUYCJ1qMvYjc8jxJQiDVQX1fF6jrkX4i+os87B2CXzt8J4w u5zDrYF8mvmXJtMLjAM6IUnCVeO6YUb0PHK8u0JIKUD7So9NiIgtvHDXLGYxd2WGr6Y7 1PH7wgYhMo3gn9hfQ+jmD8j0YmkneU3dK7/y4Drs8KjudZxVsrwmPaRdYCmGyk/q13nK XJ4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3X4XYo9RgxVa04TE1Qq9SfxdTeNFRSUWAgNURH01Abw=; b=RMIz1hpuhyOUMAPWpXtUUNW4u3DTGS++b5YLiCbXg/Kz4ETJrDbgirZAvozV5MhcxP BDsOJwcOoYOOC9SNQhDRBiJOfatPAUj/8m3l40qDwxCkTxrQzh9XrsiuS/8hwiuYZcC5 w0RiaCBeDCQOcVcUU2NRHo4sAVe3ewHF3tBKhiqfpY5mx69JxRaY/0LMc3hLhownhqi1 FBT6IFodvnX8zWMnBaiCkCevcITvaRTdbao419uyM5XoImwAAhJXok/yVAq5etcaut8W 8VQf0O7RSk+GCNt+VQ7kT52zM80Ef3GTYptOn+eDc91/i+rX3ZGwnrOAwzyF1Awb7F/G dX3g== X-Gm-Message-State: AMke39nSMFPKBh6Lp6Tj+ppWwruDhKpPFX0jIsRymh5EZ5oszjULD1jnIUZw0Vv0adVGOG9p3Pcil2EHZwLvBQ== X-Received: by 10.55.195.138 with SMTP id r10mr11771642qkl.89.1486409111184; Mon, 06 Feb 2017 11:25:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.174.226 with HTTP; Mon, 6 Feb 2017 11:24:40 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Mon, 6 Feb 2017 11:24:40 -0800 Message-ID: Subject: Re: Performance/safety trade-off To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11479bcc102bb30547e19726 Archived-At: Cc: Eric Rescorla , Watson Ladd , Ian Swett , Dragana Damjanovic , Jana Iyengar , IETF QUIC WG , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2017 19:25:14 -0000 --001a11479bcc102bb30547e19726 Content-Type: text/plain; charset=UTF-8 On Sat, Feb 4, 2017 at 1:09 AM, Martin Thomson wrote: > On 3 February 2017 at 23:04, Eric Rescorla wrote: > > However, if you > > combine my proposal with David's, I believe that that resolves all the > > issues. > > That's not so simple. We'll have to be very careful with this one. I > have an idea, but it depends on having "special packets" more fully > fleshed out. > > So, to just to confirm the state of play by returning to Martin's original set of choices, we had: 1. As I originally suggested, suck it up and don't let the server send. > > 2. Don't protect the Finished (it's protected with TLS handshake keys > anyway). That would allow for acknowledgment in the clear. That > requires a tweak to the way that keys are shared, but it's a fairly > simple tweak. The major downside is that we now have an extra packet > to send, because you can't collapse the Finished message with other > things (like requests). > > 3. In the hackiest possible way, generate a redundant ACK for the > ClientHello in the clear. If that could trigger retransmission of the > first encrypted packet(s), then we'd be OK. (Sorry, I haven't > internalized the loss recovery stuff, so I'm not sure if this even > works, we could be back into RTO space here.) One is always possible, but it doesn't optimize anything much, so we can leave it off the table until we've decided that anything that does optimize this flow isn't workable or worth it. Three is testable: are we certain that generating a redundant ACK for the ClientHello triggers retransmission? There are going to be cases where this is needed anyways, so it seems worth testing whether it is used in this hack or not. If it does work, it's still less optimized that 2, but we could leave it on the table. In two, the concern is that including the Finished message, which is encrypted with TTL handshake keys, in packets that are also encrypted using the QUIC 1-RTT keys will make formal analysis of the security state lose the independence of the handshake and record layers that is a desired design goal. Ekr suggested that we resolve this by using explicit lengths here, rather than padding to the end of the frame; that would allow, at least in some cases, the client to generate two packets within one datagram. David Benjamin suggested that we include the Finished message in all packets until acknowledged. Several people have since suggested combining the two. That would appear to me to mean using explicit lengths and the two-packets per datagram theory until Finished is acknowledged, but correct me if I have combined David and ekr's ideas in a way different than folks presumed. Is that a reasonable summary? Additional questions: Speaking personally, I'm a bit worried about the theory in which we combine two packets into a single datagram, as I'm not clear how much receiver stacks would have to change to do that unpacking correctly. I can imagine them doing the wrong thing (in multiple ways) when encountering a second set of headers within the same datagram. Are there examples of this approach in use already that we can use to guide us? The usual way to avoid that problem but keep the main idea seems to be generating an enveloping mechanism that allows the second packet to be within a payload section of the (now only) packet within the datagram. But doing so requires us to find an enveloping mechanism that doesn't generate the same problem in formal analysis. As I look at that, I can't see any reason why that enveloping mechanism would actually need to enclose a valid packet (rather than Finished message), so we might be able to do this by adding a Flag to the quic common header like "BonusFinish" and then having a Finished message jammed in the type dependent field. The semantics here would be that this packet contains a bonus finish message in the header, as well as QUIC common packet. That could be included until acknowledged. The Finished message would still be encrypted by the TTL handshake key, but it would be outside the payload encrypted by the 1-RTT keys. Does the authentication of the headers generates the same formal analysis problem?. Can we encode the Finished message in a type dependent fields? Are there other problems with this approach that I'm missing? thanks, Ted --001a11479bcc102bb30547e19726 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Sat, Feb 4, 2017 at 1:09 AM, Martin Thomson <= martin.thomson@gmail.com> wrote:
On 3 February 2017 at 23:04, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com">ekr@rtfm.com> wrote:
> However, if you
> combine my proposal with David's, I believe that that resolves all= the
> issues.

That's not so simple.=C2=A0 We'll have to be very careful wi= th this one.=C2=A0 I
have an idea, but it depends on having "special packets" more ful= ly
fleshed out.


So, to just to conf= irm the state of play by returning to Martin's original set of choices,= we had:

1. As I originally suggested, suck it up and don't let the server send.=

2. Don't protect the Finished (it's protected with TLS handshake ke= ys
anyway).=C2=A0 That would allow for acknowledgment in the clear.=C2=A0 That=
requires a tweak to the way that keys are shared, but it's a fairly
simple tweak.=C2=A0 The major downside is that we now have an extra packet<= br> to send, because you can't collapse the Finished message with other
things (like requests).

3. In the hackiest possible way, generate a redundant ACK for the
ClientHello in the clear.=C2=A0 If that could trigger retransmission of the=
first encrypted packet(s), then we'd be OK.=C2=A0 (Sorry, I haven't=
internalized the loss recovery stuff, so I'm not sure if this even
works, we could be back into RTO space here.)

One is always possibl= e, but it doesn't optimize anything much, so we can leave it off the ta= ble until we've decided that anything that does optimize this flow isn&= #39;t workable or worth it.

Three i= s testable:=C2=A0 are we certain that generating a redundant ACK for the Cl= ientHello triggers retransmission?=C2=A0 There are going to be cases where = this is needed anyways, so it seems worth testing whether it is used in thi= s hack or not.=C2=A0 If it does work, it's still less optimized that 2,= but we could leave it on the table.

In two, the concern is that including the Finished message, which is encr= ypted with TTL handshake keys, in packets that are also encrypted using the= QUIC 1-RTT keys will make formal analysis of the security state lose the i= ndependence of the handshake and record layers that is a desired design goa= l.=C2=A0

Ekr suggested that we res= olve this by using explicit lengths here, rather than padding to the end of= the frame; that would allow, at least in some cases, the client to generat= e two packets within one datagram.=C2=A0 David Benjamin suggested that we i= nclude the Finished message in all packets until acknowledged.=C2=A0 Severa= l people have since suggested combining the two.=C2=A0

That would a= ppear to me to mean using explicit lengths and the two-packets per datagram= theory until Finished is acknowledged, but correct me if I have combined D= avid and ekr's ideas in a way different than folks presumed.

Is that a reasonable summary?

Additional questions:

Speaking personally, I'm a= bit worried about the theory in which we combine two packets into a single= datagram, as I'm not clear how much receiver stacks would have to chan= ge to do that unpacking correctly.=C2=A0 I can imagine them doing the wrong= thing (in multiple ways) when encountering a second set of headers within = the same datagram.=C2=A0 Are there examples of this approach in use already= that we can use to guide us?

The u= sual way to avoid that problem but keep the main idea seems to be generatin= g an enveloping mechanism that allows the second packet to be within a payl= oad section of the (now only) packet within the datagram.=C2=A0 But doing s= o requires us to find an enveloping mechanism that doesn't generate the= same problem in formal analysis.=C2=A0=C2=A0=C2=A0 As I look at that, I ca= n't see any reason why that enveloping mechanism would actually need to= enclose a valid packet (rather than Finished message), so we might be able= to do this by adding a Flag to the quic common header like "BonusFini= sh" and then having a Finished message jammed in the type dependent fi= eld.=C2=A0 The semantics here would be that this packet contains a bonus fi= nish message in the header, as well as QUIC common packet.=C2=A0 That could= be included until acknowledged.=C2=A0 The Finished message would still be = encrypted by the TTL handshake key, but it would be outside the payload enc= rypted by the 1-RTT keys.

Does the = authentication of the headers generates the same formal analysis problem?.= =C2=A0 Can we encode the Finished message in a type dependent fields?=C2=A0= Are there other problems with this approach that I'm missing?

<= /div>
thanks,

Ted


--001a11479bcc102bb30547e19726-- From nobody Mon Feb 6 17:16:56 2017 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 C10B3129555 for ; Mon, 6 Feb 2017 17:16:54 -0800 (PST) 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 4KwbzTAUoK02 for ; Mon, 6 Feb 2017 17:16:53 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 816D61293E3 for ; Mon, 6 Feb 2017 17:16:53 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id u25so73573882qki.2 for ; Mon, 06 Feb 2017 17:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=x7lLHWLQBztnkwZAp8/ThAD8M+nCJVNfde7/1qcn9hk=; b=sV/rOiGXRH54FUoCsvwvK6DtwrozOEoq9waHKNLYsSZIPLdT6/SRKoIHTP/pLBPiuO +Ya5EYL4VAya8gapzrkXBVYvkjZF5ahf2ONYq58SmMvUCJRgFsNaxAfnL2dRCJwFPsPT M3gkx8SZ1sQPOtDUG/Bw/VquOcJs95u1dG3olqeDqO0K3tIDQS5T8gPxvgFg8dotTwtm AyiG+oSprHZX88+s1jxHUwtKKodWW85sPeDgE8YuFneUlIsHmHzxpEJx7Vf5cTbRinZu fPKAcpA/b0xuTyzTq+AOH0Kn1qGZkj3lB4SFp2laHYAxjRjPpGIkTQNffkq5+CuaKAMJ 37tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x7lLHWLQBztnkwZAp8/ThAD8M+nCJVNfde7/1qcn9hk=; b=mKwJQwDSeMSPmRC8jgEI7uM8rGygxAmz7H+eMSjXYqrFTkmRlpfg9APr6J1aHe0wQH GKu7IiqpqUAJqWiUFs+qBcwEdyuwwKGQuInQs2ZwVSd5IhHBiPDknVr9RCoCkA8cx3x1 3vNQcT+VFF3jS2RiBSAuK1t347a6ZlFrRBfaEnDD+btbdArvTcRQhLMR0aQk8vbPmHCi KHxS0OZaKgzTDmlw1GiOBqeSQohTIIRG5/TqFFP4AhAdQVZYc4VPoqgJ6Ko2Zv5dD4un /pWRIYJL+XLVs21SCIxGjxeNQ8KHgSlO3Ar/ku9vWekOlKPoSR53EYqlEwE0Ctq1Hf+9 Iy9w== X-Gm-Message-State: AMke39l4UV3QvQSOsOr48OiLzOVaTNvfl/+XtGcS9+r4kGBNc8Mt5XgoSXkrV1HD38UZUT0FSI/qflIN+BgESw== X-Received: by 10.55.151.7 with SMTP id z7mr12940161qkd.316.1486430212708; Mon, 06 Feb 2017 17:16:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Mon, 6 Feb 2017 17:16:52 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 7 Feb 2017 12:16:52 +1100 Message-ID: Subject: Re: Performance/safety trade-off To: Ted Hardie Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Eric Rescorla , Watson Ladd , Ian Swett , Dragana Damjanovic , Jana Iyengar , IETF QUIC WG , Stephen Farrell X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 01:16:55 -0000 On 7 February 2017 at 06:24, Ted Hardie wrote: > Does the authentication of the headers generates the same formal analysis > problem?. Hmm, probably. I had been considering an approach where you had a special packet type that included a length-prefixed finished in the header, with the tail of the packet being 1-RTT protected. However, you are right that this triggers the problem because the finished might be seen as part of the header and we've agreed to integrity protect the header. > Can we encode the Finished message in a type dependent fields? Maybe, but perhaps only if it is outside of the authenticated data, which might be OK if we are still able to authenticate the *existence* of the finished, but it could accidentally leave us with a design for unauthenticated extensions to the header. I'm not sure that I'm happy about that as an outcome. Jana just reminded me that they ran an experiment regarding HOLB at the server: originally server packets were protected with 0-RTT keys immediately after the handshake, but the experiment fairly conclusively determined that protecting packets with 1-RTT keys didn't affect application metrics by any observable amount. Since using 1-RTT keys created a dependency on the SHLO in much the same way that we're dependent on the client Finished, I wonder if the reciprocal arrangement (i.e., option 1: wait it out) would have a similarly trivial impact. In other words, maybe we should measure before we waste even more time on this. From nobody Tue Feb 7 01:50:47 2017 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 3FE0A12949F for ; Tue, 7 Feb 2017 01:50:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WfUNrXDbdA-g for ; Tue, 7 Feb 2017 01:50:43 -0800 (PST) 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 C2D20129451 for ; Tue, 7 Feb 2017 01:50:43 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D88BD22E25B; Tue, 7 Feb 2017 04:50:36 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: ROUGH minutes from Tokyo Interim Message-Id: <963CF79E-0CF2-4577-A218-AFA7AC5E00B5@mnot.net> Date: Tue, 7 Feb 2017 20:50:33 +1100 To: IETF QUIC WG X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Lars Eggert X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Feb 2017 09:50:46 -0000 ... are at: https://github.com/quicwg/wg-materials/tree/master/interim-17-01 Please have a look through and make suggestions and corrections (either = in e-mail, or preferably as pull requests). Thanks again to our scribes for all three days. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Wed Feb 8 20:42:56 2017 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 0ACA0129F0E for ; Wed, 8 Feb 2017 20:42:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8gLBQVVgnOZ for ; Wed, 8 Feb 2017 20:42:54 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 F0E4E129F0A for ; Wed, 8 Feb 2017 20:42:53 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id v23so186490518qtb.0 for ; Wed, 08 Feb 2017 20:42:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Pbm6EdZGQtQpVZ49BYfTzMFpPbRufHcIub3usCqCkeg=; b=YQ+RX0Wj65ubkgudxNNIkW1geavaCoR5vopx7+4nt726dK8vxzjS5725AGZAXiVMh+ O8NTIFyHJFRdVM1u02YpL1Crb0MlQlNE5YkUFtkai2b3Yz6EfK1meRKgkBmKTGs87doP TMvPTU0MCOVxmgcUel0xiPp3DLWCfASPuHDPSVlMMD93k03l/NlDb2nYW6MFBnLW/w0l nmm61Sq5tff7ly7uoWEUHI0y30hIlivpJhVUTliCYGbTxNhRPa1/hMgaYew3KB6HmQXz K5LVgCNrbqDbls5qFffvUFwRRWNYQpCwKVAby7gfvgQv5/Eri7bNS9scwTEwaU3pn8aT RaDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Pbm6EdZGQtQpVZ49BYfTzMFpPbRufHcIub3usCqCkeg=; b=f9hnh7SUjILZ6pOiK+WwxwUecb5sVhxZfEy30FcaYHuWHX50o54SsmpZke5keWCB/B cBUgD6JAuOWJZTQV4d1eiKNitYmfgGIhq3msgVoXASkjmuWcgHptZRng94IxKYOv/Hpi hBwfYj+Q/UfWlWmGfZiLtIqfMGtqxjxcJ9U7uvyNd7zJkiyv6dKz6ZxFkD3utWG17iKo aUnoLNJXO0D6fFqC/4f+4zw2cW+z10dmul5BISpOfLdKXvnYIhSwSERQDs7S7KTk4hOD XpI70AtSF6TjDZjfzjMjX18VN5T8uj/DVImxipXZI+Wpv+C7uUbc0dIVIr3Xb56u5m50 /yBA== X-Gm-Message-State: AMke39lAMBT6AjecpE32XmIuH1A6Qtnc/CXOiG78JzMeWPxSRkzMwwlVxz9Apep7sdwDMuf0jURN3cPz+Q+spg== X-Received: by 10.200.55.112 with SMTP id p45mr1167989qtb.278.1486615372484; Wed, 08 Feb 2017 20:42:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 8 Feb 2017 20:42:52 -0800 (PST) From: Martin Thomson Date: Thu, 9 Feb 2017 15:42:52 +1100 Message-ID: Subject: Proposal for QUIC header To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 04:42:56 -0000 As I go through the issues list, it appears that a lot of issues on which we have consensus would benefit from a resolution to the header format issue. To that end, I have sketched out a proposal that I think meets the various constraints we have. I want to discuss this here before we embark on what could be a fairly disruptive set of changes to the drafts. (A copy of the following text can be found at https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8 ) -- There are two forms of QUIC common header: long and short. Long form packets are used for the initial exchange - until both 1-RTT packet protection can be started AND version negotiation is complete. Short form packets carry the bulk of the data. This removes a lot of the flexibility that was the source of most of the objections to the current format. Fields are aligned on four octet boundaries. All long-form header variations have the exact same form. The connection ID is in the same place in both short and long form. The long form clearly identifies the role of the sender in the first octet and it identifies the packet as a QUIC packet. The cost is that it makes occasional packets a little larger (the long header is 20 octets, whereas the existing form uses between 14 and 19 octets for initial handshake packets). This is an acceptable trade-off given that only a few of these packets are ever exchanged on a connection. It makes most packets (the short header) 12 octets where it is possible to have 10 octet packets. However, a 10 octet packet header assumes an 8 bit packet number, this is 30. # Long Header ``` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|Typ| Next | Magic "uic"/"UIC" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | [Header Extensions] ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` The first four octets: * Octet 0: Special * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) * Bit 6-5: Type * 11 - client packet * 10 - server packet * 01 - public reset * 00 - version negotiation * Bits 4-0: Next protocol * 0b10001 indicates that it is QUIC handshake data * 0b01111 indicates that it is QUIC 0-RTT data * other values mean that the payload following the packet number contains an IPv6-style extension header * Octets 1-3: Magic (this can be short given that we will have a MAC as well) * 0x756963 for a client, * 0x554943 for a server Note: A client packet starts with "quic", server starts with "QUIC", 0-RTT starts with "ouic". Note(2): We might consider the second set of 7 bits to be a single code space, rather than use a 2+5 bit partitioning. That gives us a bit more flexibility and avoids meaningless combinations like public reset + 0-RTT. The remainder of the packet layout is the same regardless of type, the difference being what rules for how to fill the values out and their semantics. A client packet then contains: * Octets 4-11: connection ID (initially all zeroes/random) * Octets 12-15: version * Octets 16-19: packet number (low 4 octets, starts at a random 32-bit value) * Octets 20+: payload Note: I'm not sure whether the client should pack the connection ID with random values. They would have no semantic value, though they might serve to provide proof that the server received the packet if we require echoing, see below. A server packet contains a connection ID: * Octets 4-11: connection ID (server-selected value) * Octets 12-15: version (echoed) * Octets 16-19: packet number (low 4 octets, random 32-bit initial value) * Octets 20+: payload A version negotiation packet contains: * Octets 4-11: connection ID (echoed) * Octets 12-15: version received (echoed) * Octets 16-19: packet number (echoed) * Octets 20+: payload = version list A public reset packet contains: * Octets 4-11: connection ID (echoed) * Octets 12-15: version (echoed) * Octets 16-19: rejected packet number (echoed) * Octets 20+: payload = authentication data Echoing details from the packet in both version negotiation and provides return routeability on version negotiation (#244), while maintaining a consistent header shape for all packets. These long-form packets are used for anything that doesn't have 1-RTT packet protection and prior to the completion of version negotiation. Once both conditions are met, switch to sending short-form packets. I haven't defined any 5/7-bit code for protected long-form packets, but that's easy to do if we need to provide for them (see below for more on this). ## Extension headers An 8-bit space (like IPv6) carries an identifier for the protocol extension. Each header extension takes the form: * Octet 1: next identifier * Octet 2: length Since only the lower 5 (or 7) bits of this space is accessible from the outset, 0x00 is reserved for a null extension header, allowing the full space to be unlocked. 0x?a can be used for greasing. I haven't talked to IP-layer people about whether they consider the IPv6 scheme this is based on to be successful. Either way, this should at least have plenty of hardware support. FWIW, I'm not sure that we need the complexity that this adds. It's not clear that there is a motivating use case. However, on balance it's probably worth putting something in for the moment. If it turns out that we don't use it and can't find even a potential use case, then removing it is simple enough. That said, this form could be used to pack a TLS Finished into 1-RTT packets if we define a 5- or 7-bit code for "small bit of handshake, followed by more", after which we can include a 1-RTT payload. # Short Header ``` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S|K| Packet Number (30) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` The short form header is defined to be specific to a version. Anything can change between protocol versions. A short packet header - in this version - reserves two bits from the first octet: * SHORT_HEADER bit 7 (0x80) = 1, * KEY_PHASE bit 6 (0x40) = 0 initially The remainder of the first four octets contain the packet number. 30 bits should be plenty. If a need is found for more flags, those can steal upper bits from the packet number. (Frankly, I suspect that 14 bits might be enough, but Ian was a little leery of that when I suggested it, and this keeps the connection ID in the same place in every packet.) The connection ID follows on the next 8 octets. If we need more bits, then we can steal them from the packet number. From nobody Thu Feb 9 06:28:25 2017 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 77DDD129A5B for ; Thu, 9 Feb 2017 06:28:23 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 m7SVKt-cEo5y for ; Thu, 9 Feb 2017 06:28:21 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 364F0129A42 for ; Thu, 9 Feb 2017 06:28:21 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7F09C43347C; Thu, 9 Feb 2017 14:28:20 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 6193543347A; Thu, 9 Feb 2017 14:28:20 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1486650500; bh=/t1/7aQEWyNh/yebhpsGrnqtm5oigMhBJBNKne6DbFA=; l=13852; h=From:To:Date:References:In-Reply-To:From; b=RXnvUlWx9YHq731J5FngHe1SGp5fbGfnYO8VYO+NVUwDGv+WIDU+1f4H5Hkypt7/L CSycILmAn7GmeO0/PnNfPDidQ/JlyqGQZY1G0uFHYm364CBqs18UPeK8lO2MffyGYz vJDFqhg2LAZR2eVpfN5qhKevW3wogCbfbvudQy7I= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 5B9BC1FC86; Thu, 9 Feb 2017 14:28:20 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 9 Feb 2017 09:28:19 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Thu, 9 Feb 2017 09:28:19 -0500 From: "Lubashev, Igor" To: Martin Thomson , IETF QUIC WG Subject: RE: Proposal for QUIC header Thread-Topic: Proposal for QUIC header Thread-Index: AQHSgo7+mc22sR/s6kO0IlKzrGvXMqFguvdg Date: Thu, 9 Feb 2017 14:28:19 +0000 Message-ID: <32b44da363984bcf931b7bb2521362ca@usma1ex-dag1mb5.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.46.24] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 14:28:23 -0000 TWFydGluLCBJIGxpa2UgaG93IHNpbXBsZSB0aGlzIGxvb2tzIG5vdy4gIEkgZmV3IGNvbW1lbnRz IG9uIHRoaXMuDQoNCjEuIExvbmcgSGVhZGVyDQoNClRoZSBjaG9pY2Ugb2YgbmFtZXMgZm9yIEJp dCA2LTUgVHlwIHNlZW0gYSBiaXQgY29uZnVzaW5nLiBQdWJsaWMgUmVzZXRzIGFuZCBWZXJzaW9u IE5lZ290aWF0aW9uIHBhY2tldHMgYXJlIGFsc28gInNlcnZlciIgb3IgImNsaWVudCIgcGFja2V0 cy4gQWxzbywgJ01hZ2ljICJ1aWMiLyJVSUMiJyBpcyBzdWZmaWNpZW50IHRvIHRlbGwgdGhlIG9y aWdpbiBvZiB0aGUgcGFja2V0LCBzbyBhcmUgZGlzdGluY3QgInNlcnZlciBwYWNrZXQiIC8gImNs aWVudCBwYWNrZXQiIHR5cGVzIG5lZWRlZD8NCg0KVGhlICJ2ZXJzaW9uIG5lZ290aWF0aW9uIiBw YWNrZXQgbmVlZHMgdG8gaGF2ZSBhbiBlY2hvZWQgY29ubmVjdGlvbiBJRC4gIElzIHRoaXMgYSBw YWNrZXQgc2VudCBieSB0aGUgc2VydmVyIGluIHJlc3BvbnNlIHRvIHRoZSBpbml0aWFsIHBhY2tl dCBmcm9tIHRoZSBjbGllbnQ/IElmIHNvLCB3b3VsZCB3ZSB3YW50IHRvIGp1c3QgZWNobyBhIHJh bmRvbSBjb25uZWN0aW9uIElEIHRoZXJlIGluc3RlYWQgb2Ygc2VsZWN0aW5nIHRoZSBjb25uZWN0 aW9uIElEPyBUaGUgcGFja2V0IG51bWJlciBpcyBhbHNvIHNhaWQgdG8gYmUgZWNob2VkLiBXb3Vs ZCBub3QgdGhlIHNlbmRlciBvZiAidmVyc2lvbiBuZWdvdGlhdGlvbiIgcGFja2V0IHdhbnQgdG8g dXNlIGl0cyBvd24gcGFja2V0IG51bWJlcj8NCg0KMi4gU2hvcnQgSGVhZGVyDQoNCiJBbnl0aGlu ZyBjYW4gY2hhbmdlIGJldHdlZW4gcHJvdG9jb2wgdmVyc2lvbnMuIiBJIGRvIG5vdCB0aGluayB0 aGlzIGlzIGNvcnJlY3QuIFlvdSBhdCBsZWFzdCBvdWdodCB0byBoYXZlIFtTSE9SVF9IRUFERVIg Yml0IDcgKDB4ODApID0gMV0gZm9yIGFsbCB2ZXJzaW9ucy4gT3RoZXJ3aXNlLCBpZiBzb21lIHZl cnNpb24gd2VyZSB0byBkZWZpbmUgdGhpcyBiaXQ9MCBmb3IgInNob3J0IGhlYWRlciIgcGFja2V0 cywgYSByZXN0YXJ0aW5nIGVuZHBvaW50IG1heSBnZXQgbWlnaHRpbHkgY29uZnVzZWQgYnkgYXJy aXZpbmcgcGFja2V0cyBiZWxvbmdpbmcgdG8gcHJldmlvdXNseSBsZWdpdGltYXRlbHkgbmVnb3Rp YXRlZCBRVUlDIGNvbm5lY3Rpb25zLg0KDQpNb3Jlb3ZlciwgSSB0aGluayBldmVuIG1vcmUgdGhp bmdzIG1heSBuZWVkIHRvIHN0YXkgY29uc3RhbnQgKGxpa2UgdGhlIGxvY2F0aW9uIG9mIHRoZSBD b25uZWN0aW9uSUQpLiBPdGhlcndpc2UsIHlvdSBhcmUgbGlrZWx5IHRvIGNvbmZ1c2UgYW4gZW5k IHBvaW50IHdob3NlIFFVSUMtc3BlYWtpbmcgYXBwbGljYXRpb24gaXMgcmVzdGFydGVkIGludG8g YSBuZXdlciAob3Igb2xkZXIpIHZlcnNpb24gdGhhdCBkb2VzIG5vdCBzdXBwb3J0IHRoZSBwcmV2 aW91cyBRVUlDIHZlcnNpb24gYW5kLCBpbnN0ZWFkLCBzdXBwb3J0cyBhIFFVSUMgdmVyc2lvbiB3 aGVyZSB0aGUgQ29ubmVjdGlvbklEIGhhcyBtb3ZlZCB0byBhbm90aGVyIGxvY2F0aW9uIGluIHRo ZSBoZWFkZXIuIEkuZS4gdGhhdCBhcHBsaWNhdGlvbiBtYXkgbm90IGJlIGFibGUgdG8gZmlndXJl IG91dCB0aGF0IGFycml2aW5nIFFVSUMgcGFja2V0cyBkbyBub3QgYmVsb25nIHRvIGFueSBvZiB0 aGUgY29ubmVjdGlvbnMgaXQgaXMgYXdhcmUgb2YuDQoNCkJvdGggb2YgdGhlIGFib3ZlIG1heSBu b3QgYmUgY2F0YXN0cm9waGljIChRVUlDIHNob3VsZCBiZSBhYmxlIHRvIGhhbmRsZSAiaW50ZXJu ZXQgbm9pc2UiKSwgYnV0IHRoZSBiZWhhdmlvciBtYXkgcmVzdWx0IGluIHRoZSBhcHBsaWNhdGlv biBjYXVzaW5nIHNvbWUgdW5pbnRlbmRlZCByZWZsZWN0ZWQgImludGVybmV0IG5vaXNlIiBvZiBp dHMgb3duLg0KDQoNCi0gSWdvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDog V2VkbmVzZGF5LCBGZWJydWFyeSAwOCwgMjAxNyAxMTo0MyBQTQ0KVG86IElFVEYgUVVJQyBXRyA8 cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFByb3Bvc2FsIGZvciBRVUlDIGhlYWRlcg0KDQpBcyBJ IGdvIHRocm91Z2ggdGhlIGlzc3VlcyBsaXN0LCBpdCBhcHBlYXJzIHRoYXQgYSBsb3Qgb2YgaXNz dWVzIG9uIHdoaWNoIHdlIGhhdmUgY29uc2Vuc3VzIHdvdWxkIGJlbmVmaXQgZnJvbSBhIHJlc29s dXRpb24gdG8gdGhlIGhlYWRlciBmb3JtYXQgaXNzdWUuICBUbyB0aGF0IGVuZCwgSSBoYXZlIHNr ZXRjaGVkIG91dCBhIHByb3Bvc2FsIHRoYXQgSSB0aGluayBtZWV0cyB0aGUgdmFyaW91cyBjb25z dHJhaW50cyB3ZSBoYXZlLg0KDQpJIHdhbnQgdG8gZGlzY3VzcyB0aGlzIGhlcmUgYmVmb3JlIHdl IGVtYmFyayBvbiB3aGF0IGNvdWxkIGJlIGEgZmFpcmx5IGRpc3J1cHRpdmUgc2V0IG9mIGNoYW5n ZXMgdG8gdGhlIGRyYWZ0cy4NCg0KKEEgY29weSBvZiB0aGUgZm9sbG93aW5nIHRleHQgY2FuIGJl IGZvdW5kIGF0DQpodHRwczovL2dpc3QuZ2l0aHViLmNvbS9tYXJ0aW50aG9tc29uLzc0NGQwNGNi Y2VjOWJlNTU0ZjJmOGU3YmFlMjcxNWI4DQopDQotLQ0KDQpUaGVyZSBhcmUgdHdvIGZvcm1zIG9m IFFVSUMgY29tbW9uIGhlYWRlcjogbG9uZyBhbmQgc2hvcnQuICBMb25nIGZvcm0gcGFja2V0cyBh cmUgdXNlZCBmb3IgdGhlIGluaXRpYWwgZXhjaGFuZ2UgLSB1bnRpbCBib3RoIDEtUlRUIHBhY2tl dCBwcm90ZWN0aW9uIGNhbiBiZSBzdGFydGVkIEFORCB2ZXJzaW9uIG5lZ290aWF0aW9uIGlzIGNv bXBsZXRlLiAgU2hvcnQgZm9ybSBwYWNrZXRzIGNhcnJ5IHRoZSBidWxrIG9mIHRoZSBkYXRhLg0K DQpUaGlzIHJlbW92ZXMgYSBsb3Qgb2YgdGhlIGZsZXhpYmlsaXR5IHRoYXQgd2FzIHRoZSBzb3Vy Y2Ugb2YgbW9zdCBvZiB0aGUgb2JqZWN0aW9ucyB0byB0aGUgY3VycmVudCBmb3JtYXQuICBGaWVs ZHMgYXJlIGFsaWduZWQgb24gZm91ciBvY3RldCBib3VuZGFyaWVzLg0KQWxsIGxvbmctZm9ybSBo ZWFkZXIgdmFyaWF0aW9ucyBoYXZlIHRoZSBleGFjdCBzYW1lIGZvcm0uICBUaGUgY29ubmVjdGlv biBJRCBpcyBpbiB0aGUgc2FtZSBwbGFjZSBpbiBib3RoIHNob3J0IGFuZCBsb25nIGZvcm0uICBU aGUgbG9uZyBmb3JtIGNsZWFybHkgaWRlbnRpZmllcyB0aGUgcm9sZSBvZiB0aGUgc2VuZGVyIGlu IHRoZSBmaXJzdCBvY3RldCBhbmQgaXQgaWRlbnRpZmllcyB0aGUgcGFja2V0IGFzIGEgUVVJQyBw YWNrZXQuDQoNClRoZSBjb3N0IGlzIHRoYXQgaXQgbWFrZXMgb2NjYXNpb25hbCBwYWNrZXRzIGEg bGl0dGxlIGxhcmdlciAodGhlIGxvbmcgaGVhZGVyIGlzIDIwIG9jdGV0cywgd2hlcmVhcyB0aGUg ZXhpc3RpbmcgZm9ybSB1c2VzIGJldHdlZW4gMTQgYW5kIDE5IG9jdGV0cyBmb3IgaW5pdGlhbCBo YW5kc2hha2UgcGFja2V0cykuICBUaGlzIGlzIGFuIGFjY2VwdGFibGUgdHJhZGUtb2ZmIGdpdmVu IHRoYXQgb25seSBhIGZldyBvZiB0aGVzZSBwYWNrZXRzIGFyZSBldmVyIGV4Y2hhbmdlZCBvbiBh IGNvbm5lY3Rpb24uDQoNCkl0IG1ha2VzIG1vc3QgcGFja2V0cyAodGhlIHNob3J0IGhlYWRlcikg MTIgb2N0ZXRzIHdoZXJlIGl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgMTAgb2N0ZXQgcGFja2V0cy4g IEhvd2V2ZXIsIGEgMTAgb2N0ZXQgcGFja2V0IGhlYWRlciBhc3N1bWVzIGFuIDggYml0IHBhY2tl dCBudW1iZXIsIHRoaXMgaXMgMzAuDQoNCg0KDQojIExvbmcgSGVhZGVyDQoNCmBgYA0KIDAgICAg ICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMN CiAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDENCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rDQp8U3xUeXB8ICBOZXh0ICAgfCAgICAgICAgICAgICAgTWFnaWMg InVpYyIvIlVJQyIgICAgICAgICAgICAgICAgfA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQorICAgICAg ICAgICAgICAgICAgICAgICAgIENvbm5lY3Rpb24gSUQgICAgICAgICAgICAgICAgICAgICAgICAg Kw0KfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgIFZlcnNp b24gICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCnwgICAgICAgICAgICAg ICAgICAgICAgICAgUGFja2V0IE51bWJlciAgICAgICAgICAgICAgICAgICAgICAgICB8DQorLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KfCAgICAgICAgICAgICAgICAgICAgICAgW0hlYWRlciBFeHRlbnNpb25zXSAgICAgICAg ICAgICAgICAgICAuLi4NCistKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgUGF5 bG9hZCAgICAgICAgICAgICAgICAgICAgICAgICAgIC4uLg0KKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCmBgYA0KDQpUaGUg Zmlyc3QgZm91ciBvY3RldHM6DQoqIE9jdGV0IDA6IFNwZWNpYWwNCiAgKiBCaXQgNyAoaS5lLiwg MHg4MCk6IFNIT1JUX0hFQURFUiAoc2V0IHRvIDAgaGVyZSkNCiAgKiBCaXQgNi01OiBUeXBlDQog ICAgKiAxMSAtIGNsaWVudCBwYWNrZXQNCiAgICAqIDEwIC0gc2VydmVyIHBhY2tldA0KICAgICog MDEgLSBwdWJsaWMgcmVzZXQNCiAgICAqIDAwIC0gdmVyc2lvbiBuZWdvdGlhdGlvbg0KICAqIEJp dHMgNC0wOiBOZXh0IHByb3RvY29sDQogICAgKiAwYjEwMDAxIGluZGljYXRlcyB0aGF0IGl0IGlz IFFVSUMgaGFuZHNoYWtlIGRhdGENCiAgICAqIDBiMDExMTEgaW5kaWNhdGVzIHRoYXQgaXQgaXMg UVVJQyAwLVJUVCBkYXRhDQogICAgKiBvdGhlciB2YWx1ZXMgbWVhbiB0aGF0IHRoZSBwYXlsb2Fk IGZvbGxvd2luZyB0aGUgcGFja2V0IG51bWJlciBjb250YWlucw0KICAgICBhbiBJUHY2LXN0eWxl IGV4dGVuc2lvbiBoZWFkZXINCiogT2N0ZXRzIDEtMzogTWFnaWMgKHRoaXMgY2FuIGJlIHNob3J0 IGdpdmVuIHRoYXQgd2Ugd2lsbCBoYXZlIGEgTUFDIGFzIHdlbGwpDQogICogMHg3NTY5NjMgZm9y IGEgY2xpZW50LA0KICAqIDB4NTU0OTQzIGZvciBhIHNlcnZlcg0KDQpOb3RlOiBBIGNsaWVudCBw YWNrZXQgc3RhcnRzIHdpdGggInF1aWMiLCBzZXJ2ZXIgc3RhcnRzIHdpdGggIlFVSUMiLCAwLVJU VCBzdGFydHMgd2l0aCAib3VpYyIuDQoNCk5vdGUoMik6IFdlIG1pZ2h0IGNvbnNpZGVyIHRoZSBz ZWNvbmQgc2V0IG9mIDcgYml0cyB0byBiZSBhIHNpbmdsZSBjb2RlIHNwYWNlLCByYXRoZXIgdGhh biB1c2UgYSAyKzUgYml0IHBhcnRpdGlvbmluZy4gIFRoYXQgZ2l2ZXMgdXMgYSBiaXQgbW9yZSBm bGV4aWJpbGl0eSBhbmQgYXZvaWRzIG1lYW5pbmdsZXNzIGNvbWJpbmF0aW9ucyBsaWtlIHB1Ymxp YyByZXNldCArIDAtUlRULg0KDQpUaGUgcmVtYWluZGVyIG9mIHRoZSBwYWNrZXQgbGF5b3V0IGlz IHRoZSBzYW1lIHJlZ2FyZGxlc3Mgb2YgdHlwZSwgdGhlIGRpZmZlcmVuY2UgYmVpbmcgd2hhdCBy dWxlcyBmb3IgaG93IHRvIGZpbGwgdGhlIHZhbHVlcyBvdXQgYW5kIHRoZWlyIHNlbWFudGljcy4N Cg0KQSBjbGllbnQgcGFja2V0IHRoZW4gY29udGFpbnM6DQoqIE9jdGV0cyA0LTExOiBjb25uZWN0 aW9uIElEIChpbml0aWFsbHkgYWxsIHplcm9lcy9yYW5kb20pDQoqIE9jdGV0cyAxMi0xNTogdmVy c2lvbg0KKiBPY3RldHMgMTYtMTk6IHBhY2tldCBudW1iZXIgKGxvdyA0IG9jdGV0cywgc3RhcnRz IGF0IGEgcmFuZG9tIDMyLWJpdCB2YWx1ZSkNCiogT2N0ZXRzIDIwKzogcGF5bG9hZA0KDQpOb3Rl OiBJJ20gbm90IHN1cmUgd2hldGhlciB0aGUgY2xpZW50IHNob3VsZCBwYWNrIHRoZSBjb25uZWN0 aW9uIElEIHdpdGggcmFuZG9tIHZhbHVlcy4gIFRoZXkgd291bGQgaGF2ZSBubyBzZW1hbnRpYyB2 YWx1ZSwgdGhvdWdoIHRoZXkgbWlnaHQgc2VydmUgdG8gcHJvdmlkZSBwcm9vZiB0aGF0IHRoZSBz ZXJ2ZXIgcmVjZWl2ZWQgdGhlIHBhY2tldCBpZiB3ZSByZXF1aXJlIGVjaG9pbmcsIHNlZSBiZWxv dy4NCg0KQSBzZXJ2ZXIgcGFja2V0IGNvbnRhaW5zIGEgY29ubmVjdGlvbiBJRDoNCiogT2N0ZXRz IDQtMTE6IGNvbm5lY3Rpb24gSUQgKHNlcnZlci1zZWxlY3RlZCB2YWx1ZSkNCiogT2N0ZXRzIDEy LTE1OiB2ZXJzaW9uIChlY2hvZWQpDQoqIE9jdGV0cyAxNi0xOTogcGFja2V0IG51bWJlciAobG93 IDQgb2N0ZXRzLCByYW5kb20gMzItYml0IGluaXRpYWwgdmFsdWUpDQoqIE9jdGV0cyAyMCs6IHBh eWxvYWQNCg0KQSB2ZXJzaW9uIG5lZ290aWF0aW9uIHBhY2tldCBjb250YWluczoNCiogT2N0ZXRz IDQtMTE6IGNvbm5lY3Rpb24gSUQgKGVjaG9lZCkNCiogT2N0ZXRzIDEyLTE1OiB2ZXJzaW9uIHJl Y2VpdmVkIChlY2hvZWQpDQoqIE9jdGV0cyAxNi0xOTogcGFja2V0IG51bWJlciAoZWNob2VkKQ0K KiBPY3RldHMgMjArOiBwYXlsb2FkID0gdmVyc2lvbiBsaXN0DQoNCkEgcHVibGljIHJlc2V0IHBh Y2tldCBjb250YWluczoNCiogT2N0ZXRzIDQtMTE6IGNvbm5lY3Rpb24gSUQgKGVjaG9lZCkNCiog T2N0ZXRzIDEyLTE1OiB2ZXJzaW9uIChlY2hvZWQpDQoqIE9jdGV0cyAxNi0xOTogcmVqZWN0ZWQg cGFja2V0IG51bWJlciAoZWNob2VkKQ0KKiBPY3RldHMgMjArOiBwYXlsb2FkID0gYXV0aGVudGlj YXRpb24gZGF0YQ0KDQpFY2hvaW5nIGRldGFpbHMgZnJvbSB0aGUgcGFja2V0IGluIGJvdGggdmVy c2lvbiBuZWdvdGlhdGlvbiBhbmQgcHJvdmlkZXMgcmV0dXJuIHJvdXRlYWJpbGl0eSBvbiB2ZXJz aW9uIG5lZ290aWF0aW9uICgjMjQ0KSwgd2hpbGUgbWFpbnRhaW5pbmcgYSBjb25zaXN0ZW50IGhl YWRlciBzaGFwZSBmb3IgYWxsIHBhY2tldHMuDQoNClRoZXNlIGxvbmctZm9ybSBwYWNrZXRzIGFy ZSB1c2VkIGZvciBhbnl0aGluZyB0aGF0IGRvZXNuJ3QgaGF2ZSAxLVJUVCBwYWNrZXQgcHJvdGVj dGlvbiBhbmQgcHJpb3IgdG8gdGhlIGNvbXBsZXRpb24gb2YgdmVyc2lvbiBuZWdvdGlhdGlvbi4g IE9uY2UgYm90aCBjb25kaXRpb25zIGFyZSBtZXQsIHN3aXRjaCB0byBzZW5kaW5nIHNob3J0LWZv cm0gcGFja2V0cy4gIEkgaGF2ZW4ndCBkZWZpbmVkIGFueSA1LzctYml0IGNvZGUgZm9yIHByb3Rl Y3RlZCBsb25nLWZvcm0gcGFja2V0cywgYnV0IHRoYXQncyBlYXN5IHRvIGRvIGlmIHdlIG5lZWQg dG8gcHJvdmlkZSBmb3IgdGhlbSAoc2VlIGJlbG93IGZvciBtb3JlIG9uIHRoaXMpLg0KDQoNCiMj IEV4dGVuc2lvbiBoZWFkZXJzDQoNCkFuIDgtYml0IHNwYWNlIChsaWtlIElQdjYpIGNhcnJpZXMg YW4gaWRlbnRpZmllciBmb3IgdGhlIHByb3RvY29sIGV4dGVuc2lvbi4NCg0KRWFjaCBoZWFkZXIg ZXh0ZW5zaW9uIHRha2VzIHRoZSBmb3JtOg0KKiBPY3RldCAxOiBuZXh0IGlkZW50aWZpZXINCiog T2N0ZXQgMjogbGVuZ3RoDQoNClNpbmNlIG9ubHkgdGhlIGxvd2VyIDUgKG9yIDcpIGJpdHMgb2Yg dGhpcyBzcGFjZSBpcyBhY2Nlc3NpYmxlIGZyb20gdGhlIG91dHNldCwNCjB4MDAgaXMgcmVzZXJ2 ZWQgZm9yIGEgbnVsbCBleHRlbnNpb24gaGVhZGVyLCBhbGxvd2luZyB0aGUgZnVsbCBzcGFjZSB0 byBiZSB1bmxvY2tlZC4gIDB4P2EgY2FuIGJlIHVzZWQgZm9yIGdyZWFzaW5nLg0KDQpJIGhhdmVu J3QgdGFsa2VkIHRvIElQLWxheWVyIHBlb3BsZSBhYm91dCB3aGV0aGVyIHRoZXkgY29uc2lkZXIg dGhlIElQdjYgc2NoZW1lIHRoaXMgaXMgYmFzZWQgb24gdG8gYmUgc3VjY2Vzc2Z1bC4gIEVpdGhl ciB3YXksIHRoaXMgc2hvdWxkIGF0IGxlYXN0IGhhdmUgcGxlbnR5IG9mIGhhcmR3YXJlIHN1cHBv cnQuDQoNCkZXSVcsIEknbSBub3Qgc3VyZSB0aGF0IHdlIG5lZWQgdGhlIGNvbXBsZXhpdHkgdGhh dCB0aGlzIGFkZHMuICBJdCdzIG5vdCBjbGVhcg0KdGhhdCB0aGVyZSBpcyBhIG1vdGl2YXRpbmcg dXNlIGNhc2UuICAgSG93ZXZlciwgb24gYmFsYW5jZSBpdCdzIHByb2JhYmx5IHdvcnRoDQpwdXR0 aW5nIHNvbWV0aGluZyBpbiBmb3IgdGhlIG1vbWVudC4gIElmIGl0IHR1cm5zIG91dCB0aGF0IHdl IGRvbid0IHVzZSBpdCBhbmQgY2FuJ3QgZmluZCBldmVuIGEgcG90ZW50aWFsIHVzZSBjYXNlLCB0 aGVuIHJlbW92aW5nIGl0IGlzIHNpbXBsZSBlbm91Z2guDQoNClRoYXQgc2FpZCwgdGhpcyBmb3Jt IGNvdWxkIGJlIHVzZWQgdG8gcGFjayBhIFRMUyBGaW5pc2hlZCBpbnRvIDEtUlRUIHBhY2tldHMg aWYgd2UgZGVmaW5lIGEgNS0gb3IgNy1iaXQgY29kZSBmb3IgInNtYWxsIGJpdCBvZiBoYW5kc2hh a2UsIGZvbGxvd2VkIGJ5IG1vcmUiLCBhZnRlciB3aGljaCB3ZSBjYW4gaW5jbHVkZSBhIDEtUlRU IHBheWxvYWQuDQoNCg0KIyBTaG9ydCBIZWFkZXINCg0KYGBgDQogMCAgICAgICAgICAgICAgICAg ICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KIDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCnxTfEt8ICAgICAgICAgICAgICAgIFBhY2tldCBOdW1iZXIgKDMwKSAgICAgICAgICAg ICAgICAgICAgICAgICB8DQorLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCisgICAgICAgICAgICAgICAgICAg ICAgICAgQ29ubmVjdGlvbiBJRCAgICAgICAgICAgICAgICAgICAgICAgICArDQp8ICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSsNCmBgYA0KDQpUaGUgc2hvcnQgZm9ybSBoZWFkZXIgaXMgZGVmaW5lZCB0byBiZSBz cGVjaWZpYyB0byBhIHZlcnNpb24uICBBbnl0aGluZyBjYW4gY2hhbmdlIGJldHdlZW4gcHJvdG9j b2wgdmVyc2lvbnMuDQoNCkEgc2hvcnQgcGFja2V0IGhlYWRlciAtIGluIHRoaXMgdmVyc2lvbiAt IHJlc2VydmVzIHR3byBiaXRzIGZyb20gdGhlIGZpcnN0DQpvY3RldDoNCiogU0hPUlRfSEVBREVS IGJpdCA3ICgweDgwKSA9IDEsDQoqIEtFWV9QSEFTRSBiaXQgNiAoMHg0MCkgPSAwIGluaXRpYWxs eQ0KDQpUaGUgcmVtYWluZGVyIG9mIHRoZSBmaXJzdCBmb3VyIG9jdGV0cyBjb250YWluIHRoZSBw YWNrZXQgbnVtYmVyLiAgMzAgYml0cyBzaG91bGQgYmUgcGxlbnR5LiAgSWYgYSBuZWVkIGlzIGZv dW5kIGZvciBtb3JlIGZsYWdzLCB0aG9zZSBjYW4gc3RlYWwgdXBwZXIgYml0cyBmcm9tIHRoZSBw YWNrZXQgbnVtYmVyLiAgKEZyYW5rbHksIEkgc3VzcGVjdCB0aGF0IDE0IGJpdHMgbWlnaHQgYmUg ZW5vdWdoLCBidXQgSWFuIHdhcyBhIGxpdHRsZSBsZWVyeSBvZiB0aGF0IHdoZW4gSSBzdWdnZXN0 ZWQgaXQsIGFuZCB0aGlzIGtlZXBzIHRoZSBjb25uZWN0aW9uIElEIGluIHRoZSBzYW1lIHBsYWNl IGluIGV2ZXJ5IHBhY2tldC4pDQoNClRoZSBjb25uZWN0aW9uIElEIGZvbGxvd3Mgb24gdGhlIG5l eHQgOCBvY3RldHMuDQoNCklmIHdlIG5lZWQgbW9yZSBiaXRzLCB0aGVuIHdlIGNhbiBzdGVhbCB0 aGVtIGZyb20gdGhlIHBhY2tldCBudW1iZXIuDQoNCg== From nobody Thu Feb 9 10:31:51 2017 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 9781F129C4C for ; Thu, 9 Feb 2017 10:31:49 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0cNi2dQIlMOE for ; Thu, 9 Feb 2017 10:31:47 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::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 87DE4129C48 for ; Thu, 9 Feb 2017 10:31:46 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id c85so239777695wmi.1 for ; Thu, 09 Feb 2017 10:31:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aA5EFRBiBr6TDk+EVIoMxsGwwTCD6pQ4v0+ItXz5eLg=; b=IwirMBR/olBgQUwfX6A212LRq0bxZXpUz/7H7Ll/RLBxDTqpKMYbplnjMrifBUnVS/ t1/BMUhgQDd76Uvxi5RSDoIynddHNiSSTr93Lf+JDZtxfTEbOXzpSCJJby6SFQT8Z0Rx 4IKAbz622z7E+CXztVff6koWpD0EEA3BuU5EKVR0s0AVaKNk0oDiY1dyZ83oPB88qZow VOlO51q5MUA9Xt5aqosKIHBEAGod01dZQBlVDE51YtELUYBK5WyBoEy8l246ABIXJ0qr RaSpRbnjH7aVHElWNtk82kDLJTHcNI54Hw+fzTGvkp/ngvOYQPMiU93WpCzsj0hiW8bd CgSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aA5EFRBiBr6TDk+EVIoMxsGwwTCD6pQ4v0+ItXz5eLg=; b=B0tzJk7QKJ9zNsjbVmSaBe/FBK2H/0zB9SHzHmb77SGNrn9KwcXB4brIUpAmEtvB0j 7CkMg2mII/Q6Zel3Frb37jQl/wusVQu7EGWWuggbLqwFZE0giiEF9p5HcMQwGYS8Q5Nd eRyr5IL1kPFZgKLEAAQS9O5t/0l4FR4jz1EZRUm46py0pfDzJ+5VYu+bxzncidNYdSEn 6dvo4dMDG7dW1tc1e1sFawGGkxaGMqLdFy8GUZCMGtVWNhaUzaOnuuhwr0IK3YBUujNT XMnt2SJ/xwFknsJ/8WpaO0ph52KRGGSR9bzvBDQSD7YRt6MttUBLI07247vCfEoNxOOG 4oog== X-Gm-Message-State: AMke39nuKwB3Per0jXKU3VQWNR2hW/PoQdaw/9Q2gRwEtkvNS817E02DjUb0BLPMZpXutVQypBJ9vCJ9M2cWklwA X-Received: by 10.28.128.205 with SMTP id b196mr4200785wmd.21.1486665104687; Thu, 09 Feb 2017 10:31:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Thu, 9 Feb 2017 10:31:43 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 9 Feb 2017 10:31:43 -0800 Message-ID: Subject: Re: Proposal for QUIC header To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1141e66478086a05481d3106 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 18:31:49 -0000 --001a1141e66478086a05481d3106 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson wrote: > As I go through the issues list, it appears that a lot of issues on > which we have consensus would benefit from a resolution to the header > format issue. To that end, I have sketched out a proposal that I > think meets the various constraints we have. > > I want to discuss this here before we embark on what could be a fairly > disruptive set of changes to the drafts. > > (A copy of the following text can be found at > https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8 > ) > -- > > There are two forms of QUIC common header: long and short. Long form > packets > are used for the initial exchange - until both 1-RTT packet protection ca= n > be > started AND version negotiation is complete. Short form packets carry th= e > bulk of the data. > > This removes a lot of the flexibility that was the source of most of the > objections to the current format. Fields are aligned on four octet > boundaries. > All long-form header variations have the exact same form. The connection > ID is > in the same place in both short and long form. The long form clearly > identifies the role of the sender in the first octet and it identifies th= e > packet as a QUIC packet. > > The cost is that it makes occasional packets a little larger (the long > header > is 20 octets, whereas the existing form uses between 14 and 19 octets > for initial > handshake packets). This is an acceptable trade-off given that only a fe= w > of > these packets are ever exchanged on a connection. > > It makes most packets (the short header) 12 octets where it is possible t= o > have 10 octet packets. =E2=80=8BIn currently deployed QUIC, 1-RTT packets from the server to the c= lient do not have connection ID present. (This is because an endpoint tells the peer how many connection=E2=80=8B ID bits it needs the peer to send. In the case= of clients, since they only have 1 connection on a given socket, the connection ID is not needed.). These packets also typically have a 1 or 2 byte packet number. So the header ends up being: 1 byte public flags + 1 or 2 byte packet number for a total of 2-3 bytes. This new format seems to be much larger. > However, a 10 octet packet header assumes an 8 bit > packet number, this is 30. > I don't think I understand how to construct a 10 octet packet. Can you elaborate? > # Long Header > > ``` > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |S|Typ| Next | Magic "uic"/"UIC" | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Connection ID + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | [Header Extensions] ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ``` > > The first four octets: > * Octet 0: Special > * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) > * Bit 6-5: Type > * 11 - client packet > * 10 - server packet > * 01 - public reset > * 00 - version negotiation > * Bits 4-0: Next protocol > * 0b10001 indicates that it is QUIC handshake data > * 0b01111 indicates that it is QUIC 0-RTT data > * other values mean that the payload following the packet number > contains > an IPv6-style extension header > * Octets 1-3: Magic (this can be short given that we will have a MAC as > well) > * 0x756963 for a client, > * 0x554943 for a server > > Note: A client packet starts with "quic", server starts with "QUIC", > 0-RTT starts > with "ouic". > > Note(2): We might consider the second set of 7 bits to be a single code > space, > rather than use a 2+5 bit partitioning. That gives us a bit more > flexibility > and avoids meaningless combinations like public reset + 0-RTT. > > The remainder of the packet layout is the same regardless of type, the > difference > being what rules for how to fill the values out and their semantics. > > A client packet then contains: > * Octets 4-11: connection ID (initially all zeroes/random) > * Octets 12-15: version > * Octets 16-19: packet number (low 4 octets, starts at a random 32-bit > value) > * Octets 20+: payload > > Note: I'm not sure whether the client should pack the connection ID with > random > values. They would have no semantic value, though they might serve to > provide > proof that the server received the packet if we require echoing, see belo= w. > =E2=80=8B > A server packet contains a connection ID: > * Octets 4-11: connection ID (server-selected value) > * Octets 12-15: version (echoed) > * Octets 16-19: packet number (low 4 octets, random 32-bit initial value) > * Octets 20+: payload > > A version negotiation packet contains: > * Octets 4-11: connection ID (echoed) > * Octets 12-15: version received (echoed) > * Octets 16-19: packet number (echoed) > * Octets 20+: payload =3D version list > In order for the server to echo back the packet number, the server obviously needs to be able parse the packet number. But if the packet contains a version that the server does not support, it may well be the case that the packet number layout may be different in the new version. So I'm not sure it's possible to echo back the packet number. =E2=80=8B > A public reset packet contains: > * Octets 4-11: connection ID (echoed) > * Octets 12-15: version (echoed) > * Octets 16-19: rejected packet number (echoed) > * Octets 20+: payload =3D authentication data > =E2=80=8BPublic reset packets are commonly sent when a server receives a pa= cket for a connection it does not have state for. (For example, a server restart or a routing hiccup). In this case, the server is responding to a packet with an unknown version and consequently and unknown packet number. So I'm not sure it's possible to echo back the packet number. =E2=80=8B > Echoing details from the packet in both version negotiation and provides > return > routeability on version negotiation (#244), while maintaining a consisten= t > header shape for all packets. > > These long-form packets are used for anything that doesn't have 1-RTT > packet > protection and prior to the completion of version negotiation. Once both > conditions are met, switch to sending short-form packets. I haven't > defined any > 5/7-bit code for protected long-form packets, but that's easy to do if we > need > to provide for them (see below for more on this). > > > ## Extension headers > > An 8-bit space (like IPv6) carries an identifier for the protocol > extension. > > Each header extension takes the form: > * Octet 1: next identifier > * Octet 2: length > > Since only the lower 5 (or 7) bits of this space is accessible from the > outset, > 0x00 is reserved for a null extension header, allowing the full space to = be > unlocked. 0x?a can be used for greasing. > > I haven't talked to IP-layer people about whether they consider the IPv6 > scheme > this is based on to be successful. Either way, this should at least have > plenty > of hardware support. > > FWIW, I'm not sure that we need the complexity that this adds. It's not > clear > that there is a motivating use case. However, on balance it's probably > worth > putting something in for the moment. If it turns out that we don't use i= t > and > can't find even a potential use case, then removing it is simple enough. > > That said, this form could be used to pack a TLS Finished into 1-RTT > packets if > we define a 5- or 7-bit code for "small bit of handshake, followed by > more", > after which we can include a 1-RTT payload. > > > # Short Header > > ``` > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > |S|K| Packet Number (30) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Connection ID + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ``` > > The short form header is defined to be specific to a version. Anything > can change between protocol versions. > > A short packet header - in this version - reserves two bits from the firs= t > octet: > * SHORT_HEADER bit 7 (0x80) =3D 1, > * KEY_PHASE bit 6 (0x40) =3D 0 initially > > The remainder of the first four octets contain the packet number. 30 bit= s > should be plenty. If a need is found for more flags, those can steal upp= er > bits from the packet number. (Frankly, I suspect that 14 bits might be > enough, but Ian was a little leery of that when I suggested it, and this > keeps the connection ID in the same place in every packet.) > > The connection ID follows on the next 8 octets. > > If we need more bits, then we can steal them from the packet number. > > --001a1141e66478086a05481d3106 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson <martin.thomson@gmail.com&= gt; wrote:
As I= go through the issues list, it appears that a lot of issues on
which we have consensus would benefit from a resolution to the header
format issue.=C2=A0 To that end, I have sketched out a proposal that I
think meets the various constraints we have.

I want to discuss this here before we embark on what could be a fairly
disruptive set of changes to the drafts.

(A copy of the following text can be found at
https://gist.github.com/martinthomson/744d04cbcec9be= 554f2f8e7bae2715b8
)
--

There are two forms of QUIC common header: long and short.=C2=A0 Long form = packets
are used for the initial exchange - until both 1-RTT packet protection can = be
started AND version negotiation is complete.=C2=A0 Short form packets carry= the
bulk of the data.

This removes a lot of the flexibility that was the source of most of the objections to the current format.=C2=A0 Fields are aligned on four octet bo= undaries.
All long-form header variations have the exact same form.=C2=A0 The connect= ion ID is
in the same place in both short and long form.=C2=A0 The long form clearly<= br> identifies the role of the sender in the first octet and it identifies the<= br> packet as a QUIC packet.

The cost is that it makes occasional packets a little larger (the long head= er
is 20 octets, whereas the existing form uses between 14 and 19 octets
for initial
handshake packets).=C2=A0 This is an acceptable trade-off given that only a= few of
these packets are ever exchanged on a connection.

It makes most packets (the short header) 12 octets where it is possible to<= br> have 10 octet packets.=C2=A0

=E2=80=8BIn currently dep= loyed QUIC, 1-RTT packets from the server to the client do not have connect= ion ID present. (This is because an endpoint tells the peer how many connec= tion=E2=80=8B ID bits it needs the peer to send. In the case of clients, si= nce they only have 1 connection on a given socket, the connection ID is not= needed.). These packets also typically have a 1 or 2 byte packet number. S= o the header ends up being: =C2=A01 byte public flags + 1 or 2 byte packet = number for a total of 2-3 bytes. This new format seems to be much larger.
=C2=A0
However, a 10 octet packet header assumes an 8 bit
packet number, this is 30.

# Long Header

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|S|Typ|=C2=A0 Next=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Magic "uic"/"UIC"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Version=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Packet Number=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Header Extensions]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Payload=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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The first four octets:
* Octet 0: Special
=C2=A0 * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here)
=C2=A0 * Bit 6-5: Type
=C2=A0 =C2=A0 * 11 - client packet
=C2=A0 =C2=A0 * 10 - server packet
=C2=A0 =C2=A0 * 01 - public reset
=C2=A0 =C2=A0 * 00 - version negotiation
=C2=A0 * Bits 4-0: Next protocol
=C2=A0 =C2=A0 * 0b10001 indicates that it is QUIC handshake data
=C2=A0 =C2=A0 * 0b01111 indicates that it is QUIC 0-RTT data
=C2=A0 =C2=A0 * other values mean that the payload following the packet num= ber contains
=C2=A0 =C2=A0 =C2=A0an IPv6-style extension header
* Octets 1-3: Magic (this can be short given that we will have a MAC as wel= l)
=C2=A0 * 0x756963 for a client,
=C2=A0 * 0x554943 for a server

Note: A client packet starts with "quic", server starts with &quo= t;QUIC",
0-RTT starts
with "ouic".

Note(2): We might consider the second set of 7 bits to be a single code spa= ce,
rather than use a 2+5 bit partitioning.=C2=A0 That gives us a bit more flex= ibility
and avoids meaningless combinations like public reset + 0-RTT.

The remainder of the packet layout is the same regardless of type, the
difference
being what rules for how to fill the values out and their semantics.

A client packet then contains:
* Octets 4-11: connection ID (initially all zeroes/random)
* Octets 12-15: version
* Octets 16-19: packet number (low 4 octets, starts at a random 32-bit valu= e)
* Octets 20+: payload

Note: I'm not sure whether the client should pack the connection ID wit= h random
values.=C2=A0 They would have no semantic value, though they might serve to= provide
proof that the server received the packet if we require echoing, see below.= =E2=80=8B

A server packet contains a connection ID:
* Octets 4-11: connection ID (server-selected value)
* Octets 12-15: version (echoed)
* Octets 16-19: packet number (low 4 octets, random 32-bit initial value) * Octets 20+: payload

A version negotiation packet contains:
* Octets 4-11: connection ID (echoed)
* Octets 12-15: version received (echoed)
* Octets 16-19: packet number (echoed)
* Octets 20+: payload =3D version list

In order for the server to echo back the packet number, the server o= bviously needs to be able parse the packet number. But if the packet contai= ns a version that the server does not support, it may well be the case that= the packet number layout may be different in the new version. So I'm n= ot sure it's possible to echo back the packet number.
A public= reset packet contains:
* Octets 4-11: connection ID (echoed)
* Octets 12-15: version (echoed)
* Octets 16-19: rejected packet number (echoed)
* Octets 20+: payload =3D authentication data

=E2=80=8BPublic reset packets are commonly sent when a server= receives a packet for a connection it does not have state for. (For exampl= e, a server restart or a routing hiccup). In this case, the server is respo= nding to a packet with an unknown version and consequently and unknown pack= et number. So I'm not sure it's possible to echo back the packet nu= mber.
=E2=80=8B
Echoing details from the packet in both version negotiation an= d provides return
routeability on version negotiation (#244), while maintaining a consistent<= br> header shape for all packets.

These long-form packets are used for anything that doesn't have 1-RTT p= acket
protection and prior to the completion of version negotiation.=C2=A0 Once b= oth
conditions are met, switch to sending short-form packets.=C2=A0 I haven'= ;t defined any
5/7-bit code for protected long-form packets, but that's easy to do if = we need
to provide for them (see below for more on this).


## Extension headers

An 8-bit space (like IPv6) carries an identifier for the protocol extension= .

Each header extension takes the form:
* Octet 1: next identifier
* Octet 2: length

Since only the lower 5 (or 7) bits of this space is accessible from the out= set,
0x00 is reserved for a null extension header, allowing the full space to be=
unlocked.=C2=A0 0x?a can be used for greasing.

I haven't talked to IP-layer people about whether they consider the IPv= 6 scheme
this is based on to be successful.=C2=A0 Either way, this should at least h= ave plenty
of hardware support.

FWIW, I'm not sure that we need the complexity that this adds.=C2=A0 It= 's not clear
that there is a motivating use case.=C2=A0 =C2=A0However, on balance it'= ;s probably worth
putting something in for the moment.=C2=A0 If it turns out that we don'= t use it and
can't find even a potential use case, then removing it is simple enough= .

That said, this form could be used to pack a TLS Finished into 1-RTT packet= s if
we define a 5- or 7-bit code for "small bit of handshake, followed by = more",
after which we can include a 1-RTT payload.


# Short Header

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|S|K|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packet Number = (30)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The short form header is defined to be specific to a version.=C2=A0 Anythin= g
can change between protocol versions.

A short packet header - in this version - reserves two bits from the first<= br> octet:
* SHORT_HEADER bit 7 (0x80) =3D 1,
* KEY_PHASE bit 6 (0x40) =3D 0 initially

The remainder of the first four octets contain the packet number.=C2=A0 30 = bits
should be plenty.=C2=A0 If a need is found for more flags, those can steal = upper
bits from the packet number.=C2=A0 (Frankly, I suspect that 14 bits might b= e
enough, but Ian was a little leery of that when I suggested it, and this keeps the connection ID in the same place in every packet.)

The connection ID follows on the next 8 octets.

If we need more bits, then we can steal them from the packet number.


--001a1141e66478086a05481d3106-- From nobody Thu Feb 9 11:58:04 2017 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 881AE129C6B for ; Thu, 9 Feb 2017 11:57:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 F38hi05Gw8wb for ; Thu, 9 Feb 2017 11:57:56 -0800 (PST) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46323129C5D for ; Thu, 9 Feb 2017 11:57:54 -0800 (PST) Received: by mail-yb0-x232.google.com with SMTP id o65so4759425ybo.2 for ; Thu, 09 Feb 2017 11:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YKlUPuv9Rfk85Gy8TqDj3eJcisUngvtrAIAfYzWQLmU=; b=mszr8ALn9GBsJ8OjFJ9Xt/a/6AuVAGI/5mRkQCRHm6yR/mFPRuOU0851FQoJA5tuKp obBTaQAkuYMqdx17BMebRWIGSp8pMrgSkiAYpoN203WI5bfDRfN+buh7yiO1sfCx/d9m MFrG3+iXvYHeDnIXJsWa40PzVyFiCVQALJ8HnsuYRZnPJ0Y48y2VIC4DQoeu7zXm+BMR oqs6L1AqKnbGKcuB4WrwdVkA4qkeLBEAGI/UINJ7JUIj8Mt3HnjF3bgjJlFcUMN8m0Ji IPYQpurTeyWZIBO+Dg8y5JjsbJMm87U6wuJvjZp4NSVZgnMXSPOIVD7nBiGc7Bx8xnoy CJnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YKlUPuv9Rfk85Gy8TqDj3eJcisUngvtrAIAfYzWQLmU=; b=VHmUmlOXO7wQqsXV08nh4btdrctWC56L4yzphWHMiAG0JwlZcLZYwVNKcx7PhM5x30 AJQF10D5fk9FrGsROnr1opCu40N/0rtZpQgR0GNnwBs7udrDF0f+lMiRwdQGQJS/LtFG 55L8FymmgX1RQkK2JsDw8ELkevWr5wlKWPhWgAn2uK3Nk9FXxwUJ2AGKM/nZggYAIMii IOAWFGH2dq3iug8DboSKwwunEu9kCoV5QiS4DwD+3cU0Lfi92BPZHijEqWuK7ukhhxfF lUQyOkNMq04/EmkXOCTWsCRV/98Jkck+sisrxZast44YcRbYUqmO2hARIxWy3wBmsCEy UR7w== X-Gm-Message-State: AMke39n8m1YtQf0X1A1acYn15ficAk41lnUr6SN6L90wDaqvTZS7CNNWAO0t9WZoxw2JNZusd3ejkOqLHGA06lPC X-Received: by 10.37.204.209 with SMTP id l200mr3741130ybf.158.1486670273262; Thu, 09 Feb 2017 11:57:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Thu, 9 Feb 2017 11:57:32 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 9 Feb 2017 14:57:32 -0500 Message-ID: Subject: Re: Proposal for QUIC header To: Ryan Hamilton Content-Type: multipart/alternative; boundary=94eb2c07bca889921a05481e658c Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 19:57:59 -0000 --94eb2c07bca889921a05481e658c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks for taking a crack at this. I have a few high-level comments. 1) This implicitly requires the connection ID to always be stated, which as Ryan said, inflates the packet header substantially from the status quo of what we send server to client, which I'm not a fan of from a practical perspective. Equally importantly, I think we need to resolve the conversation about privacy and connection IDs before we know whether we should always be sending the connection ID. 2) I believe we may want to add packet number echo bit(#269 ) and possibly a loss detection bit(#279 ) on every packet. I think it makes sense to resolve these before redesigning the packet header, since I believe it would substantially change your current design? 3) This proposes header extensions, which seems orthogonal to the header redesign. I'm not a fan of header extensions at the moment, but I think it deserves a separate conversation. So I would be biased towards getting some clarity on the connection id privacy question as well as the #269 and #279 before attempting a holistic redesign of the packet header. On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton wrote: > > > On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson > wrote: > >> As I go through the issues list, it appears that a lot of issues on >> which we have consensus would benefit from a resolution to the header >> format issue. To that end, I have sketched out a proposal that I >> think meets the various constraints we have. >> >> I want to discuss this here before we embark on what could be a fairly >> disruptive set of changes to the drafts. >> >> (A copy of the following text can be found at >> https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8 >> ) >> -- >> >> There are two forms of QUIC common header: long and short. Long form >> packets >> are used for the initial exchange - until both 1-RTT packet protection >> can be >> started AND version negotiation is complete. Short form packets carry t= he >> bulk of the data. >> >> This removes a lot of the flexibility that was the source of most of the >> objections to the current format. Fields are aligned on four octet >> boundaries. >> All long-form header variations have the exact same form. The connectio= n >> ID is >> in the same place in both short and long form. The long form clearly >> identifies the role of the sender in the first octet and it identifies t= he >> packet as a QUIC packet. >> >> The cost is that it makes occasional packets a little larger (the long >> header >> is 20 octets, whereas the existing form uses between 14 and 19 octets >> for initial >> handshake packets). This is an acceptable trade-off given that only a >> few of >> these packets are ever exchanged on a connection. >> >> It makes most packets (the short header) 12 octets where it is possible = to >> have 10 octet packets. > > > =E2=80=8BIn currently deployed QUIC, 1-RTT packets from the server to the= client > do not have connection ID present. (This is because an endpoint tells the > peer how many connection=E2=80=8B ID bits it needs the peer to send. In t= he case of > clients, since they only have 1 connection on a given socket, the > connection ID is not needed.). These packets also typically have a 1 or 2 > byte packet number. So the header ends up being: 1 byte public flags + 1 > or 2 byte packet number for a total of 2-3 bytes. This new format seems t= o > be much larger. > > >> However, a 10 octet packet header assumes an 8 bit >> packet number, this is 30. >> > > I don't think I understand how to construct a 10 octet packet. Can you > elaborate? > > >> # Long Header >> >> ``` >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |S|Typ| Next | Magic "uic"/"UIC" | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + Connection ID + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Version | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Packet Number | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | [Header Extensions] ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ``` >> >> The first four octets: >> * Octet 0: Special >> * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) >> * Bit 6-5: Type >> * 11 - client packet >> * 10 - server packet >> * 01 - public reset >> * 00 - version negotiation >> * Bits 4-0: Next protocol >> * 0b10001 indicates that it is QUIC handshake data >> * 0b01111 indicates that it is QUIC 0-RTT data >> * other values mean that the payload following the packet number >> contains >> an IPv6-style extension header >> * Octets 1-3: Magic (this can be short given that we will have a MAC as >> well) >> * 0x756963 for a client, >> * 0x554943 for a server >> >> Note: A client packet starts with "quic", server starts with "QUIC", >> 0-RTT starts >> with "ouic". >> >> Note(2): We might consider the second set of 7 bits to be a single code >> space, >> rather than use a 2+5 bit partitioning. That gives us a bit more >> flexibility >> and avoids meaningless combinations like public reset + 0-RTT. >> >> The remainder of the packet layout is the same regardless of type, the >> difference >> being what rules for how to fill the values out and their semantics. >> >> A client packet then contains: >> * Octets 4-11: connection ID (initially all zeroes/random) >> * Octets 12-15: version >> * Octets 16-19: packet number (low 4 octets, starts at a random 32-bit >> value) >> * Octets 20+: payload >> >> Note: I'm not sure whether the client should pack the connection ID with >> random >> values. They would have no semantic value, though they might serve to >> provide >> proof that the server received the packet if we require echoing, see >> below.=E2=80=8B > > >> A server packet contains a connection ID: >> * Octets 4-11: connection ID (server-selected value) >> * Octets 12-15: version (echoed) >> * Octets 16-19: packet number (low 4 octets, random 32-bit initial value= ) >> * Octets 20+: payload >> >> A version negotiation packet contains: >> * Octets 4-11: connection ID (echoed) >> * Octets 12-15: version received (echoed) >> * Octets 16-19: packet number (echoed) >> * Octets 20+: payload =3D version list >> > > In order for the server to echo back the packet number, the server > obviously needs to be able parse the packet number. But if the packet > contains a version that the server does not support, it may well be the > case that the packet number layout may be different in the new version. S= o > I'm not sure it's possible to echo back the packet number. > =E2=80=8B > >> A public reset packet contains: >> * Octets 4-11: connection ID (echoed) >> * Octets 12-15: version (echoed) >> * Octets 16-19: rejected packet number (echoed) >> * Octets 20+: payload =3D authentication data >> > > =E2=80=8BPublic reset packets are commonly sent when a server receives a = packet > for a connection it does not have state for. (For example, a server resta= rt > or a routing hiccup). In this case, the server is responding to a packet > with an unknown version and consequently and unknown packet number. So I'= m > not sure it's possible to echo back the packet number. > =E2=80=8B > >> Echoing details from the packet in both version negotiation and provides >> return >> routeability on version negotiation (#244), while maintaining a consiste= nt >> header shape for all packets. >> >> These long-form packets are used for anything that doesn't have 1-RTT >> packet >> protection and prior to the completion of version negotiation. Once bot= h >> conditions are met, switch to sending short-form packets. I haven't >> defined any >> 5/7-bit code for protected long-form packets, but that's easy to do if w= e >> need >> to provide for them (see below for more on this). >> >> >> ## Extension headers >> >> An 8-bit space (like IPv6) carries an identifier for the protocol >> extension. >> >> Each header extension takes the form: >> * Octet 1: next identifier >> * Octet 2: length >> >> Since only the lower 5 (or 7) bits of this space is accessible from the >> outset, >> 0x00 is reserved for a null extension header, allowing the full space to >> be >> unlocked. 0x?a can be used for greasing. >> >> I haven't talked to IP-layer people about whether they consider the IPv6 >> scheme >> this is based on to be successful. Either way, this should at least hav= e >> plenty >> of hardware support. >> >> FWIW, I'm not sure that we need the complexity that this adds. It's not >> clear >> that there is a motivating use case. However, on balance it's probably >> worth >> putting something in for the moment. If it turns out that we don't use >> it and >> can't find even a potential use case, then removing it is simple enough. >> >> That said, this form could be used to pack a TLS Finished into 1-RTT >> packets if >> we define a 5- or 7-bit code for "small bit of handshake, followed by >> more", >> after which we can include a 1-RTT payload. >> >> >> # Short Header >> >> ``` >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> |S|K| Packet Number (30) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + Connection ID + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ``` >> >> The short form header is defined to be specific to a version. Anything >> can change between protocol versions. >> >> A short packet header - in this version - reserves two bits from the fir= st >> octet: >> * SHORT_HEADER bit 7 (0x80) =3D 1, >> * KEY_PHASE bit 6 (0x40) =3D 0 initially >> >> The remainder of the first four octets contain the packet number. 30 bi= ts >> should be plenty. If a need is found for more flags, those can steal >> upper >> bits from the packet number. (Frankly, I suspect that 14 bits might be >> enough, but Ian was a little leery of that when I suggested it, and this >> keeps the connection ID in the same place in every packet.) >> >> The connection ID follows on the next 8 octets. >> >> If we need more bits, then we can steal them from the packet number. >> >> > --94eb2c07bca889921a05481e658c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks for taking a crack at this.=C2=A0 I have a few high= -level comments.

1) This implicitly requires the connection ID= to always be stated, which as Ryan said, inflates the packet header substa= ntially from the status quo of what we send server to client, which I'm= not a fan of from a practical perspective.=C2=A0 Equally importantly, I th= ink we need to resolve the conversation about privacy and connection IDs be= fore we know whether we should always be sending the connection ID.
2) I believe we may want to add packet number echo bit(#269) and possibly a loss d= etection bit(#= 279) on every packet.=C2=A0 I think it makes sense to resolve these bef= ore redesigning the packet header, since I believe it would substantially c= hange your current design?
3) This proposes header extensions, wh= ich seems orthogonal to the header redesign.=C2=A0 I'm not a fan of hea= der extensions at the moment, but I think it deserves a separate conversati= on.

So I would be biased towards getting some clar= ity on the connection id privacy question as well as the #269 and #279 befo= re attempting a holistic redesign of the packet header.

On Thu, Feb 9, 2017= at 1:31 PM, Ryan Hamilton <rch@google.com> wrote:


On W= ed, Feb 8, 2017 at 8:42 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
As I go through the issues list, it appear= s that a lot of issues on
which we have consensus would benefit from a resolution to the header
format issue.=C2=A0 To that end, I have sketched out a proposal that I
think meets the various constraints we have.

I want to discuss this here before we embark on what could be a fairly
disruptive set of changes to the drafts.

(A copy of the following text can be found at
https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae= 2715b8
)
--

There are two forms of QUIC common header: long and short.=C2=A0 Long form = packets
are used for the initial exchange - until both 1-RTT packet protection can = be
started AND version negotiation is complete.=C2=A0 Short form packets carry= the
bulk of the data.

This removes a lot of the flexibility that was the source of most of the objections to the current format.=C2=A0 Fields are aligned on four octet bo= undaries.
All long-form header variations have the exact same form.=C2=A0 The connect= ion ID is
in the same place in both short and long form.=C2=A0 The long form clearly<= br> identifies the role of the sender in the first octet and it identifies the<= br> packet as a QUIC packet.

The cost is that it makes occasional packets a little larger (the long head= er
is 20 octets, whereas the existing form uses between 14 and 19 octets
for initial
handshake packets).=C2=A0 This is an acceptable trade-off given that only a= few of
these packets are ever exchanged on a connection.

It makes most packets (the short header) 12 octets where it is possible to<= br> have 10 octet packets.=C2=A0

=E2=80=8BIn c= urrently deployed QUIC, 1-RTT packets from the server to the client do not = have connection ID present. (This is because an endpoint tells the peer how= many connection=E2=80=8B ID bits it needs the peer to send. In the case of= clients, since they only have 1 connection on a given socket, the connecti= on ID is not needed.). These packets also typically have a 1 or 2 byte pack= et number. So the header ends up being: =C2=A01 byte public flags + 1 or 2 = byte packet number for a total of 2-3 bytes. This new format seems to be mu= ch larger.
=C2=A0
However, a 10 octet packet header assumes= an 8 bit
packet number, this is 30.

I don't think I understand how to construct a 10 octet packet. C= an you elaborate?
=C2=A0
# Long Header

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|S|Typ|=C2=A0 Next=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Magic "uic"/"UIC"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Version=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Packet Number=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Header Extensions]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Payload=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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The first four octets:
* Octet 0: Special
=C2=A0 * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here)
=C2=A0 * Bit 6-5: Type
=C2=A0 =C2=A0 * 11 - client packet
=C2=A0 =C2=A0 * 10 - server packet
=C2=A0 =C2=A0 * 01 - public reset
=C2=A0 =C2=A0 * 00 - version negotiation
=C2=A0 * Bits 4-0: Next protocol
=C2=A0 =C2=A0 * 0b10001 indicates that it is QUIC handshake data
=C2=A0 =C2=A0 * 0b01111 indicates that it is QUIC 0-RTT data
=C2=A0 =C2=A0 * other values mean that the payload following the packet num= ber contains
=C2=A0 =C2=A0 =C2=A0an IPv6-style extension header
* Octets 1-3: Magic (this can be short given that we will have a MAC as wel= l)
=C2=A0 * 0x756963 for a client,
=C2=A0 * 0x554943 for a server

Note: A client packet starts with "quic", server starts with &quo= t;QUIC",
0-RTT starts
with "ouic".

Note(2): We might consider the second set of 7 bits to be a single code spa= ce,
rather than use a 2+5 bit partitioning.=C2=A0 That gives us a bit more flex= ibility
and avoids meaningless combinations like public reset + 0-RTT.

The remainder of the packet layout is the same regardless of type, the
difference
being what rules for how to fill the values out and their semantics.

A client packet then contains:
* Octets 4-11: connection ID (initially all zeroes/random)
* Octets 12-15: version
* Octets 16-19: packet number (low 4 octets, starts at a random 32-bit valu= e)
* Octets 20+: payload

Note: I'm not sure whether the client should pack the connection ID wit= h random
values.=C2=A0 They would have no semantic value, though they might serve to= provide
proof that the server received the packet if we require echoing, see below.= =E2=80=8B

A server packet contains a connection ID:
* Octets 4-11: connection ID (server-selected value)
* Octets 12-15: version (echoed)
* Octets 16-19: packet number (low 4 octets, random 32-bit initial value) * Octets 20+: payload

A version negotiation packet contains:
* Octets 4-11: connection ID (echoed)
* Octets 12-15: version received (echoed)
* Octets 16-19: packet number (echoed)
* Octets 20+: payload =3D version list

In order for the server to echo back the packet number, = the server obviously needs to be able parse the packet number. But if the p= acket contains a version that the server does not support, it may well be t= he case that the packet number layout may be different in the new version. = So I'm not sure it's possible to echo back the packet number.
=
=E2=80=8B
A public reset packet contains:
* Octets 4-11: connection ID (echoed)
* Octets 12-15: version (echoed)
* Octets 16-19: rejected packet number (echoed)
* Octets 20+: payload =3D authentication data

=E2=80=8BPublic reset packets are commonly sent when a= server receives a packet for a connection it does not have state for. (For= example, a server restart or a routing hiccup). In this case, the server i= s responding to a packet with an unknown version and consequently and unkno= wn packet number. So I'm not sure it's possible to echo back the pa= cket number.
=E2=80=8B
Echoing details from the packet = in both version negotiation and provides return
routeability on version negotiation (#244), while maintaining a consistent<= br> header shape for all packets.

These long-form packets are used for anything that doesn't have 1-RTT p= acket
protection and prior to the completion of version negotiation.=C2=A0 Once b= oth
conditions are met, switch to sending short-form packets.=C2=A0 I haven'= ;t defined any
5/7-bit code for protected long-form packets, but that's easy to do if = we need
to provide for them (see below for more on this).


## Extension headers

An 8-bit space (like IPv6) carries an identifier for the protocol extension= .

Each header extension takes the form:
* Octet 1: next identifier
* Octet 2: length

Since only the lower 5 (or 7) bits of this space is accessible from the out= set,
0x00 is reserved for a null extension header, allowing the full space to be=
unlocked.=C2=A0 0x?a can be used for greasing.

I haven't talked to IP-layer people about whether they consider the IPv= 6 scheme
this is based on to be successful.=C2=A0 Either way, this should at least h= ave plenty
of hardware support.

FWIW, I'm not sure that we need the complexity that this adds.=C2=A0 It= 's not clear
that there is a motivating use case.=C2=A0 =C2=A0However, on balance it'= ;s probably worth
putting something in for the moment.=C2=A0 If it turns out that we don'= t use it and
can't find even a potential use case, then removing it is simple enough= .

That said, this form could be used to pack a TLS Finished into 1-RTT packet= s if
we define a 5- or 7-bit code for "small bit of handshake, followed by = more",
after which we can include a 1-RTT payload.


# Short Header

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|S|K|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packet Number = (30)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The short form header is defined to be specific to a version.=C2=A0 Anythin= g
can change between protocol versions.

A short packet header - in this version - reserves two bits from the first<= br> octet:
* SHORT_HEADER bit 7 (0x80) =3D 1,
* KEY_PHASE bit 6 (0x40) =3D 0 initially

The remainder of the first four octets contain the packet number.=C2=A0 30 = bits
should be plenty.=C2=A0 If a need is found for more flags, those can steal = upper
bits from the packet number.=C2=A0 (Frankly, I suspect that 14 bits might b= e
enough, but Ian was a little leery of that when I suggested it, and this keeps the connection ID in the same place in every packet.)

The connection ID follows on the next 8 octets.

If we need more bits, then we can steal them from the packet number.



--94eb2c07bca889921a05481e658c-- From nobody Thu Feb 9 12:42:11 2017 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 D469A129452 for ; Thu, 9 Feb 2017 12:42:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vmS0TtyK6Mip for ; Thu, 9 Feb 2017 12:42:08 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 B82C81295A0 for ; Thu, 9 Feb 2017 12:42:07 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 35so12652190uak.1 for ; Thu, 09 Feb 2017 12:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sj4PU3J1oNtb4V5bRsMBTl7IZhSpByQdgdWl0eBquUI=; b=AbceFFTAqeh2F3gJBLhkpXBfkBfJBGkhKw5eYXSriMNNpVYlvghZTSdxLCNHpBVBQ5 aNf501avNJRIXOUXCyjYLKUxvB27PEAlNBHjD25QyTChAO0aNPbTW6tj2Cmo9Rm0g7+2 gGUWL6rCmIkVHytYOPgJ8+RnCicKcCL3OHn9Qjz132tvqx+7elRlJEEewa8jC4aZjP/J ZvEuu3RIFHmzz/49crG8oqEjRrYPkf6D8ukxxuwNRlW01uMHX52KBxegxs2SIqjH9n/1 4UFfsqM7WY2o1jSNJ5qa5MPn/QQ2LeMPZzF/FEjQ37pCPI9sjabeGfE8UyJJysxvZHn0 wdaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sj4PU3J1oNtb4V5bRsMBTl7IZhSpByQdgdWl0eBquUI=; b=h3pMiWvEZv4ZGnoD/9BR1vTqCYo0rdZuNKfv2SgWdJTEgXVUNPbRL1OlKQLfSvwrMf tujS83Nde4Aj09mbFEKDawtOzdoyC9ZBtoMad8qQoaAu3wqNg7JA24cgt4Dn08EqSRy2 g0KdWprLNCNbNsjhXYFjMhV+nRIzNPF+vFxYu9hpA+btIYr175u/X06Yra6Httmx8jwh F84uzAWjUKJjJBTg0wCMnOX9eCeVpASVxvNsMlkDmD0QWELx0hJnZhp+dvm/l8bnpUbP JpRX0mUPUgzU6oQKGy5jfFZgf/wDexbsf6q2yTDkTe1ooAeaSYDhSKlHnxQeTsVatrFv t9KQ== X-Gm-Message-State: AMke39mh1+pUdUaE/qSS6a5jHyarZjMB3nIY3dKlC3IJOeKhnaUrzMUb0frigexlqxgp/1gw4QiO+c3Y1CYtYZLv X-Received: by 10.159.54.205 with SMTP id p71mr2195658uap.61.1486672926522; Thu, 09 Feb 2017 12:42:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 9 Feb 2017 12:42:05 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 9 Feb 2017 12:42:05 -0800 Message-ID: Subject: Re: Proposal for QUIC header To: Ian Swett Content-Type: multipart/alternative; boundary=94eb2c03d92aaf617005481f0300 Archived-At: Cc: IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 20:42:11 -0000 --94eb2c03d92aaf617005481f0300 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Martin, I like that you've separated the early handshake packet format from the "common case" format -- there may be value in having that separation when thinking about overhead and header formats (earlier versions of the transport draft talked about Regular and Special packets, which may be worth reconsidering.) That said, I think this proposal conflates three things: (i) it attempts to compress the header, in some cases (ii) it changes the header in ways which have been suggested but without consensus (connection ID, magic field) (iii) it adds extensibility in ways that are not yet justified. I think the proposal is useful in that it shows how the header might look in a different world. But let's get consensus on what's reasonable to do before figuring out how to do it. Specifically, as Ian notes, #269 and #279 are existing issues, and we need to discuss things like the magic header field before adding them in (is there an issue for this?) I propose parking this for now. - jana On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett wrote: > Thanks for taking a crack at this. I have a few high-level comments. > > 1) This implicitly requires the connection ID to always be stated, which > as Ryan said, inflates the packet header substantially from the status qu= o > of what we send server to client, which I'm not a fan of from a practical > perspective. Equally importantly, I think we need to resolve the > conversation about privacy and connection IDs before we know whether we > should always be sending the connection ID. > 2) I believe we may want to add packet number echo bit(#269 > ) and possibly a loss > detection bit(#279 ) on > every packet. I think it makes sense to resolve these before redesigning > the packet header, since I believe it would substantially change your > current design? > 3) This proposes header extensions, which seems orthogonal to the header > redesign. I'm not a fan of header extensions at the moment, but I think = it > deserves a separate conversation. > > So I would be biased towards getting some clarity on the connection id > privacy question as well as the #269 and #279 before attempting a holisti= c > redesign of the packet header. > > On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton wrote: > >> >> >> On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson >> wrote: >> >>> As I go through the issues list, it appears that a lot of issues on >>> which we have consensus would benefit from a resolution to the header >>> format issue. To that end, I have sketched out a proposal that I >>> think meets the various constraints we have. >>> >>> I want to discuss this here before we embark on what could be a fairly >>> disruptive set of changes to the drafts. >>> >>> (A copy of the following text can be found at >>> https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8 >>> ) >>> -- >>> >>> There are two forms of QUIC common header: long and short. Long form >>> packets >>> are used for the initial exchange - until both 1-RTT packet protection >>> can be >>> started AND version negotiation is complete. Short form packets carry >>> the >>> bulk of the data. >>> >>> This removes a lot of the flexibility that was the source of most of th= e >>> objections to the current format. Fields are aligned on four octet >>> boundaries. >>> All long-form header variations have the exact same form. The >>> connection ID is >>> in the same place in both short and long form. The long form clearly >>> identifies the role of the sender in the first octet and it identifies >>> the >>> packet as a QUIC packet. >>> >>> The cost is that it makes occasional packets a little larger (the long >>> header >>> is 20 octets, whereas the existing form uses between 14 and 19 octets >>> for initial >>> handshake packets). This is an acceptable trade-off given that only a >>> few of >>> these packets are ever exchanged on a connection. >>> >>> It makes most packets (the short header) 12 octets where it is possible >>> to >>> have 10 octet packets. >> >> >> =E2=80=8BIn currently deployed QUIC, 1-RTT packets from the server to th= e client >> do not have connection ID present. (This is because an endpoint tells th= e >> peer how many connection=E2=80=8B ID bits it needs the peer to send. In = the case of >> clients, since they only have 1 connection on a given socket, the >> connection ID is not needed.). These packets also typically have a 1 or = 2 >> byte packet number. So the header ends up being: 1 byte public flags + = 1 >> or 2 byte packet number for a total of 2-3 bytes. This new format seems = to >> be much larger. >> >> >>> However, a 10 octet packet header assumes an 8 bit >>> packet number, this is 30. >>> >> >> I don't think I understand how to construct a 10 octet packet. Can you >> elaborate? >> >> >>> # Long Header >>> >>> ``` >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |S|Typ| Next | Magic "uic"/"UIC" | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> + Connection ID + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Version | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Packet Number | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | [Header Extensions] ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | Payload ... >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> ``` >>> >>> The first four octets: >>> * Octet 0: Special >>> * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) >>> * Bit 6-5: Type >>> * 11 - client packet >>> * 10 - server packet >>> * 01 - public reset >>> * 00 - version negotiation >>> * Bits 4-0: Next protocol >>> * 0b10001 indicates that it is QUIC handshake data >>> * 0b01111 indicates that it is QUIC 0-RTT data >>> * other values mean that the payload following the packet number >>> contains >>> an IPv6-style extension header >>> * Octets 1-3: Magic (this can be short given that we will have a MAC as >>> well) >>> * 0x756963 for a client, >>> * 0x554943 for a server >>> >>> Note: A client packet starts with "quic", server starts with "QUIC", >>> 0-RTT starts >>> with "ouic". >>> >>> Note(2): We might consider the second set of 7 bits to be a single code >>> space, >>> rather than use a 2+5 bit partitioning. That gives us a bit more >>> flexibility >>> and avoids meaningless combinations like public reset + 0-RTT. >>> >>> The remainder of the packet layout is the same regardless of type, the >>> difference >>> being what rules for how to fill the values out and their semantics. >>> >>> A client packet then contains: >>> * Octets 4-11: connection ID (initially all zeroes/random) >>> * Octets 12-15: version >>> * Octets 16-19: packet number (low 4 octets, starts at a random 32-bit >>> value) >>> * Octets 20+: payload >>> >>> Note: I'm not sure whether the client should pack the connection ID wit= h >>> random >>> values. They would have no semantic value, though they might serve to >>> provide >>> proof that the server received the packet if we require echoing, see >>> below.=E2=80=8B >> >> >>> A server packet contains a connection ID: >>> * Octets 4-11: connection ID (server-selected value) >>> * Octets 12-15: version (echoed) >>> * Octets 16-19: packet number (low 4 octets, random 32-bit initial valu= e) >>> * Octets 20+: payload >>> >>> A version negotiation packet contains: >>> * Octets 4-11: connection ID (echoed) >>> * Octets 12-15: version received (echoed) >>> * Octets 16-19: packet number (echoed) >>> * Octets 20+: payload =3D version list >>> >> >> In order for the server to echo back the packet number, the server >> obviously needs to be able parse the packet number. But if the packet >> contains a version that the server does not support, it may well be the >> case that the packet number layout may be different in the new version. = So >> I'm not sure it's possible to echo back the packet number. >> =E2=80=8B >> >>> A public reset packet contains: >>> * Octets 4-11: connection ID (echoed) >>> * Octets 12-15: version (echoed) >>> * Octets 16-19: rejected packet number (echoed) >>> * Octets 20+: payload =3D authentication data >>> >> >> =E2=80=8BPublic reset packets are commonly sent when a server receives a= packet >> for a connection it does not have state for. (For example, a server rest= art >> or a routing hiccup). In this case, the server is responding to a packet >> with an unknown version and consequently and unknown packet number. So I= 'm >> not sure it's possible to echo back the packet number. >> =E2=80=8B >> >>> Echoing details from the packet in both version negotiation and provide= s >>> return >>> routeability on version negotiation (#244), while maintaining a >>> consistent >>> header shape for all packets. >>> >>> These long-form packets are used for anything that doesn't have 1-RTT >>> packet >>> protection and prior to the completion of version negotiation. Once bo= th >>> conditions are met, switch to sending short-form packets. I haven't >>> defined any >>> 5/7-bit code for protected long-form packets, but that's easy to do if >>> we need >>> to provide for them (see below for more on this). >>> >>> >>> ## Extension headers >>> >>> An 8-bit space (like IPv6) carries an identifier for the protocol >>> extension. >>> >>> Each header extension takes the form: >>> * Octet 1: next identifier >>> * Octet 2: length >>> >>> Since only the lower 5 (or 7) bits of this space is accessible from the >>> outset, >>> 0x00 is reserved for a null extension header, allowing the full space t= o >>> be >>> unlocked. 0x?a can be used for greasing. >>> >>> I haven't talked to IP-layer people about whether they consider the IPv= 6 >>> scheme >>> this is based on to be successful. Either way, this should at least >>> have plenty >>> of hardware support. >>> >>> FWIW, I'm not sure that we need the complexity that this adds. It's no= t >>> clear >>> that there is a motivating use case. However, on balance it's probabl= y >>> worth >>> putting something in for the moment. If it turns out that we don't use >>> it and >>> can't find even a potential use case, then removing it is simple enough= . >>> >>> That said, this form could be used to pack a TLS Finished into 1-RTT >>> packets if >>> we define a 5- or 7-bit code for "small bit of handshake, followed by >>> more", >>> after which we can include a 1-RTT payload. >>> >>> >>> # Short Header >>> >>> ``` >>> 0 1 2 3 >>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> |S|K| Packet Number (30) | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> | | >>> + Connection ID + >>> | | >>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>> ``` >>> >>> The short form header is defined to be specific to a version. Anything >>> can change between protocol versions. >>> >>> A short packet header - in this version - reserves two bits from the >>> first >>> octet: >>> * SHORT_HEADER bit 7 (0x80) =3D 1, >>> * KEY_PHASE bit 6 (0x40) =3D 0 initially >>> >>> The remainder of the first four octets contain the packet number. 30 >>> bits >>> should be plenty. If a need is found for more flags, those can steal >>> upper >>> bits from the packet number. (Frankly, I suspect that 14 bits might be >>> enough, but Ian was a little leery of that when I suggested it, and thi= s >>> keeps the connection ID in the same place in every packet.) >>> >>> The connection ID follows on the next 8 octets. >>> >>> If we need more bits, then we can steal them from the packet number. >>> >>> >> > --94eb2c03d92aaf617005481f0300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin,

I like that you've separate= d the early handshake packet format from the "common case" format= -- there may be value in having that separation when thinking about overhe= ad and header formats (earlier versions of the transport draft talked about= Regular and Special packets, which may be worth reconsidering.) That said,= I think this proposal conflates three things:=C2=A0
(i) it attem= pts to compress the header, in some cases
(ii) it changes the hea= der in ways which have been suggested but without consensus (connection ID,= magic field)
(iii) it adds extensibility in ways that are not ye= t justified.

I think the proposal is useful in tha= t it shows how the header might look in a different world. But let's ge= t consensus on what's reasonable to do before figuring out how to do it= . Specifically, as Ian notes, #269 and #279 are existing issues, and we nee= d to discuss things like the magic header field before adding them in (is t= here an issue for this?)

I propose parking this fo= r now.

- jana


On Thu, Feb 9, 2017 at 11:5= 7 AM, Ian Swett <ianswett@google.com> wrote:
Thanks for taking a crack at this.=C2= =A0 I have a few high-level comments.

1) This implicitly requi= res the connection ID to always be stated, which as Ryan said, inflates the= packet header substantially from the status quo of what we send server to = client, which I'm not a fan of from a practical perspective.=C2=A0 Equa= lly importantly, I think we need to resolve the conversation about privacy = and connection IDs before we know whether we should always be sending the c= onnection ID.
2) I believe we may want to add packet number echo = bit(#269) and possibly a loss detection bit(#279) on every = packet.=C2=A0 I think it makes sense to resolve these before redesigning th= e packet header, since I believe it would substantially change your current= design?
3) This proposes header extensions, which seems orthogon= al to the header redesign.=C2=A0 I'm not a fan of header extensions at = the moment, but I think it deserves a separate conversation.

=
So I would be biased towards getting some clarity on the connect= ion id privacy question as well as the #269 and #279 before attempting a ho= listic redesign of the packet header.

On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton <rch@google.com> wrote:

On Wed, Feb 8, 2017 at 8:42 PM, Martin T= homson <martin.thomson@gmail.com> = wrote:
As I go through= the issues list, it appears that a lot of issues on
which we have consensus would benefit from a resolution to the header
format issue.=C2=A0 To that end, I have sketched out a proposal that I
think meets the various constraints we have.

I want to discuss this here before we embark on what could be a fairly
disruptive set of changes to the drafts.

(A copy of the following text can be found at
https://gis= t.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8 )
--

There are two forms of QUIC common header: long and short.=C2=A0 Long form = packets
are used for the initial exchange - until both 1-RTT packet protection can = be
started AND version negotiation is complete.=C2=A0 Short form packets carry= the
bulk of the data.

This removes a lot of the flexibility that was the source of most of the objections to the current format.=C2=A0 Fields are aligned on four octet bo= undaries.
All long-form header variations have the exact same form.=C2=A0 The connect= ion ID is
in the same place in both short and long form.=C2=A0 The long form clearly<= br> identifies the role of the sender in the first octet and it identifies the<= br> packet as a QUIC packet.

The cost is that it makes occasional packets a little larger (the long head= er
is 20 octets, whereas the existing form uses between 14 and 19 octets
for initial
handshake packets).=C2=A0 This is an acceptable trade-off given that only a= few of
these packets are ever exchanged on a connection.

It makes most packets (the short header) 12 octets where it is possible to<= br> have 10 octet packets.=C2=A0

=E2=80=8BIn c= urrently deployed QUIC, 1-RTT packets from the server to the client do not = have connection ID present. (This is because an endpoint tells the peer how= many connection=E2=80=8B ID bits it needs the peer to send. In the case of= clients, since they only have 1 connection on a given socket, the connecti= on ID is not needed.). These packets also typically have a 1 or 2 byte pack= et number. So the header ends up being: =C2=A01 byte public flags + 1 or 2 = byte packet number for a total of 2-3 bytes. This new format seems to be mu= ch larger.
=C2=A0
However, a 10 octet packet header assumes an 8 bit packet number, this is 30.

I don't think I understand how to construct a 10 octet packet. C= an you elaborate?
=C2=A0
# Long Hea= der

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|S|Typ|=C2=A0 Next=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Magic "uic"/"UIC"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Version=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Packet Number=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Header Extensions]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Payload=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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The first four octets:
* Octet 0: Special
=C2=A0 * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here)
=C2=A0 * Bit 6-5: Type
=C2=A0 =C2=A0 * 11 - client packet
=C2=A0 =C2=A0 * 10 - server packet
=C2=A0 =C2=A0 * 01 - public reset
=C2=A0 =C2=A0 * 00 - version negotiation
=C2=A0 * Bits 4-0: Next protocol
=C2=A0 =C2=A0 * 0b10001 indicates that it is QUIC handshake data
=C2=A0 =C2=A0 * 0b01111 indicates that it is QUIC 0-RTT data
=C2=A0 =C2=A0 * other values mean that the payload following the packet num= ber contains
=C2=A0 =C2=A0 =C2=A0an IPv6-style extension header
* Octets 1-3: Magic (this can be short given that we will have a MAC as wel= l)
=C2=A0 * 0x756963 for a client,
=C2=A0 * 0x554943 for a server

Note: A client packet starts with "quic", server starts with &quo= t;QUIC",
0-RTT starts
with "ouic".

Note(2): We might consider the second set of 7 bits to be a single code spa= ce,
rather than use a 2+5 bit partitioning.=C2=A0 That gives us a bit more flex= ibility
and avoids meaningless combinations like public reset + 0-RTT.

The remainder of the packet layout is the same regardless of type, the
difference
being what rules for how to fill the values out and their semantics.

A client packet then contains:
* Octets 4-11: connection ID (initially all zeroes/random)
* Octets 12-15: version
* Octets 16-19: packet number (low 4 octets, starts at a random 32-bit valu= e)
* Octets 20+: payload

Note: I'm not sure whether the client should pack the connection ID wit= h random
values.=C2=A0 They would have no semantic value, though they might serve to= provide
proof that the server received the packet if we require echoing, see below.= =E2=80=8B

A server packet contains a connection ID:
* Octets 4-11: connection ID (server-selected value)
* Octets 12-15: version (echoed)
* Octets 16-19: packet number (low 4 octets, random 32-bit initial value) * Octets 20+: payload

A version negotiation packet contains:
* Octets 4-11: connection ID (echoed)
* Octets 12-15: version received (echoed)
* Octets 16-19: packet number (echoed)
* Octets 20+: payload =3D version list

In order for the server to echo back the packet number, = the server obviously needs to be able parse the packet number. But if the p= acket contains a version that the server does not support, it may well be t= he case that the packet number layout may be different in the new version. = So I'm not sure it's possible to echo back the packet number.
=
=E2=80=8B
A public reset packet contains:
* Octets 4-11: connection ID (echoed)
* Octets 12-15: version (echoed)
* Octets 16-19: rejected packet number (echoed)
* Octets 20+: payload =3D authentication data

=E2=80=8BPublic reset packets are commonly sent when a= server receives a packet for a connection it does not have state for. (For= example, a server restart or a routing hiccup). In this case, the server i= s responding to a packet with an unknown version and consequently and unkno= wn packet number. So I'm not sure it's possible to echo back the pa= cket number.
= =E2=80=8B
Echoing de= tails from the packet in both version negotiation and provides return
routeability on version negotiation (#244), while maintaining a consistent<= br> header shape for all packets.

These long-form packets are used for anything that doesn't have 1-RTT p= acket
protection and prior to the completion of version negotiation.=C2=A0 Once b= oth
conditions are met, switch to sending short-form packets.=C2=A0 I haven'= ;t defined any
5/7-bit code for protected long-form packets, but that's easy to do if = we need
to provide for them (see below for more on this).


## Extension headers

An 8-bit space (like IPv6) carries an identifier for the protocol extension= .

Each header extension takes the form:
* Octet 1: next identifier
* Octet 2: length

Since only the lower 5 (or 7) bits of this space is accessible from the out= set,
0x00 is reserved for a null extension header, allowing the full space to be=
unlocked.=C2=A0 0x?a can be used for greasing.

I haven't talked to IP-layer people about whether they consider the IPv= 6 scheme
this is based on to be successful.=C2=A0 Either way, this should at least h= ave plenty
of hardware support.

FWIW, I'm not sure that we need the complexity that this adds.=C2=A0 It= 's not clear
that there is a motivating use case.=C2=A0 =C2=A0However, on balance it'= ;s probably worth
putting something in for the moment.=C2=A0 If it turns out that we don'= t use it and
can't find even a potential use case, then removing it is simple enough= .

That said, this form could be used to pack a TLS Finished into 1-RTT packet= s if
we define a 5- or 7-bit code for "small bit of handshake, followed by = more",
after which we can include a 1-RTT payload.


# Short Header

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|S|K|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packet Number = (30)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The short form header is defined to be specific to a version.=C2=A0 Anythin= g
can change between protocol versions.

A short packet header - in this version - reserves two bits from the first<= br> octet:
* SHORT_HEADER bit 7 (0x80) =3D 1,
* KEY_PHASE bit 6 (0x40) =3D 0 initially

The remainder of the first four octets contain the packet number.=C2=A0 30 = bits
should be plenty.=C2=A0 If a need is found for more flags, those can steal = upper
bits from the packet number.=C2=A0 (Frankly, I suspect that 14 bits might b= e
enough, but Ian was a little leery of that when I suggested it, and this keeps the connection ID in the same place in every packet.)

The connection ID follows on the next 8 octets.

If we need more bits, then we can steal them from the packet number.




--94eb2c03d92aaf617005481f0300-- From nobody Thu Feb 9 13:39:17 2017 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 6B4BD129C9C for ; Thu, 9 Feb 2017 13:39:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 LZpLtkRQYJN6 for ; Thu, 9 Feb 2017 13:39:12 -0800 (PST) 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 9BEF4129C9D for ; Thu, 9 Feb 2017 13:39:11 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id l19so10397006ywc.2 for ; Thu, 09 Feb 2017 13:39:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RFS4DMoC/D2uxPi/CMaOBhROgFTOUsu4DC0T7bzWUeU=; b=CXZRQxoG/1c01u5a1GKjb++zBHSHf1lnUBl2TP5YbFr0TLBddfXa75wfwdVUCdqZRX qbxMRFzXxOsBHEKRxHImtmVoU3rvKahUc7AZi6+y3u/oJ2ynTlQFDF2fG5aafPajmjQr 8SJjH35/itFe2EM3IRHxzq5wT+iHKm696ZTpkC0KV8Qa7vctRENZ3hETpk6JOcwauE9m Byjpp41hANAF0PHhKQWOGXc7LjNEiakra/Vh3zA5Jalwmm41ENwa8PzPojoBtNAoxT/D grcwggUNLPa3IhIlPX8cYLUFpubiqen9jxt7YfwhQFwF+6IJNW/qVJR3V7k6VoryL3qK tdXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RFS4DMoC/D2uxPi/CMaOBhROgFTOUsu4DC0T7bzWUeU=; b=ZgiUMfT0vkY4UJfSc5On4syJ2sgBFDuIi5yteZM3vrR0PCdIfx+EqngzodOKevRx+Q o1LAr1r1qftGICPapGYNrfRnntFrWk59mGFj5kdh+18CZrJ3JHioPLNBW7Exi8/+QxJ9 DYe1lpFTiNxRz3loDJsTKnzEQaXqbWKsKNqkBYGbY3kUUqhMPDEwtcjuRKzijIHIvsAb 4lwSPdUaTJJrIH6lJ5hUG1JrW+gFo8dGSpFNyZ8sGM68Ke2Z5vAZOeP4vZZc2oGUcDCW /icrD/2Bhc90mcsOMwz9Sfj2Br6ZPY2BcB8KmqhhN2ngkKI6X4rDYcahAY+pwgx2A4aX g6zw== X-Gm-Message-State: AMke39nQfh9JAleV1mKJj1qebnlEn3f5L3vCYSPszVDnSDiN07d7rHVR5ZeOL/ua7XtDQWmv/WdGOgXB9q6pwg== X-Received: by 10.129.108.131 with SMTP id h125mr3942477ywc.71.1486676350778; Thu, 09 Feb 2017 13:39:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 9 Feb 2017 13:38:30 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 9 Feb 2017 13:38:30 -0800 Message-ID: Subject: Re: Proposal for QUIC header To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a114dcf78c95f1005481fcf1b Archived-At: Cc: Ian Swett , IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2017 21:39:15 -0000 --001a114dcf78c95f1005481fcf1b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable First, Martin, thanks for doing the work I promised to do. I've got some more things I'm going to try that with :) On Thu, Feb 9, 2017 at 12:42 PM, Jana Iyengar wrote: > Martin, > > I like that you've separated the early handshake packet format from the > "common case" format -- there may be value in having that separation when > thinking about overhead and header formats (earlier versions of the > transport draft talked about Regular and Special packets, which may be > worth reconsidering.) That said, I think this proposal conflates three > things: > (i) it attempts to compress the header, in some cases > I thought there was agreement that making the header smaller was good. Not sure how we would have consensus for that in the abstract, so we probably just need to debate whether or not this particular form of compression is good. > (ii) it changes the header in ways which have been suggested but without > consensus (connection ID, magic field) > Hmm.... I thought we did have consensus for the magic field in the interim. Of course that needs confirmation on the mailing list, but this seems like a good venue for that. I don't think we need concern ourselves with the connection ID, because this proposal neatly accommodates removing the connection ID field, either by having the server tell the client it can (with no indicator) or if we like, stealing a bit from the packet number to say ("here is a conn id"). There doesn't seem to be a percentage in removing conn id from the special packets, so we don't need to address that. (iii) it adds extensibility in ways that are not yet justified. > I think I do agree with you here, ultimately, but I'd like to leave it in for now. My reasoning here is that you often find that you have a bunch of small things that you want some flexibility for but that aren't enough to add a whole new extension point, so you just get death of a thousand cuts as you try to work around them. Contrariwise, if we have this extension point available, we can see if it gets used and pull it out before pubreq. > I think the proposal is useful in that it shows how the header might look > in a different world. But let's get consensus on what's reasonable to do > before figuring out how to do it. Specifically, as Ian notes, #269 and #2= 79 > are existing issues, and we need to discuss things like the magic header > field before adding them in (is there an issue for this?) > > I propose parking this for now. > I'd rather we hash out these issues and decide on this PR or some revision one way or the other. There's a lot of other stuff that's kind of piled up behind the packet header. -Ekr > - jana > > > On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett wrote: > >> Thanks for taking a crack at this. I have a few high-level comments. >> >> 1) This implicitly requires the connection ID to always be stated, which >> as Ryan said, inflates the packet header substantially from the status q= uo >> of what we send server to client, which I'm not a fan of from a practica= l >> perspective. Equally importantly, I think we need to resolve the >> conversation about privacy and connection IDs before we know whether we >> should always be sending the connection ID. >> 2) I believe we may want to add packet number echo bit(#269 >> ) and possibly a loss >> detection bit(#279 ) >> on every packet. I think it makes sense to resolve these before >> redesigning the packet header, since I believe it would substantially >> change your current design? >> 3) This proposes header extensions, which seems orthogonal to the header >> redesign. I'm not a fan of header extensions at the moment, but I think= it >> deserves a separate conversation. >> >> So I would be biased towards getting some clarity on the connection id >> privacy question as well as the #269 and #279 before attempting a holist= ic >> redesign of the packet header. >> >> On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton wrote: >> >>> >>> >>> On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson >> > wrote: >>> >>>> As I go through the issues list, it appears that a lot of issues on >>>> which we have consensus would benefit from a resolution to the header >>>> format issue. To that end, I have sketched out a proposal that I >>>> think meets the various constraints we have. >>>> >>>> I want to discuss this here before we embark on what could be a fairly >>>> disruptive set of changes to the drafts. >>>> >>>> (A copy of the following text can be found at >>>> https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8 >>>> ) >>>> -- >>>> >>>> There are two forms of QUIC common header: long and short. Long form >>>> packets >>>> are used for the initial exchange - until both 1-RTT packet protection >>>> can be >>>> started AND version negotiation is complete. Short form packets carry >>>> the >>>> bulk of the data. >>>> >>>> This removes a lot of the flexibility that was the source of most of t= he >>>> objections to the current format. Fields are aligned on four octet >>>> boundaries. >>>> All long-form header variations have the exact same form. The >>>> connection ID is >>>> in the same place in both short and long form. The long form clearly >>>> identifies the role of the sender in the first octet and it identifies >>>> the >>>> packet as a QUIC packet. >>>> >>>> The cost is that it makes occasional packets a little larger (the long >>>> header >>>> is 20 octets, whereas the existing form uses between 14 and 19 octets >>>> for initial >>>> handshake packets). This is an acceptable trade-off given that only a >>>> few of >>>> these packets are ever exchanged on a connection. >>>> >>>> It makes most packets (the short header) 12 octets where it is possibl= e >>>> to >>>> have 10 octet packets. >>> >>> >>> =E2=80=8BIn currently deployed QUIC, 1-RTT packets from the server to t= he client >>> do not have connection ID present. (This is because an endpoint tells t= he >>> peer how many connection=E2=80=8B ID bits it needs the peer to send. In= the case of >>> clients, since they only have 1 connection on a given socket, the >>> connection ID is not needed.). These packets also typically have a 1 or= 2 >>> byte packet number. So the header ends up being: 1 byte public flags += 1 >>> or 2 byte packet number for a total of 2-3 bytes. This new format seems= to >>> be much larger. >>> >>> >>>> However, a 10 octet packet header assumes an 8 bit >>>> packet number, this is 30. >>>> >>> >>> I don't think I understand how to construct a 10 octet packet. Can you >>> elaborate? >>> >>> >>>> # Long Header >>>> >>>> ``` >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |S|Typ| Next | Magic "uic"/"UIC" | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> + Connection ID + >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Version | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Packet Number | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | [Header Extensions] ... >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | Payload ... >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> ``` >>>> >>>> The first four octets: >>>> * Octet 0: Special >>>> * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) >>>> * Bit 6-5: Type >>>> * 11 - client packet >>>> * 10 - server packet >>>> * 01 - public reset >>>> * 00 - version negotiation >>>> * Bits 4-0: Next protocol >>>> * 0b10001 indicates that it is QUIC handshake data >>>> * 0b01111 indicates that it is QUIC 0-RTT data >>>> * other values mean that the payload following the packet number >>>> contains >>>> an IPv6-style extension header >>>> * Octets 1-3: Magic (this can be short given that we will have a MAC a= s >>>> well) >>>> * 0x756963 for a client, >>>> * 0x554943 for a server >>>> >>>> Note: A client packet starts with "quic", server starts with "QUIC", >>>> 0-RTT starts >>>> with "ouic". >>>> >>>> Note(2): We might consider the second set of 7 bits to be a single cod= e >>>> space, >>>> rather than use a 2+5 bit partitioning. That gives us a bit more >>>> flexibility >>>> and avoids meaningless combinations like public reset + 0-RTT. >>>> >>>> The remainder of the packet layout is the same regardless of type, the >>>> difference >>>> being what rules for how to fill the values out and their semantics. >>>> >>>> A client packet then contains: >>>> * Octets 4-11: connection ID (initially all zeroes/random) >>>> * Octets 12-15: version >>>> * Octets 16-19: packet number (low 4 octets, starts at a random 32-bit >>>> value) >>>> * Octets 20+: payload >>>> >>>> Note: I'm not sure whether the client should pack the connection ID >>>> with random >>>> values. They would have no semantic value, though they might serve to >>>> provide >>>> proof that the server received the packet if we require echoing, see >>>> below.=E2=80=8B >>> >>> >>>> A server packet contains a connection ID: >>>> * Octets 4-11: connection ID (server-selected value) >>>> * Octets 12-15: version (echoed) >>>> * Octets 16-19: packet number (low 4 octets, random 32-bit initial >>>> value) >>>> * Octets 20+: payload >>>> >>>> A version negotiation packet contains: >>>> * Octets 4-11: connection ID (echoed) >>>> * Octets 12-15: version received (echoed) >>>> * Octets 16-19: packet number (echoed) >>>> * Octets 20+: payload =3D version list >>>> >>> >>> In order for the server to echo back the packet number, the server >>> obviously needs to be able parse the packet number. But if the packet >>> contains a version that the server does not support, it may well be the >>> case that the packet number layout may be different in the new version.= So >>> I'm not sure it's possible to echo back the packet number. >>> =E2=80=8B >>> >>>> A public reset packet contains: >>>> * Octets 4-11: connection ID (echoed) >>>> * Octets 12-15: version (echoed) >>>> * Octets 16-19: rejected packet number (echoed) >>>> * Octets 20+: payload =3D authentication data >>>> >>> >>> =E2=80=8BPublic reset packets are commonly sent when a server receives = a packet >>> for a connection it does not have state for. (For example, a server res= tart >>> or a routing hiccup). In this case, the server is responding to a packe= t >>> with an unknown version and consequently and unknown packet number. So = I'm >>> not sure it's possible to echo back the packet number. >>> =E2=80=8B >>> >>>> Echoing details from the packet in both version negotiation and >>>> provides return >>>> routeability on version negotiation (#244), while maintaining a >>>> consistent >>>> header shape for all packets. >>>> >>>> These long-form packets are used for anything that doesn't have 1-RTT >>>> packet >>>> protection and prior to the completion of version negotiation. Once >>>> both >>>> conditions are met, switch to sending short-form packets. I haven't >>>> defined any >>>> 5/7-bit code for protected long-form packets, but that's easy to do if >>>> we need >>>> to provide for them (see below for more on this). >>>> >>>> >>>> ## Extension headers >>>> >>>> An 8-bit space (like IPv6) carries an identifier for the protocol >>>> extension. >>>> >>>> Each header extension takes the form: >>>> * Octet 1: next identifier >>>> * Octet 2: length >>>> >>>> Since only the lower 5 (or 7) bits of this space is accessible from th= e >>>> outset, >>>> 0x00 is reserved for a null extension header, allowing the full space >>>> to be >>>> unlocked. 0x?a can be used for greasing. >>>> >>>> I haven't talked to IP-layer people about whether they consider the >>>> IPv6 scheme >>>> this is based on to be successful. Either way, this should at least >>>> have plenty >>>> of hardware support. >>>> >>>> FWIW, I'm not sure that we need the complexity that this adds. It's >>>> not clear >>>> that there is a motivating use case. However, on balance it's >>>> probably worth >>>> putting something in for the moment. If it turns out that we don't us= e >>>> it and >>>> can't find even a potential use case, then removing it is simple enoug= h. >>>> >>>> That said, this form could be used to pack a TLS Finished into 1-RTT >>>> packets if >>>> we define a 5- or 7-bit code for "small bit of handshake, followed by >>>> more", >>>> after which we can include a 1-RTT payload. >>>> >>>> >>>> # Short Header >>>> >>>> ``` >>>> 0 1 2 3 >>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> |S|K| Packet Number (30) | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> | | >>>> + Connection ID + >>>> | | >>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>> ``` >>>> >>>> The short form header is defined to be specific to a version. Anythin= g >>>> can change between protocol versions. >>>> >>>> A short packet header - in this version - reserves two bits from the >>>> first >>>> octet: >>>> * SHORT_HEADER bit 7 (0x80) =3D 1, >>>> * KEY_PHASE bit 6 (0x40) =3D 0 initially >>>> >>>> The remainder of the first four octets contain the packet number. 30 >>>> bits >>>> should be plenty. If a need is found for more flags, those can steal >>>> upper >>>> bits from the packet number. (Frankly, I suspect that 14 bits might b= e >>>> enough, but Ian was a little leery of that when I suggested it, and th= is >>>> keeps the connection ID in the same place in every packet.) >>>> >>>> The connection ID follows on the next 8 octets. >>>> >>>> If we need more bits, then we can steal them from the packet number. >>>> >>>> >>> >> > --001a114dcf78c95f1005481fcf1b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
First, Martin, thanks for doing the work I promised to do.= I've got some more things I'm going to try that with :)


On Thu, Feb 9, 2017 at 12:42 PM, Jana Iyengar <jri@google.com> wrote:
Mar= tin,

I like that you've separated the early handshak= e packet format from the "common case" format -- there may be val= ue in having that separation when thinking about overhead and header format= s (earlier versions of the transport draft talked about Regular and Special= packets, which may be worth reconsidering.) That said, I think this propos= al conflates three things:=C2=A0
(i) it attempts to compress the = header, in some cases

I thought= there was agreement that making the header smaller was good. Not sure how = we would have consensus for that in the abstract, so we probably just need = to debate whether or not this particular form of compression is good.
=

=C2=A0
(ii) it changes the header in ways which have been suggested = but without consensus (connection ID, magic field)
=

Hmm.... I thought we did have consensus for the magic f= ield in the interim. Of course that needs confirmation on the mailing list,= but this seems like a good venue for that.
I don't think we = need concern ourselves with the connection ID, because this proposal neatly= accommodates removing the connection ID field, either by having the server=
tell the client it can (with no indicator) or if we like, steali= ng a bit from the packet number to say ("here is a conn id"). The= re doesn't seem to be a percentage in removing conn id from the special= packets, so we don't need to address that.

(iii) it adds = extensibility in ways that are not yet justified.
<= div>





- jana<= /div>


On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett = <ianswett@google.com> wrote:
Thanks for taking a crack at this.=C2=A0 I have a few= high-level comments.

1) This implicitly requires the connecti= on ID to always be stated, which as Ryan said, inflates the packet header s= ubstantially from the status quo of what we send server to client, which I&= #39;m not a fan of from a practical perspective.=C2=A0 Equally importantly,= I think we need to resolve the conversation about privacy and connection I= Ds before we know whether we should always be sending the connection ID.
2) I believe we may want to add packet number echo bit(#269= ) and possibly a loss detection bit(#279) on every packet.=C2=A0 I = think it makes sense to resolve these before redesigning the packet header,= since I believe it would substantially change your current design?
3) This proposes header extensions, which seems orthogonal to the header= redesign.=C2=A0 I'm not a fan of header extensions at the moment, but = I think it deserves a separate conversation.

So I = would be biased towards getting some clarity on the connection id privacy q= uestion as well as the #269 and #279 before attempting a holistic redesign = of the packet header.

On= Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton <rch@google.com> = wrote:


On Wed, Feb 8, 2017 at 8= :42 PM, Martin Thomson <martin.thomson@gmail.com> wrote= :
As I go through the = issues list, it appears that a lot of issues on
which we have consensus would benefit from a resolution to the header
format issue.=C2=A0 To that end, I have sketched out a proposal that I
think meets the various constraints we have.

I want to discuss this here before we embark on what could be a fairly
disruptive set of changes to the drafts.

(A copy of the following text can be found at
https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8
)
--

There are two forms of QUIC common header: long and short.=C2=A0 Long form = packets
are used for the initial exchange - until both 1-RTT packet protection can = be
started AND version negotiation is complete.=C2=A0 Short form packets carry= the
bulk of the data.

This removes a lot of the flexibility that was the source of most of the objections to the current format.=C2=A0 Fields are aligned on four octet bo= undaries.
All long-form header variations have the exact same form.=C2=A0 The connect= ion ID is
in the same place in both short and long form.=C2=A0 The long form clearly<= br> identifies the role of the sender in the first octet and it identifies the<= br> packet as a QUIC packet.

The cost is that it makes occasional packets a little larger (the long head= er
is 20 octets, whereas the existing form uses between 14 and 19 octets
for initial
handshake packets).=C2=A0 This is an acceptable trade-off given that only a= few of
these packets are ever exchanged on a connection.

It makes most packets (the short header) 12 octets where it is possible to<= br> have 10 octet packets.=C2=A0

=E2=80=8BIn c= urrently deployed QUIC, 1-RTT packets from the server to the client do not = have connection ID present. (This is because an endpoint tells the peer how= many connection=E2=80=8B ID bits it needs the peer to send. In the case of= clients, since they only have 1 connection on a given socket, the connecti= on ID is not needed.). These packets also typically have a 1 or 2 byte pack= et number. So the header ends up being: =C2=A01 byte public flags + 1 or 2 = byte packet number for a total of 2-3 bytes. This new format seems to be mu= ch larger.
=C2=A0
However, a 10 octet packet header assumes an 8 bit packet number, this is 30.

I don't think= I understand how to construct a 10 octet packet. Can you elaborate?
<= /div>
=C2=A0
# Long Header

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|S|Typ|=C2=A0 Next=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Magic "uic"/"UIC"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Version=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Packet Number=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Header Extensions]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Payload=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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The first four octets:
* Octet 0: Special
=C2=A0 * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here)
=C2=A0 * Bit 6-5: Type
=C2=A0 =C2=A0 * 11 - client packet
=C2=A0 =C2=A0 * 10 - server packet
=C2=A0 =C2=A0 * 01 - public reset
=C2=A0 =C2=A0 * 00 - version negotiation
=C2=A0 * Bits 4-0: Next protocol
=C2=A0 =C2=A0 * 0b10001 indicates that it is QUIC handshake data
=C2=A0 =C2=A0 * 0b01111 indicates that it is QUIC 0-RTT data
=C2=A0 =C2=A0 * other values mean that the payload following the packet num= ber contains
=C2=A0 =C2=A0 =C2=A0an IPv6-style extension header
* Octets 1-3: Magic (this can be short given that we will have a MAC as wel= l)
=C2=A0 * 0x756963 for a client,
=C2=A0 * 0x554943 for a server

Note: A client packet starts with "quic", server starts with &quo= t;QUIC",
0-RTT starts
with "ouic".

Note(2): We might consider the second set of 7 bits to be a single code spa= ce,
rather than use a 2+5 bit partitioning.=C2=A0 That gives us a bit more flex= ibility
and avoids meaningless combinations like public reset + 0-RTT.

The remainder of the packet layout is the same regardless of type, the
difference
being what rules for how to fill the values out and their semantics.

A client packet then contains:
* Octets 4-11: connection ID (initially all zeroes/random)
* Octets 12-15: version
* Octets 16-19: packet number (low 4 octets, starts at a random 32-bit valu= e)
* Octets 20+: payload

Note: I'm not sure whether the client should pack the connection ID wit= h random
values.=C2=A0 They would have no semantic value, though they might serve to= provide
proof that the server received the packet if we require echoing, see below.= =E2=80=8B

A server packet contains a connection ID:
* Octets 4-11: connection ID (server-selected value)
* Octets 12-15: version (echoed)
* Octets 16-19: packet number (low 4 octets, random 32-bit initial value) * Octets 20+: payload

A version negotiation packet contains:
* Octets 4-11: connection ID (echoed)
* Octets 12-15: version received (echoed)
* Octets 16-19: packet number (echoed)
* Octets 20+: payload =3D version list

In or= der for the server to echo back the packet number, the server obviously nee= ds to be able parse the packet number. But if the packet contains a version= that the server does not support, it may well be the case that the packet = number layout may be different in the new version. So I'm not sure it&#= 39;s possible to echo back the packet number.
=E2=80=8B
A public reset packet contains:
* Octets 4-11: connection ID (echoed)
* Octets 12-15: version (echoed)
* Octets 16-19: rejected packet number (echoed)
* Octets 20+: payload =3D authentication data

=E2= =80=8BPublic reset packets are commonly sent when a server receives a packe= t for a connection it does not have state for. (For example, a server resta= rt or a routing hiccup). In this case, the server is responding to a packet= with an unknown version and consequently and unknown packet number. So I&#= 39;m not sure it's possible to echo back the packet number.
<= div class=3D"m_-6199183305228247620m_3673605300989309482m_-2248227817827599= 51h5">
=E2=80= =8B
Echoing details = from the packet in both version negotiation and provides return
routeability on version negotiation (#244), while maintaining a consistent<= br> header shape for all packets.

These long-form packets are used for anything that doesn't have 1-RTT p= acket
protection and prior to the completion of version negotiation.=C2=A0 Once b= oth
conditions are met, switch to sending short-form packets.=C2=A0 I haven'= ;t defined any
5/7-bit code for protected long-form packets, but that's easy to do if = we need
to provide for them (see below for more on this).


## Extension headers

An 8-bit space (like IPv6) carries an identifier for the protocol extension= .

Each header extension takes the form:
* Octet 1: next identifier
* Octet 2: length

Since only the lower 5 (or 7) bits of this space is accessible from the out= set,
0x00 is reserved for a null extension header, allowing the full space to be=
unlocked.=C2=A0 0x?a can be used for greasing.

I haven't talked to IP-layer people about whether they consider the IPv= 6 scheme
this is based on to be successful.=C2=A0 Either way, this should at least h= ave plenty
of hardware support.

FWIW, I'm not sure that we need the complexity that this adds.=C2=A0 It= 's not clear
that there is a motivating use case.=C2=A0 =C2=A0However, on balance it'= ;s probably worth
putting something in for the moment.=C2=A0 If it turns out that we don'= t use it and
can't find even a potential use case, then removing it is simple enough= .

That said, this form could be used to pack a TLS Finished into 1-RTT packet= s if
we define a 5- or 7-bit code for "small bit of handshake, followed by = more",
after which we can include a 1-RTT payload.


# Short Header

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|S|K|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packet Number = (30)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The short form header is defined to be specific to a version.=C2=A0 Anythin= g
can change between protocol versions.

A short packet header - in this version - reserves two bits from the first<= br> octet:
* SHORT_HEADER bit 7 (0x80) =3D 1,
* KEY_PHASE bit 6 (0x40) =3D 0 initially

The remainder of the first four octets contain the packet number.=C2=A0 30 = bits
should be plenty.=C2=A0 If a need is found for more flags, those can steal = upper
bits from the packet number.=C2=A0 (Frankly, I suspect that 14 bits might b= e
enough, but Ian was a little leery of that when I suggested it, and this keeps the connection ID in the same place in every packet.)

The connection ID follows on the next 8 octets.

If we need more bits, then we can steal them from the packet number.





--001a114dcf78c95f1005481fcf1b-- From nobody Thu Feb 9 17:08:09 2017 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 E4721129E0E for ; Thu, 9 Feb 2017 17:08:06 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 kSbG6m5HFmHq for ; Thu, 9 Feb 2017 17:07:58 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 01F4A129E14 for ; Thu, 9 Feb 2017 17:07:57 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id r136so15677838vke.1 for ; Thu, 09 Feb 2017 17:07:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xoSEP6jyginsD9csr2ElvCXc+igH3TRzp4IvHe7E5O4=; b=s252NYDESMBl9D94pKDS1xF4BOPCxG9H6THi0cpiGdu41IMSpUcckpMSDCxy6BCePW g+Kpo9+7B7uqQFtUMJ9IKP4wzKVja5RaIa3NGwPMmSJ1xXvLuOinFt5iJTrmH3bjaWTw P2LaC1ns5BvJOSb5ucCVgd2rRch9aLJXhkADXXC4ynQ7EoU5i2hiVmKItjw5QAhALx+f LnkwXzTLfNZLxuEpZTg9JoyhKs5lDYjBTqvR/HVPMRf5lhhWSp5DtqAeNkLd2tF9dA8L GteWkldJDbQcKS5PSY5Y3TqBVL0v5Z1jz4gHa38Px39uX6tjZvP3BrBO8Npwnr0c8VaE wGrw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xoSEP6jyginsD9csr2ElvCXc+igH3TRzp4IvHe7E5O4=; b=tqtXMlCwn8IEKDXU7GgyNgOJos7DbrRTn5zmkdCW7oQ1g/O5Y1wp9ZOfmw4ASmiBDd u4ZQsGKyWkJGt7eOd/GyohWAYr04fU1NdgW3IjaUdOk0mrMU1bQMyK97mTIMVQywT4Xi XaqrJhvU7uEvPD/5mtsp6q7AD4ju1b0Gb6lVUwzDjGPcmKo/EolYMep+p3954nvI90MZ /l1YzqMLhmtTskzOmoLfhz9FFdMDun3+Io0GVpxoQSmrzaHjYwn7avL/8TeJaQ+yciQ1 0kunsgQ7h2p0SSdQzbS2qxam0O2MZ1jnIoUcsMIPyVlBWp+mkWdNmJOK1OGvaSZCumcT UneA== X-Gm-Message-State: AMke39n9BgrvlFH5tavDipBdCrpvXlnniJwHvOnF7TpHVRxKlqESFILLwlY5lNdycwulu7Hj2moK8Qo/t+6Z1aLm X-Received: by 10.31.99.1 with SMTP id x1mr2985005vkb.161.1486688876508; Thu, 09 Feb 2017 17:07:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 9 Feb 2017 17:07:55 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 9 Feb 2017 17:07:55 -0800 Message-ID: Subject: Re: Proposal for QUIC header To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c07b178607fe8054822bab8 Archived-At: Cc: Ian Swett , IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 01:08:07 -0000 --94eb2c07b178607fe8054822bab8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Eric, Responses inline. > I like that you've separated the early handshake packet format from the >> "common case" format -- there may be value in having that separation whe= n >> thinking about overhead and header formats (earlier versions of the >> transport draft talked about Regular and Special packets, which may be >> worth reconsidering.) That said, I think this proposal conflates three >> things: >> (i) it attempts to compress the header, in some cases >> > > I thought there was agreement that making the header smaller was good. No= t > sure how we would have consensus for that in the abstract, so we probably > just need to debate whether or not this particular form of compression is > good. > Agreed in principle, but as Ryan points out, this makes the connection ID show up all the time, which increases header size. > (ii) it changes the header in ways which have been suggested but without >> consensus (connection ID, magic field) >> > > Hmm.... I thought we did have consensus for the magic field in the > interim. Of course that needs confirmation on the mailing list, but this > seems like a good venue for that. > I don't think we need concern ourselves with the connection ID, because > this proposal neatly accommodates removing the connection ID field, eithe= r > by having the server > tell the client it can (with no indicator) or if we like, stealing a bit > from the packet number to say ("here is a conn id"). There doesn't seem t= o > be a percentage in removing conn id from the special packets, so we don't > need to address that. > Yes, you're right. We did have consensus on encoding version neg packets to include a ver + magic for directionality, but as you note, this hasn't been confirmed on the list, and we should do that. This is a simple change that addresses the DoS issue by adding directionality (Issue #135 ), and that change would be relatively small. (iii) it adds extensibility in ways that are not yet justified. >> > > I think I do agree with you here, ultimately, but I'd like to leave it in > for now. My reasoning here is that you often find that you have a bunch o= f > small things that you want some flexibility for but that aren't enough to > add a whole new extension point, so you just get death of a thousand cuts > as you try to work around them. Contrariwise, if we have this extension > point available, we can see if it gets used and pull it out before pubreq= . > I am sympathetic to your point about death by a thousand cuts, but I don't think we're there yet. I'm still of the opinion that this introduces unwarranted arbitrary extensibility in the header, since I don't see the warranting use cases. > I think the proposal is useful in that it shows how the header might look >> in a different world. But let's get consensus on what's reasonable to do >> before figuring out how to do it. Specifically, as Ian notes, #269 and #= 279 >> are existing issues, and we need to discuss things like the magic header >> field before adding them in (is there an issue for this?) >> >> I propose parking this for now. >> > > I'd rather we hash out these issues and decide on this PR or some revisio= n > one way or the other. There's a lot of other stuff that's kind of piled u= p > behind the packet header > In that case, I'd suggest that we separate the version + magic flag in one PR to address the DoS issue. As discussed at the interim , this would simply mean that we have an interpretation of the version bit that includes the magic part. For the long header (inlining my comments below:) * Octet 0: Special * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) * Bit 6-5: Type * 11 - client packet * 10 - server packet * 01 - public reset * 00 - version negotiation Why do you need two codepoints for regular packets? The magic header gives directionality on initial packets, and the connection keys on subsequent rounds, right? You need only three codepoints in all here. * Bits 4-0: Next protocol * 0b10001 indicates that it is QUIC handshake data * 0b01111 indicates that it is QUIC 0-RTT data Why do we need these? * other values mean that the payload following the packet number contains an IPv6-style extension header Why do we need this? * Octets 1-3: Magic (this can be short given that we will have a MAC as well) * 0x756963 for a client, * 0x554943 for a server SGTM, based on consensus. The proposed short header removes the following bits that I would not want to lose: - packet number size. The packet number size currently changes as our estimation of how many packets fit in the cwnd changes (loosely speaking) and is dynamic through the connection. - Connection ID flag, and makes the Connection ID required in all packets. As previously pointed out, this flexibility is quite useful and reduces header size quite a bit in the direction where it commonly matters most (server->client), but it can be used by any endpoint as long as it does not need Connection ID for routing on incoming packets. Based on my take on the long and short headers above: If we remove the extensibility points, eliminate server/client directionality in the header bits, and retain the fields I noted above, I'm not sure that there's much to be had by separating the long and short headers. The resulting header looks as follows on all packets: - TT: Packet type * 00 - version negotiation packet * 01 - public reset * 1X - regular packet - Key Phase - Connection ID - Packet Number Size (2 bits) The only difference from the spec is the TT bits, which is equivalent to the explicit V and PR bits in the spec right now, since with V and PR bits: 10 - version negotiation packet 01 - public reset packet (we could make this X1, to make it cover the unused codepoint.) 00 - regular packet I would suggest a PR that only adds a magic field for directionality, and leaves the rest of it out; perhaps in a separate issue + PR to discuss why these may be useful. - jana -Ekr > > > >> - jana >> >> >> On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett wrote: >> >>> Thanks for taking a crack at this. I have a few high-level comments. >>> >>> 1) This implicitly requires the connection ID to always be stated, whic= h >>> as Ryan said, inflates the packet header substantially from the status = quo >>> of what we send server to client, which I'm not a fan of from a practic= al >>> perspective. Equally importantly, I think we need to resolve the >>> conversation about privacy and connection IDs before we know whether we >>> should always be sending the connection ID. >>> 2) I believe we may want to add packet number echo bit(#269 >>> ) and possibly a loss >>> detection bit(#279 ) >>> on every packet. I think it makes sense to resolve these before >>> redesigning the packet header, since I believe it would substantially >>> change your current design? >>> 3) This proposes header extensions, which seems orthogonal to the heade= r >>> redesign. I'm not a fan of header extensions at the moment, but I thin= k it >>> deserves a separate conversation. >>> >>> So I would be biased towards getting some clarity on the connection id >>> privacy question as well as the #269 and #279 before attempting a holis= tic >>> redesign of the packet header. >>> >>> On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton wrote: >>> >>>> >>>> >>>> On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson < >>>> martin.thomson@gmail.com> wrote: >>>> >>>>> As I go through the issues list, it appears that a lot of issues on >>>>> which we have consensus would benefit from a resolution to the header >>>>> format issue. To that end, I have sketched out a proposal that I >>>>> think meets the various constraints we have. >>>>> >>>>> I want to discuss this here before we embark on what could be a fairl= y >>>>> disruptive set of changes to the drafts. >>>>> >>>>> (A copy of the following text can be found at >>>>> https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b= 8 >>>>> ) >>>>> -- >>>>> >>>>> There are two forms of QUIC common header: long and short. Long form >>>>> packets >>>>> are used for the initial exchange - until both 1-RTT packet protectio= n >>>>> can be >>>>> started AND version negotiation is complete. Short form packets carr= y >>>>> the >>>>> bulk of the data. >>>>> >>>>> This removes a lot of the flexibility that was the source of most of >>>>> the >>>>> objections to the current format. Fields are aligned on four octet >>>>> boundaries. >>>>> All long-form header variations have the exact same form. The >>>>> connection ID is >>>>> in the same place in both short and long form. The long form clearly >>>>> identifies the role of the sender in the first octet and it identifie= s >>>>> the >>>>> packet as a QUIC packet. >>>>> >>>>> The cost is that it makes occasional packets a little larger (the lon= g >>>>> header >>>>> is 20 octets, whereas the existing form uses between 14 and 19 octets >>>>> for initial >>>>> handshake packets). This is an acceptable trade-off given that only = a >>>>> few of >>>>> these packets are ever exchanged on a connection. >>>>> >>>>> It makes most packets (the short header) 12 octets where it is >>>>> possible to >>>>> have 10 octet packets. >>>> >>>> >>>> =E2=80=8BIn currently deployed QUIC, 1-RTT packets from the server to = the >>>> client do not have connection ID present. (This is because an endpoint >>>> tells the peer how many connection=E2=80=8B ID bits it needs the peer = to send. In >>>> the case of clients, since they only have 1 connection on a given sock= et, >>>> the connection ID is not needed.). These packets also typically have a= 1 or >>>> 2 byte packet number. So the header ends up being: 1 byte public flag= s + 1 >>>> or 2 byte packet number for a total of 2-3 bytes. This new format seem= s to >>>> be much larger. >>>> >>>> >>>>> However, a 10 octet packet header assumes an 8 bit >>>>> packet number, this is 30. >>>>> >>>> >>>> I don't think I understand how to construct a 10 octet packet. Can you >>>> elaborate? >>>> >>>> >>>>> # Long Header >>>>> >>>>> ``` >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |S|Typ| Next | Magic "uic"/"UIC" | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | | >>>>> + Connection ID + >>>>> | | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Version | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Packet Number | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | [Header Extensions] ... >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | Payload ... >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> ``` >>>>> >>>>> The first four octets: >>>>> * Octet 0: Special >>>>> * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) >>>>> * Bit 6-5: Type >>>>> * 11 - client packet >>>>> * 10 - server packet >>>>> * 01 - public reset >>>>> * 00 - version negotiation >>>>> * Bits 4-0: Next protocol >>>>> * 0b10001 indicates that it is QUIC handshake data >>>>> * 0b01111 indicates that it is QUIC 0-RTT data >>>>> * other values mean that the payload following the packet number >>>>> contains >>>>> an IPv6-style extension header >>>>> * Octets 1-3: Magic (this can be short given that we will have a MAC >>>>> as well) >>>>> * 0x756963 for a client, >>>>> * 0x554943 for a server >>>>> >>>>> Note: A client packet starts with "quic", server starts with "QUIC", >>>>> 0-RTT starts >>>>> with "ouic". >>>>> >>>>> Note(2): We might consider the second set of 7 bits to be a single >>>>> code space, >>>>> rather than use a 2+5 bit partitioning. That gives us a bit more >>>>> flexibility >>>>> and avoids meaningless combinations like public reset + 0-RTT. >>>>> >>>>> The remainder of the packet layout is the same regardless of type, th= e >>>>> difference >>>>> being what rules for how to fill the values out and their semantics. >>>>> >>>>> A client packet then contains: >>>>> * Octets 4-11: connection ID (initially all zeroes/random) >>>>> * Octets 12-15: version >>>>> * Octets 16-19: packet number (low 4 octets, starts at a random 32-bi= t >>>>> value) >>>>> * Octets 20+: payload >>>>> >>>>> Note: I'm not sure whether the client should pack the connection ID >>>>> with random >>>>> values. They would have no semantic value, though they might serve t= o >>>>> provide >>>>> proof that the server received the packet if we require echoing, see >>>>> below.=E2=80=8B >>>> >>>> >>>>> A server packet contains a connection ID: >>>>> * Octets 4-11: connection ID (server-selected value) >>>>> * Octets 12-15: version (echoed) >>>>> * Octets 16-19: packet number (low 4 octets, random 32-bit initial >>>>> value) >>>>> * Octets 20+: payload >>>>> >>>>> A version negotiation packet contains: >>>>> * Octets 4-11: connection ID (echoed) >>>>> * Octets 12-15: version received (echoed) >>>>> * Octets 16-19: packet number (echoed) >>>>> * Octets 20+: payload =3D version list >>>>> >>>> >>>> In order for the server to echo back the packet number, the server >>>> obviously needs to be able parse the packet number. But if the packet >>>> contains a version that the server does not support, it may well be th= e >>>> case that the packet number layout may be different in the new version= . So >>>> I'm not sure it's possible to echo back the packet number. >>>> =E2=80=8B >>>> >>>>> A public reset packet contains: >>>>> * Octets 4-11: connection ID (echoed) >>>>> * Octets 12-15: version (echoed) >>>>> * Octets 16-19: rejected packet number (echoed) >>>>> * Octets 20+: payload =3D authentication data >>>>> >>>> >>>> =E2=80=8BPublic reset packets are commonly sent when a server receives= a packet >>>> for a connection it does not have state for. (For example, a server re= start >>>> or a routing hiccup). In this case, the server is responding to a pack= et >>>> with an unknown version and consequently and unknown packet number. So= I'm >>>> not sure it's possible to echo back the packet number. >>>> =E2=80=8B >>>> >>>>> Echoing details from the packet in both version negotiation and >>>>> provides return >>>>> routeability on version negotiation (#244), while maintaining a >>>>> consistent >>>>> header shape for all packets. >>>>> >>>>> These long-form packets are used for anything that doesn't have 1-RTT >>>>> packet >>>>> protection and prior to the completion of version negotiation. Once >>>>> both >>>>> conditions are met, switch to sending short-form packets. I haven't >>>>> defined any >>>>> 5/7-bit code for protected long-form packets, but that's easy to do i= f >>>>> we need >>>>> to provide for them (see below for more on this). >>>>> >>>>> >>>>> ## Extension headers >>>>> >>>>> An 8-bit space (like IPv6) carries an identifier for the protocol >>>>> extension. >>>>> >>>>> Each header extension takes the form: >>>>> * Octet 1: next identifier >>>>> * Octet 2: length >>>>> >>>>> Since only the lower 5 (or 7) bits of this space is accessible from >>>>> the outset, >>>>> 0x00 is reserved for a null extension header, allowing the full space >>>>> to be >>>>> unlocked. 0x?a can be used for greasing. >>>>> >>>>> I haven't talked to IP-layer people about whether they consider the >>>>> IPv6 scheme >>>>> this is based on to be successful. Either way, this should at least >>>>> have plenty >>>>> of hardware support. >>>>> >>>>> FWIW, I'm not sure that we need the complexity that this adds. It's >>>>> not clear >>>>> that there is a motivating use case. However, on balance it's >>>>> probably worth >>>>> putting something in for the moment. If it turns out that we don't >>>>> use it and >>>>> can't find even a potential use case, then removing it is simple >>>>> enough. >>>>> >>>>> That said, this form could be used to pack a TLS Finished into 1-RTT >>>>> packets if >>>>> we define a 5- or 7-bit code for "small bit of handshake, followed by >>>>> more", >>>>> after which we can include a 1-RTT payload. >>>>> >>>>> >>>>> # Short Header >>>>> >>>>> ``` >>>>> 0 1 2 3 >>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> |S|K| Packet Number (30) | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> | | >>>>> + Connection ID + >>>>> | | >>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>> ``` >>>>> >>>>> The short form header is defined to be specific to a version. Anythi= ng >>>>> can change between protocol versions. >>>>> >>>>> A short packet header - in this version - reserves two bits from the >>>>> first >>>>> octet: >>>>> * SHORT_HEADER bit 7 (0x80) =3D 1, >>>>> * KEY_PHASE bit 6 (0x40) =3D 0 initially >>>>> >>>>> The remainder of the first four octets contain the packet number. 30 >>>>> bits >>>>> should be plenty. If a need is found for more flags, those can steal >>>>> upper >>>>> bits from the packet number. (Frankly, I suspect that 14 bits might = be >>>>> enough, but Ian was a little leery of that when I suggested it, and >>>>> this >>>>> keeps the connection ID in the same place in every packet.) >>>>> >>>>> The connection ID follows on the next 8 octets. >>>>> >>>>> If we need more bits, then we can steal them from the packet number. >>>>> >>>>> >>>> >>> >> > > --94eb2c07b178607fe8054822bab8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Eric,

Responses inline.
=C2=A0
=
I like th= at you've separated the early handshake packet format from the "co= mmon case" format -- there may be value in having that separation when= thinking about overhead and header formats (earlier versions of the transp= ort draft talked about Regular and Special packets, which may be worth reco= nsidering.) That said, I think this proposal conflates three things:=C2=A0<= br>
(i) it attempts to compress the header, in some cases

I thought there was agreement t= hat making the header smaller was good. Not sure how we would have consensu= s for that in the abstract, so we probably just need to debate whether or n= ot this particular form of compression is good.

Agreed in principle, but as Ryan points out, t= his makes the connection ID show up all the time, which increases header si= ze.
=C2=A0
(ii) it changes the header in ways which have been suggest= ed but without consensus (connection ID, magic field)

Hmm.... I thought we did have consensus for t= he magic field in the interim. Of course that needs confirmation on the mai= ling list, but this seems like a good venue for that.
I don't= think we need concern ourselves with the connection ID, because this propo= sal neatly accommodates removing the connection ID field, either by having = the server
tell the client it can (with no indicator) or if we li= ke, stealing a bit from the packet number to say ("here is a conn id&q= uot;). There doesn't seem to be a percentage in removing conn id from t= he special packets, so we don't need to address that.
=

Yes, you're right. We did have c= onsensus on encoding version neg packets to include a ver + magic for direc= tionality, but as you note, this hasn't been confirmed on the list, and= we should do that. This is a simple change that addresses the DoS issue by= adding directionality (Issue #135), and that change would be relatively small.
=

(iii) it adds extensibility in ways that are not yet justified.

I think I do agree with yo= u here, ultimately, but I'd like to leave it in for now. My reasoning h= ere is that you often find that you have a bunch of small things that you w= ant some flexibility for but that aren't enough to add a whole new exte= nsion point, so you just get death of a thousand cuts as you try to work ar= ound them. Contrariwise, if we have this extension point available, we can = see if it gets used and pull it out before pubreq.
<= /blockquote>

I am sympathetic to your point about death = by a thousand cuts, but I don't think we're there yet. I'm stil= l of the opinion that this introduces unwarranted arbitrary extensibility i= n the header, since I don't see the warranting use cases.
=C2= =A0
= I think the proposal is useful in that it shows how the header might look i= n a different world. But let's get consensus on what's reasonable t= o do before figuring out how to do it. Specifically, as Ian notes, #269 and= #279 are existing issues, and we need to discuss things like the magic hea= der field before adding them in (is there an issue for this?)
I propose parking this for now.
I'd rather we hash out these issues and decide on t= his PR or some revision one way or the other. There's a lot of other st= uff that's kind of piled up behind the packet header
<= /div>

In that case, I'd suggest that we= separate the version + magic flag in one PR to address the DoS issue. As <= a href=3D"https://github.com/quicwg/wg-materials/blob/master/interim-17-01/= minutes-24.md#issue-135--dos-using-version-negotiation-packets">discussed a= t the interim, this would simply mean that we have an interpretation of= the version bit that includes the magic part.

For the long header (inlining my comments below:)
* Octet 0: Special
=C2=A0 * Bit 7 (i.e., 0x80): SHORT_HEADER (set = to 0 here)
=C2=A0 * Bit 6-5: Type
=C2=A0 =C2=A0 * 11 - client packet
=C2=A0 =C2=A0 * 10 -= server packet
=C2=A0 =C2= =A0 * 01 - public reset
=C2=A0 =C2=A0 * 00 - version negotiation

Why do yo= u need two codepoints for regular packets? The magic header gives direction= ality on initial packets, and the connection keys on subsequent rounds, rig= ht? You need only three codepoints in all here.

<= div>=C2=A0 * Bits 4-0: Next protocol
=C2=A0 =C2= =A0 * 0b10001 indicates that it is QUIC handshake data
=C2=A0 =C2=A0 * 0b01111 i= ndicates that it is QUIC 0-RTT data

Why do we need these?

=C2=A0 =C2= =A0 * other values mean that the payload following the packet number contai= ns
= =C2=A0 =C2=A0 =C2=A0an IPv6-style extension header

Why do we need this?

* Octets 1-3: Magic (this can be short given that we will have a MAC as w= ell)
= =C2=A0 * 0x756963 for a client,
=C2=A0 * 0x554943 for a server
<= div>
SGTM, based on consensus.


<= /div>
The proposed short header removes the following bits that I would= not want to lose:
- packet number size. The packet number size c= urrently changes as our estimation of how many packets fit in the cwnd chan= ges (loosely speaking) and is dynamic through the connection.
- C= onnection ID flag, and makes the Connection ID required in all packets. As = previously pointed out, this flexibility is quite useful and reduces header= size quite a bit in the direction where it commonly matters most (server-&= gt;client), but it can be used by any endpoint as long as it does not need = Connection ID for routing on incoming packets.

Based on my take on the long and short headers above:

If we remove the extensibility points, eliminate server/cli= ent directionality in the header bits, and retain the fields I noted above,= I'm not sure that there's much to be had by separating the long an= d short headers. The resulting header looks as follows on all packets:
- TT: Packet type
=C2= =A0 =C2=A0 * 00 - version negotiation packet
=C2=A0 =C2=A0 * 01 - public reset=
=C2=A0 =C2=A0 * 1X - regular packet
- Key Ph= ase
- Connection ID
- Packet Number Size (2 bits)
=

The only difference from the spec is the TT bits, which= is equivalent to the explicit V and PR bits in the spec right now, since w= ith V and PR bits:
10 - version negotiation packet
01 -= public reset packet (we could make this X1, to make it cover the unused co= depoint.)
00 - regular packet


=
I would suggest a PR that only adds a magic field for directionality, = and leaves the rest of it out; perhaps in a separate issue + PR to discuss = why these may be useful.
- jana




-Ekr



- jana


On Thu, Feb 9, 2017 at= 11:57 AM, Ian Swett <ianswett@google.com> wrote:
Thanks for ta= king a crack at this.=C2=A0 I have a few high-level comments.

= 1) This implicitly requires the connection ID to always be stated, which as= Ryan said, inflates the packet header substantially from the status quo of= what we send server to client, which I'm not a fan of from a practical= perspective.=C2=A0 Equally importantly, I think we need to resolve the con= versation about privacy and connection IDs before we know whether we should= always be sending the connection ID.
2) I believe we may want to= add packet number echo bit(#269) and possibly a loss detection bit= (#279) on every packet.=C2=A0 I think it makes sense to resolve the= se before redesigning the packet header, since I believe it would substanti= ally change your current design?
3) This proposes header extensio= ns, which seems orthogonal to the header redesign.=C2=A0 I'm not a fan = of header extensions at the moment, but I think it deserves a separate conv= ersation.

So I would be biased towards getting som= e clarity on the connection id privacy question as well as the #269 and #27= 9 before attempting a holistic redesign of the packet header.

On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton <rch@google.co= m> wrote:


=
On Wed, Feb 8, 2017 at 8:42 PM, Mart= in Thomson <martin.thomson@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">As I go through the issues= list, it appears that a lot of issues on
which we have consensus would benefit from a resolution to the header
format issue.=C2=A0 To that end, I have sketched out a proposal that I
think meets the various constraints we have.

I want to discuss this here before we embark on what could be a fairly
disruptive set of changes to the drafts.

(A copy of the following text can be found at
https://gist.github.com/ma= rtinthomson/744d04cbcec9be554f2f8e7bae2715b8
)
--

There are two forms of QUIC common header: long and short.=C2=A0 Long form = packets
are used for the initial exchange - until both 1-RTT packet protection can = be
started AND version negotiation is complete.=C2=A0 Short form packets carry= the
bulk of the data.

This removes a lot of the flexibility that was the source of most of the objections to the current format.=C2=A0 Fields are aligned on four octet bo= undaries.
All long-form header variations have the exact same form.=C2=A0 The connect= ion ID is
in the same place in both short and long form.=C2=A0 The long form clearly<= br> identifies the role of the sender in the first octet and it identifies the<= br> packet as a QUIC packet.

The cost is that it makes occasional packets a little larger (the long head= er
is 20 octets, whereas the existing form uses between 14 and 19 octets
for initial
handshake packets).=C2=A0 This is an acceptable trade-off given that only a= few of
these packets are ever exchanged on a connection.

It makes most packets (the short header) 12 octets where it is possible to<= br> have 10 octet packets.=C2=A0

=E2=80=8BIn c= urrently deployed QUIC, 1-RTT packets from the server to the client do not = have connection ID present. (This is because an endpoint tells the peer how= many connection=E2=80=8B ID bits it needs the peer to send. In the case of= clients, since they only have 1 connection on a given socket, the connecti= on ID is not needed.). These packets also typically have a 1 or 2 byte pack= et number. So the header ends up being: =C2=A01 byte public flags + 1 or 2 = byte packet number for a total of 2-3 bytes. This new format seems to be mu= ch larger.
=C2=A0
However, a 10 octet packet header assumes an 8 bit packet number, this is 30.

I don't think= I understand how to construct a 10 octet packet. Can you elaborate?
<= /div>
=C2=A0
# Long Header

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|S|Typ|=C2=A0 Next=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Magic "uic"/"UIC"=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Version=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Packet Number=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0[Header Extensions]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Payload=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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The first four octets:
* Octet 0: Special
=C2=A0 * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here)
=C2=A0 * Bit 6-5: Type
=C2=A0 =C2=A0 * 11 - client packet
=C2=A0 =C2=A0 * 10 - server packet
=C2=A0 =C2=A0 * 01 - public reset
=C2=A0 =C2=A0 * 00 - version negotiation
=C2=A0 * Bits 4-0: Next protocol
=C2=A0 =C2=A0 * 0b10001 indicates that it is QUIC handshake data
=C2=A0 =C2=A0 * 0b01111 indicates that it is QUIC 0-RTT data
=C2=A0 =C2=A0 * other values mean that the payload following the packet num= ber contains
=C2=A0 =C2=A0 =C2=A0an IPv6-style extension header
* Octets 1-3: Magic (this can be short given that we will have a MAC as wel= l)
=C2=A0 * 0x756963 for a client,
=C2=A0 * 0x554943 for a server

Note: A client packet starts with "quic", server starts with &quo= t;QUIC",
0-RTT starts
with "ouic".

Note(2): We might consider the second set of 7 bits to be a single code spa= ce,
rather than use a 2+5 bit partitioning.=C2=A0 That gives us a bit more flex= ibility
and avoids meaningless combinations like public reset + 0-RTT.

The remainder of the packet layout is the same regardless of type, the
difference
being what rules for how to fill the values out and their semantics.

A client packet then contains:
* Octets 4-11: connection ID (initially all zeroes/random)
* Octets 12-15: version
* Octets 16-19: packet number (low 4 octets, starts at a random 32-bit valu= e)
* Octets 20+: payload

Note: I'm not sure whether the client should pack the connection ID wit= h random
values.=C2=A0 They would have no semantic value, though they might serve to= provide
proof that the server received the packet if we require echoing, see below.= =E2=80=8B

A server packet contains a connection ID:
* Octets 4-11: connection ID (server-selected value)
* Octets 12-15: version (echoed)
* Octets 16-19: packet number (low 4 octets, random 32-bit initial value) * Octets 20+: payload

A version negotiation packet contains:
* Octets 4-11: connection ID (echoed)
* Octets 12-15: version received (echoed)
* Octets 16-19: packet number (echoed)
* Octets 20+: payload =3D version list

In or= der for the server to echo back the packet number, the server obviously nee= ds to be able parse the packet number. But if the packet contains a version= that the server does not support, it may well be the case that the packet = number layout may be different in the new version. So I'm not sure it&#= 39;s possible to echo back the packet number.
=E2=80=8B
A public reset packet contains:
* Octets 4-11: connection ID (echoed)
* Octets 12-15: version (echoed)
* Octets 16-19: rejected packet number (echoed)
* Octets 20+: payload =3D authentication data

=E2= =80=8BPublic reset packets are commonly sent when a server receives a packe= t for a connection it does not have state for. (For example, a server resta= rt or a routing hiccup). In this case, the server is responding to a packet= with an unknown version and consequently and unknown packet number. So I&#= 39;m not sure it's possible to echo back the packet number.
<= div class=3D"gmail-m_8643799661940003891m_-6199183305228247620m_36736053009= 89309482m_-224822781782759951h5">
=E2=80=8B
Echoing details from the packet in both version negotiation and = provides return
routeability on version negotiation (#244), while maintaining a consistent<= br> header shape for all packets.

These long-form packets are used for anything that doesn't have 1-RTT p= acket
protection and prior to the completion of version negotiation.=C2=A0 Once b= oth
conditions are met, switch to sending short-form packets.=C2=A0 I haven'= ;t defined any
5/7-bit code for protected long-form packets, but that's easy to do if = we need
to provide for them (see below for more on this).


## Extension headers

An 8-bit space (like IPv6) carries an identifier for the protocol extension= .

Each header extension takes the form:
* Octet 1: next identifier
* Octet 2: length

Since only the lower 5 (or 7) bits of this space is accessible from the out= set,
0x00 is reserved for a null extension header, allowing the full space to be=
unlocked.=C2=A0 0x?a can be used for greasing.

I haven't talked to IP-layer people about whether they consider the IPv= 6 scheme
this is based on to be successful.=C2=A0 Either way, this should at least h= ave plenty
of hardware support.

FWIW, I'm not sure that we need the complexity that this adds.=C2=A0 It= 's not clear
that there is a motivating use case.=C2=A0 =C2=A0However, on balance it'= ;s probably worth
putting something in for the moment.=C2=A0 If it turns out that we don'= t use it and
can't find even a potential use case, then removing it is simple enough= .

That said, this form could be used to pack a TLS Finished into 1-RTT packet= s if
we define a 5- or 7-bit code for "small bit of handshake, followed by = more",
after which we can include a 1-RTT payload.


# Short Header

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|S|K|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packet Number = (30)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The short form header is defined to be specific to a version.=C2=A0 Anythin= g
can change between protocol versions.

A short packet header - in this version - reserves two bits from the first<= br> octet:
* SHORT_HEADER bit 7 (0x80) =3D 1,
* KEY_PHASE bit 6 (0x40) =3D 0 initially

The remainder of the first four octets contain the packet number.=C2=A0 30 = bits
should be plenty.=C2=A0 If a need is found for more flags, those can steal = upper
bits from the packet number.=C2=A0 (Frankly, I suspect that 14 bits might b= e
enough, but Ian was a little leery of that when I suggested it, and this keeps the connection ID in the same place in every packet.)

The connection ID follows on the next 8 octets.

If we need more bits, then we can steal them from the packet number.







--94eb2c07b178607fe8054822bab8-- From nobody Thu Feb 9 18:40:26 2017 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 A3B89129681 for ; Thu, 9 Feb 2017 18:40:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OnUKqIcZI2B9 for ; Thu, 9 Feb 2017 18:40:22 -0800 (PST) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215B2129D9A for ; Thu, 9 Feb 2017 18:40:21 -0800 (PST) Received: by mail-qk0-x244.google.com with SMTP id u25so3343985qki.2 for ; Thu, 09 Feb 2017 18:40:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jZXYrvr9KU41CeP0i4GTJ9952Nygwz/xRYLt6O5R44g=; b=TJePxNIXdr9uPwbEXU8pJk1cuBYTvoMSvdoqEJ6BMrB4vfU/z/IKljwlWa5/c5mpM2 /8tDWAATxEKCqdkfXcDkyWmDAw0XuTDNuBNHkHcuZ/p6sad4dKfTBTj9dTYvRhxk3nhl LFC9YVXu6MQ0x0FzniPqOWNM8bwrcX0HvIhV9yREFMYKgotwgS40cdA5ipG7pCJ1EEf+ HMHPsixotAN0EaZ9wF6NJoIvZ1ap0/Rjerc2wQ9lhCQcMpOVknfFGzje6McDvMpzD84Z FaTfOqp0amOm9Z+e6cqQ3sqvdTC7tyfxqXME2qaWw78fOv4vxgjNSLDv+Y/s9+pMLVMR AJPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jZXYrvr9KU41CeP0i4GTJ9952Nygwz/xRYLt6O5R44g=; b=L+PKUUmLfsc918JVwjCgHdcUuF1S60G/MorXLgldNoETsEZ841fH4gcc1TR3rLkEy3 aG17eBy/Yrqh2v4hUAkxxcHWkGUsOw/beRJ7SBZAttjOQH0c5i+EPjlwKEDbLOjUTgmF R9NEtlF0A3MLFSSzCBI5Vhi3ePRAuLcXnZl8GXZN4ArgBMEz7FHKqCivn2DJKt9j8WNj 7U09r5JVg44oD60RtpiM6xrvQ/IP+SafBdXZq2yislOB+he06CO9sbtv+0zPFRaJcBDt NxdJy1mtVW8u8mbWATcZjYuRn+YAT9hwS1J4qvvuXkr0hnrJg0xnhk0LVCn6icLiGvkc gonw== X-Gm-Message-State: AMke39lZOsoOL6C3Z5bkwd0lNCxZoHn/BdQF6+S9x8WYpm+6IQXZomX1w6tqfhHCD8Isx2auX9hRlcCqGfUrxQ== X-Received: by 10.233.216.68 with SMTP id u65mr6144155qkf.68.1486694419780; Thu, 09 Feb 2017 18:40:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 9 Feb 2017 18:40:19 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 10 Feb 2017 13:40:19 +1100 Message-ID: Subject: Re: Proposal for QUIC header To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Ian Swett , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 02:40:25 -0000 Hi Jana, To address your concerns: Connection ID removal: I believe that ekr addressed your concern about the connection ID removal, so I'm surprised that you bring it up again. Since we haven't really discussed it thus far, I don't know how important this feature is. I believe that it means making a choice about whether you think connection migration is important or not. Whether it requires an explicit per-packet signal is debatable; in developing the proposal, my assumption was that negotiating connection ID away would be good enough. Packet number size: There's a trade-off here. One of the features of my proposal is that the connection ID remains in the same place for both short- and long-form. I agree that 30 bits is far more than we need, but the bits were just sitting there doing nothing otherwise. Also, I don't feel much urgency behind byte-level optimizations for small BDP when they come at the expense of other things. The trends are all toward increases in that number. Extensibility: ekr explained the rationale here, it's an escape valve. I too would dearly like to remove the feature. Given that I can't think of a use case, I hope that time will come soon. It seems like your counter-proposal just reiterates the current design with some minor adjustments. I just don't think that is sufficient to address the concerns that people have raised about the excessive number of variations in packet layout. Adding a magic field in the way you propose only compounds that problem. The reason for needing a proposal was that it was clear that we needed a holistic approach to designing the header. There were just too many different, interacting issues. My proposal addresses many of those at once with a simple change. From a skim through the list: #40, #56, #67, #119, #133, #135, #170, #185, #193, and #244 all go away. It also goes some way to address #147 and #205. On 10 February 2017 at 12:07, Jana Iyengar wrote: > Hi Eric, > > Responses inline. > >>> >>> I like that you've separated the early handshake packet format from the >>> "common case" format -- there may be value in having that separation when >>> thinking about overhead and header formats (earlier versions of the >>> transport draft talked about Regular and Special packets, which may be worth >>> reconsidering.) That said, I think this proposal conflates three things: >>> (i) it attempts to compress the header, in some cases >> >> >> I thought there was agreement that making the header smaller was good. Not >> sure how we would have consensus for that in the abstract, so we probably >> just need to debate whether or not this particular form of compression is >> good. > > > Agreed in principle, but as Ryan points out, this makes the connection ID > show up all the time, which increases header size. > >>> >>> (ii) it changes the header in ways which have been suggested but without >>> consensus (connection ID, magic field) >> >> >> Hmm.... I thought we did have consensus for the magic field in the >> interim. Of course that needs confirmation on the mailing list, but this >> seems like a good venue for that. >> I don't think we need concern ourselves with the connection ID, because >> this proposal neatly accommodates removing the connection ID field, either >> by having the server >> tell the client it can (with no indicator) or if we like, stealing a bit >> from the packet number to say ("here is a conn id"). There doesn't seem to >> be a percentage in removing conn id from the special packets, so we don't >> need to address that. > > > Yes, you're right. We did have consensus on encoding version neg packets to > include a ver + magic for directionality, but as you note, this hasn't been > confirmed on the list, and we should do that. This is a simple change that > addresses the DoS issue by adding directionality (Issue #135), and that > change would be relatively small. > >>> (iii) it adds extensibility in ways that are not yet justified. >> >> >> I think I do agree with you here, ultimately, but I'd like to leave it in >> for now. My reasoning here is that you often find that you have a bunch of >> small things that you want some flexibility for but that aren't enough to >> add a whole new extension point, so you just get death of a thousand cuts as >> you try to work around them. Contrariwise, if we have this extension point >> available, we can see if it gets used and pull it out before pubreq. > > > I am sympathetic to your point about death by a thousand cuts, but I don't > think we're there yet. I'm still of the opinion that this introduces > unwarranted arbitrary extensibility in the header, since I don't see the > warranting use cases. > >>> >>> I think the proposal is useful in that it shows how the header might look >>> in a different world. But let's get consensus on what's reasonable to do >>> before figuring out how to do it. Specifically, as Ian notes, #269 and #279 >>> are existing issues, and we need to discuss things like the magic header >>> field before adding them in (is there an issue for this?) >>> >>> I propose parking this for now. >> >> >> I'd rather we hash out these issues and decide on this PR or some revision >> one way or the other. There's a lot of other stuff that's kind of piled up >> behind the packet header > > > In that case, I'd suggest that we separate the version + magic flag in one > PR to address the DoS issue. As discussed at the interim, this would simply > mean that we have an interpretation of the version bit that includes the > magic part. > > > For the long header (inlining my comments below:) > * Octet 0: Special > * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) > * Bit 6-5: Type > * 11 - client packet > * 10 - server packet > * 01 - public reset > * 00 - version negotiation > > Why do you need two codepoints for regular packets? The magic header gives > directionality on initial packets, and the connection keys on subsequent > rounds, right? You need only three codepoints in all here. > > * Bits 4-0: Next protocol > * 0b10001 indicates that it is QUIC handshake data > * 0b01111 indicates that it is QUIC 0-RTT data > > Why do we need these? > > * other values mean that the payload following the packet number > contains > an IPv6-style extension header > > Why do we need this? > > * Octets 1-3: Magic (this can be short given that we will have a MAC as > well) > * 0x756963 for a client, > * 0x554943 for a server > > SGTM, based on consensus. > > > The proposed short header removes the following bits that I would not want > to lose: > - packet number size. The packet number size currently changes as our > estimation of how many packets fit in the cwnd changes (loosely speaking) > and is dynamic through the connection. > - Connection ID flag, and makes the Connection ID required in all packets. > As previously pointed out, this flexibility is quite useful and reduces > header size quite a bit in the direction where it commonly matters most > (server->client), but it can be used by any endpoint as long as it does not > need Connection ID for routing on incoming packets. > > > Based on my take on the long and short headers above: > > If we remove the extensibility points, eliminate server/client > directionality in the header bits, and retain the fields I noted above, I'm > not sure that there's much to be had by separating the long and short > headers. The resulting header looks as follows on all packets: > - TT: Packet type > * 00 - version negotiation packet > * 01 - public reset > * 1X - regular packet > - Key Phase > - Connection ID > - Packet Number Size (2 bits) > > The only difference from the spec is the TT bits, which is equivalent to the > explicit V and PR bits in the spec right now, since with V and PR bits: > 10 - version negotiation packet > 01 - public reset packet (we could make this X1, to make it cover the unused > codepoint.) > 00 - regular packet > > > I would suggest a PR that only adds a magic field for directionality, and > leaves the rest of it out; perhaps in a separate issue + PR to discuss why > these may be useful. > - jana > > > > >> -Ekr >> >> >>> >>> - jana >>> >>> >>> On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett wrote: >>>> >>>> Thanks for taking a crack at this. I have a few high-level comments. >>>> >>>> 1) This implicitly requires the connection ID to always be stated, which >>>> as Ryan said, inflates the packet header substantially from the status quo >>>> of what we send server to client, which I'm not a fan of from a practical >>>> perspective. Equally importantly, I think we need to resolve the >>>> conversation about privacy and connection IDs before we know whether we >>>> should always be sending the connection ID. >>>> 2) I believe we may want to add packet number echo bit(#269) and >>>> possibly a loss detection bit(#279) on every packet. I think it makes sense >>>> to resolve these before redesigning the packet header, since I believe it >>>> would substantially change your current design? >>>> 3) This proposes header extensions, which seems orthogonal to the header >>>> redesign. I'm not a fan of header extensions at the moment, but I think it >>>> deserves a separate conversation. >>>> >>>> So I would be biased towards getting some clarity on the connection id >>>> privacy question as well as the #269 and #279 before attempting a holistic >>>> redesign of the packet header. >>>> >>>> On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton wrote: >>>>> >>>>> >>>>> >>>>> On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson >>>>> wrote: >>>>>> >>>>>> As I go through the issues list, it appears that a lot of issues on >>>>>> which we have consensus would benefit from a resolution to the header >>>>>> format issue. To that end, I have sketched out a proposal that I >>>>>> think meets the various constraints we have. >>>>>> >>>>>> I want to discuss this here before we embark on what could be a fairly >>>>>> disruptive set of changes to the drafts. >>>>>> >>>>>> (A copy of the following text can be found at >>>>>> https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8 >>>>>> ) >>>>>> -- >>>>>> >>>>>> There are two forms of QUIC common header: long and short. Long form >>>>>> packets >>>>>> are used for the initial exchange - until both 1-RTT packet protection >>>>>> can be >>>>>> started AND version negotiation is complete. Short form packets carry >>>>>> the >>>>>> bulk of the data. >>>>>> >>>>>> This removes a lot of the flexibility that was the source of most of >>>>>> the >>>>>> objections to the current format. Fields are aligned on four octet >>>>>> boundaries. >>>>>> All long-form header variations have the exact same form. The >>>>>> connection ID is >>>>>> in the same place in both short and long form. The long form clearly >>>>>> identifies the role of the sender in the first octet and it identifies >>>>>> the >>>>>> packet as a QUIC packet. >>>>>> >>>>>> The cost is that it makes occasional packets a little larger (the long >>>>>> header >>>>>> is 20 octets, whereas the existing form uses between 14 and 19 octets >>>>>> for initial >>>>>> handshake packets). This is an acceptable trade-off given that only a >>>>>> few of >>>>>> these packets are ever exchanged on a connection. >>>>>> >>>>>> It makes most packets (the short header) 12 octets where it is >>>>>> possible to >>>>>> have 10 octet packets. >>>>> >>>>> >>>>> In currently deployed QUIC, 1-RTT packets from the server to the client >>>>> do not have connection ID present. (This is because an endpoint tells the >>>>> peer how many connection ID bits it needs the peer to send. In the case of >>>>> clients, since they only have 1 connection on a given socket, the connection >>>>> ID is not needed.). These packets also typically have a 1 or 2 byte packet >>>>> number. So the header ends up being: 1 byte public flags + 1 or 2 byte >>>>> packet number for a total of 2-3 bytes. This new format seems to be much >>>>> larger. >>>>> >>>>>> >>>>>> However, a 10 octet packet header assumes an 8 bit >>>>>> packet number, this is 30. >>>>> >>>>> >>>>> I don't think I understand how to construct a 10 octet packet. Can you >>>>> elaborate? >>>>> >>>>>> >>>>>> # Long Header >>>>>> >>>>>> ``` >>>>>> 0 1 2 3 >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> |S|Typ| Next | Magic "uic"/"UIC" | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> + Connection ID + >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Version | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Packet Number | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | [Header Extensions] ... >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | Payload ... >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> ``` >>>>>> >>>>>> The first four octets: >>>>>> * Octet 0: Special >>>>>> * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) >>>>>> * Bit 6-5: Type >>>>>> * 11 - client packet >>>>>> * 10 - server packet >>>>>> * 01 - public reset >>>>>> * 00 - version negotiation >>>>>> * Bits 4-0: Next protocol >>>>>> * 0b10001 indicates that it is QUIC handshake data >>>>>> * 0b01111 indicates that it is QUIC 0-RTT data >>>>>> * other values mean that the payload following the packet number >>>>>> contains >>>>>> an IPv6-style extension header >>>>>> * Octets 1-3: Magic (this can be short given that we will have a MAC >>>>>> as well) >>>>>> * 0x756963 for a client, >>>>>> * 0x554943 for a server >>>>>> >>>>>> Note: A client packet starts with "quic", server starts with "QUIC", >>>>>> 0-RTT starts >>>>>> with "ouic". >>>>>> >>>>>> Note(2): We might consider the second set of 7 bits to be a single >>>>>> code space, >>>>>> rather than use a 2+5 bit partitioning. That gives us a bit more >>>>>> flexibility >>>>>> and avoids meaningless combinations like public reset + 0-RTT. >>>>>> >>>>>> The remainder of the packet layout is the same regardless of type, the >>>>>> difference >>>>>> being what rules for how to fill the values out and their semantics. >>>>>> >>>>>> A client packet then contains: >>>>>> * Octets 4-11: connection ID (initially all zeroes/random) >>>>>> * Octets 12-15: version >>>>>> * Octets 16-19: packet number (low 4 octets, starts at a random 32-bit >>>>>> value) >>>>>> * Octets 20+: payload >>>>>> >>>>>> Note: I'm not sure whether the client should pack the connection ID >>>>>> with random >>>>>> values. They would have no semantic value, though they might serve to >>>>>> provide >>>>>> proof that the server received the packet if we require echoing, see >>>>>> below. >>>>>> >>>>>> >>>>>> A server packet contains a connection ID: >>>>>> * Octets 4-11: connection ID (server-selected value) >>>>>> * Octets 12-15: version (echoed) >>>>>> * Octets 16-19: packet number (low 4 octets, random 32-bit initial >>>>>> value) >>>>>> * Octets 20+: payload >>>>>> >>>>>> A version negotiation packet contains: >>>>>> * Octets 4-11: connection ID (echoed) >>>>>> * Octets 12-15: version received (echoed) >>>>>> * Octets 16-19: packet number (echoed) >>>>>> * Octets 20+: payload = version list >>>>> >>>>> >>>>> In order for the server to echo back the packet number, the server >>>>> obviously needs to be able parse the packet number. But if the packet >>>>> contains a version that the server does not support, it may well be the case >>>>> that the packet number layout may be different in the new version. So I'm >>>>> not sure it's possible to echo back the packet number. >>>>>> >>>>>> A public reset packet contains: >>>>>> * Octets 4-11: connection ID (echoed) >>>>>> * Octets 12-15: version (echoed) >>>>>> * Octets 16-19: rejected packet number (echoed) >>>>>> * Octets 20+: payload = authentication data >>>>> >>>>> >>>>> Public reset packets are commonly sent when a server receives a packet >>>>> for a connection it does not have state for. (For example, a server restart >>>>> or a routing hiccup). In this case, the server is responding to a packet >>>>> with an unknown version and consequently and unknown packet number. So I'm >>>>> not sure it's possible to echo back the packet number. >>>>>> >>>>>> Echoing details from the packet in both version negotiation and >>>>>> provides return >>>>>> routeability on version negotiation (#244), while maintaining a >>>>>> consistent >>>>>> header shape for all packets. >>>>>> >>>>>> These long-form packets are used for anything that doesn't have 1-RTT >>>>>> packet >>>>>> protection and prior to the completion of version negotiation. Once >>>>>> both >>>>>> conditions are met, switch to sending short-form packets. I haven't >>>>>> defined any >>>>>> 5/7-bit code for protected long-form packets, but that's easy to do if >>>>>> we need >>>>>> to provide for them (see below for more on this). >>>>>> >>>>>> >>>>>> ## Extension headers >>>>>> >>>>>> An 8-bit space (like IPv6) carries an identifier for the protocol >>>>>> extension. >>>>>> >>>>>> Each header extension takes the form: >>>>>> * Octet 1: next identifier >>>>>> * Octet 2: length >>>>>> >>>>>> Since only the lower 5 (or 7) bits of this space is accessible from >>>>>> the outset, >>>>>> 0x00 is reserved for a null extension header, allowing the full space >>>>>> to be >>>>>> unlocked. 0x?a can be used for greasing. >>>>>> >>>>>> I haven't talked to IP-layer people about whether they consider the >>>>>> IPv6 scheme >>>>>> this is based on to be successful. Either way, this should at least >>>>>> have plenty >>>>>> of hardware support. >>>>>> >>>>>> FWIW, I'm not sure that we need the complexity that this adds. It's >>>>>> not clear >>>>>> that there is a motivating use case. However, on balance it's >>>>>> probably worth >>>>>> putting something in for the moment. If it turns out that we don't >>>>>> use it and >>>>>> can't find even a potential use case, then removing it is simple >>>>>> enough. >>>>>> >>>>>> That said, this form could be used to pack a TLS Finished into 1-RTT >>>>>> packets if >>>>>> we define a 5- or 7-bit code for "small bit of handshake, followed by >>>>>> more", >>>>>> after which we can include a 1-RTT payload. >>>>>> >>>>>> >>>>>> # Short Header >>>>>> >>>>>> ``` >>>>>> 0 1 2 3 >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> |S|K| Packet Number (30) | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> | | >>>>>> + Connection ID + >>>>>> | | >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >>>>>> ``` >>>>>> >>>>>> The short form header is defined to be specific to a version. >>>>>> Anything >>>>>> can change between protocol versions. >>>>>> >>>>>> A short packet header - in this version - reserves two bits from the >>>>>> first >>>>>> octet: >>>>>> * SHORT_HEADER bit 7 (0x80) = 1, >>>>>> * KEY_PHASE bit 6 (0x40) = 0 initially >>>>>> >>>>>> The remainder of the first four octets contain the packet number. 30 >>>>>> bits >>>>>> should be plenty. If a need is found for more flags, those can steal >>>>>> upper >>>>>> bits from the packet number. (Frankly, I suspect that 14 bits might >>>>>> be >>>>>> enough, but Ian was a little leery of that when I suggested it, and >>>>>> this >>>>>> keeps the connection ID in the same place in every packet.) >>>>>> >>>>>> The connection ID follows on the next 8 octets. >>>>>> >>>>>> If we need more bits, then we can steal them from the packet number. >>>>>> >>>>> >>>> >>> >> >> > From nobody Thu Feb 9 22:09:45 2017 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 0CA7412948A for ; Thu, 9 Feb 2017 22:09:45 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 RPO-K1x6Zw17 for ; Thu, 9 Feb 2017 22:09:41 -0800 (PST) Received: from mail-vk0-x22a.google.com (mail-vk0-x22a.google.com [IPv6:2607:f8b0:400c:c05::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 3C593129868 for ; Thu, 9 Feb 2017 22:09:41 -0800 (PST) Received: by mail-vk0-x22a.google.com with SMTP id x75so18999914vke.2 for ; Thu, 09 Feb 2017 22:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NTiyBVkLwNnjsRSEp3kguIdMADc3g/5IiMLCkSpcP6k=; b=rmZfxGXzDxTaJmW+x5iLGDzLBVIr5WSp9odvu1zsWkZxA+eH1jl8XGLMRwB8E3PA8B FNPA9OGsRqsMb0xkkIgH+5c3BI3os6FRpkUizj1MyjrO2WZOAjFxmjKY27/1vBcapSbT XBCcpfu9Kdg7EpvfYyYX6pF1yEMI3gKV7dm7RYO29hjnL6UX6307R3khvmhjv271415r CpR0wPuSHZUHU3DGArfApIKqPMp/Ummn+Skrv6pc4BsTaMAGd+WIldqv3bGnfWkgAUYb UVAbKNxZaOkHWhdHMlR7gostM/Iij8+ESKe++syM66zmESDNokafMee51owxWu5DPXby oU9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NTiyBVkLwNnjsRSEp3kguIdMADc3g/5IiMLCkSpcP6k=; b=nexewRASx4EtQhVUHZR19464LX/3QH4nbmPKtiLGPG51F7YgKVT/0wmEX9zt12obxC +5rp70csy2lwlasur9dmdVo4OtmAo/ua9kopHMO/PUZAQB6mw3efMIIQdaIoT9+uRgfL iLo0BmjVROTlKs1P6IyRCakvAgRBmPIdcWjfNemKOTxy4WcbyP7YCKobLxdMxMxghoCg Y/8l4dbC3MtHAkiR4H+0/5KS0UpxKQ96cH72GeC2vT7MlYCeEEXrVaosmPpJBw3Qm83B CsPIdC1+fNpE/Qohj/ZBfpxGP981tac+BvQ/i86b1deqsYlLVfFGV6eGszMYLu93/crR HXZg== X-Gm-Message-State: AMke39lByRnY9MzOFVPkLExe9/qAGT+r5351W7cnosAthkjoCscXO3mrYXi+6BrSp/OKwgWldtzJIh9p6MBei0xN X-Received: by 10.31.92.1 with SMTP id q1mr2906359vkb.151.1486706979885; Thu, 09 Feb 2017 22:09:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 9 Feb 2017 22:09:39 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 9 Feb 2017 22:09:39 -0800 Message-ID: Subject: Re: Proposal for QUIC header To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e2b6e6c21cc054826f1b5 Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Ian Swett , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 06:09:45 -0000 --001a114e2b6e6c21cc054826f1b5 Content-Type: text/plain; charset=UTF-8 Martin, Responses inline. > Connection ID removal: > I believe that ekr addressed your concern about the connection ID > removal, so I'm surprised that you bring it up again. Since we > haven't really discussed it thus far, I don't know how important this > feature is. I believe that it means making a choice about whether you > think connection migration is important or not. Whether it requires an explicit per-packet signal is debatable; in developing the > proposal, my assumption was that negotiating connection ID away would > be good enough. > Apologies -- yes, you're right that ekr addressed it. I agree that it's reasonable to not have it in each packet. I would suggest that changing the packet header to not have it should be accompanied by text to negotiate it during handshake. On its value: I would strongly argue against its removal -- it is what allows QUIC to survive NAT rebinding, which we know happens often enough to matter. Removing it would be a fundamental change to the protocol, and would cause measurable performance impact. Packet number size: > There's a trade-off here. One of the features of my proposal is that > the connection ID remains in the same place for both short- and > long-form. I agree that 30 bits is far more than we need, but the > bits were just sitting there doing nothing otherwise. I don't follow -- the 30 bits would be used by the payload, right? Also, I don't feel much urgency behind byte-level optimizations for > small BDP when they come at the expense of other things. The trends > are all toward increases in that number. > I think exactly the opposite: you gain two bits by removing the packet number size bits and you lose 1-few bytes per packet. That's additional overhead in each packet. While we should try to optimize for low bandwdith as long as it is reasonable, I'll note that my argument isn't based on optimizing for low-bandwidth networks; I just don't see the tradeoff here. What do you gain by removing packet number size bits (besides 2 bits in the header)? Extensibility: > ekr explained the rationale here, it's an escape valve. I too would > dearly like to remove the feature. Given that I can't think of a use > case, I hope that time will come soon. > I don't think we should add extensibility options now that we hope to never use. If we don't think we'll need it, let's not include it. Including it attracts nuisance, since extensible fields often find reasons to be extended. I don't agree with the rationale: providing an escape valve suggests that we may need to add something that we won't have a place to put so we can throw it into extensions. If we need something in the header later that's important enough, we can always redo this header later. It seems like your counter-proposal just reiterates the current design > with some minor adjustments. I just don't think that is sufficient to > address the concerns that people have raised about the excessive > number of variations in packet layout. Adding a magic field in the > way you propose only compounds that problem. > I wasn't making a counter proposal -- I was walking down the path of figuring out what I wanted to retain in the header, and if we had those bits, how different the header would look from what it is now. What I wrote down was what I realized as I walked down that path. One clarification question you haven't answered: Why do you need a client/server bit in Typ? The reason for needing a proposal was that it was clear that we needed > a holistic approach to designing the header. There were just too many > different, interacting issues. My proposal addresses many of those at > once with a simple change. From a skim through the list: #40, #56, > #67, #119, #133, #135, #170, #185, #193, and #244 all go away. It > also goes some way to address #147 and #205. (It's late now for me -- I'll go through the issues you've listed tomorrow and respond to this point.) - jana On 10 February 2017 at 12:07, Jana Iyengar wrote: > > Hi Eric, > > > > Responses inline. > > > >>> > >>> I like that you've separated the early handshake packet format from the > >>> "common case" format -- there may be value in having that separation > when > >>> thinking about overhead and header formats (earlier versions of the > >>> transport draft talked about Regular and Special packets, which may be > worth > >>> reconsidering.) That said, I think this proposal conflates three > things: > >>> (i) it attempts to compress the header, in some cases > >> > >> > >> I thought there was agreement that making the header smaller was good. > Not > >> sure how we would have consensus for that in the abstract, so we > probably > >> just need to debate whether or not this particular form of compression > is > >> good. > > > > > > Agreed in principle, but as Ryan points out, this makes the connection ID > > show up all the time, which increases header size. > > > >>> > >>> (ii) it changes the header in ways which have been suggested but > without > >>> consensus (connection ID, magic field) > >> > >> > >> Hmm.... I thought we did have consensus for the magic field in the > >> interim. Of course that needs confirmation on the mailing list, but this > >> seems like a good venue for that. > >> I don't think we need concern ourselves with the connection ID, because > >> this proposal neatly accommodates removing the connection ID field, > either > >> by having the server > >> tell the client it can (with no indicator) or if we like, stealing a bit > >> from the packet number to say ("here is a conn id"). There doesn't seem > to > >> be a percentage in removing conn id from the special packets, so we > don't > >> need to address that. > > > > > > Yes, you're right. We did have consensus on encoding version neg packets > to > > include a ver + magic for directionality, but as you note, this hasn't > been > > confirmed on the list, and we should do that. This is a simple change > that > > addresses the DoS issue by adding directionality (Issue #135), and that > > change would be relatively small. > > > >>> (iii) it adds extensibility in ways that are not yet justified. > >> > >> > >> I think I do agree with you here, ultimately, but I'd like to leave it > in > >> for now. My reasoning here is that you often find that you have a bunch > of > >> small things that you want some flexibility for but that aren't enough > to > >> add a whole new extension point, so you just get death of a thousand > cuts as > >> you try to work around them. Contrariwise, if we have this extension > point > >> available, we can see if it gets used and pull it out before pubreq. > > > > > > I am sympathetic to your point about death by a thousand cuts, but I > don't > > think we're there yet. I'm still of the opinion that this introduces > > unwarranted arbitrary extensibility in the header, since I don't see the > > warranting use cases. > > > >>> > >>> I think the proposal is useful in that it shows how the header might > look > >>> in a different world. But let's get consensus on what's reasonable to > do > >>> before figuring out how to do it. Specifically, as Ian notes, #269 and > #279 > >>> are existing issues, and we need to discuss things like the magic > header > >>> field before adding them in (is there an issue for this?) > >>> > >>> I propose parking this for now. > >> > >> > >> I'd rather we hash out these issues and decide on this PR or some > revision > >> one way or the other. There's a lot of other stuff that's kind of piled > up > >> behind the packet header > > > > > > In that case, I'd suggest that we separate the version + magic flag in > one > > PR to address the DoS issue. As discussed at the interim, this would > simply > > mean that we have an interpretation of the version bit that includes the > > magic part. > > > > > > For the long header (inlining my comments below:) > > * Octet 0: Special > > * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) > > * Bit 6-5: Type > > * 11 - client packet > > * 10 - server packet > > * 01 - public reset > > * 00 - version negotiation > > > > Why do you need two codepoints for regular packets? The magic header > gives > > directionality on initial packets, and the connection keys on subsequent > > rounds, right? You need only three codepoints in all here. > > > > * Bits 4-0: Next protocol > > * 0b10001 indicates that it is QUIC handshake data > > * 0b01111 indicates that it is QUIC 0-RTT data > > > > Why do we need these? > > > > * other values mean that the payload following the packet number > > contains > > an IPv6-style extension header > > > > Why do we need this? > > > > * Octets 1-3: Magic (this can be short given that we will have a MAC as > > well) > > * 0x756963 for a client, > > * 0x554943 for a server > > > > SGTM, based on consensus. > > > > > > The proposed short header removes the following bits that I would not > want > > to lose: > > - packet number size. The packet number size currently changes as our > > estimation of how many packets fit in the cwnd changes (loosely speaking) > > and is dynamic through the connection. > > - Connection ID flag, and makes the Connection ID required in all > packets. > > As previously pointed out, this flexibility is quite useful and reduces > > header size quite a bit in the direction where it commonly matters most > > (server->client), but it can be used by any endpoint as long as it does > not > > need Connection ID for routing on incoming packets. > > > > > > Based on my take on the long and short headers above: > > > > If we remove the extensibility points, eliminate server/client > > directionality in the header bits, and retain the fields I noted above, > I'm > > not sure that there's much to be had by separating the long and short > > headers. The resulting header looks as follows on all packets: > > - TT: Packet type > > * 00 - version negotiation packet > > * 01 - public reset > > * 1X - regular packet > > - Key Phase > > - Connection ID > > - Packet Number Size (2 bits) > > > > The only difference from the spec is the TT bits, which is equivalent to > the > > explicit V and PR bits in the spec right now, since with V and PR bits: > > 10 - version negotiation packet > > 01 - public reset packet (we could make this X1, to make it cover the > unused > > codepoint.) > > 00 - regular packet > > > > > > I would suggest a PR that only adds a magic field for directionality, and > > leaves the rest of it out; perhaps in a separate issue + PR to discuss > why > > these may be useful. > > - jana > > > > > > > > > >> -Ekr > >> > >> > >>> > >>> - jana > >>> > >>> > >>> On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett > wrote: > >>>> > >>>> Thanks for taking a crack at this. I have a few high-level comments. > >>>> > >>>> 1) This implicitly requires the connection ID to always be stated, > which > >>>> as Ryan said, inflates the packet header substantially from the > status quo > >>>> of what we send server to client, which I'm not a fan of from a > practical > >>>> perspective. Equally importantly, I think we need to resolve the > >>>> conversation about privacy and connection IDs before we know whether > we > >>>> should always be sending the connection ID. > >>>> 2) I believe we may want to add packet number echo bit(#269) and > >>>> possibly a loss detection bit(#279) on every packet. I think it > makes sense > >>>> to resolve these before redesigning the packet header, since I > believe it > >>>> would substantially change your current design? > >>>> 3) This proposes header extensions, which seems orthogonal to the > header > >>>> redesign. I'm not a fan of header extensions at the moment, but I > think it > >>>> deserves a separate conversation. > >>>> > >>>> So I would be biased towards getting some clarity on the connection id > >>>> privacy question as well as the #269 and #279 before attempting a > holistic > >>>> redesign of the packet header. > >>>> > >>>> On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson > >>>>> wrote: > >>>>>> > >>>>>> As I go through the issues list, it appears that a lot of issues on > >>>>>> which we have consensus would benefit from a resolution to the > header > >>>>>> format issue. To that end, I have sketched out a proposal that I > >>>>>> think meets the various constraints we have. > >>>>>> > >>>>>> I want to discuss this here before we embark on what could be a > fairly > >>>>>> disruptive set of changes to the drafts. > >>>>>> > >>>>>> (A copy of the following text can be found at > >>>>>> https://gist.github.com/martinthomson/ > 744d04cbcec9be554f2f8e7bae2715b8 > >>>>>> ) > >>>>>> -- > >>>>>> > >>>>>> There are two forms of QUIC common header: long and short. Long > form > >>>>>> packets > >>>>>> are used for the initial exchange - until both 1-RTT packet > protection > >>>>>> can be > >>>>>> started AND version negotiation is complete. Short form packets > carry > >>>>>> the > >>>>>> bulk of the data. > >>>>>> > >>>>>> This removes a lot of the flexibility that was the source of most of > >>>>>> the > >>>>>> objections to the current format. Fields are aligned on four octet > >>>>>> boundaries. > >>>>>> All long-form header variations have the exact same form. The > >>>>>> connection ID is > >>>>>> in the same place in both short and long form. The long form > clearly > >>>>>> identifies the role of the sender in the first octet and it > identifies > >>>>>> the > >>>>>> packet as a QUIC packet. > >>>>>> > >>>>>> The cost is that it makes occasional packets a little larger (the > long > >>>>>> header > >>>>>> is 20 octets, whereas the existing form uses between 14 and 19 > octets > >>>>>> for initial > >>>>>> handshake packets). This is an acceptable trade-off given that > only a > >>>>>> few of > >>>>>> these packets are ever exchanged on a connection. > >>>>>> > >>>>>> It makes most packets (the short header) 12 octets where it is > >>>>>> possible to > >>>>>> have 10 octet packets. > >>>>> > >>>>> > >>>>> In currently deployed QUIC, 1-RTT packets from the server to the > client > >>>>> do not have connection ID present. (This is because an endpoint > tells the > >>>>> peer how many connection ID bits it needs the peer to send. In the > case of > >>>>> clients, since they only have 1 connection on a given socket, the > connection > >>>>> ID is not needed.). These packets also typically have a 1 or 2 byte > packet > >>>>> number. So the header ends up being: 1 byte public flags + 1 or 2 > byte > >>>>> packet number for a total of 2-3 bytes. This new format seems to be > much > >>>>> larger. > >>>>> > >>>>>> > >>>>>> However, a 10 octet packet header assumes an 8 bit > >>>>>> packet number, this is 30. > >>>>> > >>>>> > >>>>> I don't think I understand how to construct a 10 octet packet. Can > you > >>>>> elaborate? > >>>>> > >>>>>> > >>>>>> # Long Header > >>>>>> > >>>>>> ``` > >>>>>> 0 1 2 3 > >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> |S|Typ| Next | Magic "uic"/"UIC" | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | | > >>>>>> + Connection ID + > >>>>>> | | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | Version | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | Packet Number | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | [Header Extensions] ... > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | Payload ... > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> ``` > >>>>>> > >>>>>> The first four octets: > >>>>>> * Octet 0: Special > >>>>>> * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) > >>>>>> * Bit 6-5: Type > >>>>>> * 11 - client packet > >>>>>> * 10 - server packet > >>>>>> * 01 - public reset > >>>>>> * 00 - version negotiation > >>>>>> * Bits 4-0: Next protocol > >>>>>> * 0b10001 indicates that it is QUIC handshake data > >>>>>> * 0b01111 indicates that it is QUIC 0-RTT data > >>>>>> * other values mean that the payload following the packet number > >>>>>> contains > >>>>>> an IPv6-style extension header > >>>>>> * Octets 1-3: Magic (this can be short given that we will have a MAC > >>>>>> as well) > >>>>>> * 0x756963 for a client, > >>>>>> * 0x554943 for a server > >>>>>> > >>>>>> Note: A client packet starts with "quic", server starts with "QUIC", > >>>>>> 0-RTT starts > >>>>>> with "ouic". > >>>>>> > >>>>>> Note(2): We might consider the second set of 7 bits to be a single > >>>>>> code space, > >>>>>> rather than use a 2+5 bit partitioning. That gives us a bit more > >>>>>> flexibility > >>>>>> and avoids meaningless combinations like public reset + 0-RTT. > >>>>>> > >>>>>> The remainder of the packet layout is the same regardless of type, > the > >>>>>> difference > >>>>>> being what rules for how to fill the values out and their semantics. > >>>>>> > >>>>>> A client packet then contains: > >>>>>> * Octets 4-11: connection ID (initially all zeroes/random) > >>>>>> * Octets 12-15: version > >>>>>> * Octets 16-19: packet number (low 4 octets, starts at a random > 32-bit > >>>>>> value) > >>>>>> * Octets 20+: payload > >>>>>> > >>>>>> Note: I'm not sure whether the client should pack the connection ID > >>>>>> with random > >>>>>> values. They would have no semantic value, though they might serve > to > >>>>>> provide > >>>>>> proof that the server received the packet if we require echoing, see > >>>>>> below. > >>>>>> > >>>>>> > >>>>>> A server packet contains a connection ID: > >>>>>> * Octets 4-11: connection ID (server-selected value) > >>>>>> * Octets 12-15: version (echoed) > >>>>>> * Octets 16-19: packet number (low 4 octets, random 32-bit initial > >>>>>> value) > >>>>>> * Octets 20+: payload > >>>>>> > >>>>>> A version negotiation packet contains: > >>>>>> * Octets 4-11: connection ID (echoed) > >>>>>> * Octets 12-15: version received (echoed) > >>>>>> * Octets 16-19: packet number (echoed) > >>>>>> * Octets 20+: payload = version list > >>>>> > >>>>> > >>>>> In order for the server to echo back the packet number, the server > >>>>> obviously needs to be able parse the packet number. But if the packet > >>>>> contains a version that the server does not support, it may well be > the case > >>>>> that the packet number layout may be different in the new version. > So I'm > >>>>> not sure it's possible to echo back the packet number. > >>>>>> > >>>>>> A public reset packet contains: > >>>>>> * Octets 4-11: connection ID (echoed) > >>>>>> * Octets 12-15: version (echoed) > >>>>>> * Octets 16-19: rejected packet number (echoed) > >>>>>> * Octets 20+: payload = authentication data > >>>>> > >>>>> > >>>>> Public reset packets are commonly sent when a server receives a > packet > >>>>> for a connection it does not have state for. (For example, a server > restart > >>>>> or a routing hiccup). In this case, the server is responding to a > packet > >>>>> with an unknown version and consequently and unknown packet number. > So I'm > >>>>> not sure it's possible to echo back the packet number. > >>>>>> > >>>>>> Echoing details from the packet in both version negotiation and > >>>>>> provides return > >>>>>> routeability on version negotiation (#244), while maintaining a > >>>>>> consistent > >>>>>> header shape for all packets. > >>>>>> > >>>>>> These long-form packets are used for anything that doesn't have > 1-RTT > >>>>>> packet > >>>>>> protection and prior to the completion of version negotiation. Once > >>>>>> both > >>>>>> conditions are met, switch to sending short-form packets. I haven't > >>>>>> defined any > >>>>>> 5/7-bit code for protected long-form packets, but that's easy to do > if > >>>>>> we need > >>>>>> to provide for them (see below for more on this). > >>>>>> > >>>>>> > >>>>>> ## Extension headers > >>>>>> > >>>>>> An 8-bit space (like IPv6) carries an identifier for the protocol > >>>>>> extension. > >>>>>> > >>>>>> Each header extension takes the form: > >>>>>> * Octet 1: next identifier > >>>>>> * Octet 2: length > >>>>>> > >>>>>> Since only the lower 5 (or 7) bits of this space is accessible from > >>>>>> the outset, > >>>>>> 0x00 is reserved for a null extension header, allowing the full > space > >>>>>> to be > >>>>>> unlocked. 0x?a can be used for greasing. > >>>>>> > >>>>>> I haven't talked to IP-layer people about whether they consider the > >>>>>> IPv6 scheme > >>>>>> this is based on to be successful. Either way, this should at least > >>>>>> have plenty > >>>>>> of hardware support. > >>>>>> > >>>>>> FWIW, I'm not sure that we need the complexity that this adds. It's > >>>>>> not clear > >>>>>> that there is a motivating use case. However, on balance it's > >>>>>> probably worth > >>>>>> putting something in for the moment. If it turns out that we don't > >>>>>> use it and > >>>>>> can't find even a potential use case, then removing it is simple > >>>>>> enough. > >>>>>> > >>>>>> That said, this form could be used to pack a TLS Finished into 1-RTT > >>>>>> packets if > >>>>>> we define a 5- or 7-bit code for "small bit of handshake, followed > by > >>>>>> more", > >>>>>> after which we can include a 1-RTT payload. > >>>>>> > >>>>>> > >>>>>> # Short Header > >>>>>> > >>>>>> ``` > >>>>>> 0 1 2 3 > >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> |S|K| Packet Number (30) | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | | > >>>>>> + Connection ID + > >>>>>> | | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> ``` > >>>>>> > >>>>>> The short form header is defined to be specific to a version. > >>>>>> Anything > >>>>>> can change between protocol versions. > >>>>>> > >>>>>> A short packet header - in this version - reserves two bits from the > >>>>>> first > >>>>>> octet: > >>>>>> * SHORT_HEADER bit 7 (0x80) = 1, > >>>>>> * KEY_PHASE bit 6 (0x40) = 0 initially > >>>>>> > >>>>>> The remainder of the first four octets contain the packet number. > 30 > >>>>>> bits > >>>>>> should be plenty. If a need is found for more flags, those can > steal > >>>>>> upper > >>>>>> bits from the packet number. (Frankly, I suspect that 14 bits might > >>>>>> be > >>>>>> enough, but Ian was a little leery of that when I suggested it, and > >>>>>> this > >>>>>> keeps the connection ID in the same place in every packet.) > >>>>>> > >>>>>> The connection ID follows on the next 8 octets. > >>>>>> > >>>>>> If we need more bits, then we can steal them from the packet number. > >>>>>> > >>>>> > >>>> > >>> > >> > >> > > > --001a114e2b6e6c21cc054826f1b5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Martin,

Responses inline.
=C2=A0
Connection ID removal:
I believe that ekr addressed your concern about the connection ID
removal, so I'm surprised that you bring it up again.=C2=A0 Since we haven't really discussed it thus far, I don't know how important th= is
feature is.=C2=A0 I believe that it means making a choice about whether you=
think connection migration is important or not.=C2=A0 Whether it requires= =C2=A0
an exp= licit per-packet signal is debatable; in developing the
proposal, my assumption was that negotiating connection ID away would
be good enough.

Apologies -- yes, = you're right that ekr addressed it. I agree that it's reasonable to= not have it in each packet. I would suggest that changing the packet heade= r to not have it should be accompanied by text to negotiate it during hands= hake.

On its value: I would strongly argue against= its removal -- it is what allows QUIC to survive NAT rebinding, which we k= now happens often enough to matter. Removing it would be a fundamental chan= ge to the protocol, and would cause measurable performance impact.

Packet number size:
There's a trade-off here.=C2=A0 One of the features of my proposal is t= hat
the connection ID remains in the same place for both short- and
long-form.=C2=A0 I agree that 30 bits is far more than we need, but the
bits were just sitting there doing nothing otherwise.

=
I don't follow -- the 30 bits would be used by the payload, = right?

Extensibility:
ekr explained the rationale here, it's an escape valve.=C2=A0 I too wou= ld
dearly like to remove the feature.=C2=A0 Given that I can't think of a = use
case, I hope that time will come soon.

= I don't think we should add extensibility options now that we hope to n= ever use. If we don't think we'll need it, let's not include it= . Including it attracts nuisance, since extensible fields often find reason= s to be extended. I don't agree with the rationale: providing an escape= valve suggests that we may need to add something that we won't have a = place to put so we can throw it into extensions. If we need something in th= e header later that's important enough, we can always redo this header = later.

The reason for needing a proposal was that it was clear that we needed
a holistic approach to designing the header.=C2=A0 There were just too many=
different, interacting issues.=C2=A0 My proposal addresses many of those at=
once with a simple change.=C2=A0 From a skim through the list: #40, #56, #67, #119, #133, #135, #170, #185, #193, and #244 all go away.=C2=A0 It
also goes some way to address #147 and #205.

(It's late now for me -- I'll go through the issues you've li= sted tomorrow and respond to this point.)

- ja= na

On 10 February 2017 at 12:07, Jana Iyengar <jri@google.com> wrote:
> Hi Eric,
>
> Responses inline.
>
>>>
>>> I like that you've separated the early handshake packet fo= rmat from the
>>> "common case" format -- there may be value in having= that separation when
>>> thinking about overhead and header formats (earlier versions o= f the
>>> transport draft talked about Regular and Special packets, whic= h may be worth
>>> reconsidering.) That said, I think this proposal conflates thr= ee things:
>>> (i) it attempts to compress the header, in some cases
>>
>>
>> I thought there was agreement that making the header smaller was g= ood. Not
>> sure how we would have consensus for that in the abstract, so we p= robably
>> just need to debate whether or not this particular form of compres= sion is
>> good.
>
>
> Agreed in principle, but as Ryan points out, this makes the connection= ID
> show up all the time, which increases header size.
>
>>>
>>> (ii) it changes the header in ways which have been suggested b= ut without
>>> consensus (connection ID, magic field)
>>
>>
>> Hmm.... I thought we did have consensus for the magic field in the=
>> interim. Of course that needs confirmation on the mailing list, bu= t this
>> seems like a good venue for that.
>> I don't think we need concern ourselves with the connection ID= , because
>> this proposal neatly accommodates removing the connection ID field= , either
>> by having the server
>> tell the client it can (with no indicator) or if we like, stealing= a bit
>> from the packet number to say ("here is a conn id"). The= re doesn't seem to
>> be a percentage in removing conn id from the special packets, so w= e don't
>> need to address that.
>
>
> Yes, you're right. We did have consensus on encoding version neg p= ackets to
> include a ver + magic for directionality, but as you note, this hasn&#= 39;t been
> confirmed on the list, and we should do that. This is a simple change = that
> addresses the DoS issue by adding directionality (Issue #135), and tha= t
> change would be relatively small.
>
>>> (iii) it adds extensibility in ways that are not yet justified= .
>>
>>
>> I think I do agree with you here, ultimately, but I'd like to = leave it in
>> for now. My reasoning here is that you often find that you have a = bunch of
>> small things that you want some flexibility for but that aren'= t enough to
>> add a whole new extension point, so you just get death of a thousa= nd cuts as
>> you try to work around them. Contrariwise, if we have this extensi= on point
>> available, we can see if it gets used and pull it out before pubre= q.
>
>
> I am sympathetic to your point about death by a thousand cuts, but I d= on't
> think we're there yet. I'm still of the opinion that this intr= oduces
> unwarranted arbitrary extensibility in the header, since I don't s= ee the
> warranting use cases.
>
>>>
>>> I think the proposal is useful in that it shows how the header= might look
>>> in a different world. But let's get consensus on what'= s reasonable to do
>>> before figuring out how to do it. Specifically, as Ian notes, = #269 and #279
>>> are existing issues, and we need to discuss things like the ma= gic header
>>> field before adding them in (is there an issue for this?)
>>>
>>> I propose parking this for now.
>>
>>
>> I'd rather we hash out these issues and decide on this PR or s= ome revision
>> one way or the other. There's a lot of other stuff that's = kind of piled up
>> behind the packet header
>
>
> In that case, I'd suggest that we separate the version + magic fla= g in one
> PR to address the DoS issue. As discussed at the interim, this would s= imply
> mean that we have an interpretation of the version bit that includes t= he
> magic part.
>
>
> For the long header (inlining my comments below:)
> * Octet 0: Special
>=C2=A0 =C2=A0* Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here)
>=C2=A0 =C2=A0* Bit 6-5: Type
>=C2=A0 =C2=A0 =C2=A0* 11 - client packet
>=C2=A0 =C2=A0 =C2=A0* 10 - server packet
>=C2=A0 =C2=A0 =C2=A0* 01 - public reset
>=C2=A0 =C2=A0 =C2=A0* 00 - version negotiation
>
> Why do you need two codepoints for regular packets? The magic header g= ives
> directionality on initial packets, and the connection keys on subseque= nt
> rounds, right? You need only three codepoints in all here.
>
>=C2=A0 =C2=A0* Bits 4-0: Next protocol
>=C2=A0 =C2=A0 =C2=A0* 0b10001 indicates that it is QUIC handshake data<= br> >=C2=A0 =C2=A0 =C2=A0* 0b01111 indicates that it is QUIC 0-RTT data
>
> Why do we need these?
>
>=C2=A0 =C2=A0 =C2=A0* other values mean that the payload following the = packet number
> contains
>=C2=A0 =C2=A0 =C2=A0 an IPv6-style extension header
>
> Why do we need this?
>
> * Octets 1-3: Magic (this can be short given that we will have a MAC a= s
> well)
>=C2=A0 =C2=A0* 0x756963 for a client,
>=C2=A0 =C2=A0* 0x554943 for a server
>
> SGTM, based on consensus.
>
>
> The proposed short header removes the following bits that I would not = want
> to lose:
> - packet number size. The packet number size currently changes as our<= br> > estimation of how many packets fit in the cwnd changes (loosely speaki= ng)
> and is dynamic through the connection.
> - Connection ID flag, and makes the Connection ID required in all pack= ets.
> As previously pointed out, this flexibility is quite useful and reduce= s
> header size quite a bit in the direction where it commonly matters mos= t
> (server->client), but it can be used by any endpoint as long as it = does not
> need Connection ID for routing on incoming packets.
>
>
> Based on my take on the long and short headers above:
>
> If we remove the extensibility points, eliminate server/client
> directionality in the header bits, and retain the fields I noted above= , I'm
> not sure that there's much to be had by separating the long and sh= ort
> headers. The resulting header looks as follows on all packets:
> - TT: Packet type
>=C2=A0 =C2=A0 =C2=A0* 00 - version negotiation packet
>=C2=A0 =C2=A0 =C2=A0* 01 - public reset
>=C2=A0 =C2=A0 =C2=A0* 1X - regular packet
> - Key Phase
> - Connection ID
> - Packet Number Size (2 bits)
>
> The only difference from the spec is the TT bits, which is equivalent = to the
> explicit V and PR bits in the spec right now, since with V and PR bits= :
> 10 - version negotiation packet
> 01 - public reset packet (we could make this X1, to make it cover the = unused
> codepoint.)
> 00 - regular packet
>
>
> I would suggest a PR that only adds a magic field for directionality, = and
> leaves the rest of it out; perhaps in a separate issue + PR to discuss= why
> these may be useful.
> - jana
>
>
>
>
>> -Ekr
>>
>>
>>>
>>> - jana
>>>
>>>
>>> On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett <ianswett@google.com> wrote:
>>>>
>>>> Thanks for taking a crack at this.=C2=A0 I have a few high= -level comments.
>>>>
>>>> 1) This implicitly requires the connection ID to always be= stated, which
>>>> as Ryan said, inflates the packet header substantially fro= m the status quo
>>>> of what we send server to client, which I'm not a fan = of from a practical
>>>> perspective.=C2=A0 Equally importantly, I think we need to= resolve the
>>>> conversation about privacy and connection IDs before we kn= ow whether we
>>>> should always be sending the connection ID.
>>>> 2) I believe we may want to add packet number echo bit(#26= 9) and
>>>> possibly a loss detection bit(#279) on every packet.=C2=A0= I think it makes sense
>>>> to resolve these before redesigning the packet header, sin= ce I believe it
>>>> would substantially change your current design?
>>>> 3) This proposes header extensions, which seems orthogonal= to the header
>>>> redesign.=C2=A0 I'm not a fan of header extensions at = the moment, but I think it
>>>> deserves a separate conversation.
>>>>
>>>> So I would be biased towards getting some clarity on the c= onnection id
>>>> privacy question as well as the #269 and #279 before attem= pting a holistic
>>>> redesign of the packet header.
>>>>
>>>> On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton <rch@google.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson
>>>>> <martin= .thomson@gmail.com> wrote:
>>>>>>
>>>>>> As I go through the issues list, it appears that a= lot of issues on
>>>>>> which we have consensus would benefit from a resol= ution to the header
>>>>>> format issue.=C2=A0 To that end, I have sketched o= ut a proposal that I
>>>>>> think meets the various constraints we have.
>>>>>>
>>>>>> I want to discuss this here before we embark on wh= at could be a fairly
>>>>>> disruptive set of changes to the drafts.
>>>>>>
>>>>>> (A copy of the following text can be found at
>>>>>> https= ://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8
>>>>>> )
>>>>>> --
>>>>>>
>>>>>> There are two forms of QUIC common header: long an= d short.=C2=A0 Long form
>>>>>> packets
>>>>>> are used for the initial exchange - until both 1-R= TT packet protection
>>>>>> can be
>>>>>> started AND version negotiation is complete.=C2=A0= Short form packets carry
>>>>>> the
>>>>>> bulk of the data.
>>>>>>
>>>>>> This removes a lot of the flexibility that was the= source of most of
>>>>>> the
>>>>>> objections to the current format.=C2=A0 Fields are= aligned on four octet
>>>>>> boundaries.
>>>>>> All long-form header variations have the exact sam= e form.=C2=A0 The
>>>>>> connection ID is
>>>>>> in the same place in both short and long form.=C2= =A0 The long form clearly
>>>>>> identifies the role of the sender in the first oct= et and it identifies
>>>>>> the
>>>>>> packet as a QUIC packet.
>>>>>>
>>>>>> The cost is that it makes occasional packets a lit= tle larger (the long
>>>>>> header
>>>>>> is 20 octets, whereas the existing form uses betwe= en 14 and 19 octets
>>>>>> for initial
>>>>>> handshake packets).=C2=A0 This is an acceptable tr= ade-off given that only a
>>>>>> few of
>>>>>> these packets are ever exchanged on a connection.<= br> >>>>>>
>>>>>> It makes most packets (the short header) 12 octets= where it is
>>>>>> possible to
>>>>>> have 10 octet packets.
>>>>>
>>>>>
>>>>> In currently deployed QUIC, 1-RTT packets from the ser= ver to the client
>>>>> do not have connection ID present. (This is because an= endpoint tells the
>>>>> peer how many connection ID bits it needs the peer to = send. In the case of
>>>>> clients, since they only have 1 connection on a given = socket, the connection
>>>>> ID is not needed.). These packets also typically have = a 1 or 2 byte packet
>>>>> number. So the header ends up being:=C2=A0 1 byte publ= ic flags + 1 or 2 byte
>>>>> packet number for a total of 2-3 bytes. This new forma= t seems to be much
>>>>> larger.
>>>>>
>>>>>>
>>>>>> However, a 10 octet packet header assumes an 8 bit=
>>>>>> packet number, this is 30.
>>>>>
>>>>>
>>>>> I don't think I understand how to construct a 10 o= ctet packet. Can you
>>>>> elaborate?
>>>>>
>>>>>>
>>>>>> # Long Header
>>>>>>
>>>>>> ```
>>>>>>=C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A03
>>>>>>=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |S|Typ|=C2=A0 Next=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Magic "uic"/"UIC"=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet Number=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Header Extensions]=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=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...
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> ```
>>>>>>
>>>>>> The first four octets:
>>>>>> * Octet 0: Special
>>>>>>=C2=A0 =C2=A0* Bit 7 (i.e., 0x80): SHORT_HEADER (se= t to 0 here)
>>>>>>=C2=A0 =C2=A0* Bit 6-5: Type
>>>>>>=C2=A0 =C2=A0 =C2=A0* 11 - client packet
>>>>>>=C2=A0 =C2=A0 =C2=A0* 10 - server packet
>>>>>>=C2=A0 =C2=A0 =C2=A0* 01 - public reset
>>>>>>=C2=A0 =C2=A0 =C2=A0* 00 - version negotiation
>>>>>>=C2=A0 =C2=A0* Bits 4-0: Next protocol
>>>>>>=C2=A0 =C2=A0 =C2=A0* 0b10001 indicates that it is = QUIC handshake data
>>>>>>=C2=A0 =C2=A0 =C2=A0* 0b01111 indicates that it is = QUIC 0-RTT data
>>>>>>=C2=A0 =C2=A0 =C2=A0* other values mean that the pa= yload following the packet number
>>>>>> contains
>>>>>>=C2=A0 =C2=A0 =C2=A0 an IPv6-style extension header=
>>>>>> * Octets 1-3: Magic (this can be short given that = we will have a MAC
>>>>>> as well)
>>>>>>=C2=A0 =C2=A0* 0x756963 for a client,
>>>>>>=C2=A0 =C2=A0* 0x554943 for a server
>>>>>>
>>>>>> Note: A client packet starts with "quic"= , server starts with "QUIC",
>>>>>> 0-RTT starts
>>>>>> with "ouic".
>>>>>>
>>>>>> Note(2): We might consider the second set of 7 bit= s to be a single
>>>>>> code space,
>>>>>> rather than use a 2+5 bit partitioning.=C2=A0 That= gives us a bit more
>>>>>> flexibility
>>>>>> and avoids meaningless combinations like public re= set + 0-RTT.
>>>>>>
>>>>>> The remainder of the packet layout is the same reg= ardless of type, the
>>>>>> difference
>>>>>> being what rules for how to fill the values out an= d their semantics.
>>>>>>
>>>>>> A client packet then contains:
>>>>>> * Octets 4-11: connection ID (initially all zeroes= /random)
>>>>>> * Octets 12-15: version
>>>>>> * Octets 16-19: packet number (low 4 octets, start= s at a random 32-bit
>>>>>> value)
>>>>>> * Octets 20+: payload
>>>>>>
>>>>>> Note: I'm not sure whether the client should p= ack the connection ID
>>>>>> with random
>>>>>> values.=C2=A0 They would have no semantic value, t= hough they might serve to
>>>>>> provide
>>>>>> proof that the server received the packet if we re= quire echoing, see
>>>>>> below.
>>>>>>
>>>>>>
>>>>>> A server packet contains a connection ID:
>>>>>> * Octets 4-11: connection ID (server-selected valu= e)
>>>>>> * Octets 12-15: version (echoed)
>>>>>> * Octets 16-19: packet number (low 4 octets, rando= m 32-bit initial
>>>>>> value)
>>>>>> * Octets 20+: payload
>>>>>>
>>>>>> A version negotiation packet contains:
>>>>>> * Octets 4-11: connection ID (echoed)
>>>>>> * Octets 12-15: version received (echoed)
>>>>>> * Octets 16-19: packet number (echoed)
>>>>>> * Octets 20+: payload =3D version list
>>>>>
>>>>>
>>>>> In order for the server to echo back the packet number= , the server
>>>>> obviously needs to be able parse the packet number. Bu= t if the packet
>>>>> contains a version that the server does not support, i= t may well be the case
>>>>> that the packet number layout may be different in the = new version. So I'm
>>>>> not sure it's possible to echo back the packet num= ber.
>>>>>>
>>>>>> A public reset packet contains:
>>>>>> * Octets 4-11: connection ID (echoed)
>>>>>> * Octets 12-15: version (echoed)
>>>>>> * Octets 16-19: rejected packet number (echoed) >>>>>> * Octets 20+: payload =3D authentication data
>>>>>
>>>>>
>>>>> Public reset packets are commonly sent when a server r= eceives a packet
>>>>> for a connection it does not have state for. (For exam= ple, a server restart
>>>>> or a routing hiccup). In this case, the server is resp= onding to a packet
>>>>> with an unknown version and consequently and unknown p= acket number. So I'm
>>>>> not sure it's possible to echo back the packet num= ber.
>>>>>>
>>>>>> Echoing details from the packet in both version ne= gotiation and
>>>>>> provides return
>>>>>> routeability on version negotiation (#244), while = maintaining a
>>>>>> consistent
>>>>>> header shape for all packets.
>>>>>>
>>>>>> These long-form packets are used for anything that= doesn't have 1-RTT
>>>>>> packet
>>>>>> protection and prior to the completion of version = negotiation.=C2=A0 Once
>>>>>> both
>>>>>> conditions are met, switch to sending short-form p= ackets.=C2=A0 I haven't
>>>>>> defined any
>>>>>> 5/7-bit code for protected long-form packets, but = that's easy to do if
>>>>>> we need
>>>>>> to provide for them (see below for more on this).<= br> >>>>>>
>>>>>>
>>>>>> ## Extension headers
>>>>>>
>>>>>> An 8-bit space (like IPv6) carries an identifier f= or the protocol
>>>>>> extension.
>>>>>>
>>>>>> Each header extension takes the form:
>>>>>> * Octet 1: next identifier
>>>>>> * Octet 2: length
>>>>>>
>>>>>> Since only the lower 5 (or 7) bits of this space i= s accessible from
>>>>>> the outset,
>>>>>> 0x00 is reserved for a null extension header, allo= wing the full space
>>>>>> to be
>>>>>> unlocked.=C2=A0 0x?a can be used for greasing.
>>>>>>
>>>>>> I haven't talked to IP-layer people about whet= her they consider the
>>>>>> IPv6 scheme
>>>>>> this is based on to be successful.=C2=A0 Either wa= y, this should at least
>>>>>> have plenty
>>>>>> of hardware support.
>>>>>>
>>>>>> FWIW, I'm not sure that we need the complexity= that this adds.=C2=A0 It's
>>>>>> not clear
>>>>>> that there is a motivating use case.=C2=A0 =C2=A0H= owever, on balance it's
>>>>>> probably worth
>>>>>> putting something in for the moment.=C2=A0 If it t= urns out that we don't
>>>>>> use it and
>>>>>> can't find even a potential use case, then rem= oving it is simple
>>>>>> enough.
>>>>>>
>>>>>> That said, this form could be used to pack a TLS F= inished into 1-RTT
>>>>>> packets if
>>>>>> we define a 5- or 7-bit code for "small bit o= f handshake, followed by
>>>>>> more",
>>>>>> after which we can include a 1-RTT payload.
>>>>>>
>>>>>>
>>>>>> # Short Header
>>>>>>
>>>>>> ```
>>>>>>=C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A03
>>>>>>=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |S|K|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Packet Number (30)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> ```
>>>>>>
>>>>>> The short form header is defined to be specific to= a version.
>>>>>> Anything
>>>>>> can change between protocol versions.
>>>>>>
>>>>>> A short packet header - in this version - reserves= two bits from the
>>>>>> first
>>>>>> octet:
>>>>>> * SHORT_HEADER bit 7 (0x80) =3D 1,
>>>>>> * KEY_PHASE bit 6 (0x40) =3D 0 initially
>>>>>>
>>>>>> The remainder of the first four octets contain the= packet number.=C2=A0 30
>>>>>> bits
>>>>>> should be plenty.=C2=A0 If a need is found for mor= e flags, those can steal
>>>>>> upper
>>>>>> bits from the packet number.=C2=A0 (Frankly, I sus= pect that 14 bits might
>>>>>> be
>>>>>> enough, but Ian was a little leery of that when I = suggested it, and
>>>>>> this
>>>>>> keeps the connection ID in the same place in every= packet.)
>>>>>>
>>>>>> The connection ID follows on the next 8 octets. >>>>>>
>>>>>> If we need more bits, then we can steal them from = the packet number.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>

--001a114e2b6e6c21cc054826f1b5-- From nobody Thu Feb 9 22:38:12 2017 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 3F0B7129A41 for ; Thu, 9 Feb 2017 22:38:02 -0800 (PST) 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 qQHadkKqQ4id for ; Thu, 9 Feb 2017 22:38:01 -0800 (PST) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3770B12973A for ; Thu, 9 Feb 2017 22:38:01 -0800 (PST) Received: by mail-qt0-x244.google.com with SMTP id s58so3457281qtc.2 for ; Thu, 09 Feb 2017 22:38:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FnGvYP4T3gDNwAnzG9MgHMJXILdm1VOXJd9Af/oM7iA=; b=HhDfAccasf8LD8epRRJSpNqqj60BWAiA1EXZgYPYuN82Y3p//y86uduHNv+vD+C0JH 9h9+Dk05Tly/9ID6okzjHDiJci+KgcWZVlzfgL8ETVHBgY4qwI7UNP5lU1p5ufjxicJ+ OKoRx4Ho5/f+n/q8szZHlVRkul+1dn2jp0puJ4Jco3Jdv4mtPmKqQBdCfLXyZWc2vkwK 5185NWn+M5PNdZpawImnmDhX3XCzaZgAFvREGd/Xqrf40w285YOUUJrCpbvL5raikK9j rlGfWDKuJ5or5n689yhSwTTFYQx8t372R/NoNThjNGY3Yt1ZZril5G5mGhtZ1a65yTjL uHZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FnGvYP4T3gDNwAnzG9MgHMJXILdm1VOXJd9Af/oM7iA=; b=rSRmrBkitRC8rSowu5hujs9QobNTc0olvjl5l6yIiPwUEFK55EEOBiLghhHLzldqzQ mDjnmo/gn5lISCfCaTHz5XzjBLT8FvP2JahO8M5Bz+ZqwEe4361jYsJSf/iXSGNtAqY/ eEhNJ6JelDuuL8XoKfOdZEXQWXwTl6ySvaV4ob1PJaEOYxLTmiBAY3y8oHeEP/6smfC1 AmD1ibdoUVpoafowx1NjZ9P7UCJOXitcEgCvgC63q2JNDoPE61G8OHtFZPvom6Dlx0Lu xHRjT74ZbZDWBBAutFp3lTWvdzquQpKJLu4PK1oTmeJHEnqbBoVIKlAGnEoJba2zozSO tHIA== X-Gm-Message-State: AMke39mau/Ip+P9n14l83vdBOSz7op6tjczPa5YmDOnnsrb+VVn4LwRngniykSUPjQrftkRQNrSJv/u+VsJe4A== X-Received: by 10.200.53.247 with SMTP id l52mr6726293qtb.144.1486708680411; Thu, 09 Feb 2017 22:38:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 9 Feb 2017 22:37:59 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 10 Feb 2017 17:37:59 +1100 Message-ID: Subject: Re: Proposal for QUIC header To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Ian Swett , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2017 06:38:02 -0000 Brief answers, we'll resume when you have operating capacity. On 10 February 2017 at 17:09, Jana Iyengar wrote: > What do you gain by removing packet number size bits (besides 2 bits in the > header)? Consistent position of the connection ID primarily. And I didn't really propose removing the bits, it's just that if you accept that having a stable position for the routing information is valuable, there is no point in flexibility above 30 and going below 30 means you have idle bits lying around. So it just happened. > One clarification question you haven't answered: Why do you need a > client/server bit in Typ? It's not really a bit - obviously the part where I talk about 5 and 7 bits was a little obtuse and I should on improving my explanation of that some. The reason was largely so that it wouldn't say "Quic" and "QUIC", but could say "quic" and "QUIC". An inane reason, I know, but the actual space available is so large that a conceit like that seemed affordable. I'm now of the opinion that you can use that first byte (after the "special" bit) as a single unified type (of 7-bits) and dispense with the bit twiddling. But I didn't come to that conclusion until well after I had written this up and I thought that the formulation with a 2-bit type might end up being easier for people to understand. From nobody Sun Feb 12 09:59:25 2017 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 8F70312999C for ; Sun, 12 Feb 2017 09:59:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rjX_zMg7kk8t for ; Sun, 12 Feb 2017 09:59:21 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E236A12999E for ; Sun, 12 Feb 2017 09:59:20 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id j82so22474769ybg.1 for ; Sun, 12 Feb 2017 09:59:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CyKTd8f4oNISZNht63YCYypKoGGZElIXTlPne0yiSbU=; b=Mse7bbCApU2UvM5cGf+awTG62D/hQ93Eche789tzxlNdIB0tKpyups5zDy/czYxuFC yftvi1lp2MDSBSM9Sqm5mUc+PoL6pGLBHOcKNPb/xvhuzL72jOUIOBuy2HEsKLyKVIj5 rR/BqpVQph2xlXEA8zZ0m4oWBU4nK56IdlZnk1pWfibz/MpxyqeZnA1N1WuZBHXL6m8R jHw+UdJ+uvGdG3qD6Ug9NArgGooSZ/d59PQ9yWCqTMQR19f0weP2UDbHmS3fhfQO/OLg io2j7zZkAwr/91rB/hfOn8wt2OCLxRiWPg3PvFr0C9J2178l19I03qs9NR60f2XtTQAx uM+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CyKTd8f4oNISZNht63YCYypKoGGZElIXTlPne0yiSbU=; b=e5z7tFTGMHxel/HtS4O8Oeoe7vcHe1V48QDk01aFAKpF7Wgz+MpUhtLWoBWCepqDjG +MTwN6HMrA5sCH7NofYFNYSGY4RDekTselmhqV5Uqti9A+vI/wEJzBIy9cDmAPPIH8bK x2L/bV5s/207lyRENiWEa0egzDqooB+744emSMc3P1or0ES71FtDK9A9epnNCaogw7kE H825bLUv5Y1xay7gmKBzhb+vgztU1pqPERSDjmS259CrTbc4bGSDTIOqGJISlQQPgykB 6fgmaJBFPh7eyusHcNt8iMRNnfIdscZ0lull41yAUX7ygbqtldZy95jByxXC0ZOMP+5O Leaw== X-Gm-Message-State: AMke39k+euQWzqidIeQe3hEaEDUBdSm+PO5YOIQ53wV+nT3zFB7DDXjo1V4cgyBgJU9Op7iwDfgX/GcSBkTR9WbC X-Received: by 10.37.86.215 with SMTP id k206mr13308458ybb.66.1486922359655; Sun, 12 Feb 2017 09:59:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Sun, 12 Feb 2017 09:58:59 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Sun, 12 Feb 2017 12:58:59 -0500 Message-ID: Subject: Re: Proposal for QUIC header To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114257320ed0a905485917b0 Archived-At: Cc: Jana Iyengar , Eric Rescorla , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 17:59:24 -0000 --001a114257320ed0a905485917b0 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 9, 2017 at 9:40 PM, Martin Thomson wrote: > Hi Jana, > > To address your concerns: > > Connection ID removal: > I believe that ekr addressed your concern about the connection ID > removal, so I'm surprised that you bring it up again. Since we > haven't really discussed it thus far, I don't know how important this > feature is. I believe that it means making a choice about whether you > think connection migration is important or not. Whether it requires > an explicit per-packet signal is debatable; in developing the > proposal, my assumption was that negotiating connection ID away would > be good enough. > > Packet number size: > There's a trade-off here. One of the features of my proposal is that > the connection ID remains in the same place for both short- and > long-form. I agree that 30 bits is far more than we need, but the > bits were just sitting there doing nothing otherwise. > > Also, I don't feel much urgency behind byte-level optimizations for > small BDP when they come at the expense of other things. The trends > are all toward increases in that number. > > Extensibility: > ekr explained the rationale here, it's an escape valve. I too would > dearly like to remove the feature. Given that I can't think of a use > case, I hope that time will come soon. > > All the use cases I can think of for extensibility would be on short packets, so if we're going to do this, I think it should be available there as well. Also, the last time I remember talking about an extensible UDP header, it was at the PLUS BoF, where there were quite a few objections, notably on privacy grounds. I don't understand ekr's rationale. We'll already be doing negotiation as part of the QUIC handshake in TLS, so I feel like that combined with version negotiation provide a pretty substantial escape valve. These extensions seem only valuable to communicate to or from middleboxes or if we absolutely have to add something to 0RTT packets. > It seems like your counter-proposal just reiterates the current design > with some minor adjustments. I just don't think that is sufficient to > address the concerns that people have raised about the excessive > number of variations in packet layout. Adding a magic field in the > way you propose only compounds that problem. > > > The reason for needing a proposal was that it was clear that we needed > a holistic approach to designing the header. There were just too many > different, interacting issues. My proposal addresses many of those at > once with a simple change. From a skim through the list: #40, #56, > #67, #119, #133, #135, #170, #185, #193, and #244 all go away. It > also goes some way to address #147 and #205. > > After reading through them, I don't believe #40, #56, #67, #119, #133, #135, #170, #185, #193, and #244 all go away with this proposal, since this proposal really is about framing. Some were tentatively resolved at the interim or are in the process of being resolved by proper documentation(thanks for your #67 PR, BTW). Additionally, this has implications on other issues, such as #203, #269 and #279, and I opened #292 and #293 to discuss whether a fixed location for connection id and 4 byte alignment are requirements. On the other hand, if we had clear direction on most of the non-editorial issues listed(except #40, which is really only a question of framing), we'd be in a better position to fix up the framing with a clear set of goals. On 10 February 2017 at 12:07, Jana Iyengar wrote: > > Hi Eric, > > > > Responses inline. > > > >>> > >>> I like that you've separated the early handshake packet format from the > >>> "common case" format -- there may be value in having that separation > when > >>> thinking about overhead and header formats (earlier versions of the > >>> transport draft talked about Regular and Special packets, which may be > worth > >>> reconsidering.) That said, I think this proposal conflates three > things: > >>> (i) it attempts to compress the header, in some cases > >> > >> > >> I thought there was agreement that making the header smaller was good. > Not > >> sure how we would have consensus for that in the abstract, so we > probably > >> just need to debate whether or not this particular form of compression > is > >> good. > > > > > > Agreed in principle, but as Ryan points out, this makes the connection ID > > show up all the time, which increases header size. > > > >>> > >>> (ii) it changes the header in ways which have been suggested but > without > >>> consensus (connection ID, magic field) > >> > >> > >> Hmm.... I thought we did have consensus for the magic field in the > >> interim. Of course that needs confirmation on the mailing list, but this > >> seems like a good venue for that. > >> I don't think we need concern ourselves with the connection ID, because > >> this proposal neatly accommodates removing the connection ID field, > either > >> by having the server > >> tell the client it can (with no indicator) or if we like, stealing a bit > >> from the packet number to say ("here is a conn id"). There doesn't seem > to > >> be a percentage in removing conn id from the special packets, so we > don't > >> need to address that. > > > > > > Yes, you're right. We did have consensus on encoding version neg packets > to > > include a ver + magic for directionality, but as you note, this hasn't > been > > confirmed on the list, and we should do that. This is a simple change > that > > addresses the DoS issue by adding directionality (Issue #135), and that > > change would be relatively small. > > > >>> (iii) it adds extensibility in ways that are not yet justified. > >> > >> > >> I think I do agree with you here, ultimately, but I'd like to leave it > in > >> for now. My reasoning here is that you often find that you have a bunch > of > >> small things that you want some flexibility for but that aren't enough > to > >> add a whole new extension point, so you just get death of a thousand > cuts as > >> you try to work around them. Contrariwise, if we have this extension > point > >> available, we can see if it gets used and pull it out before pubreq. > > > > > > I am sympathetic to your point about death by a thousand cuts, but I > don't > > think we're there yet. I'm still of the opinion that this introduces > > unwarranted arbitrary extensibility in the header, since I don't see the > > warranting use cases. > > > >>> > >>> I think the proposal is useful in that it shows how the header might > look > >>> in a different world. But let's get consensus on what's reasonable to > do > >>> before figuring out how to do it. Specifically, as Ian notes, #269 and > #279 > >>> are existing issues, and we need to discuss things like the magic > header > >>> field before adding them in (is there an issue for this?) > >>> > >>> I propose parking this for now. > >> > >> > >> I'd rather we hash out these issues and decide on this PR or some > revision > >> one way or the other. There's a lot of other stuff that's kind of piled > up > >> behind the packet header > > > > > > In that case, I'd suggest that we separate the version + magic flag in > one > > PR to address the DoS issue. As discussed at the interim, this would > simply > > mean that we have an interpretation of the version bit that includes the > > magic part. > > > > > > For the long header (inlining my comments below:) > > * Octet 0: Special > > * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) > > * Bit 6-5: Type > > * 11 - client packet > > * 10 - server packet > > * 01 - public reset > > * 00 - version negotiation > > > > Why do you need two codepoints for regular packets? The magic header > gives > > directionality on initial packets, and the connection keys on subsequent > > rounds, right? You need only three codepoints in all here. > > > > * Bits 4-0: Next protocol > > * 0b10001 indicates that it is QUIC handshake data > > * 0b01111 indicates that it is QUIC 0-RTT data > > > > Why do we need these? > > > > * other values mean that the payload following the packet number > > contains > > an IPv6-style extension header > > > > Why do we need this? > > > > * Octets 1-3: Magic (this can be short given that we will have a MAC as > > well) > > * 0x756963 for a client, > > * 0x554943 for a server > > > > SGTM, based on consensus. > > > > > > The proposed short header removes the following bits that I would not > want > > to lose: > > - packet number size. The packet number size currently changes as our > > estimation of how many packets fit in the cwnd changes (loosely speaking) > > and is dynamic through the connection. > > - Connection ID flag, and makes the Connection ID required in all > packets. > > As previously pointed out, this flexibility is quite useful and reduces > > header size quite a bit in the direction where it commonly matters most > > (server->client), but it can be used by any endpoint as long as it does > not > > need Connection ID for routing on incoming packets. > > > > > > Based on my take on the long and short headers above: > > > > If we remove the extensibility points, eliminate server/client > > directionality in the header bits, and retain the fields I noted above, > I'm > > not sure that there's much to be had by separating the long and short > > headers. The resulting header looks as follows on all packets: > > - TT: Packet type > > * 00 - version negotiation packet > > * 01 - public reset > > * 1X - regular packet > > - Key Phase > > - Connection ID > > - Packet Number Size (2 bits) > > > > The only difference from the spec is the TT bits, which is equivalent to > the > > explicit V and PR bits in the spec right now, since with V and PR bits: > > 10 - version negotiation packet > > 01 - public reset packet (we could make this X1, to make it cover the > unused > > codepoint.) > > 00 - regular packet > > > > > > I would suggest a PR that only adds a magic field for directionality, and > > leaves the rest of it out; perhaps in a separate issue + PR to discuss > why > > these may be useful. > > - jana > > > > > > > > > >> -Ekr > >> > >> > >>> > >>> - jana > >>> > >>> > >>> On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett > wrote: > >>>> > >>>> Thanks for taking a crack at this. I have a few high-level comments. > >>>> > >>>> 1) This implicitly requires the connection ID to always be stated, > which > >>>> as Ryan said, inflates the packet header substantially from the > status quo > >>>> of what we send server to client, which I'm not a fan of from a > practical > >>>> perspective. Equally importantly, I think we need to resolve the > >>>> conversation about privacy and connection IDs before we know whether > we > >>>> should always be sending the connection ID. > >>>> 2) I believe we may want to add packet number echo bit(#269) and > >>>> possibly a loss detection bit(#279) on every packet. I think it > makes sense > >>>> to resolve these before redesigning the packet header, since I > believe it > >>>> would substantially change your current design? > >>>> 3) This proposes header extensions, which seems orthogonal to the > header > >>>> redesign. I'm not a fan of header extensions at the moment, but I > think it > >>>> deserves a separate conversation. > >>>> > >>>> So I would be biased towards getting some clarity on the connection id > >>>> privacy question as well as the #269 and #279 before attempting a > holistic > >>>> redesign of the packet header. > >>>> > >>>> On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton wrote: > >>>>> > >>>>> > >>>>> > >>>>> On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson > >>>>> wrote: > >>>>>> > >>>>>> As I go through the issues list, it appears that a lot of issues on > >>>>>> which we have consensus would benefit from a resolution to the > header > >>>>>> format issue. To that end, I have sketched out a proposal that I > >>>>>> think meets the various constraints we have. > >>>>>> > >>>>>> I want to discuss this here before we embark on what could be a > fairly > >>>>>> disruptive set of changes to the drafts. > >>>>>> > >>>>>> (A copy of the following text can be found at > >>>>>> https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e > 7bae2715b8 > >>>>>> ) > >>>>>> -- > >>>>>> > >>>>>> There are two forms of QUIC common header: long and short. Long > form > >>>>>> packets > >>>>>> are used for the initial exchange - until both 1-RTT packet > protection > >>>>>> can be > >>>>>> started AND version negotiation is complete. Short form packets > carry > >>>>>> the > >>>>>> bulk of the data. > >>>>>> > >>>>>> This removes a lot of the flexibility that was the source of most of > >>>>>> the > >>>>>> objections to the current format. Fields are aligned on four octet > >>>>>> boundaries. > >>>>>> All long-form header variations have the exact same form. The > >>>>>> connection ID is > >>>>>> in the same place in both short and long form. The long form > clearly > >>>>>> identifies the role of the sender in the first octet and it > identifies > >>>>>> the > >>>>>> packet as a QUIC packet. > >>>>>> > >>>>>> The cost is that it makes occasional packets a little larger (the > long > >>>>>> header > >>>>>> is 20 octets, whereas the existing form uses between 14 and 19 > octets > >>>>>> for initial > >>>>>> handshake packets). This is an acceptable trade-off given that > only a > >>>>>> few of > >>>>>> these packets are ever exchanged on a connection. > >>>>>> > >>>>>> It makes most packets (the short header) 12 octets where it is > >>>>>> possible to > >>>>>> have 10 octet packets. > >>>>> > >>>>> > >>>>> In currently deployed QUIC, 1-RTT packets from the server to the > client > >>>>> do not have connection ID present. (This is because an endpoint > tells the > >>>>> peer how many connection ID bits it needs the peer to send. In the > case of > >>>>> clients, since they only have 1 connection on a given socket, the > connection > >>>>> ID is not needed.). These packets also typically have a 1 or 2 byte > packet > >>>>> number. So the header ends up being: 1 byte public flags + 1 or 2 > byte > >>>>> packet number for a total of 2-3 bytes. This new format seems to be > much > >>>>> larger. > >>>>> > >>>>>> > >>>>>> However, a 10 octet packet header assumes an 8 bit > >>>>>> packet number, this is 30. > >>>>> > >>>>> > >>>>> I don't think I understand how to construct a 10 octet packet. Can > you > >>>>> elaborate? > >>>>> > >>>>>> > >>>>>> # Long Header > >>>>>> > >>>>>> ``` > >>>>>> 0 1 2 3 > >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> |S|Typ| Next | Magic "uic"/"UIC" | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | | > >>>>>> + Connection ID + > >>>>>> | | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | Version | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | Packet Number | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | [Header Extensions] ... > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | Payload ... > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> ``` > >>>>>> > >>>>>> The first four octets: > >>>>>> * Octet 0: Special > >>>>>> * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) > >>>>>> * Bit 6-5: Type > >>>>>> * 11 - client packet > >>>>>> * 10 - server packet > >>>>>> * 01 - public reset > >>>>>> * 00 - version negotiation > >>>>>> * Bits 4-0: Next protocol > >>>>>> * 0b10001 indicates that it is QUIC handshake data > >>>>>> * 0b01111 indicates that it is QUIC 0-RTT data > >>>>>> * other values mean that the payload following the packet number > >>>>>> contains > >>>>>> an IPv6-style extension header > >>>>>> * Octets 1-3: Magic (this can be short given that we will have a MAC > >>>>>> as well) > >>>>>> * 0x756963 for a client, > >>>>>> * 0x554943 for a server > >>>>>> > >>>>>> Note: A client packet starts with "quic", server starts with "QUIC", > >>>>>> 0-RTT starts > >>>>>> with "ouic". > >>>>>> > >>>>>> Note(2): We might consider the second set of 7 bits to be a single > >>>>>> code space, > >>>>>> rather than use a 2+5 bit partitioning. That gives us a bit more > >>>>>> flexibility > >>>>>> and avoids meaningless combinations like public reset + 0-RTT. > >>>>>> > >>>>>> The remainder of the packet layout is the same regardless of type, > the > >>>>>> difference > >>>>>> being what rules for how to fill the values out and their semantics. > >>>>>> > >>>>>> A client packet then contains: > >>>>>> * Octets 4-11: connection ID (initially all zeroes/random) > >>>>>> * Octets 12-15: version > >>>>>> * Octets 16-19: packet number (low 4 octets, starts at a random > 32-bit > >>>>>> value) > >>>>>> * Octets 20+: payload > >>>>>> > >>>>>> Note: I'm not sure whether the client should pack the connection ID > >>>>>> with random > >>>>>> values. They would have no semantic value, though they might serve > to > >>>>>> provide > >>>>>> proof that the server received the packet if we require echoing, see > >>>>>> below. > >>>>>> > >>>>>> > >>>>>> A server packet contains a connection ID: > >>>>>> * Octets 4-11: connection ID (server-selected value) > >>>>>> * Octets 12-15: version (echoed) > >>>>>> * Octets 16-19: packet number (low 4 octets, random 32-bit initial > >>>>>> value) > >>>>>> * Octets 20+: payload > >>>>>> > >>>>>> A version negotiation packet contains: > >>>>>> * Octets 4-11: connection ID (echoed) > >>>>>> * Octets 12-15: version received (echoed) > >>>>>> * Octets 16-19: packet number (echoed) > >>>>>> * Octets 20+: payload = version list > >>>>> > >>>>> > >>>>> In order for the server to echo back the packet number, the server > >>>>> obviously needs to be able parse the packet number. But if the packet > >>>>> contains a version that the server does not support, it may well be > the case > >>>>> that the packet number layout may be different in the new version. > So I'm > >>>>> not sure it's possible to echo back the packet number. > >>>>>> > >>>>>> A public reset packet contains: > >>>>>> * Octets 4-11: connection ID (echoed) > >>>>>> * Octets 12-15: version (echoed) > >>>>>> * Octets 16-19: rejected packet number (echoed) > >>>>>> * Octets 20+: payload = authentication data > >>>>> > >>>>> > >>>>> Public reset packets are commonly sent when a server receives a > packet > >>>>> for a connection it does not have state for. (For example, a server > restart > >>>>> or a routing hiccup). In this case, the server is responding to a > packet > >>>>> with an unknown version and consequently and unknown packet number. > So I'm > >>>>> not sure it's possible to echo back the packet number. > >>>>>> > >>>>>> Echoing details from the packet in both version negotiation and > >>>>>> provides return > >>>>>> routeability on version negotiation (#244), while maintaining a > >>>>>> consistent > >>>>>> header shape for all packets. > >>>>>> > >>>>>> These long-form packets are used for anything that doesn't have > 1-RTT > >>>>>> packet > >>>>>> protection and prior to the completion of version negotiation. Once > >>>>>> both > >>>>>> conditions are met, switch to sending short-form packets. I haven't > >>>>>> defined any > >>>>>> 5/7-bit code for protected long-form packets, but that's easy to do > if > >>>>>> we need > >>>>>> to provide for them (see below for more on this). > >>>>>> > >>>>>> > >>>>>> ## Extension headers > >>>>>> > >>>>>> An 8-bit space (like IPv6) carries an identifier for the protocol > >>>>>> extension. > >>>>>> > >>>>>> Each header extension takes the form: > >>>>>> * Octet 1: next identifier > >>>>>> * Octet 2: length > >>>>>> > >>>>>> Since only the lower 5 (or 7) bits of this space is accessible from > >>>>>> the outset, > >>>>>> 0x00 is reserved for a null extension header, allowing the full > space > >>>>>> to be > >>>>>> unlocked. 0x?a can be used for greasing. > >>>>>> > >>>>>> I haven't talked to IP-layer people about whether they consider the > >>>>>> IPv6 scheme > >>>>>> this is based on to be successful. Either way, this should at least > >>>>>> have plenty > >>>>>> of hardware support. > >>>>>> > >>>>>> FWIW, I'm not sure that we need the complexity that this adds. It's > >>>>>> not clear > >>>>>> that there is a motivating use case. However, on balance it's > >>>>>> probably worth > >>>>>> putting something in for the moment. If it turns out that we don't > >>>>>> use it and > >>>>>> can't find even a potential use case, then removing it is simple > >>>>>> enough. > >>>>>> > >>>>>> That said, this form could be used to pack a TLS Finished into 1-RTT > >>>>>> packets if > >>>>>> we define a 5- or 7-bit code for "small bit of handshake, followed > by > >>>>>> more", > >>>>>> after which we can include a 1-RTT payload. > >>>>>> > >>>>>> > >>>>>> # Short Header > >>>>>> > >>>>>> ``` > >>>>>> 0 1 2 3 > >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> |S|K| Packet Number (30) | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> | | > >>>>>> + Connection ID + > >>>>>> | | > >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > >>>>>> ``` > >>>>>> > >>>>>> The short form header is defined to be specific to a version. > >>>>>> Anything > >>>>>> can change between protocol versions. > >>>>>> > >>>>>> A short packet header - in this version - reserves two bits from the > >>>>>> first > >>>>>> octet: > >>>>>> * SHORT_HEADER bit 7 (0x80) = 1, > >>>>>> * KEY_PHASE bit 6 (0x40) = 0 initially > >>>>>> > >>>>>> The remainder of the first four octets contain the packet number. > 30 > >>>>>> bits > >>>>>> should be plenty. If a need is found for more flags, those can > steal > >>>>>> upper > >>>>>> bits from the packet number. (Frankly, I suspect that 14 bits might > >>>>>> be > >>>>>> enough, but Ian was a little leery of that when I suggested it, and > >>>>>> this > >>>>>> keeps the connection ID in the same place in every packet.) > >>>>>> > >>>>>> The connection ID follows on the next 8 octets. > >>>>>> > >>>>>> If we need more bits, then we can steal them from the packet number. > >>>>>> > >>>>> > >>>> > >>> > >> > >> > > > --001a114257320ed0a905485917b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Feb 9, 2017 at 9:40 PM, Martin Thomson <martin.thomson@gmai= l.com> wrote:
Hi Jana,

To address your concerns:

Connection ID removal:
I believe that ekr addressed your concern about the connection ID
removal, so I'm surprised that you bring it up again.=C2=A0 Since we haven't really discussed it thus far, I don't know how important th= is
feature is.=C2=A0 I believe that it means making a choice about whether you=
think connection migration is important or not.=C2=A0 Whether it requires an explicit per-packet signal is debatable; in developing the
proposal, my assumption was that negotiating connection ID away would
be good enough.

Packet number size:
There's a trade-off here.=C2=A0 One of the features of my proposal is t= hat
the connection ID remains in the same place for both short- and
long-form.=C2=A0 I agree that 30 bits is far more than we need, but the
bits were just sitting there doing nothing otherwise.

Also, I don't feel much urgency behind byte-level optimizations for
small BDP when they come at the expense of other things.=C2=A0 The trends are all toward increases in that number.

Extensibility:
ekr explained the rationale here, it's an escape valve.=C2=A0 I too wou= ld
dearly like to remove the feature.=C2=A0 Given that I can't think of a = use
case, I hope that time will come soon.


All the use cases I can think of for e= xtensibility would be on short packets, so if we're going to do this, I= think it should be available there as well.=C2=A0 Also, the last time I re= member talking about an extensible UDP header, it was at the PLUS BoF, wher= e there were quite a few objections, notably on privacy grounds.
=
I don't understand ekr's rationale.=C2=A0 We'll = already be doing negotiation as part of the QUIC handshake in TLS, so I fee= l like that combined with version negotiation provide a pretty substantial = escape valve.=C2=A0 These extensions seem only valuable to communicate to o= r from middleboxes or if we absolutely have to add something to 0RTT packet= s.=C2=A0
=C2=A0
It seems like your counter-proposal just reiterates the current design
with some minor adjustments.=C2=A0 I just don't think that is sufficien= t to
address the concerns that people have raised about the excessive
number of variations in packet layout.=C2=A0 Adding a magic field in the way you propose only compounds that problem.


=C2=A0
The reason for needing a proposal was that it was clear that we needed
a holistic approach to designing the header.=C2=A0 There were just too many=
different, interacting issues.=C2=A0 My proposal addresses many of those at=
once with a simple change.=C2=A0 From a skim through the list: #40, #56, #67, #119, #133, #135, #170, #185, #193, and #244 all go away.=C2=A0 It
also goes some way to address #147 and #205.


After reading through them, I don't believe #40, #56, #67, #119, #133,= #135, #170, #185, #193, and #244 all go away with this proposal, since thi= s proposal really is about framing. Some were tentatively resolved at the i= nterim or are in the process of being resolved by proper documentation(than= ks for your #67 PR, BTW).=C2=A0 Additionally, this has implications on othe= r issues, such as #203, #269 and #279, and I opened #292 and #293 to discus= s whether a fixed location for connection id and 4 byte alignment are requi= rements.

On the other hand, if we had clear direction on most of the non-editoria= l issues listed(except #40, which is really only a question of framing), we= 'd be in a better position to fix up the framing with a clear set of go= als.

On 10 February 2017 at 12:07, Jana Iyengar <jri@google.com> wrote:
> Hi Eric,
>
> Responses inline.
>
>>>
>>> I like that you've separated the early handshake packet fo= rmat from the
>>> "common case" format -- there may be value in having= that separation when
>>> thinking about overhead and header formats (earlier versions o= f the
>>> transport draft talked about Regular and Special packets, whic= h may be worth
>>> reconsidering.) That said, I think this proposal conflates thr= ee things:
>>> (i) it attempts to compress the header, in some cases
>>
>>
>> I thought there was agreement that making the header smaller was g= ood. Not
>> sure how we would have consensus for that in the abstract, so we p= robably
>> just need to debate whether or not this particular form of compres= sion is
>> good.
>
>
> Agreed in principle, but as Ryan points out, this makes the connection= ID
> show up all the time, which increases header size.
>
>>>
>>> (ii) it changes the header in ways which have been suggested b= ut without
>>> consensus (connection ID, magic field)
>>
>>
>> Hmm.... I thought we did have consensus for the magic field in the=
>> interim. Of course that needs confirmation on the mailing list, bu= t this
>> seems like a good venue for that.
>> I don't think we need concern ourselves with the connection ID= , because
>> this proposal neatly accommodates removing the connection ID field= , either
>> by having the server
>> tell the client it can (with no indicator) or if we like, stealing= a bit
>> from the packet number to say ("here is a conn id"). The= re doesn't seem to
>> be a percentage in removing conn id from the special packets, so w= e don't
>> need to address that.
>
>
> Yes, you're right. We did have consensus on encoding version neg p= ackets to
> include a ver + magic for directionality, but as you note, this hasn&#= 39;t been
> confirmed on the list, and we should do that. This is a simple change = that
> addresses the DoS issue by adding directionality (Issue #135), and tha= t
> change would be relatively small.
>
>>> (iii) it adds extensibility in ways that are not yet justified= .
>>
>>
>> I think I do agree with you here, ultimately, but I'd like to = leave it in
>> for now. My reasoning here is that you often find that you have a = bunch of
>> small things that you want some flexibility for but that aren'= t enough to
>> add a whole new extension point, so you just get death of a thousa= nd cuts as
>> you try to work around them. Contrariwise, if we have this extensi= on point
>> available, we can see if it gets used and pull it out before pubre= q.
>
>
> I am sympathetic to your point about death by a thousand cuts, but I d= on't
> think we're there yet. I'm still of the opinion that this intr= oduces
> unwarranted arbitrary extensibility in the header, since I don't s= ee the
> warranting use cases.
>
>>>
>>> I think the proposal is useful in that it shows how the header= might look
>>> in a different world. But let's get consensus on what'= s reasonable to do
>>> before figuring out how to do it. Specifically, as Ian notes, = #269 and #279
>>> are existing issues, and we need to discuss things like the ma= gic header
>>> field before adding them in (is there an issue for this?)
>>>
>>> I propose parking this for now.
>>
>>
>> I'd rather we hash out these issues and decide on this PR or s= ome revision
>> one way or the other. There's a lot of other stuff that's = kind of piled up
>> behind the packet header
>
>
> In that case, I'd suggest that we separate the version + magic fla= g in one
> PR to address the DoS issue. As discussed at the interim, this would s= imply
> mean that we have an interpretation of the version bit that includes t= he
> magic part.
>
>
> For the long header (inlining my comments below:)
> * Octet 0: Special
>=C2=A0 =C2=A0* Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here)
>=C2=A0 =C2=A0* Bit 6-5: Type
>=C2=A0 =C2=A0 =C2=A0* 11 - client packet
>=C2=A0 =C2=A0 =C2=A0* 10 - server packet
>=C2=A0 =C2=A0 =C2=A0* 01 - public reset
>=C2=A0 =C2=A0 =C2=A0* 00 - version negotiation
>
> Why do you need two codepoints for regular packets? The magic header g= ives
> directionality on initial packets, and the connection keys on subseque= nt
> rounds, right? You need only three codepoints in all here.
>
>=C2=A0 =C2=A0* Bits 4-0: Next protocol
>=C2=A0 =C2=A0 =C2=A0* 0b10001 indicates that it is QUIC handshake data<= br> >=C2=A0 =C2=A0 =C2=A0* 0b01111 indicates that it is QUIC 0-RTT data
>
> Why do we need these?
>
>=C2=A0 =C2=A0 =C2=A0* other values mean that the payload following the = packet number
> contains
>=C2=A0 =C2=A0 =C2=A0 an IPv6-style extension header
>
> Why do we need this?
>
> * Octets 1-3: Magic (this can be short given that we will have a MAC a= s
> well)
>=C2=A0 =C2=A0* 0x756963 for a client,
>=C2=A0 =C2=A0* 0x554943 for a server
>
> SGTM, based on consensus.
>
>
> The proposed short header removes the following bits that I would not = want
> to lose:
> - packet number size. The packet number size currently changes as our<= br> > estimation of how many packets fit in the cwnd changes (loosely speaki= ng)
> and is dynamic through the connection.
> - Connection ID flag, and makes the Connection ID required in all pack= ets.
> As previously pointed out, this flexibility is quite useful and reduce= s
> header size quite a bit in the direction where it commonly matters mos= t
> (server->client), but it can be used by any endpoint as long as it = does not
> need Connection ID for routing on incoming packets.
>
>
> Based on my take on the long and short headers above:
>
> If we remove the extensibility points, eliminate server/client
> directionality in the header bits, and retain the fields I noted above= , I'm
> not sure that there's much to be had by separating the long and sh= ort
> headers. The resulting header looks as follows on all packets:
> - TT: Packet type
>=C2=A0 =C2=A0 =C2=A0* 00 - version negotiation packet
>=C2=A0 =C2=A0 =C2=A0* 01 - public reset
>=C2=A0 =C2=A0 =C2=A0* 1X - regular packet
> - Key Phase
> - Connection ID
> - Packet Number Size (2 bits)
>
> The only difference from the spec is the TT bits, which is equivalent = to the
> explicit V and PR bits in the spec right now, since with V and PR bits= :
> 10 - version negotiation packet
> 01 - public reset packet (we could make this X1, to make it cover the = unused
> codepoint.)
> 00 - regular packet
>
>
> I would suggest a PR that only adds a magic field for directionality, = and
> leaves the rest of it out; perhaps in a separate issue + PR to discuss= why
> these may be useful.
> - jana
>
>
>
>
>> -Ekr
>>
>>
>>>
>>> - jana
>>>
>>>
>>> On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett <ianswett@google.com> wrote= :
>>>>
>>>> Thanks for taking a crack at this.=C2=A0 I have a few high= -level comments.
>>>>
>>>> 1) This implicitly requires the connection ID to always be= stated, which
>>>> as Ryan said, inflates the packet header substantially fro= m the status quo
>>>> of what we send server to client, which I'm not a fan = of from a practical
>>>> perspective.=C2=A0 Equally importantly, I think we need to= resolve the
>>>> conversation about privacy and connection IDs before we kn= ow whether we
>>>> should always be sending the connection ID.
>>>> 2) I believe we may want to add packet number echo bit(#26= 9) and
>>>> possibly a loss detection bit(#279) on every packet.=C2=A0= I think it makes sense
>>>> to resolve these before redesigning the packet header, sin= ce I believe it
>>>> would substantially change your current design?
>>>> 3) This proposes header extensions, which seems orthogonal= to the header
>>>> redesign.=C2=A0 I'm not a fan of header extensions at = the moment, but I think it
>>>> deserves a separate conversation.
>>>>
>>>> So I would be biased towards getting some clarity on the c= onnection id
>>>> privacy question as well as the #269 and #279 before attem= pting a holistic
>>>> redesign of the packet header.
>>>>
>>>> On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton <rch@google.com> wrote:<= br> >>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson
>>>>> <martin.thomson@gmail.com> wrote:
>>>>>>
>>>>>> As I go through the issues list, it appears that a= lot of issues on
>>>>>> which we have consensus would benefit from a resol= ution to the header
>>>>>> format issue.=C2=A0 To that end, I have sketched o= ut a proposal that I
>>>>>> think meets the various constraints we have.
>>>>>>
>>>>>> I want to discuss this here before we embark on wh= at could be a fairly
>>>>>> disruptive set of changes to the drafts.
>>>>>>
>>>>>> (A copy of the following text can be found at
>>>>>> https= ://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8=
>>>>>> )
>>>>>> --
>>>>>>
>>>>>> There are two forms of QUIC common header: long an= d short.=C2=A0 Long form
>>>>>> packets
>>>>>> are used for the initial exchange - until both 1-R= TT packet protection
>>>>>> can be
>>>>>> started AND version negotiation is complete.=C2=A0= Short form packets carry
>>>>>> the
>>>>>> bulk of the data.
>>>>>>
>>>>>> This removes a lot of the flexibility that was the= source of most of
>>>>>> the
>>>>>> objections to the current format.=C2=A0 Fields are= aligned on four octet
>>>>>> boundaries.
>>>>>> All long-form header variations have the exact sam= e form.=C2=A0 The
>>>>>> connection ID is
>>>>>> in the same place in both short and long form.=C2= =A0 The long form clearly
>>>>>> identifies the role of the sender in the first oct= et and it identifies
>>>>>> the
>>>>>> packet as a QUIC packet.
>>>>>>
>>>>>> The cost is that it makes occasional packets a lit= tle larger (the long
>>>>>> header
>>>>>> is 20 octets, whereas the existing form uses betwe= en 14 and 19 octets
>>>>>> for initial
>>>>>> handshake packets).=C2=A0 This is an acceptable tr= ade-off given that only a
>>>>>> few of
>>>>>> these packets are ever exchanged on a connection.<= br> >>>>>>
>>>>>> It makes most packets (the short header) 12 octets= where it is
>>>>>> possible to
>>>>>> have 10 octet packets.
>>>>>
>>>>>
>>>>> In currently deployed QUIC, 1-RTT packets from the ser= ver to the client
>>>>> do not have connection ID present. (This is because an= endpoint tells the
>>>>> peer how many connection ID bits it needs the peer to = send. In the case of
>>>>> clients, since they only have 1 connection on a given = socket, the connection
>>>>> ID is not needed.). These packets also typically have = a 1 or 2 byte packet
>>>>> number. So the header ends up being:=C2=A0 1 byte publ= ic flags + 1 or 2 byte
>>>>> packet number for a total of 2-3 bytes. This new forma= t seems to be much
>>>>> larger.
>>>>>
>>>>>>
>>>>>> However, a 10 octet packet header assumes an 8 bit=
>>>>>> packet number, this is 30.
>>>>>
>>>>>
>>>>> I don't think I understand how to construct a 10 o= ctet packet. Can you
>>>>> elaborate?
>>>>>
>>>>>>
>>>>>> # Long Header
>>>>>>
>>>>>> ```
>>>>>>=C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A03
>>>>>>=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |S|Typ|=C2=A0 Next=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Magic "uic"/"UIC"=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet Number=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Header Extensions]=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=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...
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> ```
>>>>>>
>>>>>> The first four octets:
>>>>>> * Octet 0: Special
>>>>>>=C2=A0 =C2=A0* Bit 7 (i.e., 0x80): SHORT_HEADER (se= t to 0 here)
>>>>>>=C2=A0 =C2=A0* Bit 6-5: Type
>>>>>>=C2=A0 =C2=A0 =C2=A0* 11 - client packet
>>>>>>=C2=A0 =C2=A0 =C2=A0* 10 - server packet
>>>>>>=C2=A0 =C2=A0 =C2=A0* 01 - public reset
>>>>>>=C2=A0 =C2=A0 =C2=A0* 00 - version negotiation
>>>>>>=C2=A0 =C2=A0* Bits 4-0: Next protocol
>>>>>>=C2=A0 =C2=A0 =C2=A0* 0b10001 indicates that it is = QUIC handshake data
>>>>>>=C2=A0 =C2=A0 =C2=A0* 0b01111 indicates that it is = QUIC 0-RTT data
>>>>>>=C2=A0 =C2=A0 =C2=A0* other values mean that the pa= yload following the packet number
>>>>>> contains
>>>>>>=C2=A0 =C2=A0 =C2=A0 an IPv6-style extension header=
>>>>>> * Octets 1-3: Magic (this can be short given that = we will have a MAC
>>>>>> as well)
>>>>>>=C2=A0 =C2=A0* 0x756963 for a client,
>>>>>>=C2=A0 =C2=A0* 0x554943 for a server
>>>>>>
>>>>>> Note: A client packet starts with "quic"= , server starts with "QUIC",
>>>>>> 0-RTT starts
>>>>>> with "ouic".
>>>>>>
>>>>>> Note(2): We might consider the second set of 7 bit= s to be a single
>>>>>> code space,
>>>>>> rather than use a 2+5 bit partitioning.=C2=A0 That= gives us a bit more
>>>>>> flexibility
>>>>>> and avoids meaningless combinations like public re= set + 0-RTT.
>>>>>>
>>>>>> The remainder of the packet layout is the same reg= ardless of type, the
>>>>>> difference
>>>>>> being what rules for how to fill the values out an= d their semantics.
>>>>>>
>>>>>> A client packet then contains:
>>>>>> * Octets 4-11: connection ID (initially all zeroes= /random)
>>>>>> * Octets 12-15: version
>>>>>> * Octets 16-19: packet number (low 4 octets, start= s at a random 32-bit
>>>>>> value)
>>>>>> * Octets 20+: payload
>>>>>>
>>>>>> Note: I'm not sure whether the client should p= ack the connection ID
>>>>>> with random
>>>>>> values.=C2=A0 They would have no semantic value, t= hough they might serve to
>>>>>> provide
>>>>>> proof that the server received the packet if we re= quire echoing, see
>>>>>> below.
>>>>>>
>>>>>>
>>>>>> A server packet contains a connection ID:
>>>>>> * Octets 4-11: connection ID (server-selected valu= e)
>>>>>> * Octets 12-15: version (echoed)
>>>>>> * Octets 16-19: packet number (low 4 octets, rando= m 32-bit initial
>>>>>> value)
>>>>>> * Octets 20+: payload
>>>>>>
>>>>>> A version negotiation packet contains:
>>>>>> * Octets 4-11: connection ID (echoed)
>>>>>> * Octets 12-15: version received (echoed)
>>>>>> * Octets 16-19: packet number (echoed)
>>>>>> * Octets 20+: payload =3D version list
>>>>>
>>>>>
>>>>> In order for the server to echo back the packet number= , the server
>>>>> obviously needs to be able parse the packet number. Bu= t if the packet
>>>>> contains a version that the server does not support, i= t may well be the case
>>>>> that the packet number layout may be different in the = new version. So I'm
>>>>> not sure it's possible to echo back the packet num= ber.
>>>>>>
>>>>>> A public reset packet contains:
>>>>>> * Octets 4-11: connection ID (echoed)
>>>>>> * Octets 12-15: version (echoed)
>>>>>> * Octets 16-19: rejected packet number (echoed) >>>>>> * Octets 20+: payload =3D authentication data
>>>>>
>>>>>
>>>>> Public reset packets are commonly sent when a server r= eceives a packet
>>>>> for a connection it does not have state for. (For exam= ple, a server restart
>>>>> or a routing hiccup). In this case, the server is resp= onding to a packet
>>>>> with an unknown version and consequently and unknown p= acket number. So I'm
>>>>> not sure it's possible to echo back the packet num= ber.
>>>>>>
>>>>>> Echoing details from the packet in both version ne= gotiation and
>>>>>> provides return
>>>>>> routeability on version negotiation (#244), while = maintaining a
>>>>>> consistent
>>>>>> header shape for all packets.
>>>>>>
>>>>>> These long-form packets are used for anything that= doesn't have 1-RTT
>>>>>> packet
>>>>>> protection and prior to the completion of version = negotiation.=C2=A0 Once
>>>>>> both
>>>>>> conditions are met, switch to sending short-form p= ackets.=C2=A0 I haven't
>>>>>> defined any
>>>>>> 5/7-bit code for protected long-form packets, but = that's easy to do if
>>>>>> we need
>>>>>> to provide for them (see below for more on this).<= br> >>>>>>
>>>>>>
>>>>>> ## Extension headers
>>>>>>
>>>>>> An 8-bit space (like IPv6) carries an identifier f= or the protocol
>>>>>> extension.
>>>>>>
>>>>>> Each header extension takes the form:
>>>>>> * Octet 1: next identifier
>>>>>> * Octet 2: length
>>>>>>
>>>>>> Since only the lower 5 (or 7) bits of this space i= s accessible from
>>>>>> the outset,
>>>>>> 0x00 is reserved for a null extension header, allo= wing the full space
>>>>>> to be
>>>>>> unlocked.=C2=A0 0x?a can be used for greasing.
>>>>>>
>>>>>> I haven't talked to IP-layer people about whet= her they consider the
>>>>>> IPv6 scheme
>>>>>> this is based on to be successful.=C2=A0 Either wa= y, this should at least
>>>>>> have plenty
>>>>>> of hardware support.
>>>>>>
>>>>>> FWIW, I'm not sure that we need the complexity= that this adds.=C2=A0 It's
>>>>>> not clear
>>>>>> that there is a motivating use case.=C2=A0 =C2=A0H= owever, on balance it's
>>>>>> probably worth
>>>>>> putting something in for the moment.=C2=A0 If it t= urns out that we don't
>>>>>> use it and
>>>>>> can't find even a potential use case, then rem= oving it is simple
>>>>>> enough.
>>>>>>
>>>>>> That said, this form could be used to pack a TLS F= inished into 1-RTT
>>>>>> packets if
>>>>>> we define a 5- or 7-bit code for "small bit o= f handshake, followed by
>>>>>> more",
>>>>>> after which we can include a 1-RTT payload.
>>>>>>
>>>>>>
>>>>>> # Short Header
>>>>>>
>>>>>> ```
>>>>>>=C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A03
>>>>>>=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |S|K|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Packet Number (30)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> ```
>>>>>>
>>>>>> The short form header is defined to be specific to= a version.
>>>>>> Anything
>>>>>> can change between protocol versions.
>>>>>>
>>>>>> A short packet header - in this version - reserves= two bits from the
>>>>>> first
>>>>>> octet:
>>>>>> * SHORT_HEADER bit 7 (0x80) =3D 1,
>>>>>> * KEY_PHASE bit 6 (0x40) =3D 0 initially
>>>>>>
>>>>>> The remainder of the first four octets contain the= packet number.=C2=A0 30
>>>>>> bits
>>>>>> should be plenty.=C2=A0 If a need is found for mor= e flags, those can steal
>>>>>> upper
>>>>>> bits from the packet number.=C2=A0 (Frankly, I sus= pect that 14 bits might
>>>>>> be
>>>>>> enough, but Ian was a little leery of that when I = suggested it, and
>>>>>> this
>>>>>> keeps the connection ID in the same place in every= packet.)
>>>>>>
>>>>>> The connection ID follows on the next 8 octets. >>>>>>
>>>>>> If we need more bits, then we can steal them from = the packet number.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>

--001a114257320ed0a905485917b0-- From nobody Sun Feb 12 11:19:20 2017 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 394B6129AAC for ; Sun, 12 Feb 2017 11:19:18 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 CXDv6NeviLIJ for ; Sun, 12 Feb 2017 11:19:14 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::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 0C1EB129A3A for ; Sun, 12 Feb 2017 11:19:14 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id t8so50618588vke.3 for ; Sun, 12 Feb 2017 11:19:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YJJzrlKNIcbFVOuwOx1c28SLsBtJbJASlphRq41B5ec=; b=BXFPXkR6TprCivDgh6UlkZ9bsEVIWp7DCIeRMQ4wcuAdbY4CCAzWf9o0F69id6yqtD FnNjNUpkTIwQVTA46NF4Z5KQOs7hg5KpmglZkTWv0nOSOmnlo/siguoQHe2zZqCfvVV/ Qf0a85LCyy5ov6muhyvQjL6NlYIivd57KuQSv8+0dqFx5MRtsDI4c3z/z8RgzRqzxkYs IAlq3DT98Q+4QB17f/vG5tNVDFduNTMaLyoGF2c0SJZcVWzaHK+Z2WWNIQXl60YlnaBS pk4R97/wA85xlqMDDK7AHi1dAu2tH65PrE2d+IbgE0gNEbysaQj7T5aUw/bhmW2SHOua Hj3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YJJzrlKNIcbFVOuwOx1c28SLsBtJbJASlphRq41B5ec=; b=nePf0+doRG27hiO6qtBY7/PkoX/uhlprp95ZflrKs5PUBFrQLom8LMrEwf8Yrz/iMq 0OhvmnSqfr53hZ6/PXa35RKTbSZk9j/Yj0MX9ucUW6UrIsxG2xCqYWpKODNXJUlfEYsK qEqFPnge62xqaGqzT+cJG6SpkiVA7/iY04TXsOvm0VLiGx8ya2m4OqBPHEOsttUXHtSU Cl5ZRrxtTGoIuoI04JlOX5kmxzf3pKDhX7o0rw5gdDCyLcERIuq7MP7FsjS0uLv6X+ML U1RXQQ2WcmrnJ62DVSbOtohifLddcPqSqNbDEiIsH/UM+OmzRF1FdQummggFBwAS2dWD JYzQ== X-Gm-Message-State: AMke39kCxtp5aId3ECYXuzC2LZ4jAw1BBBqdzYsb7tQtCEhHIg1sLMcy0WhwFS8DFlBxyN277/UK3s+2aDrux6XL X-Received: by 10.31.238.6 with SMTP id m6mr8192474vkh.28.1486927152534; Sun, 12 Feb 2017 11:19:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Sun, 12 Feb 2017 11:19:11 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Sun, 12 Feb 2017 11:19:11 -0800 Message-ID: Subject: Re: Proposal for QUIC header To: Ian Swett Content-Type: multipart/alternative; boundary=94eb2c149714bc1b7e05485a3417 Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2017 19:19:18 -0000 --94eb2c149714bc1b7e05485a3417 Content-Type: text/plain; charset=UTF-8 Responding to Ian and Martin together. A couple of high-order points: (i) There may be value in the separation of long and short headers, and I'd like to keep that general idea around, and come back to this later. That said, as Ian points out, there are things that aren't resolved yet, and redoing the header at this time seems like an early optimization. I think we should address the things that we have consensus for (adding a magic header for directionality). We had consensus on attempting to simplify the headers, which we can do, but I'd be wary of doing it at a cost to common use cases. (ii) Let's not add arbitrary extensibility to the header. We have versioning, we have transport params, and now this adds a third extensibility option which seems unnecessary. More inline: > Extensibility: >> ekr explained the rationale here, it's an escape valve. I too would >> dearly like to remove the feature. Given that I can't think of a use >> case, I hope that time will come soon. >> >> > All the use cases I can think of for extensibility would be on short > packets, so if we're going to do this, I think it should be available there > as well. Also, the last time I remember talking about an extensible UDP > header, it was at the PLUS BoF, where there were quite a few objections, > notably on privacy grounds. > > I don't understand ekr's rationale. We'll already be doing negotiation as > part of the QUIC handshake in TLS, so I feel like that combined with > version negotiation provide a pretty substantial escape valve. These > extensions seem only valuable to communicate to or from middleboxes or if > we absolutely have to add something to 0RTT packets. > I agree. If we have a need for more header fields, let's revisit the header itself. Providing arbitrary extensibility hoping that it doesn't get used is a bad strategy. > It seems like your counter-proposal just reiterates the current design >> with some minor adjustments. I just don't think that is sufficient to >> address the concerns that people have raised about the excessive >> number of variations in packet layout. Adding a magic field in the >> way you propose only compounds that problem. >> > I would like to come back to this point -- yes there were some concerns raised about the variations in packet layout. I don't think there's been a convincing case that this is a major issue for implementations. Where exactly is this variability in headers a problem? I'd like to hear more about this issue before we embark on a complete redesign. Specifically, implementation experience (ours at least, others with experience should chime in) suggests that this has not been a concern for implementation at least. The reason for needing a proposal was that it was clear that we needed >> a holistic approach to designing the header. There were just too many >> different, interacting issues. My proposal addresses many of those at >> once with a simple change. From a skim through the list: #40, #56, >> #67, #119, #133, #135, #170, #185, #193, and #244 all go away. It >> also goes some way to address #147 and #205. > > > After reading through them, I don't believe #40, #56, #67, #119, #133, > #135, #170, #185, #193, and #244 all go away with this proposal, since this > proposal really is about framing. Some were tentatively resolved at the > interim or are in the process of being resolved by proper > documentation(thanks for your #67 PR, BTW). Additionally, this has > implications on other issues, such as #203, #269 and #279, and I opened > #292 and #293 to discuss whether a fixed location for connection id and 4 > byte alignment are requirements. > > On the other hand, if we had clear direction on most of the non-editorial > issues listed(except #40, which is really only a question of framing), we'd > be in a better position to fix up the framing with a clear set of goals. > I spent time going through all the issues as well. These issues are either addressed by using the magic field for directionality, by using server-generated connection ID, or by editorial work, all of which are independent of the framing changes. These changes can be made simply in the current format. The newer issues should be addressed, and we can always come back to this framing change later, if it's still warranted. - jana > On 10 February 2017 at 12:07, Jana Iyengar wrote: >> > Hi Eric, >> > >> > Responses inline. >> > >> >>> >> >>> I like that you've separated the early handshake packet format from >> the >> >>> "common case" format -- there may be value in having that separation >> when >> >>> thinking about overhead and header formats (earlier versions of the >> >>> transport draft talked about Regular and Special packets, which may >> be worth >> >>> reconsidering.) That said, I think this proposal conflates three >> things: >> >>> (i) it attempts to compress the header, in some cases >> >> >> >> >> >> I thought there was agreement that making the header smaller was good. >> Not >> >> sure how we would have consensus for that in the abstract, so we >> probably >> >> just need to debate whether or not this particular form of compression >> is >> >> good. >> > >> > >> > Agreed in principle, but as Ryan points out, this makes the connection >> ID >> > show up all the time, which increases header size. >> > >> >>> >> >>> (ii) it changes the header in ways which have been suggested but >> without >> >>> consensus (connection ID, magic field) >> >> >> >> >> >> Hmm.... I thought we did have consensus for the magic field in the >> >> interim. Of course that needs confirmation on the mailing list, but >> this >> >> seems like a good venue for that. >> >> I don't think we need concern ourselves with the connection ID, because >> >> this proposal neatly accommodates removing the connection ID field, >> either >> >> by having the server >> >> tell the client it can (with no indicator) or if we like, stealing a >> bit >> >> from the packet number to say ("here is a conn id"). There doesn't >> seem to >> >> be a percentage in removing conn id from the special packets, so we >> don't >> >> need to address that. >> > >> > >> > Yes, you're right. We did have consensus on encoding version neg >> packets to >> > include a ver + magic for directionality, but as you note, this hasn't >> been >> > confirmed on the list, and we should do that. This is a simple change >> that >> > addresses the DoS issue by adding directionality (Issue #135), and that >> > change would be relatively small. >> > >> >>> (iii) it adds extensibility in ways that are not yet justified. >> >> >> >> >> >> I think I do agree with you here, ultimately, but I'd like to leave it >> in >> >> for now. My reasoning here is that you often find that you have a >> bunch of >> >> small things that you want some flexibility for but that aren't enough >> to >> >> add a whole new extension point, so you just get death of a thousand >> cuts as >> >> you try to work around them. Contrariwise, if we have this extension >> point >> >> available, we can see if it gets used and pull it out before pubreq. >> > >> > >> > I am sympathetic to your point about death by a thousand cuts, but I >> don't >> > think we're there yet. I'm still of the opinion that this introduces >> > unwarranted arbitrary extensibility in the header, since I don't see the >> > warranting use cases. >> > >> >>> >> >>> I think the proposal is useful in that it shows how the header might >> look >> >>> in a different world. But let's get consensus on what's reasonable to >> do >> >>> before figuring out how to do it. Specifically, as Ian notes, #269 >> and #279 >> >>> are existing issues, and we need to discuss things like the magic >> header >> >>> field before adding them in (is there an issue for this?) >> >>> >> >>> I propose parking this for now. >> >> >> >> >> >> I'd rather we hash out these issues and decide on this PR or some >> revision >> >> one way or the other. There's a lot of other stuff that's kind of >> piled up >> >> behind the packet header >> > >> > >> > In that case, I'd suggest that we separate the version + magic flag in >> one >> > PR to address the DoS issue. As discussed at the interim, this would >> simply >> > mean that we have an interpretation of the version bit that includes the >> > magic part. >> > >> > >> > For the long header (inlining my comments below:) >> > * Octet 0: Special >> > * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) >> > * Bit 6-5: Type >> > * 11 - client packet >> > * 10 - server packet >> > * 01 - public reset >> > * 00 - version negotiation >> > >> > Why do you need two codepoints for regular packets? The magic header >> gives >> > directionality on initial packets, and the connection keys on subsequent >> > rounds, right? You need only three codepoints in all here. >> > >> > * Bits 4-0: Next protocol >> > * 0b10001 indicates that it is QUIC handshake data >> > * 0b01111 indicates that it is QUIC 0-RTT data >> > >> > Why do we need these? >> > >> > * other values mean that the payload following the packet number >> > contains >> > an IPv6-style extension header >> > >> > Why do we need this? >> > >> > * Octets 1-3: Magic (this can be short given that we will have a MAC as >> > well) >> > * 0x756963 for a client, >> > * 0x554943 for a server >> > >> > SGTM, based on consensus. >> > >> > >> > The proposed short header removes the following bits that I would not >> want >> > to lose: >> > - packet number size. The packet number size currently changes as our >> > estimation of how many packets fit in the cwnd changes (loosely >> speaking) >> > and is dynamic through the connection. >> > - Connection ID flag, and makes the Connection ID required in all >> packets. >> > As previously pointed out, this flexibility is quite useful and reduces >> > header size quite a bit in the direction where it commonly matters most >> > (server->client), but it can be used by any endpoint as long as it does >> not >> > need Connection ID for routing on incoming packets. >> > >> > >> > Based on my take on the long and short headers above: >> > >> > If we remove the extensibility points, eliminate server/client >> > directionality in the header bits, and retain the fields I noted above, >> I'm >> > not sure that there's much to be had by separating the long and short >> > headers. The resulting header looks as follows on all packets: >> > - TT: Packet type >> > * 00 - version negotiation packet >> > * 01 - public reset >> > * 1X - regular packet >> > - Key Phase >> > - Connection ID >> > - Packet Number Size (2 bits) >> > >> > The only difference from the spec is the TT bits, which is equivalent >> to the >> > explicit V and PR bits in the spec right now, since with V and PR bits: >> > 10 - version negotiation packet >> > 01 - public reset packet (we could make this X1, to make it cover the >> unused >> > codepoint.) >> > 00 - regular packet >> > >> > >> > I would suggest a PR that only adds a magic field for directionality, >> and >> > leaves the rest of it out; perhaps in a separate issue + PR to discuss >> why >> > these may be useful. >> > - jana >> > >> > >> > >> > >> >> -Ekr >> >> >> >> >> >>> >> >>> - jana >> >>> >> >>> >> >>> On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett >> wrote: >> >>>> >> >>>> Thanks for taking a crack at this. I have a few high-level comments. >> >>>> >> >>>> 1) This implicitly requires the connection ID to always be stated, >> which >> >>>> as Ryan said, inflates the packet header substantially from the >> status quo >> >>>> of what we send server to client, which I'm not a fan of from a >> practical >> >>>> perspective. Equally importantly, I think we need to resolve the >> >>>> conversation about privacy and connection IDs before we know whether >> we >> >>>> should always be sending the connection ID. >> >>>> 2) I believe we may want to add packet number echo bit(#269) and >> >>>> possibly a loss detection bit(#279) on every packet. I think it >> makes sense >> >>>> to resolve these before redesigning the packet header, since I >> believe it >> >>>> would substantially change your current design? >> >>>> 3) This proposes header extensions, which seems orthogonal to the >> header >> >>>> redesign. I'm not a fan of header extensions at the moment, but I >> think it >> >>>> deserves a separate conversation. >> >>>> >> >>>> So I would be biased towards getting some clarity on the connection >> id >> >>>> privacy question as well as the #269 and #279 before attempting a >> holistic >> >>>> redesign of the packet header. >> >>>> >> >>>> On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton >> wrote: >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson >> >>>>> wrote: >> >>>>>> >> >>>>>> As I go through the issues list, it appears that a lot of issues on >> >>>>>> which we have consensus would benefit from a resolution to the >> header >> >>>>>> format issue. To that end, I have sketched out a proposal that I >> >>>>>> think meets the various constraints we have. >> >>>>>> >> >>>>>> I want to discuss this here before we embark on what could be a >> fairly >> >>>>>> disruptive set of changes to the drafts. >> >>>>>> >> >>>>>> (A copy of the following text can be found at >> >>>>>> https://gist.github.com/martinthomson/744d04cbcec9be554f2f8e >> 7bae2715b8 >> >>>>>> ) >> >>>>>> -- >> >>>>>> >> >>>>>> There are two forms of QUIC common header: long and short. Long >> form >> >>>>>> packets >> >>>>>> are used for the initial exchange - until both 1-RTT packet >> protection >> >>>>>> can be >> >>>>>> started AND version negotiation is complete. Short form packets >> carry >> >>>>>> the >> >>>>>> bulk of the data. >> >>>>>> >> >>>>>> This removes a lot of the flexibility that was the source of most >> of >> >>>>>> the >> >>>>>> objections to the current format. Fields are aligned on four octet >> >>>>>> boundaries. >> >>>>>> All long-form header variations have the exact same form. The >> >>>>>> connection ID is >> >>>>>> in the same place in both short and long form. The long form >> clearly >> >>>>>> identifies the role of the sender in the first octet and it >> identifies >> >>>>>> the >> >>>>>> packet as a QUIC packet. >> >>>>>> >> >>>>>> The cost is that it makes occasional packets a little larger (the >> long >> >>>>>> header >> >>>>>> is 20 octets, whereas the existing form uses between 14 and 19 >> octets >> >>>>>> for initial >> >>>>>> handshake packets). This is an acceptable trade-off given that >> only a >> >>>>>> few of >> >>>>>> these packets are ever exchanged on a connection. >> >>>>>> >> >>>>>> It makes most packets (the short header) 12 octets where it is >> >>>>>> possible to >> >>>>>> have 10 octet packets. >> >>>>> >> >>>>> >> >>>>> In currently deployed QUIC, 1-RTT packets from the server to the >> client >> >>>>> do not have connection ID present. (This is because an endpoint >> tells the >> >>>>> peer how many connection ID bits it needs the peer to send. In the >> case of >> >>>>> clients, since they only have 1 connection on a given socket, the >> connection >> >>>>> ID is not needed.). These packets also typically have a 1 or 2 byte >> packet >> >>>>> number. So the header ends up being: 1 byte public flags + 1 or 2 >> byte >> >>>>> packet number for a total of 2-3 bytes. This new format seems to be >> much >> >>>>> larger. >> >>>>> >> >>>>>> >> >>>>>> However, a 10 octet packet header assumes an 8 bit >> >>>>>> packet number, this is 30. >> >>>>> >> >>>>> >> >>>>> I don't think I understand how to construct a 10 octet packet. Can >> you >> >>>>> elaborate? >> >>>>> >> >>>>>> >> >>>>>> # Long Header >> >>>>>> >> >>>>>> ``` >> >>>>>> 0 1 2 3 >> >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> |S|Typ| Next | Magic "uic"/"UIC" | >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> | | >> >>>>>> + Connection ID + >> >>>>>> | | >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> | Version | >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> | Packet Number | >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> | [Header Extensions] ... >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> | Payload ... >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> ``` >> >>>>>> >> >>>>>> The first four octets: >> >>>>>> * Octet 0: Special >> >>>>>> * Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here) >> >>>>>> * Bit 6-5: Type >> >>>>>> * 11 - client packet >> >>>>>> * 10 - server packet >> >>>>>> * 01 - public reset >> >>>>>> * 00 - version negotiation >> >>>>>> * Bits 4-0: Next protocol >> >>>>>> * 0b10001 indicates that it is QUIC handshake data >> >>>>>> * 0b01111 indicates that it is QUIC 0-RTT data >> >>>>>> * other values mean that the payload following the packet >> number >> >>>>>> contains >> >>>>>> an IPv6-style extension header >> >>>>>> * Octets 1-3: Magic (this can be short given that we will have a >> MAC >> >>>>>> as well) >> >>>>>> * 0x756963 for a client, >> >>>>>> * 0x554943 for a server >> >>>>>> >> >>>>>> Note: A client packet starts with "quic", server starts with >> "QUIC", >> >>>>>> 0-RTT starts >> >>>>>> with "ouic". >> >>>>>> >> >>>>>> Note(2): We might consider the second set of 7 bits to be a single >> >>>>>> code space, >> >>>>>> rather than use a 2+5 bit partitioning. That gives us a bit more >> >>>>>> flexibility >> >>>>>> and avoids meaningless combinations like public reset + 0-RTT. >> >>>>>> >> >>>>>> The remainder of the packet layout is the same regardless of type, >> the >> >>>>>> difference >> >>>>>> being what rules for how to fill the values out and their >> semantics. >> >>>>>> >> >>>>>> A client packet then contains: >> >>>>>> * Octets 4-11: connection ID (initially all zeroes/random) >> >>>>>> * Octets 12-15: version >> >>>>>> * Octets 16-19: packet number (low 4 octets, starts at a random >> 32-bit >> >>>>>> value) >> >>>>>> * Octets 20+: payload >> >>>>>> >> >>>>>> Note: I'm not sure whether the client should pack the connection ID >> >>>>>> with random >> >>>>>> values. They would have no semantic value, though they might >> serve to >> >>>>>> provide >> >>>>>> proof that the server received the packet if we require echoing, >> see >> >>>>>> below. >> >>>>>> >> >>>>>> >> >>>>>> A server packet contains a connection ID: >> >>>>>> * Octets 4-11: connection ID (server-selected value) >> >>>>>> * Octets 12-15: version (echoed) >> >>>>>> * Octets 16-19: packet number (low 4 octets, random 32-bit initial >> >>>>>> value) >> >>>>>> * Octets 20+: payload >> >>>>>> >> >>>>>> A version negotiation packet contains: >> >>>>>> * Octets 4-11: connection ID (echoed) >> >>>>>> * Octets 12-15: version received (echoed) >> >>>>>> * Octets 16-19: packet number (echoed) >> >>>>>> * Octets 20+: payload = version list >> >>>>> >> >>>>> >> >>>>> In order for the server to echo back the packet number, the server >> >>>>> obviously needs to be able parse the packet number. But if the >> packet >> >>>>> contains a version that the server does not support, it may well be >> the case >> >>>>> that the packet number layout may be different in the new version. >> So I'm >> >>>>> not sure it's possible to echo back the packet number. >> >>>>>> >> >>>>>> A public reset packet contains: >> >>>>>> * Octets 4-11: connection ID (echoed) >> >>>>>> * Octets 12-15: version (echoed) >> >>>>>> * Octets 16-19: rejected packet number (echoed) >> >>>>>> * Octets 20+: payload = authentication data >> >>>>> >> >>>>> >> >>>>> Public reset packets are commonly sent when a server receives a >> packet >> >>>>> for a connection it does not have state for. (For example, a server >> restart >> >>>>> or a routing hiccup). In this case, the server is responding to a >> packet >> >>>>> with an unknown version and consequently and unknown packet number. >> So I'm >> >>>>> not sure it's possible to echo back the packet number. >> >>>>>> >> >>>>>> Echoing details from the packet in both version negotiation and >> >>>>>> provides return >> >>>>>> routeability on version negotiation (#244), while maintaining a >> >>>>>> consistent >> >>>>>> header shape for all packets. >> >>>>>> >> >>>>>> These long-form packets are used for anything that doesn't have >> 1-RTT >> >>>>>> packet >> >>>>>> protection and prior to the completion of version negotiation. >> Once >> >>>>>> both >> >>>>>> conditions are met, switch to sending short-form packets. I >> haven't >> >>>>>> defined any >> >>>>>> 5/7-bit code for protected long-form packets, but that's easy to >> do if >> >>>>>> we need >> >>>>>> to provide for them (see below for more on this). >> >>>>>> >> >>>>>> >> >>>>>> ## Extension headers >> >>>>>> >> >>>>>> An 8-bit space (like IPv6) carries an identifier for the protocol >> >>>>>> extension. >> >>>>>> >> >>>>>> Each header extension takes the form: >> >>>>>> * Octet 1: next identifier >> >>>>>> * Octet 2: length >> >>>>>> >> >>>>>> Since only the lower 5 (or 7) bits of this space is accessible from >> >>>>>> the outset, >> >>>>>> 0x00 is reserved for a null extension header, allowing the full >> space >> >>>>>> to be >> >>>>>> unlocked. 0x?a can be used for greasing. >> >>>>>> >> >>>>>> I haven't talked to IP-layer people about whether they consider the >> >>>>>> IPv6 scheme >> >>>>>> this is based on to be successful. Either way, this should at >> least >> >>>>>> have plenty >> >>>>>> of hardware support. >> >>>>>> >> >>>>>> FWIW, I'm not sure that we need the complexity that this adds. >> It's >> >>>>>> not clear >> >>>>>> that there is a motivating use case. However, on balance it's >> >>>>>> probably worth >> >>>>>> putting something in for the moment. If it turns out that we don't >> >>>>>> use it and >> >>>>>> can't find even a potential use case, then removing it is simple >> >>>>>> enough. >> >>>>>> >> >>>>>> That said, this form could be used to pack a TLS Finished into >> 1-RTT >> >>>>>> packets if >> >>>>>> we define a 5- or 7-bit code for "small bit of handshake, followed >> by >> >>>>>> more", >> >>>>>> after which we can include a 1-RTT payload. >> >>>>>> >> >>>>>> >> >>>>>> # Short Header >> >>>>>> >> >>>>>> ``` >> >>>>>> 0 1 2 3 >> >>>>>> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> |S|K| Packet Number (30) | >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> | | >> >>>>>> + Connection ID + >> >>>>>> | | >> >>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> >>>>>> ``` >> >>>>>> >> >>>>>> The short form header is defined to be specific to a version. >> >>>>>> Anything >> >>>>>> can change between protocol versions. >> >>>>>> >> >>>>>> A short packet header - in this version - reserves two bits from >> the >> >>>>>> first >> >>>>>> octet: >> >>>>>> * SHORT_HEADER bit 7 (0x80) = 1, >> >>>>>> * KEY_PHASE bit 6 (0x40) = 0 initially >> >>>>>> >> >>>>>> The remainder of the first four octets contain the packet number. >> 30 >> >>>>>> bits >> >>>>>> should be plenty. If a need is found for more flags, those can >> steal >> >>>>>> upper >> >>>>>> bits from the packet number. (Frankly, I suspect that 14 bits >> might >> >>>>>> be >> >>>>>> enough, but Ian was a little leery of that when I suggested it, and >> >>>>>> this >> >>>>>> keeps the connection ID in the same place in every packet.) >> >>>>>> >> >>>>>> The connection ID follows on the next 8 octets. >> >>>>>> >> >>>>>> If we need more bits, then we can steal them from the packet >> number. >> >>>>>> >> >>>>> >> >>>> >> >>> >> >> >> >> >> > >> > > --94eb2c149714bc1b7e05485a3417 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Responding to Ian and Martin together. A couple of high-order points:=C2= =A0
(i) There may be value in the separation of long and short he= aders, and I'd like to keep that general idea around, and come back to = this later. That said, as Ian points out, there are things that aren't = resolved yet, and redoing the header at this time seems like an early optim= ization. I think we should address the things that we have consensus for (a= dding a magic header for directionality). We had consensus on attempting to= simplify the headers, which we can do, but I'd be wary of doing it at = a cost to common use cases.
(ii) Let's not add arbitrary exte= nsibility to the header. We have versioning, we have transport params, and = now this adds a third extensibility option which seems unnecessary.

More inline:
=C2=A0
Extensibility:=
ekr explained the rationale here, it's an escape valve.=C2=A0 I too wou= ld
dearly like to remove the feature.=C2=A0 Given that I can't think of a = use
case, I hope that time will come soon.


All the use cases I can think o= f for extensibility would be on short packets, so if we're going to do = this, I think it should be available there as well.=C2=A0 Also, the last ti= me I remember talking about an extensible UDP header, it was at the PLUS Bo= F, where there were quite a few objections, notably on privacy grounds.

I don't understand ekr's rationale.=C2=A0 We&= #39;ll already be doing negotiation as part of the QUIC handshake in TLS, s= o I feel like that combined with version negotiation provide a pretty subst= antial escape valve.=C2=A0 These extensions seem only valuable to communica= te to or from middleboxes or if we absolutely have to add something to 0RTT= packets.=C2=A0

I a= gree. If we have a need for more header fields, let's revisit the heade= r itself. Providing arbitrary extensibility hoping that it doesn't get = used is a bad strategy.
=C2=A0
It seems like your counter-proposal just reiterates the current design
with some minor adjustments.=C2=A0 I just don't think that is sufficien= t to
address the concerns that people have raised about the excessive
number of variations in packet layout.=C2=A0 Adding a magic field in the way you propose only compounds that problem.
<= /div>

I would like to come back to th= is point -- yes there were some concerns raised about the variations in pac= ket layout. I don't think there's been a convincing case that this = is a major issue for implementations. Where exactly is this variability in = headers a problem? I'd like to hear more about this issue before we emb= ark on a complete redesign. Specifically, implementation experience (ours a= t least, others with experience should chime in) suggests that this has not= been a concern for implementation at least.

The reason for needing a proposal was that it was clear that we needed
a holistic approach to designing the header.=C2=A0 There were just too many=
different, interacting issues.=C2=A0 My proposal addresses many of those at=
once with a simple change.=C2=A0 From a skim through the list: #40, #56, #67, #119, #133, #135, #170, #185, #193, and #244 all go away.=C2=A0 It
also goes some way to address #147 and #205.

After reading through them, I don't believe #40, #56, #67, #119, #1= 33, #135, #170, #185, #193, and #244 all go away with this proposal, since = this proposal really is about framing. Some were tentatively resolved at th= e interim or are in the process of being resolved by proper documentation(t= hanks for your #67 PR, BTW).=C2=A0 Additionally, this has implications on o= ther issues, such as #203, #269 and #279, and I opened #292 and #293 to dis= cuss whether a fixed location for connection id and 4 byte alignment are re= quirements.

On the other hand, if we had clear direction on most of the non-edito= rial issues listed(except #40, which is really only a question of framing),= we'd be in a better position to fix up the framing with a clear set of= goals.

I spent time goin= g through all the issues as well. These issues are either addressed by usin= g the magic field for directionality, by using server-generated connection = ID, or by editorial work, all of which are independent of the framing chang= es. These changes can be made simply in the current format. The newer issue= s should be addressed, and we can always come back to this framing change l= ater, if it's still warranted.

- jana
=C2=A0
On 10 February 2017 at 12:07, Jana Iyengar <jri@google.com> wrote:
> Hi Eric,
>
> Responses inline.
>
>>>
>>> I like that you've separated the early handshake packet fo= rmat from the
>>> "common case" format -- there may be value in having= that separation when
>>> thinking about overhead and header formats (earlier versions o= f the
>>> transport draft talked about Regular and Special packets, whic= h may be worth
>>> reconsidering.) That said, I think this proposal conflates thr= ee things:
>>> (i) it attempts to compress the header, in some cases
>>
>>
>> I thought there was agreement that making the header smaller was g= ood. Not
>> sure how we would have consensus for that in the abstract, so we p= robably
>> just need to debate whether or not this particular form of compres= sion is
>> good.
>
>
> Agreed in principle, but as Ryan points out, this makes the connection= ID
> show up all the time, which increases header size.
>
>>>
>>> (ii) it changes the header in ways which have been suggested b= ut without
>>> consensus (connection ID, magic field)
>>
>>
>> Hmm.... I thought we did have consensus for the magic field in the=
>> interim. Of course that needs confirmation on the mailing list, bu= t this
>> seems like a good venue for that.
>> I don't think we need concern ourselves with the connection ID= , because
>> this proposal neatly accommodates removing the connection ID field= , either
>> by having the server
>> tell the client it can (with no indicator) or if we like, stealing= a bit
>> from the packet number to say ("here is a conn id"). The= re doesn't seem to
>> be a percentage in removing conn id from the special packets, so w= e don't
>> need to address that.
>
>
> Yes, you're right. We did have consensus on encoding version neg p= ackets to
> include a ver + magic for directionality, but as you note, this hasn&#= 39;t been
> confirmed on the list, and we should do that. This is a simple change = that
> addresses the DoS issue by adding directionality (Issue #135), and tha= t
> change would be relatively small.
>
>>> (iii) it adds extensibility in ways that are not yet justified= .
>>
>>
>> I think I do agree with you here, ultimately, but I'd like to = leave it in
>> for now. My reasoning here is that you often find that you have a = bunch of
>> small things that you want some flexibility for but that aren'= t enough to
>> add a whole new extension point, so you just get death of a thousa= nd cuts as
>> you try to work around them. Contrariwise, if we have this extensi= on point
>> available, we can see if it gets used and pull it out before pubre= q.
>
>
> I am sympathetic to your point about death by a thousand cuts, but I d= on't
> think we're there yet. I'm still of the opinion that this intr= oduces
> unwarranted arbitrary extensibility in the header, since I don't s= ee the
> warranting use cases.
>
>>>
>>> I think the proposal is useful in that it shows how the header= might look
>>> in a different world. But let's get consensus on what'= s reasonable to do
>>> before figuring out how to do it. Specifically, as Ian notes, = #269 and #279
>>> are existing issues, and we need to discuss things like the ma= gic header
>>> field before adding them in (is there an issue for this?)
>>>
>>> I propose parking this for now.
>>
>>
>> I'd rather we hash out these issues and decide on this PR or s= ome revision
>> one way or the other. There's a lot of other stuff that's = kind of piled up
>> behind the packet header
>
>
> In that case, I'd suggest that we separate the version + magic fla= g in one
> PR to address the DoS issue. As discussed at the interim, this would s= imply
> mean that we have an interpretation of the version bit that includes t= he
> magic part.
>
>
> For the long header (inlining my comments below:)
> * Octet 0: Special
>=C2=A0 =C2=A0* Bit 7 (i.e., 0x80): SHORT_HEADER (set to 0 here)
>=C2=A0 =C2=A0* Bit 6-5: Type
>=C2=A0 =C2=A0 =C2=A0* 11 - client packet
>=C2=A0 =C2=A0 =C2=A0* 10 - server packet
>=C2=A0 =C2=A0 =C2=A0* 01 - public reset
>=C2=A0 =C2=A0 =C2=A0* 00 - version negotiation
>
> Why do you need two codepoints for regular packets? The magic header g= ives
> directionality on initial packets, and the connection keys on subseque= nt
> rounds, right? You need only three codepoints in all here.
>
>=C2=A0 =C2=A0* Bits 4-0: Next protocol
>=C2=A0 =C2=A0 =C2=A0* 0b10001 indicates that it is QUIC handshake data<= br> >=C2=A0 =C2=A0 =C2=A0* 0b01111 indicates that it is QUIC 0-RTT data
>
> Why do we need these?
>
>=C2=A0 =C2=A0 =C2=A0* other values mean that the payload following the = packet number
> contains
>=C2=A0 =C2=A0 =C2=A0 an IPv6-style extension header
>
> Why do we need this?
>
> * Octets 1-3: Magic (this can be short given that we will have a MAC a= s
> well)
>=C2=A0 =C2=A0* 0x756963 for a client,
>=C2=A0 =C2=A0* 0x554943 for a server
>
> SGTM, based on consensus.
>
>
> The proposed short header removes the following bits that I would not = want
> to lose:
> - packet number size. The packet number size currently changes as our<= br> > estimation of how many packets fit in the cwnd changes (loosely speaki= ng)
> and is dynamic through the connection.
> - Connection ID flag, and makes the Connection ID required in all pack= ets.
> As previously pointed out, this flexibility is quite useful and reduce= s
> header size quite a bit in the direction where it commonly matters mos= t
> (server->client), but it can be used by any endpoint as long as it = does not
> need Connection ID for routing on incoming packets.
>
>
> Based on my take on the long and short headers above:
>
> If we remove the extensibility points, eliminate server/client
> directionality in the header bits, and retain the fields I noted above= , I'm
> not sure that there's much to be had by separating the long and sh= ort
> headers. The resulting header looks as follows on all packets:
> - TT: Packet type
>=C2=A0 =C2=A0 =C2=A0* 00 - version negotiation packet
>=C2=A0 =C2=A0 =C2=A0* 01 - public reset
>=C2=A0 =C2=A0 =C2=A0* 1X - regular packet
> - Key Phase
> - Connection ID
> - Packet Number Size (2 bits)
>
> The only difference from the spec is the TT bits, which is equivalent = to the
> explicit V and PR bits in the spec right now, since with V and PR bits= :
> 10 - version negotiation packet
> 01 - public reset packet (we could make this X1, to make it cover the = unused
> codepoint.)
> 00 - regular packet
>
>
> I would suggest a PR that only adds a magic field for directionality, = and
> leaves the rest of it out; perhaps in a separate issue + PR to discuss= why
> these may be useful.
> - jana
>
>
>
>
>> -Ekr
>>
>>
>>>
>>> - jana
>>>
>>>
>>> On Thu, Feb 9, 2017 at 11:57 AM, Ian Swett <ianswett@google.com> wrote= :
>>>>
>>>> Thanks for taking a crack at this.=C2=A0 I have a few high= -level comments.
>>>>
>>>> 1) This implicitly requires the connection ID to always be= stated, which
>>>> as Ryan said, inflates the packet header substantially fro= m the status quo
>>>> of what we send server to client, which I'm not a fan = of from a practical
>>>> perspective.=C2=A0 Equally importantly, I think we need to= resolve the
>>>> conversation about privacy and connection IDs before we kn= ow whether we
>>>> should always be sending the connection ID.
>>>> 2) I believe we may want to add packet number echo bit(#26= 9) and
>>>> possibly a loss detection bit(#279) on every packet.=C2=A0= I think it makes sense
>>>> to resolve these before redesigning the packet header, sin= ce I believe it
>>>> would substantially change your current design?
>>>> 3) This proposes header extensions, which seems orthogonal= to the header
>>>> redesign.=C2=A0 I'm not a fan of header extensions at = the moment, but I think it
>>>> deserves a separate conversation.
>>>>
>>>> So I would be biased towards getting some clarity on the c= onnection id
>>>> privacy question as well as the #269 and #279 before attem= pting a holistic
>>>> redesign of the packet header.
>>>>
>>>> On Thu, Feb 9, 2017 at 1:31 PM, Ryan Hamilton <rch@google.com> wrote:<= br> >>>>>
>>>>>
>>>>>
>>>>> On Wed, Feb 8, 2017 at 8:42 PM, Martin Thomson
>>>>> <martin.thomson@gmail.com> wrote:
>>>>>>
>>>>>> As I go through the issues list, it appears that a= lot of issues on
>>>>>> which we have consensus would benefit from a resol= ution to the header
>>>>>> format issue.=C2=A0 To that end, I have sketched o= ut a proposal that I
>>>>>> think meets the various constraints we have.
>>>>>>
>>>>>> I want to discuss this here before we embark on wh= at could be a fairly
>>>>>> disruptive set of changes to the drafts.
>>>>>>
>>>>>> (A copy of the following text can be found at
>>>>>> https= ://gist.github.com/martinthomson/744d04cbcec9be554f2f8e7bae2715b8=
>>>>>> )
>>>>>> --
>>>>>>
>>>>>> There are two forms of QUIC common header: long an= d short.=C2=A0 Long form
>>>>>> packets
>>>>>> are used for the initial exchange - until both 1-R= TT packet protection
>>>>>> can be
>>>>>> started AND version negotiation is complete.=C2=A0= Short form packets carry
>>>>>> the
>>>>>> bulk of the data.
>>>>>>
>>>>>> This removes a lot of the flexibility that was the= source of most of
>>>>>> the
>>>>>> objections to the current format.=C2=A0 Fields are= aligned on four octet
>>>>>> boundaries.
>>>>>> All long-form header variations have the exact sam= e form.=C2=A0 The
>>>>>> connection ID is
>>>>>> in the same place in both short and long form.=C2= =A0 The long form clearly
>>>>>> identifies the role of the sender in the first oct= et and it identifies
>>>>>> the
>>>>>> packet as a QUIC packet.
>>>>>>
>>>>>> The cost is that it makes occasional packets a lit= tle larger (the long
>>>>>> header
>>>>>> is 20 octets, whereas the existing form uses betwe= en 14 and 19 octets
>>>>>> for initial
>>>>>> handshake packets).=C2=A0 This is an acceptable tr= ade-off given that only a
>>>>>> few of
>>>>>> these packets are ever exchanged on a connection.<= br> >>>>>>
>>>>>> It makes most packets (the short header) 12 octets= where it is
>>>>>> possible to
>>>>>> have 10 octet packets.
>>>>>
>>>>>
>>>>> In currently deployed QUIC, 1-RTT packets from the ser= ver to the client
>>>>> do not have connection ID present. (This is because an= endpoint tells the
>>>>> peer how many connection ID bits it needs the peer to = send. In the case of
>>>>> clients, since they only have 1 connection on a given = socket, the connection
>>>>> ID is not needed.). These packets also typically have = a 1 or 2 byte packet
>>>>> number. So the header ends up being:=C2=A0 1 byte publ= ic flags + 1 or 2 byte
>>>>> packet number for a total of 2-3 bytes. This new forma= t seems to be much
>>>>> larger.
>>>>>
>>>>>>
>>>>>> However, a 10 octet packet header assumes an 8 bit=
>>>>>> packet number, this is 30.
>>>>>
>>>>>
>>>>> I don't think I understand how to construct a 10 o= ctet packet. Can you
>>>>> elaborate?
>>>>>
>>>>>>
>>>>>> # Long Header
>>>>>>
>>>>>> ```
>>>>>>=C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A03
>>>>>>=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |S|Typ|=C2=A0 Next=C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Magic "uic"/"UIC"=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet Number=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0[Header Extensions]=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload=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...
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> ```
>>>>>>
>>>>>> The first four octets:
>>>>>> * Octet 0: Special
>>>>>>=C2=A0 =C2=A0* Bit 7 (i.e., 0x80): SHORT_HEADER (se= t to 0 here)
>>>>>>=C2=A0 =C2=A0* Bit 6-5: Type
>>>>>>=C2=A0 =C2=A0 =C2=A0* 11 - client packet
>>>>>>=C2=A0 =C2=A0 =C2=A0* 10 - server packet
>>>>>>=C2=A0 =C2=A0 =C2=A0* 01 - public reset
>>>>>>=C2=A0 =C2=A0 =C2=A0* 00 - version negotiation
>>>>>>=C2=A0 =C2=A0* Bits 4-0: Next protocol
>>>>>>=C2=A0 =C2=A0 =C2=A0* 0b10001 indicates that it is = QUIC handshake data
>>>>>>=C2=A0 =C2=A0 =C2=A0* 0b01111 indicates that it is = QUIC 0-RTT data
>>>>>>=C2=A0 =C2=A0 =C2=A0* other values mean that the pa= yload following the packet number
>>>>>> contains
>>>>>>=C2=A0 =C2=A0 =C2=A0 an IPv6-style extension header=
>>>>>> * Octets 1-3: Magic (this can be short given that = we will have a MAC
>>>>>> as well)
>>>>>>=C2=A0 =C2=A0* 0x756963 for a client,
>>>>>>=C2=A0 =C2=A0* 0x554943 for a server
>>>>>>
>>>>>> Note: A client packet starts with "quic"= , server starts with "QUIC",
>>>>>> 0-RTT starts
>>>>>> with "ouic".
>>>>>>
>>>>>> Note(2): We might consider the second set of 7 bit= s to be a single
>>>>>> code space,
>>>>>> rather than use a 2+5 bit partitioning.=C2=A0 That= gives us a bit more
>>>>>> flexibility
>>>>>> and avoids meaningless combinations like public re= set + 0-RTT.
>>>>>>
>>>>>> The remainder of the packet layout is the same reg= ardless of type, the
>>>>>> difference
>>>>>> being what rules for how to fill the values out an= d their semantics.
>>>>>>
>>>>>> A client packet then contains:
>>>>>> * Octets 4-11: connection ID (initially all zeroes= /random)
>>>>>> * Octets 12-15: version
>>>>>> * Octets 16-19: packet number (low 4 octets, start= s at a random 32-bit
>>>>>> value)
>>>>>> * Octets 20+: payload
>>>>>>
>>>>>> Note: I'm not sure whether the client should p= ack the connection ID
>>>>>> with random
>>>>>> values.=C2=A0 They would have no semantic value, t= hough they might serve to
>>>>>> provide
>>>>>> proof that the server received the packet if we re= quire echoing, see
>>>>>> below.
>>>>>>
>>>>>>
>>>>>> A server packet contains a connection ID:
>>>>>> * Octets 4-11: connection ID (server-selected valu= e)
>>>>>> * Octets 12-15: version (echoed)
>>>>>> * Octets 16-19: packet number (low 4 octets, rando= m 32-bit initial
>>>>>> value)
>>>>>> * Octets 20+: payload
>>>>>>
>>>>>> A version negotiation packet contains:
>>>>>> * Octets 4-11: connection ID (echoed)
>>>>>> * Octets 12-15: version received (echoed)
>>>>>> * Octets 16-19: packet number (echoed)
>>>>>> * Octets 20+: payload =3D version list
>>>>>
>>>>>
>>>>> In order for the server to echo back the packet number= , the server
>>>>> obviously needs to be able parse the packet number. Bu= t if the packet
>>>>> contains a version that the server does not support, i= t may well be the case
>>>>> that the packet number layout may be different in the = new version. So I'm
>>>>> not sure it's possible to echo back the packet num= ber.
>>>>>>
>>>>>> A public reset packet contains:
>>>>>> * Octets 4-11: connection ID (echoed)
>>>>>> * Octets 12-15: version (echoed)
>>>>>> * Octets 16-19: rejected packet number (echoed) >>>>>> * Octets 20+: payload =3D authentication data
>>>>>
>>>>>
>>>>> Public reset packets are commonly sent when a server r= eceives a packet
>>>>> for a connection it does not have state for. (For exam= ple, a server restart
>>>>> or a routing hiccup). In this case, the server is resp= onding to a packet
>>>>> with an unknown version and consequently and unknown p= acket number. So I'm
>>>>> not sure it's possible to echo back the packet num= ber.
>>>>>>
>>>>>> Echoing details from the packet in both version ne= gotiation and
>>>>>> provides return
>>>>>> routeability on version negotiation (#244), while = maintaining a
>>>>>> consistent
>>>>>> header shape for all packets.
>>>>>>
>>>>>> These long-form packets are used for anything that= doesn't have 1-RTT
>>>>>> packet
>>>>>> protection and prior to the completion of version = negotiation.=C2=A0 Once
>>>>>> both
>>>>>> conditions are met, switch to sending short-form p= ackets.=C2=A0 I haven't
>>>>>> defined any
>>>>>> 5/7-bit code for protected long-form packets, but = that's easy to do if
>>>>>> we need
>>>>>> to provide for them (see below for more on this).<= br> >>>>>>
>>>>>>
>>>>>> ## Extension headers
>>>>>>
>>>>>> An 8-bit space (like IPv6) carries an identifier f= or the protocol
>>>>>> extension.
>>>>>>
>>>>>> Each header extension takes the form:
>>>>>> * Octet 1: next identifier
>>>>>> * Octet 2: length
>>>>>>
>>>>>> Since only the lower 5 (or 7) bits of this space i= s accessible from
>>>>>> the outset,
>>>>>> 0x00 is reserved for a null extension header, allo= wing the full space
>>>>>> to be
>>>>>> unlocked.=C2=A0 0x?a can be used for greasing.
>>>>>>
>>>>>> I haven't talked to IP-layer people about whet= her they consider the
>>>>>> IPv6 scheme
>>>>>> this is based on to be successful.=C2=A0 Either wa= y, this should at least
>>>>>> have plenty
>>>>>> of hardware support.
>>>>>>
>>>>>> FWIW, I'm not sure that we need the complexity= that this adds.=C2=A0 It's
>>>>>> not clear
>>>>>> that there is a motivating use case.=C2=A0 =C2=A0H= owever, on balance it's
>>>>>> probably worth
>>>>>> putting something in for the moment.=C2=A0 If it t= urns out that we don't
>>>>>> use it and
>>>>>> can't find even a potential use case, then rem= oving it is simple
>>>>>> enough.
>>>>>>
>>>>>> That said, this form could be used to pack a TLS F= inished into 1-RTT
>>>>>> packets if
>>>>>> we define a 5- or 7-bit code for "small bit o= f handshake, followed by
>>>>>> more",
>>>>>> after which we can include a 1-RTT payload.
>>>>>>
>>>>>>
>>>>>> # Short Header
>>>>>>
>>>>>> ```
>>>>>>=C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A03
>>>>>>=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 = 2 3 4 5 6 7 8 9 0 1
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |S|K|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Packet Number (30)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Connection ID=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
>>>>>> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+
>>>>>> ```
>>>>>>
>>>>>> The short form header is defined to be specific to= a version.
>>>>>> Anything
>>>>>> can change between protocol versions.
>>>>>>
>>>>>> A short packet header - in this version - reserves= two bits from the
>>>>>> first
>>>>>> octet:
>>>>>> * SHORT_HEADER bit 7 (0x80) =3D 1,
>>>>>> * KEY_PHASE bit 6 (0x40) =3D 0 initially
>>>>>>
>>>>>> The remainder of the first four octets contain the= packet number.=C2=A0 30
>>>>>> bits
>>>>>> should be plenty.=C2=A0 If a need is found for mor= e flags, those can steal
>>>>>> upper
>>>>>> bits from the packet number.=C2=A0 (Frankly, I sus= pect that 14 bits might
>>>>>> be
>>>>>> enough, but Ian was a little leery of that when I = suggested it, and
>>>>>> this
>>>>>> keeps the connection ID in the same place in every= packet.)
>>>>>>
>>>>>> The connection ID follows on the next 8 octets. >>>>>>
>>>>>> If we need more bits, then we can steal them from = the packet number.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>


--94eb2c149714bc1b7e05485a3417-- From nobody Sun Feb 12 16:35:46 2017 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 930071294E1 for ; Sun, 12 Feb 2017 16:35:44 -0800 (PST) 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 2yadTJ5ECOEB for ; Sun, 12 Feb 2017 16:35:43 -0800 (PST) Received: from mail-qk0-x243.google.com (mail-qk0-x243.google.com [IPv6:2607:f8b0:400d:c09::243]) (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 7FC191294C7 for ; Sun, 12 Feb 2017 16:35:43 -0800 (PST) Received: by mail-qk0-x243.google.com with SMTP id p22so4790064qka.3 for ; Sun, 12 Feb 2017 16:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jdt04Pah65Okpl/uBl7k0UmCiKamMbZz0XhegJEOaW4=; b=izVS4WdLilUcZ99IDzcFxu/ezD1fOAjyd6MKVKQzw0xI0Y5OAxadFo4/yurwoi9bqs vz/DWK7Oq+irOiWmv05Yl8KXBWve+1BhjAks/88yjA1LgFxyIvgju2DAMn20udw/gSyx Yg2t6pFq2WQifSTW+AN0gmPquCGRqQjdbubpuBKybRewMvct65mSeTbopTeoHrh1x4lO D3xvf2H6X9fdocLK/U/KbQq5vCdfSUInRVtzDSQ5qms28S4Hu7TstL6rMariQV6kTTXm +b++IUFSlzyL/Ck3GNMALHze6Kbu5JDxAFtfbfmZWNHivVLzJKVMSochzZcyWQfWdUeG hwuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jdt04Pah65Okpl/uBl7k0UmCiKamMbZz0XhegJEOaW4=; b=ajjmkmvxpjMTRn27rtJJkjQ/wIFkzyWOGKji5lV6E04BICDAeCxvqcJmcc8D0CXDlH aapQtnQ4zixtTcz9lXlGWobG5Ezo9fcPoDyMe25aElgSUcMBXmS1Zj5nc/Pkko5Vr0Y+ Mg/PYAD9k9PkPNSNCXr4sGyFYHG2x2UT4elu59pszhyuJO49KFZWkZmr6mK7C09iPFye O7gWqjQfhZwqn50reOcotsonWeMlzdtd2SaD+Or6MNBXWXosmqWYrq8PorJx4Ty5OxDA rOAWQZWOWlFl6mFb3qU2yJCWC1RLet7xhZlVhLgOAI01MDD7nnRdE0rUstRMdZxrmZ2y R/JA== X-Gm-Message-State: AMke39kReO7kXNOykmhq7rZjXv2JrRnLwj2eK5EvUodayapP6aKhXAxWVHXCGUk23xvUkH0M3he/Bh+ycgOQsA== X-Received: by 10.233.216.68 with SMTP id u65mr18698490qkf.68.1486946142721; Sun, 12 Feb 2017 16:35:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Sun, 12 Feb 2017 16:35:42 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 13 Feb 2017 11:35:42 +1100 Message-ID: Subject: Re: Proposal for QUIC header To: Ian Swett Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jana Iyengar , Eric Rescorla , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 00:35:44 -0000 On 13 February 2017 at 04:58, Ian Swett wrote: > All the use cases I can think of for extensibility would be on short > packets, so if we're going to do this, I think it should be available there > as well. Also, the last time I remember talking about an extensible UDP > header, it was at the PLUS BoF, where there were quite a few objections, > notably on privacy grounds. The principle here is that short headers don't need extensibility in the same way. While we might want to be careful about what can change in the short header, in theory it is possible to change everything about the short header by negotiation. And you said as much yourself. > I don't understand ekr's rationale. Is that a rhetorical device? FWIW, I entirely agree in that I don't *think* that we need extensibility. But I'd rather delete something when I'm certain it's not needed than find we're building adhoc systems. Since that's a nonessential part of the proposal, I'm happy to remove it on the understanding that the escape valve exists. > After reading through them, I don't believe #40, #56, #67, #119, #133, #135, > #170, #185, #193, and #244 all go away with this proposal, I suggest we don't belabor this point. We clearly disagree (at least on the ones I checked). From nobody Sun Feb 12 16:39:09 2017 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 A2FFE1294E1 for ; Sun, 12 Feb 2017 16:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 d3YqaMtjoTZJ for ; Sun, 12 Feb 2017 16:39:06 -0800 (PST) Received: from mail-qk0-x244.google.com (mail-qk0-x244.google.com [IPv6:2607:f8b0:400d:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F0B6127058 for ; Sun, 12 Feb 2017 16:39:06 -0800 (PST) Received: by mail-qk0-x244.google.com with SMTP id e1so12580611qkh.1 for ; Sun, 12 Feb 2017 16:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PifrLupYlxDfee35r7Or76Hbo8cBgAbR5XcyJpO3G2c=; b=AAO6MLzeTwuNJZk9H+haUJQ1J2BbAwBI2qJAFHW5k4C4214HwHiNtTm9VvryjNR+Pv rOcOgsGkKDJlaQQLYyP1M2hnyFfDFTgsl/9GjSjdxycXCMb3t0AV5AWUhJRezlvToQUH nxSO9gfY4PIUEHP1AwRdHICsYw4qg73SLWcVfzvjXTxYkWKkZYGsh9138+zHXGpJWPpx mokzixv6tQCQ9wpu77CxpitIRFmF02bBA2G4uPxA7oJxta9qotC4dGOLa+vaXkoaun5b Q4a8qtIe9Xj60wFdK5IKvuDIyqUC94GcHrVGuiSfMT7QUv5BEEBBTal0pNR4vO9UyJkD agBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PifrLupYlxDfee35r7Or76Hbo8cBgAbR5XcyJpO3G2c=; b=Bjyvg0CNRveWxcz+RyMSEqmM5Hphw88CUr3zHxmbZ6qO+MahQS4mfYDclYM4T3Ye8f WsdoscdUHreD9Cv3l8h4tjM2J8Jxd6Q/WaA9drTE1Kx30gfbrRqMXzD4bpGrJsLdlXsb xXPxe54grYco6pQLbSnfk1H4HwF5smFCTHnmwt436BOIVMoAGKS64TJd70kiag+S0bNc D4hKzdkfOz0LRjAWhLwInJEAaWJZ9CoOCYWWheuilQkqFyc9MwaVWieN9zVn6Zsq/gRe O1QkSratRjsoHdi0zsE3PKiwP2sVeS6rfkAgo+iXb81Ue0Q/TlqRSxk/vr6ge6IwYDLT 7uQQ== X-Gm-Message-State: AMke39lLbJFs7RQCQ8Fd8mdAStY4iihFjTsQdM/Lhzb1MIH7th7OlyhQ0qfQI+x2rkw2pXqaokFLo+sdFGjf7A== X-Received: by 10.55.151.7 with SMTP id z7mr20031221qkd.316.1486946345792; Sun, 12 Feb 2017 16:39:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Sun, 12 Feb 2017 16:39:05 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 13 Feb 2017 11:39:05 +1100 Message-ID: Subject: Re: Proposal for QUIC header To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Ian Swett , IETF QUIC WG , Eric Rescorla , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2017 00:39:07 -0000 On 13 February 2017 at 06:19, Jana Iyengar wrote: > There may be value in the separation of long and short headers, and I'd like > to keep that general idea around, and come back to this later. That said, as > Ian points out, there are things that aren't resolved yet, and redoing the > header at this time seems like an early optimization. Shelving the discussion isn't going to work. We've a lot of outstanding work that is affected by this (as you and Ian readily acknowledge) and uncertainty on this point is affecting our ability to make progress. It's hardly optimization, the structure of the bits in the handshake is foundational. From nobody Tue Feb 14 14:16:54 2017 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 AFDD1129863 for ; Tue, 14 Feb 2017 14:16:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.887, 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 Y2L8ji7huP1L for ; Tue, 14 Feb 2017 14:16:51 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0097.outbound.protection.outlook.com [104.47.32.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3531298BC for ; Tue, 14 Feb 2017 14:16:51 -0800 (PST) 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=0JyYLrAOsCBRtCOXxIiYI184NqaJiY8T+Gnyafv/26Q=; b=RZ7cHsrnCcsv54oCgfpJdT23AVMlBGpaMrx4/RtaZkrghJqf+4lK3AY12sB8LXv24Uf3Axw5IwE7gh9xm+DGv6dejOce5YzT0Wh1rTwEoRXGN+Y8higYkm1vouaN81Fa8CyitwnOj+FOvWVTvZ727MKbjKNdetdPV+ZhycEOTYw= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Tue, 14 Feb 2017 22:16:49 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0888.030; Tue, 14 Feb 2017 22:16:49 +0000 From: Mike Bishop To: Patrick McManus , Charles 'Buck' Krasic Subject: RE: Splitting QPACK Thread-Topic: Splitting QPACK Thread-Index: AdJ30+1U3c1mTWZdTYamExCwb70oCACzn2/wAAELOgAAARWsoAAua8MAACFVcoAAAD2LAAAGDrKAAATiuQAAAMc7gAAB6CmAAAzFUYACrt5dwA== Date: Tue, 14 Feb 2017 22:16:49 +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=Michael.Bishop@microsoft.com; x-originating-ip: [2601:600:8300:3b9a:b968:14cd:38fe:a35c] x-ms-office365-filtering-correlation-id: 1985f3b4-e4b8-4b56-aa26-08d455272bc7 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:WvrFgzdnZpufPUjGLxMqZtKld+KOB59eKhVLS6WnNZuD4+cPXiETMaQQTDc8dpEfT2PYqWE2rvfSipLxQ10NCLBwhSHRZKIOP9UY7l6eAyp7QMo4+7h3OqUpumCwr1KR9rTdwiBAFFvxlbRJBmGoo9jrovtGOO+ta/rAWcPZreIfCAXZjh+MdnXOagrNd1NYFFFMPx05kwpVjqqOOKoNhVZEGAl6XSBa8EGyoFrm5lh+XEky78KqIcRTe5lU+r7J4JWwNGKVXnyuxxB2hMvMPk17euRf2dLCaK+lwBG9VNYMux+ZtFPJhQWGGQjwFJwaOimQeD6wZ3myFEmada8FK7yXC4fC59CVPqgrKL+jt1At1oyQ8UdhMBv4LCYPB4S986kLxG99XB38E15kI8Z13uZM/LUOJMKauL+BUGas+XczTa58/5KOiazp3T9rOqU2+HHQuMIksant+6ogOrz6f3R+elB9OCuLRECD2Oyx7+XxWsB4b7UZOiWgSn5L0mSWpcqDpihLjuXjjDLrrEiW2krKpp/3mL3J0xFoJKmj3WA= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 0218A015FA x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39450400003)(39850400002)(39410400002)(39860400002)(189002)(199003)(377454003)(24454002)(189998001)(8990500004)(81156014)(8676002)(81166006)(93886004)(4326007)(105586002)(3480700004)(8936002)(3660700001)(122556002)(3280700002)(106356001)(7906003)(7736002)(74316002)(221733001)(92566002)(2906002)(2900100001)(790700001)(102836003)(6116002)(99286003)(54906002)(6306002)(55016002)(236005)(97736004)(9686003)(54896002)(229853002)(606005)(6506006)(6436002)(50986999)(54356999)(76176999)(10090500001)(5660300001)(39060400002)(38730400002)(33656002)(2950100002)(101416001)(10290500002)(7116003)(25786008)(53936002)(53546003)(5005710100001)(6246003)(86362001)(77096006)(19609705001)(68736007)(86612001)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.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: multipart/alternative; boundary="_000_BN6PR03MB2708F0211875A14F5CAFE7E187580BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2017 22:16:49.0731 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: IETF QUIC WG , Martin Thomson , Ryan Hamilton , Kazuho Oku X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2017 22:16:54 -0000 --_000_BN6PR03MB2708F0211875A14F5CAFE7E187580BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QW4gLTAyIHZlcnNpb24gb2YgdGhlIFFQQUNLIGRyYWZ0IGJhc2VkIG9uIHRoZSBzcGxpdCBtb2Rl bCBhbmQgdGhlIGRpc2N1c3Npb24gZnJvbSB0aGlzIHRocmVhZCBjYW4gYmUgZm91bmQgYXQgIGh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFj ay0wMi4NCg0KRnJvbTogUGF0cmljayBNY01hbnVzIFttYWlsdG86cG1jbWFudXNAbW96aWxsYS5j b21dDQpTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDMxLCAyMDE3IDEwOjI5IFBNDQpUbzogQ2hhcmxl cyAnQnVjaycgS3Jhc2ljIDxja3Jhc2ljQGdvb2dsZS5jb20+DQpDYzogTWFydGluIFRob21zb24g PG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBt aWNyb3NvZnQuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgS2F6dWhvIE9rdSA8 a2F6dWhvb2t1QGdtYWlsLmNvbT47IFJ5YW4gSGFtaWx0b24gPHJjaEBnb29nbGUuY29tPg0KU3Vi amVjdDogUmU6IFNwbGl0dGluZyBRUEFDSw0KDQpvciB0byBwdXQgaXQgYW5vdGhlciByZWxhdGVk IHdheSAtIHRoZSB2YWx1ZSBvZiBocGFjayBoYXMgYWx3YXlzIGJlZW4gaW4gYXZvaWRpbmcgY3du ZCBzdGFsbHMuIHF1aWMgYnJlYWtzIGRvd24gdGhlIG9sZCBhYnN0cmFjdGlvbnMgYW5kIGFuIGVu Y29kZXIgY2FuIGNlcnRhaW5seSBiZXR0ZXIgdGFrZSBpbnRvIGFjY291bnQgY3duZCwgdGhlIGFt b3VudCBvZiBkYXRhIGl0IHRoaW5rcyBpdCB3aWxsIGJlIHNlbmRpbmcsIGFuZCBob3cgaXQgd2Fu dHMgdG8gY29tYmluZSBmcmFtZXMgaW4gcGFja2V0cy4gdGhhdCdzIHByZXR0eSBwb3dlcmZ1bCBp biBiYWxhbmNpbmcgdGhlIHRyYWRlb2ZmcyBoZXJlLg0Kb2ZmIGhhbmQgaXQgc2VlbXMgY2xpZW50 cyBkb2luZyB0aGUgbygxMDApIHRoaW5nIHdvdWxkIGJlIGhpZ2hseSBpbmNlbnRlZCBlYXJseSBv biwgYnV0IGxhdGVyIG1pZ2h0IG5vdCBuZWVkIHRvIGFjY29tbW9kYXRlIHN1Y2ggYnVyc3RzIGFu ZCB3b3VsZCB1c2UgZGlmZmVyZW50IHN0cmF0ZWdpZXMuLiBzaW1pbGFybHkgc2VydmVycyBtaWdo dCBvbmx5IHVzZSBjb21wcmVzc2lvbiByYXJlbHkuDQpiZXlvbmQgdG8gY29tcHJlc3Mgb3Igbm90 LCBkaWZmZXJlbnQgY2hvaWNlcyBtaWdodCBiZSBtYWRlIGluIGhvdyB0aWdodGx5IGVhY2ggcGFj a2V0IGlzIHN0dWZmZWQgYWdhaW4gYmFzZWQgb24gY3duZC4NCg0KT24gV2VkLCBGZWIgMSwgMjAx NyBhdCAxOjIzIEFNLCBDaGFybGVzICdCdWNrJyBLcmFzaWMgPGNrcmFzaWNAZ29vZ2xlLmNvbTxt YWlsdG86Y2tyYXNpY0Bnb29nbGUuY29tPj4gd3JvdGU6DQoNCg0KT24gVHVlLCBKYW4gMzEsIDIw MTcgYXQgMzoyOCBQTSwgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxt YWlsdG86bWFydGluLnRob21zb25AZ21haWwuY29tPj4gd3JvdGU6DQpPbiAxIEZlYnJ1YXJ5IDIw MTcgYXQgMTA6MDYsIENoYXJsZXMgJ0J1Y2snIEtyYXNpYyA8Y2tyYXNpY0Bnb29nbGUuY29tPG1h aWx0bzpja3Jhc2ljQGdvb2dsZS5jb20+PiB3cm90ZToNCj4gT2sgSSBnZXQgaXQgbm93LiAgRm9y IHRoZSBoZWFkZXIgdGhhdCBjYXVzZXMgYSB0YWJsZSBpbnNlcnQsIGl0IHdvdWxkIGJlDQo+IGls bC1hZHZpc2VkIHRvIHVzZSBhIGhwYWNrIGxpdGVyYWwgb24gdGhlIGhlYWRlcnMgc3RyZWFtLiAg IFRoZXJlJ3Mgbm8gcG9pbnQNCj4gZ3VhcmRpbmcgSG9MIGJsb2NraW5nIGFtb25nIHRoaW5ncyB0 aGF0IHRoYXQgd2lsbCBlbmQgdXAgaW4gdGhlIHNhbWUgcGFja2V0DQo+IGFueXdheS4NCg0KVGhl IGhhemFyZCBpcyB3aGVyZSB5b3UgaGF2ZSBtdWx0aXBsZSBjb25jdXJyZW50IHVzZXMgaW4gc2hv cnQgb3JkZXIuDQpJZiBwYWNrZXRpemF0aW9uIGNhdXNlcyB0aGUgaW5zZXJ0IGFuZCB0aGUgcmVm ZXJlbmNlIHRvIGFwcGVhciBpbg0KZGlmZmVyZW50IHBhY2tldHMsIHlvdSBoYXZlIGEgSE9MQiBl eHBvc3VyZS4NCg0KQXMgTWlrZSBvYnNlcnZlcywgdGhlIG9kZHMgb2YgaGF2aW5nIGEgcmVmZXJl bmNlIHRoYXQgY2F1c2VzIGFuIGluc2VydA0Kc3BsaXQgYmV0d2VlbiB0d28gcGFja2V0cyBpcyBs b3cuICBXZWxsLCBkZXBlbmRpbmcgb24gaG93IHlvdQ0KY29uc3RydWN0IHBhY2tldHMuICBZb3Ug Y2FuIG1pbmltaXplIHRoaXMgYnkgZ2VuZXJhdGluZyBpbnRlcmxlYXZlZA0KU1RSRUFNIGZyYW1l cywgYnV0IHRoYXQgaGFzIGEgYnVuY2ggb2Ygb3ZlcmhlYWQgYXNzb2NpYXRlZCB3aXRoIGl0Lg0K DQpJdCBhbGwgZGVwZW5kcyBvbiBob3cgbXVjaCB5b3Ugd2FudCB0byBzcGVuZCB0byBhdm9pZCBz dGFsbGluZyBpbiB0aGUNCmNhc2Ugb2YgcGFja2V0IGxvc3MuICBJIGNhbiBpbWFnaW5lIHVzaW5n IGRpZmZlcmVudCBzdHJhdGVnaWVzIGJhc2VkDQpvbiBvYnNlcnZlZCBwYWNrZXQgbG9zcywgYnV0 IHRoZW4gSSBjYW4gYWxzbyBpbWFnaW5lIGZseWluZyBjYXJzIGFuZA0Kd2UgYWxsIGtub3cgaG93 IGNvbW1vbiB0aG9zZSBhcmUuDQoNClllYS4gIEkgY2FuIGltYWdpbmUgdGhhdCB0aGUgdHJhZGUt b2ZmcyBtYXkgcGxheSBvdXQgZGlmZmVyZW50bHkgZm9yIHJlcXVlc3RzIHZzIHJlc3BvbnNlcy4N Cg0KQ29uc2lkZXJpbmcgdGhlIE8oMTAwKSByZXF1ZXN0cyBleGFtcGxlIFBhdHJpY2sgbWVudGlv bmVkLg0KDQpUaGVyZSBjb3VsZCBiZSBhIHZlcnkgZ29vZCBjaGFuY2UgdGhhdCBhZnRlciBjb21w cmVzc2lvbiBtYW55IHBhY2tldHMgY29udGFpbiBoZWFkZXJzIGZyb20gc2V2ZXJhbCBkaXN0aW5j dCByZXF1ZXN0cy4gICBUaGUgc3Vic2V0IG9mIHJlcXVlc3RzIHBhY2tlZCBpbnRvIGEgY29tbW9u IHBhY2tldCBub3cgc2hhcmUgZmF0ZSwgc28gbm8gcG9pbnQgZ2l2aW5nIHVwIGNvbXByZXNzaW9u IGVmZmljaWVuY3kgYnkgY29kaW5nIHRoZW0gaW5kZXBlbmRlbnRseSBvZiBlYWNoIG90aGVyLiAg ICppZiogaXQgd2VyZSB0aGUgY2FzZSB0aGF0IGFsbCB0aGUgcmVxdWVzdHMgZml0IGludG8gYSBz aW5nbGUgcGFja2V0LCB0aGVuIGNsZWFybHkgYW55IEhvTCBhdm9pZGFuY2Ugd291bGQgYmUgc3Ry aWN0bHkgbG9zaW5nIHRhY3RpYy4NCg0KSW4gdGhlIHJlc3BvbnNlIGRpcmVjdGlvbiBpdCBpcyBx dWl0ZSBkaWZmZXJlbnQuICBTdXBwb3NlIHRoZSByZXF1ZXN0IHdlcmUgZm9yIGltYWdlcywgc3Vj aCB0aGF0IHRoZSBib2RpZXMgd2VyZSBhbGwgb25lIG9yIG1vcmUgcGFja2V0cyBsYXJnZS4gICAg SWYgdGhlIGJvZGllcyB3ZXJlIGNvbnNpc3RlbnRseSB3cml0dGVuIGFsb25nIHdpdGggdGhlIGNv cnJlc3BvbmRpbmcgcmVzcG9uc2UgaGVhZGVycywgdGhlIGNoYW5jZSBvZiB0d28gcmVzcG9uc2Ug aGVhZGVycyBzaGFyaW5nIGZhdGUgKGJ5IHZpcnR1ZSBvZiBzZXJpYWxpemluZyBpbnRvIHRoZSBz YW1lIHBhY2tldCkgbWF5IGJlIGVmZmVjdGl2ZWx5IHplcm8uICAgICBJbiB0aGF0IGNhc2UsIGhh dmluZyB0aGUgcmVzcG9uc2UgaGVhZGVycyBlbmNvZGVkIGluZGVwZW5kZW50IG9mIGVhY2ggb3Ro ZXIgY291bGQgYmUgcXVpdGUgdmFsdWFibGUgKHN0aWxsIG1vZHVsbyBjb21wcmVzc2lvbiBlZmZp Y2llbmN5KS4NCg0KV2UgY2xlYXJseSBuZWVkIHNvbWUgbWVhc3VyZW1lbnRzLi4uDQoNCi0tDQpD aGFybGVzICdCdWNrJyBLcmFzaWMgfCBTb2Z0d2FyZSBFbmdpbmVlciB8IGNrcmFzaWNAZ29vZ2xl LmNvbTxtYWlsdG86Y2tyYXNpY0Bnb29nbGUuY29tPiB8ICsxICg0MDgpIDQxMi0xMTQxDQoNCg== --_000_BN6PR03MB2708F0211875A14F5CAFE7E187580BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFuIC0wMiB2ZXJzaW9uIG9mIHRoZSBRUEFDSyBkcmFmdCBi YXNlZCBvbiB0aGUgc3BsaXQgbW9kZWwgYW5kIHRoZSBkaXNjdXNzaW9uIGZyb20gdGhpcyB0aHJl YWQgY2FuIGJlIGZvdW5kIGF0ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1iaXNob3AtcXVpYy1odHRwLWFuZC1xcGFjay0wMiI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWJpc2hvcC1xdWljLWh0dHAtYW5kLXFwYWNrLTAyPC9hPi48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFBhdHJpY2sg TWNNYW51cyBbbWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+ IFR1ZXNkYXksIEphbnVhcnkgMzEsIDIwMTcgMTA6MjkgUE08YnI+DQo8Yj5Ubzo8L2I+IENoYXJs ZXMgJ0J1Y2snIEtyYXNpYyAmbHQ7Y2tyYXNpY0Bnb29nbGUuY29tJmd0Ozxicj4NCjxiPkNjOjwv Yj4gTWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs7IE1pa2Ug QmlzaG9wICZsdDtNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tJmd0OzsgSUVURiBRVUlDIFdH ICZsdDtxdWljQGlldGYub3JnJmd0OzsgS2F6dWhvIE9rdSAmbHQ7a2F6dWhvb2t1QGdtYWlsLmNv bSZndDs7IFJ5YW4gSGFtaWx0b24gJmx0O3JjaEBnb29nbGUuY29tJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBSZTogU3BsaXR0aW5nIFFQQUNLPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPm9yIHRv IHB1dCBpdCBhbm90aGVyIHJlbGF0ZWQgd2F5IC0gdGhlIHZhbHVlIG9mIGhwYWNrIGhhcyBhbHdh eXMgYmVlbiBpbiBhdm9pZGluZyBjd25kIHN0YWxscy4gcXVpYyBicmVha3MgZG93biB0aGUgb2xk IGFic3RyYWN0aW9ucyBhbmQgYW4gZW5jb2RlciBjYW4gY2VydGFpbmx5IGJldHRlciB0YWtlIGlu dG8gYWNjb3VudCBjd25kLCB0aGUgYW1vdW50IG9mDQogZGF0YSBpdCB0aGlua3MgaXQgd2lsbCBi ZSBzZW5kaW5nLCBhbmQgaG93IGl0IHdhbnRzIHRvIGNvbWJpbmUgZnJhbWVzIGluIHBhY2tldHMu IHRoYXQncyBwcmV0dHkgcG93ZXJmdWwgaW4gYmFsYW5jaW5nIHRoZSB0cmFkZW9mZnMgaGVyZS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij5vZmYgaGFuZCBpdCBzZWVtcyBjbGllbnRzIGRvaW5nIHRoZSBvKDEw MCkgdGhpbmcgd291bGQgYmUgaGlnaGx5IGluY2VudGVkIGVhcmx5IG9uLCBidXQgbGF0ZXIgbWln aHQgbm90IG5lZWQgdG8gYWNjb21tb2RhdGUgc3VjaCBidXJzdHMgYW5kIHdvdWxkIHVzZSBkaWZm ZXJlbnQgc3RyYXRlZ2llcy4uIHNpbWlsYXJseSBzZXJ2ZXJzIG1pZ2h0IG9ubHkgdXNlIGNvbXBy ZXNzaW9uDQogcmFyZWx5LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPmJleW9uZCB0byBjb21wcmVzcyBvciBu b3QsIGRpZmZlcmVudCBjaG9pY2VzIG1pZ2h0IGJlIG1hZGUgaW4gaG93IHRpZ2h0bHkgZWFjaCBw YWNrZXQgaXMgc3R1ZmZlZCBhZ2FpbiBiYXNlZCBvbiBjd25kLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBGZWIgMSwgMjAxNyBhdCAxOjIzIEFN LCBDaGFybGVzICdCdWNrJyBLcmFzaWMgJmx0OzxhIGhyZWY9Im1haWx0bzpja3Jhc2ljQGdvb2ds ZS5jb20iIHRhcmdldD0iX2JsYW5rIj5ja3Jhc2ljQGdvb2dsZS5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBUdWUsIEphbiAzMSwgMjAxNyBhdCAzOjI4IFBNLCBNYXJ0aW4gVGhvbXNvbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1h cnRpbi50aG9tc29uQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJs b2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4w cHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmln aHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDEgRmVicnVhcnkgMjAxNyBhdCAxMDow NiwgQ2hhcmxlcyAnQnVjaycgS3Jhc2ljICZsdDs8YSBocmVmPSJtYWlsdG86Y2tyYXNpY0Bnb29n bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+Y2tyYXNpY0Bnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6 PGJyPg0KJmd0OyBPayBJIGdldCBpdCBub3cuJm5ic3A7IEZvciB0aGUgaGVhZGVyIHRoYXQgY2F1 c2VzIGEgdGFibGUgaW5zZXJ0LCBpdCB3b3VsZCBiZTxicj4NCiZndDsgaWxsLWFkdmlzZWQgdG8g dXNlIGEgaHBhY2sgbGl0ZXJhbCBvbiB0aGUgaGVhZGVycyBzdHJlYW0uJm5ic3A7ICZuYnNwO1Ro ZXJlJ3Mgbm8gcG9pbnQ8YnI+DQomZ3Q7IGd1YXJkaW5nIEhvTCBibG9ja2luZyBhbW9uZyB0aGlu Z3MgdGhhdCB0aGF0IHdpbGwgZW5kIHVwIGluIHRoZSBzYW1lIHBhY2tldDxicj4NCiZndDsgYW55 d2F5Ljxicj4NCjxicj4NClRoZSBoYXphcmQgaXMgd2hlcmUgeW91IGhhdmUgbXVsdGlwbGUgY29u Y3VycmVudCB1c2VzIGluIHNob3J0IG9yZGVyLjxicj4NCklmIHBhY2tldGl6YXRpb24gY2F1c2Vz IHRoZSBpbnNlcnQgYW5kIHRoZSByZWZlcmVuY2UgdG8gYXBwZWFyIGluPGJyPg0KZGlmZmVyZW50 IHBhY2tldHMsIHlvdSBoYXZlIGEgSE9MQiBleHBvc3VyZS48YnI+DQo8YnI+DQpBcyBNaWtlIG9i c2VydmVzLCB0aGUgb2RkcyBvZiBoYXZpbmcgYSByZWZlcmVuY2UgdGhhdCBjYXVzZXMgYW4gaW5z ZXJ0PGJyPg0Kc3BsaXQgYmV0d2VlbiB0d28gcGFja2V0cyBpcyBsb3cuJm5ic3A7IFdlbGwsIGRl cGVuZGluZyBvbiBob3cgeW91PGJyPg0KY29uc3RydWN0IHBhY2tldHMuJm5ic3A7IFlvdSBjYW4g bWluaW1pemUgdGhpcyBieSBnZW5lcmF0aW5nIGludGVybGVhdmVkPGJyPg0KU1RSRUFNIGZyYW1l cywgYnV0IHRoYXQgaGFzIGEgYnVuY2ggb2Ygb3ZlcmhlYWQgYXNzb2NpYXRlZCB3aXRoIGl0Ljxi cj4NCjxicj4NCkl0IGFsbCBkZXBlbmRzIG9uIGhvdyBtdWNoIHlvdSB3YW50IHRvIHNwZW5kIHRv IGF2b2lkIHN0YWxsaW5nIGluIHRoZTxicj4NCmNhc2Ugb2YgcGFja2V0IGxvc3MuJm5ic3A7IEkg Y2FuIGltYWdpbmUgdXNpbmcgZGlmZmVyZW50IHN0cmF0ZWdpZXMgYmFzZWQ8YnI+DQpvbiBvYnNl cnZlZCBwYWNrZXQgbG9zcywgYnV0IHRoZW4gSSBjYW4gYWxzbyBpbWFnaW5lIGZseWluZyBjYXJz IGFuZDxicj4NCndlIGFsbCBrbm93IGhvdyBjb21tb24gdGhvc2UgYXJlLjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlllYS4mbmJzcDsgSSBjYW4gaW1hZ2luZSB0aGF0IHRoZSB0cmFkZS1vZmZzIG1heSBw bGF5IG91dCBkaWZmZXJlbnRseSBmb3IgcmVxdWVzdHMgdnMgcmVzcG9uc2VzLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db25zaWRlcmluZyB0 aGUgTygxMDApIDxpPnJlcXVlc3RzPC9pPiBleGFtcGxlIFBhdHJpY2sgbWVudGlvbmVkLiAmbmJz cDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoZXJlIGNvdWxkIGJlIGEgdmVyeSBnb29kIGNoYW5jZSB0aGF0IGFmdGVyIGNvbXBy ZXNzaW9uIG1hbnkgcGFja2V0cyBjb250YWluIGhlYWRlcnMgZnJvbSBzZXZlcmFsIGRpc3RpbmN0 IHJlcXVlc3RzLiAmbmJzcDsgVGhlIHN1YnNldCBvZiByZXF1ZXN0cyBwYWNrZWQgaW50byBhIGNv bW1vbiBwYWNrZXQgbm93IHNoYXJlIGZhdGUsIHNvIG5vIHBvaW50IGdpdmluZyB1cCBjb21wcmVz c2lvbiBlZmZpY2llbmN5IGJ5IGNvZGluZw0KIHRoZW0gaW5kZXBlbmRlbnRseSBvZiBlYWNoIG90 aGVyLiAmbmJzcDsgKmlmKiBpdCB3ZXJlIHRoZSBjYXNlIHRoYXQgYWxsIHRoZSByZXF1ZXN0cyBm aXQgaW50byBhIHNpbmdsZSBwYWNrZXQsIHRoZW4gY2xlYXJseSBhbnkgSG9MIGF2b2lkYW5jZSB3 b3VsZCBiZSBzdHJpY3RseSBsb3NpbmcgdGFjdGljLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiB0aGUgPGk+cmVzcG9uc2U8L2k+IGRpcmVj dGlvbiBpdCBpcyBxdWl0ZSBkaWZmZXJlbnQuJm5ic3A7IFN1cHBvc2UgdGhlIHJlcXVlc3Qgd2Vy ZSBmb3IgaW1hZ2VzLCBzdWNoIHRoYXQgdGhlIGJvZGllcyB3ZXJlIGFsbCBvbmUgb3IgbW9yZSBw YWNrZXRzIGxhcmdlLiAmbmJzcDsgJm5ic3A7SWYgdGhlIGJvZGllcyB3ZXJlIGNvbnNpc3RlbnRs eSB3cml0dGVuIGFsb25nIHdpdGggdGhlIGNvcnJlc3BvbmRpbmcgcmVzcG9uc2UgaGVhZGVycywN CiB0aGUgY2hhbmNlIG9mIHR3byByZXNwb25zZSBoZWFkZXJzIHNoYXJpbmcgZmF0ZSAoYnkgdmly dHVlIG9mIHNlcmlhbGl6aW5nIGludG8gdGhlIHNhbWUgcGFja2V0KSBtYXkgYmUgZWZmZWN0aXZl bHkgemVyby4gJm5ic3A7ICZuYnNwOyBJbiB0aGF0IGNhc2UsIGhhdmluZyB0aGUgcmVzcG9uc2Ug aGVhZGVycyBlbmNvZGVkIGluZGVwZW5kZW50IG9mIGVhY2ggb3RoZXIgY291bGQgYmUgcXVpdGUg dmFsdWFibGUgKHN0aWxsIG1vZHVsbyBjb21wcmVzc2lvbiBlZmZpY2llbmN5KS48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XZSBj bGVhcmx5IG5lZWQgc29tZSBtZWFzdXJlbWVudHMuLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9y ZGVyOnNvbGlkICNENTBGMjUgMS41cHQ7cGFkZGluZzoyLjBwdCI+Q2hhcmxlcyAnQnVjaycgS3Jh c2ljJm5ic3A7fDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojNTU1NTU1O2JvcmRlcjpzb2xpZCAjMzM2OUU4IDEuNXB0O3Bh ZGRpbmc6Mi4wcHQiPiZuYnNwO1NvZnR3YXJlDQogRW5naW5lZXImbmJzcDt8PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1 NTU1NTU7Ym9yZGVyOnNvbGlkICMwMDk5MzkgMS41cHQ7cGFkZGluZzoyLjBwdCI+Jm5ic3A7PGEg aHJlZj0ibWFpbHRvOmNrcmFzaWNAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmNrcmFzaWNA Z29vZ2xlLmNvbTwvYT4mbmJzcDt8PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM1NTU1NTU7Ym9yZGVyOnNvbGlkICNFRUIy MTEgMS41cHQ7cGFkZGluZzoyLjBwdCI+Jm5ic3A7JiM0MzsxDQogKDQwOCkgNDEyLTExNDE8L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB2708F0211875A14F5CAFE7E187580BN6PR03MB2708namp_-- From nobody Tue Feb 14 23:05:22 2017 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 B396B129AD3 for ; Tue, 14 Feb 2017 23:05:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 HL8Flsbpt8Xp for ; Tue, 14 Feb 2017 23:05:19 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 6BB52129ACD for ; Tue, 14 Feb 2017 23:05:17 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id y9so101130832uae.2 for ; Tue, 14 Feb 2017 23:05:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=wjsjh5CWE1H7h1n7f1JqxzbhOE2KUx0cWodJ6+Dzsik=; b=fPWA3hRfyUeoC7mlKK3AvPccaNhcomj1In4Zo0HFNJXkj7tXPAoKEmfWFM7M2sPazw gi8zmlaEMTeeKoFrC5Qe8flL3zH03K2SaBInZb1enwEacWGGnC3IxXkCp1iph3xpiY+j N8WaIhZjvzobYtkAhf0i5lZtFuBJP2E8XZJw8UPYoV5Eq6JbxNskByOdiNTrvblRxloF gifNpN6VTrAZ6A10j+Yrytxf3RXEFbs11bN2QXqtGOPQkp4t2liVtU81zi8Cuah/4rta W2Pst63ji5jbwrNmIX5DGRU2fZutuFYYsf7zYVazAZpx3u1A8ztEYXBdCbTGeCfZSaYn Jerw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=wjsjh5CWE1H7h1n7f1JqxzbhOE2KUx0cWodJ6+Dzsik=; b=bf5LYFj+SFTUxFmHUWkF22EGxFLrBdPG8E+KMtx5mfecT6GO38/mrWZnL/bmbhN2Q/ R/pp+fBHKOaJhBlEGxa1Z/6jYfr4LQbDe7QuquU8sfWLdmExhXKSWsiITp48l5GvTK4+ 4kdx/Nq9td4sqLoP8QTmrxOyw+aepMu29LuXqwL+a9Y12T6FOZ9nOp/pNQWSetctUVeQ PPIHwgB/1dL2LEcq62CkGhu/7U98/U7tPjwlsfMNeDKzxxDPNgn9D84z4WYLLijI9zMu HT5+kXhNUSmGTEjrvEgRvA+bk8dBVEx6M0T/RJZJWnGJvgsMGESK+t7G+gG5rG0bU5wB x3WQ== X-Gm-Message-State: AMke39m2rOqgTC2zA5uqAbVlZ0O9NIPYsgfhIkzHRNSYBrUVFYFb6TeFt53IMpXQRP+2Zm5Knc0eaFGX5A7Vg0rx X-Received: by 10.159.40.201 with SMTP id d67mr17179543uad.98.1487142315813; Tue, 14 Feb 2017 23:05:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Tue, 14 Feb 2017 23:05:15 -0800 (PST) From: Jana Iyengar Date: Tue, 14 Feb 2017 23:05:15 -0800 Message-ID: Subject: Alternate header proposal To: IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c123f1677430005488c4d2b Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 07:05:21 -0000 --94eb2c123f1677430005488c4d2b Content-Type: text/plain; charset=UTF-8 After discussion with various folks, I have put together an alternate proposal for packet header organization, described below (also on github here .) This borrows the long/short header idea from Martin's formulation, but turns the flags field into a type byte, with only 18 codepoints defined. This proposal eliminates the need for an explicit magic field, and uses packet types for directionality of cleartext packets. Hope this makes sense, and happy to discuss modifications to this format. Details can of course be changed, but I'm quite liking the use of a 1-byte codepoint instead of bits for various fields. ------------------- QUIC packet headers can be separated into long form and short form headers. Long form headers are used for version negotiation, connection establishment, and public reset packets. Short form headers are version-specific, and are used for 1-RTT packets, minimizing their header size. While all packets are identified using the same Type octet, headers are separated into the two categories for two reasons: (i) short form headers are only used after version negotiation and establishment of 1-RTT keys, and (ii) editorial convenience. This formulation eschews specific bits indicating the presence of various fields in favor of an octet indicating one of 256 packet types. Of these 256 types, this version defines and uses only 18: 6 with long-form headers for the initial phase of the connection, and 12 with short-form headers for after the version negotiation and 1-RTT keys are established. # Long-Form Headers ``` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number / Proof | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` These long-form headers are used for anything that doesn't have 1-RTT packet protection and prior to the completion of version negotiation. Once both conditions are met, a sender may switch to sending short-form headers. While inefficient, long headers may also be used for 1-RTT packets. The long form allows for special packets, such as the version negotiation and the public reset packets to be represented in this uniform fixed-length packet format. * Octet 0: Packet Type * 39: Version Negotiation packet * 3a: Public Reset packet * 3d: 0-RTT packet * 3e: Server cleartext packet * 3f: Client cleartext packet * 1c: 1-RTT packet with version field, connection ID, and 2-byte packet number The remainder of the packet layout is the same regardless of type, the difference being what rules for how to fill the values out and their semantics. A client cleartext packet (type = 0x3c) then contains: * Octets 1-8: connection ID (initially randomly chosen) * Octets 9-12: version * Octets 13-16: packet number (low 4 octets, starts at a random 31-bit value) * Octets 17+: payload The client MUST choose a random value and use it as the Connection ID until the server replies with a server-selected connection ID. The client's connection ID would have no semantic value, though they might serve to provide proof that the server received the packet via echoing, see below. A server cleartext packet (type = 0x3e) contains: * Octets 1-8: connection ID (server-selected value) * Octets 9-12: version (echoed) * Octets 13-16: packet number (low 4 octets, random 31-bit initial value) * Octets 17+: payload Both 0-RTT and 1-RTT packets with long-form headers contain: * Octets 1-8: connection ID (server-selected value) * Octets 9-12: version * Octets 13-16: packet number (low 4 octets) * Octets 17+: payload A version negotiation packet contains: * Octets 1-8: connection ID (server-selected value, may be used in a subsequent connection to reach the same server) * Octets 9-12: version (echoed) * Octets 13-16: proof (first 4 octets of client-selected connection ID) * Octets 17+: payload = version list A public reset packet is sent when the server has no state for a received packet. A server may therefore have to respond to either a long-form or a short-form packet. A public reset packet contains: * Octets 1-8: connection ID (server-selected value) * Octets 9-12: version * Octets 13-16: proof (octets 1-5 of received packet) Echoing details from the packet in both version negotiation and public reset provides return routeability (#244), while maintaining a consistent header shape for all packets. # Short Form Header ``` 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+ | Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID (optional) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (1/2/4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ``` The short form header is used after the version and 1-RTT keys are negotiated. The short form header is defined to be specific to a version. In this version, bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, resulting in the following packet types. * Octet 0: Packet Type * 04 and 84: 1-RTT packet (packet number size = 1) * 14 and 94: 1-RTT packet (packet number size = 2) * 34 and b4: 1-RTT packet (packet number size = 4) * 0c and 8c: 1-RTT packet with Connection ID (packet number size = 1) * 1c and 9c: 1-RTT packet with Connection ID (packet number size = 2) * 3c and bc: 1-RTT packet with Connection ID (packet number size = 4) --94eb2c123f1677430005488c4d2b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
After discussion with various folks, I have put together a= n alternate proposal for packet header organization, described below (also = on github=C2=A0here.) This borrows the long/short header idea fro= m Martin's formulation, but turns the flags field into a type byte, wit= h only 18 codepoints defined. This proposal eliminates the need for an expl= icit magic field, and uses packet types for directionality of cleartext pac= kets.

Hope this makes sense, and happy to discuss modifi= cations to this format. Details can of course be changed, but I'm quite= liking the use of a 1-byte codepoint instead of bits for various fields.

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

Q= UIC packet headers can be separated into long form and short form headers.<= /div>
Long form headers are used for version negotiation, connection es= tablishment,=C2=A0
and public reset packets. Short form headers a= re version-specific, and are used
for 1-RTT packets, minimizing t= heir header size.

While all packets are identified= using the same Type octet, headers are=C2=A0
separated into the = two categories for two reasons: (i) short form headers are=C2=A0
= only used after version negotiation and establishment of 1-RTT keys, and=C2= =A0
(ii) editorial convenience.

This for= mulation eschews specific bits indicating the presence of=C2=A0
v= arious fields in favor of an octet indicating one of 256 packet types.=C2= =A0
Of these 256 types, this version defines and uses only 18: 6 = with long-form=C2=A0
headers for the initial phase of the connect= ion, and 12 with short-form headers
for after the version negotia= tion and 1-RTT keys are established.


# Long-Form Headers

```
=C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3<= /font>
=C2=A00 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| =C2=A0 =C2=A0 Type =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
| =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= + =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Connection ID =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0+
| =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Version =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Packet= Number / Proof =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Pa= yload =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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

These long-form headers are used fo= r anything that doesn't have 1-RTT packet
protection and prio= r to the completion of version negotiation. Once both
conditions = are met, a sender may switch to sending short-form headers.
While= inefficient, long headers may also be used for 1-RTT packets. The long=C2= =A0
form allows for special packets, such as the version negotiat= ion and the public
reset packets to be represented in this unifor= m fixed-length packet format.

* Octet 0: Packet Ty= pe
=C2=A0 * 39: Version Negotiation packet
=C2=A0 * 3a:= Public Reset packet
=C2=A0 * 3d: 0-RTT packet
=C2=A0 *= 3e: Server cleartext packet
=C2=A0 * 3f: Client cleartext packet=
=C2=A0 * 1c: 1-RTT packet with version field, connection ID,=C2= =A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and 2-byte packet number

The remainder of the packet layout is the same regardless = of type, the
difference being what rules for how to fill the valu= es out and their semantics.

A client cleartext pac= ket (type =3D 0x3c) then contains:
* Octets 1-8: connection ID (i= nitially randomly chosen)
* Octets 9-12: version
* Octe= ts 13-16: packet number (low 4 octets, starts at a random 31-bit value)
* Octets 17+: payload

The client MUST choos= e a random value and use it as the Connection ID until the=C2=A0
= server replies with a server-selected connection ID. The client's conne= ction ID
would have no semantic value, though they might serve to= provide proof that=C2=A0
the server received the packet via echo= ing, see below.

A server cleartext packet (type = =3D 0x3e) contains:
* Octets 1-8: connection ID (server-selected = value)
* Octets 9-12: version (echoed)
* Octets 13-16: = packet number (low 4 octets, random 31-bit initial value)
* Octet= s 17+: payload

Both 0-RTT and 1-RTT packets with l= ong-form headers contain:
* Octets 1-8: connection ID (server-sel= ected value)
* Octets 9-12: version
* Octets 13-16: pac= ket number (low 4 octets)
* Octets 17+: payload

A version negotiation packet contains:
* Octets 1-8: conn= ection ID (server-selected value, may be used in a subsequent=C2=A0
=C2=A0 connection to reach the same server)
* Octets 9-12: ver= sion (echoed)
* Octets 13-16: proof (first 4 octets of client-sel= ected connection ID)
* Octets 17+: payload =3D version list
=

A public reset packet is sent when the server has no st= ate for a received
packet. A server may therefore have to respond= to either a long-form or a=C2=A0
short-form packet. A public res= et packet contains:
* Octets 1-8: connection ID (server-selected = value)
* Octets 9-12: version
* Octets 13-16: proof (oc= tets 1-5 of received packet)

Echoing details from = the packet in both version negotiation and public reset=C2=A0
pro= vides return routeability (#244), while maintaining a consistent header=C2= =A0
shape for all packets.


# Short Form Header

```
=C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3<= /font>
=C2=A00 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
| =C2=A0 =C2=A0 =C2=A0Type =C2=A0 =C2=A0 | =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+
| =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 Connection ID (optional) =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =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 Packet Number (1/2/4) =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Payload =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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
```

The short form header is used after the version and 1-RTT keys are ne= gotiated.
The short form header is defined to be specific to a ve= rsion. In this version,=C2=A0
bit 0 of the first octet (i.e., 0x8= 0) is used as the key phase bit, resulting=C2=A0
in the following= packet types.
* Octet 0: Packet Type
=C2=A0 * 04 and 8= 4: 1-RTT packet (packet number size =3D 1)
=C2=A0 * 14 and 94: 1-= RTT packet (packet number size =3D 2)
=C2=A0 * 34 and b4: 1-RTT p= acket (packet number size =3D 4)
=C2=A0 * 0c and 8c: 1-RTT packet= with Connection ID (packet number size =3D 1)
=C2=A0 * 1c and 9c= : 1-RTT packet with Connection ID (packet number size =3D 2)
=C2= =A0 * 3c and bc: 1-RTT packet with Connection ID (packet number size =3D 4)=

--94eb2c123f1677430005488c4d2b-- From nobody Wed Feb 15 00:43:48 2017 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 4711B1294F7 for ; Wed, 15 Feb 2017 00:43:48 -0800 (PST) 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 RVdqVw9nBgLO for ; Wed, 15 Feb 2017 00:43:47 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::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 060A81294EF for ; Wed, 15 Feb 2017 00:43:47 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id k15so131901260qtg.3 for ; Wed, 15 Feb 2017 00:43:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UpAUutAL5MY4nKAulKj19ToL/xSlTjITFUy2y0qt2Z8=; b=nJzvZGvxAy1tbKzkaziY9tIQmYQBSFB2or7wrrcVNqjh75VrEH5ZeJhrO84YNlTMiX fB3ReNZ1aeEQIQwPJLfhvMSi2yfodPWh77CoNlVowQPP4JogTiMYNg3+LlmbxsbF6zl1 IbjmBJdgx7FxoGBdfLYBhJcI1MV9YkD6zc+sjCnWg68GSjeqqTDZ1d2eU0PKxla7QxLB sY692hkLy72vSzIPhUa8R0mansqWP195yvw5pf6vXAMF6+7cuGBKjeauABTn+P5cv8MS NqYNkImngQYaBPvomfEV4/GFL9VBO0Cxe/7v5Y/v1oQllgDYpUNfR9iyGEWeuKRzOc+L Dd+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UpAUutAL5MY4nKAulKj19ToL/xSlTjITFUy2y0qt2Z8=; b=AsGXrwRyyPWdbX7Mi5e40Lfcy84ShtbFeWWnWE2sS1cLam2cOlUFlArDl37osTfzC9 GgDjPUq+O1Xbgd9ENMp90jflx9hc0hB4swu7WNcKcpGiwnyjxENzwXCja5JkbFAUQ0f4 AlxZEPYzFia5L/qC+kwxiwvl5iaeHTybZ9g+ZCvMgcBkireW7qFclP3DawMKjPbOh8nb mbrG0H2Ku7dcRHTVDvX9h4us5mb9lP0vkZhX9N2Qj+uH07ZOZ4LiXLw/sVl3qav7o6Re BzeHxd/a/t+ub/FQpd/2DXAmSjzuo0KW7oYrnU/J06XJDVAE74HyniBRHtbxD2JISJJV goFw== X-Gm-Message-State: AMke39nSc32Pk2S6cXCGB/drEHqwRi+wWfAmHsHMxiVL8RNaVl086cwXaagdltz9aaZp95b0NAOshknYRk9YwQ== X-Received: by 10.200.53.247 with SMTP id l52mr31484992qtb.144.1487148226119; Wed, 15 Feb 2017 00:43:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 00:43:45 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 15 Feb 2017 19:43:45 +1100 Message-ID: Subject: Re: Alternate header proposal To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 08:43:48 -0000 I like this general approach. I would prefer if the packet number were in the same place in both forms (that seems easy enough to do by moving the version). Then we get a contiguous proof block (connection ID + packet number) for a public reset. I note that you can use 0x08 to check if the packet is long or short. We should try to keep that property until we can't any more. I'm OK with the server proposing a new connection ID on a version negotiation packet (though not yet 100% confident that it's the right answer), but it doesn't make any sense to propose a new connection ID on a public reset. Echoing the client value is a chance to provide stronger proof that it saw the packet it is reacting to. On 15 February 2017 at 18:05, Jana Iyengar wrote: > * 04 and 84: 1-RTT packet (packet number size = 1) > * 14 and 94: 1-RTT packet (packet number size = 2) > * 34 and b4: 1-RTT packet (packet number size = 4) I don't think that we need these. I haven't seen any reason why connection ID can't be negotiated off during the handshake (if that even makes sense), reducing your 18 types to 12. I'm not sure why you have 1c mentioned in two places. Was your intent to define a long-form packet that can carry 1-RTT? Because you need to explicitly mark it as long-form in that case or we'll have some confusion about whether version is present or not. (Note that you need two 1-RTT long-form packets to deal with key changes.) From nobody Wed Feb 15 01:14:42 2017 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 1773D12940E for ; Wed, 15 Feb 2017 01:14:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PoAn35Rhljpc for ; Wed, 15 Feb 2017 01:14:38 -0800 (PST) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 74A0B128AC9 for ; Wed, 15 Feb 2017 01:14:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3vNYWx0jMvz15M8y; Wed, 15 Feb 2017 10:14:37 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUXnss8lGHA0; Wed, 15 Feb 2017 10:14:35 +0100 (CET) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 15 Feb 2017 10:14:35 +0100 (CET) Subject: Re: Alternate header proposal To: Jana Iyengar , IETF QUIC WG References: From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: Date: Wed, 15 Feb 2017 10:14:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 09:14:41 -0000 Hi Jana, hi all, in general I like the idea of short and long packets because optimizing header bits really only make a lot of sense if this space can be used for payload bits instead. However, couple of comments: 1) I'd say that having undefined codepoints enables actually the kind of extensibility (beside versioning) that you've been arguing against previously. I don't think that this a bad thing because it's under endpoint control, however, having codepoints instead of bits with a special meaning actually makes it harder to deploy. If the endpoint sees an unknown codepoint, it can only drop the packet completely (it doesn't even know where the payload starts), while with an dedicated bit that declares a certain space to be used for additional information that can always be ignored. In summary, I think your proposal needs a header length field, but still I prefer the flags field because it's less complex. 2) Further effectively as Martin basically pointed out in his follow-up mail, you still have one bit that indicates the short or long header. I think that's good and we should maintain this but in that case we should also call this bit out like this because that's easier to understand for humans (who need to implement this). 3) I still don't really understand the need for different sizes of the packet number field, especially I don't understand why we have 3 different values. I assume you mainly try to save bits in a data center scenario, right? But in this case you could even run your own version of quic where the only difference is that you always have a shorter packet number. 4) And finally, I think it would be safer to have the connection ID on all packets. But maybe we can just use a shorter connection ID? What's the reason for a 64 bits connection ID again? Also if we allow for packets without the connection ID, that's probably something the server should tell the client because the server might know if that's needed for some kind of load balancing setup at server side or not. Mirja On 15.02.2017 08:05, Jana Iyengar wrote: > After discussion with various folks, I have put together an alternate > proposal for packet header organization, described below (also on github here > .) This > borrows the long/short header idea from Martin's formulation, but turns the > flags field into a type byte, with only 18 codepoints defined. This proposal > eliminates the need for an explicit magic field, and uses packet types for > directionality of cleartext packets. > > Hope this makes sense, and happy to discuss modifications to this format. > Details can of course be changed, but I'm quite liking the use of a 1-byte > codepoint instead of bits for various fields. > > ------------------- > > QUIC packet headers can be separated into long form and short form headers. > Long form headers are used for version negotiation, connection establishment, > and public reset packets. Short form headers are version-specific, and are used > for 1-RTT packets, minimizing their header size. > > While all packets are identified using the same Type octet, headers are > separated into the two categories for two reasons: (i) short form headers are > only used after version negotiation and establishment of 1-RTT keys, and > (ii) editorial convenience. > > This formulation eschews specific bits indicating the presence of > various fields in favor of an octet indicating one of 256 packet types. > Of these 256 types, this version defines and uses only 18: 6 with long-form > headers for the initial phase of the connection, and 12 with short-form headers > for after the version negotiation and 1-RTT keys are established. > > > # Long-Form Headers > > ``` > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Connection ID + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number / Proof | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ``` > > These long-form headers are used for anything that doesn't have 1-RTT packet > protection and prior to the completion of version negotiation. Once both > conditions are met, a sender may switch to sending short-form headers. > While inefficient, long headers may also be used for 1-RTT packets. The long > form allows for special packets, such as the version negotiation and the public > reset packets to be represented in this uniform fixed-length packet format. > > * Octet 0: Packet Type > * 39: Version Negotiation packet > * 3a: Public Reset packet > * 3d: 0-RTT packet > * 3e: Server cleartext packet > * 3f: Client cleartext packet > * 1c: 1-RTT packet with version field, connection ID, > and 2-byte packet number > > The remainder of the packet layout is the same regardless of type, the > difference being what rules for how to fill the values out and their semantics. > > A client cleartext packet (type = 0x3c) then contains: > * Octets 1-8: connection ID (initially randomly chosen) > * Octets 9-12: version > * Octets 13-16: packet number (low 4 octets, starts at a random 31-bit value) > * Octets 17+: payload > > The client MUST choose a random value and use it as the Connection ID until the > server replies with a server-selected connection ID. The client's connection ID > would have no semantic value, though they might serve to provide proof that > the server received the packet via echoing, see below. > > A server cleartext packet (type = 0x3e) contains: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version (echoed) > * Octets 13-16: packet number (low 4 octets, random 31-bit initial value) > * Octets 17+: payload > > Both 0-RTT and 1-RTT packets with long-form headers contain: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version > * Octets 13-16: packet number (low 4 octets) > * Octets 17+: payload > > A version negotiation packet contains: > * Octets 1-8: connection ID (server-selected value, may be used in a subsequent > connection to reach the same server) > * Octets 9-12: version (echoed) > * Octets 13-16: proof (first 4 octets of client-selected connection ID) > * Octets 17+: payload = version list > > A public reset packet is sent when the server has no state for a received > packet. A server may therefore have to respond to either a long-form or a > short-form packet. A public reset packet contains: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version > * Octets 13-16: proof (octets 1-5 of received packet) > > Echoing details from the packet in both version negotiation and public reset > provides return routeability (#244), while maintaining a consistent header > shape for all packets. > > > # Short Form Header > > ``` > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Connection ID (optional) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number (1/2/4) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ``` > > The short form header is used after the version and 1-RTT keys are negotiated. > The short form header is defined to be specific to a version. In this version, > bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, resulting > in the following packet types. > * Octet 0: Packet Type > * 04 and 84: 1-RTT packet (packet number size = 1) > * 14 and 94: 1-RTT packet (packet number size = 2) > * 34 and b4: 1-RTT packet (packet number size = 4) > * 0c and 8c: 1-RTT packet with Connection ID (packet number size = 1) > * 1c and 9c: 1-RTT packet with Connection ID (packet number size = 2) > * 3c and bc: 1-RTT packet with Connection ID (packet number size = 4) > From nobody Wed Feb 15 03:17:31 2017 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 21E97129AD1 for ; Wed, 15 Feb 2017 03:17:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Ko1OUaCNSUM for ; Wed, 15 Feb 2017 03:17:28 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE99D129A0F for ; Wed, 15 Feb 2017 03:17:27 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id p22so56417950qka.0 for ; Wed, 15 Feb 2017 03:17:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=PfRNTCDOnMDoXWXRNmiXR++auGctQaSXzVRbtcytCKY=; b=oOaJ4uJbgb44fvO/CWlJPRVFKFtxvf62kB79jqlcx6dDA4lSn8wasPtrSVPNXgvNbX uDHhwOuLjB11QrBMrx5Rbmf+NRakUcKL79W+9eR8QKRwaScISU6myy4m8ADNET7QHAt0 9cxnSs0SPvBX9UPl1UfDiZUiy9nVHafFpA7JlNpi0j7DbbTnj0vhaj48S2hRmhLziAnp 1DLHI4LI3SkffXR7CRulH1NirqVvBeVIcFE+UKyXWdMa/J5JOSvEd/oh97KUJe/zEfpH Dwn3RFfSBt8FN3oIencWHXBOMT0NGuQnSkhDD8RRCZD8BtaKV3Es3l2HkBrPjO7cZg+D xutg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=PfRNTCDOnMDoXWXRNmiXR++auGctQaSXzVRbtcytCKY=; b=dEHoDjsb35Fi0ZUggzZR95PytFpGhBkaSrKP/RQOASN5fvOL2T7vCc+bqIsLcrGR79 ajbKTC+YDIXtPZbXzlWkvaDHTMUjF/D78dtXEOIoq71/ITWt0gvJCvfJvvERnRf2MMQz AouhgqUYvzhKr+kk/x1tA1RSR8uVuoAGDgTnSZMpzVhNQ84bSWUqXassLraaj/PH1bGV 4yQUml+LkhoNyVCszeB+oJPBkVTflFAsavTL17c1FpR/dvbcC9s1huDGQHU4skqteiLl NXKuMHRSmDTwIKNpEA7oBpaRovikBmAJBFb2tsQ1N7CvptGF/zgJ9j2Az6eYhsS96qwu EBnQ== X-Gm-Message-State: AMke39ls1DPlK3Aipy/YZVn9CnFj6Ch1ATDAAcU1XpZA2jVovvwuiYcqR4CZm1cdq+pYDBFFhpUpDmWz5SlBLA== X-Received: by 10.233.235.66 with SMTP id b63mr34653590qkg.144.1487157447056; Wed, 15 Feb 2017 03:17:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 03:17:26 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 15 Feb 2017 22:17:26 +1100 Message-ID: Subject: Re: Alternate header proposal To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 11:17:29 -0000 On 15 February 2017 at 20:14, Mirja K=C3=BChlewind wrote: > 4) And finally, I think it would be safer to have the connection ID on al= l > packets. But maybe we can just use a shorter connection ID? What's the > reason for a 64 bits connection ID again? If anything I think that 64 bits is too short :) Server people keep asking for more anyway. Managing routing, authentication and whatever else this field might be used for, all in a mere 64 bits, is pretty challenging. I think that the notion of removing connection ID needs a lot more discussion. Reasons I can see for removing it are that the server doesn't need it, or the client doesn't want it (hello linkability). Removing it does jeopardize some connection migration cases though, so we probably want to work through the use cases in more detail. From nobody Wed Feb 15 04:49:21 2017 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 D3E01129AD4 for ; Wed, 15 Feb 2017 04:49:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 pbWLKLptrEN8 for ; Wed, 15 Feb 2017 04:49:18 -0800 (PST) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F238129A37 for ; Wed, 15 Feb 2017 04:49:18 -0800 (PST) Received: by mail-yb0-x229.google.com with SMTP id 123so44466107ybe.3 for ; Wed, 15 Feb 2017 04:49:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4pmx4eNw3ZLwwSPPTSBoRPFMyp/+2R0UpUnVVEgQj94=; b=dupyc2D5Z+SIeXgrocH9/5AZ5PF2++yeYwr95L6nICkfg3VZS42vCwAbU2azxqXxa5 FpESoB7esMRra9usikcKI4uL9wODtvMLQXlOCkWMd1Htr2o1rdq7csQ5Ec12Wt9YPbFA BYqCB1cf/9qsOJIZa/xvxZfomfP34qHApgbqO9PTE0JQkSEKkZ45mROIwLHQz6Ni83eH +Zpc8KGKuOC+r5PaZgC1ZYDt2m2NhwqaVu5dDDJCsOBnwCPa+2rXPIhvAC8HACY0r5lw AVgio9g3izGw81HRYd/TNCes0W8ZTb3A7hCh2dlkCdTYc9dUWnYBa4CkIhEG7RhFVjIt REBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4pmx4eNw3ZLwwSPPTSBoRPFMyp/+2R0UpUnVVEgQj94=; b=XFCToOLXO3aCBi7YmJw/gYiRFwJhKkTAih0MZdyRxZk3WmJPJTvJDTXrS+tkpA8QXv dDQZmd8rkWCA805iZxtsHgslLoFextLvPKLBpa6iwRcrlX06or/eLmI9DATp8yFEEPIr Qhc/gv15ip0WChsh/L1QNoVaclFddmR71OnpGmI9FGJasNeOG78pphKwApKyO83UFwmE h8KgcfIKFpoCHTuQXyyyR2P3PvAPF22ODIS6+6Ha8prKxR8U0f5JJU4jN6AhUooxQu2g YtXDHKJ2Pxtt6zILMLlPCyHYezctWVPykHIBNeN2GIh/RHO9NskHv2wf67f03f/uYGzK GTww== X-Gm-Message-State: AMke39ltMjQywzKxCy2YXi1WaGxBXpK04Zk7V0fp6tRCgAld+If3LtPZoSCwszawzVITm35053AKCtiqh5jKwC2O X-Received: by 10.37.103.2 with SMTP id b2mr24139159ybc.175.1487162956973; Wed, 15 Feb 2017 04:49:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Wed, 15 Feb 2017 04:48:56 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Wed, 15 Feb 2017 07:48:56 -0500 Message-ID: Subject: Re: Alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11c14a94c6755b0548911b93 Archived-At: Cc: Jana Iyengar , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 12:49:20 -0000 --001a11c14a94c6755b0548911b93 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I like this general approach a lot, because it defines a consistent set of easy to parse packets for prior to version negotiation, and allows plenty of extensibility both pre and post version negotiation if we need it. Having connection ID come after the flags byte feels right, because it's routing info. I also think it'll be relatively easy to implement. Mirja, to address your point about extensibility. I think we want the ability to evolve the design and add new features, in this case via packet types. One can imagine adding an 8 byte packet number format in the future, for example, or even a format with Martin's authenticated repeated options if we decide it's compelling? Mirja, re #3 about packet number sizes. This is very much about user-facing traffic, not datacenters. 2 bytes is enough for all the user facing traffic we have today. But that allows a max CWND that's less than what TCP allows, so 4 bytes was added because it seemed fairly futureproof. 1 byte isn't really that necessary, though it's commonly used on short connections and it's really easy to implement and we use it today, so Jana defined it. Martin and Mirja, re: When to include connection ID: Yes, it's clear this needs more discussion. I think it makes sense to have both sets of codepoints in there for now, and we can remove them later if we really think connection ID is never necessary. Currently, it's necessary in cases when NATs rapidly rebind. I do think we need a long-form packet that can carry 1-RTT, and I think it's critical if we want to drop connection ID from short form packets, since it could allow us to re-establish a connection with the same server using a new different ID. It's also useful for out of band key negotiation, which I believe is why Jana added it. If we're only going to include connection ID in packets which also contain version, we could bump the length to 16 bytes if there's a compelling use case. This proposal also allows us to grease every unencrypted byte in the packet, which makes me excited, but I'll write that up on the grease issue. On Wed, Feb 15, 2017 at 6:17 AM, Martin Thomson wrote: > On 15 February 2017 at 20:14, Mirja K=C3=BChlewind > wrote: > > 4) And finally, I think it would be safer to have the connection ID on > all > > packets. But maybe we can just use a shorter connection ID? What's the > > reason for a 64 bits connection ID again? > > If anything I think that 64 bits is too short :) Server people keep > asking for more anyway. Managing routing, authentication and whatever > else this field might be used for, all in a mere 64 bits, is pretty > challenging. > > I think that the notion of removing connection ID needs a lot more > discussion. Reasons I can see for removing it are that the server > doesn't need it, or the client doesn't want it (hello linkability). > Removing it does jeopardize some connection migration cases though, so > we probably want to work through the use cases in more detail. > > --001a11c14a94c6755b0548911b93 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I like this general approach a lot, because it defines a c= onsistent set of easy to parse packets for prior to version negotiation, an= d allows plenty of extensibility both pre and post version negotiation if w= e need it.=C2=A0 Having connection ID come after the flags byte feels right= , because it's routing info.=C2=A0 I also think it'll be relatively= easy to implement.

Mirja, to address your point about e= xtensibility.=C2=A0 I think we want the ability to evolve the design and ad= d new features, in this case via packet types.=C2=A0 One can imagine adding= an 8 byte packet number format in the future, for example, or even a forma= t with Martin's authenticated repeated options if we decide it's co= mpelling?

Mirja, re #3 about packet number sizes.= =C2=A0 This is very much about user-facing traffic, not datacenters. =C2=A0= 2 bytes is enough for all the user facing traffic we have today.=C2=A0 But = that allows a max CWND that's less than what TCP allows, so 4 bytes was= added because it seemed fairly futureproof. =C2=A01 byte isn't really = that necessary, though it's commonly used on short connections and it&#= 39;s really easy to implement and we use it today, so Jana defined it. =C2= =A0

Martin and Mirja, re: When to include connecti= on ID: Yes, it's clear this needs more discussion.=C2=A0 I think it mak= es sense to have both sets of codepoints in there for now, and we can remov= e them later if we really think connection ID is never necessary.=C2=A0 Cur= rently, it's necessary in cases when NATs rapidly rebind. =C2=A0
<= div>
I do think we need a long-form packet that can carry 1-R= TT, and I think it's critical if we want to drop connection ID from sho= rt form packets, since it could allow us to re-establish a connection with = the same server using a new different ID.=C2=A0 It's also useful for ou= t of band key negotiation, which I believe is why Jana added it.
=
If we're only going to include connection ID in packets = which also contain version, we could bump the length to 16 bytes if there&#= 39;s a compelling use case.=C2=A0

This proposal al= so allows us to grease every unencrypted byte in the packet, which makes me= excited, but I'll write that up on the grease issue.

On Wed, Feb 15, 2017 at= 6:17 AM, Martin Thomson <martin.thomson@gmail.com> w= rote:
On 15 February 2017 at 20:14, Mirja= K=C3=BChlewind
<mir= ja.kuehlewind@tik.ee.ethz.ch> wrote:
> 4) And finally, I think it would be safer to have the connection ID on= all
> packets. But maybe we can just use a shorter connection ID? What's= the
> reason for a 64 bits connection ID again?

If anything I think that 64 bits is too short :)=C2=A0 Server people= keep
asking for more anyway.=C2=A0 Managing routing, authentication and whatever=
else this field might be used for, all in a mere 64 bits, is pretty
challenging.

I think that the notion of removing connection ID needs a lot more
discussion.=C2=A0 Reasons I can see for removing it are that the server
doesn't need it, or the client doesn't want it (hello linkability).=
Removing it does jeopardize some connection migration cases though, so
we probably want to work through the use cases in more detail.


--001a11c14a94c6755b0548911b93-- From nobody Wed Feb 15 10:50:06 2017 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 746A41296CF for ; Wed, 15 Feb 2017 10:50:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxeEFhbGaDUI for ; Wed, 15 Feb 2017 10:50:02 -0800 (PST) Received: from brc2.unina.it (brc2.unina.it [192.132.34.42]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E93F0128E18 for ; Wed, 15 Feb 2017 10:50:01 -0800 (PST) X-ASG-Debug-ID: 1487184598-05f275541a06d00001-AtAMq9 Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by brc2.unina.it with ESMTP id XasFsrc53L8fDvz6 (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2017 19:49:58 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.62 Received: from [192.168.1.66] (93-44-65-253.ip96.fastwebnet.it [93.44.65.253]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id v1FInvpr016937 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Feb 2017 19:49:58 +0100 From: Simon Pietro Romano Content-Type: multipart/alternative; boundary="Apple-Mail=_57204802-0BCD-4917-A91A-EC30038F84F4" Date: Wed, 15 Feb 2017 19:49:47 +0100 Subject: No support for multipath in QUIC? To: IETF QUIC WG X-ASG-Orig-Subj: No support for multipath in QUIC? Message-Id: <08E13458-B861-4DFD-807F-F8497891944E@unina.it> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp2.unina.it[192.132.34.62] X-Barracuda-Start-Time: 1487184598 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.42:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.36049 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 18:50:04 -0000 --Apple-Mail=_57204802-0BCD-4917-A91A-EC30038F84F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi all, as part of a research project here at the University of Napoli, we are = working on a multipath enabled version of QUIC. Though, through = interactions with the Chromium guys on the "proto-quic=E2=80=9D mailing = list (which, as you know, is developing a code base for QUIC = implementation), we just discovered that they=E2=80=99re actively = removing the multipath code from the active repo. Does this also mean = that the QUIC wg at the IETF does not look at multipath as a desirable = functionality to be (optionally) offered by the protocol? If so, can I = dare to ask why? Thanks a lot for your feedback, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it = <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ --Apple-Mail=_57204802-0BCD-4917-A91A-EC30038F84F4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi all,

as = part of a research project here at the University of Napoli, we are = working on a multipath enabled version of QUIC. Though, through = interactions with the Chromium guys on the "proto-quic=E2=80=9D mailing = list (which, as you know, is developing a code base for QUIC = implementation), we just discovered that they=E2=80=99re actively = removing the multipath code from the active repo. Does this also mean = that the QUIC wg at the IETF does not look at multipath as a desirable = functionality to be (optionally) offered by the protocol? If so, can I = dare to ask why?

Thanks a lot for your feedback,

Simon


          =             =   _\\|//_
      =                     =   = ( O-O )
      = ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
  =                 =    = Simon Pietro Romano
    =            Universita' di = Napoli Federico II
        =               Computer Engineering = Department 
           =   Phone: +39 081 7683823 -- Fax: +39 081 7683816
                =                     =        e-mail: spromano@unina.it

    <<Molti mi = dicono che lo scoraggiamento =C3=A8 l'alibi degli 
=     idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
      =                 =                oooO
       ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=               =    \ (            (   = )
=               =                   =   \_)          ) /
                =                     =                     =               =  (_/



= --Apple-Mail=_57204802-0BCD-4917-A91A-EC30038F84F4-- From nobody Wed Feb 15 11:03:21 2017 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 D85B412940A for ; Wed, 15 Feb 2017 11:03:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 vlxEjE2byp57 for ; Wed, 15 Feb 2017 11:03:18 -0800 (PST) Received: from mail-wr0-x233.google.com (mail-wr0-x233.google.com [IPv6:2a00:1450:400c:c0c::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 E2F52128E18 for ; Wed, 15 Feb 2017 11:03:17 -0800 (PST) Received: by mail-wr0-x233.google.com with SMTP id c4so39611959wrd.2 for ; Wed, 15 Feb 2017 11:03:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qxtumtESzu3bbqUj2TQqFI4865D5H2qHPfNO2BC6M3I=; b=XmUFJD//+DaJ8s9EOyZsD7nSKPenz4Ke9CwE4Tv0ag6FssxhIYL3REQGNWPYbugNiN hyEvBanivwo6KOm74TZvaKXprdRXUGZ9qjU/WHvEMt8w9VuCCvqZwaP5WMkGRS3wwno5 0A2SNTZYPMZQZMn8xlesO7Z1F1ZrMia9RxODCGySvdKLIjhpah82qvyg7e4q6Wo9HRGg AIyjkGEGAsO/kr6JJ4D4aN8TDnC8okNrnHPRFizw061Koqia0dhHZIZB6luVRYLdmspF hunkIOktPsd3NDsvHsiFMwD+13iV8bfJmgZR9nCIPduAy0l/Xv1s2/6ejMd4KTRH6sX1 B1Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qxtumtESzu3bbqUj2TQqFI4865D5H2qHPfNO2BC6M3I=; b=qkKtEPyN3zAzacWFQuCYUhLq1XDrMmTHCh5SQjSY4mQx6chGWmrSUL6PanRf7JbF6B KI+n5KtRVge1QECvTOpmk0FTbvRXmJWrv74mwFLjqPBBwVuc/gdWGXkW/vW5GJrFh6+O exSFDc9AuEA0qYlqcYzniMVdT3gRGEiMFaJZHAq8SOwAJd6DVzE7loqMKuvg7uANK6qw NP+55AvrQkCqyAVd5qx4EyB3XKqq9mGZf4MHU23WMjdOO2CnFunM0LnUmSYrvC25AesO 0XzrFSXbKMBPL8iObz15HV900wOrZMBbnPTLYlPHkkouFg5ShDv6PQ8awQu0OOxHYA7j rqIw== X-Gm-Message-State: AMke39natRNrquRkO91Da3iN0OUPH0d8NZnOOXsn8U2BF/RvqoplzZymvNIVgHDXmJEyfhi+0p6C1c2zXhPsiRGt X-Received: by 10.223.169.112 with SMTP id u103mr31027347wrc.166.1487185396274; Wed, 15 Feb 2017 11:03:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Wed, 15 Feb 2017 11:03:15 -0800 (PST) In-Reply-To: <08E13458-B861-4DFD-807F-F8497891944E@unina.it> References: <08E13458-B861-4DFD-807F-F8497891944E@unina.it> From: Ryan Hamilton Date: Wed, 15 Feb 2017 11:03:15 -0800 Message-ID: Subject: Re: No support for multipath in QUIC? To: Simon Pietro Romano Content-Type: multipart/alternative; boundary=f403045cf000433f8f0548965546 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:03:20 -0000 --f403045cf000433f8f0548965546 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The IETF QUIC Working Group is tasked with, among other things: - Enabling multipath and forward error correction extensions; As such, I'm sure this group will eventually tackle multipath. However, it will likely be done via an extension to the core protocol. The experimental multipath support in Google's QUIC implementation was not via an extension, and was never complete. Instead it was a core part of the protocol and hence is being removed. Cheers, Ryan On Wed, Feb 15, 2017 at 10:49 AM, Simon Pietro Romano wrote: > Hi all, > > as part of a research project here at the University of Napoli, we are > working on a multipath enabled version of QUIC. Though, through > interactions with the Chromium guys on the "proto-quic=E2=80=9D mailing l= ist > (which, as you know, is developing a code base for QUIC implementation), = we > just discovered that they=E2=80=99re actively removing the multipath code= from the > active repo. Does this also mean that the QUIC wg at the IETF does not lo= ok > at multipath as a desirable functionality to be (optionally) offered by t= he > protocol? If so, can I dare to ask why? > > Thanks a lot for your feedback, > > Simon > > > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico II > Computer Engineering Department > Phone: +39 081 7683823 <+39%20081%20768%203823> -- Fax: +39 > 081 7683816 <+39%20081%20768%203816> > e-mail: spromano@unina.it > > < idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( ( ) > \_) ) / > (_= / > > > > --f403045cf000433f8f0548965546 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The IETF QUIC Working Group is tasked with, am= ong other things:

<= font face=3D"trebuchet ms, sans-serif">- Enabling multipath and forward err= or correction extensions;=C2=A0

As such, I'm sure = this group will eventually tackle multipath. However, it will likely be don= e via an extension to the core protocol. The experimental multipath support= in Google's QUIC implementation was not via an extension, and was neve= r complete. Instead it was a core part of the protocol and hence is being r= emoved.

Cheers,
<= font face=3D"trebuchet ms, sans-serif">
Ryan

On Wed, Feb 15, 201= 7 at 10:49 AM, Simon Pietro Romano <spromano@unina.it> wrote= :
Hi = all,

as part of a research project here at the Universit= y of Napoli, we are working on a multipath enabled version of QUIC. Though,= through interactions with the Chromium guys on the "proto-quic=E2=80= =9D mailing list (which, as you know, is developing a code base for QUIC im= plementation), we just discovered that they=E2=80=99re actively removing th= e multipath code from the active repo. Does this also mean that the QUIC wg= at the IETF does not look at multipath as a desirable functionality to be = (optionally) offered by the protocol? If so, can I dare to ask why?

Thanks a lot for your feedback,

= Simon


=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2= =A0=C2=A0_\\|//_
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ( O-O )
=C2=A0 =C2=A0 =C2=A0 ~~~~~~~~~~~= ~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 Simon Pietro Romano
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Universita' di Napoli Federico II
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0Computer Engineering Departmen= t=C2=A0
=C2=A0 =C2= =A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0Phone: +39 081 7683823= -- Fax: +39 081 7683816
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0e-mail:=C2=A0spromano@unina.it

=C2=A0 =C2=A0=C2=A0<<Molti mi di= cono che lo scoraggiamento =C3=A8 l'alibi degli=C2=A0
=C2=A0=C2=A0 =C2=A0idioti. Ci riflet= to un istante; e mi scoraggio>>. Magritte.
=C2=A0 =C2=A0 = =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0oooO
=C2=A0 =C2=A0 =C2=A0=C2=A0=C2=A0~~~~~~~~= ~~~~~~~~~~~~~~~( =C2=A0 )~~~=C2=A0Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
<= div> =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0\ ( =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0( =C2=A0 )
<= /span>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0\_) =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0) /
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(_/




--f403045cf000433f8f0548965546-- From nobody Wed Feb 15 11:08:28 2017 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 4A4941296F8 for ; Wed, 15 Feb 2017 11:08:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YGut4cJhBbBU for ; Wed, 15 Feb 2017 11:08:24 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 528431296EA for ; Wed, 15 Feb 2017 11:08:24 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id 73so122341088otj.0 for ; Wed, 15 Feb 2017 11:08:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wtOJqOFUXQzdmp5Kkgpkr5slhSPU/rg6ahnGjirn07A=; b=fjOmtVqmREeurObIJPzXUTPqSAB8L51NK2nBTAiEzAPQxNsqtVEdZjejxC9UFThFSb BTlCVV0HnSHwvp9YFMYLepG9G0NaFfUS4ewx/4xZkscNR1fdfXnLJLh1QqYgwG/hxEy3 zqNGoUJnxryN4EM6QqkljkCrh8Tiew5GS+fjAVHtyg5Ry/7vRPd6svP0XSPxin8SU3ef WmCIjv9y9rYvC9jPKDwyFsslh1cg6rRdMhKA0+VuUk+NddUqvl7uAprmep2T85zcrKSQ whMPr+wMupjTPy+WKDCPeSX2+bnlZDHgAkUddSqdywgCzTQbjBx/7AIYwRaL3XREAC6Z NgQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wtOJqOFUXQzdmp5Kkgpkr5slhSPU/rg6ahnGjirn07A=; b=RslVg30ULixa2kP2i/BDWlMlVCsjdrV8zTnWB9N3dIOTx3+rE5xfPqJibWK4hzjqWF 0AWJRfbcTweiMAECuQo05lKeIz6xVh/aSvKx6qwB4HLN4RvxS8X8RFKA04A6wbmsquNv lUCPsQ8YRxr2MWqLjH8dY3oFvlUq9VT1zOAK4P4udGLAkD48/q+4EGIGGUyes+R/pD5G wc5NbVijFOgMrFaz5XSXxTYCKSud8B/3/yTwUBpF1gBknCFekHi0+HKEJo/ImkhIbqoT ozKvGHQzXHOO4jER5Z83Wmqe9hWOf4s4nsVnIEX/s/aBYN9NtOyAyVXJGCk3jVV8wH9J 36mA== X-Gm-Message-State: AMke39mHGKTTB8pOZ/8K7y+B9o29yDrrAtUzVNj3V49surHAgKhW3LVlIPhB0Yflfd3eIbRsZwybYdqQqdEP9A== X-Received: by 10.157.22.163 with SMTP id c32mr18953556ote.107.1487185703635; Wed, 15 Feb 2017 11:08:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.15.182 with HTTP; Wed, 15 Feb 2017 11:08:23 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Wed, 15 Feb 2017 11:08:23 -0800 Message-ID: Subject: Re: Alternate header proposal To: Ian Swett Content-Type: multipart/alternative; boundary=001a1141f26c9496690548966744 Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Martin Thomson , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 19:08:26 -0000 --001a1141f26c9496690548966744 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The packet formats look great. I also like the idea of a version-agnostic long form header with version complexity only in the short form. But I have issues with the first byte: Perhaps I'm missing something simple here, but how does 0x8 specify short/long form? The first six short headers Jana presented differ in this bit from the second six. In fact there is no bit that is consistently set in the short form while cleared in the long form, or vice versa. Also, we have a number of outstanding manageability issues that could use 2-3 bits in the public flags, and I'd like to compress the uses here to make space for those. Furthermore, I think having an actual long/short bit would be quite useful and I'd like to arrange the codepoints to allow that. So I think processing would be somewhat easier with the following arrangement: 0x80: Long Form header If a long form header: 0x80-0xd0 - covers the six types of long-form packet The last 4 are reserved, and greased if we don't find uses for them If a short form header 0x40 - key phase 0x20 - conn Id included 0x10 and 0x08 - pkt # length The last three bits are reserved/greased. On Wed, Feb 15, 2017 at 4:48 AM, Ian Swett wrote: > I like this general approach a lot, because it defines a consistent set o= f > easy to parse packets for prior to version negotiation, and allows plenty > of extensibility both pre and post version negotiation if we need it. > Having connection ID come after the flags byte feels right, because it's > routing info. I also think it'll be relatively easy to implement. > > Mirja, to address your point about extensibility. I think we want the > ability to evolve the design and add new features, in this case via packe= t > types. One can imagine adding an 8 byte packet number format in the > future, for example, or even a format with Martin's authenticated repeate= d > options if we decide it's compelling? > > Mirja, re #3 about packet number sizes. This is very much about > user-facing traffic, not datacenters. 2 bytes is enough for all the user > facing traffic we have today. But that allows a max CWND that's less tha= n > what TCP allows, so 4 bytes was added because it seemed fairly futureproo= f. > 1 byte isn't really that necessary, though it's commonly used on short > connections and it's really easy to implement and we use it today, so Jan= a > defined it. > > Martin and Mirja, re: When to include connection ID: Yes, it's clear this > needs more discussion. I think it makes sense to have both sets of > codepoints in there for now, and we can remove them later if we really > think connection ID is never necessary. Currently, it's necessary in cas= es > when NATs rapidly rebind. > > I do think we need a long-form packet that can carry 1-RTT, and I think > it's critical if we want to drop connection ID from short form packets, > since it could allow us to re-establish a connection with the same server > using a new different ID. It's also useful for out of band key > negotiation, which I believe is why Jana added it. > > If we're only going to include connection ID in packets which also contai= n > version, we could bump the length to 16 bytes if there's a compelling use > case. > > This proposal also allows us to grease every unencrypted byte in the > packet, which makes me excited, but I'll write that up on the grease issu= e. > > On Wed, Feb 15, 2017 at 6:17 AM, Martin Thomson > wrote: > >> On 15 February 2017 at 20:14, Mirja K=C3=BChlewind >> wrote: >> > 4) And finally, I think it would be safer to have the connection ID on >> all >> > packets. But maybe we can just use a shorter connection ID? What's the >> > reason for a 64 bits connection ID again? >> >> If anything I think that 64 bits is too short :) Server people keep >> asking for more anyway. Managing routing, authentication and whatever >> else this field might be used for, all in a mere 64 bits, is pretty >> challenging. >> >> I think that the notion of removing connection ID needs a lot more >> discussion. Reasons I can see for removing it are that the server >> doesn't need it, or the client doesn't want it (hello linkability). >> Removing it does jeopardize some connection migration cases though, so >> we probably want to work through the use cases in more detail. >> >> > --001a1141f26c9496690548966744 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The packet formats look great. I also like the idea o= f a version-agnostic long form header with version complexity only in the s= hort form.

But I have issues with the first byte:<= /div>

Perhaps I'm missing something simple here, but= how does 0x8 specify short/long form? The first six short headers Jana pre= sented differ in this bit from the second six. In fact there is no bit that= is consistently set in the short form while cleared in the long form, or v= ice versa.

Also, we have a number of outstanding m= anageability issues that could use 2-3 bits in the public flags, and I'= d like to compress the uses here to make space for those.

Furthermore, I think having an actual long/short bit would be quite= useful and I'd like to arrange the codepoints to allow that.

So I think processing would be somewhat easier with the fol= lowing arrangement:
0x80: Long Form header
If a long fo= rm header:
=C2=A0 0x80-0xd0 - covers the six types of long-form p= acket
=C2=A0 The last 4 are reserved, and greased if we don't= find uses for them
If a short form header
=C2=A0 0x40 = - key phase
=C2=A0 0x20 - conn Id included
=C2=A0 0x10 = and 0x08 - pkt # length
=C2=A0 The last three bits are reserved/g= reased.

On Wed, Feb 15, 2017 at 4:48 AM, Ian Swett <ianswett@google.com&g= t; wrote:
I like = this general approach a lot, because it defines a consistent set of easy to= parse packets for prior to version negotiation, and allows plenty of exten= sibility both pre and post version negotiation if we need it.=C2=A0 Having = connection ID come after the flags byte feels right, because it's routi= ng info.=C2=A0 I also think it'll be relatively easy to implement.
=
Mirja, to address your point about extensibility.=C2=A0 I th= ink we want the ability to evolve the design and add new features, in this = case via packet types.=C2=A0 One can imagine adding an 8 byte packet number= format in the future, for example, or even a format with Martin's auth= enticated repeated options if we decide it's compelling?

=
Mirja, re #3 about packet number sizes.=C2=A0 This is very much = about user-facing traffic, not datacenters. =C2=A02 bytes is enough for all= the user facing traffic we have today.=C2=A0 But that allows a max CWND th= at's less than what TCP allows, so 4 bytes was added because it seemed = fairly futureproof. =C2=A01 byte isn't really that necessary, though it= 's commonly used on short connections and it's really easy to imple= ment and we use it today, so Jana defined it. =C2=A0

Martin and Mirja, re: When to include connection ID: Yes, it's clear= this needs more discussion.=C2=A0 I think it makes sense to have both sets= of codepoints in there for now, and we can remove them later if we really = think connection ID is never necessary.=C2=A0 Currently, it's necessary= in cases when NATs rapidly rebind. =C2=A0

I do th= ink we need a long-form packet that can carry 1-RTT, and I think it's c= ritical if we want to drop connection ID from short form packets, since it = could allow us to re-establish a connection with the same server using a ne= w different ID.=C2=A0 It's also useful for out of band key negotiation,= which I believe is why Jana added it.

If we'r= e only going to include connection ID in packets which also contain version= , we could bump the length to 16 bytes if there's a compelling use case= .=C2=A0

This proposal also allows us to grease eve= ry unencrypted byte in the packet, which makes me excited, but I'll wri= te that up on the grease issue.

On Wed, F= eb 15, 2017 at 6:17 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 15 February 2017 a= t 20:14, Mirja K=C3=BChlewind
<mirja.kuehlewind@tik.ee.ethz.ch> wrote:
> 4) And finally, I think it would be safer to have the connection ID on= all
> packets. But maybe we can just use a shorter connection ID? What's= the
> reason for a 64 bits connection ID again?

If anything I think that 64 bits is too short :)=C2=A0 Server people= keep
asking for more anyway.=C2=A0 Managing routing, authentication and whatever=
else this field might be used for, all in a mere 64 bits, is pretty
challenging.

I think that the notion of removing connection ID needs a lot more
discussion.=C2=A0 Reasons I can see for removing it are that the server
doesn't need it, or the client doesn't want it (hello linkability).=
Removing it does jeopardize some connection migration cases though, so
we probably want to work through the use cases in more detail.



--001a1141f26c9496690548966744-- From nobody Wed Feb 15 12:56:26 2017 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 4DECD1297CE for ; Wed, 15 Feb 2017 12:56:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 AvDIwFHN1pBB for ; Wed, 15 Feb 2017 12:56:22 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 64369129522 for ; Wed, 15 Feb 2017 12:56:22 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id 35so114181955uak.1 for ; Wed, 15 Feb 2017 12:56:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pVCc6TmUMQXngSM0SeOJbqYFzCGEq8EI/X930gYJhIw=; b=a34vtY8GeMP9pdZDP+iE4rou61ydSfm5pyrri8DCg5OLB8UGfm8NbNzWBFu5N/jO50 RJ/cY4j0GHKY26Uztc06JpnZs5T13lttxy2tv0vUQoKgrrdAt+qSt08y3XywEYWlWafe CmrecPgWKYO3oeQdK3NngBPZ8vvIAiW2FPv6iYEiIvWUc/MQMkeqkyCt04JDenxyWA/P EIN1zQBmnV5Imq67cm/ZeYW1VnGDaOUAS/W6Obkjo8qGilsdwY2wNHKpsyaGSsygs77P TmSpWEOKenhtDc0/YcndwDAXtQVQfDt2MwFj1bnnXshbSsTNwC54quLWHkEa2tqThaj+ TLIw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pVCc6TmUMQXngSM0SeOJbqYFzCGEq8EI/X930gYJhIw=; b=CbGpnNhmroy//eKTC0vwEIuz6llAIkVTF+KbWnUCaMp/jJXD7Vn3QSfvZHwJMVFooo i5H6/ehDYwcYJpkSoGMXdIjsW3tQd5qhabOT1v/JbZT6gLERon7zJKao8O7VZOfjvoas eLOsTHotoTJYNuRCmyrkFC2iCOX6nUSSC9A4YTNy0vn6+5fMJjjgLBR1LjGBvQloiht3 +wJyFvBCJRjzdzm6O3/GJmVgxLctbVEWLOMfthoDAijHFn8h2rBZtFqw2HqH7GKUnJl5 nkj+s3/E2k9rmcpuTW2B0pgwUMoAE2IFiJpMyP41YQJJNmU9YkJ098bywPeyizdUfZQy ljdw== X-Gm-Message-State: AMke39mYs7PUQLMq6IQiTSjXu+M73U1rJ6BgJORwhy7zz861btapJwmu8iSZcQvLzSlHl5b7IR3JK3SfNoOvwqWE X-Received: by 10.159.48.79 with SMTP id i15mr16320628uab.13.1487192180791; Wed, 15 Feb 2017 12:56:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Wed, 15 Feb 2017 12:56:20 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Feb 2017 12:56:20 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045d9e22a6e9ed054897e9b3 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 20:56:24 -0000 --f403045d9e22a6e9ed054897e9b3 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 12:43 AM, Martin Thomson wrote: > I like this general approach. > I do too. It comes from my discussions with you, so thank you for those. I would prefer if the packet number were in the same place in both > forms (that seems easy enough to do by moving the version). Then we > get a contiguous proof block (connection ID + packet number) for a > public reset. > Packet number after version was deliberate, to allow packet number to change in future versions. An incompatible receiver only has to read up through the version field, and ignores the packet number field. If we move the packet number to before the version, we burn the 4-byte packet number in the long-form header for future versions too. It's not the craziest thing to burn in, so I'm not opposed to this idea. You do get the nice contiguous block... if we have packet number before version in the long header, here's a reformulation of the public reset packet. A public reset packet is sent when the server has no state for a received packet. A server may therefore have to respond to either a long-form or a short-form packet. A public reset packet contains: * Octets 1-12: proof (octets 1-12 of received packet) * Octets 13-16: version For a client that sends a connection ID on every packet, this packet can be simply interpreted as: * Octets 1-8: connection ID (echoed) * Octets 9-12: 1/2/4-byte packet number (echoed) * Octets 13-16: version I think I like this. Can anyone think of reasons to not burn packet number in the long header? I note that you can use 0x08 to check if the packet is long or short. > We should try to keep that property until we can't any more. > I'd argue against that. This means that all code points including 0x80 are lost, and I don't see what you gain. Checking if the packet is long or short is easy: if the type is in {39, 3a, 3d, 3e, 3f, 1c} then it's long, and if it's in {04, 84, 14, 94, 34, b4, 0c, 8c, 1c, 9c, 3c, bc} then it's short. This isn't hard to do. I'm OK with the server proposing a new connection ID on a version > negotiation packet (though not yet 100% confident that it's the right > answer), but it doesn't make any sense to propose a new connection ID > on a public reset. Echoing the client value is a chance to provide > stronger proof that it saw the packet it is reacting to. Agreed. The contiguous block idea above resolves this. - jana --f403045d9e22a6e9ed054897e9b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 12:43 AM, Martin Thomson <martin.thomson@gmail= .com> wrote:
I like this general approach.

I do= too. It comes from my discussions with you, so thank you for those.
<= div>
I would prefer if the packet number were in the same place in both
forms (that seems easy enough to do by moving the version).=C2=A0 Then we get a contiguous proof block (connection ID + packet number) for a
public reset.

Packet number after versi= on was deliberate, to allow packet number to change in future versions. An = incompatible receiver only has to read up through the version field, and ig= nores the packet number field. If we move the packet number to before the v= ersion, we burn the 4-byte packet number in the long-form header for future= versions too. It's not the craziest thing to burn in, so I'm not o= pposed to this idea. You do get the nice contiguous block... if we have pac= ket number before version in the long header, here's a reformulation of= the public reset packet.

A public reset pack= et is sent when the server has no state for a received
packet. A = server may therefore have to respond to either a long-form or a=C2=A0
=
short-form packet. A public reset packet contains:
* Octets = 1-12: proof (octets 1-12 of received packet)
* Octets 13-16: vers= ion

For a client that sends a connection ID = on every packet, this packet can be simply interpreted as:
<= div>* Octets 1-8: connection ID (echoed)
* Octets 9-12: 1/2/4-byt= e packet number (echoed)
* Octets 13-16: version

I think I like this. Can anyone think of reasons to no= t burn packet number in the long header?

I note that you can use 0x08 to check if the packet is long or short.
We should try to keep that property until we can't any more.

I'd argue against that. This means that all c= ode points including 0x80 are lost, and I don't see what you gain. Chec= king if the packet is long or short is easy: if the type is in {39, 3a, 3d,= 3e, 3f, 1c} then it's long, and if it's in {04, 84, 14, 94, 34, b4= , 0c, 8c, 1c, 9c, 3c, bc} then it's short. This isn't hard to do.

I'm OK with the server proposing a new connection ID on a version
negotiation packet (though not yet 100% confident that it's the right answer), but it doesn't make any sense to propose a new connection ID on a public reset.=C2=A0 Echoing the client value is a chance to provide stronger proof that it saw the packet it is reacting to.
<= br>
Agreed. The contiguous block idea above resolves this.
<= div>=C2=A0
- jana
--f403045d9e22a6e9ed054897e9b3-- From nobody Wed Feb 15 14:05:19 2017 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 8E88C1295AE for ; Wed, 15 Feb 2017 14:05:18 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 rtWcs_tm3w8I for ; Wed, 15 Feb 2017 14:05:16 -0800 (PST) Received: from mail-vk0-x236.google.com (mail-vk0-x236.google.com [IPv6:2607:f8b0:400c:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E371E129559 for ; Wed, 15 Feb 2017 14:05:15 -0800 (PST) Received: by mail-vk0-x236.google.com with SMTP id x75so107837743vke.2 for ; Wed, 15 Feb 2017 14:05:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=oOa6MfcqkJdEYBxW7vglljJEG5CodbkGKfN9Oia0hsY=; b=Fc1oioVNcT/X6jSn8j/ox8Nwi0rBq/q70RsOu9KmhOa96bWakoPyym2sqQWsIsfTMW c/NsIaND2P1kZNxfqczSmVizkzJV9U+J8s+fXEOQyNHG/L1N9wLC0/CT5kwiRBMEcWns ihqYGl+KCaQJ/Enmt/iBbEfgjk/DsSx4uHncZZZ8kIUDkPlODMfYDc/2UUx4FlcPX7cR uUvyVEkY9GhHOxL+CGPQYqtLMy1/ZpZjIwkQU+xCyQHdyPAory7ijQY7PLbJoG56Lsu7 asSd6uD/HkRFnYUgbbPbmkHkD9vIwcCxGXLVm0op/fV3F2zfTQ11YvUVGheYxvJmmEj8 DyxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oOa6MfcqkJdEYBxW7vglljJEG5CodbkGKfN9Oia0hsY=; b=EnJXL8G+NJETBJr/0PZcKD6WNYxuJYewJ/iufdj7EVYDLHQTPlebZSJ/Gg8wGSMVmV GJgQsP0VKK8wOCkDPK/r8rROdBPf+HOBmciU1TL9QGw0/hUp/jmiflFxPmxPUWUvtaze wA8FEJK9QLR5A+OUSbiayQEmkuZs65qr/MbE41zNH3r2URmgu70iHGuQsiE9kV/f33O1 72TXDKb4oSeSuSzWjoe9pDX22lBe/NuoUtP87Ss8UtngeNJVoyKH6y9SORs9fMRQKmHN GXcGpANzsJPjlcLjyjgUuOqiVPyxKs0DcH9QwDK7q77TGMv0n9XonLYLhureTdwJP+NT HBfA== X-Gm-Message-State: AMke39mpbBPtEfwGU2MQhEf642yaScKovfUPdA/m4/nSTAIZWSru9h5pzHU7ZBnanYqfm/5AxK/Fuwwo75OM/qrl X-Received: by 10.31.99.1 with SMTP id x1mr18489851vkb.161.1487196314461; Wed, 15 Feb 2017 14:05:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Wed, 15 Feb 2017 14:05:13 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Feb 2017 14:05:13 -0800 Message-ID: Subject: Re: Alternate header proposal To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=94eb2c07b178091c68054898e08f Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 22:05:18 -0000 --94eb2c07b178091c68054898e08f Content-Type: text/plain; charset=UTF-8 Hi Mirja, in general I like the idea of short and long packets because optimizing > header bits really only make a lot of sense if this space can be used for > payload bits instead. > Cool -- agreed. > However, couple of comments: > > 1) I'd say that having undefined codepoints enables actually the kind of > extensibility (beside versioning) that you've been arguing against > previously. I don't think that this a bad thing because it's under My disagreement with the earlier proposal was an arbitrary extensibility mechanism that I didn't want baked into the protocol... but I think Martin may have been proposing using it only up until we get to RFC, in which case I misunderstood his proposal. This proposal generalizes that idea for sure, but it also combines that with requirement to identify QUIC packets, which was done with the magic field in the previous proposal. > endpoint control, however, having codepoints instead of bits with a > special meaning actually makes it harder to deploy. If the endpoint sees an > unknown codepoint, it can only drop the packet completely (it doesn't even > know where the payload starts), while with an dedicated bit that declares a > certain space to be used for additional information that can always be > ignored. In summary, I think your proposal needs a header length field, but > still I prefer the flags field because it's less complex. > This is deliberate. An endpoint that sees an unknown codepoint should drop it since it can't tell it as a QUIC packet from random garbage. Interpreting a piece of an unknown header as header-length is quite problematic and I don't think you gain anything from doing this. If you can't interpret the header, what is the endpoint to do with the payload? Middleboxes are trickier: you may have a box that understands the early codepoints but doesn't understand later codepoints. Ian has an idea for greasing the codepoint space for short-form headers, which should help with this problem. 2) Further effectively as Martin basically pointed out in his follow-up > mail, you still have one bit that indicates the short or long header. I > think that's good and we should maintain this but in that case we should > also call this bit out like this because that's easier to understand for > humans (who need to implement this). > As I said earlier in my response to Martin, I don't think that's right, and I don't think we want a bit set aside. > 3) I still don't really understand the need for different sizes of the > packet number field, especially I don't understand why we have 3 different > values. I assume you mainly try to save bits in a data center scenario, > right? But in this case you could even run your own version of quic where > the only difference is that you always have a shorter packet number. > I agree with Ian's response -- we use the different packet number sizes for the bandwidth-constrained direction (server -> client) on the public Internet. I'll note that in the common case in Google's Internet-side deployment, QUIC packets in the bandwidth-constrained direction currently have a 2 or 3 byte header (flags, 1-2 bytes of packet number.) > 4) And finally, I think it would be safer to have the connection ID on all > packets. But maybe we can just use a shorter connection ID? What's the > reason for a 64 bits connection ID again? Also if we allow for packets > without the connection ID, that's probably something the server should tell > the client because the server might know if that's needed for some kind of > load balancing setup at server side or not. > This is currently negotiated during the handshake as the TCID (truncated connection ID) param, which is described in the draft. Sending the entire connection ID on all packets in both directions is quite wasteful. Connection ID need only be sent if it is required for routing. If the 5-tuple is adequate, then sending a connection ID on each packet is a waste of bandwidth. - jana > Mirja > > > On 15.02.2017 08:05, Jana Iyengar wrote: > >> After discussion with various folks, I have put together an alternate >> proposal for packet header organization, described below (also on github >> here >> .) >> This >> >> borrows the long/short header idea from Martin's formulation, but turns >> the >> flags field into a type byte, with only 18 codepoints defined. This >> proposal >> eliminates the need for an explicit magic field, and uses packet types for >> directionality of cleartext packets. >> >> Hope this makes sense, and happy to discuss modifications to this format. >> Details can of course be changed, but I'm quite liking the use of a 1-byte >> codepoint instead of bits for various fields. >> >> ------------------- >> >> QUIC packet headers can be separated into long form and short form >> headers. >> Long form headers are used for version negotiation, connection >> establishment, >> and public reset packets. Short form headers are version-specific, and >> are used >> for 1-RTT packets, minimizing their header size. >> >> While all packets are identified using the same Type octet, headers are >> separated into the two categories for two reasons: (i) short form headers >> are >> only used after version negotiation and establishment of 1-RTT keys, and >> (ii) editorial convenience. >> >> This formulation eschews specific bits indicating the presence of >> various fields in favor of an octet indicating one of 256 packet types. >> Of these 256 types, this version defines and uses only 18: 6 with >> long-form >> headers for the initial phase of the connection, and 12 with short-form >> headers >> for after the version negotiation and 1-RTT keys are established. >> >> >> # Long-Form Headers >> >> ``` >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+ >> | Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + Connection ID + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Version | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Packet Number / Proof | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ``` >> >> These long-form headers are used for anything that doesn't have 1-RTT >> packet >> protection and prior to the completion of version negotiation. Once both >> conditions are met, a sender may switch to sending short-form headers. >> While inefficient, long headers may also be used for 1-RTT packets. The >> long >> form allows for special packets, such as the version negotiation and the >> public >> reset packets to be represented in this uniform fixed-length packet >> format. >> >> * Octet 0: Packet Type >> * 39: Version Negotiation packet >> * 3a: Public Reset packet >> * 3d: 0-RTT packet >> * 3e: Server cleartext packet >> * 3f: Client cleartext packet >> * 1c: 1-RTT packet with version field, connection ID, >> and 2-byte packet number >> >> The remainder of the packet layout is the same regardless of type, the >> difference being what rules for how to fill the values out and their >> semantics. >> >> A client cleartext packet (type = 0x3c) then contains: >> * Octets 1-8: connection ID (initially randomly chosen) >> * Octets 9-12: version >> * Octets 13-16: packet number (low 4 octets, starts at a random 31-bit >> value) >> * Octets 17+: payload >> >> The client MUST choose a random value and use it as the Connection ID >> until the >> server replies with a server-selected connection ID. The client's >> connection ID >> would have no semantic value, though they might serve to provide proof >> that >> the server received the packet via echoing, see below. >> >> A server cleartext packet (type = 0x3e) contains: >> * Octets 1-8: connection ID (server-selected value) >> * Octets 9-12: version (echoed) >> * Octets 13-16: packet number (low 4 octets, random 31-bit initial value) >> * Octets 17+: payload >> >> Both 0-RTT and 1-RTT packets with long-form headers contain: >> * Octets 1-8: connection ID (server-selected value) >> * Octets 9-12: version >> * Octets 13-16: packet number (low 4 octets) >> * Octets 17+: payload >> >> A version negotiation packet contains: >> * Octets 1-8: connection ID (server-selected value, may be used in a >> subsequent >> connection to reach the same server) >> * Octets 9-12: version (echoed) >> * Octets 13-16: proof (first 4 octets of client-selected connection ID) >> * Octets 17+: payload = version list >> >> A public reset packet is sent when the server has no state for a received >> packet. A server may therefore have to respond to either a long-form or a >> short-form packet. A public reset packet contains: >> * Octets 1-8: connection ID (server-selected value) >> * Octets 9-12: version >> * Octets 13-16: proof (octets 1-5 of received packet) >> >> Echoing details from the packet in both version negotiation and public >> reset >> provides return routeability (#244), while maintaining a consistent header >> shape for all packets. >> >> >> # Short Form Header >> >> ``` >> 0 1 2 3 >> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> +-+-+-+-+-+-+-+-+ >> | Type | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | | >> + Connection ID (optional) + >> | | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Packet Number (1/2/4) | >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> | Payload ... >> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> ``` >> >> The short form header is used after the version and 1-RTT keys are >> negotiated. >> The short form header is defined to be specific to a version. In this >> version, >> bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, >> resulting >> in the following packet types. >> * Octet 0: Packet Type >> * 04 and 84: 1-RTT packet (packet number size = 1) >> * 14 and 94: 1-RTT packet (packet number size = 2) >> * 34 and b4: 1-RTT packet (packet number size = 4) >> * 0c and 8c: 1-RTT packet with Connection ID (packet number size = 1) >> * 1c and 9c: 1-RTT packet with Connection ID (packet number size = 2) >> * 3c and bc: 1-RTT packet with Connection ID (packet number size = 4) >> >> --94eb2c07b178091c68054898e08f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Mirja,


in general I like the idea of short and long packets because optimizing hea= der bits really only make a lot of sense if this space can be used for payl= oad bits instead.

Cool -- agreed.
=
=C2=A0
However, couple of comments:

1) I'd say that having undefined codepoints enables actually the kind o= f extensibility (beside versioning) that you've been arguing against pr= eviously. I don't think that this a bad thing because it's under

My disagreement with the earlier proposal wa= s an arbitrary extensibility mechanism that I didn't want baked into th= e protocol... but I think Martin may have been proposing using it only up u= ntil we get to RFC, in which case I misunderstood his proposal. This propos= al generalizes that idea for sure, but it also combines that with requireme= nt to identify QUIC packets, which was done with the magic field in the pre= vious proposal.
=C2=A0
endpoint control, however, having codepoints instead of bits w= ith a special meaning actually makes it harder to deploy. If the endpoint s= ees an unknown codepoint, it can only drop the packet completely (it doesn&= #39;t even know where the payload starts), while with an dedicated bit that= declares a certain space to be used for additional information that can al= ways be ignored. In summary, I think your proposal needs a header length fi= eld, but still I prefer the flags field because it's less complex.
<= /blockquote>

This is deliberate. An endpoint that sees a= n unknown codepoint should drop it since it can't tell it as a QUIC pac= ket from random garbage. Interpreting a piece of an unknown header as heade= r-length is quite problematic and I don't think you gain anything from = doing this. If you can't interpret the header, what is the endpoint to = do with the payload?

Middleboxes are trickier: =C2= =A0you may have a box that understands the early codepoints but doesn't= understand later codepoints. Ian has an idea for greasing the codepoint sp= ace for short-form headers, which should help with this problem.
=
2) Further effectively as Martin basically pointed out in his follow-up mai= l, you still have one bit that indicates the short or long header. I think = that's good and we should maintain this but in that case we should also= call this bit out like this because that's easier to understand for hu= mans (who need to implement this).

As I= said earlier in my response to Martin, I don't think that's right,= and I don't think we want a bit set aside.
=C2=A0
3) I still don't really understand the need for different sizes of the = packet number field, especially I don't understand why we have 3 differ= ent values. I assume you mainly try to save bits in a data center scenario,= right? But in this case you could even run your own version of quic where = the only difference is that you always have a shorter packet number.

I agree with Ian's response -- we use the= different packet number sizes for the bandwidth-constrained direction (ser= ver -> client) on the public Internet. I'll note that in the common = case in Google's Internet-side deployment, QUIC packets in the bandwidt= h-constrained direction currently have a 2 or 3 byte header (flags, 1-2 byt= es of packet number.)
=C2=A0
4) And finally, I think it would be safer to have the connection ID on all = packets. But maybe we can just use a shorter connection ID? What's the = reason for a 64 bits connection ID again? Also if we allow for packets with= out the connection ID, that's probably something the server should tell= the client because the server might know if that's needed for some kin= d of load balancing setup at server side or not.

<= /div>
This is currently negotiated during the handshake as the TCID (tr= uncated connection ID) param, which is described in the draft. Sending the = entire connection ID on all packets in both directions is quite wasteful. C= onnection ID need only be sent if it is required for routing. If the 5-tupl= e is adequate, then sending a connection ID on each packet is a waste of ba= ndwidth.

- jana
=C2=A0
Mirja


On 15.02.2017 08:05, Jana Iyengar wrote:
After discussion with various folks, I have put together an alternate
proposal for packet header organization, described below (also on github he= re
 <https://gist.github.com/jana= iyengar/b05acb3af17d6e938d25befc69c11eae>.) This

borrows the long/short header idea from Martin's formulation, but turns= the
flags field into a type byte, with only 18 codepoints defined. This proposa= l
eliminates the need for an explicit magic field, and uses packet types for<= br> directionality of cleartext packets.

Hope this makes sense, and happy to discuss modifications to this format. Details can of course be changed, but I'm quite liking the use of a 1-b= yte
codepoint instead of bits for various fields.

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

QUIC packet headers can be separated into long form and short form headers.=
Long form headers are used for version negotiation, connection establishmen= t,
and public reset packets. Short form headers are version-specific, and are = used
for 1-RTT packets, minimizing their header size.

While all packets are identified using the same Type octet, headers are
separated into the two categories for two reasons: (i) short form headers a= re
only used after version negotiation and establishment of 1-RTT keys, and (ii) editorial convenience.

This formulation eschews specific bits indicating the presence of
various fields in favor of an octet indicating one of 256 packet types.
Of these 256 types, this version defines and uses only 18: 6 with long-form=
headers for the initial phase of the connection, and 12 with short-form hea= ders
for after the version negotiation and 1-RTT keys are established.


# Long-Form Headers

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|=C2=A0 =C2=A0 =C2=A0Type=C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Version=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packet Numb= er / Proof=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Payload=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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

These long-form headers are used for anything that doesn't have 1-RTT p= acket
protection and prior to the completion of version negotiation. Once both conditions are met, a sender may switch to sending short-form headers.
While inefficient, long headers may also be used for 1-RTT packets. The lon= g
form allows for special packets, such as the version negotiation and the pu= blic
reset packets to be represented in this uniform fixed-length packet format.=

* Octet 0: Packet Type
=C2=A0 * 39: Version Negotiation packet
=C2=A0 * 3a: Public Reset packet
=C2=A0 * 3d: 0-RTT packet
=C2=A0 * 3e: Server cleartext packet
=C2=A0 * 3f: Client cleartext packet
=C2=A0 * 1c: 1-RTT packet with version field, connection ID,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 and 2-byte packet number

The remainder of the packet layout is the same regardless of type, the
difference being what rules for how to fill the values out and their semant= ics.

A client cleartext packet (type =3D 0x3c) then contains:
* Octets 1-8: connection ID (initially randomly chosen)
* Octets 9-12: version
* Octets 13-16: packet number (low 4 octets, starts at a random 31-bit valu= e)
* Octets 17+: payload

The client MUST choose a random value and use it as the Connection ID until= the
server replies with a server-selected connection ID. The client's conne= ction ID
would have no semantic value, though they might serve to provide proof that=
the server received the packet via echoing, see below.

A server cleartext packet (type =3D 0x3e) contains:
* Octets 1-8: connection ID (server-selected value)
* Octets 9-12: version (echoed)
* Octets 13-16: packet number (low 4 octets, random 31-bit initial value) * Octets 17+: payload

Both 0-RTT and 1-RTT packets with long-form headers contain:
* Octets 1-8: connection ID (server-selected value)
* Octets 9-12: version
* Octets 13-16: packet number (low 4 octets)
* Octets 17+: payload

A version negotiation packet contains:
* Octets 1-8: connection ID (server-selected value, may be used in a subseq= uent
=C2=A0 connection to reach the same server)
* Octets 9-12: version (echoed)
* Octets 13-16: proof (first 4 octets of client-selected connection ID)
* Octets 17+: payload =3D version list

A public reset packet is sent when the server has no state for a received packet. A server may therefore have to respond to either a long-form or a short-form packet. A public reset packet contains:
* Octets 1-8: connection ID (server-selected value)
* Octets 9-12: version
* Octets 13-16: proof (octets 1-5 of received packet)

Echoing details from the packet in both version negotiation and public rese= t
provides return routeability (#244), while maintaining a consistent header<= br> shape for all packets.


# Short Form Header

```
=C2=A00=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03
=C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|=C2=A0 =C2=A0 =C2=A0 Type=C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Conne= ction ID (optional)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 +
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0Packet Number (1/2/4)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
|=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Payload=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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+=
```

The short form header is used after the version and 1-RTT keys are negotiat= ed.
The short form header is defined to be specific to a version. In this versi= on,
bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, resulti= ng
in the following packet types.
* Octet 0: Packet Type
=C2=A0 * 04 and 84: 1-RTT packet (packet number size =3D 1)
=C2=A0 * 14 and 94: 1-RTT packet (packet number size =3D 2)
=C2=A0 * 34 and b4: 1-RTT packet (packet number size =3D 4)
=C2=A0 * 0c and 8c: 1-RTT packet with Connection ID (packet number size =3D= 1)
=C2=A0 * 1c and 9c: 1-RTT packet with Connection ID (packet number size =3D= 2)
=C2=A0 * 3c and bc: 1-RTT packet with Connection ID (packet number size =3D= 4)


--94eb2c07b178091c68054898e08f-- From nobody Wed Feb 15 14:27:08 2017 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 C3FD21296E7 for ; Wed, 15 Feb 2017 14:27:06 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 IRnnr4zZao7A for ; Wed, 15 Feb 2017 14:27:04 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c: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 7E9CE129584 for ; Wed, 15 Feb 2017 14:27:04 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id t8so93735vke.3 for ; Wed, 15 Feb 2017 14:27:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=u58C0cVKBkqo0Kb9a6TtoMl3wwYw+5ic0I6Hk3k9UsU=; b=fnNndVNF8+5STGW5cx/MokqDPvHkcxEPP3oxi5+G+Wqs+WMMdyWcF8XQrpUR2JNHDp Unzb5Y5kvqQmX8xervmwCRttFf9rMvSL/1msX2HSVwerWEuWzZ1dfjLIqQenibpbCkqv VL1u0OyNR+kI0w3lcRZBr46qsCB0G3Kj13Jpj9ny3frKtPW1LozNdIfLI2LY78n3awfM UMcAvMXauVVck6x+oP72k0f01Dp1jxTggn8MP0+gJbZAqYVcNhNl7EDMgJBgfZagPa6k oKrFvro/OOwjH3K3JM/u1NSLih81qERNqloerXJoiJKWWU9nXHmU+aCvapJydpho2RdU KLQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=u58C0cVKBkqo0Kb9a6TtoMl3wwYw+5ic0I6Hk3k9UsU=; b=gLwCPjn6hsCedQz5wGtdj0EarpTEqhGwRkUeVQ/w5lflMd1jkFxKhpj8RQogXMyu85 tIDrO+sZIJA2Ye6mvzn/9+s2SKdfLug7P9st4n3TRh311jPtNq6wokGn1oj7G7eBXKc2 JhPNsPZANyoKSw+vQOtsRo1BZoWvo3ufssSyijpTGQl3Led4v/w7k042PErbjJ+SLIEW wDS0YxloWgchlXcpyopdLt7EfnReCcB+I4vMa4FZY1/LsEXaOIk5+2S8Xhab1N9JNqnt 6W1Zmc7v6Ncb9FHLxGN4ySWFW+F1uIHVeJYLwASeCME7sd8Fub21MoNEWVOVSsaNcCtd 8m6w== X-Gm-Message-State: AMke39kOq08+1jZkevcaGNtG9JJwZxyk1jUyOESJCPM39+knSg9m4vjCzixwMTYPkfOqT8HAILL4+zSIOvVlkcXX X-Received: by 10.31.92.1 with SMTP id q1mr15633700vkb.151.1487197623231; Wed, 15 Feb 2017 14:27:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Wed, 15 Feb 2017 14:27:02 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Feb 2017 14:27:02 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Duke Content-Type: multipart/alternative; boundary=001a114e2b6e0b961a0548992e3a Archived-At: Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Ian Swett , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 22:27:07 -0000 --001a114e2b6e0b961a0548992e3a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2017 at 11:08 AM, Martin Duke wrote: > The packet formats look great. I also like the idea of a version-agnostic > long form header with version complexity only in the short form. > > But I have issues with the first byte: > > Perhaps I'm missing something simple here, but how does 0x8 specify > short/long form? The first six short headers Jana presented differ in thi= s > bit from the second six. In fact there is no bit that is consistently set > in the short form while cleared in the long form, or vice versa. > You're right, there's no single bit that can be used in this proposal. > Also, we have a number of outstanding manageability issues that could use > 2-3 bits in the public flags, and I'd like to compress the uses here to > make space for those. > ... or we could add more codepoints. We can make the codepoints contiguous if that helps. Let's discuss the issues independent of representation first, and then figure out representation. > Furthermore, I think having an actual long/short bit would be quite usefu= l > and I'd like to arrange the codepoints to allow that. > > So I think processing would be somewhat easier with the following > arrangement: > 0x80: Long Form header > If a long form header: > 0x80-0xd0 - covers the six types of long-form packet > The last 4 are reserved, and greased if we don't find uses for them > If a short form header > 0x40 - key phase > 0x20 - conn Id included > 0x10 and 0x08 - pkt # length > The last three bits are reserved/greased. > This looks close to an intermediate proposal I had come up with :-) I'm not opposed to this, but it makes the split between long and short forms more explicit than necessary. I don't think processing is harder with the current proposal, though sure, you could make the packet types contiguous if that helps. Importantly, the two forms are not really that different from a processing point-of-view if you look closely; the separation is really more useful for reasoning and understanding. There is the distinction of the short form being version-specific, but that's really only to say that a receiver that negotiates version X should only process the codepoints defined for that version. Except for the version negotiation and public reset packets, the rest of the types are data bearing packets (with or without some fields and key phase signaling) and should be treated as such. As to going from codepoint to bits that indicate presence of fields, it's a simple matter of mapping codepoints to local per-packet state, and you continue processing the packet with the local state. I don't think you need explicit bits; mapping from a codepoint to explicit bits at the endpoints should work fine IMO. - jana > On Wed, Feb 15, 2017 at 4:48 AM, Ian Swett wrote: > >> I like this general approach a lot, because it defines a consistent set >> of easy to parse packets for prior to version negotiation, and allows >> plenty of extensibility both pre and post version negotiation if we need >> it. Having connection ID come after the flags byte feels right, because >> it's routing info. I also think it'll be relatively easy to implement. >> >> Mirja, to address your point about extensibility. I think we want the >> ability to evolve the design and add new features, in this case via pack= et >> types. One can imagine adding an 8 byte packet number format in the >> future, for example, or even a format with Martin's authenticated repeat= ed >> options if we decide it's compelling? >> >> Mirja, re #3 about packet number sizes. This is very much about >> user-facing traffic, not datacenters. 2 bytes is enough for all the use= r >> facing traffic we have today. But that allows a max CWND that's less th= an >> what TCP allows, so 4 bytes was added because it seemed fairly futurepro= of. >> 1 byte isn't really that necessary, though it's commonly used on short >> connections and it's really easy to implement and we use it today, so Ja= na >> defined it. >> >> Martin and Mirja, re: When to include connection ID: Yes, it's clear thi= s >> needs more discussion. I think it makes sense to have both sets of >> codepoints in there for now, and we can remove them later if we really >> think connection ID is never necessary. Currently, it's necessary in ca= ses >> when NATs rapidly rebind. >> >> I do think we need a long-form packet that can carry 1-RTT, and I think >> it's critical if we want to drop connection ID from short form packets, >> since it could allow us to re-establish a connection with the same serve= r >> using a new different ID. It's also useful for out of band key >> negotiation, which I believe is why Jana added it. >> >> If we're only going to include connection ID in packets which also >> contain version, we could bump the length to 16 bytes if there's a >> compelling use case. >> >> This proposal also allows us to grease every unencrypted byte in the >> packet, which makes me excited, but I'll write that up on the grease iss= ue. >> >> On Wed, Feb 15, 2017 at 6:17 AM, Martin Thomson > > wrote: >> >>> On 15 February 2017 at 20:14, Mirja K=C3=BChlewind >>> wrote: >>> > 4) And finally, I think it would be safer to have the connection ID o= n >>> all >>> > packets. But maybe we can just use a shorter connection ID? What's th= e >>> > reason for a 64 bits connection ID again? >>> >>> If anything I think that 64 bits is too short :) Server people keep >>> asking for more anyway. Managing routing, authentication and whatever >>> else this field might be used for, all in a mere 64 bits, is pretty >>> challenging. >>> >>> I think that the notion of removing connection ID needs a lot more >>> discussion. Reasons I can see for removing it are that the server >>> doesn't need it, or the client doesn't want it (hello linkability). >>> Removing it does jeopardize some connection migration cases though, so >>> we probably want to work through the use cases in more detail. >>> >>> >> > --001a114e2b6e0b961a0548992e3a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 11:08 AM, Martin Duke <martin.h.duke@gmail.com> wrote:
The packet formats look great. I also like the idea of a version-agnostic= long form header with version complexity only in the short form.


=
Perhaps I'm missing something simple here, but how does 0x8 specif= y short/long form? The first six short headers Jana presented differ in thi= s bit from the second six. In fact there is no bit that is consistently set= in the short form while cleared in the long form, or vice versa.

You're right, there's no single = bit that can be used in this proposal.
=C2=A0
Also, we have a number of outstandin= g manageability issues that could use 2-3 bits in the public flags, and I&#= 39;d like to compress the uses here to make space for those.

... or we could add more codepoints. We can m= ake the codepoints contiguous if that helps. Let's discuss the issues i= ndependent of representation first, and then figure out representation.
=C2=A0
Fur= thermore, I think having an actual long/short bit would be quite useful and= I'd like to arrange the codepoints to allow that.

=
So I think processing would be somewhat easier with the following arra= ngement:
0x80: Long Form header
If a long form header:<= /div>
=C2=A0 0x80-0xd0 - covers the six types of long-form packet
=
=C2=A0 The last 4 are reserved, and greased if we don't find uses = for them
If a short form header
=C2=A0 0x40 - key phase=
=C2=A0 0x20 - conn Id included
=C2=A0 0x10 and 0x08 - = pkt # length
=C2=A0 The last three bits are reserved/greased.

This looks close to an intermediat= e proposal I had come up with :-) I'm not opposed to this, but it makes= the split between long and short forms more explicit than necessary. I don= 't think processing is harder with the current proposal, though sure, y= ou could make the packet types contiguous if that helps.

Importantly, the two forms are not really that different from a proc= essing point-of-view if you look closely; the separation is really more use= ful for reasoning and understanding. There is the distinction of the short = form being version-specific, but that's really only to say that a recei= ver that negotiates version X should only process the codepoints defined fo= r that version.=C2=A0 Except for the version negotiation and public reset p= ackets, the rest of the types are data bearing packets (with or without som= e fields and key phase signaling) and should be treated as such. As to goin= g from codepoint to bits that indicate presence of fields, it's a simpl= e matter of mapping codepoints to local per-packet state, and you continue = processing the packet with the local state.=C2=A0

= I don't think you need explicit bits; mapping from a codepoint to expli= cit bits at the endpoints should work fine IMO.

- = jana
=C2=A0
On Wed, Feb 15, 2017 at 4:48 AM, Ian Swett <ianswett@google.com> wrote:
I li= ke this general approach a lot, because it defines a consistent set of easy= to parse packets for prior to version negotiation, and allows plenty of ex= tensibility both pre and post version negotiation if we need it.=C2=A0 Havi= ng connection ID come after the flags byte feels right, because it's ro= uting info.=C2=A0 I also think it'll be relatively easy to implement.
Mirja, to address your point about extensibility.=C2=A0 I= think we want the ability to evolve the design and add new features, in th= is case via packet types.=C2=A0 One can imagine adding an 8 byte packet num= ber format in the future, for example, or even a format with Martin's a= uthenticated repeated options if we decide it's compelling?
<= br>
Mirja, re #3 about packet number sizes.=C2=A0 This is very mu= ch about user-facing traffic, not datacenters. =C2=A02 bytes is enough for = all the user facing traffic we have today.=C2=A0 But that allows a max CWND= that's less than what TCP allows, so 4 bytes was added because it seem= ed fairly futureproof. =C2=A01 byte isn't really that necessary, though= it's commonly used on short connections and it's really easy to im= plement and we use it today, so Jana defined it. =C2=A0

Martin and Mirja, re: When to include connection ID: Yes, it's cl= ear this needs more discussion.=C2=A0 I think it makes sense to have both s= ets of codepoints in there for now, and we can remove them later if we real= ly think connection ID is never necessary.=C2=A0 Currently, it's necess= ary in cases when NATs rapidly rebind. =C2=A0

I do= think we need a long-form packet that can carry 1-RTT, and I think it'= s critical if we want to drop connection ID from short form packets, since = it could allow us to re-establish a connection with the same server using a= new different ID.=C2=A0 It's also useful for out of band key negotiati= on, which I believe is why Jana added it.

If we= 9;re only going to include connection ID in packets which also contain vers= ion, we could bump the length to 16 bytes if there's a compelling use c= ase.=C2=A0

This proposal also allows us to grease = every unencrypted byte in the packet, which makes me excited, but I'll = write that up on the grease issue.

On Wed, Feb 15, 2017 at 6:17 AM, Mart= in Thomson <martin.thomson@gmail.com> wrote:
On 15 February 2017 at 20:14, Mirja K=C3=BChlewin= d
<mirja.kuehlewind@tik.ee.ethz.ch> wrote:
> 4) And finally, I think it would be safer to have the connection ID on= all
> packets. But maybe we can just use a shorter connection ID? What's= the
> reason for a 64 bits connection ID again?

If anything I think that 64 bits is too short :)=C2=A0 Server people= keep
asking for more anyway.=C2=A0 Managing routing, authentication and whatever=
else this field might be used for, all in a mere 64 bits, is pretty
challenging.

I think that the notion of removing connection ID needs a lot more
discussion.=C2=A0 Reasons I can see for removing it are that the server
doesn't need it, or the client doesn't want it (hello linkability).=
Removing it does jeopardize some connection migration cases though, so
we probably want to work through the use cases in more detail.




--001a114e2b6e0b961a0548992e3a-- From nobody Wed Feb 15 14:41:37 2017 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 5CCEC129585 for ; Wed, 15 Feb 2017 14:41:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1YQjgF8wkEK for ; Wed, 15 Feb 2017 14:41:35 -0800 (PST) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 353CC129525 for ; Wed, 15 Feb 2017 14:41:35 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id 73so425931otj.0 for ; Wed, 15 Feb 2017 14:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+Z/eWxctt6NsXTzHcV2BtyBLUKQsspTnBx7u8ZMW4Bk=; b=tYp80BUbL6sZZof3SFQwWnXAaO1JbXqqdfqTrz33uViWiregYlwzEr15xOhz8LuEol D89U/4GOwx7ySSyxvhcPbJOq9VhZOWGqEUJSFBN6b05YgbPOCEFuLkXEOcCgMD88s1v8 tuKdaPuRaHfDIFoHjVE79V/QHFpdouMWVn2J3iTZim1wt9Q5Hr/QRCRO7BqWJbgBcLBs cWATA7bCacXhW4TcHpUOQiUItNv1dTDquWlGYE27SEXCVTB6x1V41z+Czpf9bwIuoUCn ASWNfMLuc69S7ZhDUfxzGtLEXb3ic6LgxDx6TaS7+oztocvktzmMZ6O+id5+gsmqCdTQ XxFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+Z/eWxctt6NsXTzHcV2BtyBLUKQsspTnBx7u8ZMW4Bk=; b=c9YPY9P5Eh+eL9f+zP4NhXMPK560rKIAkxp+xKn3fFNLIoWkoYZZk49481yUxSGBPz Abd4CA3wK5ilDUtjcEPQGJJFIBTuQTOpgd3pWqEowDCERjmFdDLGgO2YlzjgH2hlLaRq tgyAtzRSMRb1lxKNEBAu8FimkwqBspv+VeCQ+qRhPU5U+feqwchZ5kz+Ygast0vW20Pn vHutYg3kIEExF0K9wAcwz7MZsHQqwEyzjSRsxHeA244ZZ9F1QGjQEZo0jvMsi0ky6cVd bbEKNmH8OI7Yl2/bht/CKqxi7+uzNyl926WWwNXLJPWNTndBvkdQ6Tuc5gnK1eWL8wke 11JA== X-Gm-Message-State: AMke39nz8xcQLdT8h58SFOrYmL0MMnBWEDpAX7SVRoFQN7sFGDypljKIf0sZ58NYYIpNvU7XjPh4Efu8ryQfzg== X-Received: by 10.157.7.17 with SMTP id 17mr18820679ote.231.1487198494672; Wed, 15 Feb 2017 14:41:34 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.15.182 with HTTP; Wed, 15 Feb 2017 14:41:34 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Wed, 15 Feb 2017 14:41:34 -0800 Message-ID: Subject: Re: Alternate header proposal To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a1137be10fc4df5054899614e Archived-At: Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Ian Swett , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 22:41:36 -0000 --001a1137be10fc4df5054899614e Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 2:27 PM, Jana Iyengar wrote: > On Wed, Feb 15, 2017 at 11:08 AM, Martin Duke > wrote: > >> >> Also, we have a number of outstanding manageability issues that could use >> 2-3 bits in the public flags, and I'd like to compress the uses here to >> make space for those. >> > > ... or we could add more codepoints. We can make the codepoints contiguous > if that helps. Let's discuss the issues independent of representation > first, and then figure out representation. > > Without trying to legislate these issues here, the manageability proposals basically involve setting a few bits in the flags to give basic loss and flow control information to middleboxes. They are orthogonal to header length and (largely) to each otehr, so you're multiplying the number of codepoints by up to 8 (32 if ECE/CWR in the flags has a constituency) in a way that makes it much harder for the middlebox to read if those codepoints don't in practice correspond to a particular bit. These flags would apply to both long and short form packets, so there are not even any economies there. I don't think you need explicit bits; mapping from a codepoint to explicit > bits at the endpoints should work fine IMO. I agree 100% for long form, where there are a series of oddball packet types. But for short form, there are many permutations that are largely independent of each other, so little is lost by formally organizing them as bits corresponding to fields. --001a1137be10fc4df5054899614e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 2:27 PM, Jana Iyengar <jri@google.com> wrot= e:
= On Wed, Feb 15, 2017 at 11:08 AM, Martin Duke <martin.h.duke@gmail.c= om> wrote:

Also,= we have a number of outstanding manageability issues that could use 2-3 bi= ts in the public flags, and I'd like to compress the uses here to make = space for those.

... or = we could add more codepoints. We can make the codepoints contiguous if that= helps. Let's discuss the issues independent of representation first, a= nd then figure out representation.
=C2=A0<= /div>

Without tryi= ng to legislate these issues here, the manageability proposals basically in= volve setting a few bits in the flags to give basic loss and flow control i= nformation to middleboxes. They are orthogonal to header length and (largel= y) to each otehr, so you're multiplying the number of codepoints by up = to 8 (32 if ECE/CWR in the flags has a constituency) in a way that makes it= much harder for the middlebox to read if those codepoints don't in pra= ctice correspond to a particular bit.=C2=A0

These = flags would apply to both long and short form packets, so there are not eve= n any economies there.

I don't think you ne= ed explicit bits; mapping from a codepoint to explicit bits at the endpoint= s should work fine IMO.

I agree 100%= for long form, where there are a series of oddball packet types. But for s= hort form, there are many permutations that are largely independent of each= other, so little is lost by formally organizing them as bits corresponding= to fields.
--001a1137be10fc4df5054899614e-- From nobody Wed Feb 15 15:09:44 2017 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 DD2BB1298BC for ; Wed, 15 Feb 2017 15:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 mwLVap22KXZ9 for ; Wed, 15 Feb 2017 15:09:42 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0098.outbound.protection.outlook.com [104.47.36.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CA3A129721 for ; Wed, 15 Feb 2017 15:01:18 -0800 (PST) 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=2VOZe8lqsRk+gI7eq0LQ87bkuP3PBQdTFJ+HPycBRso=; b=Ogna0/FMEIMN4BXDLt3eD/YcJ1cD3DZqAD64DG5+YY/A4iLROhqejpRRDt2QS4mQumA36QzYWl6PDgyGBe+axvU/NtoFhI1Zljfz8qVf90DcxkufBvD4sX6qVyJWJskuCUp4W5mZEmutkh040gJr51N/qpc0o8N5BSQStt/+Nek= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2705.namprd03.prod.outlook.com (10.173.144.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.888.16; Wed, 15 Feb 2017 23:01:13 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0888.030; Wed, 15 Feb 2017 23:01:13 +0000 From: Mike Bishop To: Jana Iyengar , Martin Duke Subject: RE: Alternate header proposal Thread-Topic: Alternate header proposal Thread-Index: AQHSh1nlBuN55lDYUkCbfaX8oDZiNKFpySWAgAAiUwCAABmRAIAAagSAgAA3gQCAAAYHUA== Date: Wed, 15 Feb 2017 23:01:13 +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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:7::51f] x-ms-office365-filtering-correlation-id: d9920e91-3303-42ec-2ab9-08d455f68a45 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2705; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2705; 7:RC9W7EJff3VKZZ3HtQUhmhi88pbXuPcHO5qzj49TKLNsBG4aSncshkzNtJCojuLKUCmEDks6AQA7hOBX+U/5ngUtiCUDojoAfbGC8EJlCO2pducEYJcJbbJZpUDtkMa/ChIRozCZNnxShRUO1my/DrGRuugYIROg5ricaqYCWV0tsW5BR997uNKA56Mmg/iM9mNBqqtvN6VNajgZbZZlECYPhCHRFqiLrwmmuXA+Vug/NMaRGXiEK70Y4Yhdas+bZ06LMWBNEGUtWs85OQEsQEK/yV1Ke9A3yhFxwuK9cRpzlkJ/x0sSGnQpYKP7Pnr2PzoBIQlXG3Bo3XBKqVQJT+Iqwfx0r4RQMyCr+n0yMi4= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558025)(6042181)(6072148); SRVR:BN6PR03MB2705; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2705; x-forefront-prvs: 021975AE46 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(189002)(199003)(51444003)(377454003)(24454002)(81166006)(8990500004)(3280700002)(81156014)(93886004)(8936002)(4326007)(3480700004)(105586002)(106116001)(189998001)(8676002)(7736002)(122556002)(3660700001)(790700001)(2900100001)(2906002)(106356001)(54896002)(6116002)(102836003)(389900002)(74316002)(92566002)(55016002)(54906002)(99286003)(236005)(97736004)(9686003)(6306002)(68736007)(229853002)(6506006)(54356999)(76176999)(50986999)(10090500001)(2950100002)(33656002)(38730400002)(101416001)(561944003)(7116003)(5660300001)(39060400002)(10290500002)(6436002)(25786008)(6246003)(5005710100001)(86362001)(86612001)(77096006)(53546003)(53936002)(19609705001)(7696004); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2705; H:BN6PR03MB2708.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: multipart/alternative; boundary="_000_BN6PR03MB270846AFA9914DDC52210405875B0BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2017 23:01:13.3404 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2705 Archived-At: Cc: Martin Thomson , Ian Swett , IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:09:44 -0000 --_000_BN6PR03MB270846AFA9914DDC52210405875B0BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgc2VlbXMgbGlrZSB0aGVyZeKAmXMgYW4gZW1lcmdpbmcgaWRlYSAod2hpY2ggaGFzIGJlZW4g cHJlc2VudCBhbGwgYWxvbmcpIHRoYXQgdGhlcmUgYXJlIHJlYWxseSB0d28gc3ViZGl2aXNpb25z IG9mIFFVSUM6DQoNCiAgKiAgIFFVSUMtZm9yLWFsbC10aW1lOiAgRm9yZXZlci1maXhlZCBwYWNr ZXQgbGF5b3V0cyBjYXJyeWluZyB2ZXJzaW9uIG5lZ290aWF0aW9uLCBwdWJsaWMgcmVzZXQsIGV0 Yy47IGNhbiBjYXJyeSB2ZXJzaW9uLXNwZWNpZmljIGhlYWRlcnMvcGF5bG9hZCBhcyB3ZWxsIGlm IHlvdeKAmXZlIGFncmVlZCBvbiB0aGUgdmVyc2lvbg0KICAgICAqICAgSWYgeW91IGNoYW5nZSB0 aGVzZSwgeW914oCZcmUgZGVmaW5pbmcgYSBuZXcgcHJvdG9jb2wgdGhhdCBoYXMgdG8gYmUgZGlz dGluZ3Vpc2hhYmxlIGZyb20gUVVJQyBpbiBzb21lIHdheQ0KICAqICAgUVVJQy1mb3Itbm93OiAg VmVyc2lvbi1zcGVjaWZpYyBwYWNrZXQgbGF5b3V0cyBjYXJyeWluZyB2ZXJzaW9uLXNwZWNpZmlj IHBheWxvYWQNCg0KSXQgc291bmRzIGxpa2Ugd2hhdCB5b3XigJlyZSBzYXlpbmcgaGVyZSBpcyB0 aGF0IGFsbCBsb25nLWZvcm0gcGFja2V0IGNvZGVwb2ludHMgYXJlIHBhcnQgb2YgUVVJQy1mb3It YWxsLXRpbWUgKGRlbGliZXJhdGVseSBub3QgY29pbmluZyB0aGUgdGVybSDigJxRRkFU4oCdKSwg YW5kIGEgcmVjZWl2ZXIgaGFzIHRvIGFzc3VtZSB0aGF0IGFueSBvdGhlciBjb2RlcG9pbnQgbWln aHQgYmUgcGFydCBvZiBRVUlDLWZvci1ub3cgaW4gYSB2ZXJzaW9uIGl0IGRvZXNu4oCZdCBrbm93 ICh3aGljaCBnZXRzIGRyb3BwZWQsIGVpdGhlciBiZWNhdXNlIGl0IGtub3dzIHRoZSBwdXJwb3J0 ZWQgdmVyc2lvbiBhbmQgZG9lc27igJl0IHJlY29nbml6ZSB0aGUgY29kZXBvaW50IG9yIGRvZXNu 4oCZdCBrbm93IHRoZSBwdXJwb3J0ZWQgdmVyc2lvbiBhbmQgaXQgc2hvdWxkbuKAmXQgYmUgc2Vl aW5nIHRob3NlIHdpdGhvdXQgbmVnb3RpYXRpb24gaGF2aW5nIGNvbXBsZXRlZCkuDQoNCkN1cnJl bnRseSwgd2UgZGVzY3JpYmUgdGhlIHdob2xlIHRoaW5nIHRvZ2V0aGVyLCBhbmQgaGF2ZSBhIGZv bGxvdy11cCBzZWN0aW9uIHRoYXQgc2F5cyDigJxCVFcsIHRoZXNlIHRoaW5ncyB3b27igJl0IGNo YW5nZSBpbiBmdXR1cmUgdmVyc2lvbnMu4oCdICBXaXRob3V0IG5lY2Vzc2FyaWx5IHNwbGl0dGlu ZyBRVUlDLWZvci1hbGwtdGltZSBpbnRvIGEgc2VwYXJhdGUgZG9jdW1lbnQsIGl0IG1pZ2h0IGJl IHVzZWZ1bCB0byB0ZWFzZSB0aGF0IGxpbmUgYXBhcnQgZnVydGhlciBhbmQgbWFrZSB0aGUgaW1t dXRhYmxlIHN0dWZmIGF0IGxlYXN0IGEgZnVsbHkgc2VwYXJhdGUgc2VjdGlvbi4NCg0KRnJvbTog UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEphbmEgSXll bmdhcg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAxNSwgMjAxNyAyOjI3IFBNDQpUbzogTWFy dGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPg0KQ2M6IE1pcmphIEvDvGhsZXdpbmQg PG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdv b2dsZS5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNYXJ0aW4gVGhvbXNvbiA8 bWFydGluLnRob21zb25AZ21haWwuY29tPg0KU3ViamVjdDogUmU6IEFsdGVybmF0ZSBoZWFkZXIg cHJvcG9zYWwNCg0KT24gV2VkLCBGZWIgMTUsIDIwMTcgYXQgMTE6MDggQU0sIE1hcnRpbiBEdWtl IDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLmguZHVrZUBnbWFpbC5jb20+ PiB3cm90ZToNClRoZSBwYWNrZXQgZm9ybWF0cyBsb29rIGdyZWF0LiBJIGFsc28gbGlrZSB0aGUg aWRlYSBvZiBhIHZlcnNpb24tYWdub3N0aWMgbG9uZyBmb3JtIGhlYWRlciB3aXRoIHZlcnNpb24g Y29tcGxleGl0eSBvbmx5IGluIHRoZSBzaG9ydCBmb3JtLg0KDQpCdXQgSSBoYXZlIGlzc3VlcyB3 aXRoIHRoZSBmaXJzdCBieXRlOg0KDQpQZXJoYXBzIEknbSBtaXNzaW5nIHNvbWV0aGluZyBzaW1w bGUgaGVyZSwgYnV0IGhvdyBkb2VzIDB4OCBzcGVjaWZ5IHNob3J0L2xvbmcgZm9ybT8gVGhlIGZp cnN0IHNpeCBzaG9ydCBoZWFkZXJzIEphbmEgcHJlc2VudGVkIGRpZmZlciBpbiB0aGlzIGJpdCBm cm9tIHRoZSBzZWNvbmQgc2l4LiBJbiBmYWN0IHRoZXJlIGlzIG5vIGJpdCB0aGF0IGlzIGNvbnNp c3RlbnRseSBzZXQgaW4gdGhlIHNob3J0IGZvcm0gd2hpbGUgY2xlYXJlZCBpbiB0aGUgbG9uZyBm b3JtLCBvciB2aWNlIHZlcnNhLg0KDQpZb3UncmUgcmlnaHQsIHRoZXJlJ3Mgbm8gc2luZ2xlIGJp dCB0aGF0IGNhbiBiZSB1c2VkIGluIHRoaXMgcHJvcG9zYWwuDQoNCkFsc28sIHdlIGhhdmUgYSBu dW1iZXIgb2Ygb3V0c3RhbmRpbmcgbWFuYWdlYWJpbGl0eSBpc3N1ZXMgdGhhdCBjb3VsZCB1c2Ug Mi0zIGJpdHMgaW4gdGhlIHB1YmxpYyBmbGFncywgYW5kIEknZCBsaWtlIHRvIGNvbXByZXNzIHRo ZSB1c2VzIGhlcmUgdG8gbWFrZSBzcGFjZSBmb3IgdGhvc2UuDQoNCi4uLiBvciB3ZSBjb3VsZCBh ZGQgbW9yZSBjb2RlcG9pbnRzLiBXZSBjYW4gbWFrZSB0aGUgY29kZXBvaW50cyBjb250aWd1b3Vz IGlmIHRoYXQgaGVscHMuIExldCdzIGRpc2N1c3MgdGhlIGlzc3VlcyBpbmRlcGVuZGVudCBvZiBy ZXByZXNlbnRhdGlvbiBmaXJzdCwgYW5kIHRoZW4gZmlndXJlIG91dCByZXByZXNlbnRhdGlvbi4N Cg0KRnVydGhlcm1vcmUsIEkgdGhpbmsgaGF2aW5nIGFuIGFjdHVhbCBsb25nL3Nob3J0IGJpdCB3 b3VsZCBiZSBxdWl0ZSB1c2VmdWwgYW5kIEknZCBsaWtlIHRvIGFycmFuZ2UgdGhlIGNvZGVwb2lu dHMgdG8gYWxsb3cgdGhhdC4NCg0KU28gSSB0aGluayBwcm9jZXNzaW5nIHdvdWxkIGJlIHNvbWV3 aGF0IGVhc2llciB3aXRoIHRoZSBmb2xsb3dpbmcgYXJyYW5nZW1lbnQ6DQoweDgwOiBMb25nIEZv cm0gaGVhZGVyDQpJZiBhIGxvbmcgZm9ybSBoZWFkZXI6DQogIDB4ODAtMHhkMCAtIGNvdmVycyB0 aGUgc2l4IHR5cGVzIG9mIGxvbmctZm9ybSBwYWNrZXQNCiAgVGhlIGxhc3QgNCBhcmUgcmVzZXJ2 ZWQsIGFuZCBncmVhc2VkIGlmIHdlIGRvbid0IGZpbmQgdXNlcyBmb3IgdGhlbQ0KSWYgYSBzaG9y dCBmb3JtIGhlYWRlcg0KICAweDQwIC0ga2V5IHBoYXNlDQogIDB4MjAgLSBjb25uIElkIGluY2x1 ZGVkDQogIDB4MTAgYW5kIDB4MDggLSBwa3QgIyBsZW5ndGgNCiAgVGhlIGxhc3QgdGhyZWUgYml0 cyBhcmUgcmVzZXJ2ZWQvZ3JlYXNlZC4NCg0KVGhpcyBsb29rcyBjbG9zZSB0byBhbiBpbnRlcm1l ZGlhdGUgcHJvcG9zYWwgSSBoYWQgY29tZSB1cCB3aXRoIDotKSBJJ20gbm90IG9wcG9zZWQgdG8g dGhpcywgYnV0IGl0IG1ha2VzIHRoZSBzcGxpdCBiZXR3ZWVuIGxvbmcgYW5kIHNob3J0IGZvcm1z IG1vcmUgZXhwbGljaXQgdGhhbiBuZWNlc3NhcnkuIEkgZG9uJ3QgdGhpbmsgcHJvY2Vzc2luZyBp cyBoYXJkZXIgd2l0aCB0aGUgY3VycmVudCBwcm9wb3NhbCwgdGhvdWdoIHN1cmUsIHlvdSBjb3Vs ZCBtYWtlIHRoZSBwYWNrZXQgdHlwZXMgY29udGlndW91cyBpZiB0aGF0IGhlbHBzLg0KDQpJbXBv cnRhbnRseSwgdGhlIHR3byBmb3JtcyBhcmUgbm90IHJlYWxseSB0aGF0IGRpZmZlcmVudCBmcm9t IGEgcHJvY2Vzc2luZyBwb2ludC1vZi12aWV3IGlmIHlvdSBsb29rIGNsb3NlbHk7IHRoZSBzZXBh cmF0aW9uIGlzIHJlYWxseSBtb3JlIHVzZWZ1bCBmb3IgcmVhc29uaW5nIGFuZCB1bmRlcnN0YW5k aW5nLiBUaGVyZSBpcyB0aGUgZGlzdGluY3Rpb24gb2YgdGhlIHNob3J0IGZvcm0gYmVpbmcgdmVy c2lvbi1zcGVjaWZpYywgYnV0IHRoYXQncyByZWFsbHkgb25seSB0byBzYXkgdGhhdCBhIHJlY2Vp dmVyIHRoYXQgbmVnb3RpYXRlcyB2ZXJzaW9uIFggc2hvdWxkIG9ubHkgcHJvY2VzcyB0aGUgY29k ZXBvaW50cyBkZWZpbmVkIGZvciB0aGF0IHZlcnNpb24uICBFeGNlcHQgZm9yIHRoZSB2ZXJzaW9u IG5lZ290aWF0aW9uIGFuZCBwdWJsaWMgcmVzZXQgcGFja2V0cywgdGhlIHJlc3Qgb2YgdGhlIHR5 cGVzIGFyZSBkYXRhIGJlYXJpbmcgcGFja2V0cyAod2l0aCBvciB3aXRob3V0IHNvbWUgZmllbGRz IGFuZCBrZXkgcGhhc2Ugc2lnbmFsaW5nKSBhbmQgc2hvdWxkIGJlIHRyZWF0ZWQgYXMgc3VjaC4g QXMgdG8gZ29pbmcgZnJvbSBjb2RlcG9pbnQgdG8gYml0cyB0aGF0IGluZGljYXRlIHByZXNlbmNl IG9mIGZpZWxkcywgaXQncyBhIHNpbXBsZSBtYXR0ZXIgb2YgbWFwcGluZyBjb2RlcG9pbnRzIHRv IGxvY2FsIHBlci1wYWNrZXQgc3RhdGUsIGFuZCB5b3UgY29udGludWUgcHJvY2Vzc2luZyB0aGUg cGFja2V0IHdpdGggdGhlIGxvY2FsIHN0YXRlLg0KDQpJIGRvbid0IHRoaW5rIHlvdSBuZWVkIGV4 cGxpY2l0IGJpdHM7IG1hcHBpbmcgZnJvbSBhIGNvZGVwb2ludCB0byBleHBsaWNpdCBiaXRzIGF0 IHRoZSBlbmRwb2ludHMgc2hvdWxkIHdvcmsgZmluZSBJTU8uDQoNCi0gamFuYQ0KDQpPbiBXZWQs IEZlYiAxNSwgMjAxNyBhdCA0OjQ4IEFNLCBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208 bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PiB3cm90ZToNCkkgbGlrZSB0aGlzIGdlbmVyYWwg YXBwcm9hY2ggYSBsb3QsIGJlY2F1c2UgaXQgZGVmaW5lcyBhIGNvbnNpc3RlbnQgc2V0IG9mIGVh c3kgdG8gcGFyc2UgcGFja2V0cyBmb3IgcHJpb3IgdG8gdmVyc2lvbiBuZWdvdGlhdGlvbiwgYW5k IGFsbG93cyBwbGVudHkgb2YgZXh0ZW5zaWJpbGl0eSBib3RoIHByZSBhbmQgcG9zdCB2ZXJzaW9u IG5lZ290aWF0aW9uIGlmIHdlIG5lZWQgaXQuICBIYXZpbmcgY29ubmVjdGlvbiBJRCBjb21lIGFm dGVyIHRoZSBmbGFncyBieXRlIGZlZWxzIHJpZ2h0LCBiZWNhdXNlIGl0J3Mgcm91dGluZyBpbmZv LiAgSSBhbHNvIHRoaW5rIGl0J2xsIGJlIHJlbGF0aXZlbHkgZWFzeSB0byBpbXBsZW1lbnQuDQoN Ck1pcmphLCB0byBhZGRyZXNzIHlvdXIgcG9pbnQgYWJvdXQgZXh0ZW5zaWJpbGl0eS4gIEkgdGhp bmsgd2Ugd2FudCB0aGUgYWJpbGl0eSB0byBldm9sdmUgdGhlIGRlc2lnbiBhbmQgYWRkIG5ldyBm ZWF0dXJlcywgaW4gdGhpcyBjYXNlIHZpYSBwYWNrZXQgdHlwZXMuICBPbmUgY2FuIGltYWdpbmUg YWRkaW5nIGFuIDggYnl0ZSBwYWNrZXQgbnVtYmVyIGZvcm1hdCBpbiB0aGUgZnV0dXJlLCBmb3Ig ZXhhbXBsZSwgb3IgZXZlbiBhIGZvcm1hdCB3aXRoIE1hcnRpbidzIGF1dGhlbnRpY2F0ZWQgcmVw ZWF0ZWQgb3B0aW9ucyBpZiB3ZSBkZWNpZGUgaXQncyBjb21wZWxsaW5nPw0KDQpNaXJqYSwgcmUg IzMgYWJvdXQgcGFja2V0IG51bWJlciBzaXplcy4gIFRoaXMgaXMgdmVyeSBtdWNoIGFib3V0IHVz ZXItZmFjaW5nIHRyYWZmaWMsIG5vdCBkYXRhY2VudGVycy4gIDIgYnl0ZXMgaXMgZW5vdWdoIGZv ciBhbGwgdGhlIHVzZXIgZmFjaW5nIHRyYWZmaWMgd2UgaGF2ZSB0b2RheS4gIEJ1dCB0aGF0IGFs bG93cyBhIG1heCBDV05EIHRoYXQncyBsZXNzIHRoYW4gd2hhdCBUQ1AgYWxsb3dzLCBzbyA0IGJ5 dGVzIHdhcyBhZGRlZCBiZWNhdXNlIGl0IHNlZW1lZCBmYWlybHkgZnV0dXJlcHJvb2YuICAxIGJ5 dGUgaXNuJ3QgcmVhbGx5IHRoYXQgbmVjZXNzYXJ5LCB0aG91Z2ggaXQncyBjb21tb25seSB1c2Vk IG9uIHNob3J0IGNvbm5lY3Rpb25zIGFuZCBpdCdzIHJlYWxseSBlYXN5IHRvIGltcGxlbWVudCBh bmQgd2UgdXNlIGl0IHRvZGF5LCBzbyBKYW5hIGRlZmluZWQgaXQuDQoNCk1hcnRpbiBhbmQgTWly amEsIHJlOiBXaGVuIHRvIGluY2x1ZGUgY29ubmVjdGlvbiBJRDogWWVzLCBpdCdzIGNsZWFyIHRo aXMgbmVlZHMgbW9yZSBkaXNjdXNzaW9uLiAgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBoYXZl IGJvdGggc2V0cyBvZiBjb2RlcG9pbnRzIGluIHRoZXJlIGZvciBub3csIGFuZCB3ZSBjYW4gcmVt b3ZlIHRoZW0gbGF0ZXIgaWYgd2UgcmVhbGx5IHRoaW5rIGNvbm5lY3Rpb24gSUQgaXMgbmV2ZXIg bmVjZXNzYXJ5LiAgQ3VycmVudGx5LCBpdCdzIG5lY2Vzc2FyeSBpbiBjYXNlcyB3aGVuIE5BVHMg cmFwaWRseSByZWJpbmQuDQoNCkkgZG8gdGhpbmsgd2UgbmVlZCBhIGxvbmctZm9ybSBwYWNrZXQg dGhhdCBjYW4gY2FycnkgMS1SVFQsIGFuZCBJIHRoaW5rIGl0J3MgY3JpdGljYWwgaWYgd2Ugd2Fu dCB0byBkcm9wIGNvbm5lY3Rpb24gSUQgZnJvbSBzaG9ydCBmb3JtIHBhY2tldHMsIHNpbmNlIGl0 IGNvdWxkIGFsbG93IHVzIHRvIHJlLWVzdGFibGlzaCBhIGNvbm5lY3Rpb24gd2l0aCB0aGUgc2Ft ZSBzZXJ2ZXIgdXNpbmcgYSBuZXcgZGlmZmVyZW50IElELiAgSXQncyBhbHNvIHVzZWZ1bCBmb3Ig b3V0IG9mIGJhbmQga2V5IG5lZ290aWF0aW9uLCB3aGljaCBJIGJlbGlldmUgaXMgd2h5IEphbmEg YWRkZWQgaXQuDQoNCklmIHdlJ3JlIG9ubHkgZ29pbmcgdG8gaW5jbHVkZSBjb25uZWN0aW9uIElE IGluIHBhY2tldHMgd2hpY2ggYWxzbyBjb250YWluIHZlcnNpb24sIHdlIGNvdWxkIGJ1bXAgdGhl IGxlbmd0aCB0byAxNiBieXRlcyBpZiB0aGVyZSdzIGEgY29tcGVsbGluZyB1c2UgY2FzZS4NCg0K VGhpcyBwcm9wb3NhbCBhbHNvIGFsbG93cyB1cyB0byBncmVhc2UgZXZlcnkgdW5lbmNyeXB0ZWQg Ynl0ZSBpbiB0aGUgcGFja2V0LCB3aGljaCBtYWtlcyBtZSBleGNpdGVkLCBidXQgSSdsbCB3cml0 ZSB0aGF0IHVwIG9uIHRoZSBncmVhc2UgaXNzdWUuDQoNCk9uIFdlZCwgRmViIDE1LCAyMDE3IGF0 IDY6MTcgQU0sIE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208bWFpbHRv Om1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4+IHdyb3RlOg0KT24gMTUgRmVicnVhcnkgMjAxNyBh dCAyMDoxNCwgTWlyamEgS8O8aGxld2luZA0KPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHou Y2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+PiB3cm90ZToNCj4gNCkg QW5kIGZpbmFsbHksIEkgdGhpbmsgaXQgd291bGQgYmUgc2FmZXIgdG8gaGF2ZSB0aGUgY29ubmVj dGlvbiBJRCBvbiBhbGwNCj4gcGFja2V0cy4gQnV0IG1heWJlIHdlIGNhbiBqdXN0IHVzZSBhIHNo b3J0ZXIgY29ubmVjdGlvbiBJRD8gV2hhdCdzIHRoZQ0KPiByZWFzb24gZm9yIGEgNjQgYml0cyBj b25uZWN0aW9uIElEIGFnYWluPw0KDQpJZiBhbnl0aGluZyBJIHRoaW5rIHRoYXQgNjQgYml0cyBp cyB0b28gc2hvcnQgOikgIFNlcnZlciBwZW9wbGUga2VlcA0KYXNraW5nIGZvciBtb3JlIGFueXdh eS4gIE1hbmFnaW5nIHJvdXRpbmcsIGF1dGhlbnRpY2F0aW9uIGFuZCB3aGF0ZXZlcg0KZWxzZSB0 aGlzIGZpZWxkIG1pZ2h0IGJlIHVzZWQgZm9yLCBhbGwgaW4gYSBtZXJlIDY0IGJpdHMsIGlzIHBy ZXR0eQ0KY2hhbGxlbmdpbmcuDQoNCkkgdGhpbmsgdGhhdCB0aGUgbm90aW9uIG9mIHJlbW92aW5n IGNvbm5lY3Rpb24gSUQgbmVlZHMgYSBsb3QgbW9yZQ0KZGlzY3Vzc2lvbi4gIFJlYXNvbnMgSSBj YW4gc2VlIGZvciByZW1vdmluZyBpdCBhcmUgdGhhdCB0aGUgc2VydmVyDQpkb2Vzbid0IG5lZWQg aXQsIG9yIHRoZSBjbGllbnQgZG9lc24ndCB3YW50IGl0IChoZWxsbyBsaW5rYWJpbGl0eSkuDQpS ZW1vdmluZyBpdCBkb2VzIGplb3BhcmRpemUgc29tZSBjb25uZWN0aW9uIG1pZ3JhdGlvbiBjYXNl cyB0aG91Z2gsIHNvDQp3ZSBwcm9iYWJseSB3YW50IHRvIHdvcmsgdGhyb3VnaCB0aGUgdXNlIGNh c2VzIGluIG1vcmUgZGV0YWlsLg0KDQoNCg0K --_000_BN6PR03MB270846AFA9914DDC52210405875B0BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE0OTg4ODAwNTQ7DQoJbXNvLWxpc3QtdHlw ZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTc2MTAwMDAgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3Qg bDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMg djpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFw IHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlm XS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 IHNlZW1zIGxpa2UgdGhlcmXigJlzIGFuIGVtZXJnaW5nIGlkZWEgKHdoaWNoIGhhcyBiZWVuIHBy ZXNlbnQgYWxsIGFsb25nKSB0aGF0IHRoZXJlIGFyZSByZWFsbHkgdHdvIHN1YmRpdmlzaW9ucyBv ZiBRVUlDOjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPlFVSUMtZm9yLWFsbC10aW1lOiZuYnNwOyBGb3Jl dmVyLWZpeGVkIHBhY2tldCBsYXlvdXRzIGNhcnJ5aW5nIHZlcnNpb24gbmVnb3RpYXRpb24sIHB1 YmxpYyByZXNldCwgZXRjLjsgY2FuIGNhcnJ5IHZlcnNpb24tc3BlY2lmaWMgaGVhZGVycy9wYXls b2FkIGFzIHdlbGwgaWYgeW914oCZdmUgYWdyZWVkIG9uIHRoZSB2ZXJzaW9uPG86cD48L286cD4N Cjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1z b0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwy IGxmbzEiPklmIHlvdSBjaGFuZ2UgdGhlc2UsIHlvdeKAmXJlIGRlZmluaW5nIGEgbmV3IHByb3Rv Y29sIHRoYXQgaGFzIHRvIGJlIGRpc3Rpbmd1aXNoYWJsZSBmcm9tIFFVSUMgaW4gc29tZSB3YXk8 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5RVUlDLWZvci1u b3c6Jm5ic3A7IFZlcnNpb24tc3BlY2lmaWMgcGFja2V0IGxheW91dHMgY2FycnlpbmcgdmVyc2lv bi1zcGVjaWZpYyBwYXlsb2FkPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNvdW5k cyBsaWtlIHdoYXQgeW914oCZcmUgc2F5aW5nIGhlcmUgaXMgdGhhdCBhbGwgbG9uZy1mb3JtIHBh Y2tldCBjb2RlcG9pbnRzIGFyZSBwYXJ0IG9mIFFVSUMtZm9yLWFsbC10aW1lIChkZWxpYmVyYXRl bHkgbm90IGNvaW5pbmcgdGhlIHRlcm0g4oCcUUZBVOKAnSksIGFuZCBhIHJlY2VpdmVyIGhhcyB0 byBhc3N1bWUgdGhhdCBhbnkgb3RoZXIgY29kZXBvaW50DQo8aT5taWdodDwvaT4gYmUgcGFydCBv ZiBRVUlDLWZvci1ub3cgaW4gYSB2ZXJzaW9uIGl0IGRvZXNu4oCZdCBrbm93ICh3aGljaCBnZXRz IGRyb3BwZWQsIGVpdGhlciBiZWNhdXNlIGl0IGtub3dzIHRoZSBwdXJwb3J0ZWQgdmVyc2lvbiBh bmQgZG9lc27igJl0IHJlY29nbml6ZSB0aGUgY29kZXBvaW50IG9yIGRvZXNu4oCZdCBrbm93IHRo ZSBwdXJwb3J0ZWQgdmVyc2lvbiBhbmQgaXQgc2hvdWxkbuKAmXQgYmUgc2VlaW5nIHRob3NlIHdp dGhvdXQgbmVnb3RpYXRpb24NCiBoYXZpbmcgY29tcGxldGVkKS48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q3VycmVudGx5LCB3ZSBkZXNjcmliZSB0aGUgd2hvbGUgdGhpbmcgdG9nZXRoZXIsIGFu ZCBoYXZlIGEgZm9sbG93LXVwIHNlY3Rpb24gdGhhdCBzYXlzIOKAnEJUVywgdGhlc2UgdGhpbmdz IHdvbuKAmXQgY2hhbmdlIGluIGZ1dHVyZSB2ZXJzaW9ucy7igJ0mbmJzcDsgV2l0aG91dCBuZWNl c3NhcmlseSBzcGxpdHRpbmcgUVVJQy1mb3ItYWxsLXRpbWUgaW50byBhIHNlcGFyYXRlIGRvY3Vt ZW50LCBpdCBtaWdodCBiZSB1c2VmdWwgdG8NCiB0ZWFzZSB0aGF0IGxpbmUgYXBhcnQgZnVydGhl ciBhbmQgbWFrZSB0aGUgaW1tdXRhYmxlIHN0dWZmIGF0IGxlYXN0IGEgZnVsbHkgc2VwYXJhdGUg c2VjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPkphbmEgSXllbmdh cjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDE1LCAyMDE3IDI6MjcgUE08 YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBEdWtlICZsdDttYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSZn dDs8YnI+DQo8Yj5DYzo8L2I+IE1pcmphIEvDvGhsZXdpbmQgJmx0O21pcmphLmt1ZWhsZXdpbmRA dGlrLmVlLmV0aHouY2gmZ3Q7OyBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7 OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBNYXJ0aW4gVGhvbXNvbiAmbHQ7 bWFydGluLnRob21zb25AZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogQWx0 ZXJuYXRlIGhlYWRlciBwcm9wb3NhbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAxNSwgMjAxNyBhdCAxMTowOCBBTSwgTWFydGluIER1a2Ug Jmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxh bmsiPm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgcGFj a2V0IGZvcm1hdHMgbG9vayBncmVhdC4gSSBhbHNvIGxpa2UgdGhlIGlkZWEgb2YgYSB2ZXJzaW9u LWFnbm9zdGljIGxvbmcgZm9ybSBoZWFkZXIgd2l0aCB2ZXJzaW9uIGNvbXBsZXhpdHkgb25seSBp biB0aGUgc2hvcnQgZm9ybS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QnV0IEkgaGF2ZSBpc3N1ZXMgd2l0aCB0aGUgZmlyc3QgYnl0ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGVyaGFw cyBJJ20gbWlzc2luZyBzb21ldGhpbmcgc2ltcGxlIGhlcmUsIGJ1dCBob3cgZG9lcyAweDggc3Bl Y2lmeSBzaG9ydC9sb25nIGZvcm0/IFRoZSBmaXJzdCBzaXggc2hvcnQgaGVhZGVycyBKYW5hIHBy ZXNlbnRlZCBkaWZmZXIgaW4gdGhpcyBiaXQgZnJvbSB0aGUgc2Vjb25kIHNpeC4gSW4gZmFjdCB0 aGVyZSBpcyBubyBiaXQgdGhhdCBpcyBjb25zaXN0ZW50bHkgc2V0IGluIHRoZSBzaG9ydCBmb3Jt IHdoaWxlDQogY2xlYXJlZCBpbiB0aGUgbG9uZyBmb3JtLCBvciB2aWNlIHZlcnNhLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPllvdSdyZSByaWdodCwgdGhlcmUncyBubyBzaW5nbGUgYml0IHRoYXQgY2Fu IGJlIHVzZWQgaW4gdGhpcyBwcm9wb3NhbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8Ymxv Y2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBw dDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdo dDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvLCB3ZSBoYXZl IGEgbnVtYmVyIG9mIG91dHN0YW5kaW5nIG1hbmFnZWFiaWxpdHkgaXNzdWVzIHRoYXQgY291bGQg dXNlIDItMyBiaXRzIGluIHRoZSBwdWJsaWMgZmxhZ3MsIGFuZCBJJ2QgbGlrZSB0byBjb21wcmVz cyB0aGUgdXNlcyBoZXJlIHRvIG1ha2Ugc3BhY2UgZm9yIHRob3NlLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi4uLiBvciB3ZSBjb3VsZCBhZGQgbW9yZSBjb2RlcG9pbnRzLiBXZSBjYW4gbWFrZSB0aGUg Y29kZXBvaW50cyBjb250aWd1b3VzIGlmIHRoYXQgaGVscHMuIExldCdzIGRpc2N1c3MgdGhlIGlz c3VlcyBpbmRlcGVuZGVudCBvZiByZXByZXNlbnRhdGlvbiBmaXJzdCwgYW5kIHRoZW4gZmlndXJl IG91dCByZXByZXNlbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90 ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRk aW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4i Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GdXJ0aGVybW9yZSwgSSB0aGlu ayBoYXZpbmcgYW4gYWN0dWFsIGxvbmcvc2hvcnQgYml0IHdvdWxkIGJlIHF1aXRlIHVzZWZ1bCBh bmQgSSdkIGxpa2UgdG8gYXJyYW5nZSB0aGUgY29kZXBvaW50cyB0byBhbGxvdyB0aGF0LjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBJIHRo aW5rIHByb2Nlc3Npbmcgd291bGQgYmUgc29tZXdoYXQgZWFzaWVyIHdpdGggdGhlIGZvbGxvd2lu ZyBhcnJhbmdlbWVudDo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjB4ODA6IExvbmcgRm9ybSBoZWFkZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGEgbG9uZyBmb3JtIGhlYWRlcjo8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAweDgw LTB4ZDAgLSBjb3ZlcnMgdGhlIHNpeCB0eXBlcyBvZiBsb25nLWZvcm0gcGFja2V0PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgVGhlIGxh c3QgNCBhcmUgcmVzZXJ2ZWQsIGFuZCBncmVhc2VkIGlmIHdlIGRvbid0IGZpbmQgdXNlcyBmb3Ig dGhlbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SWYgYSBzaG9ydCBmb3JtIGhlYWRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IDB4NDAgLSBrZXkgcGhhc2U8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAweDIwIC0gY29ubiBJ ZCBpbmNsdWRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7IDB4MTAgYW5kIDB4MDggLSBwa3QgIyBsZW5ndGg8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBUaGUgbGFzdCB0aHJl ZSBiaXRzIGFyZSByZXNlcnZlZC9ncmVhc2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgbG9v a3MgY2xvc2UgdG8gYW4gaW50ZXJtZWRpYXRlIHByb3Bvc2FsIEkgaGFkIGNvbWUgdXAgd2l0aCA6 LSkgSSdtIG5vdCBvcHBvc2VkIHRvIHRoaXMsIGJ1dCBpdCBtYWtlcyB0aGUgc3BsaXQgYmV0d2Vl biBsb25nIGFuZCBzaG9ydCBmb3JtcyBtb3JlIGV4cGxpY2l0IHRoYW4gbmVjZXNzYXJ5LiBJIGRv bid0IHRoaW5rIHByb2Nlc3NpbmcgaXMgaGFyZGVyIHdpdGggdGhlIGN1cnJlbnQgcHJvcG9zYWws DQogdGhvdWdoIHN1cmUsIHlvdSBjb3VsZCBtYWtlIHRoZSBwYWNrZXQgdHlwZXMgY29udGlndW91 cyBpZiB0aGF0IGhlbHBzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JbXBvcnRhbnRseSwgdGhlIHR3byBmb3JtcyBhcmUgbm90IHJlYWxseSB0 aGF0IGRpZmZlcmVudCBmcm9tIGEgcHJvY2Vzc2luZyBwb2ludC1vZi12aWV3IGlmIHlvdSBsb29r IGNsb3NlbHk7IHRoZSBzZXBhcmF0aW9uIGlzIHJlYWxseSBtb3JlIHVzZWZ1bCBmb3IgcmVhc29u aW5nIGFuZCB1bmRlcnN0YW5kaW5nLiBUaGVyZSBpcyB0aGUgZGlzdGluY3Rpb24gb2YgdGhlIHNo b3J0IGZvcm0gYmVpbmcgdmVyc2lvbi1zcGVjaWZpYywNCiBidXQgdGhhdCdzIHJlYWxseSBvbmx5 IHRvIHNheSB0aGF0IGEgcmVjZWl2ZXIgdGhhdCBuZWdvdGlhdGVzIHZlcnNpb24gWCBzaG91bGQg b25seSBwcm9jZXNzIHRoZSBjb2RlcG9pbnRzIGRlZmluZWQgZm9yIHRoYXQgdmVyc2lvbi4mbmJz cDsgRXhjZXB0IGZvciB0aGUgdmVyc2lvbiBuZWdvdGlhdGlvbiBhbmQgcHVibGljIHJlc2V0IHBh Y2tldHMsIHRoZSByZXN0IG9mIHRoZSB0eXBlcyBhcmUgZGF0YSBiZWFyaW5nIHBhY2tldHMgKHdp dGggb3Igd2l0aG91dA0KIHNvbWUgZmllbGRzIGFuZCBrZXkgcGhhc2Ugc2lnbmFsaW5nKSBhbmQg c2hvdWxkIGJlIHRyZWF0ZWQgYXMgc3VjaC4gQXMgdG8gZ29pbmcgZnJvbSBjb2RlcG9pbnQgdG8g Yml0cyB0aGF0IGluZGljYXRlIHByZXNlbmNlIG9mIGZpZWxkcywgaXQncyBhIHNpbXBsZSBtYXR0 ZXIgb2YgbWFwcGluZyBjb2RlcG9pbnRzIHRvIGxvY2FsIHBlci1wYWNrZXQgc3RhdGUsIGFuZCB5 b3UgY29udGludWUgcHJvY2Vzc2luZyB0aGUgcGFja2V0IHdpdGggdGhlIGxvY2FsDQogc3RhdGUu Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkkgZG9uJ3QgdGhpbmsgeW91IG5lZWQgZXhwbGljaXQgYml0czsgbWFwcGluZyBmcm9tIGEg Y29kZXBvaW50IHRvIGV4cGxpY2l0IGJpdHMgYXQgdGhlIGVuZHBvaW50cyBzaG91bGQgd29yayBm aW5lIElNTy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+LSBqYW5hPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEZlYiAx NSwgMjAxNyBhdCA0OjQ4IEFNLCBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0 dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDtt YXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGxpa2UgdGhpcyBnZW5lcmFsIGFwcHJvYWNoIGEgbG90LCBiZWNhdXNlIGl0IGRl ZmluZXMgYSBjb25zaXN0ZW50IHNldCBvZiBlYXN5IHRvIHBhcnNlIHBhY2tldHMgZm9yIHByaW9y IHRvIHZlcnNpb24gbmVnb3RpYXRpb24sIGFuZCBhbGxvd3MgcGxlbnR5IG9mIGV4dGVuc2liaWxp dHkgYm90aCBwcmUgYW5kIHBvc3QgdmVyc2lvbiBuZWdvdGlhdGlvbiBpZiB3ZSBuZWVkIGl0LiZu YnNwOyBIYXZpbmcgY29ubmVjdGlvbg0KIElEIGNvbWUgYWZ0ZXIgdGhlIGZsYWdzIGJ5dGUgZmVl bHMgcmlnaHQsIGJlY2F1c2UgaXQncyByb3V0aW5nIGluZm8uJm5ic3A7IEkgYWxzbyB0aGluayBp dCdsbCBiZSByZWxhdGl2ZWx5IGVhc3kgdG8gaW1wbGVtZW50LjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWlyamEsIHRvIGFkZHJlc3MgeW91ciBwb2ludCBh Ym91dCBleHRlbnNpYmlsaXR5LiZuYnNwOyBJIHRoaW5rIHdlIHdhbnQgdGhlIGFiaWxpdHkgdG8g ZXZvbHZlIHRoZSBkZXNpZ24gYW5kIGFkZCBuZXcgZmVhdHVyZXMsIGluIHRoaXMgY2FzZSB2aWEg cGFja2V0IHR5cGVzLiZuYnNwOyBPbmUgY2FuIGltYWdpbmUgYWRkaW5nIGFuIDggYnl0ZSBwYWNr ZXQgbnVtYmVyIGZvcm1hdCBpbiB0aGUgZnV0dXJlLCBmb3IgZXhhbXBsZSwNCiBvciBldmVuIGEg Zm9ybWF0IHdpdGggTWFydGluJ3MgYXV0aGVudGljYXRlZCByZXBlYXRlZCBvcHRpb25zIGlmIHdl IGRlY2lkZSBpdCdzIGNvbXBlbGxpbmc/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pcmphLCByZSAjMyBhYm91dCBwYWNrZXQgbnVtYmVyIHNp emVzLiZuYnNwOyBUaGlzIGlzIHZlcnkgbXVjaCBhYm91dCB1c2VyLWZhY2luZyB0cmFmZmljLCBu b3QgZGF0YWNlbnRlcnMuICZuYnNwOzIgYnl0ZXMgaXMgZW5vdWdoIGZvciBhbGwgdGhlIHVzZXIg ZmFjaW5nIHRyYWZmaWMgd2UgaGF2ZSB0b2RheS4mbmJzcDsgQnV0IHRoYXQgYWxsb3dzIGEgbWF4 IENXTkQgdGhhdCdzIGxlc3MgdGhhbiB3aGF0IFRDUCBhbGxvd3MsIHNvIDQNCiBieXRlcyB3YXMg YWRkZWQgYmVjYXVzZSBpdCBzZWVtZWQgZmFpcmx5IGZ1dHVyZXByb29mLiAmbmJzcDsxIGJ5dGUg aXNuJ3QgcmVhbGx5IHRoYXQgbmVjZXNzYXJ5LCB0aG91Z2ggaXQncyBjb21tb25seSB1c2VkIG9u IHNob3J0IGNvbm5lY3Rpb25zIGFuZCBpdCdzIHJlYWxseSBlYXN5IHRvIGltcGxlbWVudCBhbmQg d2UgdXNlIGl0IHRvZGF5LCBzbyBKYW5hIGRlZmluZWQgaXQuICZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYXJ0aW4gYW5kIE1pcmph LCByZTogV2hlbiB0byBpbmNsdWRlIGNvbm5lY3Rpb24gSUQ6IFllcywgaXQncyBjbGVhciB0aGlz IG5lZWRzIG1vcmUgZGlzY3Vzc2lvbi4mbmJzcDsgSSB0aGluayBpdCBtYWtlcyBzZW5zZSB0byBo YXZlIGJvdGggc2V0cyBvZiBjb2RlcG9pbnRzIGluIHRoZXJlIGZvciBub3csIGFuZCB3ZSBjYW4g cmVtb3ZlIHRoZW0gbGF0ZXIgaWYgd2UgcmVhbGx5IHRoaW5rIGNvbm5lY3Rpb24gSUQgaXMNCiBu ZXZlciBuZWNlc3NhcnkuJm5ic3A7IEN1cnJlbnRseSwgaXQncyBuZWNlc3NhcnkgaW4gY2FzZXMg d2hlbiBOQVRzIHJhcGlkbHkgcmViaW5kLiAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBkbyB0aGluayB3ZSBuZWVkIGEgbG9uZy1m b3JtIHBhY2tldCB0aGF0IGNhbiBjYXJyeSAxLVJUVCwgYW5kIEkgdGhpbmsgaXQncyBjcml0aWNh bCBpZiB3ZSB3YW50IHRvIGRyb3AgY29ubmVjdGlvbiBJRCBmcm9tIHNob3J0IGZvcm0gcGFja2V0 cywgc2luY2UgaXQgY291bGQgYWxsb3cgdXMgdG8gcmUtZXN0YWJsaXNoIGEgY29ubmVjdGlvbiB3 aXRoIHRoZSBzYW1lIHNlcnZlciB1c2luZyBhIG5ldyBkaWZmZXJlbnQNCiBJRC4mbmJzcDsgSXQn cyBhbHNvIHVzZWZ1bCBmb3Igb3V0IG9mIGJhbmQga2V5IG5lZ290aWF0aW9uLCB3aGljaCBJIGJl bGlldmUgaXMgd2h5IEphbmEgYWRkZWQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIHdlJ3JlIG9ubHkgZ29pbmcgdG8gaW5jbHVkZSBj b25uZWN0aW9uIElEIGluIHBhY2tldHMgd2hpY2ggYWxzbyBjb250YWluIHZlcnNpb24sIHdlIGNv dWxkIGJ1bXAgdGhlIGxlbmd0aCB0byAxNiBieXRlcyBpZiB0aGVyZSdzIGEgY29tcGVsbGluZyB1 c2UgY2FzZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyBwcm9wb3NhbCBhbHNvIGFsbG93cyB1cyB0byBncmVhc2UgZXZlcnkg dW5lbmNyeXB0ZWQgYnl0ZSBpbiB0aGUgcGFja2V0LCB3aGljaCBtYWtlcyBtZSBleGNpdGVkLCBi dXQgSSdsbCB3cml0ZSB0aGF0IHVwIG9uIHRoZSBncmVhc2UgaXNzdWUuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24g V2VkLCBGZWIgMTUsIDIwMTcgYXQgNjoxNyBBTSwgTWFydGluIFRob21zb24gJmx0OzxhIGhyZWY9 Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5tYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1 b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBp biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPk9u IDE1IEZlYnJ1YXJ5IDIwMTcgYXQgMjA6MTQsIE1pcmphIEvDvGhsZXdpbmQ8YnI+DQombHQ7PGEg aHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2giIHRhcmdldD0iX2Js YW5rIj5taXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPC9hPiZndDsgd3JvdGU6PGJyPg0K Jmd0OyA0KSBBbmQgZmluYWxseSwgSSB0aGluayBpdCB3b3VsZCBiZSBzYWZlciB0byBoYXZlIHRo ZSBjb25uZWN0aW9uIElEIG9uIGFsbDxicj4NCiZndDsgcGFja2V0cy4gQnV0IG1heWJlIHdlIGNh biBqdXN0IHVzZSBhIHNob3J0ZXIgY29ubmVjdGlvbiBJRD8gV2hhdCdzIHRoZTxicj4NCiZndDsg cmVhc29uIGZvciBhIDY0IGJpdHMgY29ubmVjdGlvbiBJRCBhZ2Fpbj88YnI+DQo8YnI+DQpJZiBh bnl0aGluZyBJIHRoaW5rIHRoYXQgNjQgYml0cyBpcyB0b28gc2hvcnQgOikmbmJzcDsgU2VydmVy IHBlb3BsZSBrZWVwPGJyPg0KYXNraW5nIGZvciBtb3JlIGFueXdheS4mbmJzcDsgTWFuYWdpbmcg cm91dGluZywgYXV0aGVudGljYXRpb24gYW5kIHdoYXRldmVyPGJyPg0KZWxzZSB0aGlzIGZpZWxk IG1pZ2h0IGJlIHVzZWQgZm9yLCBhbGwgaW4gYSBtZXJlIDY0IGJpdHMsIGlzIHByZXR0eTxicj4N CmNoYWxsZW5naW5nLjxicj4NCjxicj4NCkkgdGhpbmsgdGhhdCB0aGUgbm90aW9uIG9mIHJlbW92 aW5nIGNvbm5lY3Rpb24gSUQgbmVlZHMgYSBsb3QgbW9yZTxicj4NCmRpc2N1c3Npb24uJm5ic3A7 IFJlYXNvbnMgSSBjYW4gc2VlIGZvciByZW1vdmluZyBpdCBhcmUgdGhhdCB0aGUgc2VydmVyPGJy Pg0KZG9lc24ndCBuZWVkIGl0LCBvciB0aGUgY2xpZW50IGRvZXNuJ3Qgd2FudCBpdCAoaGVsbG8g bGlua2FiaWxpdHkpLjxicj4NClJlbW92aW5nIGl0IGRvZXMgamVvcGFyZGl6ZSBzb21lIGNvbm5l Y3Rpb24gbWlncmF0aW9uIGNhc2VzIHRob3VnaCwgc288YnI+DQp3ZSBwcm9iYWJseSB3YW50IHRv IHdvcmsgdGhyb3VnaCB0aGUgdXNlIGNhc2VzIGluIG1vcmUgZGV0YWlsLjxvOnA+PC9vOnA+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_BN6PR03MB270846AFA9914DDC52210405875B0BN6PR03MB2708namp_-- From nobody Wed Feb 15 15:14:44 2017 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 40E751298D5 for ; Wed, 15 Feb 2017 15:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 f3Z-J2mMKa-U for ; Wed, 15 Feb 2017 15:14:41 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 8025D1293E3 for ; Wed, 15 Feb 2017 15:05:18 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id 45so690399otd.2 for ; Wed, 15 Feb 2017 15:05:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qu5bIw51G39IROJurSTPfgo8YAvHD79FR1jTpN23gzk=; b=KO4g+Lz4FYtSUDOoIdsKSFhhLCyC68Qp4RUmE9OpfuzwjG7lhVFF+1LJ3VVIGEm0Gu KwyKm28gMnJcZAqawu5EpulTt8pHyH8Mr/IUEcDmB7/Ka2OdO/moBaYeIytjNbugAdgo S8mS5zGKo+B9rtEgLZ2C0/xGfGVra7t2LG6+7vDCjABACwdpP4YJEn5WghOObZXzEF0M XYgTfuhi39CzXOFiRc6KkeEuDAVDxFZgFVdzkyUL2TmVs56ezeU+6SbrSTok57HCqkmP APb2Kut6r94H2JxXcXUCSXITyUQQxQltCVF+s3OEnTZaVgVRsw1PXhc62fBSscn+NSAY O1mQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qu5bIw51G39IROJurSTPfgo8YAvHD79FR1jTpN23gzk=; b=HkstWArlO2NGpJClZA/J+B/ChT7kgDphx6ntIQyKNK8fMLWdzhHCvPFxUcVzQFlChX 7Fz2vj0p1JNtYPIi3ZPe2+yPAhQGvI34oKq4Tr7Ch+rxgWABDw42EqTNAriRh/BStgiQ gMQyrHj9jwIp12SIJktqRh7g1zGFa1gveNnjUjRkiqh7F2Sjx+Sab9zXuMhZ8YK8GIhQ srKLJcnneN6ZLzUTNI2dxaD6ezPJ4xLFgoXlPZDl7PAiMTkVUWbZxvBgV+G901eFS+1P 3miREa5uwJTdt4fcM36UrdVgauKdTpHK+OD9J0CUSPeD7o7UyqFcNU4XaQUzCHA4j4WN WtQQ== X-Gm-Message-State: AMke39kRr4BoNkBH43ctEYeRYVU7uZFoxnLX8iatTFjxJj8/8NZI4n+MxwMBPaFSkZVs7ZpJfJxqx+yVMd8ICQ== X-Received: by 10.157.44.150 with SMTP id p22mr3291232otb.34.1487199917842; Wed, 15 Feb 2017 15:05:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.15.182 with HTTP; Wed, 15 Feb 2017 15:05:17 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Wed, 15 Feb 2017 15:05:17 -0800 Message-ID: Subject: Re: Alternate header proposal To: Mike Bishop Content-Type: multipart/alternative; boundary=001a113adf3ed02951054899b6f0 Archived-At: Cc: Jana Iyengar , Ian Swett , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:14:43 -0000 --001a113adf3ed02951054899b6f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable We actually have a "what cannot change in future versions" section, but having it be a whole set of header types is much cleaner than the current text. On Wed, Feb 15, 2017 at 3:01 PM, Mike Bishop wrote: > It seems like there=E2=80=99s an emerging idea (which has been present al= l along) > that there are really two subdivisions of QUIC: > > - QUIC-for-all-time: Forever-fixed packet layouts carrying version > negotiation, public reset, etc.; can carry version-specific headers/pa= yload > as well if you=E2=80=99ve agreed on the version > - If you change these, you=E2=80=99re defining a new protocol that = has to > be distinguishable from QUIC in some way > - QUIC-for-now: Version-specific packet layouts carrying > version-specific payload > > > > It sounds like what you=E2=80=99re saying here is that all long-form pack= et > codepoints are part of QUIC-for-all-time (deliberately not coining the te= rm > =E2=80=9CQFAT=E2=80=9D), and a receiver has to assume that any other code= point *might* be > part of QUIC-for-now in a version it doesn=E2=80=99t know (which gets dro= pped, > either because it knows the purported version and doesn=E2=80=99t recogni= ze the > codepoint or doesn=E2=80=99t know the purported version and it shouldn=E2= =80=99t be seeing > those without negotiation having completed). > > > > Currently, we describe the whole thing together, and have a follow-up > section that says =E2=80=9CBTW, these things won=E2=80=99t change in futu= re versions.=E2=80=9D > Without necessarily splitting QUIC-for-all-time into a separate document, > it might be useful to tease that line apart further and make the immutabl= e > stuff at least a fully separate section. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar > *Sent:* Wednesday, February 15, 2017 2:27 PM > *To:* Martin Duke > *Cc:* Mirja K=C3=BChlewind ; Ian Swett < > ianswett@google.com>; IETF QUIC WG ; Martin Thomson < > martin.thomson@gmail.com> > *Subject:* Re: Alternate header proposal > > > > On Wed, Feb 15, 2017 at 11:08 AM, Martin Duke > wrote: > > The packet formats look great. I also like the idea of a version-agnostic > long form header with version complexity only in the short form. > > > > But I have issues with the first byte: > > > > Perhaps I'm missing something simple here, but how does 0x8 specify > short/long form? The first six short headers Jana presented differ in thi= s > bit from the second six. In fact there is no bit that is consistently set > in the short form while cleared in the long form, or vice versa. > > > > You're right, there's no single bit that can be used in this proposal. > > > > Also, we have a number of outstanding manageability issues that could use > 2-3 bits in the public flags, and I'd like to compress the uses here to > make space for those. > > > > ... or we could add more codepoints. We can make the codepoints contiguou= s > if that helps. Let's discuss the issues independent of representation > first, and then figure out representation. > > > > Furthermore, I think having an actual long/short bit would be quite usefu= l > and I'd like to arrange the codepoints to allow that. > > > > So I think processing would be somewhat easier with the following > arrangement: > > 0x80: Long Form header > > If a long form header: > > 0x80-0xd0 - covers the six types of long-form packet > > The last 4 are reserved, and greased if we don't find uses for them > > If a short form header > > 0x40 - key phase > > 0x20 - conn Id included > > 0x10 and 0x08 - pkt # length > > The last three bits are reserved/greased. > > > > This looks close to an intermediate proposal I had come up with :-) I'm > not opposed to this, but it makes the split between long and short forms > more explicit than necessary. I don't think processing is harder with the > current proposal, though sure, you could make the packet types contiguous > if that helps. > > > > Importantly, the two forms are not really that different from a processin= g > point-of-view if you look closely; the separation is really more useful f= or > reasoning and understanding. There is the distinction of the short form > being version-specific, but that's really only to say that a receiver tha= t > negotiates version X should only process the codepoints defined for that > version. Except for the version negotiation and public reset packets, th= e > rest of the types are data bearing packets (with or without some fields a= nd > key phase signaling) and should be treated as such. As to going from > codepoint to bits that indicate presence of fields, it's a simple matter = of > mapping codepoints to local per-packet state, and you continue processing > the packet with the local state. > > > > I don't think you need explicit bits; mapping from a codepoint to explici= t > bits at the endpoints should work fine IMO. > > > > - jana > > > > On Wed, Feb 15, 2017 at 4:48 AM, Ian Swett wrote: > > I like this general approach a lot, because it defines a consistent set o= f > easy to parse packets for prior to version negotiation, and allows plenty > of extensibility both pre and post version negotiation if we need it. > Having connection ID come after the flags byte feels right, because it's > routing info. I also think it'll be relatively easy to implement. > > > > Mirja, to address your point about extensibility. I think we want the > ability to evolve the design and add new features, in this case via packe= t > types. One can imagine adding an 8 byte packet number format in the > future, for example, or even a format with Martin's authenticated repeate= d > options if we decide it's compelling? > > > > Mirja, re #3 about packet number sizes. This is very much about > user-facing traffic, not datacenters. 2 bytes is enough for all the user > facing traffic we have today. But that allows a max CWND that's less tha= n > what TCP allows, so 4 bytes was added because it seemed fairly futureproo= f. > 1 byte isn't really that necessary, though it's commonly used on short > connections and it's really easy to implement and we use it today, so Jan= a > defined it. > > > > Martin and Mirja, re: When to include connection ID: Yes, it's clear this > needs more discussion. I think it makes sense to have both sets of > codepoints in there for now, and we can remove them later if we really > think connection ID is never necessary. Currently, it's necessary in cas= es > when NATs rapidly rebind. > > > > I do think we need a long-form packet that can carry 1-RTT, and I think > it's critical if we want to drop connection ID from short form packets, > since it could allow us to re-establish a connection with the same server > using a new different ID. It's also useful for out of band key > negotiation, which I believe is why Jana added it. > > > > If we're only going to include connection ID in packets which also contai= n > version, we could bump the length to 16 bytes if there's a compelling use > case. > > > > This proposal also allows us to grease every unencrypted byte in the > packet, which makes me excited, but I'll write that up on the grease issu= e. > > > > On Wed, Feb 15, 2017 at 6:17 AM, Martin Thomson > wrote: > > On 15 February 2017 at 20:14, Mirja K=C3=BChlewind > wrote: > > 4) And finally, I think it would be safer to have the connection ID on > all > > packets. But maybe we can just use a shorter connection ID? What's the > > reason for a 64 bits connection ID again? > > If anything I think that 64 bits is too short :) Server people keep > asking for more anyway. Managing routing, authentication and whatever > else this field might be used for, all in a mere 64 bits, is pretty > challenging. > > I think that the notion of removing connection ID needs a lot more > discussion. Reasons I can see for removing it are that the server > doesn't need it, or the client doesn't want it (hello linkability). > Removing it does jeopardize some connection migration cases though, so > we probably want to work through the use cases in more detail. > > > > > > > --001a113adf3ed02951054899b6f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We actually have a "what cannot change in future vers= ions" section, but having it be a whole set of header types is much cl= eaner than the current text.

On Wed, Feb 15, 2017 at 3:01 PM, Mike Bishop <= Michael.Bishop@microsoft.com> wrote:

It seems like there=E2=80=99s an emerging idea (whic= h has been present all along) that there are really two subdivisions of QUI= C:

  • QUIC-for-all-time:=C2=A0 Forever-fixed packet layouts carrying version ne= gotiation, public reset, etc.; can carry version-specific headers/payload a= s well if you=E2=80=99ve agreed on the version
    • If you change these, you=E2=80=99re defining a new protocol that has to b= e distinguishable from QUIC in some way
  • QUIC-for-now:=C2=A0 Version-specific packet layouts carrying version= -specific payload

=C2=A0

It sounds like what you=E2=80=99re saying here is th= at all long-form packet codepoints are part of QUIC-for-all-time (deliberat= ely not coining the term =E2=80=9CQFAT=E2=80=9D), and a receiver has to ass= ume that any other codepoint might be part of QUIC-for-now in a version it doesn=E2=80=99t know (= which gets dropped, either because it knows the purported version and doesn= =E2=80=99t recognize the codepoint or doesn=E2=80=99t know the purported ve= rsion and it shouldn=E2=80=99t be seeing those without negotiation having completed).

=C2=A0

Currently, we describe the whole thing together, and= have a follow-up section that says =E2=80=9CBTW, these things won=E2=80=99= t change in future versions.=E2=80=9D=C2=A0 Without necessarily splitting Q= UIC-for-all-time into a separate document, it might be useful to tease that line apart further and make the immutable stuff at least a full= y separate section.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Wednesday, February 15, 2017 2:27 PM
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>;= Ian Swett <ian= swett@google.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Alternate header proposal

=C2=A0

On Wed, Feb 15, 2017 at 11:08 AM, Martin Duke <martin.h.duke@gm= ail.com> wrote:

The packet formats look great. I also like the idea = of a version-agnostic long form header with version complexity only in the = short form.

=C2=A0

But I have issues with the first byte:=

=C2=A0

Perhaps I'm missing something simple here, but h= ow does 0x8 specify short/long form? The first six short headers Jana prese= nted differ in this bit from the second six. In fact there is no bit that i= s consistently set in the short form while cleared in the long form, or vice versa.

=C2=A0

You're right, there's no single bit that can= be used in this proposal.

=C2=A0

Also, we have a number of outstanding manageability = issues that could use 2-3 bits in the public flags, and I'd like to com= press the uses here to make space for those.

=C2=A0

... or we could add more codepoints. We can make the= codepoints contiguous if that helps. Let's discuss the issues independ= ent of representation first, and then figure out representation.<= /u>

=C2=A0

Furthermore, I think having an actual long/short bit= would be quite useful and I'd like to arrange the codepoints to allow = that.

=C2=A0

So I think processing would be somewhat easier with = the following arrangement:

0x80: Long Form header

If a long form header:

=C2=A0 0x80-0xd0 - covers the six types of long-form= packet

=C2=A0 The last 4 are reserved, and greased if we do= n't find uses for them

If a short form header

=C2=A0 0x40 - key phase

=C2=A0 0x20 - conn Id included

=C2=A0 0x10 and 0x08 - pkt # length

=C2=A0 The last three bits are reserved/greased.<= /u>

=C2=A0

This looks close to an intermediate proposal I had c= ome up with :-) I'm not opposed to this, but it makes the split between= long and short forms more explicit than necessary. I don't think proce= ssing is harder with the current proposal, though sure, you could make the packet types contiguous if that helps.<= /u>

=C2=A0

Importantly, the two forms are not really that diffe= rent from a processing point-of-view if you look closely; the separation is= really more useful for reasoning and understanding. There is the distincti= on of the short form being version-specific, but that's really only to say that a receiver that negotiates version = X should only process the codepoints defined for that version.=C2=A0 Except= for the version negotiation and public reset packets, the rest of the type= s are data bearing packets (with or without some fields and key phase signaling) and should be treated as such. As to = going from codepoint to bits that indicate presence of fields, it's a s= imple matter of mapping codepoints to local per-packet state, and you conti= nue processing the packet with the local state.=C2=A0

=C2=A0

I don't think you need explicit bits; mapping fr= om a codepoint to explicit bits at the endpoints should work fine IMO.

=C2=A0

- jana

=C2=A0

On Wed, Feb 15, 2017 at 4:48 AM, Ian Swett <ianswett@google.com= > wrote:

I like this general approach a lot, because it defin= es a consistent set of easy to parse packets for prior to version negotiati= on, and allows plenty of extensibility both pre and post version negotiatio= n if we need it.=C2=A0 Having connection ID come after the flags byte feels right, because it's routing info.= =C2=A0 I also think it'll be relatively easy to implement.

=C2=A0

Mirja, to address your point about extensibility.=C2= =A0 I think we want the ability to evolve the design and add new features, = in this case via packet types.=C2=A0 One can imagine adding an 8 byte packe= t number format in the future, for example, or even a format with Martin's authenticated repeated options if we de= cide it's compelling?

=C2=A0

Mirja, re #3 about packet number sizes.=C2=A0 This i= s very much about user-facing traffic, not datacenters. =C2=A02 bytes is en= ough for all the user facing traffic we have today.=C2=A0 But that allows a= max CWND that's less than what TCP allows, so 4 bytes was added because it seemed fairly futureproof. =C2=A01 byte isn'= ;t really that necessary, though it's commonly used on short connection= s and it's really easy to implement and we use it today, so Jana define= d it. =C2=A0

=C2=A0

Martin and Mirja, re: When to include connection ID:= Yes, it's clear this needs more discussion.=C2=A0 I think it makes sen= se to have both sets of codepoints in there for now, and we can remove them= later if we really think connection ID is never necessary.=C2=A0 Currently, it's necessary in cases when NATs ra= pidly rebind. =C2=A0

=C2=A0

I do think we need a long-form packet that can carry= 1-RTT, and I think it's critical if we want to drop connection ID from= short form packets, since it could allow us to re-establish a connection w= ith the same server using a new different ID.=C2=A0 It's also useful for out of band key negotiation, which I be= lieve is why Jana added it.

=C2=A0

If we're only going to include connection ID in = packets which also contain version, we could bump the length to 16 bytes if= there's a compelling use case.=C2=A0

=C2=A0

This proposal also allows us to grease every unencry= pted byte in the packet, which makes me excited, but I'll write that up= on the grease issue.

=C2=A0

On Wed, Feb 15, 2017 at 6:17 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

On 15 February 2017 a= t 20:14, Mirja K=C3=BChlewind
<mi= rja.kuehlewind@tik.ee.ethz.ch> wrote:
> 4) And finally, I think it would be safer to have the connection ID on= all
> packets. But maybe we can just use a shorter connection ID? What's= the
> reason for a 64 bits connection ID again?

If anything I think that 64 bits is too short :)=C2=A0 Server people keep asking for more anyway.=C2=A0 Managing routing, authentication and whatever=
else this field might be used for, all in a mere 64 bits, is pretty
challenging.

I think that the notion of removing connection ID needs a lot more
discussion.=C2=A0 Reasons I can see for removing it are that the server
doesn't need it, or the client doesn't want it (hello linkability).=
Removing it does jeopardize some connection migration cases though, so
we probably want to work through the use cases in more detail.

=C2=A0

=C2=A0

=C2=A0


--001a113adf3ed02951054899b6f0-- From nobody Wed Feb 15 15:17:50 2017 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 7924B129BC5 for ; Wed, 15 Feb 2017 15:17:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 bMNPbWP84tPP for ; Wed, 15 Feb 2017 15:17:47 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 D217A129BC4 for ; Wed, 15 Feb 2017 15:17:46 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id y9so800086uae.2 for ; Wed, 15 Feb 2017 15:17:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5re+iPRdZBzWHgZqkBc9apg070XO6DREJAShyZgbc3Y=; b=iyFY8tPFEBt0UJooC2lofy29P0qFUzRPz2XqfocTheK2vJIUchIaTQk31k2B82EsxI 8Pn9eNcA+xIm1775B9hOSrM+pi6+JHQ1Q95PmgwJ8+lYmDoS/qaOFZ/cZy6ICr6vmbK3 Egayf/aO8AjzYipgu+MfISc/WC3RKjHayM/MaCuGUm4gP2wETSzYjYQ6H/4vPPM9g2sb U4sZAK51WoWeY8RseWfgljuqnNbj8GR6auLXEXFWENvIeNy6Po3G8/7ZrRa4xuVgpzmO YZG5swabv4ql9RP+eU/LYoSKAh1EtADuZre5dlM+cndiuctO+e36U95qzVhkdS591N13 wi1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5re+iPRdZBzWHgZqkBc9apg070XO6DREJAShyZgbc3Y=; b=tt2cc9BsSJiEymYOq2pjSDFBIdbTksDjiqtp+9cROFnCRcekKSKmXrnuQfX3ab/AB2 xeELhL+WcZUcli9psrHublMSIg+eIgZWPLEvC/yumdV8WTMbZH4YhEQ3509YxdqvW4th u5NPipQ+9EHaYjfOxSdNc/U3v8+d3LYYj0lEHmw82wkcArOuPJc3daSvj7FqxGZ70Jr3 GLnrtPHCy1XZdszbruFkMj7CGoPXPOQCVXCM6E1k47WXbNJJ/a+rdve+PHCAC+sfwSfz cJ9OUem/7UGH3TD3AbjxLv5M2xgF5QCi8VcBCOulONJWzURiJkOUbZiP/mecWewR5AcU tWFg== X-Gm-Message-State: AMke39muNUJYEOAANdLu9+MZbGXCGT6Fygl6JiGSik9JF8Eugnd3Xb9M2ek0/ysWe/9t3cELujMbDF9Aye3RXiel X-Received: by 10.176.1.51 with SMTP id 48mr2138401uak.143.1487200659593; Wed, 15 Feb 2017 15:17:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Wed, 15 Feb 2017 15:17:38 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Feb 2017 15:17:38 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Duke Content-Type: multipart/alternative; boundary=001a113ac1be069eb9054899e304 Archived-At: Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Ian Swett , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:17:48 -0000 --001a113ac1be069eb9054899e304 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 2:41 PM, Martin Duke wrote: > On Wed, Feb 15, 2017 at 2:27 PM, Jana Iyengar wrote: > >> On Wed, Feb 15, 2017 at 11:08 AM, Martin Duke >> wrote: >> >>> >>> Also, we have a number of outstanding manageability issues that could >>> use 2-3 bits in the public flags, and I'd like to compress the uses here to >>> make space for those. >>> >> >> ... or we could add more codepoints. We can make the codepoints >> contiguous if that helps. Let's discuss the issues independent of >> representation first, and then figure out representation. >> >> > > Without trying to legislate these issues here, the manageability proposals > basically involve setting a few bits in the flags to give basic loss and > flow control information to middleboxes. They are orthogonal to header > length and (largely) to each otehr, so you're multiplying the number of > codepoints by up to 8 (32 if ECE/CWR in the flags has a constituency) in a > way that makes it much harder for the middlebox to read if those codepoints > don't in practice correspond to a particular bit. > > These flags would apply to both long and short form packets, so there are > not even any economies there. > I don't think they all do -- for instance, these bits would not need to be expressed on the public reset and version negtiation packets, would they? Depending on the signal in question, we may be able to contain the combinatorial explosion. If unavoidable, we can surely give up a bit. Why do you need ECE/CWR bits in the header? I haven't carefully considered yet how to do this in QUIC (and I haven't carefully read Ingemar's draft yet), but those would/should be in explicit frames I would imagine. > I don't think you need explicit bits; mapping from a codepoint to explicit >> bits at the endpoints should work fine IMO. > > > I agree 100% for long form, where there are a series of oddball packet > types. But for short form, there are many permutations that are largely > independent of each other, so little is lost by formally organizing them as > bits corresponding to fields. > I'm not sure that's true... more accurately, this isn't a demonstrated problem yet. The short forms currently constitute 12 packet types, which is not too many. If we end up having combinatorial explosion as we move forward, then sure, we can re-jigger this type byte to be flags+type. --001a113ac1be069eb9054899e304 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 2:41 PM, Martin Duke <martin.h.duke@gmail.com> wrote:
On Wed, Feb 15, 201= 7 at 2:27 PM, Jana Iyengar <jri@google.com> wrote:
On Wed, Feb 15, 2017 at 11:08 AM, M= artin Duke <martin.h.duke@gmail.com> wrote:

Also, we have a number of outstanding manageability issues t= hat could use 2-3 bits in the public flags, and I'd like to compress th= e uses here to make space for those.

... or we could add more codepoints. We can make the codepoint= s contiguous if that helps. Let's discuss the issues independent of rep= resentation first, and then figure out representation.
=C2=A0
<= /span>

Without trying to = legislate these issues here, the manageability proposals basically involve = setting a few bits in the flags to give basic loss and flow control informa= tion to middleboxes. They are orthogonal to header length and (largely) to = each otehr, so you're multiplying the number of codepoints by up to 8 (= 32 if ECE/CWR in the flags has a constituency) in a way that makes it much = harder for the middlebox to read if those codepoints don't in practice = correspond to a particular bit.=C2=A0

These flags = would apply to both long and short form packets, so there are not even any = economies there.

I = don't think they all do -- for instance, these bits would not need to b= e expressed on the public reset and version negtiation packets, would they?= Depending on the signal in question, we may be able to contain the combina= torial explosion. If unavoidable, we can surely give up a bit.
Why do you need ECE/CWR bits in the header? I haven't care= fully considered yet how to do this in QUIC (and I haven't carefully re= ad Ingemar's draft yet), but those would/should be in explicit frames I= would imagine.
=C2=A0
I don't think you need explicit bits; mapping from a codepoint to e= xplicit bits at the endpoints should work fine IMO.

I agree 100% for long form, where there are a series= of oddball packet types. But for short form, there are many permutations t= hat are largely independent of each other, so little is lost by formally or= ganizing them as bits corresponding to fields.

I'm not sure th= at's true... more accurately, this isn't a demonstrated problem yet= . The short forms currently constitute 12 packet types, which is not too ma= ny. If we end up having combinatorial explosion as we move forward, then su= re, we can re-jigger this type byte to be flags+type.

--001a113ac1be069eb9054899e304-- From nobody Wed Feb 15 15:26:35 2017 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 04EFE12995D for ; Wed, 15 Feb 2017 15:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYNylcqzxRTn for ; Wed, 15 Feb 2017 15:26:32 -0800 (PST) Received: from mail-ot0-x234.google.com (mail-ot0-x234.google.com [IPv6:2607:f8b0:4003:c0f::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 BDFAB1293E3 for ; Wed, 15 Feb 2017 15:26:32 -0800 (PST) Received: by mail-ot0-x234.google.com with SMTP id t47so987380ota.1 for ; Wed, 15 Feb 2017 15:26:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1DlSFnQWa0hRAY+q5fNHr9yt8cMUGI34CBjgV9jXeWI=; b=LkCqkBbeUk4ONGaLauGFF+d9muYGVpCpVAVKgvtePmlTJ6i0Eepade1g02PHfWBA8C XXRqiGPMI9iOqaK9GWvlyq+jutYPkYbdWhe0/zLeD2IJNq/3N3ImNovBWcV0aVdxBLEx ALGwl2kUeNoeQ13+DejwjylQmxyLEOwJaIfRLjB9SW08tTSBs4HU8tFbm1zflCtalkSn 347DT5kBRivM5NBTl0RdTaC8kNKYRe2wcScL807vazNHOdoU66jC+lch8EWzTkYJNZnf e9naDd5aDxm8hnWsftgzIe0Hc94c45qAtMnpIiPTawBWF8a9ai/AMw3nd2VOyMET9+6F sxhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1DlSFnQWa0hRAY+q5fNHr9yt8cMUGI34CBjgV9jXeWI=; b=rn87oycKpFCqj43dkUGzKljZlCaSH6Xfx7zAq5q1DyKm4TN2z8ADO5vGR5xLDU4d1p 0CZp5rG1klFeLgOAldhs4VA8kgmIWg6BGvtM2YCAiia1VYO19geWY+amCcCwpBDouwc6 DNNJKf+bTT2GJq/XgRRNCKg1I/tp8CZWimJm5+gBtBSc4rziqu826lOsWAzEo06gGJbF ARJrJxwNBQAu62fzOVzg4Wkl+yUt6dlwr/dU5qhwVZORLHNQ9U6006aNA3529SJ5pwK4 nZTd5cJXuvmHvpa5i3uJ0mhhpVGh08nre5XEXcHv6ILnSyipNV/aERRVQF6vf1tidhYD yd5w== X-Gm-Message-State: AMke39knvU3rzxVDnCwLGVUMxeu7D2r58fNqmxQ+QveXzg3DjmvxKoKCji2PY3fxh02nqiABvyph+8sCxuwIuA== X-Received: by 10.157.7.17 with SMTP id 17mr18899339ote.231.1487201192261; Wed, 15 Feb 2017 15:26:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.15.182 with HTTP; Wed, 15 Feb 2017 15:26:31 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Wed, 15 Feb 2017 15:26:31 -0800 Message-ID: Subject: Re: Alternate header proposal To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a1137be10c63d7005489a023c Archived-At: Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Ian Swett , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:26:34 -0000 --001a1137be10c63d7005489a023c Content-Type: text/plain; charset=UTF-8 > > > Why do you need ECE/CWR bits in the header? I haven't carefully considered > yet how to do this in QUIC (and I haven't carefully read Ingemar's draft > yet), but those would/should be in explicit frames I would imagine. > The draft puts them in the ACK frame. There is a case, I think, to have them in the public header, though I'm not convinced of it at all. The point I am trying to make is that there are uses for these bits that are not related to the header layout, and in the extreme case this would be as many as 5 (I am personally convinced we need only 2). --001a1137be10c63d7005489a023c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Why do you need ECE/CWR bits in = the header? I haven't carefully considered yet how to do this in QUIC (= and I haven't carefully read Ingemar's draft yet), but those would/= should be in explicit frames I would imagine.

The draft puts them in the ACK frame. There is a= case, I think, to have them in the public header, though I'm not convi= nced of it at all. The point I am trying to make is that there are uses for= these bits that are not related to the header layout, and in the extreme c= ase this would be as many as 5 (I am personally convinced we need only 2).= =C2=A0
--001a1137be10c63d7005489a023c-- From nobody Wed Feb 15 15:36:26 2017 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 0F54F129B9E for ; Wed, 15 Feb 2017 15:36:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 y6H_qOQ4j6Yt for ; Wed, 15 Feb 2017 15:36:21 -0800 (PST) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 D79AA129954 for ; Wed, 15 Feb 2017 15:36:20 -0800 (PST) Received: by mail-ua0-x22a.google.com with SMTP id x12so1067502uax.0 for ; Wed, 15 Feb 2017 15:36:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=I+n+eEyHKY1kszvbAHTlR3mtNCMd4WYmuI/nLDOn2sU=; b=Kpo3obzIPmgR4bMg0si1kKzYJ0eqwnUC4MR6Am/MZg6ZZ+vB3o4JgazB9JbEtbPFei 9GRrzbZJTF7nxK9NCQD7qCviFkJ7bJ1KWtqCzSoXzRyzHvLSx1s6QPgJ5tj/XFtkId58 t7IAawrRhEvLNEF/g2XyDLirnvVk4UZVHlnXnyUPz+f3LFNTG7+jbwxYkq8Xkohnllh9 ugACeS9Ak3YR1Dgo23Vy4001aC4DpF3ee9yVb9oL8J/T3H+y/gv7k9zfVpleglqMjv2l S0FdPNEZPqlgC6KaXEJ5Nn5oVbfDYJcuOxReV3fRQcAdXcttu3y/JcwFDWQpe4nrvf+w xeog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=I+n+eEyHKY1kszvbAHTlR3mtNCMd4WYmuI/nLDOn2sU=; b=J0eFWzwis12CCFFr0NvwhgrPp/AUFHLJrqtr8o44XJ52XlVSYWSxi6fVTjBNLXJc73 q76UMYEFzB4whX/VX9v8JKTqzBaKkQVDpKJ4KUYMEsn7+NZ2YFFYXwodYwj7gyuQX42j DWvH6cx2tKr2O1M6KZMEdNxCc04YuTC01n1KZk9RlDrVcHztUMxqhnumZrl6IsG0uvIV hXDGTSJgNJaaM2qGpd7YumT57iezozz7UMFZHUsH7+6G0nPiZw5WBOuULsaQwzOQ87AL f/K34SngBeaTRaUrKsx1eg5G0XB1Xj5soDnUZnMhQY7CvCM34I5OgxPpmbHNAtGZGLNs LFPA== X-Gm-Message-State: AMke39k41y4OT0FSe8in0gDK3Hadnv56oovWzYt37IRd6khM8v+w7Uh8jT/ZRFPyPLTKaB2xXApjVlvmQmg8Mt65 X-Received: by 10.176.2.113 with SMTP id 104mr1427037uas.155.1487201779438; Wed, 15 Feb 2017 15:36:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Wed, 15 Feb 2017 15:36:18 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Feb 2017 15:36:18 -0800 Message-ID: Subject: Re: Alternate header proposal To: Mike Bishop Content-Type: multipart/alternative; boundary=001a113e4b92c62c4705489a257c Archived-At: Cc: Martin Thomson , Ian Swett , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:36:24 -0000 --001a113e4b92c62c4705489a257c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2017 at 3:01 PM, Mike Bishop wrote: > It seems like there=E2=80=99s an emerging idea (which has been present al= l along) > that there are really two subdivisions of QUIC: > > - QUIC-for-all-time: Forever-fixed packet layouts carrying version > negotiation, public reset, etc.; can carry version-specific headers/pa= yload > as well if you=E2=80=99ve agreed on the version > - If you change these, you=E2=80=99re defining a new protocol that = has to > be distinguishable from QUIC in some way > - QUIC-for-now: Version-specific packet layouts carrying > version-specific payload > > Yes. Working through Martin's proposal and trying to fix the things in there led me to a couple of other proposals along the way, but chatting with Martin about the codepoint idea led me to this proposal, which I think is a nice and elegant simplification of those proposals. The core of this proposal is in making existing uses of the Flags byte slightly more rigid, and making the rest of the combinatorial space available for extensibility. It sounds like what you=E2=80=99re saying here is that all long-form packet > codepoints are part of QUIC-for-all-time (deliberately not coining the te= rm > =E2=80=9CQFAT=E2=80=9D), and a receiver has to assume that any other code= point > ... and you just coined it :-) > *might* be part of QUIC-for-now in a version it doesn=E2=80=99t know (whi= ch gets > dropped, either because it knows the purported version and doesn=E2=80=99= t > recognize the codepoint or doesn=E2=80=99t know the purported version and= it > shouldn=E2=80=99t be seeing those without negotiation having completed). > Yes that is correct. As Martin (Duke; E_TOO_MANY_MARTINS) points out, there's also the version-agnostic headers fields now, which, in the long forms, are the parts preceding the version field. Note that the entire packet header for the long form does not need to be version agnostic. There's no reason fields following the version field cannot change across versions. > Currently, we describe the whole thing together, and have a follow-up > section that says =E2=80=9CBTW, these things won=E2=80=99t change in futu= re versions.=E2=80=9D > Without necessarily splitting QUIC-for-all-time into a separate document, > it might be useful to tease that line apart further and make the immutabl= e > stuff at least a fully separate section. > Yes, agreed. The long/short split is roughly along those lines, but we need to carefully and explicitly draw the line in the transport document. - jana > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar > *Sent:* Wednesday, February 15, 2017 2:27 PM > *To:* Martin Duke > *Cc:* Mirja K=C3=BChlewind ; Ian Swett < > ianswett@google.com>; IETF QUIC WG ; Martin Thomson < > martin.thomson@gmail.com> > *Subject:* Re: Alternate header proposal > > > > On Wed, Feb 15, 2017 at 11:08 AM, Martin Duke > wrote: > > The packet formats look great. I also like the idea of a version-agnostic > long form header with version complexity only in the short form. > > > > But I have issues with the first byte: > > > > Perhaps I'm missing something simple here, but how does 0x8 specify > short/long form? The first six short headers Jana presented differ in thi= s > bit from the second six. In fact there is no bit that is consistently set > in the short form while cleared in the long form, or vice versa. > > > > You're right, there's no single bit that can be used in this proposal. > > > > Also, we have a number of outstanding manageability issues that could use > 2-3 bits in the public flags, and I'd like to compress the uses here to > make space for those. > > > > ... or we could add more codepoints. We can make the codepoints contiguou= s > if that helps. Let's discuss the issues independent of representation > first, and then figure out representation. > > > > Furthermore, I think having an actual long/short bit would be quite usefu= l > and I'd like to arrange the codepoints to allow that. > > > > So I think processing would be somewhat easier with the following > arrangement: > > 0x80: Long Form header > > If a long form header: > > 0x80-0xd0 - covers the six types of long-form packet > > The last 4 are reserved, and greased if we don't find uses for them > > If a short form header > > 0x40 - key phase > > 0x20 - conn Id included > > 0x10 and 0x08 - pkt # length > > The last three bits are reserved/greased. > > > > This looks close to an intermediate proposal I had come up with :-) I'm > not opposed to this, but it makes the split between long and short forms > more explicit than necessary. I don't think processing is harder with the > current proposal, though sure, you could make the packet types contiguous > if that helps. > > > > Importantly, the two forms are not really that different from a processin= g > point-of-view if you look closely; the separation is really more useful f= or > reasoning and understanding. There is the distinction of the short form > being version-specific, but that's really only to say that a receiver tha= t > negotiates version X should only process the codepoints defined for that > version. Except for the version negotiation and public reset packets, th= e > rest of the types are data bearing packets (with or without some fields a= nd > key phase signaling) and should be treated as such. As to going from > codepoint to bits that indicate presence of fields, it's a simple matter = of > mapping codepoints to local per-packet state, and you continue processing > the packet with the local state. > > > > I don't think you need explicit bits; mapping from a codepoint to explici= t > bits at the endpoints should work fine IMO. > > > > - jana > > > > On Wed, Feb 15, 2017 at 4:48 AM, Ian Swett wrote: > > I like this general approach a lot, because it defines a consistent set o= f > easy to parse packets for prior to version negotiation, and allows plenty > of extensibility both pre and post version negotiation if we need it. > Having connection ID come after the flags byte feels right, because it's > routing info. I also think it'll be relatively easy to implement. > > > > Mirja, to address your point about extensibility. I think we want the > ability to evolve the design and add new features, in this case via packe= t > types. One can imagine adding an 8 byte packet number format in the > future, for example, or even a format with Martin's authenticated repeate= d > options if we decide it's compelling? > > > > Mirja, re #3 about packet number sizes. This is very much about > user-facing traffic, not datacenters. 2 bytes is enough for all the user > facing traffic we have today. But that allows a max CWND that's less tha= n > what TCP allows, so 4 bytes was added because it seemed fairly futureproo= f. > 1 byte isn't really that necessary, though it's commonly used on short > connections and it's really easy to implement and we use it today, so Jan= a > defined it. > > > > Martin and Mirja, re: When to include connection ID: Yes, it's clear this > needs more discussion. I think it makes sense to have both sets of > codepoints in there for now, and we can remove them later if we really > think connection ID is never necessary. Currently, it's necessary in cas= es > when NATs rapidly rebind. > > > > I do think we need a long-form packet that can carry 1-RTT, and I think > it's critical if we want to drop connection ID from short form packets, > since it could allow us to re-establish a connection with the same server > using a new different ID. It's also useful for out of band key > negotiation, which I believe is why Jana added it. > > > > If we're only going to include connection ID in packets which also contai= n > version, we could bump the length to 16 bytes if there's a compelling use > case. > > > > This proposal also allows us to grease every unencrypted byte in the > packet, which makes me excited, but I'll write that up on the grease issu= e. > > > > On Wed, Feb 15, 2017 at 6:17 AM, Martin Thomson > wrote: > > On 15 February 2017 at 20:14, Mirja K=C3=BChlewind > wrote: > > 4) And finally, I think it would be safer to have the connection ID on > all > > packets. But maybe we can just use a shorter connection ID? What's the > > reason for a 64 bits connection ID again? > > If anything I think that 64 bits is too short :) Server people keep > asking for more anyway. Managing routing, authentication and whatever > else this field might be used for, all in a mere 64 bits, is pretty > challenging. > > I think that the notion of removing connection ID needs a lot more > discussion. Reasons I can see for removing it are that the server > doesn't need it, or the client doesn't want it (hello linkability). > Removing it does jeopardize some connection migration cases though, so > we probably want to work through the use cases in more detail. > > > > > > > --001a113e4b92c62c4705489a257c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 3:01 PM, Mike Bishop <Michael.Bishop@micros= oft.com> wrote:

It seems like there=E2=80=99s an emerging idea (whic= h has been present all along) that there are really two subdivisions of QUI= C:

  • QUIC-for-all-time:=C2=A0 Forever-fixed packe= t layouts carrying version negotiation, public reset, etc.; can carry versi= on-specific headers/payload as well if you=E2=80=99ve agreed on the version=
    • If you change these, you=E2=80=99re defining= a new protocol that has to be distinguishable from QUIC in some way=
  • QUIC-for-now:=C2=A0 Version-specific pa= cket layouts carrying version-specific payload
Yes. Working through Martin's proposal and trying to fix the= things in there led me to a couple of other proposals along the way, but c= hatting with Martin about the codepoint idea led me to this proposal, which= I think is a nice and elegant simplification of those proposals. The core = of this proposal is in making existing uses of the Flags byte slightly more= rigid, and making the rest of the combinatorial space available for extens= ibility.

It sounds like what you=E2= =80=99re saying here is that all long-form packet codepoints are part of QU= IC-for-all-time (deliberately not coining the term =E2=80=9CQFAT=E2=80=9D),= and a receiver has to assume that any other codepoint


... and you just coined it= :-)
=C2=A0

might be part of QUIC= -for-now in a version it doesn=E2=80=99t know (which gets dropped, either b= ecause it knows the purported version and doesn=E2=80=99t recognize the cod= epoint or doesn=E2=80=99t know the purported version and it shouldn=E2=80= =99t be seeing those without negotiation having completed).


Ye= s that is correct. As Martin (Duke; E_TOO_MANY_MARTINS) points out, there&#= 39;s also the version-agnostic headers fields now, which, in the long forms= , are the parts preceding the version field. Note that the entire packet he= ader for the long form does not need to be version agnostic. There's no= reason fields following the version field cannot change across versions.
=C2=A0

Currently, we describe the whole thing together, and= have a follow-up section that says =E2=80=9CBTW, these things won=E2=80=99= t change in future versions.=E2=80=9D=C2=A0 Without necessarily splitting Q= UIC-for-all-time into a separate document, it might be useful to tease that line apart further and make the immutable stuff at least a full= y separate section.


Yes, ag= reed. The long/short split is roughly along those lines, but we need to car= efully and explicitly draw the line in the transport document.
- jana
=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Wednesday, February 15, 2017 2:27 PM
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>;= Ian Swett <ian= swett@google.com>; IETF QUIC WG <quic@ietf.org>; Martin Thomson <martin.thomson@gmail.com>
Subject: Re: Alternate header proposal

=C2=A0

On Wed, Feb 15, 2017 at 11:08 AM, Martin Duke <martin.h.duke@gm= ail.com> wrote:

The packet formats look great. I also like the idea = of a version-agnostic long form header with version complexity only in the = short form.

=C2=A0

But I have issues with the first byte:=

=C2=A0

Perhaps I'm missing something simple here, but h= ow does 0x8 specify short/long form? The first six short headers Jana prese= nted differ in this bit from the second six. In fact there is no bit that i= s consistently set in the short form while cleared in the long form, or vice versa.

=C2=A0

You're right, there's no single bit that can= be used in this proposal.

=C2=A0

Also, we have a number of outstanding manageability = issues that could use 2-3 bits in the public flags, and I'd like to com= press the uses here to make space for those.

=C2=A0

... or we could add more codepoints. We can make the= codepoints contiguous if that helps. Let's discuss the issues independ= ent of representation first, and then figure out representation.<= /u>

=C2=A0

Furthermore, I think having an actual long/short bit= would be quite useful and I'd like to arrange the codepoints to allow = that.

=C2=A0

So I think processing would be somewhat easier with = the following arrangement:

0x80: Long Form header

If a long form header:

=C2=A0 0x80-0xd0 - covers the six types of long-form= packet

=C2=A0 The last 4 are reserved, and greased if we do= n't find uses for them

If a short form header

=C2=A0 0x40 - key phase

=C2=A0 0x20 - conn Id included

=C2=A0 0x10 and 0x08 - pkt # length

=C2=A0 The last three bits are reserved/greased.<= /u>

=C2=A0

This looks close to an intermediate proposal I had c= ome up with :-) I'm not opposed to this, but it makes the split between= long and short forms more explicit than necessary. I don't think proce= ssing is harder with the current proposal, though sure, you could make the packet types contiguous if that helps.<= /u>

=C2=A0

Importantly, the two forms are not really that diffe= rent from a processing point-of-view if you look closely; the separation is= really more useful for reasoning and understanding. There is the distincti= on of the short form being version-specific, but that's really only to say that a receiver that negotiates version = X should only process the codepoints defined for that version.=C2=A0 Except= for the version negotiation and public reset packets, the rest of the type= s are data bearing packets (with or without some fields and key phase signaling) and should be treated as such. As to = going from codepoint to bits that indicate presence of fields, it's a s= imple matter of mapping codepoints to local per-packet state, and you conti= nue processing the packet with the local state.=C2=A0

=C2=A0

I don't think you need explicit bits; mapping fr= om a codepoint to explicit bits at the endpoints should work fine IMO.

=C2=A0

- jana

=C2=A0

On Wed, Feb 15, 2017 at 4:48 AM, Ian Swett <ianswett@google.com= > wrote:

I like this general approach a lot, because it defin= es a consistent set of easy to parse packets for prior to version negotiati= on, and allows plenty of extensibility both pre and post version negotiatio= n if we need it.=C2=A0 Having connection ID come after the flags byte feels right, because it's routing info.= =C2=A0 I also think it'll be relatively easy to implement.

=C2=A0

Mirja, to address your point about extensibility.=C2= =A0 I think we want the ability to evolve the design and add new features, = in this case via packet types.=C2=A0 One can imagine adding an 8 byte packe= t number format in the future, for example, or even a format with Martin's authenticated repeated options if we de= cide it's compelling?

=C2=A0

Mirja, re #3 about packet number sizes.=C2=A0 This i= s very much about user-facing traffic, not datacenters. =C2=A02 bytes is en= ough for all the user facing traffic we have today.=C2=A0 But that allows a= max CWND that's less than what TCP allows, so 4 bytes was added because it seemed fairly futureproof. =C2=A01 byte isn'= ;t really that necessary, though it's commonly used on short connection= s and it's really easy to implement and we use it today, so Jana define= d it. =C2=A0

=C2=A0

Martin and Mirja, re: When to include connection ID:= Yes, it's clear this needs more discussion.=C2=A0 I think it makes sen= se to have both sets of codepoints in there for now, and we can remove them= later if we really think connection ID is never necessary.=C2=A0 Currently, it's necessary in cases when NATs ra= pidly rebind. =C2=A0

=C2=A0

I do think we need a long-form packet that can carry= 1-RTT, and I think it's critical if we want to drop connection ID from= short form packets, since it could allow us to re-establish a connection w= ith the same server using a new different ID.=C2=A0 It's also useful for out of band key negotiation, which I be= lieve is why Jana added it.

=C2=A0

If we're only going to include connection ID in = packets which also contain version, we could bump the length to 16 bytes if= there's a compelling use case.=C2=A0

=C2=A0

This proposal also allows us to grease every unencry= pted byte in the packet, which makes me excited, but I'll write that up= on the grease issue.

=C2=A0

On Wed, Feb 15, 2017 at 6:17 AM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:

On 15 February 2017 at = 20:14, Mirja K=C3=BChlewind
<mi= rja.kuehlewind@tik.ee.ethz.ch> wrote:
> 4) And finally, I think it would be safer to have the connection ID on= all
> packets. But maybe we can just use a shorter connection ID? What's= the
> reason for a 64 bits connection ID again?

If anything I think that 64 bits is too short :)=C2=A0 Server people keep asking for more anyway.=C2=A0 Managing routing, authentication and whatever=
else this field might be used for, all in a mere 64 bits, is pretty
challenging.

I think that the notion of removing connection ID needs a lot more
discussion.=C2=A0 Reasons I can see for removing it are that the server
doesn't need it, or the client doesn't want it (hello linkability).=
Removing it does jeopardize some connection migration cases though, so
we probably want to work through the use cases in more detail.

=C2=A0

=C2=A0

=C2=A0


--001a113e4b92c62c4705489a257c-- From nobody Wed Feb 15 15:47:16 2017 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 807F8129BEB for ; Wed, 15 Feb 2017 15:47:14 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 GIqEYSWMA0xA for ; Wed, 15 Feb 2017 15:47:13 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDFD4129BEA for ; Wed, 15 Feb 2017 15:47:12 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id r136so1104745vke.1 for ; Wed, 15 Feb 2017 15:47:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ofi9rMi4VGP+61VkuUEiR7TqZl576OgLwid4fC5xnGo=; b=G/QDZrqbkNRSPZccarGIxuBXDejHrC2MBQQFwZAXuQe7v8i7N8byY+o8xJ7UhRGWYs mcBnB52PxWx6riIhBXn6bWKLzCnKR0OvX8NeWmf/UzCQZ/+zOjiKOUW0h/xc0LxPfRrw SfQXUdKi7yVzisBBnJ/Xdh1xUpq6DyjM3xzmg2M2VQgkFWs0i8Iljr25ffqSthES4i7D p+Y3ciegREThN0PUIKo3PpSLXSIHNS+7ywYkPUj9aXD3QhLXA09IygwVIxry4MJrvUkz WncFQY09X4to1yyyQjzOR8vbg5IMAAu9819LarNSoW4a3qon6p06vHfFmp+yI4dENS0O cLig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ofi9rMi4VGP+61VkuUEiR7TqZl576OgLwid4fC5xnGo=; b=TvaZpmE2gGRqGk5D6095k+dGke1oG+Ie23lnBVPISy/Zg12/MwjdxojN1YX3iDUT6Q dYD2ezEyovrSv4nwA2Po/f1memKhmJO9ap7eF4NqRRwRuARwyc/CROUOI8g+etG6nzqO 73PTCzmA/GLDbtHdD9Q/CM/ertrvT+BoJWYobc44H8km3s3fCF8laMnTmYe6PIbtD/3Q X6uziuXz+TO1BBhTrRHujM/pPpQqNiyAAYmV8LKPeU9310svSnIKp/2uO73OodEH+ek0 1h+8XqUzMudFc80gB6xgOZOHWBD724y7u4At6DE4i6hqEDM8rPmk0lAnvvmmDb2+taRt hIsw== X-Gm-Message-State: AMke39kMEXzl/iEYJ5+zD2+ca1/7GtN9pilGOR2yMGrG6SPfZKNsAw3BksuzQR3fck1QvZThW+PEjGmnRhJ4mHZB X-Received: by 10.31.200.199 with SMTP id y190mr18914184vkf.115.1487202431348; Wed, 15 Feb 2017 15:47:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Wed, 15 Feb 2017 15:47:10 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Feb 2017 15:47:10 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Duke Content-Type: multipart/alternative; boundary=001a114d9d48a18bcd05489a4ce0 Archived-At: Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Ian Swett , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2017 23:47:14 -0000 --001a114d9d48a18bcd05489a4ce0 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 3:26 PM, Martin Duke wrote: > >> Why do you need ECE/CWR bits in the header? I haven't carefully >> considered yet how to do this in QUIC (and I haven't carefully read >> Ingemar's draft yet), but those would/should be in explicit frames I would >> imagine. >> > > The draft puts them in the ACK frame. There is a case, I think, to have > them in the public header, though I'm not convinced of it at all. The point > I am trying to make is that there are uses for these bits that are not > related to the header layout, and in the extreme case this would be as many > as 5 (I am personally convinced we need only 2). > I understand and agree with the point that we may have things that need to be put in the packet header (FWIW, and we can discuss this separately, but I'm hard-pressed to understand why ECN bits are needed in the packet header instead of in the ack frame.) Either ways I think we'll have to discuss this on a case-by-case basis, but in the meanwhile, this proposal gives you another degree of freedom -- codepoint space. The current proposal only addresses things we have reasonable agreement on in the wg, and not on things that are yet under discussion. No matter what header format we use, we're going to have to revisit it if there are issues that touch the header in the future, and to that extent, this header format will have to remain malleable. I wouldn't say we've done away with explicit bits, but I'd sure like to try and avoid them in favor of codepoints if we can, since it seems like a big enough space. --001a114d9d48a18bcd05489a4ce0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 3:26 PM, Martin Duke <martin.h.duke@gmail.com> wrote:

Why do you need ECE/CWR bits in the header? I haven't carefully= considered yet how to do this in QUIC (and I haven't carefully read In= gemar's draft yet), but those would/should be in explicit frames I woul= d imagine.

T= he draft puts them in the ACK frame. There is a case, I think, to have them= in the public header, though I'm not convinced of it at all. The point= I am trying to make is that there are uses for these bits that are not rel= ated to the header layout, and in the extreme case this would be as many as= 5 (I am personally convinced we need only 2).=C2=A0

I understand and ag= ree with the point that we may have things that need to be put in the packe= t header (FWIW, and we can discuss this separately, but I'm hard-presse= d to understand why ECN bits are needed in the packet header instead of in = the ack frame.) Either ways I think we'll have to discuss this on a cas= e-by-case basis, but in the meanwhile, this proposal gives you another degr= ee of freedom -- codepoint space.=C2=A0
The current proposal only addresses thing= s we have reasonable agreement on in the wg, and not on things that are yet= under discussion. No matter what header format we use, we're going to = have to revisit it if there are issues that touch the header in the future,= and to that extent, this header format will have to remain malleable. I wo= uldn't say we've done away with explicit bits, but I'd sure lik= e to try and avoid them in favor of codepoints if we can, since it seems li= ke a big enough space.
--001a114d9d48a18bcd05489a4ce0-- From nobody Wed Feb 15 16:16:39 2017 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 63EFE129B75 for ; Wed, 15 Feb 2017 16:16:37 -0800 (PST) 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 jLQvWxdi_raI for ; Wed, 15 Feb 2017 16:16:36 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35B28129550 for ; Wed, 15 Feb 2017 16:16:36 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id 11so2072592qkl.3 for ; Wed, 15 Feb 2017 16:16:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hyz8vcecFB2qKx25gzXLq/UzSN00ORno4ycc4TzGUgU=; b=a1kq49efbpJVc4plyQj1TCMxSeoyQo8tSYq10lVttZIMA5tI9aFX1m1ICpmvkpzu2i O4Xbe8cUDDZ/em+lyz/MAUkw6J4rpMAmZoZog2oQo3japRYzVr3RsHE3hF+veDL/Fu8v p6xvIM8LPmE8LFyd2IiC/bqGT4H+tBUP/Pxr6TcRRdJY/5OxgAilN8WpBO6sbV5LnJJY XRuQocToPORe3XzRlWu3OThYkZd0Cq48VQwauTtFrznMAUBBtF228LG4UXg9jl0CHwkb kL3GarrpU2mYQcyEaE2wScrO7vLKrOwXK2nM/USFUuaolDnKMpb3AxJgHd3TLxcPw3W9 egzQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hyz8vcecFB2qKx25gzXLq/UzSN00ORno4ycc4TzGUgU=; b=qDAS7yFvi5JUmQHKlxJHzlKcHXTPCMCgh+QM1Qc398X6eJ2kvzaWSdeDucTxTPPM3m bdLmT54QRe+SDPNeLVwzrXC1jgC67napP7NzR3wls8ssx9TgMxCR0muPNVl/Fl9nk0qG QAb3xuAnwReYkhTbTJmFfgis9KuwmYPauNvz5qY+99wB8baoQ4AEc0zlTBdpibAvTsAl KtYl+5WsdTcZhEeUj5mX6vJM9xDH12ZEokWQ3AR6ATdTpnMaCpKWPywcNzKnJhFFXu2H 8zaYiZZE4Yb1oGIfrOifnRxFpwbYrzkBnv6BiNkTMWEsgPkinajL8IuqzxMqkZ8As0xA zQIA== X-Gm-Message-State: AMke39lai6cZG+wWI+beKH1avHv+PCkHaDhRLi3Kn7sPtEBBt0sGXyVKxemUcep1DzPr2uYYGe4F3++haks4Rw== X-Received: by 10.55.151.7 with SMTP id z7mr37622969qkd.316.1487204195333; Wed, 15 Feb 2017 16:16:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 16:16:34 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 16 Feb 2017 11:16:34 +1100 Message-ID: Subject: Re: Alternate header proposal To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 00:16:37 -0000 On 16 February 2017 at 07:56, Jana Iyengar wrote: > I think I like this. Can anyone think of reasons to not burn packet number > in the long header? If I understand what you mean by "burn" sure. Note that the semantics don't need to be understood, it's just that the octets need to be present. I'd argue for a fixed 4 octets in the long form though (I'm not sure what you intended with your mention of 1/2/4). >> I note that you can use 0x08 to check if the packet is long or short. >> We should try to keep that property until we can't any more. > > > I'd argue against that. This means that all code points including 0x80 are > lost, and I don't see what you gain. Checking if the packet is long or short > is easy: if the type is in {39, 3a, 3d, 3e, 3f, 1c} then it's long, and if > it's in {04, 84, 14, 94, 34, b4, 0c, 8c, 1c, 9c, 3c, bc} then it's short. > This isn't hard to do. That's fine with me. Note that I retain my desire to trim this list further. I will continue to push on the optional connection ID thing (as the lowest hanging fruit), but am happy to see us make forward progress on the other aspects in the meantime. From nobody Wed Feb 15 16:36:22 2017 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 2D6A6129863 for ; Wed, 15 Feb 2017 16:36:21 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 8Eis3UKVskRF for ; Wed, 15 Feb 2017 16:36:19 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FBFD12953F for ; Wed, 15 Feb 2017 16:36:19 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id r136so1616501vke.1 for ; Wed, 15 Feb 2017 16:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=YginCDONcOPLE4Cn9a5QINh8b4Bg2Ml242nIB66RTX4=; b=t1K6bvODc0zl/nUdthBjIucvg04nRcaekpHbFfSdE9DwIT56idPeyk3tBx5F47O34C X78RkYh0Mf4HY/lgwDnOs4E7iTKa5KOid48FvcEbLv2FYM7G1EYC1t/IMqXKOTPLbXqr 7g12mjNIW3CmRS1ckKnfPzQSI+PE8HfGXDR/3AbFTG1+9LlfvHNyRfFYsIxiQapgZbjW GhPee+9O7CIWSogwN9j8aBlg9Pq6rpf5Kp+/rO6P4lDRN2bF2R7IGz5Y6kA0mBv71iyO tOkhw+U/LmpXA/M9lOl3lbBb9hGO8JKtKA4tQvbuyhKxJTuHSLALNRPOF4I3gQTX00nN uKQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=YginCDONcOPLE4Cn9a5QINh8b4Bg2Ml242nIB66RTX4=; b=DJXL61j40doeE/Q/kguncjeDpC8T++MdxdJ1eYC/mO3oyFcO3/X3FjynemN8TUGb3B 5UlCpkmOFmlabGPiUIkWkgbs/bxCWtVIa2Z/LWh8cCk9WT2JeiNaEZZphYV4mnthHpUE R3IBsBsNjMou40w2i7FNWDqHrHbACdTBFXxNBcX+TpYpfWvfYy205L67CCYQU3iJEzX3 8HK28G/v8qzftzlk05XC3pxZrJ687y1RB04DzXatf90jAyuXcipJLH1q8vTdGM5yMfI6 cTqZG+998ZKE2wSJmniXZJ2zy0l+G9Fg0lWv6FDAfmkb6qcrmhtDN58bAU+nVXXisywZ oLhg== X-Gm-Message-State: AMke39lLuxDkcoglR7KevHyPkmpO42TGOAgpfZp3geb7fPO9zIU2cNdZWCkq0VXBVn25QABHw0koYpPEqVOoC+D0 X-Received: by 10.31.107.74 with SMTP id g71mr15787500vkc.116.1487205378434; Wed, 15 Feb 2017 16:36:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Wed, 15 Feb 2017 16:36:17 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Feb 2017 16:36:17 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114791004ab77205489afc6c Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 00:36:21 -0000 --001a114791004ab77205489afc6c Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 4:16 PM, Martin Thomson wrote: > On 16 February 2017 at 07:56, Jana Iyengar wrote: > > I think I like this. Can anyone think of reasons to not burn packet > number > > in the long header? > > If I understand what you mean by "burn" sure. Note that the semantics > don't need to be understood, it's just that the octets need to be > present. > Sorry, I meant to say "bake in" these 4 octets for all time, and agreed on your point about semantics. > I'd argue for a fixed 4 octets in the long form though (I'm not sure > what you intended with your mention of 1/2/4). My mention was in the public reset packet, which may be sent in response to a long packet with 4-byte packet number or a short packet with a 1/2/4-byte packet number. >> I note that you can use 0x08 to check if the packet is long or short. > >> We should try to keep that property until we can't any more. > > > > > > I'd argue against that. This means that all code points including 0x80 > are > > lost, and I don't see what you gain. Checking if the packet is long or > short > > is easy: if the type is in {39, 3a, 3d, 3e, 3f, 1c} then it's long, and > if > > it's in {04, 84, 14, 94, 34, b4, 0c, 8c, 1c, 9c, 3c, bc} then it's short. > > This isn't hard to do. > > That's fine with me. Note that I retain my desire to trim this list > further. I will continue to push on the optional connection ID thing > (as the lowest hanging fruit), but am happy to see us make forward > progress on the other aspects in the meantime. SGTM. The reason for leaving in connection ID is to keep the packet as self-descriptive as possible, allowing network devices to know whether to look for a connection ID in the packet or not, since connection ID is used for routing. Additionally, network tooling (say, wireshark) to be able to tell whether to look for a connection ID in this packet or not. --001a114791004ab77205489afc6c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 4:16 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 16 February 2017 at 07:56, Jana Iyengar <jri@google.com> wrote:
> I think I like this. Can anyone think of reasons to not burn packet nu= mber
> in the long header?

If I understand what you mean by "burn" sure.=C2=A0 Note t= hat the semantics
don't need to be understood, it's just that the octets need to be present.

Sorry, I meant to say "ba= ke in" these 4 octets for all time, and agreed on your point about sem= antics.
=C2=A0
I'd argue for a fixed 4 octets in the long form though (I'm not sur= e
what you intended with your mention of 1/2/4).

<= div>My mention was in the public reset packet, which may be sent in respons= e to a long packet with 4-byte packet number or a short packet with a 1/2/4= -byte packet number.=C2=A0

>> I note that you can use 0x08 to check if the packet is long or sho= rt.
>> We should try to keep that property until we can't any more. >
>
> I'd argue against that. This means that all code points including = 0x80 are
> lost, and I don't see what you gain. Checking if the packet is lon= g or short
> is easy: if the type is in {39, 3a, 3d, 3e, 3f, 1c} then it's long= , and if
> it's in {04, 84, 14, 94, 34, b4, 0c, 8c, 1c, 9c, 3c, bc} then it&#= 39;s short.
> This isn't hard to do.

That's fine with me.=C2=A0 Note that I retain my desire to trim = this list
further.=C2=A0 I will continue to push on the optional connection ID thing<= br> (as the lowest hanging fruit), but am happy to see us make forward
progress on the other aspects in the meantime.

<= div>SGTM. The reason for leaving in connection ID is to keep the packet as = self-descriptive as possible, allowing network devices to know whether to l= ook for a connection ID in the packet or not, since connection ID is used f= or routing. Additionally, network tooling (say, wireshark) to be able to te= ll whether to look for a connection ID in this packet or not.
--001a114791004ab77205489afc6c-- From nobody Wed Feb 15 17:05:06 2017 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 C48F6129407 for ; Wed, 15 Feb 2017 17:05:05 -0800 (PST) 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 oKvrbPKV428W for ; Wed, 15 Feb 2017 17:05:04 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F944129C0A for ; Wed, 15 Feb 2017 17:05:04 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id x49so2598155qtc.2 for ; Wed, 15 Feb 2017 17:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M6Xk/jjeKYu2kZvk8mL5/2lArd7QiTFbJ3WdCYHVAZU=; b=PaspeOSwdd21YXjtH734bwngK0zhdAun41ncarcEciGZU5mXMpD22aoBxhJp7G9C3C Fbvx3QMzXWOgba2F6+FqSQPXiqn4ftmdQuIPEM1PRgxyqv4/tSsHnFjr0hpwPvKOqD8t rYxB1efMUULdtbNImuAtrnm9AH8VC35Zn1HIbnUcxBTQ8xEuMdluvFN9/kVZqqbsA8kF B12PUmd7NEsiZW6c1CerRI8mR70b0G3FANrTdTD7c2f/Mgr1LFezYSTA04c9KczDb3Si TrlQWq0GMg6ParcJ/N64uo079YIHXEdBm+LFD4jDSx2LdGr3ehyEByg6jYNY95vxOzHW R/Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M6Xk/jjeKYu2kZvk8mL5/2lArd7QiTFbJ3WdCYHVAZU=; b=oDHiY8SXNsS1wm3gYzjllGRITB/ZIrrtMMuqgpawOOeGF2taCj4jvi7lzMunnz3R2s 9j8dO6N4u952kFbtzG348UKJ6cIHXef+oSnfcPIlzCsJ8xaodg9LJM6h9Jtt69Amziib HPje8oGOh06XEaE1AfGBhZdwfJApoKRwFfpVALw8mPlto7Qqz3VVZGPT8K6hBjJ/Lj5J u+jMtcToRMS+oXoSvRUH4DvIpKkzlxlCtgZL/7411wN7G278B9Lh/5Zp9tvZSPT324YK XIKfDFKwLQ5W9s9s5hxhfPIU841uNJ3Cou9H0yWhqY3Gq7kEMqb6OFE/5viBdjp9Aq3J 8CBA== X-Gm-Message-State: AMke39m7+xpDvCCzF5iiaGAprocwe+CAJ4I8ooMRe6aL6GapTP/Avgn6cI5+kgkgb4Q2mi2jCsKzqHTiud8cAw== X-Received: by 10.200.53.247 with SMTP id l52mr35619761qtb.144.1487207103846; Wed, 15 Feb 2017 17:05:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 17:05:03 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 16 Feb 2017 12:05:03 +1100 Message-ID: Subject: Re: Alternate header proposal To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:05:06 -0000 On 16 February 2017 at 11:36, Jana Iyengar wrote: >> I'd argue for a fixed 4 octets in the long form though (I'm not sure >> what you intended with your mention of 1/2/4). > > My mention was in the public reset packet, which may be sent in response to > a long packet with 4-byte packet number or a short packet with a 1/2/4-byte > packet number. Ahh, that's fine. In the case that packet number is short, I guess the public reset will be sending the first 2 or 3 octets of the payload. That's something for implementations to remember. We'll need special text on that. I think that it's relatively easy to implement that way, but it's not something that will be obvious. > SGTM. The reason for leaving in connection ID is to keep the packet as > self-descriptive as possible, allowing network devices to know whether to > look for a connection ID in the packet or not, since connection ID is used > for routing. Additionally, network tooling (say, wireshark) to be able to > tell whether to look for a connection ID in this packet or not. Well, if you retain the ability to break stateless inspection by removing connection ID, I'm not sure what value there is in explicitly telling them that they are screwed given that they have no recourse. Unless you are saying that the consequence is that 5-tuple identifies the flow when the connection ID is absent, but I'd just use the same argument. Connection ID is only really useful if you are multiplexing on the same 5-tuple - don't do this please - or you have changes in 5-tuple. If you remove it, then you can't change 5-tuple. (If you haven't guessed already, connection ID is the single feature of this protocol that I am most conflicted about. I can see so many advantages and so many disadvantages. They are all potentially huge and that means that I don't know how to make the trade-offs sensibly.) From nobody Wed Feb 15 17:28:04 2017 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 75C5A129C35 for ; Wed, 15 Feb 2017 17:28:02 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 4SOxoddK278b for ; Wed, 15 Feb 2017 17:28:01 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA53E129C34 for ; Wed, 15 Feb 2017 17:28:00 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id c85so55430929wmi.1 for ; Wed, 15 Feb 2017 17:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7Si+j3klEtxqtTmU/oiE1lS2tZpbZAqx40y3HmFIgA0=; b=YdlkJo7zPgXbGnVeaj+wO4Et4E6zn6TO6FFru7kZRT7fBrV7Ky0lHTNCv+v6sIgUCh v/ni5sXEpWt+HAU6QkQSRjUsfqqlwsISk+egrhcg27PX+osxgfS4J7OKfrco/qTtfPmz kONzRBXc50J+LlJ93TFlX1+iYev2Gikbsr4sAi6W1OLhu2GjxT1EyHc4GcKBd9ZHJ5+A SfKa38p3UlILaGnkVqcaPo+Ez1X4tpsY59uslKxixO7eJlAhnnrxY51c+6Ws7PDdtmyR r3oQkNbxnMbHuJ7wUEgMfbtRbRnZpNNzvDC3FJdpzkV9YGqpQSgJNaTS2PIFtvZUEBg8 8Uag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7Si+j3klEtxqtTmU/oiE1lS2tZpbZAqx40y3HmFIgA0=; b=R7RHPFRRgpnNsSrXNycra3PXT0u9YmxMuF4jkzBLl6zFnOr848D0r1lU5dByiZTsEi 3HuPPAPYUCbNs+HY3LuJave9JEJpUNUEqjRjf7S8wuQR4UlNmzj/E6etxcTODwFntTx2 ezYkM8iQ8Jy3x5DQe2se+ymcP1kAAzggUf75AGVK9LNJ2k+KX40lbtwioAObryo30Qj5 /RFdiIVQIkYqLLJkHEBXCCj/wTFXmqohas1qCJcUeth4fvZ55j0ErYk68+O9n3I2R36o EtDJsvYicEM+eaKbnlkT+3+g9Zr8lkhOq42JyZZNFOK7WK34GU0tzDtLdFJbxtupCM39 lgrA== X-Gm-Message-State: AMke39nP8myVG6//rcidAM3LGCVtndIbxrJ6d5N8p+W70Hrm4mEU3vitFeh8miTvo1eQRQjozIdPMihQB86JX9qI X-Received: by 10.28.38.2 with SMTP id m2mr9941325wmm.44.1487208479233; Wed, 15 Feb 2017 17:27:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Wed, 15 Feb 2017 17:27:58 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Wed, 15 Feb 2017 17:27:58 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c03fb961d01bf05489bb5ad Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:28:02 -0000 --94eb2c03fb961d01bf05489bb5ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Feb 15, 2017 at 5:05 PM, Martin Thomson wrote: > Unless you are saying that the consequence is that 5-tuple identifies > the flow when the connection ID is absent, but I'd just use the same > argument. Connection ID is only really useful if you are multiplexing > on the same 5-tuple - don't do this please - or you have changes in > 5-tuple. If you remove it, then you can't change 5-tuple. > > (If you haven't guessed already, connection ID is the single feature > of this protocol that I am most conflicted about. I can see so many > advantages and so many disadvantages. They are all potentially huge > and that means that I don't know how to make the trade-offs sensibly.) > =E2=80=8BAs you're thinking through the pros and cons of this issue, keep i= n mind that short NAT rebinding timeouts for UDP flows are a terribly unfortunate fact of life on the internet today. If a QUIC connection is unable to change the 5-tuple, I suspect that will be a big challenge for QUIC adoption since these NAT rebindings are essentially invisible to the client= . --94eb2c03fb961d01bf05489bb5ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 5:05 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
Unless you are saying that the conse= quence is that 5-tuple identifies
the flow when the connection ID is absent, but I'd just use the same argument.=C2=A0 Connection ID is only really useful if you are multiplexing=
on the same 5-tuple - don't do this please - or you have changes in
5-tuple.=C2=A0 If you remove it, then you can't change 5-tuple.

(If you haven't guessed already, connection ID is the single feature of this protocol that I am most conflicted about.=C2=A0 I can see so many advantages and so many disadvantages.=C2=A0 They are all potentially huge and that means that I don't know how to make the trade-offs sensibly.)<= /div>

=E2=80=8BAs you're thinkin= g through the pros and cons of this issue, keep in mind that short NAT rebi= nding timeouts for UDP flows are a terribly unfortunate fact of life on the= internet today. If a QUIC connection is unable to change the 5-tuple, I su= spect that will be a big challenge for QUIC adoption since these NAT rebind= ings are essentially invisible to the client.
--94eb2c03fb961d01bf05489bb5ad-- From nobody Wed Feb 15 17:32:48 2017 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 D5B18129C3E for ; Wed, 15 Feb 2017 17:32:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham 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 MQb7nTsiF1Oi for ; Wed, 15 Feb 2017 17:32:45 -0800 (PST) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 251BA129C3D for ; Wed, 15 Feb 2017 17:32:45 -0800 (PST) Received: by mail-qk0-x229.google.com with SMTP id p22so3399304qka.0 for ; Wed, 15 Feb 2017 17:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lOmiXdeUuEwSr3NHhJN3T31Bd7vG1YsKquP9jBVo5WY=; b=Q+smRjxLVVVUGsO3mQxQx1NwGMoiLhCNjVXBLapJw//rG30os7VzEOFCZUwBbCw3fR KuYnMt05JhoAgw5j4pLGSzzP8IhERZJk9J58Xu1cc4nAuwyfHIyMB0ZxfZrAzzCWbAes FArzE12zAVNHkuhlnIE7Re9EmRR+O6N1ZBWnCKx5PlV5is3xGIboUejkRzsonAzZ2AUN IF8mv+9pBnSQaMwj2x6NEUMO7gsEx9ys8ZlOhaZH89tOKz/iI/Y2M/hKAzBYZoNM1vw9 jtrVRZnhQrw3htJ9+1B/Fyxhkp1epPEz+JHQSHN0HI1gaddRbprlBDmz2knhHVDgYL6T 8BzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lOmiXdeUuEwSr3NHhJN3T31Bd7vG1YsKquP9jBVo5WY=; b=IlEvjcmSmSZ8zIYNmGs992jwcxa2aMMKDZLrLBlXcTiTEc589A4WcqSP4+O7nMtZmm 5AMqj+DK6ezIvauCaCiDg5a3upcbsusExCKP7+oaJiobngXYn/snBIzTlBFcqKl8Aa1y a3EcCyYg8jWx0Zq6W13WgbQRCb35CgVWiXZJghw2auE17wVZLDcCxeOiZNqLUVSWXp8b B6dA0nTjwCgymEEZ2n0C/r0Km8RZ9rZFfRdiEIWEOoz9UZTGlZbO9leXw4K1GvJmCGZc tqaRgCsT01gEbRKxJQO5Ga3nJcHG9a9Vy4VLS2Wx3O2ND+IbryWe8J1U34IazXAJ0cA/ odsA== X-Gm-Message-State: AMke39kWiqVDEwAul5TV0Dlslxpy9cShdBDtw7c3T8sJVlD+UKO6DUSEKWyYuXObECkly1EaPi47jypqCWq/kA== X-Received: by 10.55.200.217 with SMTP id t86mr16090577qkl.5.1487208764323; Wed, 15 Feb 2017 17:32:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 17:32:43 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 16 Feb 2017 12:32:43 +1100 Message-ID: Subject: Re: Alternate header proposal To: Ryan Hamilton Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:32:47 -0000 On 16 February 2017 at 12:27, Ryan Hamilton wrote: > As you're thinking through the pros and cons of this issue, keep in mind > that short NAT rebinding timeouts for UDP flows are a terribly unfortunate > fact of life on the internet today. If a QUIC connection is unable to change > the 5-tuple, I suspect that will be a big challenge for QUIC adoption since > these NAT rebindings are essentially invisible to the client. That would be one of the big/huge advantages, of which I'm acutely aware. And also why I'm quite skeptical about having the ability to trim connection ID, but I guess your counter will be data-center use cases. From nobody Wed Feb 15 17:37:43 2017 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 6079E129C33 for ; Wed, 15 Feb 2017 17:37:42 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 U5Yddx_tsv1V for ; Wed, 15 Feb 2017 17:37:41 -0800 (PST) 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 E10A0129442 for ; Wed, 15 Feb 2017 17:37:40 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id v77so4631171wmv.0 for ; Wed, 15 Feb 2017 17:37:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qP4UgzG1LKl/auC67KZ/lAqPLDM6KjIgQx0V0W4wVNY=; b=aYDAgbYkH4lCLJpUnyNoqgWd/5XjhlaDOR6UHW/EwBtQiNi+5KP09UOy/UOFwWAgTm oiBr1INi7/5a9fNy3BngwaD2yw4oIUJfGU6HFvdFct/tYF1DOKxkuP9gsEsy5EZP+JqA YAfIuYHj8mTuIA+YVEYhQIEBSP0z3qU3uR9PfHQZUfV+9HQK+FK6CAkBpGHNu6dlquYP 33Wr62UpxvLUf4BKJHAw3OfnfxekalwywxuYGeZYWXJdYTjH+ecCe3qIesU0FyV471j2 wR/lWrxpxE5QgWcJmmm79YuTWqTUcpqM0r/g5OgrVOumTKosM3s8R3gzIUPhTn+g6jua 9JXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qP4UgzG1LKl/auC67KZ/lAqPLDM6KjIgQx0V0W4wVNY=; b=jc0kiEQsOzakcox4V/culAvgPODFJYerjd3HjRsYaLD7UgCUczuL7muE8uThpwOAh3 QbdZ59+eHrKUPmH1fDJxtpBIZeUGeDCoqeLkm12xL2Az48KVF4e+yzQTXIUeW+6aK9td OK9Qz2OctcM3A/xBoTkUfRdeN4UTvyVv5FACMPO9rdeVV2Wm/J+oem+nkLzLOpfhMb2h mAFzvGPzi/Rb6HamxRFY5Iplw3HPtZwF5VtaiTukrbotzZ5oGH+LE77UPlEkKm2AkEN+ uuWUo/A8CdkcOcYiYULIafu3g3imZjOIyYwELb6evTAFqMxLbXJYPsH48FnFQp7NEvgL Mc2w== X-Gm-Message-State: AMke39nn/AxsADXCMO35JBlVMerv6c2+Pur+VzkrBDwPzPber/h8txDkcxfE3CwB5q2fE0HOLGW0yAC61uT54LTo X-Received: by 10.28.191.79 with SMTP id p76mr10111330wmf.21.1487209059389; Wed, 15 Feb 2017 17:37:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Wed, 15 Feb 2017 17:37:37 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Wed, 15 Feb 2017 17:37:37 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c071272b1657005489bd76c Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:37:42 -0000 --94eb2c071272b1657005489bd76c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable =E2=80=8B=E2=80=8BOn Wed, Feb 15, 2017 at 5:32 PM, Martin Thomson wrote: > On 16 February 2017 at 12:27, Ryan Hamilton wrote: > > As you're thinking through the pros and cons of this issue, keep in min= d > > that short NAT rebinding timeouts for UDP flows are a terribly > unfortunate > > fact of life on the internet today. If a QUIC connection is unable to > change > > the 5-tuple, I suspect that will be a big challenge for QUIC adoption > since > > these NAT rebindings are essentially invisible to the client. > > That would be one of the big/huge advantages, of which I'm acutely > aware. =E2=80=8BFair enough! Sorry for harping on it.=E2=80=8B > And also why I'm quite skeptical about having the ability to > trim connection ID, but I guess your counter will be data-center use > cases. > Actually, I think it's super useful for the web use case. =E2=80=8BIn Googl= e QUIC, we have the server always omit the connection ID in packets it sends to the client (as the result of negotiation) because the client's socket is only associated with a single connection. Since this is the direction that the vast majority of the data flows, saving the bytes is valuable. (But in the other direction, from the client to the server, we always send the full connection ID, because the =E2=80=8Bserver has to multiplex connections fro= m client for which their underlying 5-tuple may change.) I hope that we are able to do this with IETF QUIC as well. (Man, I hate saying "Google QUIC" and IETF QUIC. We should retroactively rename Google QUIC to GUIC or something :) --94eb2c071272b1657005489bd76c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
=E2=80=8B=E2=80=8BOn Wed, Feb 15, 2017 at 5:32 PM, Martin Thomson <martin.thomso= n@gmail.com> wro= te:
On 16 February 2017 at 12:27, Ry= an Hamilton <rch@goog= le.com> wrote:
> As you're thinking through the pros and cons of this issue, keep i= n mind
> that short NAT rebinding timeouts for UDP flows are a terribly unfortu= nate
> fact of life on the internet today. If a QUIC connection is unable to = change
> the 5-tuple, I suspect that will be a big challenge for QUIC adoption = since
> these NAT rebindings are essentially invisible to the client.

That would be one of the big/huge advantages, of which I'm acute= ly
aware.=C2=A0

=E2=80=8BFair eno= ugh! Sorry for harping on it.=E2=80=8B
=C2=A0
And also why I'm quite skeptical about having th= e ability to
trim connection ID, but I guess your counter will be data-center use
cases.

Actuall= y, I think it's super useful for the web use case. =E2=80=8BIn Google Q= UIC, we have the server always omit the connection ID in packets it sends t= o the client (as the result of negotiation) because the client's socket= is only associated with a single connection. Since this is the direction t= hat the vast majority of the data flows, saving the bytes is valuable. (But= in the other direction, from the client to the server, we always send the = full connection ID, because the =E2=80=8Bserver has to multiplex connection= s from client for which their underlying 5-tuple may change.) I hope that w= e are able to do this with IETF QUIC as well.=C2=A0

(Man, I hate saying "Google QUIC" and IETF QUIC. = We should retroactively rename Google QUIC to GUIC or something :)
--94eb2c071272b1657005489bd76c-- From nobody Wed Feb 15 17:39:23 2017 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 DE372129C33 for ; Wed, 15 Feb 2017 17:39:21 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 M9EOtfFp_x3Y for ; Wed, 15 Feb 2017 17:39:20 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 463F5129C3F for ; Wed, 15 Feb 2017 17:39:20 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id t8so2188247vke.3 for ; Wed, 15 Feb 2017 17:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AXnx2yfZbOpbdQfLc3IBAq3AE+KOztj480PRB4CCwzE=; b=csVGxcGWvbT1rAG9FNvA0jscpaF8JADxmliLZayOPxXozHj7TXo6RptBJtUK1q8zcm lOvD22cQb/qpW/qCDiW0SFIzAuXGBHtZtOpULbdbd7MC+V8OySs5/Ob3wMhMCB44rkKp kFtiM0vyyIjIZzJLv5kDeR+dmARZZ8ktxsboECWFFvGCwYL+UsRrTgkrnObxTsazrvcR WljNsmQV6vNOG5g5WLTOeMup7BfWL8hU0v9KwuXrYP3kS1ryiK/urPgl1w4sn80BBEzj O1/lfuo6ixHewNoO+IYamc3s96Ijers9K0zt8Vy4wvM808POKdvwRe0FuzqnTu+M+xi7 OgRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AXnx2yfZbOpbdQfLc3IBAq3AE+KOztj480PRB4CCwzE=; b=avshxwAcuouG4BgevmVAT1jOyOOi/8aQjO2ZF59EJuN5vSPtTslAXbW1epy4tm//7W rR36rKzPWLkwBkBmDtGvAjkPLyyQs4G/0BqhonafJCJPnUGIjJWPhRCoO1vdn508Pdlf BIoXbOJBi0/P/CTaFTQ3A5BRDx6d6zxeB5BnQMwqLBReKqru0D7vvDfT6pG8P2e4PUic KAa8b1RCHsiTshOmA/s4tIYE/fqVBplXSRSe5VmSXqA11fvFPsb0JU3F9ViNLW+xxc6O y4DYmpT0+ZH+yjHgXV7y+PbCW0VHlsL+giMyuvvlN/nJaVjiBLzYhnPiHkVRemYCll9O VTjw== X-Gm-Message-State: AMke39kDfXI/PG9WPz0sMCyfneghWwDNcrKmCtJCIFg2oGaf62PJNjVgoqBkjshjEW6VaNngVdMIrgqMCcwDxFWG X-Received: by 10.31.99.1 with SMTP id x1mr18907314vkb.161.1487209158908; Wed, 15 Feb 2017 17:39:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Wed, 15 Feb 2017 17:39:18 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Feb 2017 17:39:18 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=94eb2c07b1789fff2c05489bdd46 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:39:22 -0000 --94eb2c07b1789fff2c05489bdd46 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 5:05 PM, Martin Thomson wrote: > On 16 February 2017 at 11:36, Jana Iyengar wrote: > >> I'd argue for a fixed 4 octets in the long form though (I'm not sure > >> what you intended with your mention of 1/2/4). > > > > My mention was in the public reset packet, which may be sent in response > to > > a long packet with 4-byte packet number or a short packet with a > 1/2/4-byte > > packet number. > > Ahh, that's fine. In the case that packet number is short, I guess > the public reset will be sending the first 2 or 3 octets of the > payload. That's something for implementations to remember. We'll > Right, payload in this version, but really, whatever follows the packet number. Of course, if the connection ID is absent in the received packet then the structure of what's echoed back is different. But the client should know how to interpret the 12 bytes since it sent them. > need special text on that. I think that it's relatively easy to > implement that way, but it's not something that will be obvious. > > > SGTM. The reason for leaving in connection ID is to keep the packet as > > self-descriptive as possible, allowing network devices to know whether to > > look for a connection ID in the packet or not, since connection ID is > used > > for routing. Additionally, network tooling (say, wireshark) to be able to > > tell whether to look for a connection ID in this packet or not. > > Well, if you retain the ability to break stateless inspection by > removing connection ID, I'm not sure what value there is in explicitly > telling them that they are screwed given that they have no recourse. > > Unless you are saying that the consequence is that 5-tuple identifies > the flow when the connection ID is absent, but I'd just use the same > argument. Connection ID is only really useful if you are multiplexing > on the same 5-tuple - don't do this please - or you have changes in > 5-tuple. If you remove it, then you can't change 5-tuple. > You are assuming that connection ID is gone in both directions, which isn't true. In the common case, which is what Google's deployment does, you allow NAT rebinding at the client by having the client send connection ID on packets. If they're absent in the server->client packets, that disallows IP/port change at the server, which is entirely fine, since the server's not behind a NAT. > (If you haven't guessed already, connection ID is the single feature > of this protocol that I am most conflicted about. I can see so many > advantages and so many disadvantages. They are all potentially huge > and that means that I don't know how to make the trade-offs sensibly.) > Do you have more disadvantages besides the potential of increased link-ability? --94eb2c07b1789fff2c05489bdd46 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 5:05 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 16 February 2017 at 11:36, Jana Iyengar <jri@google.com> wrote:
>> I'd argue for a fixed 4 octets in the long form though (I'= m not sure
>> what you intended with your mention of 1/2/4).
>
> My mention was in the public reset packet, which may be sent in respon= se to
> a long packet with 4-byte packet number or a short packet with a 1/2/4= -byte
> packet number.

Ahh, that's fine.=C2=A0 In the case that packet number is short,= I guess
the public reset will be sending the first 2 or 3 octets of the
payload.=C2=A0 That's something for implementations to remember.=C2=A0 = We'll

Right, payload in this version, but really= , whatever follows the packet number. Of course, if the connection ID is ab= sent in the received packet then the structure of what's echoed back is= different. But the client should know how to interpret the 12 bytes since = it sent them.
=C2=A0
need spe= cial text on that.=C2=A0 I think that it's relatively easy to
implement that way, but it's not something that will be obvious.

> SGTM. The reason for leaving in connection ID is to keep the packet as=
> self-descriptive as possible, allowing network devices to know whether= to
> look for a connection ID in the packet or not, since connection ID is = used
> for routing. Additionally, network tooling (say, wireshark) to be able= to
> tell whether to look for a connection ID in this packet or not.

Well, if you retain the ability to break stateless inspection by
removing connection ID, I'm not sure what value there is in explicitly<= br> telling them that they are screwed given that they have no recourse.

Unless you are saying that the consequence is that 5-tuple identifies
the flow when the connection ID is absent, but I'd just use the same argument.=C2=A0 Connection ID is only really useful if you are multiplexing=
on the same 5-tuple - don't do this please - or you have changes in
5-tuple.=C2=A0 If you remove it, then you can't change 5-tuple.

You are assuming that connection ID is gone in= both directions, which isn't true. In the common case, which is what G= oogle's deployment does, you allow NAT rebinding at the client by havin= g the client send connection ID on packets. If they're absent in the se= rver->client packets, that disallows IP/port change at the server, which= is entirely fine, since the server's not behind a NAT.
=C2= =A0
(If you haven't guessed already, connection ID is the single feature of this protocol that I am most conflicted about.=C2=A0 I can see so many advantages and so many disadvantages.=C2=A0 They are all potentially huge and that means that I don't know how to make the trade-offs sensibly.)<= br>

Do you have more di= sadvantages besides the potential of increased link-ability?
--94eb2c07b1789fff2c05489bdd46-- From nobody Wed Feb 15 17:41:43 2017 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 2AAB3129C33 for ; Wed, 15 Feb 2017 17:41:42 -0800 (PST) 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 DfXaqJor_tdF for ; Wed, 15 Feb 2017 17:41:41 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::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 F247A1297C9 for ; Wed, 15 Feb 2017 17:41:40 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id v23so3181202qtb.0 for ; Wed, 15 Feb 2017 17:41:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IiXhXfXDaWrjFf2/QYtKgwc4A3nBRH2lLuwzbMYCJ3g=; b=b9A18kMPw4THyx+5hCdvj1b5h1OuftUeTQ7VdsE5EQ5wgGKJLPo7a97kR8ofyGnoGJ ieijHoMVZfO4iwxvEtxacoTc4p2JqzDOhC2gFvMnZ/XuOupNfMEYE9I3VsbEbP4lSmf5 NTJrmOYgxNm8iSU8kdMrHYOHwpDMefakcpr3v0+TKo+aWyzAUBwMEDxWyjdaC1nRSA9u n1hGnQxyKUpZOtLRVz+3/oKKybEz2YryOttiJIP8BH/Mapoj/wQB17q2rNew7KMpJXRX fOMCLc1W991Y1HVWP77BIP6p0th0Q95adacFzW8HwotNxn/qOfYFCWqXThj+cZiF3BaE CdHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IiXhXfXDaWrjFf2/QYtKgwc4A3nBRH2lLuwzbMYCJ3g=; b=DiDQgscxIgolk1UpKioyUaHV09jB5fH9n/AviRxZaX1EfWrhK1V/xgHuX5XAJ8WkNM /cjs+YpbGhhsetI9YhPGKqeCBdHtQGc5RSGW583iTq9MBxbWlS64L+I+i0zLbZTfrYai OrmisVQCeRCBHoo1uQBONdA/Yz16wadr2s2D7cDIPBHonsTZpgCicmDiNg1G5CL6tHG3 fSeAo/Gyb3bv3EX5FM7S4E+GQg1zRE+b0tYK+DbsEHlB6kiEz5BRdQ0v907w57OLM+Br wQXDyBiYipWvEhIg0FThSkK1MHR/ZdwKlpRln+4OUAYSBxtwWim0SlddDDT03aha8SY+ sfAQ== X-Gm-Message-State: AMke39lxjSYU/mNe5aeDcoxyDhhN1opryZyx41ysA1VREj1gERHISmj0MPG6FQqgZ8Y2at841bXvjiK7j0eGTw== X-Received: by 10.237.55.97 with SMTP id i88mr38211087qtb.143.1487209300219; Wed, 15 Feb 2017 17:41:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 17:41:39 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 16 Feb 2017 12:41:39 +1100 Message-ID: Subject: Re: Alternate header proposal To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:41:42 -0000 On 16 February 2017 at 12:39, Jana Iyengar wrote: > Do you have more disadvantages besides the potential of increased > link-ability? Bloat. We just took great paints to trim a couple of octets from the packet number, saving a whole 2 octets in the best case. But connection ID is 8. From nobody Wed Feb 15 17:45:25 2017 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 7E05012964A for ; Wed, 15 Feb 2017 17:45:24 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 95wHJoD6ZztQ for ; Wed, 15 Feb 2017 17:45:23 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 7A9DA129400 for ; Wed, 15 Feb 2017 17:45:23 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id k127so2338183vke.0 for ; Wed, 15 Feb 2017 17:45:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+y4qXhD4NqNJr0mPFpduv8xmRTtQGRNjZsRCBg/Or5k=; b=F8fk6iCyJ8fUC8+Cek3Xs6KawOw1p0qGQcCwMD/oQUWS5N62JRoe92L7IZM5dIXrFB 4EuYDm1oXmjULuTguUvu/JqWzAAhEvy/znSRYlYzLlH2GsavCDhnbLEPUgC+YxMGFBFS Zgu2P2zKI2UGbXeYJzqam3Q9vLCVh0qUaZw7sFjMsYHU0o0VRmlnk9v/tXzV82AfxpfX K4iuKv8vOkAVqmqtYn0fLm2VrAkTgBuq4ZJXuxUc7wo8qC9L7ba6JC+AeFvevzZww0F1 J+AtkpDnaMmlU2wT2pcnoUvHbuigrxpjR4zfGOMY9RkBG2lNpzgFbCG0gy7/UAextMM6 b+3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+y4qXhD4NqNJr0mPFpduv8xmRTtQGRNjZsRCBg/Or5k=; b=BR9s42iAdGt0yxuTpUDsi3HITgTxvL5GNrR+hMY1JH54jfgwKzHYCFH+WfaHo92Ayr kWCBm+m4nEZgPtRF9CZqJdn2hwLXd1dygrhcLirlUVKz1afmOvgPUlWYULddu9z+eP62 DGPcGgaxg7sKH2oA8HpcmczJrf+O6ObwRTDiSQ4TtZ0eIy5fBJynTVfdrEE0XyP0kzoj zagJM9Z+R1Li9MtG8kNHupJ8Ywy0RjRCI3nHVqWnDKOGTxJ2zutJnmUoG7VNwj6IVtTr j5NrBuhu2POgPl4+R6H0r4CyG7aWOkhSOVEj/2q+8W3KfP6owE/8i5x6J/36x94GXMby a8hA== X-Gm-Message-State: AMke39lbEdHuB9F+OyEBIw6JKQyDDB2gJm9kwG55EUtadi8sVVuDfD4ZGRjwIb8YWVlBCcIfcABKcH28vCOG3V5+ X-Received: by 10.31.107.74 with SMTP id g71mr15893553vkc.116.1487209522190; Wed, 15 Feb 2017 17:45:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Wed, 15 Feb 2017 17:45:21 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Feb 2017 17:45:21 -0800 Message-ID: Subject: Re: Alternate header proposal To: Ryan Hamilton Content-Type: multipart/alternative; boundary=001a11479100470ea805489bf30d Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:45:24 -0000 --001a11479100470ea805489bf30d Content-Type: text/plain; charset=UTF-8 > > (Man, I hate saying "Google QUIC" and IETF QUIC. We should retroactively > rename Google QUIC to GUIC or something :) > HistoriQ? Actually, let's not change the name and just get used to calling it Google QUIC and IETF QUIC :-) --001a11479100470ea805489bf30d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
(Man, I hate say= ing "Google QUIC" and IETF QUIC. We should retroactively rename G= oogle QUIC to GUIC or something :)

<= /div>
HistoriQ? Actually, let's not change the name and just get us= ed to calling it Google QUIC and IETF QUIC :-)

--001a11479100470ea805489bf30d-- From nobody Wed Feb 15 17:55:29 2017 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 BA7E91297C9 for ; Wed, 15 Feb 2017 17:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 iPRcW1IrYxal for ; Wed, 15 Feb 2017 17:55:26 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 6A41F129484 for ; Wed, 15 Feb 2017 17:55:26 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id y9so2461177uae.2 for ; Wed, 15 Feb 2017 17:55:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=l4ZG3VLCM7IeCMEcD/zL2PGYelVL5HjRaTTeWZRO/UY=; b=l9nxl/pWr7n0HL31dqDSp4SX4bNigktQwOvlYqwNKJoyaRHcJkF1fIeVtCeGVz2OTq teW6pes26a+kPCCTAYNuXNWHmxvsDHh+tv7lcw5W4wg9U2hl9e4bvpehNm8Azfv6Zj6U Tb3L7ai0jvdfTtWzQpS0g9AdvRLmNPUsOE+zc0ndrwAep9CZS0AlwgOHefQwDHjOU0JV 3cKQK24xIGvVmGZE/hyYq6jBn8TGTmFx6wWZcg2wLc+XK3Bl5TwreiyCJhLA9odfKaKf fgY2p/y2Vx80Af7WY0wRn3SxOvw5+E+wlRQyEiA61V6l1DqgabjvUP2/qUgeFfI+c1AB SejA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l4ZG3VLCM7IeCMEcD/zL2PGYelVL5HjRaTTeWZRO/UY=; b=ssxQnxi8NPu8pCwwkRxed/hCm+ulFEfZMQ0e/wrt4d4lgx6L9bEq/bn3807DAJh92P lD/iKCzEt9zSpbZXyBbYfU5fbFiG48S2h2Qfkw+0bk15yNWnnhSqJEdDLP2berda7gnP YcYx/i8yn5ehi3kE2bL9nO3bbl1KbQvk6mWnAcW867dolohadlDTybthGP/xfRZjNCCJ 8srgp13GepqLMxXpiMC/FCJyODome3wVwSgVu0niCDEdfEWUnmfMKN9Ejrn1EFQkExwl +GShGySWtyfmMXntlGEIt96Ice95IYO96CbKr+4Wrsm956441lX144/R3PAr1QWOetwP Pi+Q== X-Gm-Message-State: AMke39nAadHVm18ha5SUfM2l4kbvx7//icvl4BxR8x5Ovvtilx8RkvkemI/LG4BKwQ1CknRYEn6SZktn4iZRbZP7 X-Received: by 10.176.83.153 with SMTP id k25mr17135789uaa.141.1487210125200; Wed, 15 Feb 2017 17:55:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Wed, 15 Feb 2017 17:55:24 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Wed, 15 Feb 2017 17:55:24 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045dd7ec3874f705489c17e7 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 01:55:28 -0000 --f403045dd7ec3874f705489c17e7 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 5:41 PM, Martin Thomson wrote: > On 16 February 2017 at 12:39, Jana Iyengar wrote: > > Do you have more disadvantages besides the potential of increased > > link-ability? > > Bloat. We just took great paints to trim a couple of octets from the > packet number, saving a whole 2 octets in the best case. But > connection ID is 8. > It's optional and commonly not needed in the server->client direction, which makes it avoidable it in the commonly bandwidth-constrained direction. It's what Chrome negotiates currently: it tells the server that it doesn't need connection ID on incoming packets, but it sends them on outgoing packets. --f403045dd7ec3874f705489c17e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 5:41 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 16 February 2017 at 12:39, Jana Iyengar <jri@google.com> wrote:
> Do you have more disadvantages besides the potential of increased
> link-ability?

Bloat.=C2=A0 We just took great paints to trim a couple of octets fr= om the
packet number, saving a whole 2 octets in the best case.=C2=A0 But
connection ID is 8.

It's optional a= nd commonly not needed in the server->client direction, which makes it a= voidable it in the commonly bandwidth-constrained direction. It's what = Chrome negotiates currently: it tells the server that it doesn't need c= onnection ID on incoming packets, but it sends them on outgoing packets.

--f403045dd7ec3874f705489c17e7-- From nobody Wed Feb 15 18:29:21 2017 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 91826129B91 for ; Wed, 15 Feb 2017 18:29:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.487 X-Spam-Level: X-Spam-Status: No, score=-4.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 FqnwdRDjTOD2 for ; Wed, 15 Feb 2017 18:29:18 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 EB5D6129428 for ; Wed, 15 Feb 2017 18:29:17 -0800 (PST) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1ceBoq-00085k-B6 for quic@ietf.org; Thu, 16 Feb 2017 03:29:17 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ceBoo-0004Ef-Rr for quic@ietf.org; Wed, 15 Feb 2017 21:29:15 -0500 Received: (qmail 8606 invoked from network); 16 Feb 2017 02:29:14 -0000 Received: from unknown (HELO [192.168.200.66]) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 16 Feb 2017 02:29:13 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: <90f6c1ab-6c6c-8d5d-e69f-201a902e9174@huitema.net> Date: Wed, 15 Feb 2017 16:29:10 -1000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5BC38D8CE46C3A03BC1FB942" Subject: Re: Alternate header proposal X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.33) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49MJIIgmXWciG0xIgIHG/MnhTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoVltk7ZD+dZuVzatbdR/aGRcOb18WfxGyg6Om6u4YYm3utiuUkdHTBDAqQ s61Tvj45hjoyEb9Oq0NWpyO3vrfYKtU04a0dsdHkKEFmS31kUD3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBkye6uEH7Y2FUSOL4rzI+gxQRCdMNhge1Unb77YyuZq6UWKljugeAm0QTULwk1+XGRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f1ZS3ljmeFVRIgA8pd5GE2NV TgVI3tePcP+0TP9kyYEYXZQoLm3WrM4CkGLF6uNr9weYUOp7A73HI6oJg7w/VodqDS3jhFVyYvjB Ar8iUjNZzB9tfY+mOJVw0e2xMRa7D2P5RYOa/miinTReZ5OdasFBlor8ikxQTKPsYxS4ne8tEzDd JFEeZx0L8qYzBLK5yNBqLkXGaznuCfaQ1w/JpOE= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 02:29:19 -0000 This is a multi-part message in MIME format. --------------5BC38D8CE46C3A03BC1FB942 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/15/2017 1:36 PM, Jana Iyengar wrote: > On Wed, Feb 15, 2017 at 3:01 PM, Mike Bishop > > > wrote: > > It seems like there=E2=80=99s an emerging idea (which has been pres= ent all > along) that there are really two subdivisions of QUIC: > > * QUIC-for-all-time: Forever-fixed packet layouts carrying > version negotiation, public reset, etc.; can carry > version-specific headers/payload as well if you=E2=80=99ve agre= ed on > the version > o If you change these, you=E2=80=99re defining a new protocol= that > has to be distinguishable from QUIC in some way > * QUIC-for-now: Version-specific packet layouts carrying > version-specific payload > > Yes. Working through Martin's proposal and trying to fix the things in > there led me to a couple of other proposals along the way, but > chatting with Martin about the codepoint idea led me to this proposal, > which I think is a nice and elegant simplification of those proposals. > The core of this proposal is in making existing uses of the Flags byte > slightly more rigid, and making the rest of the combinatorial space > available for extensibility. > I am a little bit worried about the proposal to set the packet number size to 32 bits in "QUIC for now". I know that "4 billion messages in 100 milliseconds" appears ridiculously large right now, but do you really believe that we are not going to see 500 Tbps links in the future? Or maybe 1Tbps link to the Moon, or to Mars? Maybe not in my lifetime, but in yours? At that point, how do we get the "short form" to use 64 bit numbers? -- Christian Huitema --------------5BC38D8CE46C3A03BC1FB942 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 2/15/2017 1:36 PM, Jana Iyengar wrote:
On Wed, Feb 15, 2017 at 3:01 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

It seems like there’s an emerging idea (which has been present all along) that there are really two subdivisions of QUIC:

  • QUIC-for-all-time:  Forever-fixed packet layouts carrying version negotiation, public reset, etc.; can carry version-specific headers/payload as well if you’ve agreed on the version
    • If you change these, you’re defining a new protocol that has to be distinguishable from QUIC in some way
  • QUIC-for-now:  Version-specific packet layouts carrying version-specific payload
Yes. Working through Martin's proposal and trying to fix the things in there led me to a couple of other proposals along the way, but chatting with Martin about the codepoint idea led me to this proposal, which I think is a nice and elegant simplification of those proposals. The core of this proposal is in making existing uses of the Flags byte slightly more rigid, and making the rest of the combinatorial space available for extensibility.

I am a little bit worried about the proposal to set the packet number size to 32 bits in "QUIC for now". I know that "4 billion messages in 100 milliseconds" appears ridiculously large right now, but do you really believe that we are not going to see 500 Tbps links in the future? Or maybe 1Tbps link to the Moon, or to Mars? Maybe not in my lifetime, but in yours? At that point, how do we get the "short form" to use 64 bit numbers?

-- Christian Huitema

--------------5BC38D8CE46C3A03BC1FB942-- From nobody Wed Feb 15 18:58:54 2017 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 B433F129C7A for ; Wed, 15 Feb 2017 18:58:53 -0800 (PST) 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 2H7-ypYQ8Wri for ; Wed, 15 Feb 2017 18:58:52 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66553129C71 for ; Wed, 15 Feb 2017 18:58:52 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id 11so4462140qkl.3 for ; Wed, 15 Feb 2017 18:58:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ip76665p5dLpRCWkpQ/G3JB3M0LxYeJ+OWnRL5SExKc=; b=DvLQtnB7wv0QmaUx3+j5MMraTE/cPbq2iP41AoS89LeAQwnBDnS+KvBuW1pjm7sprJ rBDNYbGy24wOIKEwxrFEYvj2vtt3NjKf7nE0dGCz/GYuQgFtN02NjcVWvnkJ4h3TwvA3 89r0Fcg4kj17IOaxd+8EvULeTz0Z60JmLFGaUXcg6PHpdsGXi6i97D0mH207HYhso3IE yZu3ZRoUk8cin5yMzKPr3eW0OrGQkRlZLyn34bnsuDLcT5xNyPa4t833feFwXbXG7Bj9 YgiwNxaDFBghg/okssoRCZPyMIT7GIQPoAevzSttiECjCxjIh8pHDFn6wIHk4cIWD09b ReiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ip76665p5dLpRCWkpQ/G3JB3M0LxYeJ+OWnRL5SExKc=; b=RrD+4/GVVU68LqLLjQwSuVHg2d/TQDBPcDB6LVE+ICtnE5xsd4mwZS+r70AE4dhtLH UCEqpnRS2+cmtp0MHX73G/VfbRaqzfObCIOJ/zwbuRUWqy50S4vf18JyI5Lihyyq4IvO qbXXJ2VykJv6kPpvLE+6VW88taKDi+Yx6Q3A0O0a4YjKzztx9wffCyly3ZakrFc7NpVH oCt93+dhTe+CEA3i/yhOQC03EY8HfSoaYK9GnIiPTsKM/Xq1KtERNdo5MMAqs+4+uKDo u1Qxn9dJ8YeF2eHINfRIbDe0KOTZcFb62eW80KUJKTqOCPx6OXSFrH/QEvN3a/KldAIW hGvg== X-Gm-Message-State: AMke39nnZfbHewhBbaSz7VNQBQ0J4Vh49x4S3BaHjAO7qH7q5dps0jzKsTPV38VLXCZ7bdVXNs4J0LN2Ry13Ig== X-Received: by 10.55.185.131 with SMTP id j125mr35811535qkf.115.1487213931590; Wed, 15 Feb 2017 18:58:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Wed, 15 Feb 2017 18:58:50 -0800 (PST) In-Reply-To: <90f6c1ab-6c6c-8d5d-e69f-201a902e9174@huitema.net> References: <90f6c1ab-6c6c-8d5d-e69f-201a902e9174@huitema.net> From: Martin Thomson Date: Thu, 16 Feb 2017 13:58:50 +1100 Message-ID: Subject: Re: Alternate header proposal To: Christian Huitema Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 02:58:53 -0000 On 16 February 2017 at 13:29, Christian Huitema wrote: > I am a little bit worried about the proposal to set the packet number size > to 32 bits in "QUIC for now". I know that "4 billion messages in 100 > milliseconds" appears ridiculously large right now, but do you really > believe that we are not going to see 500 Tbps links in the future? Or maybe > 1Tbps link to the Moon, or to Mars? Maybe not in my lifetime, but in yours? > At that point, how do we get the "short form" to use 64 bit numbers? You can stick the extra high bits after the version in the long form. The short form can just use a new type field to indicate that the packet number is gigantic. Of course, this all assumes that you a) have 500 Tbps or higher, and b) that you get reordering over ~4 times the BDP on that link. That latter part is where I think this breaks down some. From nobody Wed Feb 15 19:14:00 2017 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 E8EF5129505; Wed, 15 Feb 2017 19:13:58 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Subject: quic - New Interim Meeting Request X-Test-IDTracker: no X-IETF-IDTracker: 6.43.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148721483894.31486.13470639102388321198.idtracker@ietfa.amsl.com> Date: Wed, 15 Feb 2017 19:13:58 -0800 Archived-At: Cc: mnot@mnot.net, quic@ietf.org, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 03:13:59 -0000 A new interim meeting request has just been submitted by Mark Nottingham. This request requires approval by the Transport Area Area Director The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2017-quic-02 --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Mark Nottingham City: Paris Country: FR Session 1: Date: 2017-06-06 Start Time: 09:30 Europe/Paris Duration: 07:30 Remote Participation Information: Webex and Jabber; register for full details Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-17-06/arrangements.md Session 2: Date: 2017-06-07 Start Time: 09:30 Europe/Paris Duration: 07:30 Remote Participation Information: Webex and Jabber; register for full details Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-17-06/arrangements.md Session 3: Date: 2017-06-08 Start Time: 09:30 Europe/Paris Duration: 07:30 Remote Participation Information: Webex and Jabber; register for full details Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-17-06/arrangements.md --------------------------------------------------------- From nobody Wed Feb 15 23:32:55 2017 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 79B0E129759 for ; Wed, 15 Feb 2017 23:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZUJKUEHB3kbv for ; Wed, 15 Feb 2017 23:32:50 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F79C129447 for ; Wed, 15 Feb 2017 23:32:50 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id v186so59329278wmd.0 for ; Wed, 15 Feb 2017 23:32:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=S+toBEp8tKApprq2vD6MvFF26+lYJXEDEN1XUvPAnJ4=; b=fBJBgjsV05bMALB2x7KIDIIhIhfN8se+wBQa3L9Nb9aun6Kvqvx9wLgfAGbccYDno0 IWcon/tPk18cIDGFxjJKusbQio+UtMqSYknjx1Qay2hb28EkDE9mAqTEgt5v3xPfDMlu pqtlNawaF5oEt5DCN5bm6swCFrl15mUtW7dht5ZA11Ae1eF8ml5MvUZUmapx255W9nHA fLSGb6wXU96ifd7tgzZ/ParH4HZbqPlFJhiuo0B0h8VNdmO9RrsigqTHQbvphZ/cdvnO thxqPQL0xkMcafvrPeBcgdgSn1u3NT/gBA9AzPjy9oII5aMIbdkcBRWBPcbxsP9RrD8+ C/iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=S+toBEp8tKApprq2vD6MvFF26+lYJXEDEN1XUvPAnJ4=; b=RZC+iDstYl8omyyAdykoxU/GCVf3/I3aCCtuMaSWLg38pfrLOvCa0KULd6W0mjVCVQ LcMaDmbpwutlSf0hI1LvEMVYiDwzvVWRPsBLqqEE4okPs0upEE3L7alokJGhdKYkgSTT XtNB1TLmMc2EQM161tqWIhnidCHWUHDrDobKRk5RHJ/e1btlvKxvn/ljAhn9dkkVTtXP LvJDIqx3410S4+IZpK53gCYwvri3sJ0v1rqBsPcbt1sZX3Cr3zj7w75zuas6S7q5zvtt 7wJMKge6hkm8w/N4eALEdPXJsam3oJumS/lEEMAVRrT1bauDWz1BaJG+1UAdg3pV/nsm 323A== X-Gm-Message-State: AMke39mTlX52DcykM4+rU3qXVf56iXSZyKB76qVQcc0fVOy+v337PtIMjhFRZScZHhZoc7kp X-Received: by 10.28.214.137 with SMTP id n131mr970110wmg.120.1487230368532; Wed, 15 Feb 2017 23:32:48 -0800 (PST) Received: from Macintosh-6.local ([2001:720:410:1010:3d94:4860:5fa4:2479]) by smtp.gmail.com with ESMTPSA id 191sm2256401wmo.21.2017.02.15.23.32.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 15 Feb 2017 23:32:47 -0800 (PST) Subject: Re: Alternate header proposal To: quic@ietf.org References: From: marcelo bagnulo braun Message-ID: Date: Thu, 16 Feb 2017 08:32:47 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 07:32:53 -0000 El 16/02/17 a las 02:39, Jana Iyengar escribió: > > > You are assuming that connection ID is gone in both directions, which > isn't true. In the common case, which is what Google's deployment > does, you allow NAT rebinding at the client by having the client send > connection ID on packets. If they're absent in the server->client > packets, that disallows IP/port change at the server, which is > entirely fine, since the server's not behind a NAT. > > (If you haven't guessed already, connection ID is the single feature > of this protocol that I am most conflicted about. I can see so many > advantages and so many disadvantages. They are all potentially huge > and that means that I don't know how to make the trade-offs sensibly.) > > > Do you have more disadvantages besides the potential of increased > link-ability? I guess one case when the connection ID could be useful is the case where the server is located in a multihomed network and it is served by two or more NATs I understand that as of today, when there is a failure, proprietary protocols are used to synch the state between the NATs in order to allow the other NAT to act as backup when the initial NAT (or the path through that NAT) fails. Having the connection ID would allow a much cleaner/cheaper solution, since the IP of the server can change and the connection survive. I guess you make a similar argument about VM migration. Having the connection ID in all packets would allow to migrate the VM without keeping the address (making unnecessary all the mechanisms to keep the address unchanged in VM migration). And there is the case of multipath, that some form of connection ID will be needed, at least in the first packet of the new subflow. However, I am unconvinced any of these are strong enough to make the connection ID mandatory. IMHO it is enough to make it optional (with as recommendation for clients to use it in all packets and leave it open for servers). Regards, marcelo From nobody Thu Feb 16 00:00:15 2017 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 ED6CA129480 for ; Thu, 16 Feb 2017 00:00:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIMHP4vvJh06 for ; Thu, 16 Feb 2017 00:00:07 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 EEECD129490 for ; Thu, 16 Feb 2017 00:00:06 -0800 (PST) X-AuditID: c1b4fb25-93e1698000001738-87-58a55c042f1f Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id B2.5C.05944.30C55A85; Thu, 16 Feb 2017 09:00:04 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.69) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 16 Feb 2017 08:59:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6ZcUCD9fZj3eZkvD44qAIunEx3jDFAw8D0b148rHTqY=; b=WKfAxjcleIlbqHkF04BHLWSARioO446I7XJe2L0IJTCGdhAKMfZ/sea3x85AoQvpFUgirm0lvaHpdTrCvLCZ0saAJdGhh7Q2pKIt/r2OZYuxrlSqI3tI8dMlhXbtV1H8VzDXfkE8KOKcPDFe7gmVR2nw/XKyudvyb4ipP5olzZA= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Thu, 16 Feb 2017 07:59:31 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0919.011; Thu, 16 Feb 2017 07:59:28 +0000 From: Ingemar Johansson S To: Jana Iyengar , Martin Duke Subject: RE: Alternate header proposal Thread-Topic: Alternate header proposal Thread-Index: AQHSh/QBP2cP6Up0iUGaMZN1RFBlK6FrQKlQ Date: Thu, 16 Feb 2017 07:59:27 +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: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.85] x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 7:XcrHi0Qja1NQQ0jvRhH3DckzyyfAGwmQ5mIQtiw5u6gKp56ZdZ7+/LY3i2MwgOf0/q7Qtwj2biet/NCQYPH9Ac4V2Uufaa28wvAsSD+Uccbj/IdsNk3yR7uME5NNpbq2P6PxkAVtens9rFCmrFkjshfUO4R9QsSJhhRIdiSkgL2Bh9yO4t/JwUkL+/R59FLDx1vTRyn4Plx79Ht0czVdrc0RilAciIdKsTmNtYHTSNTkNOsU9NAIe2cibwuhgl1cqOoF9pGYmgzUPWf2isFiae4nkBzOsTEotEJbZlbx2LbJayR5ycAM2NsG72M5AVup+uAjpkEoY9DrpFl2qpsvoQ== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(7916002)(39450400003)(189002)(24454002)(199003)(377454003)(229853002)(50986999)(76176999)(9326002)(7116003)(101416001)(54356999)(5660300001)(122556002)(74316002)(2950100002)(19609705001)(7736002)(105586002)(106356001)(33656002)(68736007)(86362001)(7696004)(93886004)(561944003)(106116001)(3280700002)(790700001)(77096006)(6506006)(8936002)(81156014)(53936002)(8676002)(4326007)(6246003)(25786008)(6306002)(81166006)(55016002)(2906002)(389900002)(92566002)(3846002)(6116002)(9686003)(54906002)(236005)(99286003)(107886003)(189998001)(3480700004)(54896002)(6436002)(38730400002)(102836003)(66066001)(97736004)(3660700001)(2900100001)(39060400002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: c97689af-f7c1-4934-a33b-08d45641bb59 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB346; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6041248)(20161123558025)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 0220D4B98D received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB3480A397289DE7E2AD2C7B0C25A0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Feb 2017 07:59:27.8946 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0hTYRjHec85O+e4GrytlY+WXSbaBdMyi32IsEIYdCEJbIhUax7cak3Z mWZCZJCks7VZljkqzVvNrtrVkVFjaTHJD+WlyxxmgZGJtNQiuri9BX77Pc/z/7//5315eVre LYnmDSaLYDZpjUpWylRr7qetYLIaNSs/f1yr+jHQJlGdenqJUZV8bGZVVUPDrKq36zdS3bpa yahO1M5I5dRtTj+nrm3NVzc0/KDUE30tEnXH2Di7XZIpXZctGA0Fgjlp/R6pvq7mLZPnNRX+ 6p5Exci734oieMAp4LjazFmRlJfjGwjq7aUMKZ4hGG2v40IqBttoONFYRAZnKWivGGRJ0YHg WOc9JqRi8TpweSZRiBVYDU8mSumQiMYXKXjr9dGhwWwcD+3uOgkRLYGOrl6OcDI02R5TJC4O fFZHmGU4E76UB2mS9lgCPS5v2BCB06HqeDCcjHAMBCYHwkzjSHjzoYYit8PQ8LCbJjwHPg39 lhC9Dr6+tk0xP9VfBIN3t4XOB1xOg7vUTpHCx0KP/woi5q3QM3CLI7wFfvZd44jZAP0nWdLe DKOO0wzxnqPA1VT2zzsf+t2+8HJyLMDl6yWIvEQ0+F+VIQda5py2N+FcsFXfZp3hB5gFz6s/ MM6pOBovg5vuJCJZDJXlgxzhpVBy/gI3vV+LuGY0RxTEvQdyklcnCmaDThRzTYkmwdKKpr7Z kzs/4x6glyMbPAjzSDlTNmZs0Mgl2gLx0AEPAp5WKmTvdzRq5LJs7aEiwZy725xvFEQPmscz ykjZWldgpxznaC3CfkHIE8z/pxQfEV2M9kSNaaoWJAT1cxVsS5/1xXzZ+NH0wrRK3btWb02n 3WIO3NXXvovtl43/eVR/ZmmhZzBlX0s88ndpUydGRui2b60ZWWss9WlHAgllD79v0gwHd1Uv 3FtRnCGqqcP2LbExlkTf+mzZL8vzimJxo3jQv/FCzKLczkJdlGanojfJoWREvXbVctosav8C AGvNy2IDAAA= Archived-At: Cc: Ian Swett , Ingemar Johansson S , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , marcelo bagnulo braun , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 08:00:14 -0000 --_000_DB4PR07MB3480A397289DE7E2AD2C7B0C25A0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KSSBiZWxpZXZlIHRoYXQgaXQgc2hvdWxkIGJlIHN1ZmZpY2llbnQgdG8gaGF2ZSB0aGUg RUNOIGZlZWRiYWNrIGluIHRoZSBBQ0sgZnJhbWVzLiBUaGVyZSBhcmUgdGhyZWUgYWx0ZXJuYXRp dmVzIGluIHRoZSBkcmFmdCwgaG93ZXZlciBJIGRvbuKAmXQgc2VlIHRoZSBhY3R1YWwgZmVlZGJh Y2sgYXMgYSBidXJuaW5nIGlzc3VlLg0KVGhlIG1vcmUgdHJpY2t5IHBhcnQgaXMgaG93IHRvIHNh ZmVseSBlbmFibGUgRUNOIGdpdmVuIHRoYXQgdGhlcmUgYXJlIHBvc3NpYmxlIGlzc3VlcyBib3Ro IGFzIHJlZ2FyZHMgdG8gYWNjZXNzIHRvIHRoZSBFQ04gYml0cyBpbiB0aGUgSVAgaGVhZGVyIGFu ZCBpbiB0aGUgc3VwcG9ydCBpbiB0aGUgbmV0d29yay4NCk1hcmNlbG8gc3VnZ2VzdGVkIHRoYXQg YSBkZWRpY2F0ZWQgRUNOIGZyYW1lIGlzIGV4Y2hhbmdlZCBieSB0aGUgcGVlcnMgYWZ0ZXIgdGhl IGNvbm5lY3Rpb24gc2V0dXAuIEkgaG9wZSB0byB1cGRhdGUgdGhlIEVDTiBkcmFmdCBzb29uIGJh c2VkIG9uIHRoZSBjb21tZW50cyB0aGF0IEkgcmVjZWl2ZWQuDQoNClF1ZXN0aW9uOiBJcyBDV1Ig bmVjZXNzYXJ5IHdpdGggUVVJQywgSSBhbHdheXMgdGhvdWdodCB0aGF0IGl0IGlzIHNvbWV0aGlu ZyB0aGF0IGlzIGEgc3BlY2lhbCB0aGluZyBmb3IgVENQIHdpdGggaXRzIGxpbWl0ZWQgaGVhZGVy IHNwYWNlLg0KT3IgaXMgQ1dSIHVzZWQgZm9yIG90aGVyIG1lYW5zIHRoYW4gdG8ganVzdCBjbGVh ciB0aGUgRUNFIGZsYWcgZm9yIGNsYXNzaWMgRUNOID8NCg0KL0luZ2VtYXINCg0KRnJvbTogSmFu YSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21dDQpTZW50OiBkZW4gMTYgZmVicnVhcmkg MjAxNyAwMDo0Nw0KVG86IE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT4NCkNj OiBNaXJqYSBLw7xobGV3aW5kIDxtaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPjsgSWFu IFN3ZXR0IDxpYW5zd2V0dEBnb29nbGUuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3Jn PjsgTWFydGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT4NClN1YmplY3Q6IFJl OiBBbHRlcm5hdGUgaGVhZGVyIHByb3Bvc2FsDQoNCk9uIFdlZCwgRmViIDE1LCAyMDE3IGF0IDM6 MjYgUE0sIE1hcnRpbiBEdWtlIDxtYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbTxtYWlsdG86bWFydGlu LmguZHVrZUBnbWFpbC5jb20+PiB3cm90ZToNCg0KV2h5IGRvIHlvdSBuZWVkIEVDRS9DV1IgYml0 cyBpbiB0aGUgaGVhZGVyPyBJIGhhdmVuJ3QgY2FyZWZ1bGx5IGNvbnNpZGVyZWQgeWV0IGhvdyB0 byBkbyB0aGlzIGluIFFVSUMgKGFuZCBJIGhhdmVuJ3QgY2FyZWZ1bGx5IHJlYWQgSW5nZW1hcidz IGRyYWZ0IHlldCksIGJ1dCB0aG9zZSB3b3VsZC9zaG91bGQgYmUgaW4gZXhwbGljaXQgZnJhbWVz IEkgd291bGQgaW1hZ2luZS4NCg0KVGhlIGRyYWZ0IHB1dHMgdGhlbSBpbiB0aGUgQUNLIGZyYW1l LiBUaGVyZSBpcyBhIGNhc2UsIEkgdGhpbmssIHRvIGhhdmUgdGhlbSBpbiB0aGUgcHVibGljIGhl YWRlciwgdGhvdWdoIEknbSBub3QgY29udmluY2VkIG9mIGl0IGF0IGFsbC4gVGhlIHBvaW50IEkg YW0gdHJ5aW5nIHRvIG1ha2UgaXMgdGhhdCB0aGVyZSBhcmUgdXNlcyBmb3IgdGhlc2UgYml0cyB0 aGF0IGFyZSBub3QgcmVsYXRlZCB0byB0aGUgaGVhZGVyIGxheW91dCwgYW5kIGluIHRoZSBleHRy ZW1lIGNhc2UgdGhpcyB3b3VsZCBiZSBhcyBtYW55IGFzIDUgKEkgYW0gcGVyc29uYWxseSBjb252 aW5jZWQgd2UgbmVlZCBvbmx5IDIpLg0KDQpJIHVuZGVyc3RhbmQgYW5kIGFncmVlIHdpdGggdGhl IHBvaW50IHRoYXQgd2UgbWF5IGhhdmUgdGhpbmdzIHRoYXQgbmVlZCB0byBiZSBwdXQgaW4gdGhl IHBhY2tldCBoZWFkZXIgKEZXSVcsIGFuZCB3ZSBjYW4gZGlzY3VzcyB0aGlzIHNlcGFyYXRlbHks IGJ1dCBJJ20gaGFyZC1wcmVzc2VkIHRvIHVuZGVyc3RhbmQgd2h5IEVDTiBiaXRzIGFyZSBuZWVk ZWQgaW4gdGhlIHBhY2tldCBoZWFkZXIgaW5zdGVhZCBvZiBpbiB0aGUgYWNrIGZyYW1lLikgRWl0 aGVyIHdheXMgSSB0aGluayB3ZSdsbCBoYXZlIHRvIGRpc2N1c3MgdGhpcyBvbiBhIGNhc2UtYnkt Y2FzZSBiYXNpcywgYnV0IGluIHRoZSBtZWFud2hpbGUsIHRoaXMgcHJvcG9zYWwgZ2l2ZXMgeW91 IGFub3RoZXIgZGVncmVlIG9mIGZyZWVkb20gLS0gY29kZXBvaW50IHNwYWNlLg0KDQpUaGUgY3Vy cmVudCBwcm9wb3NhbCBvbmx5IGFkZHJlc3NlcyB0aGluZ3Mgd2UgaGF2ZSByZWFzb25hYmxlIGFn cmVlbWVudCBvbiBpbiB0aGUgd2csIGFuZCBub3Qgb24gdGhpbmdzIHRoYXQgYXJlIHlldCB1bmRl ciBkaXNjdXNzaW9uLiBObyBtYXR0ZXIgd2hhdCBoZWFkZXIgZm9ybWF0IHdlIHVzZSwgd2UncmUg Z29pbmcgdG8gaGF2ZSB0byByZXZpc2l0IGl0IGlmIHRoZXJlIGFyZSBpc3N1ZXMgdGhhdCB0b3Vj aCB0aGUgaGVhZGVyIGluIHRoZSBmdXR1cmUsIGFuZCB0byB0aGF0IGV4dGVudCwgdGhpcyBoZWFk ZXIgZm9ybWF0IHdpbGwgaGF2ZSB0byByZW1haW4gbWFsbGVhYmxlLiBJIHdvdWxkbid0IHNheSB3 ZSd2ZSBkb25lIGF3YXkgd2l0aCBleHBsaWNpdCBiaXRzLCBidXQgSSdkIHN1cmUgbGlrZSB0byB0 cnkgYW5kIGF2b2lkIHRoZW0gaW4gZmF2b3Igb2YgY29kZXBvaW50cyBpZiB3ZSBjYW4sIHNpbmNl IGl0IHNlZW1zIGxpa2UgYSBiaWcgZW5vdWdoIHNwYWNlLg0K --_000_DB4PR07MB3480A397289DE7E2AD2C7B0C25A0DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uZ21haWwtDQoJe21z by1zdHlsZS1uYW1lOmdtYWlsLTt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0 IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkhpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkkgYmVsaWV2ZSB0aGF0IGl0IHNob3Vs ZCBiZSBzdWZmaWNpZW50IHRvIGhhdmUgdGhlIEVDTiBmZWVkYmFjayBpbiB0aGUgQUNLIGZyYW1l cy4gVGhlcmUgYXJlIHRocmVlIGFsdGVybmF0aXZlcyBpbiB0aGUgZHJhZnQsIGhvd2V2ZXIgSSBk b27igJl0IHNlZSB0aGUgYWN0dWFsIGZlZWRiYWNrIGFzIGEgYnVybmluZw0KIGlzc3VlLiA8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PlRoZSBtb3JlIHRyaWNreSBwYXJ0IGlzIGhvdyB0byBzYWZlbHkgZW5hYmxlIEVDTiBnaXZlbiB0 aGF0IHRoZXJlIGFyZSBwb3NzaWJsZSBpc3N1ZXMgYm90aCBhcyByZWdhcmRzIHRvIGFjY2VzcyB0 byB0aGUgRUNOIGJpdHMgaW4gdGhlIElQIGhlYWRlciBhbmQgaW4gdGhlIHN1cHBvcnQgaW4gdGhl IG5ldHdvcmsuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj5NYXJjZWxvIHN1Z2dlc3RlZCB0aGF0IGEgZGVkaWNhdGVkIEVDTiBmcmFt ZSBpcyBleGNoYW5nZWQgYnkgdGhlIHBlZXJzIGFmdGVyIHRoZSBjb25uZWN0aW9uIHNldHVwLiBJ IGhvcGUgdG8gdXBkYXRlIHRoZSBFQ04gZHJhZnQgc29vbiBiYXNlZCBvbiB0aGUgY29tbWVudHMg dGhhdCBJIHJlY2VpdmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5RdWVzdGlvbjogSXMgQ1dSIG5lY2Vzc2Fy eSB3aXRoIFFVSUMsIEkgYWx3YXlzIHRob3VnaHQgdGhhdCBpdCBpcyBzb21ldGhpbmcgdGhhdCBp cyBhIHNwZWNpYWwgdGhpbmcgZm9yIFRDUCB3aXRoIGl0cyBsaW1pdGVkIGhlYWRlciBzcGFjZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPk9yIGlzIENXUiB1c2VkIGZvciBvdGhlciBtZWFucyB0aGFuIHRvIGp1c3QgY2xlYXIgdGhl IEVDRSBmbGFnIGZvciBjbGFzc2ljIEVDTiA/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPi9JbmdlbWFyPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IEphbmEgSXll bmdhciBbbWFpbHRvOmpyaUBnb29nbGUuY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IGRlbiAxNiBm ZWJydWFyaSAyMDE3IDAwOjQ3PGJyPg0KPGI+VG86PC9iPiBNYXJ0aW4gRHVrZSAmbHQ7bWFydGlu LmguZHVrZUBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaXJqYSBLw7xobGV3aW5kICZs dDttaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoJmd0OzsgSWFuIFN3ZXR0ICZsdDtpYW5z d2V0dEBnb29nbGUuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYub3JnJmd0Ozsg TWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IEFsdGVybmF0ZSBoZWFkZXIgcHJvcG9zYWw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBX ZWQsIEZlYiAxNSwgMjAxNyBhdCAzOjI2IFBNLCBNYXJ0aW4gRHVrZSAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLmguZHVr ZUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8 ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowY20iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2h5IGRvIHlvdSBuZWVkIEVDRS9DV1IgYml0cyBp biB0aGUgaGVhZGVyPyBJIGhhdmVuJ3QgY2FyZWZ1bGx5IGNvbnNpZGVyZWQgeWV0IGhvdyB0byBk byB0aGlzIGluIFFVSUMgKGFuZCBJIGhhdmVuJ3QgY2FyZWZ1bGx5IHJlYWQgSW5nZW1hcidzIGRy YWZ0IHlldCksIGJ1dCB0aG9zZSB3b3VsZC9zaG91bGQgYmUgaW4gZXhwbGljaXQgZnJhbWVzIEkg d291bGQgaW1hZ2luZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGRy YWZ0IHB1dHMgdGhlbSBpbiB0aGUgQUNLIGZyYW1lLiBUaGVyZSBpcyBhIGNhc2UsIEkgdGhpbmss IHRvIGhhdmUgdGhlbSBpbiB0aGUgcHVibGljIGhlYWRlciwgdGhvdWdoIEknbSBub3QgY29udmlu Y2VkIG9mIGl0IGF0IGFsbC4gVGhlIHBvaW50IEkgYW0gdHJ5aW5nIHRvIG1ha2UgaXMgdGhhdCB0 aGVyZSBhcmUgdXNlcyBmb3IgdGhlc2UgYml0cyB0aGF0IGFyZSBub3QgcmVsYXRlZCB0byB0aGUg aGVhZGVyDQogbGF5b3V0LCBhbmQgaW4gdGhlIGV4dHJlbWUgY2FzZSB0aGlzIHdvdWxkIGJlIGFz IG1hbnkgYXMgNSAoSSBhbSBwZXJzb25hbGx5IGNvbnZpbmNlZCB3ZSBuZWVkIG9ubHkgMikuJm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHVuZGVyc3RhbmQgYW5k IGFncmVlIHdpdGggdGhlIHBvaW50IHRoYXQgd2UgbWF5IGhhdmUgdGhpbmdzIHRoYXQgbmVlZCB0 byBiZSBwdXQgaW4gdGhlIHBhY2tldCBoZWFkZXIgKEZXSVcsIGFuZCB3ZSBjYW4gZGlzY3VzcyB0 aGlzIHNlcGFyYXRlbHksIGJ1dCBJJ20gaGFyZC1wcmVzc2VkIHRvIHVuZGVyc3RhbmQgd2h5IEVD TiBiaXRzIGFyZSBuZWVkZWQgaW4gdGhlIHBhY2tldCBoZWFkZXIgaW5zdGVhZCBvZg0KIGluIHRo ZSBhY2sgZnJhbWUuKSBFaXRoZXIgd2F5cyBJIHRoaW5rIHdlJ2xsIGhhdmUgdG8gZGlzY3VzcyB0 aGlzIG9uIGEgY2FzZS1ieS1jYXNlIGJhc2lzLCBidXQgaW4gdGhlIG1lYW53aGlsZSwgdGhpcyBw cm9wb3NhbCBnaXZlcyB5b3UgYW5vdGhlciBkZWdyZWUgb2YgZnJlZWRvbSAtLSBjb2RlcG9pbnQg c3BhY2UuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBjdXJyZW50IHByb3Bvc2FsIG9ubHkgYWRkcmVzc2VzIHRoaW5ncyB3ZSBo YXZlIHJlYXNvbmFibGUgYWdyZWVtZW50IG9uIGluIHRoZSB3ZywgYW5kIG5vdCBvbiB0aGluZ3Mg dGhhdCBhcmUgeWV0IHVuZGVyIGRpc2N1c3Npb24uIE5vIG1hdHRlciB3aGF0IGhlYWRlciBmb3Jt YXQgd2UgdXNlLCB3ZSdyZSBnb2luZyB0byBoYXZlIHRvIHJldmlzaXQgaXQgaWYgdGhlcmUgYXJl IGlzc3VlcyB0aGF0IHRvdWNoDQogdGhlIGhlYWRlciBpbiB0aGUgZnV0dXJlLCBhbmQgdG8gdGhh dCBleHRlbnQsIHRoaXMgaGVhZGVyIGZvcm1hdCB3aWxsIGhhdmUgdG8gcmVtYWluIG1hbGxlYWJs ZS4gSSB3b3VsZG4ndCBzYXkgd2UndmUgZG9uZSBhd2F5IHdpdGggZXhwbGljaXQgYml0cywgYnV0 IEknZCBzdXJlIGxpa2UgdG8gdHJ5IGFuZCBhdm9pZCB0aGVtIGluIGZhdm9yIG9mIGNvZGVwb2lu dHMgaWYgd2UgY2FuLCBzaW5jZSBpdCBzZWVtcyBsaWtlIGEgYmlnIGVub3VnaCBzcGFjZS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_DB4PR07MB3480A397289DE7E2AD2C7B0C25A0DB4PR07MB348eurprd_-- From nobody Thu Feb 16 00:13:57 2017 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 37D2A1299A0 for ; Thu, 16 Feb 2017 00:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O97OuXjIrIqJ for ; Thu, 16 Feb 2017 00:13:53 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFF5129480 for ; Thu, 16 Feb 2017 00:13:53 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id t18so1709791wmt.0 for ; Thu, 16 Feb 2017 00:13:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=MUYamL+y96lasZ2egB+LklSr4PnNsn9cmx+fPNDF1Vw=; b=lxSZmlgwkN6n5oi9ygN6xtzmU6ZKRKjnexX/EksBwjj7C9H3dR5b8zozxr2r6xKUs/ gD+9zdZN1fC0iyVLb2EjtrRjkOHw8qtZAEf0UucjTtiUUzHXKvfQwg38pRS6drXXy9SA wLOf3utf11LUL1fUw9yiUuY/wWwbOfIKniNgnOY9jPT1H1xNPtANyXR0ZnpoK81VVsXE 52vkO2ADTxROW5n83d+B2/OID7r41c98NpGieRIswr9dFNYeHhvMK3EGIr6vGU9kJzSC Leo6qPNyVG2+G3SR1k64RLj55pQHnqNSxmTjeJHxofNEDdPFI0o24w+wKILTmEDjC+Nc b6cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=MUYamL+y96lasZ2egB+LklSr4PnNsn9cmx+fPNDF1Vw=; b=aWoMVLTaB9gPhfAUidk9NRMhgXR4u4KOdSi1B2mg9UgKQqjOt8Ffv6GWF49a8eYTHz nhvNTpqsx6527h1UzGZVJYcErjF/zKy8aLO7SPIicqpkgKARPtTQ3gi2rnXiyVJ/NA9b Al4W2cD1ehewNi1H82dPH6dB2c+l7L9R9nYSDrSRpdwkOmZZuKTt9ZMV3T3R23JwBpVD sMeYWrb9unThny3CXaiPEH8A2lLwIdehK2gMEM9BkNpIb/KuKesWnnQ0uzwVWepwTwbb FqFFEP8e0WeCStgao6GRq+iedaAPGGPMLYZz/b5kRqKFjdhESdNiMJgpSK61v0BmSsXo IrIg== X-Gm-Message-State: AMke39mradS5wPaufE43OJqcY8I8UdkSJhMjwxbqDKXlID2pGth4tzJZda0nLgnXVmEyHIMV X-Received: by 10.28.167.68 with SMTP id q65mr1266960wme.126.1487232831634; Thu, 16 Feb 2017 00:13:51 -0800 (PST) Received: from Macintosh-6.local ([2001:720:410:1010:3d94:4860:5fa4:2479]) by smtp.gmail.com with ESMTPSA id 94sm7902213wrl.50.2017.02.16.00.13.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Feb 2017 00:13:50 -0800 (PST) Subject: Re: Alternate header proposal To: Ingemar Johansson S , Jana Iyengar , Martin Duke References: From: marcelo bagnulo braun Message-ID: <32c87057-cae5-fc5f-9a70-9d5fb9288a2d@it.uc3m.es> Date: Thu, 16 Feb 2017 09:13:50 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: Martin Thomson , Ian Swett , IETF QUIC WG , =?UTF-8?Q?Mirja_K=c3=bchlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 08:13:56 -0000 El 16/02/17 a las 08:59, Ingemar Johansson S escribió: > > Hi > > I believe that it should be sufficient to have the ECN feedback in the > ACK frames. There are three alternatives in the draft, however I don’t > see the actual feedback as a burning issue. > > The more tricky part is how to safely enable ECN given that there are > possible issues both as regards to access to the ECN bits in the IP > header and in the support in the network. > > Marcelo suggested that a dedicated ECN frame is exchanged by the peers > after the connection setup. I hope to update the ECN draft soon based > on the comments that I received. > > Question: Is CWR necessary with QUIC, I always thought that it is > something that is a special thing for TCP with its limited header space. > > Or is CWR used for other means than to just clear the ECE flag for > classic ECN ? > I guess if the ECE information is sent reliably in a ECN quic frame, we dont need CWR, since the ACK for that frame would fullfill the same purpose? Regards, marcelo > /Ingemar > > *From:*Jana Iyengar [mailto:jri@google.com] > *Sent:* den 16 februari 2017 00:47 > *To:* Martin Duke > *Cc:* Mirja Kühlewind ; Ian Swett > ; IETF QUIC WG ; Martin Thomson > > *Subject:* Re: Alternate header proposal > > On Wed, Feb 15, 2017 at 3:26 PM, Martin Duke > wrote: > > Why do you need ECE/CWR bits in the header? I haven't > carefully considered yet how to do this in QUIC (and I haven't > carefully read Ingemar's draft yet), but those would/should be > in explicit frames I would imagine. > > The draft puts them in the ACK frame. There is a case, I think, to > have them in the public header, though I'm not convinced of it at > all. The point I am trying to make is that there are uses for > these bits that are not related to the header layout, and in the > extreme case this would be as many as 5 (I am personally convinced > we need only 2). > > I understand and agree with the point that we may have things that > need to be put in the packet header (FWIW, and we can discuss this > separately, but I'm hard-pressed to understand why ECN bits are needed > in the packet header instead of in the ack frame.) Either ways I think > we'll have to discuss this on a case-by-case basis, but in the > meanwhile, this proposal gives you another degree of freedom -- > codepoint space. > > The current proposal only addresses things we have reasonable > agreement on in the wg, and not on things that are yet under > discussion. No matter what header format we use, we're going to have > to revisit it if there are issues that touch the header in the future, > and to that extent, this header format will have to remain malleable. > I wouldn't say we've done away with explicit bits, but I'd sure like > to try and avoid them in favor of codepoints if we can, since it seems > like a big enough space. > From nobody Thu Feb 16 04:58:25 2017 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 8995A129578 for ; Thu, 16 Feb 2017 04:58:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SXyT_yDb--sc for ; Thu, 16 Feb 2017 04:58:22 -0800 (PST) Received: from pianosa.iway.ch (pianosa.iway.ch [IPv6:2001:8e0:40:325::37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A7F1129495 for ; Thu, 16 Feb 2017 04:58:22 -0800 (PST) Received: from pianosa.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4B59FE2C01; Thu, 16 Feb 2017 13:58:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/2244.28583); Thu, 16 Feb 2017 13:58:20 +0100 (CET) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pianosa.iway.ch (Postfix) with ESMTPS; Thu, 16 Feb 2017 13:58:20 +0100 (CET) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 33E77340332; Thu, 16 Feb 2017 13:58:20 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/19061.25953); Thu, 16 Feb 2017 13:58:20 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 16 Feb 2017 13:58:20 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 8766316; Thu, 16 Feb 2017 13:58:20 +0100 Subject: Re: Alternate header proposal Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C953B5F8-D4CC-4489-8EF3-556A2D61F3DD"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Thu, 16 Feb 2017 13:58:19 +0100 Message-Id: <1358D674-9513-4451-AE6C-3B82C84057A1@trammell.ch> References: To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 12:58:24 -0000 --Apple-Mail=_C953B5F8-D4CC-4489-8EF3-556A2D61F3DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, all.. (and hi Jana, I like the general approach) trying to catch up on this thread, falling back to jump-in-randomly: > On 16 Feb 2017, at 02:41, Martin Thomson = wrote: >=20 > On 16 February 2017 at 12:39, Jana Iyengar wrote: >> Do you have more disadvantages besides the potential of increased >> link-ability? >=20 > Bloat. We just took great paints to trim a couple of octets from the > packet number, saving a whole 2 octets in the best case. But > connection ID is 8. I remain unconvinced of the complexity/space tradeoff for the 8- and = 16-bit packet number cases. Your earlier point on handling public resets = -- > Ahh, that's fine. In the case that packet number is short, I guess > the public reset will be sending the first 2 or 3 octets of the > payload. That's something for implementations to remember. We'll > need special text on that. I think that it's relatively easy to > implement that way, but it's not something that will be obvious. -- is an excellent illustration of the point here. If we're clawing 16 = to 24 bits back only to add 64 bits on Connection ID... the value prop = goes from "questionable" to "uncompelling"... And jumping back to another message: > (If you haven't guessed already, connection ID is the single feature > of this protocol that I am most conflicted about. I can see so many > advantages and so many disadvantages. They are all potentially huge > and that means that I don't know how to make the trade-offs sensibly.) This might be slightly cowardly, but I share your conflict. Perhaps the = presence/absence/utility of connection ID shouldn't be a property of = QUIC's design, then, but rather a property of the applications using = QUIC. Indeed, this isn't even a thing that should always be left up to = the app developer -- there are certainly networks I would be far less = interested in increasing my trackability on than others, independent of = application. Recommend two or three points in the space ("always" for load balancing = and rebinding, "sometimes" for load balancing and limited rebinding, = "never" for reducing traceability) and make supporting them all MTI. Cheers, Brian --Apple-Mail=_C953B5F8-D4CC-4489-8EF3-556A2D61F3DD 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 iQIcBAEBCgAGBQJYpaHrAAoJEIoSt78L6kajtcAQAK0dMesD1Rv+y4Guyk9Zy6Tr jCcTmQNn1QtVUMDBYjyfKeX1P3nsd3LH1V00szU5qkGBsnVNpPfTPkS2RJb+KG7f ExIdaXknCUEgcja6vZ4CxofXuwjg4db5+llBbQJ+8fAvPoOcs7rhq76ZEnDLWdcc /0ab4UAcYEMaUnyH7FXM5GYgqQIsZ4lhkPcD5nFB/nqC6Nq8FrSh+H8LPobPRKTA KsBn/9EL/wpfTC/Onhd/AjwqUy70W2SH8LslKEUznoyCsS91i1aznfJteRsobAax 6moaSWaZcKNPr+LqM+3DEjmKlDVK9kum2gBv0wyRZ0BLxxwRAVwNqm0Co8sMv6PX l+zGPy5S0jZ44jSVbe9VaJQHr6D3otOqMWLEYhdZhsgaBqzzB9MMegM6afuWvl3v Q/bYTVpfzAz2miJZPK8/c/bfA4ZBnl7Rl1MSb2qS54tIL4t31umLbQZ2pCrjWG16 2JdMGRfFlbW0/BiR6MsIPdHUgHBduJwLKD7HUFPh6kuYSbUV31iw0XrLHsuni3jV v4XRfs48eVoqofFn4CbxjlXY+0Knr+VZuqLfGBCiFjg9fQOYBOmqAFSEuic7Pyrx uQr6g0Lj3OcS/pTvUih1m5ZOMuHrp7iMPe5R68uuEgFXn88gAKr0Qf+WgMc98Zgd nbiHWj72lXyDl6MRCQ6z =JcM1 -----END PGP SIGNATURE----- --Apple-Mail=_C953B5F8-D4CC-4489-8EF3-556A2D61F3DD-- From nobody Thu Feb 16 05:31:53 2017 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 5923D129D09 for ; Thu, 16 Feb 2017 05:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 KkMaFIryFhzZ for ; Thu, 16 Feb 2017 05:31:41 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77B2D129D05 for ; Thu, 16 Feb 2017 05:31:41 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vPHB35JrwzMqh8; Thu, 16 Feb 2017 14:31:39 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bjJG_KVQ9r2I; Thu, 16 Feb 2017 14:31:38 +0100 (CET) X-MtScore: NO score=0 Received: from [10.2.118.92] (public-docking-etx-1626.ethz.ch [10.2.118.92]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 16 Feb 2017 14:31:38 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Alternate header proposal From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 16 Feb 2017 14:31:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Ingemar Johansson S X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Ian Swett , marcelo bagnulo braun , Jana Iyengar , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:31:43 -0000 > Am 16.02.2017 um 08:59 schrieb Ingemar Johansson S = : >=20 > Question: Is CWR necessary with QUIC, I always thought that it is = something that is a special thing for TCP with its limited header space. > Or is CWR used for other means than to just clear the ECE flag for = classic ECN ? ECE and CWR are both TCP-specifc. For quic you could also provide = feedback in the form of counters for ECT1/ECT1/CE (similar to RTCP)...= From nobody Thu Feb 16 05:33:47 2017 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 2E446129A3A for ; Thu, 16 Feb 2017 05:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 Ms_CgWzoLYTp for ; Thu, 16 Feb 2017 05:33:44 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49ADA129602 for ; Thu, 16 Feb 2017 05:33:44 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vPHDR0kyDzMqhD; Thu, 16 Feb 2017 14:33:43 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXxKo_bsP4cf; Thu, 16 Feb 2017 14:33:42 +0100 (CET) X-MtScore: NO score=0 Received: from [10.2.118.92] (public-docking-etx-1626.ethz.ch [10.2.118.92]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 16 Feb 2017 14:33:42 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Alternate header proposal From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Thu, 16 Feb 2017 14:33:50 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <834C33C2-FC93-44DF-A9FC-C6E4380BA887@tik.ee.ethz.ch> References: To: Jana Iyengar X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 13:33:45 -0000 Hi, > Am 16.02.2017 um 02:55 schrieb Jana Iyengar : >=20 > On Wed, Feb 15, 2017 at 5:41 PM, Martin Thomson = wrote: > On 16 February 2017 at 12:39, Jana Iyengar wrote: > > Do you have more disadvantages besides the potential of increased > > link-ability? >=20 > Bloat. We just took great paints to trim a couple of octets from the > packet number, saving a whole 2 octets in the best case. But > connection ID is 8. >=20 > It's optional and commonly not needed in the server->client direction, = which makes it avoidable it in the commonly bandwidth-constrained = direction. It's what Chrome negotiates currently: it tells the server = that it doesn't need connection ID on incoming packets, but it sends = them on outgoing packets. >=20 How do you know if it=E2=80=99s needed or not? Often a client might not = know if it is behind a NAT or not. Also there might be other stateful = middleboxes that could utilize the connection id (if the 5-tuple = changes) or otherwise might break the connection. Mirja From nobody Thu Feb 16 06:14:10 2017 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 BC5FF129D01 for ; Thu, 16 Feb 2017 06:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 GvirBONNOS_R for ; Thu, 16 Feb 2017 06:14:05 -0800 (PST) Received: from pianosa.iway.ch (pianosa.iway.ch [IPv6:2001:8e0:40:325::37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087361295F2 for ; Thu, 16 Feb 2017 06:14:05 -0800 (PST) Received: from pianosa.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4F7A1E2C6C; Thu, 16 Feb 2017 15:14:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/2244.3303); Thu, 16 Feb 2017 15:14:03 +0100 (CET) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pianosa.iway.ch (Postfix) with ESMTPS; Thu, 16 Feb 2017 15:14:03 +0100 (CET) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3A3C0340332; Thu, 16 Feb 2017 15:14:03 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/19061.3605); Thu, 16 Feb 2017 15:14:02 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 16 Feb 2017 15:14:02 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 8776743; Thu, 16 Feb 2017 15:14:02 +0100 Subject: Re: Alternate header proposal Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_03D951F6-3706-4022-90CC-2BFB5CCB6E42"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Thu, 16 Feb 2017 15:14:01 +0100 Message-Id: References: To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:14:10 -0000 --Apple-Mail=_03D951F6-3706-4022-90CC-2BFB5CCB6E42 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Martin, all.. (and hi Jana, I like the general approach) trying to catch up on this thread, falling back to jump-in-randomly: > On 16 Feb 2017, at 02:41, Martin Thomson = wrote: >=20 > On 16 February 2017 at 12:39, Jana Iyengar wrote: >> Do you have more disadvantages besides the potential of increased >> link-ability? >=20 > Bloat. We just took great paints to trim a couple of octets from the > packet number, saving a whole 2 octets in the best case. But > connection ID is 8. I remain unconvinced of the complexity/space tradeoff for the 8- and = 16-bit packet number cases. Your earlier point on handling public resets = -- > Ahh, that's fine. In the case that packet number is short, I guess > the public reset will be sending the first 2 or 3 octets of the > payload. That's something for implementations to remember. We'll > need special text on that. I think that it's relatively easy to > implement that way, but it's not something that will be obvious. -- is an excellent illustration of the point here. If we're clawing 16 = to 24 bits back only to add 64 bits on Connection ID... the value prop = goes from "questionable" to "uncompelling"... And jumping back to another message: > (If you haven't guessed already, connection ID is the single feature > of this protocol that I am most conflicted about. I can see so many > advantages and so many disadvantages. They are all potentially huge > and that means that I don't know how to make the trade-offs sensibly.) This might be slightly cowardly, but I share your conflict. Perhaps the = presence/absence/utility of connection ID shouldn't be a property of = QUIC's design, then, but rather a property of the applications using = QUIC. Indeed, this isn't even a thing that should always be left up to = the app developer -- there are certainly networks I would be far less = interested in increasing my trackability on than others, independent of = application. Recommend two or three points in the space ("always" for load balancing = and rebinding, "sometimes" for load balancing and limited rebinding, = "never" for reducing traceability) and make supporting them all MTI. Cheers, Brian --Apple-Mail=_03D951F6-3706-4022-90CC-2BFB5CCB6E42 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 iQIcBAEBCgAGBQJYpbOqAAoJEIoSt78L6kajzoEP/Azp7XBqQne094akvBg1W8ak YlnbfJ7iW/UUz/jZTRjtw675IxfSmbUQXEwRhQG7NmwRKAO8uP8Nh9O6XI3Tu7Yo ROU8Hrx3Z2yp1pvhplWhgbqDpMsZp+QGmuUSCwjN5NgFRcS5JLmWhdUgtqFnPsNx i9T4msoUSeOvj8tG1K0SqumWQ0gSB3nXkgtMaheR2BfsbjG61lhoEl/C48ofK01C NdHotQcvMscxyqSuxxNdIa/xwLmgg+Rv0fYwIU7EuhtRwMjhtDOwx/17Ir1LZAy2 J7OyXk+ajDYRnMf1PiB6qa7kxHz/3kn1N5zoz87E0ZE8O6pQwk4el394AVBxR4Cg rjy2jsHxeUAk58ykwg1au0GQLa4JUV7NUhXzMQ0r+AoeES7ekzc0sVn6Rs9+3HzG ZhHKBsdiSBhwmxw0UA2EzLrW/JegK8RWObFkfSRCavKbkQqiLsZWuZ/GoWgxgwhQ Ugrg1COrTm2wU3ehZxHbaOd+VbvkMLCfDE5GPF4oRztYg/hCDSQ0qqtbEzVAKbqe Yfh4erTrCaOciI2kONKbrmzVSxKMmuJo1HfEZXl1PHa5R2CUALHv/dve5uDA4PUa 0nYKVrqq3F/gcTMx3sQu/elKKoRvSZ8+1Fh5H5L50DxgAPCNDWlMqIf5k1FkVa5N 0GOqpIyYYeTVtbqYkbMC =pW9R -----END PGP SIGNATURE----- --Apple-Mail=_03D951F6-3706-4022-90CC-2BFB5CCB6E42-- From nobody Thu Feb 16 06:14:23 2017 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 02557129A0F for ; Thu, 16 Feb 2017 06:14:15 -0800 (PST) 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_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MLJlx1V9VP-2 for ; Thu, 16 Feb 2017 06:14:13 -0800 (PST) Received: from pianosa.iway.ch (pianosa.iway.ch [212.25.24.37]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC8E129D09 for ; Thu, 16 Feb 2017 06:14:12 -0800 (PST) Received: from pianosa.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 6F2C0E2D08; Thu, 16 Feb 2017 15:14:11 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/2244.3302); Thu, 16 Feb 2017 15:14:11 +0100 (CET) Received: from gozo.iway.ch (gozo.iway.ch [212.25.24.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pianosa.iway.ch (Postfix) with ESMTPS; Thu, 16 Feb 2017 15:14:11 +0100 (CET) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 4B11E3403DD; Thu, 16 Feb 2017 15:14:11 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/19061.3605); Thu, 16 Feb 2017 15:14:11 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Thu, 16 Feb 2017 15:14:11 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 8776774; Thu, 16 Feb 2017 15:14:11 +0100 Subject: Re: Alternate header proposal Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_42A13B27-7669-4742-A79F-7831E3A1ABCB"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Thu, 16 Feb 2017 15:14:10 +0100 Message-Id: <67849EFA-93CF-405F-B879-A3701597D02A@trammell.ch> References: <90f6c1ab-6c6c-8d5d-e69f-201a902e9174@huitema.net> To: Martin Thomson X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 14:14:15 -0000 --Apple-Mail=_42A13B27-7669-4742-A79F-7831E3A1ABCB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 16 Feb 2017, at 03:58, Martin Thomson = wrote: >=20 > On 16 February 2017 at 13:29, Christian Huitema = wrote: >> I am a little bit worried about the proposal to set the packet number = size >> to 32 bits in "QUIC for now". I know that "4 billion messages in 100 >> milliseconds" appears ridiculously large right now, but do you really >> believe that we are not going to see 500 Tbps links in the future? Or = maybe >> 1Tbps link to the Moon, or to Mars? Maybe not in my lifetime, but in = yours? >> At that point, how do we get the "short form" to use 64 bit numbers? >=20 >=20 > You can stick the extra high bits after the version in the long form. > The short form can just use a new type field to indicate that the > packet number is gigantic. >=20 > Of course, this all assumes that you a) have 500 Tbps or higher, and > b) that you get reordering over ~4 times the BDP on that link. That > latter part is where I think this breaks down some. I don't know; I think it'd be fun to design a networking experiment that = involves accelerating the moon to relativistic speeds... --Apple-Mail=_42A13B27-7669-4742-A79F-7831E3A1ABCB 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 iQIcBAEBCgAGBQJYpbOzAAoJEIoSt78L6kajRQQQAI095GELvEMuVbP7qiqWWLkj QbN7rHYQXH41s2GCPthl8EAsIwyq2z966DtKtgZE8vd/W3wSyh/S50jSru/Ps0kO tyCY1mSZTMNyp4WtRyX1V95TFxMpShiAjAI2UNq/xJUBLiKs8rOArC+UZlAuOZds Yq8+A0X6SBkCgdFFy/M9rzJMCuseKHFl6/4u+B080GsG9veRDlQwdmQPrTLxVQRZ hUjNHGoFiYRY4MjbalkzDmj0oopJUPCj770b2Hmrs5S4WFMPYem3rNJeTyD3l/X0 z7M0CqgaMBDHTeXb27c5R7GrLaoZMwC/Chypmck3vHL+BFOdK6nmEKeLV4gXQLzh lMgjXgTRx+X9mEiW1nPQIaVCsopu/Wmnh8jRaX87AIA4D4DY6pVXkzXXLJoyGSEU ZrmPCUbWcn1zhcvze2qU/73H14AW1RncZrzGvgg3j8k53mZdPqGadke7V4tgGLRP bVJiDrrbLUrsvjXAsqWqmGeAgSPBFCD5kCNEySG34y9SYIP0IqGV/HNj10FqEfUC bLY2PsSEXVAbdOhoIqAB0rC2Z/Q5bdlSeka6hMsw3lRjCCdPblRUTvlZSwhuIXou Tzkfu28E0XIMINuJEWCjXV8+xzBAaB2TypHua90fpUtHwgmInl6jv2G8KrvUWdzq movugSLDCRdrCjEbjSfa =5M1W -----END PGP SIGNATURE----- --Apple-Mail=_42A13B27-7669-4742-A79F-7831E3A1ABCB-- From nobody Thu Feb 16 07:31:52 2017 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 4887A12966A for ; Thu, 16 Feb 2017 07:31:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 i9Dl8v4IAxEd for ; Thu, 16 Feb 2017 07:31:50 -0800 (PST) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 034A5129662 for ; Thu, 16 Feb 2017 07:31:50 -0800 (PST) Received: by mail-yb0-x232.google.com with SMTP id o65so5182243ybo.2 for ; Thu, 16 Feb 2017 07:31:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qkXLkoG8oU7exP39HpI9mnLzgJ/XTst4DsFQrK37z6g=; b=RxCJ2W0773+GbSuXPrPAYsRMBqZnuW1Z9q9D3kwctxMM5famCBNXqHpmZWtWYUa6xi hWFGJQ/XiYKmvrPeoNhUI4iskxLjqIYOnFx1EG23Ignbna00RejvTigTUxxoOjqQEeqW 4flLMiMBTiu0Gi1l3zWP2zGTrH2MUdP9yGrjBY5Aqu2kSK9pcEI9qgWBUVslx8UDkwjQ KW4rNbuqbMFwacQMWtWaeROJvKqZCjdRDkhh/K8iSEwl1Ct4Gg7RVIUAnns729QmVWDS rPtwjhAzyXR+VVTkkymIDNelumBEmAPWdrMfqFmYXlnMzdvQE3eYnHzLZ4kEBsXLZRDb 5rKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qkXLkoG8oU7exP39HpI9mnLzgJ/XTst4DsFQrK37z6g=; b=AMOtbUFe1pu35LgCI08JakgGmrCRI8VWlfh0Sr2xRE5L6ud66bcl0JxaBvkK67drqv fcaGgQxn6xKtpCEJFRxlnVwfGJoIq7DeUq3btv3b+tfiXITtm0Sgr3hjOCJ/b69oLKPA UnAvMwA4raX9p9t2b/b5DugkmPfc6B7Y4d56zdqVN3Z6HDAvTglroOXTx+Kb4VDcrzYq GYGp8UcEqTIld/F4hMW8LER4aY0GQ4kkliEDeus993wtMo7ccAWLv8u0xipzbddTm70v J99Dbw/3xMO47Mhy0aMY/wBJsBxU0Lywrrf/tZLkQTRMJyNAWMUOO7aY10SZkbhGWGvy PnJg== X-Gm-Message-State: AMke39n0mOG4ZxlH85+P4glIoVNaN7Ya/G/eHi0daalJcxEUkJTHrX1Z5f0omokY9ge9/EiED6UdqpFPL6UxoGUL X-Received: by 10.37.170.114 with SMTP id s105mr2050946ybi.44.1487259108941; Thu, 16 Feb 2017 07:31:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.210.134 with HTTP; Thu, 16 Feb 2017 07:31:28 -0800 (PST) In-Reply-To: References: <90f6c1ab-6c6c-8d5d-e69f-201a902e9174@huitema.net> From: Ian Swett Date: Thu, 16 Feb 2017 10:31:28 -0500 Message-ID: Subject: Re: Alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11487874e120ab0548a77e2c Archived-At: Cc: IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 15:31:51 -0000 --001a11487874e120ab0548a77e2c Content-Type: text/plain; charset=UTF-8 I was a bit concerned about that as well, but I don't think we need more than 4 bytes for the handshake(long form) and it's easy to add new version specific code points for 8 byte packet numbers in the future if we wanted them. Or we can add the codepoints now if we know we're going to want them. Martin's point is valid, that this really only becomes a concern with large scale reordering or loss. On Wed, Feb 15, 2017 at 9:58 PM, Martin Thomson wrote: > On 16 February 2017 at 13:29, Christian Huitema > wrote: > > I am a little bit worried about the proposal to set the packet number > size > > to 32 bits in "QUIC for now". I know that "4 billion messages in 100 > > milliseconds" appears ridiculously large right now, but do you really > > believe that we are not going to see 500 Tbps links in the future? Or > maybe > > 1Tbps link to the Moon, or to Mars? Maybe not in my lifetime, but in > yours? > > At that point, how do we get the "short form" to use 64 bit numbers? > > > You can stick the extra high bits after the version in the long form. > The short form can just use a new type field to indicate that the > packet number is gigantic. > > Of course, this all assumes that you a) have 500 Tbps or higher, and > b) that you get reordering over ~4 times the BDP on that link. That > latter part is where I think this breaks down some. > > --001a11487874e120ab0548a77e2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I was a bit concerned about that as well, but I don't = think we need more than 4 bytes for the handshake(long form) and it's e= asy to add new version specific code points for 8 byte packet numbers in th= e future if we wanted them.=C2=A0 Or we can add the codepoints now if we kn= ow we're going to want them.=C2=A0 Martin's point is valid, that th= is really only becomes a concern with large scale reordering or loss. =C2= =A0



On Wed, Feb 15, 2017 at 9:58 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 16 February 2017 at 13:29, Christian Huitema = <huitema@huitema.net> wrot= e:
> I am a little bit worried about the proposal to set the packet number = size
> to 32 bits in "QUIC for now". I know that "4 billion me= ssages in 100
> milliseconds" appears ridiculously large right now, but do you re= ally
> believe that we are not going to see 500 Tbps links in the future? Or = maybe
> 1Tbps link to the Moon, or to Mars? Maybe not in my lifetime, but in y= ours?
> At that point, how do we get the "short form" to use 64 bit = numbers?


You can stick the extra high bits after the version in the long form= .
The short form can just use a new type field to indicate that the
packet number is gigantic.

Of course, this all assumes that you a) have 500 Tbps or higher, and
b) that you get reordering over ~4 times the BDP on that link.=C2=A0 That latter part is where I think this breaks down some.


--001a11487874e120ab0548a77e2c-- From nobody Thu Feb 16 08:11:19 2017 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 DBA77129D66 for ; Thu, 16 Feb 2017 08:11:17 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 do22SYpD8iUp for ; Thu, 16 Feb 2017 08:11:16 -0800 (PST) Received: from mail-vk0-x22e.google.com (mail-vk0-x22e.google.com [IPv6:2607:f8b0:400c: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 5554B129D63 for ; Thu, 16 Feb 2017 08:11:16 -0800 (PST) Received: by mail-vk0-x22e.google.com with SMTP id x75so13057290vke.2 for ; Thu, 16 Feb 2017 08:11:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=23EKYdA6ZzwDXaTILASCW8xfmmrQtKmVF1WMHYSPFnM=; b=R0pb37OnoFhos7yVal5OD9yZgrinb3W/haRPVPM4mWAtL/OVSJEgzT2useEVqG9Eyu FGW1fxjrOdfyPQma1VWJjRI3zNfFACD66mpx5Ckw/0/8rZ03U43ryioMBd/CvEn6iWwy p9XwNnm9X8mELWoaFSID1DsZQ5y8Wcz0aBuqsoOmYpO1hWKD25ad+s0IZi2efw7meAiz 5JRwfZkNDteShSDTJIgZD3LRWl/zMxp9cHyd/Fs+b9OAe1uI2YhGwtI4FrIPT8UP2W0D Wjn3xYvnSwzaiF0Nv9O8KK/YWXZF3aQVbSzeCfprTFNFfKrMaBPqLUOi4mW96lLbUdwC AaWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=23EKYdA6ZzwDXaTILASCW8xfmmrQtKmVF1WMHYSPFnM=; b=svn70V0s4cHiwJmKyMejrYHzewiLCTZSyhSLIuKSldFJI5bccinTFAfNLbDSk5pxyU jA00RGt0A1tCcQ/q0M/1UfIqIID4RrOM+zvqbypAeYbDN18nobwSK8PBmN6EyYxxj/cI UtSJF3DsclRDiVA90XuC2/l+e/NBRzv4DIK2UugQWHXABzwK4e5hGdHRG9dJ/1YVnmfh BAv3Mja6qUEgbXiRX9Ltb9fqg0tCTMUure79ADXOU1Wyh3SeqR0oWDFrNaiY0zbJhNYH exrFkfCU9KlPL2jfVNWrzLNi0/JJ5k3JNOkz6W2TzZV/QBes3jSpTfYtWGDeNmaBvNB+ fItQ== X-Gm-Message-State: AMke39kNdbNc/G5E2km3+8remf5AbK9stcvD1TxmWJcZXcdWOA7doCLXhi6UE2Nnp5U9FQrIZJTqGfGeQvuoEEwh X-Received: by 10.31.89.197 with SMTP id n188mr1185231vkb.58.1487261475079; Thu, 16 Feb 2017 08:11:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 16 Feb 2017 08:11:14 -0800 (PST) In-Reply-To: References: <90f6c1ab-6c6c-8d5d-e69f-201a902e9174@huitema.net> From: Jana Iyengar Date: Thu, 16 Feb 2017 08:11:14 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e19b0e961c70548a80b88 Archived-At: Cc: IETF QUIC WG , Christian Huitema X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:11:18 -0000 --001a114e19b0e961c70548a80b88 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 15, 2017 at 6:58 PM, Martin Thomson wrote: > On 16 February 2017 at 13:29, Christian Huitema > wrote: > > I am a little bit worried about the proposal to set the packet number > size > > to 32 bits in "QUIC for now". I know that "4 billion messages in 100 > > milliseconds" appears ridiculously large right now, but do you really > > believe that we are not going to see 500 Tbps links in the future? Or > maybe > > 1Tbps link to the Moon, or to Mars? Maybe not in my lifetime, but in > yours? > > At that point, how do we get the "short form" to use 64 bit numbers? > > > You can stick the extra high bits after the version in the long form. > The short form can just use a new type field to indicate that the > packet number is gigantic. > +1. This is why the packet number was after the version earlier, but we can pretty much do whatever we want in the long form after the version field. > Of course, this all assumes that you a) have 500 Tbps or higher, and > b) that you get reordering over ~4 times the BDP on that link. That > latter part is where I think this breaks down some. > I'm not arguing for having larger packet numbers now, but just on the point of reordering: it's difficult to tell if there will be reordering or not. If large bandwidths are gotten by combining multiple lambdas in one fiber for instance, then reordering could even be the norm. --001a114e19b0e961c70548a80b88 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 15, 2017 at 6:58 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 16 February 2017 at 13:29, Christian Huitema <huitema@huitema.net> wrote:
> I am a little bit worried about the proposal to set the packet number = size
> to 32 bits in "QUIC for now". I know that "4 billion me= ssages in 100
> milliseconds" appears ridiculously large right now, but do you re= ally
> believe that we are not going to see 500 Tbps links in the future? Or = maybe
> 1Tbps link to the Moon, or to Mars? Maybe not in my lifetime, but in y= ours?
> At that point, how do we get the "short form" to use 64 bit = numbers?


You can stick the extra high bits after the version in the long form= .
The short form can just use a new type field to indicate that the
packet number is gigantic.

+1. This is = why the packet number was after the version earlier, but we can pretty much= do whatever we want in the long form after the version field.=C2=A0
<= div>=C2=A0
Of course, this all assumes that you a) have 500 Tbps or higher, and
b) that you get reordering over ~4 times the BDP on that link.=C2=A0 That latter part is where I think this breaks down some.

I'm not arguing= for having larger packet numbers now, but just on the point of reordering:= it's difficult to tell if there will be reordering or not. If large ba= ndwidths are gotten by combining multiple lambdas in one fiber for instance= , then reordering could even be the norm.
--001a114e19b0e961c70548a80b88-- From nobody Thu Feb 16 08:13:15 2017 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 766A7129D72 for ; Thu, 16 Feb 2017 08:13:14 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aadVuDRG-OYS for ; Thu, 16 Feb 2017 08:13:13 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 D2E97129D70 for ; Thu, 16 Feb 2017 08:13:12 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id r136so13203401vke.1 for ; Thu, 16 Feb 2017 08:13:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=INku9ZtI44brtDdKmyRbiCMT81hxvs8TMUC5cihcHyg=; b=ucyAUHoeteE5P7hXs23p6j+EXpu7hYiHtH5xeloDLC0WRaPkFyle57RfgzLPCNSFue soFRt4QhvqDLmZV67VsfRlYPGZMi6aZwTQIFCd4zU4xnvPEapDZwG/JfYmsYUczMnpTW Q2KJkNkgk3FXxeWp0b0uKkDBkbVxJ73yp5G4Qunnc2NrCcvADMdxRWsJQX21d1HnAdQj WlC3oWtA4rLKblH5jqU5IYJDGRlzUP4wPsGVMYj0vmyJDIovSCi0o5lxQ9bxRXJEOZ86 En5ZTqURa1WyCmUJZYzoxv8B0lU1cekg4lpLIXjkTunc8kknfeiR8ky5vAhHdmVDlz1H Kcnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=INku9ZtI44brtDdKmyRbiCMT81hxvs8TMUC5cihcHyg=; b=fl6RcHfMVuyF5HcQcsctS/XLDtc3pCL4BhzKIx9W9cr0PZz7ACS3sV0eN0dYY5ZDdn Vkr50+Nxq11avlvhmBKIEf10bTko4P82w3vkfuF8YEpvzfhwO2JHkth+d9Rndf4MjK04 LCEBQEEoxfb71SQ7IxYYHy3e5zw8udyariqtBkTe1RRN7TtHWEja/VSG0vn0BtAl0KVQ bnUZ5nfERoVgyO7JhI0etPOGBcA/ST1sYplhSxSRQzaZlDBXoW5R03CZr91vokqdRZXo gRoj6H+zYW4snoQTDa5q/rQYvqSmgwr0UI7T9nDVtjj8A5hp2sT7mIT9M59fdDc2mvPu TbNg== X-Gm-Message-State: AMke39mxPPuMOFoMewE97zAcJIX16YqW3stE/+Vd7ZOcpHk2aLCTcj5PnPvQrQKfhyBfBXSh18dgq21/7ADuOErp X-Received: by 10.31.107.74 with SMTP id g71mr1237885vkc.116.1487261591628; Thu, 16 Feb 2017 08:13:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 16 Feb 2017 08:13:10 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 16 Feb 2017 08:13:10 -0800 Message-ID: Subject: Re: Alternate header proposal To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a11479100dbba9b0548a8125f Archived-At: Cc: Ian Swett , Ingemar Johansson S , marcelo bagnulo braun , IETF QUIC WG , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:13:14 -0000 --001a11479100dbba9b0548a8125f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 16, 2017 at 5:31 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > > Am 16.02.2017 um 08:59 schrieb Ingemar Johansson S < > ingemar.s.johansson@ericsson.com>: > > > > Question: Is CWR necessary with QUIC, I always thought that it is > something that is a special thing for TCP with its limited header space. > > Or is CWR used for other means than to just clear the ECE flag for > classic ECN ? > > ECE and CWR are both TCP-specifc. For quic you could also provide feedbac= k > in the form of counters for ECT1/ECT1/CE (similar to RTCP)... +1 to we can use entirely different feedback mechanisms. We definitely don't need CWR, since as Marcelo points out we can use ACKs of packets containing an ECN feedback frame instead. --001a11479100dbba9b0548a8125f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a11479100dbba9b0548a8125f-- From nobody Thu Feb 16 08:20:18 2017 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 1D02A1293DB for ; Thu, 16 Feb 2017 08:20:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 yi8FAVi5u5YF for ; Thu, 16 Feb 2017 08:20:13 -0800 (PST) Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::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 235DE12711D for ; Thu, 16 Feb 2017 08:20:13 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id 35so13834358uak.1 for ; Thu, 16 Feb 2017 08:20:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XiNy4n8dXr/JDseXjvSccAdR7rI9xUdUQ5ElGxtZPTg=; b=cShxJ+Z16PsRaxQUjRFBC7FDQI5Fx+gQKFMk5uJc9KlrxUQ4UHmiaFG8X50DhsnvLj gy4yBpXVy1mlwqtr+yMVeWqLR4tSXQ3IquXccaurXKbXMQ7v9u3Q6gVfok61c9tibNCW BGs+ohglz5ia4Jsp0RszsItVBGmKRkQlYEN0i8GDLCRBjA4AWQYLNg3Er26hr27ZdlSn 0WsFFNIPncAqV/14af5/dIwUGs3kBYJ+GHwbd2ALZ9lHk7Rv2c2bYjSNTFdrS6a3YkwV 02vJg06em+64wwQVTQq395HQZ5cEaLRr7IR4AnuIzCOv2GAq/GBx0WSV8cvsy9rMP1Cb c+ow== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XiNy4n8dXr/JDseXjvSccAdR7rI9xUdUQ5ElGxtZPTg=; b=asK1nKVQ2FpUl+xMyGa3IwJZG5tYNpeqDR/Pgvv3AU/hvP97fL2TntrjbMET9dD6bP gzNMzKMRWyTN1vk/4Xo0ITpBschQCWQc/tIgEGH8ZKB5Ai3xDsx4h90G7xFZQTRF8HKJ Le5LF315PCDQ37Vq1JMsCU54EwB2aXr0q1gF2Y6HQKT/zUGHyhxqJ+JRbCLSsJQ0tpT2 cnopAeJLJqp5A7ZA8wqgaTxkP2mfFDjpBETGqM9BXfkPiTcGujfrR0xqAzk1wPoH8bOA fQV2jKRJ2Basg4fu+qKoa5QSsp94jVM++f43KD2IoHQS2mmW9yBaxyeWjUXvdt7hwpQV XIJQ== X-Gm-Message-State: AMke39lz4t9KMV7Q+FS13uBbovly8POEj+3TNL6CJenLpxH9NqlKOLL5OTHjrzeyc4RTFVuCxamL2xf7PeV5sELV X-Received: by 10.159.54.205 with SMTP id p71mr1214375uap.61.1487262011904; Thu, 16 Feb 2017 08:20:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 16 Feb 2017 08:20:10 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 16 Feb 2017 08:20:10 -0800 Message-ID: Subject: Re: Alternate header proposal To: "Brian Trammell (IETF)" Content-Type: multipart/alternative; boundary=94eb2c03d92ae8a75b0548a82bac Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:20:17 -0000 --94eb2c03d92ae8a75b0548a82bac Content-Type: text/plain; charset=UTF-8 On Thu, Feb 16, 2017 at 6:14 AM, Brian Trammell (IETF) wrote: > hi Martin, all.. > > (and hi Jana, I like the general approach) > > trying to catch up on this thread, falling back to jump-in-randomly: > > > On 16 Feb 2017, at 02:41, Martin Thomson > wrote: > > > > On 16 February 2017 at 12:39, Jana Iyengar wrote: > >> Do you have more disadvantages besides the potential of increased > >> link-ability? > > > > Bloat. We just took great paints to trim a couple of octets from the > > packet number, saving a whole 2 octets in the best case. But > > connection ID is 8. > > I remain unconvinced of the complexity/space tradeoff for the 8- and > 16-bit packet number cases. Your earlier point on handling public resets -- > The complexity isn't high, and we save bits. > > Ahh, that's fine. In the case that packet number is short, I guess > > the public reset will be sending the first 2 or 3 octets of the > > payload. That's something for implementations to remember. We'll > > need special text on that. I think that it's relatively easy to > > implement that way, but it's not something that will be obvious. > > -- is an excellent illustration of the point here. If we're clawing 16 to > 24 bits back only to add 64 bits on Connection ID... the value prop goes > from "questionable" to "uncompelling"... > Again, connection ID is optional in this proposal. We're not simply adding 64 bits for everyone. I'll note again that the common packet header size in this format will be 2-3 bytes: 1 type byte (short form) + 1-2 bytes of packet number. - jana And jumping back to another message: > > > (If you haven't guessed already, connection ID is the single feature > > of this protocol that I am most conflicted about. I can see so many > > advantages and so many disadvantages. They are all potentially huge > > and that means that I don't know how to make the trade-offs sensibly.) > > > This might be slightly cowardly, but I share your conflict. Perhaps the > presence/absence/utility of connection ID shouldn't be a property of QUIC's > design, then, but rather a property of the applications using QUIC. Indeed, > this isn't even a thing that should always be left up to the app developer > -- there are certainly networks I would be far less interested in > increasing my trackability on than others, independent of application. > Recommend two or three points in the space ("always" for load balancing and > rebinding, "sometimes" for load balancing and limited rebinding, "never" > for reducing traceability) and make supporting them all MTI. > > Cheers, > > Brian > --94eb2c03d92ae8a75b0548a82bac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 16, 2017 at 6:14 AM, Brian Trammell (IETF) <ietf@trammell.ch>= ; wrote:
hi Martin, all..

(and hi Jana, I like the general approach)

trying to catch up on this thread, falling back to jump-in-randomly:

> On 16 Feb 2017, at 02:41, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> On 16 February 2017 at = 12:39, Jana Iyengar <jri@google.com> wrote:
>> Do you have more disadvantages besides the potential of increased<= br> >> link-ability?
>
> Bloat.=C2=A0 We just took great paints to trim a couple of octets from= the
> packet number, saving a whole 2 octets in the best case.=C2=A0 But
> connection ID is 8.

I remain unconvinced of the complexit= y/space tradeoff for the 8- and 16-bit packet number cases. Your earlier po= int on handling public resets --

The complexity isn't high, and we save bits.
> Ahh, that's fine.=C2=A0 In the ca= se that packet number is short, I guess
> the public reset will be sending the first 2 or 3 octets of the
> payload.=C2=A0 That's something for implementations to remember.= =C2=A0 We'll
> need special text on that.=C2=A0 I th= ink that it's relatively easy to
> implement that way, but it's not something that will be obvious.
-- is an excellent illustration of the poi= nt here. If we're clawing 16 to 24 bits back only to add 64 bits on Con= nection ID... the value prop goes from "questionable" to "un= compelling"...

Again, conne= ction ID is optional in this proposal. We're not simply adding 64 bits = for everyone. I'll note again that the common packet header size in thi= s format will be 2-3 bytes: 1 type byte (short form) + 1-2 bytes of packet = number.

- jana

And jumping back to another message:

> (If you haven't guessed already, = connection ID is the single feature
> of this protocol that I am most conflicted about.=C2=A0 I can see so m= any
> advantages and so many disadvantages.=C2=A0 They are all potentially h= uge
> and that means that I don't know how to make the trade-offs sensib= ly.)


This might be slightly cowar= dly, but I share your conflict. Perhaps the presence/absence/utility of con= nection ID shouldn't be a property of QUIC's design, then, but rath= er a property of the applications using QUIC. Indeed, this isn't even a= thing that should always be left up to the app developer -- there are cert= ainly networks I would be far less interested in increasing my trackability= on than others, independent of application.
<= br>
Recommend two or three points in the space ("always" for load bal= ancing and rebinding, "sometimes" for load balancing and limited = rebinding, "never" for reducing traceability) and make supporting= them all MTI.


=C2=A0

--94eb2c03d92ae8a75b0548a82bac-- From nobody Thu Feb 16 08:24:54 2017 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 96355129DA5 for ; Thu, 16 Feb 2017 08:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 nxXtOfg5a1fP for ; Thu, 16 Feb 2017 08:24:50 -0800 (PST) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE4D8127601 for ; Thu, 16 Feb 2017 08:15:23 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id u143so10874221oif.3 for ; Thu, 16 Feb 2017 08:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xj8uEh24NT/WLBFZrG1xKtXldvZORQ7K0qjTEb04Sp4=; b=uVpap0sCFwCgsktN7MuT+T9xJi/f3PvpRm5Ug7a8qqJy6ei3IVJny2IUVdG7c1R33m GzAg99bSZJoQFNTDg8ueqP9lE3KxQuYHatQ/8FHQbZTvZI5uTTXFWG1SqLkLbSD0g7OO G3kRTVJFm8/uHfibJodLBv32vVHK55WAudWFPkEHgwfa7eME4eHiiI95n+JBxl0n7tX1 /zMofwHl28V/fbv0kOJ1fJsNYduUwAe+H4fcecWthJptSWFwCdKhqILQUVpYw/ZcIjpN cUdM8EwKl4gerBzgqVrUuNBW1BvCnTz1W7rkxrzD4rQdtb1WP6VsItftw3yHA8KoZPrn NaCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xj8uEh24NT/WLBFZrG1xKtXldvZORQ7K0qjTEb04Sp4=; b=keLBTAZFDpFz1zCfA5jCkVblgM+7a/mAtMAXrVd7p85D3QCwb3YF30Z3Oq8AC7vF9D jIFbzRaSUW/4effRbbgWD/DvlEDxXOsqxsQ3zgj79PBlTt/FQPllJrWRr+owtSfRemRa YWYLJarj4/GPK370GXfZUO5SBnKD4P0y8MBM8KhKV/bngD7DKTfBVI96L0XZhgy1XrpX glJ4kDwKF2hbu6/pRnSoK6Ok7yA8+cy4T8+NvDpF2Vk3g0AaOmvf4LU4APXPoLYSfuBr /TtyWD9ldgQk8pmv69YAiJiV1BtbchGlHCeSJ8qKYkj/Yg9Evlv/UVBFLPHgsFmmmBWM skCA== X-Gm-Message-State: AMke39kJJqLrxC/L4/eY6/VcTeDDcB5mEaMhNaH4cwOyaR/iQbd4pevlsUHdD5bk+xSIltOV5HmuUBhlgivboA== X-Received: by 10.202.179.9 with SMTP id c9mr1384502oif.152.1487261723335; Thu, 16 Feb 2017 08:15:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.173.78 with HTTP; Thu, 16 Feb 2017 08:15:22 -0800 (PST) In-Reply-To: <1358D674-9513-4451-AE6C-3B82C84057A1@trammell.ch> References: <1358D674-9513-4451-AE6C-3B82C84057A1@trammell.ch> From: Matt Holdrege Date: Thu, 16 Feb 2017 17:15:22 +0100 Message-ID: Subject: Re: Alternate header proposal To: "Brian Trammell (IETF)" Content-Type: multipart/alternative; boundary=001a113ce602b521d20548a81a6e Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 16:24:51 -0000 --001a113ce602b521d20548a81a6e Content-Type: text/plain; charset=UTF-8 FWIW I completely agree with the idea of letting the application deal with connection ID and all that goes with that. QUIC should be quick, not just in terms of routing/switching packets, but by avoiding upper layer policy issues. -Matt On Thu, Feb 16, 2017 at 1:58 PM, Brian Trammell (IETF) wrote: > hi Martin, all.. > > (and hi Jana, I like the general approach) > > trying to catch up on this thread, falling back to jump-in-randomly: > > > On 16 Feb 2017, at 02:41, Martin Thomson > wrote: > > > > On 16 February 2017 at 12:39, Jana Iyengar wrote: > >> Do you have more disadvantages besides the potential of increased > >> link-ability? > > > > Bloat. We just took great paints to trim a couple of octets from the > > packet number, saving a whole 2 octets in the best case. But > > connection ID is 8. > > I remain unconvinced of the complexity/space tradeoff for the 8- and > 16-bit packet number cases. Your earlier point on handling public resets -- > > > Ahh, that's fine. In the case that packet number is short, I guess > > the public reset will be sending the first 2 or 3 octets of the > > payload. That's something for implementations to remember. We'll > > need special text on that. I think that it's relatively easy to > > implement that way, but it's not something that will be obvious. > > -- is an excellent illustration of the point here. If we're clawing 16 to > 24 bits back only to add 64 bits on Connection ID... the value prop goes > from "questionable" to "uncompelling"... > > And jumping back to another message: > > > (If you haven't guessed already, connection ID is the single feature > > of this protocol that I am most conflicted about. I can see so many > > advantages and so many disadvantages. They are all potentially huge > > and that means that I don't know how to make the trade-offs sensibly.) > > > This might be slightly cowardly, but I share your conflict. Perhaps the > presence/absence/utility of connection ID shouldn't be a property of QUIC's > design, then, but rather a property of the applications using QUIC. Indeed, > this isn't even a thing that should always be left up to the app developer > -- there are certainly networks I would be far less interested in > increasing my trackability on than others, independent of application. > > Recommend two or three points in the space ("always" for load balancing > and rebinding, "sometimes" for load balancing and limited rebinding, > "never" for reducing traceability) and make supporting them all MTI. > > Cheers, > > Brian > --001a113ce602b521d20548a81a6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FWI= W I completely agree with the idea of letting the application deal with con= nection ID and all that goes with that. QUIC should be quick, not just in t= erms of routing/switching packets, but by avoiding upper layer policy issue= s.=C2=A0

-Matt


On Thu, Feb 16, 2017 at 1:= 58 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
hi Martin, all..

(and hi Jana, I like the general approach)

trying to catch up on this thread, falling back to jump-in-randomly:

> On 16 Feb 2017, at 02:41, Martin Thomson <martin.thomson@gmail.com> wrote:
>
> On 16 February 2017 at 12:39, Jana Iyengar <jri@google.com> wrote:
>> Do you have more disadvantages besides the potential of increased<= br> >> link-ability?
>
> Bloat.=C2=A0 We just took great paints to trim a couple of octets from= the
> packet number, saving a whole 2 octets in the best case.=C2=A0 But
> connection ID is 8.

I remain unconvinced of the complexity/space tradeoff for the 8= - and 16-bit packet number cases. Your earlier point on handling public res= ets --

> Ahh, that's fine.=C2=A0 In the case that packet number is short, I= guess
> the public reset will be sending the first 2 or 3 octets of the
> payload.=C2=A0 That's something for implementations to remember.= =C2=A0 We'll
> need special text on that.=C2=A0 I think that = it's relatively easy to
> implement that way, but it's not something that will be obvious.
-- is an excellent illustration of the point here. If we're claw= ing 16 to 24 bits back only to add 64 bits on Connection ID... the value pr= op goes from "questionable" to "uncompelling"...

And jumping back to another message:

> (If you haven't guessed already, connection ID is the single featu= re
> of this protocol that I am most conflicted about.=C2=A0 I can see so m= any
> advantages and so many disadvantages.=C2=A0 They are all potentially h= uge
> and that means that I don't know how to make the trade-offs sensib= ly.)


This might be slightly cowardly, but I share your conflict. Perhaps = the presence/absence/utility of connection ID shouldn't be a property o= f QUIC's design, then, but rather a property of the applications using = QUIC. Indeed, this isn't even a thing that should always be left up to = the app developer -- there are certainly networks I would be far less inter= ested in increasing my trackability on than others, independent of applicat= ion.

Recommend two or three points in the space ("always" for load bal= ancing and rebinding, "sometimes" for load balancing and limited = rebinding, "never" for reducing traceability) and make supporting= them all MTI.

Cheers,

Brian

--001a113ce602b521d20548a81a6e-- From nobody Thu Feb 16 10:28:54 2017 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 D3136129545 for ; Thu, 16 Feb 2017 10:28:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.576 X-Spam-Level: X-Spam-Status: No, score=-1.576 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, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 fhh7yH6z1-Un for ; Thu, 16 Feb 2017 10:28:51 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 C3095129535 for ; Thu, 16 Feb 2017 10:28:50 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id r136so15741292vke.1 for ; Thu, 16 Feb 2017 10:28:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Sig2hWbHXx/IxYODa8OqMjfIR8E6s8Nswsmwy9s4Dh4=; b=AgCe225sz1DHoN1hIKoEK8GIU2Y+ZZ/Hk6xNMG9iF7ibt2WBW2LxQsv8i+WG7gXMzZ oVaqNJacjzsX2iXSuv5IL8xKCA8e4bNkTv2oXcHqXlxpFYFUrz6nwIY3JATg0qCchzaE w8n0Vl0Gdo+srIZf8PWuC4SfriFGMgs9cN9hKtw4V0kKlxwZvja3K6roA6xGaxFZ4zLW mfUqjWdL91ewpBCow2tFa2R0r/zFUaMvaachBCdcYcM7PPT9w3Jt4+xCAuqPa+0kcFzJ kA2TVNMDfOhdKCstLnwxWCiDY1zUF7P9D10tDo8Bl6lRUME3pl1+EkEs0TyR8FL1OGt0 pAgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Sig2hWbHXx/IxYODa8OqMjfIR8E6s8Nswsmwy9s4Dh4=; b=p19gCmcCX4bHsiGlls0hfGsOJ9bGqyEFyMCSQFrrpYkGO73lJIrsRVz+xD5wYw/Du+ a1TaSXSoKu4SGit3KYeGKYjZzSDO/z/epmNx0s5aYatv1rTNgcWvJuDztEZv6z/7jGlJ eZJY5PxoeEb8cihu4Ereh4YllWZbh1z3FNjBTvWpURWAIZ3XJcS1GPm3gLAbdwLYsRe0 Q05K1ox/BiQt7zDA+Tfp+1j69qDqmCrXZg/FMYtLLJ+eKC8Ub+cFyf+LkKKJj6UNkIhf Wpa5TJhckW2O6LbDGRmaIEUhrqlGgXGjb5ebrNYZX++zbhAz3MU+YQjwoiWeKZyKSrYY frAA== X-Gm-Message-State: AMke39lU/RxnFiD+pPW7xbbHxFtFcIXvvRZH0LHQv7MblSBd9RvTHRlNmNr7amsflnpYj9Y/UtxVNqWhGjfw14SC X-Received: by 10.31.99.1 with SMTP id x1mr1802562vkb.161.1487269729420; Thu, 16 Feb 2017 10:28:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 16 Feb 2017 10:28:48 -0800 (PST) From: Jana Iyengar Date: Thu, 16 Feb 2017 10:28:48 -0800 Message-ID: Subject: Driving towards agreement on alternate header proposal To: IETF QUIC WG Content-Type: multipart/alternative; boundary=94eb2c07b178e887950548a9f793 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 18:28:53 -0000 --94eb2c07b178e887950548a9f793 Content-Type: text/plain; charset=UTF-8 Stepping back a bit from the weeds, there seems to be general agreement on the shape of the header. It seems like we want to continue discussing the connection ID issue, but I'll note that this header reformulation does not change the status quo on that issue. The connection ID is present, optional, and negotiable in the current spec and this proposal retains those properties. This new formulation addresses a number of issues in the tracker however. Per my read, it closes: #35 : Starting packet number #56 : Extending flags #119 : Server-proposed connection ID #133 : Connection ID in version negotiation #135 : DoS using Version Negotiation Packets #147 : Reflection Attack Resistance #185 : Reliable identification of the initial packet for a connection #193 : Flags section is kind of confusing #244 : Need a NONCE in version negotiation packets #293 : Does the connection ID need to be in a consistent location #295 : Connection ID on a version negotiation packet And it addresses some of: #148 : QUIC packet header complexity #170 : Connection ID collisions Given the number of issues it closes, and with the understanding that (i) this format may still change as QUIC evolves, and (ii) we can continue the connection ID question on a separate bug/issue, I'd like to see if we can accept the general proposal as a step forward. Does this seem reasonable? I feel like we're moving towards editor-ready, but I am looking for a signal from the chairs to indicate this. --94eb2c07b178e887950548a9f793 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Stepping back a bit from the weeds, there seems to be gene= ral agreement on the shape of the header. It seems like we want to continue= discussing the connection ID issue, but I'll note that this header ref= ormulation does not change the status quo on that issue. The connection ID = is present, optional, and negotiable in the current spec and this proposal = retains those properties.

This new formulation addresses= a number of issues in the tracker however.=C2=A0

= Per my read, it closes:
#35: Starting packet number
#56: Extending flags
#119= : Server-proposed connection ID
#133:=C2=A0Connection ID in version negotia= tion
#135:=C2=A0DoS using Version Negotiation Packets
#147: Reflection= Attack Resistance
#185:=C2=A0Reliable identification of the initial pa= cket for a connection
#193: Flags section is kind of confusing
#244: Ne= ed a NONCE in version negotiation packets
#293: Does the connect= ion ID need to be in a consistent location
#295:=C2=A0Connection ID on = a version negotiation packet

And it addresses = some of:
#148: QUIC packet header complexity
#170:=C2=A0Connec= tion ID collisions

Given the number of issues it c= loses, and with the understanding that (i) this format may still change as = QUIC evolves, and (ii) we can continue the connection ID question on a sepa= rate bug/issue,=C2=A0I'd like to see if we can accept the general propo= sal as a step forward.

Does this seem reasonable? = I feel like we're moving towards editor-ready, but I am looking for a s= ignal from the chairs to indicate this.

--94eb2c07b178e887950548a9f793-- From nobody Thu Feb 16 11:01:51 2017 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 6449112969C for ; Thu, 16 Feb 2017 11:01:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.774 X-Spam-Level: X-Spam-Status: No, score=-0.774 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 ZTH7xS3CWLqb for ; Thu, 16 Feb 2017 11:01:49 -0800 (PST) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002: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 09CF7129611 for ; Thu, 16 Feb 2017 11:01:49 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id o65so6850411ybo.2 for ; Thu, 16 Feb 2017 11:01:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s2elKziOgvMt6VZtSasNSKT3q1QDhLnOmXiO/N1XST0=; b=O77gbhognusF87WIAYPP5ZXSJ2pUrUotZLP/NTb0RZGYsinpnuMeUg2kLobOp0j4nl aCzpNoYhpCsH0fjlAROTB3ZytKpdFK5EHGPxt2GbuJzpVczEHm7k8+CF2k08UcUkHt5I L7CEjtNBPLUHxyqRe01qOa4BTsefe0jqXfyzbc9yaMxc2hp5K4lhTj4yGBK76ODxgUZU GtOusXgbIWiDVRsqJODralGKJ2fiNS7Ptv3Q/JVDUfJjC9gmSH1tWSfv/nSPviQ8YJ8U OQgHR01nxd22/muYtNGbHlgeRQOPUtwPdRyzVnpKhhs3RE7B7ejghna/95V386Im7gSb A0Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s2elKziOgvMt6VZtSasNSKT3q1QDhLnOmXiO/N1XST0=; b=J+XJ80FsW4EjKRx5/++EyxTq+4Fgzn3vBDh8ZzX6YwTWiudpnEhy99Z/pK7hQ5G+mZ LkWYZjtZGu93pNC1MP6c9CVG6aT291Lkct7NPSqNYYIYAn3mI0AYreB67NE8NLl6ufIA p99HlaP/v5jo63DQu/kU/L5ec2Fk/f0EMfOg8Tlb6mJtlDnFgtfCU0MQYPCVYOySY+CF Q9U054T4Z06Bao6XX6BvswQ/7Scg6t+SBGhi1AHMP+Fz6C3jon7uVudQXw/3gZEiYllx LLnQpHDH+OzUy5vf9rlPrHpU/kFJIP0F6SQ+K3Z4zDONnVW9oovpxsf/FWE1dbq/XR26 BFoA== X-Gm-Message-State: AMke39nssyume5ZbI75HntO2lTD6DpGk9JAa4XfBopeec5tBmnu+6CCqoPD8kwU+cIDz7VhypEMs4ukD+1oQWg== X-Received: by 10.37.201.196 with SMTP id z187mr2840490ybf.161.1487271708283; Thu, 16 Feb 2017 11:01:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.13.204.80 with HTTP; Thu, 16 Feb 2017 11:01:07 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 16 Feb 2017 11:01:07 -0800 Message-ID: Subject: Re: Driving towards agreement on alternate header proposal To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a114d88eadb91820548aa6dab Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:01:50 -0000 --001a114d88eadb91820548aa6dab Content-Type: text/plain; charset=UTF-8 I, at least, would like some more time to review this proposal, given that it just appeared two days ago, so I would request that the chairs hold editor ready till it's been around at least a week -Ekr On Thu, Feb 16, 2017 at 10:28 AM, Jana Iyengar wrote: > Stepping back a bit from the weeds, there seems to be general agreement on > the shape of the header. It seems like we want to continue discussing the > connection ID issue, but I'll note that this header reformulation does not > change the status quo on that issue. The connection ID is present, > optional, and negotiable in the current spec and this proposal retains > those properties. > > This new formulation addresses a number of issues in the tracker however. > > Per my read, it closes: > #35 : Starting packet > number > #56 : Extending flags > #119 : Server-proposed > connection ID > #133 : Connection ID in > version negotiation > #135 : DoS using > Version Negotiation Packets > #147 : Reflection > Attack Resistance > #185 : Reliable > identification of the initial packet for a connection > #193 : Flags section is > kind of confusing > #244 : Need a NONCE in > version negotiation packets > #293 : Does the > connection ID need to be in a consistent location > #295 : Connection ID on > a version negotiation packet > > And it addresses some of: > #148 : QUIC packet > header complexity > #170 : Connection ID > collisions > > Given the number of issues it closes, and with the understanding that (i) > this format may still change as QUIC evolves, and (ii) we can continue the > connection ID question on a separate bug/issue, I'd like to see if we can > accept the general proposal as a step forward. > > Does this seem reasonable? I feel like we're moving towards editor-ready, > but I am looking for a signal from the chairs to indicate this. > > --001a114d88eadb91820548aa6dab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I, at least, would like some more time to review this prop= osal, given that it
just appeared two days ago, so I would request that= the chairs hold editor
ready till it's been around at least = a week

-Ekr


On Thu, Feb 16, 2017 at 1= 0:28 AM, Jana Iyengar <jri@google.com> wrote:
Stepping back a bit from the weeds, there= seems to be general agreement on the shape of the header. It seems like we= want to continue discussing the connection ID issue, but I'll note tha= t this header reformulation does not change the status quo on that issue. T= he connection ID is present, optional, and negotiable in the current spec a= nd this proposal retains those properties.

This new form= ulation addresses a number of issues in the tracker however.=C2=A0

Per my read, it closes:
#35: Starting pac= ket number
#56: Extending flags
#119: Se= rver-proposed connection ID
#133:=C2=A0Connection ID in v= ersion negotiation
#135:=C2=A0DoS using Version Nego= tiation Packets
#147: Reflection Attack Resistance
#185:=C2=A0Reliable identification of the initial packet fo= r a connection
#193: Flags section is kind of confusing
#244: Need a NONCE in version negotiation packets
#293: Does the connection ID need to be in a consi= stent location
#295:=C2=A0Connection ID on a version = negotiation packet

And it addresses some of:
#148: QUIC packet header complexity
<= a href=3D"https://github.com/quicwg/base-drafts/issues/170" target=3D"_blan= k">#170:=C2=A0Connection ID collisions

Given t= he number of issues it closes, and with the understanding that (i) this for= mat may still change as QUIC evolves, and (ii) we can continue the connecti= on ID question on a separate bug/issue,=C2=A0I'd like to see if we can = accept the general proposal as a step forward.

Doe= s this seem reasonable? I feel like we're moving towards editor-ready, = but I am looking for a signal from the chairs to indicate this.
<= br>

--001a114d88eadb91820548aa6dab-- From nobody Thu Feb 16 11:03:42 2017 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 3EA61129697 for ; Thu, 16 Feb 2017 11:03:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.876 X-Spam-Level: X-Spam-Status: No, score=-0.876 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, HTTP_ESCAPED_HOST=1.125, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 uS0FtELAnCyQ for ; Thu, 16 Feb 2017 11:03:38 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 A765B129698 for ; Thu, 16 Feb 2017 11:03:38 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id x12so16918084uax.0 for ; Thu, 16 Feb 2017 11:03:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BBaNCpqM5tIkY3gxk/PPq34sE3XRW1sAiOi1tvC2Yrk=; b=OrD0BHWlQWXDJwKJS6qKS5hKGL79GG8kNgzF0RtEONJGjnhGnISOLvmQ5emlxvI7YS I+GKE4PlZL0gv3qHqgIyp/NXcuf/SIsDe4RgLWrBk2PmftYHSuJwJAha2ABEEsoDDrmu +qh6wXLx5jADAKhjFNpMSZY84tuVEsEiZIw/L51PKo2JQzVWCRKOen8ytmYVKbC5qSA5 Btf89k8OLZg81MBZ/5KwcDglB/H0LZ9YJMK7MxT+x+bE4ug4c3CkBMzBjwXDybI912EF ShXAjT/x3BdQA3XMYKoWgmKPOPEX76o1c/sSwUthD5NU0dgyrRbhxVV1Ls/Q47JL2yCY SwCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BBaNCpqM5tIkY3gxk/PPq34sE3XRW1sAiOi1tvC2Yrk=; b=JBgVf4dzmL3wsVg5BEvmBTjyphULQJNJERmxRzrMtbVAtgc/gn61hGlYf+YWl3PJeY xvbXVgyPq6e5oLaInPPqzuwgSQwzgYen1uF8Ps0xZ4dGkweqWTLAjP7fsgEY9Ay/68Hi ZQiOo4WG+Ytw+moaXMhnapEgWU+L0WNY04O79jCVvcopV4mmF8OlUhdYNFmtcbGqwvSv GT8jv9kLuKC1cYpRypttTreBk688ddIByigF7aOCKRSv/Gcj5L+VwHGpCvgVVcytp1tJ iUcj1kkvJsY3+LpllmoDV5/Gjm8OeQZC5Rx8E2725FYWyBJgj2FQXBS7cgdoMKHOoxBm eRpQ== X-Gm-Message-State: AMke39kUuk4ktECVBL0Cphr7j6NQ/daC2sVodGDA+q1TKgEwCMI06GaW4E6nowWgmSv3m5yJ7ulXm2lwQVrOpf4H X-Received: by 10.159.40.225 with SMTP id d88mr1477643uad.98.1487271817241; Thu, 16 Feb 2017 11:03:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.51.14 with HTTP; Thu, 16 Feb 2017 11:03:36 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 16 Feb 2017 11:03:36 -0800 Message-ID: Subject: Re: Driving towards agreement on alternate header proposal To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c122be85a5bc90548aa74e9 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2017 19:03:40 -0000 --94eb2c122be85a5bc90548aa74e9 Content-Type: text/plain; charset=UTF-8 SGTM. On Thu, Feb 16, 2017 at 11:01 AM, Eric Rescorla wrote: > I, at least, would like some more time to review this proposal, given that > it > just appeared two days ago, so I would request that the chairs hold editor > ready till it's been around at least a week > > -Ekr > > > On Thu, Feb 16, 2017 at 10:28 AM, Jana Iyengar wrote: > >> Stepping back a bit from the weeds, there seems to be general agreement >> on the shape of the header. It seems like we want to continue discussing >> the connection ID issue, but I'll note that this header reformulation does >> not change the status quo on that issue. The connection ID is present, >> optional, and negotiable in the current spec and this proposal retains >> those properties. >> >> This new formulation addresses a number of issues in the tracker however. >> >> Per my read, it closes: >> #35 : Starting packet >> number >> #56 : Extending flags >> #119 : Server-proposed >> connection ID >> #133 : Connection ID >> in version negotiation >> #135 : DoS using >> Version Negotiation Packets >> #147 : Reflection >> Attack Resistance >> #185 : Reliable >> identification of the initial packet for a connection >> #193 : Flags section >> is kind of confusing >> #244 : Need a NONCE in >> version negotiation packets >> #293 : Does the >> connection ID need to be in a consistent location >> #295 : Connection ID >> on a version negotiation packet >> >> And it addresses some of: >> #148 : QUIC packet >> header complexity >> #170 : Connection ID >> collisions >> >> Given the number of issues it closes, and with the understanding that (i) >> this format may still change as QUIC evolves, and (ii) we can continue the >> connection ID question on a separate bug/issue, I'd like to see if we can >> accept the general proposal as a step forward. >> >> Does this seem reasonable? I feel like we're moving towards editor-ready, >> but I am looking for a signal from the chairs to indicate this. >> >> > --94eb2c122be85a5bc90548aa74e9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
SGTM.

On Thu, Feb 16, 2017 at 11:01 AM, Eric Rescorla <ekr@rtfm.com>= ; wrote:
I, at le= ast, would like some more time to review this proposal, given that it
j= ust appeared two days ago, so I would request that the chairs hold editor
ready till it's been around at least a week

=
-Ekr


On Thu, F= eb 16, 2017 at 10:28 AM, Jana Iyengar <jri@google.com> wrote:
Stepping back a bit from = the weeds, there seems to be general agreement on the shape of the header. = It seems like we want to continue discussing the connection ID issue, but I= 'll note that this header reformulation does not change the status quo = on that issue. The connection ID is present, optional, and negotiable in th= e current spec and this proposal retains those properties.

This new formulation addresses a number of issues in the tracker however= .=C2=A0

Per my read, it closes:
#56: Extending flags
#119: Server-proposed connection ID
#133:=C2=A0C= onnection ID in version negotiation
#135:=C2=A0DoS u= sing Version Negotiation Packets
#147: Reflection Attack = Resistance
#185:=C2=A0Reliable identification of the = initial packet for a connection
#193: Flags section is ki= nd of confusing
#244: Need a NONCE in version negotia= tion packets
#293: Does the connection ID need= to be in a consistent location
#295:=C2=A0Connection= ID on a version negotiation packet

And it add= resses some of:
#148: QUIC packet header complexity<= /div>
#170:=C2=A0Connection ID collisions

<= /div>
Given the number of issues it closes, and with the understanding = that (i) this format may still change as QUIC evolves, and (ii) we can cont= inue the connection ID question on a separate bug/issue,=C2=A0I'd like = to see if we can accept the general proposal as a step forward.
<= br>
Does this seem reasonable? I feel like we're moving towar= ds editor-ready, but I am looking for a signal from the chairs to indicate = this.



--94eb2c122be85a5bc90548aa74e9-- From nobody Thu Feb 16 17:25:54 2017 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 93D301289B0 for ; Thu, 16 Feb 2017 17:25:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9_1gnshJ9BUL for ; Thu, 16 Feb 2017 17:25:49 -0800 (PST) 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 78ED6129739 for ; Thu, 16 Feb 2017 17:25:49 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 6230422E253; Thu, 16 Feb 2017 20:25:42 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: June Interim Message-Id: Date: Fri, 17 Feb 2017 12:25:38 +1100 To: IETF QUIC WG X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Lars Eggert X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 01:25:52 -0000 Hi everyone, As mentioned before, we've requested an interim meeting for 6-8 June in = Paris: = https://github.com/quicwg/wg-materials/blob/master/interim-17-06/arrangeme= nts.md Please register using the link from that page, for either in-person or = remote participation. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Feb 17 07:20:26 2017 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 65BAD1293D9 for ; Fri, 17 Feb 2017 07:20:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ERuW3y58Gxab for ; Fri, 17 Feb 2017 07:20:22 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B024F12955B for ; Fri, 17 Feb 2017 07:20:21 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8C54D340EB3; Fri, 17 Feb 2017 16:20:19 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/19061.24053); Fri, 17 Feb 2017 16:20:19 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Fri, 17 Feb 2017 16:20:19 +0100 (CET) Received: from nb-10604.ethz.ch (account ietf@trammell.ch [82.130.102.91] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 8903710; Fri, 17 Feb 2017 16:20:19 +0100 Subject: Re: Alternate header proposal Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_9DC9CDA8-A978-4B39-BDB6-50719ADCA0CF"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Fri, 17 Feb 2017 16:20:19 +0100 Message-Id: References: To: Jana Iyengar X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 15:20:24 -0000 --Apple-Mail=_9DC9CDA8-A978-4B39-BDB6-50719ADCA0CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 16 Feb 2017, at 17:20, Jana Iyengar wrote: >=20 > On Thu, Feb 16, 2017 at 6:14 AM, Brian Trammell (IETF) = wrote: > hi Martin, all.. >=20 > (and hi Jana, I like the general approach) >=20 > trying to catch up on this thread, falling back to jump-in-randomly: >=20 > > On 16 Feb 2017, at 02:41, Martin Thomson = wrote: > > > > On 16 February 2017 at 12:39, Jana Iyengar wrote: > >> Do you have more disadvantages besides the potential of increased > >> link-ability? > > > > Bloat. We just took great paints to trim a couple of octets from = the > > packet number, saving a whole 2 octets in the best case. But > > connection ID is 8. >=20 > I remain unconvinced of the complexity/space tradeoff for the 8- and = 16-bit packet number cases. Your earlier point on handling public resets = -- >=20 > The complexity isn't high, and we save bits. In the general case, I agree, this is not complex; moving to codepoints = for header formats removes the pressure on bits for encoding packet = lengths. (Adding a high-order 32 bits for u64 packet lengths after = version negotiation is a bit more complex, but it's difficult to reason = about the cost of complexity in an environment where you might get two = billion packets of reordering...) As long as the internal packet number is a u64 and the receiver wraps = also on u8 and u16 packet numbers -- and conservativeness about = switching down to u8 and u16 packet numbers (i.e. only when there are = many fewer than 127 or 32767 in flight, respectively) is clear and = mandatory in the draft, I guess my only remaining problems with it are = purely aesthetic. :) Cheers, Brian >=20 > > Ahh, that's fine. In the case that packet number is short, I guess > > the public reset will be sending the first 2 or 3 octets of the > > payload. That's something for implementations to remember. We'll > > need special text on that. I think that it's relatively easy to > > implement that way, but it's not something that will be obvious. >=20 > -- is an excellent illustration of the point here. If we're clawing 16 = to 24 bits back only to add 64 bits on Connection ID... the value prop = goes from "questionable" to "uncompelling"... >=20 > Again, connection ID is optional in this proposal. We're not simply = adding 64 bits for everyone. I'll note again that the common packet = header size in this format will be 2-3 bytes: 1 type byte (short form) + = 1-2 bytes of packet number. >=20 > - jana >=20 > And jumping back to another message: >=20 > > (If you haven't guessed already, connection ID is the single feature > > of this protocol that I am most conflicted about. I can see so many > > advantages and so many disadvantages. They are all potentially huge > > and that means that I don't know how to make the trade-offs = sensibly.) >=20 >=20 > This might be slightly cowardly, but I share your conflict. Perhaps = the presence/absence/utility of connection ID shouldn't be a property of = QUIC's design, then, but rather a property of the applications using = QUIC. Indeed, this isn't even a thing that should always be left up to = the app developer -- there are certainly networks I would be far less = interested in increasing my trackability on than others, independent of = application. >=20 > Recommend two or three points in the space ("always" for load = balancing and rebinding, "sometimes" for load balancing and limited = rebinding, "never" for reducing traceability) and make supporting them = all MTI. >=20 >=20 >=20 > Cheers, >=20 > Brian >=20 --Apple-Mail=_9DC9CDA8-A978-4B39-BDB6-50719ADCA0CF 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 iQIcBAEBCgAGBQJYpxSzAAoJEIoSt78L6kajE6oQAIh32pES+gW8X+7eVuM5e+jE yA2593DrHQFQrX5VlKeQeJx1ACwv/qVtE3R4Ijs0M0jp4rmk9tSK8otjdbzVEvat J8DMOYU6hCIr6R1idzgSO4IGm1WaFCSVlfF+7UMVaGMRl41S1nYo3LkCRybdbjnR 4L0Of6SnVPGss55w1LDtcrLBOSq8RSTrbMayX8M7+dCfMDon6BSieOnvmsOIOsaM I4WIaMSd9PBpMTLbHuxU7JNK1VGGTKFDHaJtBVA+MQJibNUUZ4/YWPNG4rRcXnBw atRW/kN0PeVpu9dpn2XKWshU+fMrHwe8vqT/T//tebI9Qyca1AIEQxHBwennMnf8 4r5tq9BbtfBoNMOs9ccbx02VjnV/0qAaJDZcjYJG/P0rN8n5MxRRPFxrtJDzvXkm we55GTiyieQxjPUBgmpGfSIM/rXN/gxNmqSh9dvADFUOGTKcTAAYGGpdPa7GkvDr MVqFI0hm34GSgdKS6cnJ91/X9KpQqHvZEeKFzIF5zqABiKik6NHvPOD179QiOChi XZ9QRvnAhjBrHBFUWUZ1XpOEVF5RwZaoKMhVWx2YSn3xj5I7/u9Kl0gFWKUtsR27 41oP4vqIi4VG/P7TNSF+xyRfMC4VPgIPCvVrBZubylLI1B3wYRVkiRKmzhFBF07R L6XLeQBaockw+d1Ergob =LeI/ -----END PGP SIGNATURE----- --Apple-Mail=_9DC9CDA8-A978-4B39-BDB6-50719ADCA0CF-- From nobody Fri Feb 17 14:03:27 2017 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 1E26F129C0A for ; Fri, 17 Feb 2017 14:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J7qjvhR2bS58 for ; Fri, 17 Feb 2017 14:03:24 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3A9129C04 for ; Fri, 17 Feb 2017 14:03:24 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id p22so56617816qka.0 for ; Fri, 17 Feb 2017 14:03:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eRVcl5S9jpf7tL1HPR3hqmsKOh8wNIg9spsyBWJ98iM=; b=mT171Wg8i9sujvtzySIP8BZ7kGEwLR7HumSVV2tKmZd6LVkjEDAdccefTm7sfKhHPE scAQ3Gki1R2gT6F95yJzbjhf/iBfieZDMEM8x/bi0DskUMTJbH3cJ5mZqA3XCP9yHWUk siQe0nje6pg6ZvcBsz29f4uPXB6TUh7iz+PysOponLdxWqhv6Wson6QgaQUVKHZZDTZP 2zS53h+ALv/wA+k/PLNFvBnHCiopZ0BKeMTAj4Z+f6+9snbUexfe7ETS+j8YeRZ7uW6a 1c5HcC5O4A5Zw76Y9oD5L+3lxrFz1cugehHF/ATNzNl3mKTmA4P/mTobS8Z7JVnuQTo3 RClA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eRVcl5S9jpf7tL1HPR3hqmsKOh8wNIg9spsyBWJ98iM=; b=gMepgtm68r9JSvW6jl2RjxKdLcmpk7lhcoEi4svvEK1yd0pnoi40IhM+3XGpXAHCaT NX98pTrd4Ur/TNLkHWlqsppEez4uPb61hTFyNy4C8jvlgCpkKIonSdHmiQHurFN2m98X 36mHQ4rkyQQ8e2n7XBXBYuv4KMeOFznlmgunMofPIwdoeTESle2SL0deDaNGKGEHl0C9 kScA5xIwrw/AKNIVdjfh6k5D4ZbKlJuCpehxHui3oCIn+Rl8YKeO3ideCscxzrJjP4Kc rDEQKgxNnmswUt18SfdrATUDFvy8fSAW99iiVq6I++Ve2I5CtW6jmLe5NXLtyMMnj4vx k1Ow== X-Gm-Message-State: AMke39kAw5OqaQ379Pxdcg3IyacqxMJWzjs2MLsMhzQLV5PyJYTwCdXhnSg6dMEFg8M01NZZj0qavh5ToJMj+w== X-Received: by 10.233.216.68 with SMTP id u65mr9382918qkf.68.1487369003789; Fri, 17 Feb 2017 14:03:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Fri, 17 Feb 2017 14:03:23 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Sat, 18 Feb 2017 09:03:23 +1100 Message-ID: Subject: Re: Alternate header proposal To: "Brian Trammell (IETF)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Feb 2017 22:03:26 -0000 On 18 February 2017 at 02:20, Brian Trammell (IETF) wrote: > conservativeness about switching down to u8 and u16 packet numbers (i.e. only when there are many fewer than 127 or 32767 in flight, respectively) It's more conservative even than that, it's 64 and 16384 respectively right now. That could be overly conservative. The multiplier/divisor is currently 4, where I think that you could easily make a case for a lower value. It's also MUST, which I think is wrong (I thought I raised this already, but forgot apparently: https://github.com/quicwg/base-drafts/issues/323). From nobody Sat Feb 18 01:24:09 2017 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 BD27C1294EE for ; Sat, 18 Feb 2017 01:24:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 hmBguC8k_9IQ for ; Sat, 18 Feb 2017 01:24:05 -0800 (PST) Received: from brc1.unina.it (brc1.unina.it [192.132.34.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16711294E7 for ; Sat, 18 Feb 2017 01:24:04 -0800 (PST) X-ASG-Debug-ID: 1487409840-05ce370d21209730001-AtAMq9 Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by brc1.unina.it with ESMTP id wBHM22teqz6MxH7I (version=TLSv1 cipher=AES256-SHA bits=256 verify=NO); Sat, 18 Feb 2017 10:24:00 +0100 (CET) X-Barracuda-Envelope-From: spromano@unina.it X-Barracuda-Apparent-Source-IP: 192.132.34.61 Received: from [192.168.1.66] (93-44-65-253.ip96.fastwebnet.it [93.44.65.253]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id v1I9NqZZ003984 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 18 Feb 2017 10:24:00 +0100 Subject: Re: No support for multipath in QUIC? Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-ASG-Orig-Subj: Re: No support for multipath in QUIC? Content-Type: multipart/alternative; boundary="Apple-Mail=_E355BDD9-DD8E-4C97-BD61-F56A21025B7A" From: Simon Pietro Romano In-Reply-To: Date: Sat, 18 Feb 2017 10:20:13 +0100 Message-Id: <9D2D22FB-711D-46FD-AD78-C5DCBF33263C@unina.it> References: <08E13458-B861-4DFD-807F-F8497891944E@unina.it> To: Ryan Hamilton X-Mailer: Apple Mail (2.3124) X-Barracuda-Connect: smtp1.unina.it[192.132.34.61] X-Barracuda-Start-Time: 1487409840 X-Barracuda-Encrypted: AES256-SHA X-Barracuda-URL: http://192.132.34.50:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at unina.it X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=6.0 tests=BSF_SC0_MISMATCH_TO, HTML_MESSAGE X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.35465 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.00 BSF_SC0_MISMATCH_TO Envelope rcpt doesn't match header 0.00 HTML_MESSAGE BODY: HTML included in message Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Feb 2017 09:24:08 -0000 --Apple-Mail=_E355BDD9-DD8E-4C97-BD61-F56A21025B7A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Ryan, thank you for answering my question (both here and on the proto-quic = ML). It=E2=80=99s a pity that the community decided to stop the engines = (for now) on multipath. We do believe this functionality might prove of = paramount importance in a number of different scenarios. We=E2=80=99ll = definitely keep on working on that, by focusing on our (alas, non = standard) fork of the chromium code base. In the meanwhile, we=E2=80=99ll = wait for the standard extension promised by the WG. Cheers, Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it = <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > On 15 Feb 2017, at 20:03, Ryan Hamilton wrote: >=20 > The IETF QUIC Working Group is tasked with, among other things: >=20 > - Enabling multipath and forward error correction extensions;=20 >=20 > As such, I'm sure this group will eventually tackle multipath. = However, it will likely be done via an extension to the core protocol. = The experimental multipath support in Google's QUIC implementation was = not via an extension, and was never complete. Instead it was a core part = of the protocol and hence is being removed. >=20 > Cheers, >=20 > Ryan >=20 > On Wed, Feb 15, 2017 at 10:49 AM, Simon Pietro Romano = > wrote: > Hi all, >=20 > as part of a research project here at the University of Napoli, we are = working on a multipath enabled version of QUIC. Though, through = interactions with the Chromium guys on the "proto-quic=E2=80=9D mailing = list (which, as you know, is developing a code base for QUIC = implementation), we just discovered that they=E2=80=99re actively = removing the multipath code from the active repo. Does this also mean = that the QUIC wg at the IETF does not look at multipath as a desirable = functionality to be (optionally) offered by the protocol? If so, can I = dare to ask why? >=20 > Thanks a lot for your feedback, >=20 > Simon >=20 >=20 > _\\|//_ > ( O-O ) > ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ > Simon Pietro Romano > Universita' di Napoli Federico = II > Computer Engineering Department=20 > Phone: +39 081 7683823 = -- Fax: +39 081 7683816 > e-mail: spromano@unina.it = >=20 > < idioti. Ci rifletto un istante; e mi scoraggio>>. = Magritte. > oooO > ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ > \ ( = ( ) > \_) ) = / > = (_/ >=20 >=20 >=20 >=20 --Apple-Mail=_E355BDD9-DD8E-4C97-BD61-F56A21025B7A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Ryan,

thank you for answering my question (both here and on the = proto-quic ML). It=E2=80=99s a pity that the community decided to stop = the engines (for now) on multipath. We do believe this functionality = might prove of paramount importance in a number of different scenarios. = We=E2=80=99ll definitely keep on working on that, by focusing on our = (alas, non standard) fork of the chromium code base. In the meanwhile, = we=E2=80=99ll wait for the standard extension promised by the = WG.

Cheers,

Simon


          =             =   _\\|//_
      =                     =   = ( O-O )
      = ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
  =                 =    = Simon Pietro Romano
    =            Universita' di = Napoli Federico II
        =               Computer Engineering = Department 
           =   Phone: +39 081 7683823 -- Fax: +39 081 7683816
                =                     =        e-mail: spromano@unina.it

    <<Molti mi = dicono che lo scoraggiamento =C3=A8 l'alibi degli 
=     idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
      =                 =                oooO
       ~~~~~~~~~~~~~~~~~~~~~~~( =   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=               =    \ (            (   = )
=               =                   =   \_)          ) /
                =                     =                     =               =  (_/



On 15 Feb 2017, at 20:03, Ryan Hamilton <rch@google.com> = wrote:

The IETF QUIC = Working Group is tasked with, among other things:

- Enabling multipath and forward error correction = extensions; 

As such, I'm sure this = group will eventually tackle multipath. However, it will likely be done = via an extension to the core protocol. The experimental multipath = support in Google's QUIC implementation was not via an extension, and = was never complete. Instead it was a core part of the protocol and hence = is being removed.

Cheers,

Ryan

On Wed, = Feb 15, 2017 at 10:49 AM, Simon Pietro Romano <spromano@unina.it> wrote:
Hi all,

as part of a research project here at = the University of Napoli, we are working on a multipath enabled version = of QUIC. Though, through interactions with the Chromium guys on the = "proto-quic=E2=80=9D mailing list (which, as you know, is developing a = code base for QUIC implementation), we just discovered that they=E2=80=99r= e actively removing the multipath code from the active repo. Does this = also mean that the QUIC wg at the IETF does not look at multipath as a = desirable functionality to be (optionally) offered by the protocol? If = so, can I dare to ask why?

Thanks a lot for your feedback,

Simon


          =             =   _\\|//_
    =                     =     = ( O-O )
      = ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
  =                 =    = Simon Pietro Romano
    =            Universita' di = Napoli Federico II
        =               Computer Engineering = Department 
           =   Phone: +39 081 7683823 = -- Fax: +39 081 7683816
                =                     =        e-mail: spromano@unina.it

    <<Molti mi = dicono che lo scoraggiamento =C3=A8 l'alibi degli 
=     idioti. Ci rifletto un istante; e mi = scoraggio>>. Magritte.
      =           =                   =    oooO
    =    ~~~~~~~~~~~~~~~~~~~~~~~(   = )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
=               =    \ (            (   = )
=                 =                   \_) =          ) /
    =                     =                     =                     =        (_/





= --Apple-Mail=_E355BDD9-DD8E-4C97-BD61-F56A21025B7A-- From nobody Mon Feb 20 01:18:58 2017 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 B3C9B1293E1 for ; Mon, 20 Feb 2017 01:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vhYBvuYbjqQ for ; Mon, 20 Feb 2017 01:18:53 -0800 (PST) Received: from mail-wr0-x232.google.com (mail-wr0-x232.google.com [IPv6:2a00:1450:400c:c0c::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 9EB1A128B38 for ; Mon, 20 Feb 2017 01:18:53 -0800 (PST) Received: by mail-wr0-x232.google.com with SMTP id s27so13224469wrb.2 for ; Mon, 20 Feb 2017 01:18:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=from:subject:to:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=Fj5IDD19J7u/WdgHfQ5aerFUxCvouq1vrYTfZLMxKR4=; b=jxRTHPA0YOszPqZhSDWVR89cY+hwWUka3O9+w5HSxx3XHEw+TnACMFbkYIXROthL2E a28nsYjaU/kiCQbF4zMMyt1l7xH/LynbAmyCqYDKSvnZqZMPRetYQzpNSp+P7HzsLmvZ fI4uPd+vTjU32QnCTL6IYuoDbUscz2yiyVWy+VBnh6tM9izQ9bl7A9WCFb3IEqXQOhfR AXIRHS2F/zRbkn3tb924765klDPXMKvuitcHjONgsZL/NvvQHkM8XF8Sk4C0DY/ux5IN o0j7blQwrKyUAoatELiOac4WM1lsTUnZhYSzuW1Os1w1WJlv8QXcBvtRqcc/jRLNLNq8 rP2g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=Fj5IDD19J7u/WdgHfQ5aerFUxCvouq1vrYTfZLMxKR4=; b=haX/nyFeEmjgkP5zjwRrNQ+XnOiTJdTXG7Fi0abqbdVzvIehIXNtNoMhp2h3UCI2hE xzgvD5FAmJyoZXophkaM1PpXsVtRAeJxlRq1CAo6US9xImpk5Rb9rYK1q7D33DEQ1zhy F8oo+2xUPhRorccIv7miyimLOB7xdDUgkwdHujOEWhLHldPJE3fFdg/vUzfqiNXqSwC8 4J6wcCxiBr1G/WhkC9y9TB+SamWVLUAFhVQ4acktIkttmiGzKQ/PPME1EnGQkumvp//S aFlBlYHOBvRxSwpFhnlVCwY6m+DzSWXZUx7xgIeI2+zC7BNFCTuxntSwUTC4Zuc+UWGt xRDQ== X-Gm-Message-State: AMke39m5XdZv9gBVaCOFfIhNC+J8c1RY/J1SK86NKTRfTBh/AM5p7gttGmQE6zAQ4Q2vKY8W X-Received: by 10.223.165.1 with SMTP id i1mr14966352wrb.82.1487582331950; Mon, 20 Feb 2017 01:18:51 -0800 (PST) Received: from Macintosh-6.local ([2001:720:410:1010:3134:9ac:fe02:516a]) by smtp.gmail.com with ESMTPSA id o143sm12704340wmd.3.2017.02.20.01.18.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Feb 2017 01:18:51 -0800 (PST) From: marcelo bagnulo braun Subject: sending an retransmitting packets in draft-ietf-quic-recovery To: "quic@ietf.org" , draft-ietf-quic-recovery@ietf.org Message-ID: Date: Mon, 20 Feb 2017 10:18:50 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 09:18:55 -0000 Hi, I am going though the loss detection algorithm described in section 3 of draft-ietf-quic-recovery-01 and I have a question. I see that the MaybeRetransmitLostPackets() function is only called on Alarm firing. In particular, the MaybeRetransmitLostPackets() is not called when receiving in ack. Is that a mistake? I find strange that upon reception of an ACK, that determines that some packets are lost, the retransmission function is called right away but a timer is set and retransmission is triggered RTT/4 time later. Also, I guess upon ack reception, if no loss is detected but the windows moves, new data should be transmitted and while i understand that the loss detection algorithm may not be the right place to define the rules for transmitting new packets, it may be worth mentioning it. Regards, marcelo From nobody Mon Feb 20 10:58:53 2017 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 AE7271294CE for ; Mon, 20 Feb 2017 10:58:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 N2z9UEdTZKcR for ; Mon, 20 Feb 2017 10:58:50 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id BDE131294C8 for ; Mon, 20 Feb 2017 10:58:50 -0800 (PST) Received: from mail-qk0-f169.google.com (mail-qk0-f169.google.com [209.85.220.169]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3D9C13A021 for ; Mon, 20 Feb 2017 13:58:49 -0500 (EST) Received: by mail-qk0-f169.google.com with SMTP id s186so103294559qkb.1 for ; Mon, 20 Feb 2017 10:58:49 -0800 (PST) X-Gm-Message-State: AMke39mM+Lye8r98KcBqyTi1LpKX1pkJzjh+8wGbOgVcTlSkFZ9z8oWQNWijLYgQb7XOJbPx71rcC477GYJ3lw== X-Received: by 10.55.33.219 with SMTP id f88mr5952033qki.200.1487617128955; Mon, 20 Feb 2017 10:58:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.65 with HTTP; Mon, 20 Feb 2017 10:58:48 -0800 (PST) From: Patrick McManus Date: Mon, 20 Feb 2017 13:58:48 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: tcp rsts, data truncation, and the future of public reset To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1144d872888f910548fada8f Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 18:58:52 -0000 --001a1144d872888f910548fada8f Content-Type: text/plain; charset=UTF-8 Gentlefolk of QUIC-wg, I have recently been revisiting the pain of TCP RST as applied to the HTTP ecosystem. The layering between HTTP and TCP largely ignores RST and as a result this is a recurring implementation pain point. I think it bears thinking about the QUIC design - the language around close and public reset is not yet well developed. As you likely know, a received TCP RST essentially nulls out any existing connection state with a giant hammer. Sometimes this obliterates already ack'd data in socket buffers before it makes it to the application to say nothing of making retransmissions unreliable. Unfortunately, in several HTTP usage patterns TCP RST happens a lot. This leads to data truncation and information loss. I could go on at length, but a few scenarios where this has resulted in data loss are: h1 pipelines[1], h1 servers early-rejecting a large incoming message body[2], and h2 servers not knowing when it is ok to close a connection[3] TCP reset is in practice unhelpful in an http context except as a refusal to connect at all or as a signal that a peer has totally lost the state of the connection (i.e. crash). While I'm keenly aware this is an http centric view of the problem, It seems this would be a good footgun to keep out of quic. Public reset is sort of loosely defined right now so I want to give some thought to whether we are recreating the problematic use cases. 6.4 says *Abrupt Shutdown: An endpoint may send a Public Reset packet at any time during the connection to abruptly terminate an active connection. A Public Reset packet SHOULD only be used as a final recourse. Commonly, a public reset is expected to be sent when a packet on an established connection is received by an endpoint that is unable decrypt the packet. For instance, if a server reboots mid-connection and loses any cryptographic state associated with open connections, and then receives a packet on an open connection, it should send a Public Reset packet in return. (TODO: articulate rules around when a public reset should be sent.)* I think that the primary use case described by the text (lack of cryptographic state) is the only time a public reset should be used - the text should MUST that imo. First, if you've got cryptographic state - use it to send an in-connection error that can be authenticated! Second, when else would you want to RESET? TCP resets have been classically generated in conjunction with FIN state (though it seems rather implementation dependent for some cases of when this happens). Wouldn't a retransmission of a CONNECTION_CLOSE (or transmission of a new CONNECTION_CLOSE if need be) be a better response in pretty much every circumstance where you have the state of the connection (including encryption state) available? The transport document also has a todo re: TIME_WAIT (now opened as issue 328). When do you go into TIME_WAIT - as soon as CONNECTON_CLOSE is sent or when it is ack'd.. do retransmissions happen in that state? If nothing is unacked and you receive data do you just ignore it, or do you send a PUBLIC RST (I hope not - based on above) or another CONNECTION_CLOSE with an error code or...?? Obviously TIME_WAIT has scaling issues and dos implications, etc.. Given that we expect QUIC to be used in userspace applications, it would probably be good to have some text describing Thanks for any clarifying discussion. -Patrick [1] a client might send N requests in a http/1.1 pipeline, the server might serve a valid response for #1 and then close the connection (legit http behavior). As there are more requests sitting in the server's socket read buffers when it closes the connection, a RST is also generated. The client needs to be prepared to replay requests 2-N as part of the complexity of implementing pipelining, but the RST likely obliterates or truncates response #1. This unpredictability is a key element of why pipelines could not be widely deployed. [2] a client sends 1GB of data in a POST. The server knows right away it cannot deal with that - perhaps it needs authentication on the POST, perhaps it is going to issue a redirect, perhaps it has a 404 with a fancy error page. who knows. The point is nobody wants to wait or pay for the GB of data transfer. The server sends a response and closes the connection. This almost certainly generates a RST as there is data streaming in when it does so. Data does stop flowing, but when the client receives the reset it may destroy its ability to also see the error. So it basically looks like connection refused rather than a well formed http response - if the response demanded authentication for the POST then we've got a bootstrapping deadlock. [3] an h2 server, reacting to resource constraints, would like to close an active connection but it has 1 stream currently transmitting a response. So it sends a GOAWAY with an appropriate last-stream-id and then a few more data frames (completing that stream) and then a connection close. That seems 7540 compliant - but it might very well generate a RST based on WINDOW_UPDATEs or even other HEADERS that are arriving at the server. This RST in turn may very well obliterate those DATA frames on the client if they are still sitting in socket buffers when the RST arrives, or at the very least will prevent them from being retransmitted if they were lost - another form of data loss. --001a1144d872888f910548fada8f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Gen= tlefolk of QUIC-wg,

I have recently been revisiting the pain of TCP = RST as applied to the HTTP ecosystem. The layering between HTTP and TCP lar= gely ignores RST and as a result this is a recurring implementation pain po= int. I think it bears thinking about the QUIC design - the language around = close and public reset is not yet well developed.

As you likely know= , a received TCP RST essentially nulls out any existing connection state wi= th a giant hammer. Sometimes this obliterates already ack'd data in soc= ket buffers before it makes it to the application to say nothing of making = retransmissions unreliable.

Unfortunately, in several HTTP usage pa= tterns TCP RST happens a lot. This leads to data truncation and information= loss.

I could go on at length, but a few scenarios= where this has resulted in data loss are: h1 pipelines[1], h1 servers earl= y-rejecting a large incoming message body[2], and h2 servers not knowing wh= en it is ok to close a connection[3]

TCP= reset is in practice unhelpful in an http context except as a refusal to c= onnect at all or as a signal that a peer has totally lost the state of the = connection (i.e. crash).

While I'm keenly aware this is an http = centric view of the problem, It seems this would be a good footgun to keep = out of quic. Public reset is sort of loosely defined right now so I want to= give some thought to whether we are recreating the problematic use cases.<= br>
6.4 says
Abrupt Shutdown: An endpoint may send a Public = Reset packet at any time=20 during the connection to abruptly terminate an active connection. A=20 Public Reset packet SHOULD only be used as a final recourse. Commonly, a public reset is expected to be sent when a packet on an established=20 connection is received by an endpoint that is unable decrypt the packet. For instance, if a server reboots mid-connection and loses any=20 cryptographic state associated with open connections, and then receives a packet on an open connection, it should send a Public Reset packet in=20 return. (TODO: articulate rules around when a public reset should be=20 sent.)

I think that the primary use case described by the = text (lack of cryptographic state) is the only time a public reset should b= e used - the text should MUST that imo.

First, if you've g= ot cryptographic state - use it to send an in-connection error that can be = authenticated!

Second, when else would you want to RESET? TCP = resets have been classically generated in conjunction with FIN state (thoug= h it seems rather implementation dependent for some cases of when this happ= ens). Wouldn't a retransmission of a CONNECTION_CLOSE (or transmission = of a new CONNECTION_CLOSE if need be) be a better response in pretty much e= very circumstance where you have the state of the connection (including enc= ryption state) available?

The transport document also has a to= do re: TIME_WAIT (now opened as issue 328). When do you go into TIME_WAIT -= as soon as CONNECTON_CLOSE is sent or when it is ack'd.. do retransmis= sions happen in that state? If nothing is unacked and you receive data do y= ou just ignore it, or do you send a PUBLIC RST (I hope not - based on above= ) or another CONNECTION_CLOSE with an error code or...??

= Obviously TIME_WAIT has scaling issues and dos implications, etc..

<= /div>
Given that we expect QUIC to be used in userspace applications, i= t would probably be good to have some text describing

Thanks for any clarifying discussion.

-Patrick

[1] a client might send N requests in a http/1.1 pipeline, the server mig= ht serve a valid response for #1 and then close the connection (legit http = behavior). As there are more requests sitting in the server's socket re= ad buffers when it closes the connection, a RST is also generated. The clie= nt needs to be prepared to replay requests 2-N as part of the complexity of= implementing pipelining, but the RST likely obliterates or truncates respo= nse #1. This unpredictability is a key element of why pipelines could not b= e widely deployed.

[2] a client sends 1GB of data in a POST. T= he server knows right away it cannot deal with that - perhaps it needs auth= entication on the POST, perhaps it is going to issue a redirect, perhaps it= has a 404 with a fancy error page. who knows. The point is nobody wants to= wait or pay for the GB of data transfer. The server sends a response and c= loses the connection. This almost certainly generates a RST as there is dat= a streaming in when it does so. Data does stop flowing, but when the client= receives the reset it may destroy its ability to also see the error. So it= basically looks like connection refused rather than a well formed http res= ponse - if the response demanded authentication for the POST then we've= got a bootstrapping deadlock.

[3] an h2 s= erver, reacting to resource constraints, would like to close an active conn= ection but it has 1 stream currently transmitting a response. So it sends a= GOAWAY with an appropriate last-stream-id and then a few more data frames = (completing that stream) and then a connection close. That seems 7540 compl= iant - but it might very well generate a RST=C2=A0 based on WINDOW_UPDATEs = or even other HEADERS that are arriving at the server. This RST in turn may= very well obliterate those DATA frames on the client if they are still sit= ting in socket buffers when the RST arrives, or at the very least will prev= ent them from being retransmitted if they were lost - another form of data = loss.

--001a1144d872888f910548fada8f-- From nobody Mon Feb 20 13:47:44 2017 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 1C4811289C4 for ; Mon, 20 Feb 2017 13:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 ZJ10dt9fhXVG for ; Mon, 20 Feb 2017 13:47:41 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id A96521294B9 for ; Mon, 20 Feb 2017 13:47:41 -0800 (PST) Received: from mail-qk0-f180.google.com (mail-qk0-f180.google.com [209.85.220.180]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3B7DB3A0A6 for ; Mon, 20 Feb 2017 16:47:40 -0500 (EST) Received: by mail-qk0-f180.google.com with SMTP id p22so106997744qka.0 for ; Mon, 20 Feb 2017 13:47:40 -0800 (PST) X-Gm-Message-State: AMke39kDA+NnaOS1pmkG6uuulVFBsnhCR21RXC4W++w/z5/VZaYfCnZK+TlkMJ+0P7PBCE0GUbVJJ+kmStfBiA== X-Received: by 10.233.239.132 with SMTP id d126mr8300862qkg.313.1487627259910; Mon, 20 Feb 2017 13:47:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.65 with HTTP; Mon, 20 Feb 2017 13:47:39 -0800 (PST) In-Reply-To: References: From: Patrick McManus Date: Mon, 20 Feb 2017 16:47:39 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Patrick McManus Content-Type: multipart/alternative; boundary=94eb2c0354a462a4440548fd3687 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 21:47:43 -0000 --94eb2c0354a462a4440548fd3687 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 20, 2017 at 1:58 PM, Patrick McManus wrote: > I think that the primary use case described by the text (lack of > cryptographic state) is the only time a public reset should be used - the > text should MUST that imo. I've received a couple requests for clarification on this. What I mean to say is that a Public Reset mechanism for use when you don't have state/keying material (crash/reboot/long timeout) is imo fine. (this is the case the existing text imagines as its primary use). But we should limit the use of it to that case only rather than allowing its use "anytime to abruptly terminate a connection".. I think its that abruptness when applied to otherwise orderly TCP connections that has caused all the pain (and un-necessary data loss) around TCP RST. --94eb2c0354a462a4440548fd3687 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Feb 20, 2017 at 1:58 PM, Patrick McManus <pmcmanus@mozilla.com<= /a>> wrote:
I think that the pr= imary use case described by the text (lack of cryptographic state) is the o= nly time a public reset should be used - the text should MUST that imo.


I've received a= couple requests for clarification on this.

What I mean to say is that a Public Reset mechanism for use when y= ou don't have state/keying material (crash/reboot/long timeout) is imo = fine. (this is the case the existing text imagines as its primary use). But= we should limit the use of it to that case only rather than allowing its u= se "anytime to abruptly terminate a connection".. I think its tha= t abruptness when applied to otherwise orderly TCP connections that has cau= sed all the pain (and un-necessary data loss) around TCP RST.

=
--94eb2c0354a462a4440548fd3687-- From nobody Mon Feb 20 14:17:51 2017 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 C5F3F128E19 for ; Mon, 20 Feb 2017 14:17:50 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3rYk5v0KRc6L for ; Mon, 20 Feb 2017 14:17:49 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A446128874 for ; Mon, 20 Feb 2017 14:17:49 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id c85so92961180wmi.1 for ; Mon, 20 Feb 2017 14:17:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0ebLDO03zg8khMoNOmzlO/IRqWvT3PclHJ/416x7Gso=; b=dXl4s+2NWGJ+ioGUGE7NokocZMJCsxFqKRI7nOkZ73P5TLwQuhJKG9Cv4lxvoZEHx6 JFw8YYFUV1iWbfZS/QqlxJ863vIaxvsqaCJEsxdNibenOYPDuis/XFqxzP6D/apvPawF qOoHl/Iq0QT4x3oihvjRHaFaJkjsbZW39KZckpYNE/uPaeV0FJHSKKqT7c/joTS9fwkD QRRfnOQaGs8AyVzPhDNjhsCZsTY5iaw0sapKXmkN0Z2PPzICU+0lweVwUL243Y4WGJ8z Hfix5cOq79EK3Ces40LOxxCNXXhKO02YWtbD65umgvIbWgssCZuwG+l8nmUIi+ynPVOm awJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0ebLDO03zg8khMoNOmzlO/IRqWvT3PclHJ/416x7Gso=; b=fvZma3iRETre9nJX0j5id3qrAeHpHH+FZtl3b2UvZ0T2oUM9Axkdz4kqhWCVbIwquh rLAmGWoFZduQwSK/q1EHkl18qwewcZBtQt3ZofPk3hqPPtsafFyUvF/+Qvp5oQBfSKCy eYkO7bXYuoGhnF6h+DAtXUAVwpFIiL2LO1IueuMgs5ydrgRrkZ+OnONmxn2jTm/FVXn3 mHxu0mJg48+1PB/KNVGlpyw2TlRw3+DUm3nEbJdwTWljFI0QR1cOFn2UIiC/rB8FFVVR iCvqfGz2v6JmnpZMb2oAPtMLUYSUbcDvkTkLpH0Cqn/KeeBjii5Ttoh/npd8XcgdKXnR 5d4g== X-Gm-Message-State: AMke39kA5z5TAiMyW8+VvhET7KgVcOHm0X1WzZCbAHA7i+lR2Dt0FT5fH2gCJajW0IjtrJL9bXynGaehwcTGC9Y1 X-Received: by 10.28.38.2 with SMTP id m2mr20976343wmm.44.1487629067690; Mon, 20 Feb 2017 14:17:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Mon, 20 Feb 2017 14:17:46 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Mon, 20 Feb 2017 14:17:46 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Patrick McManus Content-Type: multipart/alternative; boundary=94eb2c03fb96236bed0548fda293 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 22:17:51 -0000 --94eb2c03fb96236bed0548fda293 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 20, 2017 at 1:47 PM, Patrick McManus wrote: > On Mon, Feb 20, 2017 at 1:58 PM, Patrick McManus > wrote: > >> I think that the primary use case described by the text (lack of >> cryptographic state) is the only time a public reset should be used - th= e >> text should MUST that imo. > > > > I've received a couple requests for clarification on this. > > What I mean to say is that a Public Reset mechanism for use when you don'= t > have state/keying material (crash/reboot/long timeout) is imo fine. (this > is the case the existing text imagines as its primary use). But we should > limit the use of it to that case only rather than allowing its use "anyti= me > to abruptly terminate a connection".. I think its that abruptness when > applied to otherwise orderly TCP connections that has caused all the pain > (and un-necessary data loss) around TCP RST. > =E2=80=8BYes, I completely agree. PUBLIC_RESET should only be used when the= server is unable to send an in-band CONNECTION_CLOSE. Specifically, this happens when a server receives a packet for a connection ID it does not have state for, which is neither a handshake (null-encrypted) or 0-RTT packet. In all other circumstances, an in-band CONNECTION_CLOSE is preferable. --94eb2c03fb96236bed0548fda293 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Feb 20, 2017 at 1:47 PM, Patrick McManus <pmcm= anus@mozilla.com> wrote:
On Mon, Feb 20, 2017 at 1:58 PM, Patrick McManus <pmcmanus@mozilla.com> wrote:
I think that the primary use case described by the text (lack of c= ryptographic state) is the only time a public reset should be used - the te= xt should MUST that imo.


I've received a couple requests for clarification on t= his.

What I mean to say is that a P= ublic Reset mechanism for use when you don't have state/keying material= (crash/reboot/long timeout) is imo fine. (this is the case the existing te= xt imagines as its primary use). But we should limit the use of it to that = case only rather than allowing its use "anytime to abruptly terminate = a connection".. I think its that abruptness when applied to otherwise = orderly TCP connections that has caused all the pain (and un-necessary data= loss) around TCP RST.

= =E2=80=8BYes, I completely agree. PUBLIC_RESET should only be used when the= server is unable to send an in-band CONNECTION_CLOSE. Specifically, this h= appens when a server receives a packet for a connection ID it does not have= state for, which is neither a handshake (null-encrypted) or 0-RTT packet. = In all other circumstances, an in-band CONNECTION_CLOSE is preferable.
--94eb2c03fb96236bed0548fda293-- From nobody Mon Feb 20 14:19:09 2017 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 9CB6D128E19 for ; Mon, 20 Feb 2017 14:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 C2Nlpd2JVRye for ; Mon, 20 Feb 2017 14:19:06 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CBA5128874 for ; Mon, 20 Feb 2017 14:19:06 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id u130so12588649ybb.0 for ; Mon, 20 Feb 2017 14:19:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RoFcnkWVyvTDWeB8CpbNqrMOi1g75kwMYWbTINSAJPc=; b=0prmKm4HZVLA2JldQ63ntKU/HUF/FqmpDkJiPtoKRhgh7y+LxmsnDMECQKfA1132hJ mJRucjx7x3T14+pyWDTjTOgRCBk+4QDUqx74ktOgi9Xo3NoB83GVlqrFwqxofCR4hSb+ DPuxZ4DrZsb8TOvDRS1iOF+/hbwcVpzdI+fzfz2spUxSXxffkHTVjWH42ZlhfZsGZmly fqxXubAYeIT+k0z4szbpjQw4s0/GUiNV1X0SVG32GLxVrBW2sMxiqurJ/zInSw5G10Mi d5PmcVK4nYBcd2BVl38l/7XcVLNbkkylC7lCsB/Jyup4hAFsybZEUayB7qJEma0qr6ey E40A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RoFcnkWVyvTDWeB8CpbNqrMOi1g75kwMYWbTINSAJPc=; b=nUSQ2+xibeT+xaWghdJrLI4f5c6sSZhfumVLgCLtnP+tz5/sIozJu37XNggKATzWz+ uBtURRQrXuHKGSC2NXA04vnU9adIz66NHtK593AIkzialaXhD/SVc3H6DBkLaOmWqxQY DM96FGDHclVDWz3HV8lzqzeomtQrpiD/vB/JZ98UAfCPEu5mZmMm4CDQKvmkpH8tQygo yuiBYilyhR9HswFwka3p7TsnRyG1Kq0as6DWeUlKB6CcP9csaeSAdZ7uZb6HJUMxJo4c /VD57tdzYEdIPMa8MQQTxBlJa5zhvhnZMJpf9Bs1/ysNRisnFNpwYgThX50LOZgzWpqA KLQg== X-Gm-Message-State: AMke39nhoc1Y+BLGDdNNvidwAyNdv3l6fVSyF8cC5kYtd2pvRzMWUy5wDTzNvnZF9eYc+wQFUGX9HtySWBTEvA== X-Received: by 10.37.78.3 with SMTP id c3mr17415076ybb.180.1487629145495; Mon, 20 Feb 2017 14:19:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.153.200 with HTTP; Mon, 20 Feb 2017 14:18:24 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Mon, 20 Feb 2017 14:18:24 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Ryan Hamilton Content-Type: multipart/alternative; boundary=001a113e7faec6892e0548fda6f0 Archived-At: Cc: IETF QUIC WG , Patrick McManus X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 22:19:07 -0000 --001a113e7faec6892e0548fda6f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I agree as well. On Mon, Feb 20, 2017 at 2:17 PM, Ryan Hamilton wrote: > > On Mon, Feb 20, 2017 at 1:47 PM, Patrick McManus > wrote: > >> On Mon, Feb 20, 2017 at 1:58 PM, Patrick McManus >> wrote: >> >>> I think that the primary use case described by the text (lack of >>> cryptographic state) is the only time a public reset should be used - t= he >>> text should MUST that imo. >> >> >> >> I've received a couple requests for clarification on this. >> >> What I mean to say is that a Public Reset mechanism for use when you >> don't have state/keying material (crash/reboot/long timeout) is imo fine= . >> (this is the case the existing text imagines as its primary use). But we >> should limit the use of it to that case only rather than allowing its us= e >> "anytime to abruptly terminate a connection".. I think its that abruptne= ss >> when applied to otherwise orderly TCP connections that has caused all th= e >> pain (and un-necessary data loss) around TCP RST. >> > > =E2=80=8BYes, I completely agree. PUBLIC_RESET should only be used when t= he server > is unable to send an in-band CONNECTION_CLOSE. Specifically, this happens > when a server receives a packet for a connection ID it does not have stat= e > for, which is neither a handshake (null-encrypted) or 0-RTT packet. In al= l > other circumstances, an in-band CONNECTION_CLOSE is preferable. > --001a113e7faec6892e0548fda6f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree as well.


On Mon, Feb 20, 2017 at 2:17 PM, Ryan = Hamilton <rch@google.com> wrote:

On Mon, Feb 20, 2017 at 1:47 PM, Patrick McManus= <pmcmanus@mozilla.com> wrote:
On Mon, Feb 20, 2017 at 1:= 58 PM, Patrick McManus <pmcmanus= @mozilla.com> wrote:
I thin= k that the primary use case described by the text (lack of cryptographic st= ate) is the only time a public reset should be used - the text should MUST = that imo.


I've received a couple requests for clarification on this.

What I mean to say is that a Public Reset mech= anism for use when you don't have state/keying material (crash/reboot/l= ong timeout) is imo fine. (this is the case the existing text imagines as i= ts primary use). But we should limit the use of it to that case only rather= than allowing its use "anytime to abruptly terminate a connection&quo= t;.. I think its that abruptness when applied to otherwise orderly TCP conn= ections that has caused all the pain (and un-necessary data loss) around TC= P RST.

=E2= =80=8BYes, I completely agree. PUBLIC_RESET should only be used when the se= rver is unable to send an in-band CONNECTION_CLOSE. Specifically, this happ= ens when a server receives a packet for a connection ID it does not have st= ate for, which is neither a handshake (null-encrypted) or 0-RTT packet. In = all other circumstances, an in-band CONNECTION_CLOSE is preferable.

--001a113e7faec6892e0548fda6f0-- From nobody Mon Feb 20 14:25:38 2017 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 E38D71293F8 for ; Mon, 20 Feb 2017 14:25:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SNBQJ5YA_g2G for ; Mon, 20 Feb 2017 14:25:36 -0800 (PST) Received: from gozo.iway.ch (gozo.iway.ch [IPv6:2001:8e0:40:325::36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC3C129406 for ; Mon, 20 Feb 2017 14:25:35 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 293323406CF; Mon, 20 Feb 2017 23:25:33 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/19061.2753); Mon, 20 Feb 2017 23:25:33 +0100 (CET) Received: from switchplus-mail.ch (switchplus-mail.ch [212.25.8.236]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gozo.iway.ch (Postfix) with ESMTPS; Mon, 20 Feb 2017 23:25:33 +0100 (CET) Received: from [94.247.222.80] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.14) with ESMTPSA id 9145848; Mon, 20 Feb 2017 23:25:33 +0100 Subject: Re: tcp rsts, data truncation, and the future of public reset Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/signed; boundary="Apple-Mail=_937A2A99-A048-484D-816F-94128AB0CB6B"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail From: "Brian Trammell (IETF)" In-Reply-To: Date: Mon, 20 Feb 2017 23:25:31 +0100 Message-Id: <4BA6847B-3D7C-42D9-88A2-032F8E74D099@trammell.ch> References: To: Ryan Hamilton X-Mailer: Apple Mail (2.3124) Archived-At: Cc: IETF QUIC WG , Patrick McManus X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 22:25:38 -0000 --Apple-Mail=_937A2A99-A048-484D-816F-94128AB0CB6B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 +1 (We'd talked about overloading reset for exposing end of connection. = Some exposure of CONNECTION_CLOSE in the public header for state = management purposes would be useful, but that's an entirely separate = issue, and should be solved in a separate way.) Cheers, Brian > On 20 Feb 2017, at 23:17, Ryan Hamilton wrote: >=20 >=20 > On Mon, Feb 20, 2017 at 1:47 PM, Patrick McManus = wrote: > On Mon, Feb 20, 2017 at 1:58 PM, Patrick McManus = wrote: > I think that the primary use case described by the text (lack of = cryptographic state) is the only time a public reset should be used - = the text should MUST that imo. >=20 >=20 > I've received a couple requests for clarification on this. >=20 > What I mean to say is that a Public Reset mechanism for use when you = don't have state/keying material (crash/reboot/long timeout) is imo = fine. (this is the case the existing text imagines as its primary use). = But we should limit the use of it to that case only rather than allowing = its use "anytime to abruptly terminate a connection".. I think its that = abruptness when applied to otherwise orderly TCP connections that has = caused all the pain (and un-necessary data loss) around TCP RST. >=20 > =E2=80=8BYes, I completely agree. PUBLIC_RESET should only be used = when the server is unable to send an in-band CONNECTION_CLOSE. = Specifically, this happens when a server receives a packet for a = connection ID it does not have state for, which is neither a handshake = (null-encrypted) or 0-RTT packet. In all other circumstances, an in-band = CONNECTION_CLOSE is preferable. --Apple-Mail=_937A2A99-A048-484D-816F-94128AB0CB6B 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 iQIcBAEBCgAGBQJYq2zcAAoJEIoSt78L6kajtMEP/jr9XfKV/GQfi9dL2N17Ex/Y JUOCALPnNpy4QFRU18hrbOnB6+YdHGKDcvtxbQMhJm88H6Lc+Oejye8Mymg/z5Ec GSQ8uxTEphIzNbyqhgIpFr92HacY0LYkAtri3Qc04OiPotaFxw/UNmGIkwr/8bG1 35p9q3tNQgzKJz6paodKdnr98gDhee1NFRsPAKmWcBg9DVxWun+8LdniWD64yJGH tOXT1ZBSy3F/XtMqYeeeYMClXR/RAiw78vJPhwkL7mHom4m6BkwC5Al1MOczE4yW Ng4CICxB16D5YLbtcx9EPJUAaze2PmcwPZBHdw+56/aflhx35M+xTK8sY1s2fdqK UUQwKVeENTrUsHiRc5qk6pdtUwDrspJK7MMRb7wFbcPRRJYVUC6+VhdnOT1vLfK3 mFUjjkWVBxrYdbS0UJEcwhSSBiyj3yAtghKrngaA8zaZvSHJZqVw/+U+euf9XPAE xDTIumjZmNAaqZ8HFB+HWdkG5ukYzCvMhYugRP7bjhwj4wNNIFyBMEDDtd9fiflS SXlweanASneb8H4CD0BzMl1Q8sKzmXf1arD6Mn4lj11u86DM25pS2R6JCPYkOE5Q eY33/eRLZdHHvapmWjuHiOSHGzYFdFjeuAu9I8aYYOxxB8fvklxInPLla8J4Lh59 xK/X7WbvU7IMYHaAdLoy =By+x -----END PGP SIGNATURE----- --Apple-Mail=_937A2A99-A048-484D-816F-94128AB0CB6B-- From nobody Mon Feb 20 14:35:45 2017 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 3E5D51289C4 for ; Mon, 20 Feb 2017 14:35:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qK9Nj0oNdhZ4 for ; Mon, 20 Feb 2017 14:35:42 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 9EDE11293DC for ; Mon, 20 Feb 2017 14:35:38 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id 40so470886uau.2 for ; Mon, 20 Feb 2017 14:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jAoN1PMoepH9tsGllEOhCfkKiihqKqeANwMbO11VD8s=; b=a7ugmWYfTFnoN95iqf5uU5dtcFZzGEslgSg0gmIHYcqbSUmKc2PuxHN8tta9BgjRbY ZpT0+hzxsJVyI1fH1ZwnmDc+BBsIwgMEwvYjIei5AOJm7BxG8mWqzR1U8xhOBF8SQMVX O/3Nks4/knhKujrdw9eMq5UaqlKBqibed+s7EF2pCY/NYCDbpbmJ97zeDLFh795RPU2E ygV5HMALL0TnJIpLiRzByxSa1Txkii0ZmhTxBK8OYnzrf0bwxeyoHrQaA6KoooDPiL3z SSdJF7l01vZTWxlZQAeDppJ0HdiA1HE+NVdr+zJ2C4uDJ2v2zNhVRSpqFaCOyKz6rIzI oiiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jAoN1PMoepH9tsGllEOhCfkKiihqKqeANwMbO11VD8s=; b=QKbC8sYRKPRt0uzk7FL+EKWSveRGPDEX1WAPLr/+a8C8VXuAhIWl6WU+xsqnd35z+0 w7pxvLpHnh89L5/1cI5IdcAMTD4sZkLHlhGIgnkdyXkSQgrzmixEneJLkgd4jRno6KKu KKtrfW1ZKE4VBvFpQwH0i3gQBkWm4fT/Doc5uRBV0BC60CgXHhogxoSam7hWh0Kf4iIL kskUgmnLWQakbSvx6AgGJg6+SQ/iKnLZTWRaMIlnvH3SM6DZ5lDF92t89JaP0//XSVM5 xUaUAEMYr5SwdLaQhb3aXb8+ogSK0lEtEBF3RmwDYBQdOT0HvVaEuO7Cja4eEH2gEANs iDfQ== X-Gm-Message-State: AMke39mtO2hlyoavRXoua/QPXh3XIgmKu+jKEuYhvGGHV5qucYxTZEaKwrcpyIGcOtaXrgFLQUQgxpP6SYBW+ir1 X-Received: by 10.159.48.22 with SMTP id h22mr1437667uab.13.1487630137310; Mon, 20 Feb 2017 14:35:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Mon, 20 Feb 2017 14:35:36 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Mon, 20 Feb 2017 14:35:36 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Eric Rescorla Content-Type: multipart/alternative; boundary=f403045e3664e518740548fde1f0 Archived-At: Cc: IETF QUIC WG , Patrick McManus , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2017 22:35:43 -0000 --f403045e3664e518740548fde1f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Completely agree. In the case of TCP, the stack simply follows the application directive (shutdown() vs close()), and at the receiver there's no way to know whether the applciation at the other end caused it or if the stack lost state. QUIC can make this difference explicit by never emitting a PUBLIC_RESET except when connection state is absent. That is indeed the goal of this signal, and we should make it more explicit and concrete in the draft where possible. On the point of what to do in TIME_WAIT, the server should hang on to some state. At the least, hanging on to the connection ID protects the server by preventing late packets from causing creation of new connection state, and the server can simply discard incoming packets for connection IDs in TIME_WAIT. (If a server wanted to hang on to more state, it could do so, allowing it to retransmit CONNECTION_CLOSE frames later, but as you note, this is more state and I wouldn't require it.) On Mon, Feb 20, 2017 at 2:18 PM, Eric Rescorla wrote: > I agree as well. > > > On Mon, Feb 20, 2017 at 2:17 PM, Ryan Hamilton wrote: > >> >> On Mon, Feb 20, 2017 at 1:47 PM, Patrick McManus >> wrote: >> >>> On Mon, Feb 20, 2017 at 1:58 PM, Patrick McManus >>> wrote: >>> >>>> I think that the primary use case described by the text (lack of >>>> cryptographic state) is the only time a public reset should be used - = the >>>> text should MUST that imo. >>> >>> >>> >>> I've received a couple requests for clarification on this. >>> >>> What I mean to say is that a Public Reset mechanism for use when you >>> don't have state/keying material (crash/reboot/long timeout) is imo fin= e. >>> (this is the case the existing text imagines as its primary use). But w= e >>> should limit the use of it to that case only rather than allowing its u= se >>> "anytime to abruptly terminate a connection".. I think its that abruptn= ess >>> when applied to otherwise orderly TCP connections that has caused all t= he >>> pain (and un-necessary data loss) around TCP RST. >>> >> >> =E2=80=8BYes, I completely agree. PUBLIC_RESET should only be used when = the >> server is unable to send an in-band CONNECTION_CLOSE. Specifically, this >> happens when a server receives a packet for a connection ID it does not >> have state for, which is neither a handshake (null-encrypted) or 0-RTT >> packet. In all other circumstances, an in-band CONNECTION_CLOSE is >> preferable. >> > > --f403045e3664e518740548fde1f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Completely agree.=C2=A0

In the case of = TCP, the stack simply follows the application directive (shutdown() vs clos= e()), and at the receiver there's no way to know whether the applciatio= n at the other end caused it or if the stack lost state. QUIC can make this= difference explicit by never emitting a PUBLIC_RESET except when connectio= n state is absent. That is indeed the goal of this signal, and we should ma= ke it more explicit and concrete in the draft where possible.

On the point of what to do in TIME_WAIT, the server should hang on to= some state. At the least, hanging on to the connection ID protects the ser= ver by preventing late packets from causing creation of new connection stat= e, and the server can simply discard incoming packets for connection IDs in= TIME_WAIT. (If a server wanted to hang on to more state, it could do so, a= llowing it to retransmit CONNECTION_CLOSE frames later, but as you note, th= is is more state and I wouldn't require it.)

On Mon, Feb 20, 2017 at 2:= 18 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I agree as well.


On Mon, Feb 20, 2017 at 2:17 PM, Ryan Hamilton <rch@google= .com> wrote:

On Mon, Feb 20, 2017 at 1:47 PM, Patrick McM= anus <pmcm= anus@mozilla.com> wrote:
= On Mon, Feb 20, 2017 at 1:58 PM, Patrick McManus <pmcmanus@mozilla.com>= wrote:
I think that the primary use case= described by the text (lack of cryptographic state) is the only time a pub= lic reset should be used - the text should MUST that imo.


I've received a couple= requests for clarification on this.

What I mean to say is that a Public Reset mechanism for use when you don&= #39;t have state/keying material (crash/reboot/long timeout) is imo fine. (= this is the case the existing text imagines as its primary use). But we sho= uld limit the use of it to that case only rather than allowing its use &quo= t;anytime to abruptly terminate a connection".. I think its that abrup= tness when applied to otherwise orderly TCP connections that has caused all= the pain (and un-necessary data loss) around TCP RST.

=E2=80=8BYes, I completely agree= . PUBLIC_RESET should only be used when the server is unable to send an in-= band CONNECTION_CLOSE. Specifically, this happens when a server receives a = packet for a connection ID it does not have state for, which is neither a h= andshake (null-encrypted) or 0-RTT packet. In all other circumstances, an i= n-band CONNECTION_CLOSE is preferable.


--f403045e3664e518740548fde1f0-- From nobody Mon Feb 20 19:48:49 2017 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 3F3621299C8 for ; Mon, 20 Feb 2017 19:48:49 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 bnkJbeok8C1B for ; Mon, 20 Feb 2017 19:48:47 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id ADC101299BF for ; Mon, 20 Feb 2017 19:48:47 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 08104433422; Tue, 21 Feb 2017 03:48:47 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id E2F88433408; Tue, 21 Feb 2017 03:48:46 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487648926; bh=C7u1QYdezK2XGh7HRPjdclkJyA5SRKUeXPNnGYHt/gI=; l=10317; h=From:To:CC:Date:References:In-Reply-To:From; b=t5imXmLm/pZeaHDm63521EOfgzhHpZKfluwk1v026rMfDS9e/za0w49m+iCLrBCZG c83l5xUDICBQKOGk2B6+36Fv4s9qpi+o2poBPJGPhrsRObJQVOrlngqwYSkAjFUuLl U9zJCWR9XKz/BGdXcuR9SUjYNwZKQP2+PhWa9z68= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id DD2B51FC96; Tue, 21 Feb 2017 03:48:46 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 20 Feb 2017 22:48:46 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Mon, 20 Feb 2017 22:48:46 -0500 From: "Lubashev, Igor" To: "ekr@rtfm.com" , "jri@google.com" Subject: RE: tcp rsts, data truncation, and the future of public reset Thread-Topic: tcp rsts, data truncation, and the future of public reset Thread-Index: AQHSi6tjprq3SA28S0CynFHnEtJTgKFy0yeAgAAIagCAAAAtAIAABM8A///y6r4= Date: Tue, 21 Feb 2017 03:48:46 +0000 Message-ID: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_866396fe7d31416e9e57b0d0500c87f1usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "quic@ietf.org" , "pmcmanus@mozilla.com" , "rch@google.com" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 03:48:49 -0000 --_000_866396fe7d31416e9e57b0d0500c87f1usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also agree that other alternatives are strongly preferred to PUBLIC RESET= . However, I am worried about making it a MUST in this case. First, a MUST leaves no wiggle room for unforeseen circumstances (see below= ). Second, it is easy to circumvent this MUST by deliberately losing all co= nnection state (or just crypto state) and then immediately sending PUBLIC R= ESET (because I no longer have the state). We can probably find a way to always avoid PUBLIC RESET when designing appl= ication protocols, since QUIC still allows the application to Reset individ= ual streams (and those resets are not subject to connection-level flow cont= rol). But what do you do about a poorly designed application protocol that = cannot solve some problem with a neat stream reset (assume you cannot updat= e the application protocol on both peers quickly)? Would you want to force = applications not to use PUBLIC RESET as a last resort workaround? - Igor -----Original Message----- From: Jana Iyengar [jri@google.com] Received: Monday, 20 Feb 2017, 5:35PM To: Eric Rescorla [ekr@rtfm.com] CC: IETF QUIC WG [quic@ietf.org]; Patrick McManus [pmcmanus@mozilla.com]; R= yan Hamilton [rch@google.com] Subject: Re: tcp rsts, data truncation, and the future of public reset Completely agree. In the case of TCP, the stack simply follows the application directive (shu= tdown() vs close()), and at the receiver there's no way to know whether the= applciation at the other end caused it or if the stack lost state. QUIC ca= n make this difference explicit by never emitting a PUBLIC_RESET except whe= n connection state is absent. That is indeed the goal of this signal, and w= e should make it more explicit and concrete in the draft where possible. On the point of what to do in TIME_WAIT, the server should hang on to some = state. At the least, hanging on to the connection ID protects the server by= preventing late packets from causing creation of new connection state, and= the server can simply discard incoming packets for connection IDs in TIME_= WAIT. (If a server wanted to hang on to more state, it could do so, allowin= g it to retransmit CONNECTION_CLOSE frames later, but as you note, this is = more state and I wouldn't require it.) On Mon, Feb 20, 2017 at 2:18 PM, Eric Rescorla > wrote: I agree as well. On Mon, Feb 20, 2017 at 2:17 PM, Ryan Hamilton > wrote: On Mon, Feb 20, 2017 at 1:47 PM, Patrick McManus > wrote: On Mon, Feb 20, 2017 at 1:58 PM, Patrick McManus > wrote: I think that the primary use case described by the text (lack of cryptograp= hic state) is the only time a public reset should be used - the text should= MUST that imo. I've received a couple requests for clarification on this. What I mean to say is that a Public Reset mechanism for use when you don't = have state/keying material (crash/reboot/long timeout) is imo fine. (this i= s the case the existing text imagines as its primary use). But we should li= mit the use of it to that case only rather than allowing its use "anytime t= o abruptly terminate a connection".. I think its that abruptness when appli= ed to otherwise orderly TCP connections that has caused all the pain (and u= n-necessary data loss) around TCP RST. ?Yes, I completely agree. PUBLIC_RESET should only be used when the server = is unable to send an in-band CONNECTION_CLOSE. Specifically, this happens w= hen a server receives a packet for a connection ID it does not have state f= or, which is neither a handshake (null-encrypted) or 0-RTT packet. In all o= ther circumstances, an in-band CONNECTION_CLOSE is preferable. --_000_866396fe7d31416e9e57b0d0500c87f1usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I also agree that other alternatives are strongly preferre= d to PUBLIC RESET. However, I am worried about making it a MUST in this cas= e.

First, a MUST leaves no wiggle room for unforeseen circumstances (see below= ). Second, it is easy to circumvent this MUST by deliberately losing all co= nnection state (or just crypto state) and then immediately sending PUBLIC R= ESET (because I no longer have the state).

We can probably find a way to always avoid PUBLIC RESET when designing appl= ication protocols, since QUIC still allows the application to Reset individ= ual streams (and those resets are not subject to connection-level flow cont= rol). But what do you do about a poorly designed application protocol that cannot solve some problem with a= neat stream reset (assume you cannot update the application protocol on bo= th peers quickly)? Would you want to force applications not to use PUBLIC R= ESET as a last resort workaround?

- Igor

-----Original Message-----
From: Jana Iyengar [jri@google.com]
Received: Monday, 20 Feb 2017, 5:35PM
To: Eric Rescorla [ekr@rtfm.com]
CC: IETF QUIC WG [quic@ietf.org]; Patrick McManus [pmcmanus@mozilla.= com]; Ryan Hamilton [rch@google.com]
Subject: Re: tcp rsts, data truncation, and the future of public res= et
Completely agree. 

In the case of TCP, the stack simply follows the application directive= (shutdown() vs close()), and at the receiver there's no way to know whethe= r the applciation at the other end caused it or if the stack lost state. QU= IC can make this difference explicit by never emitting a PUBLIC_RESET except when connection state is absent. T= hat is indeed the goal of this signal, and we should make it more explicit = and concrete in the draft where possible.

On the point of what to do in TIME_WAIT, the server should hang on to = some state. At the least, hanging on to the connection ID protects the serv= er by preventing late packets from causing creation of new connection state= , and the server can simply discard incoming packets for connection IDs in TIME_WAIT. (If a server wanted to h= ang on to more state, it could do so, allowing it to retransmit CONNECTION_= CLOSE frames later, but as you note, this is more state and I wouldn't requ= ire it.)

On Mon, Feb 20, 2017 at 2:18 PM, Eric Rescorla <= span dir=3D"ltr"> <ekr@rtfm.com><= /span> wrote:
I agree as well.


On Mon, Feb 20, 2017 at 2:17 PM, Ryan Hamilton <= span dir=3D"ltr"> <rch@google.com&= gt; wrote:

On Mon, Feb 20, 2017 at 1:47 PM, Pa= trick McManus <pmcmanus@= mozilla.com> wrote:
On Mon, Feb 20, 2017 at 1:58 PM, Patrick McManus= <pmcmanus@mozilla.com>= ; wrote:
I think that the primary use case described by the text (lack of cryptograp= hic state) is the only time a public reset should be used - the text should= MUST that imo.
I've received a couple requests for clarificatio= n on this.

What I mean to say is that a Public Reset mechan= ism for use when you don't have state/keying material (crash/reboot/long ti= meout) is imo fine. (this is the case the existing text imagines as its pri= mary use). But we should limit the use of it to that case only rather than allowing its use "anytime to = abruptly terminate a connection".. I think its that abruptness when ap= plied to otherwise orderly TCP connections that has caused all the pain (an= d un-necessary data loss) around TCP RST.

​Yes, I completely agree. PUBLIC_RESET should only be use= d when the server is unable to send an in-band CONNECTION_CLOSE. Specifical= ly, this happens when a server receives a packet for a connection ID it does not have state for, which is neither a handshake (= null-encrypted) or 0-RTT packet. In all other circumstances, an in-band CON= NECTION_CLOSE is preferable.


--_000_866396fe7d31416e9e57b0d0500c87f1usma1exdag1mb5msgcorpak_-- From nobody Mon Feb 20 21:31:42 2017 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 E18EF12944B for ; Mon, 20 Feb 2017 21:31:40 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Nofmfxp-yrT1 for ; Mon, 20 Feb 2017 21:31:39 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76A05129460 for ; Mon, 20 Feb 2017 21:31:39 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id c85so99293064wmi.1 for ; Mon, 20 Feb 2017 21:31:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tsnIcAHqXXxJn6sBUCf15iRuL1i8+9e3W+FiA417kA8=; b=lF2oJIOx1jpN9SDVddlNz7hqCawHYkEY2aG0S1LqEiL+Ehzg4/WaCGplI10LBwXdnX hAqEO0X2gH3hdaVWJ92loRtoZiewbPc8X4Pq7AqEO9JmFjegWjBaejJqxiN0UpVbJ+no K9XTYv8scU2VKYp5tR92Y1sb4VLGg+NKEl3gg0aYd6RzTbmfeSGloKDQCmj2JHKQBrtZ wU/bdX3W2CimnI2d6u7FewwsD2WrRPKvhnK3FSY/cmnBdeHbVC8XIPjerkSunE0vC50r 7S81uEhseNbS4gJTWMxYMrCLxeYBnx2K1itUliHutiw8ZOpISu5gyWcCe2CeutOrKRyR 1JfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tsnIcAHqXXxJn6sBUCf15iRuL1i8+9e3W+FiA417kA8=; b=TRsA1WSvNgNYbK857bQXDKRj0K3hvCrnkKoIeQKisFNc31/KhfMRupZWwKumk2rfzF ctqYqvVZTU049l/SKcLn3A2hdH0Lu4KpxfKlEFxuU0Dh7dx67CzWWRy7jQNCYGYKTl5m x1rP86KR9SqXA15iQFyspZdY1b7fnviuK0SnXgJcWlUpm3UYr7EVdCJQWThihRwvWsta N4g2uu0w2OJEMgN+DDQ0NGTfrheQzGdGJB3x0DYYRE2HsyRxeQxFMLQnBvVJG8CE1z2O azrlgv7X3ZMmfcMErRGlZhvDV29WdXkj3gkH1GJhcPQsHbWbC1FQ4V17S5EKBgaQUEEJ 2jxQ== X-Gm-Message-State: AMke39nvu/D4st/u72Q/FLKrxLhldcuLuUkjujwc05UlbDmDsGrCj4zjOt232vitEGszKn/5T6fUIpVvOYp6H1Bl X-Received: by 10.28.103.3 with SMTP id b3mr20986242wmc.99.1487655097777; Mon, 20 Feb 2017 21:31:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Mon, 20 Feb 2017 21:31:37 -0800 (PST) In-Reply-To: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ryan Hamilton Date: Mon, 20 Feb 2017 21:31:37 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: "Lubashev, Igor" Content-Type: multipart/alternative; boundary=001a114a91b2a7377d054903b1d6 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "quic@ietf.org" , "pmcmanus@mozilla.com" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 05:31:41 -0000 --001a114a91b2a7377d054903b1d6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 20, 2017 at 7:48 PM, Lubashev, Igor wrote= : > I also agree that other alternatives are strongly preferred to PUBLIC > RESET. However, I am worried about making it a MUST in this case. > > First, a MUST leaves no wiggle room for unforeseen circumstances (see > below). Second, it is easy to circumvent this MUST by deliberately losing > all connection state (or just crypto state) and then immediately sending > PUBLIC RESET (because I no longer have the state). > > We can probably find a way to always avoid PUBLIC RESET when designing > application protocols, since QUIC still allows the application to Reset > individual streams (and those resets are not subject to connection-level > flow control). But what do you do about a poorly designed application > protocol that cannot solve some problem with a neat stream reset (assume > you cannot update the application protocol on both peers quickly)? Would > you want to force applications not to use PUBLIC RESET as a last resort > workaround? =E2=80=8BI don't think I understand how the use of CONNECTION_CLOSE is any different to an application than PUBLIC_RESET? Under what circumstances would an application protocol (admittedly a poorly designed one) work if a PUBLIC_RESET were used, but would not work if a CONNECTION_CLOSED were?=E2= =80=8B --001a114a91b2a7377d054903b1d6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Feb 20, 2017 at 7:48 PM, Lubashev, Igor <ilubas= he@akamai.com> wrote:
I also agree that other alternatives are strongly preferred to PU= BLIC RESET. However, I am worried about making it a MUST in this case.

First, a MUST leaves no wiggle room for unforeseen circumstances (see below= ). Second, it is easy to circumvent this MUST by deliberately losing all co= nnection state (or just crypto state) and then immediately sending PUBLIC R= ESET (because I no longer have the state).

We can probably find a way to always avoid PUBLIC RESET when designing appl= ication protocols, since QUIC still allows the application to Reset individ= ual streams (and those resets are not subject to connection-level flow cont= rol). But what do you do about a poorly designed application protocol that cannot solve some problem with a= neat stream reset (assume you cannot update the application protocol on bo= th peers quickly)? Would you want to force applications not to use PUBLIC R= ESET as a last resort workaround?

=E2=80=8BI don't think I understand how the use of CONNECTION_CLOS= E is any different to an application than PUBLIC_RESET? Under what circumst= ances would an application protocol (admittedly a poorly designed one) work= if a PUBLIC_RESET were used, but would not work if a CONNECTION_CLOSED wer= e?=E2=80=8B
--001a114a91b2a7377d054903b1d6-- From nobody Mon Feb 20 23:40:38 2017 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 0DF56129873 for ; Mon, 20 Feb 2017 23:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXOvAJjdeIe4 for ; Mon, 20 Feb 2017 23:40:34 -0800 (PST) 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 D6DEC129416 for ; Mon, 20 Feb 2017 23:40:33 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id r141so68481798wmg.1 for ; Mon, 20 Feb 2017 23:40:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding; bh=qzsO4qH/5RWCTsxQFwmw5bUwLpMIr/mESr6HrXXRse4=; b=ds6A27DzmPSMookjfUpLgwT6Nu80mwy27rY00JbjBQEIy4G7/yC1ZauuuNpqixOBvJ ukiPuOelr80tNQQ4R14At4LmUW7kBveDYDFisjeAW3zHhHGnBok61jlcAcSGgwO/71H4 MaV0+fdpDNVpSExdqtt71NEciy9eKyykkCmDD4qyS5w112QHiyu133kw157E0Tt5SGO/ JVNDm/kd2ZbkoWNrxFpVkBZCSMBq7ubOK0alTUiVqk5tDaxF1fTPhiHkMQH5FcSYER/S +yPyhCKO7fb5qfnPdR6/Yo4zUag1hBi4FDkirAIGZSMSAanztDhD3Bs6+Hs9iejjyWbf NyDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding; bh=qzsO4qH/5RWCTsxQFwmw5bUwLpMIr/mESr6HrXXRse4=; b=SUqeGvxBK00+/6nIpmyilm2jmwsl0bEel4oC3CVuSujSfmJTgX8GJppCu5Udxd+tBm xN7fc7SJ4S62dZZb2RkFrI/QMNnGdMBn/gJXe26EO8WsizmxPlIKxeZhg0+0WG2+N2aE gITSgmYX95ANwd28gzBDpb/U0S5rtJrxi5ZnmZkYj6eGH/UUu7/MylAm3rN/+HxNb/B7 QQtIqLxPzAF1apW25Wy/Ji9Cig2GB0PCIcD7Fc2B3T3T9Q+AF6u/hjF8pIfHHLLeRxYD rVKkIBq6K3HETKezL+kKDUZlxAM9pQkignn3roNB4LLTZoMeWfJZDaYMYkc87mm5lfJZ 3Wbw== X-Gm-Message-State: AMke39k76Ptqx1cwPRHujiBMsIqIMzcuqzFhN0vGM8FbTFoxnJTLjrqYVJ0NhTu+99SC+5Sb X-Received: by 10.28.38.2 with SMTP id m2mr22794364wmm.44.1487662832118; Mon, 20 Feb 2017 23:40:32 -0800 (PST) Received: from Macintosh-6.local ([2001:720:410:1010:11a1:aa3f:5fd3:ec94]) by smtp.gmail.com with ESMTPSA id d1sm27816146wrb.62.2017.02.20.23.40.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Feb 2017 23:40:31 -0800 (PST) To: "quic@ietf.org" , draft-ietf-quic-recovery@ietf.org From: marcelo bagnulo braun Subject: A single alarm in draft-ietf-quic-recovery Message-ID: <57f78e9b-f75b-03da-0d3f-7405d645f7bd@it.uc3m.es> Date: Tue, 21 Feb 2017 08:40:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 07:40:37 -0000 Hi, The current version of the draft uses a single alarm for all timer based loss detection, as specified in section 3.4 of the draft. I am not sure i follow how you do this. I particular, I am uncertain you can avoid having two separated alarms, one for the RTO and another one for tail probe (at least). I mean, if i understand correctly, the RTO alarm should be set when you send the oldest packet (I guess a usual approximation is to set it when a given packet becomes the oldest, i.e. it is ok to set it when an ack arrives and acks the oldest packet (packet 5) making another packet (packet 6) to become the oldest packet, instead of setting the alarm when packet 6 was actually sent). I understand that the tail loss probe alarm is set when the last packet was sent (and the connection is in open state). So, suppose the sender sends packets 1,2, 3, 4, 5, 6, 7, 8 and 9 and suppose no ACK is received. The RTO timer should be set when packet 1 is sent while the TLP timer should be set when the packet 9 is sent. If i understand it correctly, according to the draft, the alarm will be set in TLP mode (twice) and then it wil enter in RTO mode. Suppose no ack comes back, this basically means that the actual RTO will be fired 2 TLP timeout later than the recommended RTO timeout, correct? (neglecting the transmission delay for packets 1 to 9 which may not be negligible if the number of inflight packets is high) I think a similar issue applies to the Early retransmit alarm. Again, the RTO should be set when the oldest packet is sent, but setting the early retransmit alarm will distort this. I mean again consider the situation the sender sends packets 1,2 and 3. While no acks are received, the TLP alarm is set. Suppose 1 RTT later, the ack for packet 3 arrives. At this point, the Early retransmit timer is set. Suppose now that no ack is received. RTT/4 later, the early retransmit kicks in again and again and actually the RTO will be never be set, because the alarm will always stay in early retransmit mode, no? Maybe a defining a max number of early retransmit would fix this? Probably having separated timers would also fix it (assuming we want a TCP like behaviour when the oldest packet is retransmitted after an RTO timeout) An additional comment about the Early retransmit timer, the draft references to RFC5827 to describe/explain this timer, but I personally found this a bit of a stretch. I mean RFC5827, if i understand it correctly, is about reducing the dupack threshold when the number of inflight packets is low, while this early retransmit timer is, well, a timer and it is used in any case when the latest packet has been acked. I think this fits better with the "reordering settling" timer (step 4 in section 5.2 of the RACK draft) being that the reordering settling timer applies to all packets for which a later ack has been received (not only the last ack, i mean). Maybe it is worth to adopt the full "reordering settling" timer from RACK (i.e. not limit to the case when the latests packet has been acked?) I guess if we do this, then we will need the TLP timer and the reordering settling timer to run in parallel. Regards, marcelo From nobody Tue Feb 21 03:24:15 2017 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 16C4A129445 for ; Tue, 21 Feb 2017 03:24:14 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 LUz2HWRkatcG for ; Tue, 21 Feb 2017 03:24:10 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id B850D129450 for ; Tue, 21 Feb 2017 03:24:10 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D5E54433404; Tue, 21 Feb 2017 11:24:09 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id BE058433408; Tue, 21 Feb 2017 11:24:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487676249; bh=BQ1suatnmGceI/7igsfo9KW6u473exa9jDf1Ud8/BHY=; l=5472; h=From:To:CC:Date:References:In-Reply-To:From; b=UKrMFegxMvBPlMTLCCGiyvoe3PcboaTJeCd1j87DZHhoTnGT/4oulCZfRfMfVnaa8 SjUIfc0HIMNwyLwfjeB8S+Sur/A4E51Kj23hf3xlFQt2t4G5Hyevx26xoeCLdknJkk FIFbyflYdVAbedhs6KGSDRaKenRwVqK1HO2uExoE= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id BA39C1FC8E; Tue, 21 Feb 2017 11:24:09 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Feb 2017 06:24:08 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Tue, 21 Feb 2017 06:24:09 -0500 From: "Lubashev, Igor" To: "rch@google.com" Subject: RE: tcp rsts, data truncation, and the future of public reset Thread-Topic: tcp rsts, data truncation, and the future of public reset Thread-Index: AQHSi6tjprq3SA28S0CynFHnEtJTgKFy0yeAgAAIagCAAAAtAIAABM8A///y6r6AAHCOgIAADq0G Date: Tue, 21 Feb 2017 11:24:08 +0000 Message-ID: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_bd918ea732b54f4ab9423de68b8ccf61usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "quic@ietf.org" , "pmcmanus@mozilla.com" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 11:24:14 -0000 --_000_bd918ea732b54f4ab9423de68b8ccf61usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If CONNECTION_CLOSE is like TCP FIN (an implicit FIN for all streams plus a= GOAWAY), it implies that this side will continue to re-transit frames in l= ost packets and peer will deliver data to the application. Or is CONNECTION= _CLOSE more like an implicit Reset for all streams plus a GOAWAY? - Igor -----Original Message----- From: Ryan Hamilton [rch@google.com] Received: Tuesday, 21 Feb 2017, 12:31AM To: Lubashev, Igor [ilubashe@akamai.com] CC: ekr@rtfm.com [ekr@rtfm.com]; jri@google.com [jri@google.com]; quic@ietf= .org [quic@ietf.org]; pmcmanus@mozilla.com [pmcmanus@mozilla.com] Subject: Re: tcp rsts, data truncation, and the future of public reset On Mon, Feb 20, 2017 at 7:48 PM, Lubashev, Igor > wrote: I also agree that other alternatives are strongly preferred to PUBLIC RESET= . However, I am worried about making it a MUST in this case. First, a MUST leaves no wiggle room for unforeseen circumstances (see below= ). Second, it is easy to circumvent this MUST by deliberately losing all co= nnection state (or just crypto state) and then immediately sending PUBLIC R= ESET (because I no longer have the state). We can probably find a way to always avoid PUBLIC RESET when designing appl= ication protocols, since QUIC still allows the application to Reset individ= ual streams (and those resets are not subject to connection-level flow cont= rol). But what do you do about a poorly designed application protocol that = cannot solve some problem with a neat stream reset (assume you cannot updat= e the application protocol on both peers quickly)? Would you want to force = applications not to use PUBLIC RESET as a last resort workaround? ?I don't think I understand how the use of CONNECTION_CLOSE is any differen= t to an application than PUBLIC_RESET? Under what circumstances would an ap= plication protocol (admittedly a poorly designed one) work if a PUBLIC_RESE= T were used, but would not work if a CONNECTION_CLOSED were?? --_000_bd918ea732b54f4ab9423de68b8ccf61usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable If CONNECTION_CLOSE is like TCP FIN (an implicit FIN for a= ll streams plus a GOAWAY), it implies that this side will continue to re-tr= ansit frames in lost packets and peer will deliver data to the application. Or is CONNECTION_CLOSE more like an = implicit Reset for all streams plus a GOAWAY?

- Igor

-----Original Message-----
From: Ryan Hamilton [rch@google.com]
Received: Tuesday, 21 Feb 2017, 12:31AM
To: Lubashev, Igor [ilubashe@akamai.com]
CC: ekr@rtfm.com [ekr@rtfm.com]; jri@google.com [jri@google.com]; qu= ic@ietf.org [quic@ietf.org]; pmcmanus@mozilla.com [pmcmanus@mozilla.com] Subject: Re: tcp rsts, data truncation, and the future of public res= et

On Mon, Feb 20, 2017 at 7:48 PM, Lubashev, Igor = <ilubashe@akamai.com> wrote:
I also agree that other alternatives are strongly preferre= d to PUBLIC RESET. However, I am worried about making it a MUST in this cas= e.

First, a MUST leaves no wiggle room for unforeseen circumstances (see below= ). Second, it is easy to circumvent this MUST by deliberately losing all co= nnection state (or just crypto state) and then immediately sending PUBLIC R= ESET (because I no longer have the state).

We can probably find a way to always avoid PUBLIC RESET when designing appl= ication protocols, since QUIC still allows the application to Reset individ= ual streams (and those resets are not subject to connection-level flow cont= rol). But what do you do about a poorly designed application protocol that cannot solve some problem with a= neat stream reset (assume you cannot update the application protocol on bo= th peers quickly)? Would you want to force applications not to use PUBLIC R= ESET as a last resort workaround?

​I don't think I understand how the use of CONNECTION_CLO= SE is any different to an application than PUBLIC_RESET? Under what circums= tances would an application protocol (admittedly a poorly designed one) work if a PUBLIC_RESET were used, but would not work if a CO= NNECTION_CLOSED were?​
--_000_bd918ea732b54f4ab9423de68b8ccf61usma1exdag1mb5msgcorpak_-- From nobody Tue Feb 21 06:53:17 2017 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 F1BC4129BF6 for ; Tue, 21 Feb 2017 06:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 7tFf4gU60cQ1 for ; Tue, 21 Feb 2017 06:53:14 -0800 (PST) Received: from mail-wr0-x231.google.com (mail-wr0-x231.google.com [IPv6:2a00:1450:400c:c0c::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 0C6B8129BF5 for ; Tue, 21 Feb 2017 06:53:14 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id 89so79067375wrr.3 for ; Tue, 21 Feb 2017 06:53:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=AiY9pAE0uf49OU9lZUETYWZGJCR8cs9j4NOYZIkTNQI=; b=ZDWt5YalFHuJ64xTLGtASzDwWUwQbrsG50gDy//CFoLv94PUxfy8+ZRhAd9+Wf6BJe +WeK6Ij7K5bXAM/bf0o9aCtYWiRWYfRKLSM4Aw5+wzNZDjeFOFaEfURAaQYPIHO9jjRc O1LZEXzHR8AF5h/qwjqq0JgVVLQaRUdP20wiRFiUvIG3Zl2R5CFel3AAbQueu/UAtcBe +uUJGDBA8jb9LxODVyy7tR4Ss4P4AX9zhJzqMfQVIhrD1gXHOMNYNbMrAgtQRfLKdplT hqwBBEe1qPGr+ajhYN9mqYlEwx2P2o/J//D4TyNtVwJqZqMHEVf5DuXjhfi+y4wZo/6K tz+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=AiY9pAE0uf49OU9lZUETYWZGJCR8cs9j4NOYZIkTNQI=; b=m6txMkoBy5TYo5ZciH8Utm6agmCssT30kNeRQBLeORHS3qnKFd58NmhJOwyORRHSEj VAC7tfSvCAEEeT5swJO3l3FxmL6TJdOjBFRK9+ntofapFFytrDSHrUVdu13ENTRuw5H7 JUuLLyW2WVOwtfbjSdqUFaU+JEcEkanZxptJp8O0lQVmp5ip+KOSz1+lJPbMZUKgJ3Ik vOEZmux9RJlMbLXp2FnZXxhVHGVxCijVjkuF/M+AJ1wTpe4b90zBdwS1CsRb8xRUgD2F J27MvittntSohYMAdPN6mCfyd18x6COHjxnpR9cMbJDm6IoBgLaNtEHeu6QO0LgkwA04 864w== X-Gm-Message-State: AMke39lgVyIan8kiNsyYQIkBH1J0hYe499SPxD+vn8yYTcdDWw7x6X304jGzsuaGCzOfUyrjhTqTw4Se5rqhRKU8 X-Received: by 10.223.174.247 with SMTP id y110mr19766897wrc.166.1487688792283; Tue, 21 Feb 2017 06:53:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Tue, 21 Feb 2017 06:53:11 -0800 (PST) In-Reply-To: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ryan Hamilton Date: Tue, 21 Feb 2017 06:53:11 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: "Lubashev, Igor" Content-Type: multipart/alternative; boundary=001a113c2c3800754105490b8a57 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "quic@ietf.org" , "pmcmanus@mozilla.com" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 14:53:16 -0000 --001a113c2c3800754105490b8a57 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable A CONNECTION_CLOSE immediately closes the connection. No data is retransmitted. It is not equivalent to delivering a FIN on all open streams. I would say that the equivalent of a TCP fin (which is the graceful shutdown of one half of a bidirectional communication) is a stream FIN. The CONNECTION_CLOSE sounds more like a TCP reset. On Tue, Feb 21, 2017 at 3:24 AM, Lubashev, Igor wrote= : > If CONNECTION_CLOSE is like TCP FIN (an implicit FIN for all streams plus > a GOAWAY), it implies that this side will continue to re-transit frames i= n > lost packets and peer will deliver data to the application. Or is > CONNECTION_CLOSE more like an implicit Reset for all streams plus a GOAWA= Y? > > - Igor > > -----Original Message----- > *From:* Ryan Hamilton [rch@google.com] > *Received:* Tuesday, 21 Feb 2017, 12:31AM > *To:* Lubashev, Igor [ilubashe@akamai.com] > *CC:* ekr@rtfm.com [ekr@rtfm.com]; jri@google.com [jri@google.com]; > quic@ietf.org [quic@ietf.org]; pmcmanus@mozilla.com [pmcmanus@mozilla.com= ] > *Subject:* Re: tcp rsts, data truncation, and the future of public reset > > > On Mon, Feb 20, 2017 at 7:48 PM, Lubashev, Igor > wrote: > >> I also agree that other alternatives are strongly preferred to PUBLIC >> RESET. However, I am worried about making it a MUST in this case. >> >> First, a MUST leaves no wiggle room for unforeseen circumstances (see >> below). Second, it is easy to circumvent this MUST by deliberately losin= g >> all connection state (or just crypto state) and then immediately sending >> PUBLIC RESET (because I no longer have the state). >> >> We can probably find a way to always avoid PUBLIC RESET when designing >> application protocols, since QUIC still allows the application to Reset >> individual streams (and those resets are not subject to connection-level >> flow control). But what do you do about a poorly designed application >> protocol that cannot solve some problem with a neat stream reset (assume >> you cannot update the application protocol on both peers quickly)? Would >> you want to force applications not to use PUBLIC RESET as a last resort >> workaround? > > > =E2=80=8BI don't think I understand how the use of CONNECTION_CLOSE is an= y > different to an application than PUBLIC_RESET? Under what circumstances > would an application protocol (admittedly a poorly designed one) work if = a > PUBLIC_RESET were used, but would not work if a CONNECTION_CLOSED were?= =E2=80=8B > --001a113c2c3800754105490b8a57 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
A CONNECTION_CLOSE immediately closes the connection. No d= ata is retransmitted. It is not equivalent to delivering a FIN on all open = streams. I would say that the equivalent of a TCP fin (which is the gracefu= l shutdown of one half of a bidirectional communication) is a stream FIN. T= he CONNECTION_CLOSE sounds more like a TCP reset.

On Tue, Feb 21, 2017 at 3:24 AM= , Lubashev, Igor <ilubashe@akamai.com> wr= ote:
If CONNECTION_CLOSE is like TCP FIN (an implicit FIN for all= streams plus a GOAWAY), it implies that this side will continue to re-tran= sit frames in lost packets and peer will deliver data to the application. Or is CONNECTION_CLOSE more like an = implicit Reset for all streams plus a GOAWAY?

- Igor

-----Original Message-----
From: Ryan Hamilton [rch@google.com]
Received: Tuesday, 21 Feb 2017, 12:31AM
To: Lubashev, Igor [ilubashe@akamai.com]
CC: ekr@rtfm.com [ekr@rtfm.com]; jri@google.com [jri@google.com]; quic@ietf.org [quic@ietf= .org]; pmcmanus@mozilla.com [pmcmanus@mozilla.com]
Subject: Re: tcp rsts, data truncation, and the future of public res= et


On Mon, Feb 20, 2017 at 7:48 PM, Lubashev, Igor = <ilubashe@akamai.com> wrote:
I also agree that other alternatives are strongly preferred = to PUBLIC RESET. However, I am worried about making it a MUST in this case.=

First, a MUST leaves no wiggle room for unforeseen circumstances (see below= ). Second, it is easy to circumvent this MUST by deliberately losing all co= nnection state (or just crypto state) and then immediately sending PUBLIC R= ESET (because I no longer have the state).

We can probably find a way to always avoid PUBLIC RESET when designing appl= ication protocols, since QUIC still allows the application to Reset individ= ual streams (and those resets are not subject to connection-level flow cont= rol). But what do you do about a poorly designed application protocol that cannot solve some problem with a= neat stream reset (assume you cannot update the application protocol on bo= th peers quickly)? Would you want to force applications not to use PUBLIC R= ESET as a last resort workaround?

=E2=80=8BI d= on't think I understand how the use of CONNECTION_CLOSE is any differen= t to an application than PUBLIC_RESET? Under what circumstances would an ap= plication protocol (admittedly a poorly designed one) work if a PUBLIC_RESET were used, but would not work if a CO= NNECTION_CLOSED were?=E2=80=8B

--001a113c2c3800754105490b8a57-- From nobody Tue Feb 21 07:14:02 2017 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 BDF1B1294E3 for ; Tue, 21 Feb 2017 07:14:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 IrhzR7ym6Zfe for ; Tue, 21 Feb 2017 07:13:58 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id AD13E1294D3 for ; Tue, 21 Feb 2017 07:13:58 -0800 (PST) Received: from mail-qt0-f170.google.com (mail-qt0-f170.google.com [209.85.216.170]) by linode64.ducksong.com (Postfix) with ESMTPSA id 2447D3A0AC for ; Tue, 21 Feb 2017 10:13:58 -0500 (EST) Received: by mail-qt0-f170.google.com with SMTP id x35so39825691qtc.2 for ; Tue, 21 Feb 2017 07:13:58 -0800 (PST) X-Gm-Message-State: AMke39m5vJoQN0nHK1F7Vf0EbOO8Khy7NXHYWOJhzVln0+fXLAtj9TlOGQNvpOscqBK5sY2lTEnViQ4uNSlGEg== X-Received: by 10.200.51.199 with SMTP id d7mr9160959qtb.94.1487690037923; Tue, 21 Feb 2017 07:13:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.65 with HTTP; Tue, 21 Feb 2017 07:13:57 -0800 (PST) In-Reply-To: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> From: Patrick McManus Date: Tue, 21 Feb 2017 10:13:57 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Ryan Hamilton Content-Type: multipart/alternative; boundary=001a114541de3f1a2e05490bd4c0 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , "pmcmanus@mozilla.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 15:14:01 -0000 --001a114541de3f1a2e05490bd4c0 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 21, 2017 at 9:53 AM, Ryan Hamilton wrote: > A CONNECTION_CLOSE immediately closes the connection. No data is > retransmitted. It is not equivalent to delivering a FIN on all open > streams. I would say that the equivalent of a TCP fin (which is the > graceful shutdown of one half of a bidirectional communication) is a stream > FIN. The CONNECTION_CLOSE sounds more like a TCP reset. > > would you open an issue to add this type of language to the spec (potentially in both the transport and loss drafts)? its really not defined afaict.. as it would alternatively make sense to retransmit unacked stuff after CLOSE - but then it wouldn't be behaving like reset (which honestly I would rather it didn't behave like reset - reset is leads to pain.). If the only difference between public_reset and connection_close is in the auth (and I guess the retransmitting of close as necessary?) perhaps they should share a name: public_connection_close or private_reset or somesuch? --001a114541de3f1a2e05490bd4c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 21, 2017 at 9:53 AM, Ryan Hamilton <rch@google.com>= wrote:
A CONNECTION_CLOSE immediately closes th= e connection. No data is retransmitted. It is not equivalent to delivering = a FIN on all open streams. I would say that the equivalent of a TCP fin (wh= ich is the graceful shutdown of one half of a bidirectional communication) = is a stream FIN. The CONNECTION_CLOSE sounds more like a TCP reset.

=C2=A0
would you open an issue to add this type of language to the spec (potent= ially in both the transport and loss drafts)? its really not defined afaict= .. as it would alternatively make sense to retransmit unacked stuff after C= LOSE - but then it wouldn't be behaving like reset (which honestly I wo= uld rather it didn't behave like reset - reset is leads to pain.).
<= br>
If the only difference between public_reset and connection_cl= ose is in the auth (and I guess the retransmitting of close as necessary?) = perhaps they should share a name: public_connection_close or private_reset = or somesuch?


=C2=A0

--001a114541de3f1a2e05490bd4c0-- From nobody Tue Feb 21 08:24:02 2017 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 A13F2129C6A for ; Tue, 21 Feb 2017 08:24:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y2Q2XPHa0vdh for ; Tue, 21 Feb 2017 08:23:59 -0800 (PST) Received: from mail-ot0-x236.google.com (mail-ot0-x236.google.com [IPv6:2607:f8b0:4003:c0f::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 3E952129C6B for ; Tue, 21 Feb 2017 08:23:59 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id j38so421932otb.3 for ; Tue, 21 Feb 2017 08:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TBbf+L28iDJFs8rfOttkMausRqs8q4lxEa8d+4v7j8E=; b=vA87J44SMWC9Kxl9Z2ir5caLRNdtm/JBKzM18PbK+7kDrEXCPUiA0jvzuZduF2ahE1 MCpJZ57zZU5/b9BSjJeY9mwvLDnVYybIhAMvNigQEJJ9lzTCIcLTkI2lrZkNaj98etbx Zum89I88tt7ToCIyo9w5DcL+j3I0aTPN0fNK08Z3IIXCSLEsUAqnFoOKW60jkrfkhK7H puDP466rrhmtZ8ZBjxVv/Cz5sZIC10gfAnLSfVJThAIRbRQPaeh1hYkh68nEzmlTIPLQ yY8ihxk6ychWUowwZnzra8rxP/XOs7wZ3JXaP/braavf1KJoitn90vfClsieLCEpQgmt 1gHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TBbf+L28iDJFs8rfOttkMausRqs8q4lxEa8d+4v7j8E=; b=pKyjNanBI++RcNcan3AIkkIEeexjlhwSUoLxG4uAlMRJpm+uVPbnR30YSK/ifBXutw hFJK77i8GTYa2DvjDhdFmFALwy65BIHOBDrYvj/pnzqgrhp/x+C8oYeOZAEf88UBLeku TiNWouqE2KFxmVgrpDfaU44j7PgOXVs4v07ef3b8OrMihxKFM3eq3lv2rarVpDIjAtGj 4www3buMx3u+QnGoi3UfphVPK/6hATi2TdKecKzhHswiTSR+66OVa6GvyRxHf2Ag+SH2 U298/MCIdDF/RFvntaZ/cJtQ+p43ETVzDmydvwh6mLf93OjoQWi/t2tSgHy2f/weGls7 CgOQ== X-Gm-Message-State: AMke39nDiEy2zNLmv8alFPfz/f0G1EeoCQeu+TZNtM6gEk5qyA+fV0HXR0FQkIo5Bz1oqYkbeQiy70qZlSgssw== X-Received: by 10.157.25.140 with SMTP id k12mr17461600otk.174.1487694238589; Tue, 21 Feb 2017 08:23:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.226 with HTTP; Tue, 21 Feb 2017 08:23:58 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Tue, 21 Feb 2017 08:23:58 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c09b6f6a02ad805490cce73 Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Patrick McManus , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 16:24:00 -0000 --94eb2c09b6f6a02ad805490cce73 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 20, 2017 at 2:35 PM, Jana Iyengar wrote: > On the point of what to do in TIME_WAIT, the server should hang on to some > state. At the least, hanging on to the connection ID protects the server by > preventing late packets from causing creation of new connection state, and > the server can simply discard incoming packets for connection IDs in > TIME_WAIT. (If a server wanted to hang on to more state, it could do so, > allowing it to retransmit CONNECTION_CLOSE frames later, but as you note, > this is more state and I wouldn't require it.) > I don't understand this point. If we discarded the connection ID immediately, wouldn't that just result in decryption failure for subsequent packets and a public reset? There is no new state. --94eb2c09b6f6a02ad805490cce73 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Feb 20, 2017 at 2:35 PM, Jana Iyengar <jri@google.com> wrote:
On the p= oint of what to do in TIME_WAIT, the server should hang on to some state. A= t the least, hanging on to the connection ID protects the server by prevent= ing late packets from causing creation of new connection state, and the ser= ver can simply discard incoming packets for connection IDs in TIME_WAIT. (I= f a server wanted to hang on to more state, it could do so, allowing it to = retransmit CONNECTION_CLOSE frames later, but as you note, this is more sta= te and I wouldn't require it.)
<= div>
I don't understand this point. If we discarded the c= onnection ID immediately, wouldn't that just result in decryption failu= re for subsequent packets and a public reset? There is no new state.
<= /div>
--94eb2c09b6f6a02ad805490cce73-- From nobody Tue Feb 21 08:49:21 2017 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 EDCB312948B for ; Tue, 21 Feb 2017 08:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jdcrGrjG8rvx for ; Tue, 21 Feb 2017 08:49:20 -0800 (PST) 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 DE10E12952C for ; Tue, 21 Feb 2017 08:49:19 -0800 (PST) Received: by mail-oi0-x22d.google.com with SMTP id 65so7124843oig.1 for ; Tue, 21 Feb 2017 08:49:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e7SSKC7CS+QBC3uR8IN0LOINO6hfYAQjN7JQZVDuNUo=; b=V3T0atWeJUayu2mWjgVSVbz+SIYAbEy6MBjX3PS7q4CKWYrto/DkTH0+os1301S1CL +XzekBKh83q9teOQtv6yhTvgr42NKxc8wD4A1daYvt2YI5eBRMGp0REroISyIav9tLMS MDcs1p2xQDXMkjCrt0tehqruurfD4C09xi4GRm68aHS1bA0WkuVqEAW5CjSxU2Iyn5AP ADwPj9P/ZIMveLeJAUYZHVgbhK9tEy50raRIrOTTuc3RzYlcR9PCGjZNmzNpuFfIY2jg 1mi7toI17tQpvnzMdCKORnoEsuaYkBJLxRd2V6Z+IC3eylk/31FONZaRUI2RNZRxoxgg nqUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e7SSKC7CS+QBC3uR8IN0LOINO6hfYAQjN7JQZVDuNUo=; b=n+5UWsoiZBPe0GNbOvZFmXE2lcxNa5SwXDbR2/vWuoJ14DkUDBNKxiizK3wnrPm/cE XolMkZr0l7Yiq4D0zx0eTA6VSbWGq08k2/V+KpGvq0Cc9Cx6I8HKVtdh61OU1JVLDQHC KW0xUbbtdYNasQS9vepX6/jG/7jT+lImsOlDoj5BvD2kyYsi7M74Uru5uNoNmusQJnHd Yj2Hm1jFfJ41nM/ZovMOvluCRAWO7xS9r6+PFT9zGMPkYub1j6VVK8LBRbhFpmGphzoA WvSYxHVM6UvggKWADA0mTpHe+KDc/XvV8V5xv36uyr1QRkSj1ExpEuex+DE7nVCkXQli 0eXg== X-Gm-Message-State: AMke39luPc8DYFq5TYKHNpX66JUrjD8JbXJIytiULZXVQEK7s0cEkXx68+xTdxPuK3OzztJakrwDtFYEcUZCFQ== X-Received: by 10.202.53.212 with SMTP id c203mr12797582oia.215.1487695759310; Tue, 21 Feb 2017 08:49:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.226 with HTTP; Tue, 21 Feb 2017 08:49:18 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Tue, 21 Feb 2017 08:49:18 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a113cf30e4485e405490d29e6 Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Patrick McManus , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 16:49:21 -0000 --001a113cf30e4485e405490d29e6 Content-Type: text/plain; charset=UTF-8 Never mind, no Public Reset on decryption failure. My mistake. On Tue, Feb 21, 2017 at 8:23 AM, Martin Duke wrote: > > > On Mon, Feb 20, 2017 at 2:35 PM, Jana Iyengar wrote: > >> On the point of what to do in TIME_WAIT, the server should hang on to >> some state. At the least, hanging on to the connection ID protects the >> server by preventing late packets from causing creation of new connection >> state, and the server can simply discard incoming packets for connection >> IDs in TIME_WAIT. (If a server wanted to hang on to more state, it could do >> so, allowing it to retransmit CONNECTION_CLOSE frames later, but as you >> note, this is more state and I wouldn't require it.) >> > > I don't understand this point. If we discarded the connection ID > immediately, wouldn't that just result in decryption failure for subsequent > packets and a public reset? There is no new state. > --001a113cf30e4485e405490d29e6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Never mind, no Public Reset on decryption failure. My mist= ake.

On Tue,= Feb 21, 2017 at 8:23 AM, Martin Duke <martin.h.duke@gmail.com&g= t; wrote:


On = Mon, Feb 20, 2017 at 2:35 PM, Jana Iyengar <jri@google.com> wro= te:
On the point of= what to do in TIME_WAIT, the server should hang on to some state. At the l= east, hanging on to the connection ID protects the server by preventing lat= e packets from causing creation of new connection state, and the server can= simply discard incoming packets for connection IDs in TIME_WAIT. (If a ser= ver wanted to hang on to more state, it could do so, allowing it to retrans= mit CONNECTION_CLOSE frames later, but as you note, this is more state and = I wouldn't require it.)

I don't un= derstand this point. If we discarded the connection ID immediately, wouldn&= #39;t that just result in decryption failure for subsequent packets and a p= ublic reset? There is no new state.

--001a113cf30e4485e405490d29e6-- From nobody Tue Feb 21 12:02:40 2017 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 956811296E0 for ; Tue, 21 Feb 2017 12:02:39 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 P0PmYB5S78Qx for ; Tue, 21 Feb 2017 12:02:38 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8B291296E3 for ; Tue, 21 Feb 2017 12:02:37 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id v77so84737111wmv.0 for ; Tue, 21 Feb 2017 12:02:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4oXlJQmja8H3vFGEM6ocxoJy56RdjZcQLEx3g4gIr4g=; b=qf+l0R136C3zQ/3oBNWUNMCCLucy53da5g+aseK9GkELyVe15pIIpG83WIV15guuCN edG8hAtEohRJoUKp8KL2ZPWXhPOz2c/p+TI7U2vraTxXYvoWpM0CsvLGj5gK0dyPD9HX o8fEQkIPynShqoRucsi3U7n90XD8VlUgFx0gOmltGjDIMIOWrDqG1Iz8fonJUNQ3ZBVK 6mGWFgU2WRNHoEi4V8BsBC9G2GjUhQaOqps2JucdPC1MXa8KZMaXnzKnScCjGL+B989j GoyvqZJPGxEPBRuGdIHbBtXcqxPbcoXLtxDoKiZy43vzG7SeHmzZuH/om0gZO6+2q7FH LgLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4oXlJQmja8H3vFGEM6ocxoJy56RdjZcQLEx3g4gIr4g=; b=qANgZlKcMRwN2qigEKcO4QqYQDQ1TwnxenNINsGljHCBjqcNeMoH7l6G+1PXtQz5jI Ylc+iOpnt1W7ojXXFFdODro0VhLglJ50GsvmIqX2tGt1SMyrLRu38RN6oqExNQUmJgol z688D6Hw+R4mCxzN4qxg4nchVEsdV3nMmR2hnmBVak6PXao56/Cbm2l28E4kyZamZCRv /AEYvwRCXBx+7Fi2kaSG7WrsK2RGjWUp3sD+6BpogohitpnT6V6/QKBSsHUITVTjfwkt WUeHjznAirdA+lvyalh4TtQdZZ7CydQ0627R+tv7S1fCcfKL21k3BqS1FE4FdR2LLoYB iM1w== X-Gm-Message-State: AMke39nsiXQcjAOr46AAuliMj+2LRwFCbzcpV8HxICzdxejsUlIQvv+euexWLYsRII33JbOYHeTBbY1aBmz2YDd6 X-Received: by 10.28.191.79 with SMTP id p76mr26863104wmf.21.1487707356362; Tue, 21 Feb 2017 12:02:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Tue, 21 Feb 2017 12:02:35 -0800 (PST) In-Reply-To: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ryan Hamilton Date: Tue, 21 Feb 2017 12:02:35 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Patrick McManus Content-Type: multipart/alternative; boundary=94eb2c07127281c92805490fdc9c Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 20:02:39 -0000 --94eb2c07127281c92805490fdc9c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 21, 2017 at 7:13 AM, Patrick McManus wrote: > would you open an issue to add this type of language to the spec > (potentially in both the transport and loss drafts)? its really not defin= ed > afaict.. > =E2=80=8BSure. I filed https://github.com/quicwg/base-drafts/issues/330. --94eb2c07127281c92805490fdc9c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 21, 2017 at 7:13 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
would you open an issue to = add this type of language to the spec (potentially in both the transport an= d loss drafts)? its really not defined afaict..
<= br>

--94eb2c07127281c92805490fdc9c-- From nobody Tue Feb 21 12:20:03 2017 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 E1F851294A7 for ; Tue, 21 Feb 2017 12:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 29icGX7JiIrL for ; Tue, 21 Feb 2017 12:19:59 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0100.outbound.protection.outlook.com [104.47.37.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 638D1129534 for ; Tue, 21 Feb 2017 12:19:58 -0800 (PST) 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=VFMWoi5mchXa8a7H8DxjiBz9TkDNcNOLCs3ez0bgXO0=; b=WC2YSrjPISf4dgG3dirajBZtmi26JzkoRZPviM8dTgDKor9YDfbGaSLVj/qJnL21JyDOPMjFmhpBdRM0DzMzC4jePVnCzPyZlkGk8zd4USrLv9GP5cG+I1bmNDWqSDCCZ9QGqMYeRj1JdgobM4uRaD2Wzt3uWC189v3X3n6F4hI= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Tue, 21 Feb 2017 20:19:55 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0919.018; Tue, 21 Feb 2017 20:19:55 +0000 From: Mike Bishop To: Patrick McManus , Ryan Hamilton Subject: RE: tcp rsts, data truncation, and the future of public reset Thread-Topic: tcp rsts, data truncation, and the future of public reset Thread-Index: AQHSi6tlLSNFL2QWbkadxBq6o9w3M6FybpKAgAAIagCAAAAtAIAABM4AgABXgACAABy8gIAAYn4AgAA6aYCAAAXNgIAAUnPA Date: Tue, 21 Feb 2017 20:19:55 +0000 Message-ID: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.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=Michael.Bishop@microsoft.com; x-originating-ip: [2001:4898:80e8:2::51f] x-ms-office365-filtering-correlation-id: 6ec6debb-ee71-4375-7be5-08d45a970066 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:odtyubxfErOA1l/nPb5xYWH29wVlZ5DQjRfylDLMzlcaMyCIprAjaiARhcTgRC+iVhzhQtAkOd87OjME5TzObtz05BjDGj2UioCgBEkyA/BPBuzJ1Y8cPCDUolDCjQDYi49dAww8RNWB+7/pxRiEt99U2ikMjaa8EU5eo2YIB9EY8FXqkcf2NU+wNi1TiXCCr9bkioYFi/Qil5ytJPV3sfS0XBUPgtXqMhEVPKHI/xxe3pugl7pjJTVRv/1QqKb2sRtktxpDzIr06cQpVm8hv2ZNYZw47Qamc93lut7Oq/0VOlz3s1c4UY0fBdjWZepFT/TaCJds5O73f+GAk30/uUinVONTIeixq09vM7UOyPk= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(6072148)(6042181); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0225B0D5BC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(24454002)(377454003)(189002)(6436002)(33656002)(68736007)(19609705001)(8936002)(236005)(10290500002)(93886004)(101416001)(92566002)(99286003)(5660300001)(4326007)(55016002)(25786008)(2900100001)(3280700002)(54896002)(8676002)(86362001)(7696004)(6506006)(81166006)(9686003)(54906002)(6306002)(81156014)(77096006)(7736002)(53546006)(86612001)(189998001)(229853002)(38730400002)(790700001)(5005710100001)(76176999)(2906002)(6116002)(50986999)(6246003)(102836003)(54356999)(2950100002)(53936002)(3660700001)(97736004)(74316002)(8990500004)(106356001)(106116001)(122556002)(105586002)(10090500001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708BAA3F82A81624901529987510BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Feb 2017 20:19:55.5777 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 20:20:02 -0000 --_000_BN6PR03MB2708BAA3F82A81624901529987510BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHN0cmVhbXMgbWVhbiB0aGF0IHlvdSBoYXZlIGEgdHdvLWxheWVyIGNsb3NlIHRvIHRoZSBj b25uZWN0aW9uLCB3aGljaCBtYWtlcyBhIGdyYWNlZnVsIHNodXRkb3duIG1vcmUgY29tcGxleC4g IEFzIEkgdW5kZXJzdGFuZCBpdCwgdGhlIOKAnGNsZWFu4oCdIGNvbm5lY3Rpb24gY2xvc2UgZmxv dyBpczoNCg0KICAqICAgR09BV0FZIOKAkyBubyBuZXcgc3RyZWFtcyBjYW4gb3BlbiAoaW1wbGlj aXQgUlNUIG9mIHN0cmVhbXMgdGhhdCB3ZXJlIHJhY2luZyB0aGUgR09BV0FZKQ0KICAqICAgU2Vy dmljZSBhbmQgRklOIChvciBSU1QgYXMgbmVlZGVkKSBhbGwgZXhpc3Rpbmcgc3RyZWFtcw0KICAq ICAgQ09OTkVDVElPTl9DTE9TRSBvbmNlIGFsbCBzdHJlYW1zIGhhdmUgY2xvc2VkIGFuZCBhbGwg ZGF0YSBoYXMgYmVlbiBBQ0vigJlkDQoNCkdyYWNlbGVzcyBzaHV0ZG93biBpcyBzaW1wbGUgYXMg ZXZlci4gIPCfmIogIElmIHlvdSBza2lwIHN0cmFpZ2h0IHRvIHRoZSBDT05ORUNUSU9OX0NMT1NF LCB0aGF04oCZcyBlZmZlY3RpdmVseSBhIFJTVCBvZiBldmVyeSBzdHJlYW0gdGhhdOKAmXMgc3Rp bGwgb3BlbiB3aGVuIHlvdSBnZXQgdGhlcmUuDQoNCkl0IHNvdW5kcyBsaWtlIHdoYXQgeW914oCZ cmUgY29uY2VybmVkIGFib3V0IGlzIHRoZSB3aW5kb3cgYWZ0ZXIgc2VuZGluZyBhbGwgc3RyZWFt IGRhdGEuICBJZiB5b3UgdHJhbnNtaXQgdGhlIENPTk5FQ1RJT05fQ0xPU0UgdG9vIGVhcmx5LCB5 b3UgcmlzayBsb3NpbmcgZGF0YSBpbiB0aGUgZmluYWwgZmxpZ2h0LCBlaXRoZXIgdGhyb3VnaCBs b3NzIG9yIHJlb3JkZXJpbmcgb2YgdGhlIENPTk5FQ1RJT05fQ0xPU0UgYWhlYWQgb2YgZGF0YSBw YWNrZXRzLg0KDQpJdCBzZWVtcyBsaWtlIHRoZSBvYnZpb3VzIEFQSSBzZW1hbnRpY3Mgd291bGQg YmUgc2ltaWxhciB0byBUQ1DigJlzIOKAkyBvbmUgb3B0aW9uIHdvdWxkIEdPQVdBWSwgd2FpdCwg c2VuZCB0aGUgQ09OTkVDVElPTl9DTE9TRSwgYW5kIGZpbmFsbHkgcmV0dXJuLiAgVGhlIG90aGVy IHdvdWxkIHNlbmQgdGhlIENPTk5FQ1RJT05fQ0xPU0UgaW1tZWRpYXRlbHksIGFuZCBkYXRhIGZh bGxzIHdoZXJlIGl0IG1heS4gIEhvd2V2ZXIsIHRoYXQgaW52aXRlcyB0aGUgc2FtZSBhcHBsaWNh dGlvbiBiZWhhdmlvciB5b3Ugc2VlIHdpdGggVENQIHRvZGF5IOKAkyB0aGUgYXBwbGljYXRpb24g ZG9lc27igJl0IHdhbnQgdG8gc2l0IGFyb3VuZCwgYW5kIHdpbGwgY2FsbCB0aGUgZmFzdGVyIEFQ SSBpZiBpdCBoYXMgZ290dGVuIGV2ZXJ5dGhpbmcgaXQgbmVlZHMgb2ZmIHRoZSBjb25uZWN0aW9u Lg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgUGF0cmljayBNY01hbnVzDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyMSwgMjAxNyA3OjE0 IEFNDQpUbzogUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb20+DQpDYzoganJpQGdvb2dsZS5j b207IGVrckBydGZtLmNvbTsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+OyBw bWNtYW51c0Btb3ppbGxhLmNvbTsgcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IHRjcCByc3Rz LCBkYXRhIHRydW5jYXRpb24sIGFuZCB0aGUgZnV0dXJlIG9mIHB1YmxpYyByZXNldA0KDQoNCk9u IFR1ZSwgRmViIDIxLCAyMDE3IGF0IDk6NTMgQU0sIFJ5YW4gSGFtaWx0b24gPHJjaEBnb29nbGUu Y29tPG1haWx0bzpyY2hAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KQSBDT05ORUNUSU9OX0NMT1NFIGlt bWVkaWF0ZWx5IGNsb3NlcyB0aGUgY29ubmVjdGlvbi4gTm8gZGF0YSBpcyByZXRyYW5zbWl0dGVk LiBJdCBpcyBub3QgZXF1aXZhbGVudCB0byBkZWxpdmVyaW5nIGEgRklOIG9uIGFsbCBvcGVuIHN0 cmVhbXMuIEkgd291bGQgc2F5IHRoYXQgdGhlIGVxdWl2YWxlbnQgb2YgYSBUQ1AgZmluICh3aGlj aCBpcyB0aGUgZ3JhY2VmdWwgc2h1dGRvd24gb2Ygb25lIGhhbGYgb2YgYSBiaWRpcmVjdGlvbmFs IGNvbW11bmljYXRpb24pIGlzIGEgc3RyZWFtIEZJTi4gVGhlIENPTk5FQ1RJT05fQ0xPU0Ugc291 bmRzIG1vcmUgbGlrZSBhIFRDUCByZXNldC4NCg0KDQp3b3VsZCB5b3Ugb3BlbiBhbiBpc3N1ZSB0 byBhZGQgdGhpcyB0eXBlIG9mIGxhbmd1YWdlIHRvIHRoZSBzcGVjIChwb3RlbnRpYWxseSBpbiBi b3RoIHRoZSB0cmFuc3BvcnQgYW5kIGxvc3MgZHJhZnRzKT8gaXRzIHJlYWxseSBub3QgZGVmaW5l ZCBhZmFpY3QuLiBhcyBpdCB3b3VsZCBhbHRlcm5hdGl2ZWx5IG1ha2Ugc2Vuc2UgdG8gcmV0cmFu c21pdCB1bmFja2VkIHN0dWZmIGFmdGVyIENMT1NFIC0gYnV0IHRoZW4gaXQgd291bGRuJ3QgYmUg YmVoYXZpbmcgbGlrZSByZXNldCAod2hpY2ggaG9uZXN0bHkgSSB3b3VsZCByYXRoZXIgaXQgZGlk bid0IGJlaGF2ZSBsaWtlIHJlc2V0IC0gcmVzZXQgaXMgbGVhZHMgdG8gcGFpbi4pLg0KSWYgdGhl IG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIHB1YmxpY19yZXNldCBhbmQgY29ubmVjdGlvbl9jbG9z ZSBpcyBpbiB0aGUgYXV0aCAoYW5kIEkgZ3Vlc3MgdGhlIHJldHJhbnNtaXR0aW5nIG9mIGNsb3Nl IGFzIG5lY2Vzc2FyeT8pIHBlcmhhcHMgdGhleSBzaG91bGQgc2hhcmUgYSBuYW1lOiBwdWJsaWNf Y29ubmVjdGlvbl9jbG9zZSBvciBwcml2YXRlX3Jlc2V0IG9yIHNvbWVzdWNoPw0KDQoNCg0K --_000_BN6PR03MB2708BAA3F82A81624901529987510BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQg TVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGlu aw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtt c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYu TXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDow aW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVm dDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9y bWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1t YXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUt dHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpA cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6NTc1NzUx MzQxOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotODI4 MTAyNzUwIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4 NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs Mg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291 cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJ e21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGUgc3RyZWFtcyBtZWFuIHRoYXQgeW91IGhhdmUgYSB0d28tbGF5 ZXIgY2xvc2UgdG8gdGhlIGNvbm5lY3Rpb24sIHdoaWNoIG1ha2VzIGEgZ3JhY2VmdWwgc2h1dGRv d24gbW9yZSBjb21wbGV4LiZuYnNwOyBBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSDigJxjbGVhbuKA nSBjb25uZWN0aW9uIGNsb3NlIGZsb3cgaXM6PG86cD48L286cD48L3A+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+R09BV0FZIOKA kyBubyBuZXcgc3RyZWFtcyBjYW4gb3BlbiAoaW1wbGljaXQgUlNUIG9mIHN0cmVhbXMgdGhhdCB3 ZXJlIHJhY2luZyB0aGUgR09BV0FZKTxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb0xpc3RQ YXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEi PlNlcnZpY2UgYW5kIEZJTiAob3IgUlNUIGFzIG5lZWRlZCkgYWxsIGV4aXN0aW5nIHN0cmVhbXM8 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj5DT05ORUNUSU9OX0NMT1NFIG9uY2Ug YWxsIHN0cmVhbXMgaGF2ZSBjbG9zZWQgYW5kIGFsbCBkYXRhIGhhcyBiZWVuIEFDS+KAmWQ8bzpw PjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R3JhY2VsZXNzIHNodXRkb3duIGlzIHNpbXBsZSBh cyBldmVyLiZuYnNwOyA8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1v amkmcXVvdDssc2Fucy1zZXJpZiI+DQomIzEyODUyMjs8L3NwYW4+Jm5ic3A7IElmIHlvdSBza2lw IHN0cmFpZ2h0IHRvIHRoZSBDT05ORUNUSU9OX0NMT1NFLCB0aGF04oCZcyBlZmZlY3RpdmVseSBh IFJTVCBvZiBldmVyeSBzdHJlYW0gdGhhdOKAmXMgc3RpbGwgb3BlbiB3aGVuIHlvdSBnZXQgdGhl cmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNvdW5kcyBsaWtlIHdoYXQgeW914oCZcmUg Y29uY2VybmVkIGFib3V0IGlzIHRoZSB3aW5kb3cgYWZ0ZXIgc2VuZGluZyBhbGwgc3RyZWFtIGRh dGEuJm5ic3A7IElmIHlvdSB0cmFuc21pdCB0aGUgQ09OTkVDVElPTl9DTE9TRSB0b28gZWFybHks IHlvdSByaXNrIGxvc2luZyBkYXRhIGluIHRoZSBmaW5hbCBmbGlnaHQsIGVpdGhlciB0aHJvdWdo IGxvc3Mgb3IgcmVvcmRlcmluZyBvZiB0aGUgQ09OTkVDVElPTl9DTE9TRQ0KIGFoZWFkIG9mIGRh dGEgcGFja2V0cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgc2VlbXMgbGlrZSB0aGUgb2J2 aW91cyBBUEkgc2VtYW50aWNzIHdvdWxkIGJlIHNpbWlsYXIgdG8gVENQ4oCZcyDigJMgb25lIG9w dGlvbiB3b3VsZCBHT0FXQVksIHdhaXQsIHNlbmQgdGhlIENPTk5FQ1RJT05fQ0xPU0UsIGFuZCBm aW5hbGx5IHJldHVybi4mbmJzcDsgVGhlIG90aGVyIHdvdWxkIHNlbmQgdGhlIENPTk5FQ1RJT05f Q0xPU0UgaW1tZWRpYXRlbHksIGFuZCBkYXRhIGZhbGxzIHdoZXJlIGl0IG1heS4mbmJzcDsgSG93 ZXZlciwNCiB0aGF0IGludml0ZXMgdGhlIHNhbWUgYXBwbGljYXRpb24gYmVoYXZpb3IgeW91IHNl ZSB3aXRoIFRDUCB0b2RheSDigJMgdGhlIGFwcGxpY2F0aW9uIGRvZXNu4oCZdCB3YW50IHRvIHNp dCBhcm91bmQsIGFuZCB3aWxsIGNhbGwgdGhlIGZhc3RlciBBUEkgaWYgaXQgaGFzIGdvdHRlbiBl dmVyeXRoaW5nIGl0IG5lZWRzIG9mZiB0aGUgY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxi Pk9uIEJlaGFsZiBPZg0KPC9iPlBhdHJpY2sgTWNNYW51czxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBGZWJydWFyeSAyMSwgMjAxNyA3OjE0IEFNPGJyPg0KPGI+VG86PC9iPiBSeWFuIEhhbWls dG9uICZsdDtyY2hAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGpyaUBnb29nbGUuY29t OyBla3JAcnRmbS5jb207IEx1YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0 OzsgcG1jbWFudXNAbW96aWxsYS5jb207IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IHRjcCByc3RzLCBkYXRhIHRydW5jYXRpb24sIGFuZCB0aGUgZnV0dXJlIG9mIHB1Ymxp YyByZXNldDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDIxLCAy MDE3IGF0IDk6NTMgQU0sIFJ5YW4gSGFtaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpyY2hAZ29v Z2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJjaEBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNh bnMtc2VyaWYiPkEgQ09OTkVDVElPTl9DTE9TRSBpbW1lZGlhdGVseSBjbG9zZXMgdGhlIGNvbm5l Y3Rpb24uIE5vIGRhdGEgaXMgcmV0cmFuc21pdHRlZC4gSXQgaXMgbm90IGVxdWl2YWxlbnQgdG8g ZGVsaXZlcmluZyBhIEZJTiBvbiBhbGwgb3BlbiBzdHJlYW1zLiBJIHdvdWxkIHNheSB0aGF0IHRo ZSBlcXVpdmFsZW50IG9mIGEgVENQIGZpbg0KICh3aGljaCBpcyB0aGUgZ3JhY2VmdWwgc2h1dGRv d24gb2Ygb25lIGhhbGYgb2YgYSBiaWRpcmVjdGlvbmFsIGNvbW11bmljYXRpb24pIGlzIGEgc3Ry ZWFtIEZJTi4gVGhlIENPTk5FQ1RJT05fQ0xPU0Ugc291bmRzIG1vcmUgbGlrZSBhIFRDUCByZXNl dC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPndvdWxkIHlvdSBvcGVuIGFuIGlzc3VlIHRvIGFkZCB0aGlzIHR5 cGUgb2YgbGFuZ3VhZ2UgdG8gdGhlIHNwZWMgKHBvdGVudGlhbGx5IGluIGJvdGggdGhlIHRyYW5z cG9ydCBhbmQgbG9zcyBkcmFmdHMpPyBpdHMgcmVhbGx5IG5vdCBkZWZpbmVkIGFmYWljdC4uIGFz IGl0IHdvdWxkIGFsdGVybmF0aXZlbHkgbWFrZSBzZW5zZSB0byByZXRyYW5zbWl0IHVuYWNrZWQN CiBzdHVmZiBhZnRlciBDTE9TRSAtIGJ1dCB0aGVuIGl0IHdvdWxkbid0IGJlIGJlaGF2aW5nIGxp a2UgcmVzZXQgKHdoaWNoIGhvbmVzdGx5IEkgd291bGQgcmF0aGVyIGl0IGRpZG4ndCBiZWhhdmUg bGlrZSByZXNldCAtIHJlc2V0IGlzIGxlYWRzIHRvIHBhaW4uKS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+SWYgdGhlIG9ubHkgZGlmZmVyZW5jZSBiZXR3ZWVuIHB1YmxpY19yZXNldCBhbmQgY29u bmVjdGlvbl9jbG9zZSBpcyBpbiB0aGUgYXV0aCAoYW5kIEkgZ3Vlc3MgdGhlIHJldHJhbnNtaXR0 aW5nIG9mIGNsb3NlIGFzIG5lY2Vzc2FyeT8pIHBlcmhhcHMgdGhleSBzaG91bGQgc2hhcmUgYSBu YW1lOiBwdWJsaWNfY29ubmVjdGlvbl9jbG9zZSBvciBwcml2YXRlX3Jlc2V0DQogb3Igc29tZXN1 Y2g/PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN6PR03MB2708BAA3F82A81624901529987510BN6PR03MB2708namp_-- From nobody Tue Feb 21 12:50:49 2017 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 4D7B11294E2 for ; Tue, 21 Feb 2017 12:50:47 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 YZhoUJp4Y3M5 for ; Tue, 21 Feb 2017 12:50:44 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52EE21294E0 for ; Tue, 21 Feb 2017 12:50:44 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id v186so123187081wmd.0 for ; Tue, 21 Feb 2017 12:50:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=REVcxdd1I08jQH2t+KJ5ctZtsWOefhMhQF+qvBoOiKY=; b=Iel7hoR3090CHN+innvc/10jZU81PjbVPMgxgR65RPWAjTz9Au8yrXnKLQuOnft4+D s9WQZv6o5ay5Q460sZIV31YTs/qN2c6bj8RlzdblVx/a1wENCuO8OOF9uFPyDSmhjk1b td/YxlNPrJ8aVZPWLu4IL3ivRhg2SWCii7NmdysdKiXaAHjdvNIYZDG0mju8uHU5HZeR pBkFtVi40MJgYJfRmSrqAlKO8f3c2lJtMOs8l0w7dgT+n63Lmnu8nerS08U8Bu38Zcya 2/S+s9l/R+U2Vt5Y3PsIRayH13jifHtIS+5r7y++r0keJOK7iliumvJbqWVd1kay/gnC lhyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=REVcxdd1I08jQH2t+KJ5ctZtsWOefhMhQF+qvBoOiKY=; b=DX05HztY4L/FxE5E8hR315enFs7FcTXNj/7FyEdKLPQHEAsuAqg2tmOac2Xr5bFIHL e/hLN0PHNkaovC7ILgpd/9d9QjEDpAQKEn3HGboQL6xQH16RZB3dMynt6wpf2hFz2thG /eOj83sBy3jXJ5YsBN7h8VPy64f7rvTk3GPCavqfkJigN+dJIpzQy2VMD/2kZeGH4opW xxMX27TAQBrtatDF8mTAD0lVZ8jCiOLbZpOWR1HB6VujTv4Uuod4Ol0K+nWiFV2MjiA3 gPpsbkoCaAqcsqfPoAuLeTf636aytdmT3D/+CGMObsMj+nHy4djbi6/jZxSF0Gns0Y5l Rm9A== X-Gm-Message-State: AMke39lUjDXqFbSn6TUSf1TEuCEcDblWWQxty5viHE2YSB2sAHjv3/Qn9sPLbxmJuIurBJiBX7NSw2pvlJN0mtZn X-Received: by 10.28.128.205 with SMTP id b196mr15690399wmd.21.1487710242764; Tue, 21 Feb 2017 12:50:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Tue, 21 Feb 2017 12:50:42 -0800 (PST) In-Reply-To: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> From: Ryan Hamilton Date: Tue, 21 Feb 2017 12:50:42 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Mike Bishop Content-Type: multipart/alternative; boundary=001a1141e6648cdaa5054910882f Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "Lubashev, Igor" , Patrick McManus , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 20:50:47 -0000 --001a1141e6648cdaa5054910882f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 21, 2017 at 12:19 PM, Mike Bishop wrote: > The streams mean that you have a two-layer close to the connection, which > makes a graceful shutdown more complex. As I understand it, the =E2=80= =9Cclean=E2=80=9D > connection close flow is: > > - GOAWAY =E2=80=93 no new streams can open (implicit RST of streams th= at were > racing the GOAWAY) > - Service and FIN (or RST as needed) all existing streams > - CONNECTION_CLOSE once all streams have closed and all data has been > ACK=E2=80=99d > > =E2=80=8B*nod* =E2=80=8B > Graceless shutdown is simple as ever. =F0=9F=98=8A If you skip straight= to the > CONNECTION_CLOSE, that=E2=80=99s effectively a RST of every stream that= =E2=80=99s still > open when you get there. > Agreed. This makes sense to me and seems like the right way to think about things. =E2=80=8B > It sounds like what you=E2=80=99re concerned about is the window after se= nding all > stream data. If you transmit the CONNECTION_CLOSE too early, you risk > losing data in the final flight, either through loss or reordering of the > CONNECTION_CLOSE ahead of data packets. > =E2=80=8BSince QUIC connections are multiplexed, it is common to keep them = around for some period of idle in expectation of new streams being created. As a result, it's common to only send the CONNECTION_CLOSE after that period expires. (Or if there is some sort of fatal error on the connection.) =E2=80=8B > It seems like the obvious API semantics would be similar to TCP=E2=80=99= s =E2=80=93 one > option would GOAWAY, wait, send the CONNECTION_CLOSE, and finally return. > The other would send the CONNECTION_CLOSE immediately, and data falls whe= re > it may. However, that invites the same application behavior you see with > TCP today =E2=80=93 the application doesn=E2=80=99t want to sit around, a= nd will call the > faster API if it has gotten everything it needs off the connection. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Patrick McManu= s > *Sent:* Tuesday, February 21, 2017 7:14 AM > *To:* Ryan Hamilton > *Cc:* jri@google.com; ekr@rtfm.com; Lubashev, Igor ; > pmcmanus@mozilla.com; quic@ietf.org > *Subject:* Re: tcp rsts, data truncation, and the future of public reset > > > > > > On Tue, Feb 21, 2017 at 9:53 AM, Ryan Hamilton wrote: > > A CONNECTION_CLOSE immediately closes the connection. No data is > retransmitted. It is not equivalent to delivering a FIN on all open > streams. I would say that the equivalent of a TCP fin (which is the > graceful shutdown of one half of a bidirectional communication) is a stre= am > FIN. The CONNECTION_CLOSE sounds more like a TCP reset. > > > > > > would you open an issue to add this type of language to the spec > (potentially in both the transport and loss drafts)? its really not defin= ed > afaict.. as it would alternatively make sense to retransmit unacked stuff > after CLOSE - but then it wouldn't be behaving like reset (which honestly= I > would rather it didn't behave like reset - reset is leads to pain.). > > If the only difference between public_reset and connection_close is in th= e > auth (and I guess the retransmitting of close as necessary?) perhaps they > should share a name: public_connection_close or private_reset or somesuch= ? > > > > > --001a1141e6648cdaa5054910882f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Feb 21, 2017 at 12:19 PM, Mike Bishop &= lt;Michael.Bishop@microsoft.com> wrote:

The streams mean that you have a two-layer close to = the connection, which makes a graceful shutdown more complex.=C2=A0 As I un= derstand it, the =E2=80=9Cclean=E2=80=9D connection close flow is:

  • GOAWAY =E2=80=93 no new streams can open (implicit RST of streams that w= ere racing the GOAWAY)
  • Service and FIN (or RST as need= ed) all existing streams
  • CONNECTION_CLOSE once all str= eams have closed and all data has been ACK=E2=80=99d
<= /blockquote>
=E2=80=8B*nod*
=E2=80=8B

Graceless shutdown is simple as ever.=C2=A0 =F0=9F=98=8A=C2=A0 If you skip straight to the CONNECTION_CLOSE, tha= t=E2=80=99s effectively a RST of every stream that=E2=80=99s still open whe= n you get there.


Agr= eed. This makes sense to me and seems like the right way to think about thi= ngs.
=E2=80=8B

It sounds like what you=E2=80=99re concerned = about is the window after sending all stream data.=C2=A0 If you transmit th= e CONNECTION_CLOSE too early, you risk losing data in the final flight, eit= her through loss or reordering of the CONNECTION_CLOSE ahead of data packets.


=E2=80=8BSince QUIC connections are multiplexed, it is common to keep t= hem around for some period of idle in expectation of new streams being crea= ted. As a result, it's common to only send the CONNECTION_CLOSE after t= hat period expires. (Or if there is some sort of fatal error on the connect= ion.)
=E2=80=8B

=C2=A0It seems like the obvious API semantics= would be similar to TCP=E2=80=99s =E2=80=93 one option would GOAWAY, wait,= send the CONNECTION_CLOSE, and finally return.=C2=A0 The other would send = the CONNECTION_CLOSE immediately, and data falls where it may.=C2=A0 Howeve= r, that invites the same application behavior you see with TCP today =E2=80= =93 the application doesn=E2=80=99t want to sit around, and will call the f= aster API if it has gotten everything it needs off the connection.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org= ] On Behalf Of Patrick McManus
Sent: Tuesday, February 21, 2017 7:14 AM
To: Ryan Hamilton <rch@google.com>
Cc: jri@google.com; ekr@rtfm.com; Lubashev, Igor <ilubashe@akamai.com>; pmcmanus@mozilla.com; quic@ietf.org
Subject: Re: tcp rsts, data truncation, and the future of public res= et

=C2=A0

=C2=A0

On Tue, Feb 21, 2017 at 9:53 AM, Ryan Hamilton <<= a href=3D"mailto:rch@google.com" target=3D"_blank" class=3D"cremed">rch@goo= gle.com> wrote:

A CONNECTION_CLOSE immediately closes the connection. No data i= s retransmitted. It is not equivalent to delivering a FIN on all open strea= ms. I would say that the equivalent of a TCP fin (which is the graceful shutdown of one half of a bidirectional communicati= on) is a stream FIN. The CONNECTION_CLOSE sounds more like a TCP reset.<= /u>

=C2=A0

=C2=A0

would you open an iss= ue to add this type of language to the spec (potentially in both the transp= ort and loss drafts)? its really not defined afaict.. as it would alternati= vely make sense to retransmit unacked stuff after CLOSE - but then it wouldn't be behaving like reset (which= honestly I would rather it didn't behave like reset - reset is leads t= o pain.).

If the only differenc= e between public_reset and connection_close is in the auth (and I guess the= retransmitting of close as necessary?) perhaps they should share a name: p= ublic_connection_close or private_reset or somesuch?

=C2=A0

=C2=A0


--001a1141e6648cdaa5054910882f-- From nobody Tue Feb 21 12:56:51 2017 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 4E2521297C1 for ; Tue, 21 Feb 2017 12:56:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gp6izkBJfzT1 for ; Tue, 21 Feb 2017 12:56:48 -0800 (PST) Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFC21294B5 for ; Tue, 21 Feb 2017 12:56:48 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id s205so9174882oif.3 for ; Tue, 21 Feb 2017 12:56:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Cxmx+GFzek5n5i8jaqlB3tAM05f//rdWdYHhu8sQpqI=; b=TAYKvoVS79zx0j3mIapGhrMl1jN4Vvl/ikw3VCqaKGZx+ONOx6NkzNf8NLyjcExibb EngkJQvcKWv526EgiXlORtxvM0SFCbQXbxDtH7g62UpyTrR0rNUK55kmg+Oeyt4WoHIy uZj/qfMoX97ZTMbVTSej68TNKryxk1FYMbW+aRa5Id+kfVDGoWO3icUVCEY7KtQgadw8 NnGqHNL/1hCIE0vqD6rlcQEyly63xZhloTuxKMaZbrPdvCskz+XGxLm2Rtc5vhArB3L2 pxzRH4oiT7zfsjDWhQMv3H/Bag79uToDFkjCWuRBJ9q0nIK3ZV7o8pIZXHK66l/4lx50 Hitg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Cxmx+GFzek5n5i8jaqlB3tAM05f//rdWdYHhu8sQpqI=; b=JotKAeFewZNts+ZXcA0oZOK/dddGqP8wPHGxKhJifp8JxU2INUKkeKE542Ndj/5He7 UMFNwwfamWx19CU2ymrY2GcevWpZYn3zTyHlhqDp0IX4ZmJVBYG8wohSOxG6P8bR+CwC nFRZn9Oba6xP77w6LNu8dT1sRu/ijIrnbJageG2jS9Nxf1DrvmrBNqGUuKO1tHZScBmT 4NpkT8yoUTXejL3iqzI/AWDvwiub7B6WHBj01CA2M+ptHH91JNtioXJ+PzmLdd3FWI00 zX1liSsgQ0PrqmwK3stw7q75dU+oPGfwk5JwVBJP9KzESIqrLhoy+KXM8YBt6IJNxEoX yTCQ== X-Gm-Message-State: AMke39lleHXivicxPT0yFogZbd+oW22js2w0FEsMjqR81T7M/uQiC3RXf9xI0uqkeeoRQ8AY2T7s4UmKdu+XiQ== X-Received: by 10.202.214.209 with SMTP id n200mr1989207oig.56.1487710607845; Tue, 21 Feb 2017 12:56:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.226 with HTTP; Tue, 21 Feb 2017 12:56:47 -0800 (PST) In-Reply-To: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Duke Date: Tue, 21 Feb 2017 12:56:47 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Ryan Hamilton Content-Type: multipart/alternative; boundary=001a113ad9424f2f2c0549109eb9 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , "Lubashev, Igor" , Patrick McManus , "jri@google.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 20:56:50 -0000 --001a113ad9424f2f2c0549109eb9 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The draft could really use a clear description of a clean shutdown, similar to what Mike described. However: GOAWAY means that I will neither initiate streams nor accept new streams. So how am I to know that the other side is done initiating streams? It would be better if the GOAWAY were a sort of one-way connection FIN. On Tue, Feb 21, 2017 at 12:50 PM, Ryan Hamilton wrote: > > > On Tue, Feb 21, 2017 at 12:19 PM, Mike Bishop < > Michael.Bishop@microsoft.com> wrote: > >> The streams mean that you have a two-layer close to the connection, whic= h >> makes a graceful shutdown more complex. As I understand it, the =E2=80= =9Cclean=E2=80=9D >> connection close flow is: >> >> - GOAWAY =E2=80=93 no new streams can open (implicit RST of streams t= hat were >> racing the GOAWAY) >> - Service and FIN (or RST as needed) all existing streams >> - CONNECTION_CLOSE once all streams have closed and all data has been >> ACK=E2=80=99d >> >> =E2=80=8B*nod* > =E2=80=8B > >> Graceless shutdown is simple as ever. =F0=9F=98=8A If you skip straigh= t to the >> CONNECTION_CLOSE, that=E2=80=99s effectively a RST of every stream that= =E2=80=99s still >> open when you get there. >> > > Agreed. This makes sense to me and seems like the right way to think abou= t > things. > =E2=80=8B > >> It sounds like what you=E2=80=99re concerned about is the window after s= ending >> all stream data. If you transmit the CONNECTION_CLOSE too early, you ri= sk >> losing data in the final flight, either through loss or reordering of th= e >> CONNECTION_CLOSE ahead of data packets. >> > > =E2=80=8BSince QUIC connections are multiplexed, it is common to keep the= m around > for some period of idle in expectation of new streams being created. As a > result, it's common to only send the CONNECTION_CLOSE after that period > expires. (Or if there is some sort of fatal error on the connection.) > =E2=80=8B > >> It seems like the obvious API semantics would be similar to TCP=E2=80= =99s =E2=80=93 one >> option would GOAWAY, wait, send the CONNECTION_CLOSE, and finally return= . >> The other would send the CONNECTION_CLOSE immediately, and data falls wh= ere >> it may. However, that invites the same application behavior you see wit= h >> TCP today =E2=80=93 the application doesn=E2=80=99t want to sit around, = and will call the >> faster API if it has gotten everything it needs off the connection. >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Patrick >> McManus >> *Sent:* Tuesday, February 21, 2017 7:14 AM >> *To:* Ryan Hamilton >> *Cc:* jri@google.com; ekr@rtfm.com; Lubashev, Igor = ; >> pmcmanus@mozilla.com; quic@ietf.org >> *Subject:* Re: tcp rsts, data truncation, and the future of public reset >> >> >> >> >> >> On Tue, Feb 21, 2017 at 9:53 AM, Ryan Hamilton wrote: >> >> A CONNECTION_CLOSE immediately closes the connection. No data is >> retransmitted. It is not equivalent to delivering a FIN on all open >> streams. I would say that the equivalent of a TCP fin (which is the >> graceful shutdown of one half of a bidirectional communication) is a str= eam >> FIN. The CONNECTION_CLOSE sounds more like a TCP reset. >> >> >> >> >> >> would you open an issue to add this type of language to the spec >> (potentially in both the transport and loss drafts)? its really not defi= ned >> afaict.. as it would alternatively make sense to retransmit unacked stuf= f >> after CLOSE - but then it wouldn't be behaving like reset (which honestl= y I >> would rather it didn't behave like reset - reset is leads to pain.). >> >> If the only difference between public_reset and connection_close is in >> the auth (and I guess the retransmitting of close as necessary?) perhaps >> they should share a name: public_connection_close or private_reset or >> somesuch? >> >> >> >> >> > > --001a113ad9424f2f2c0549109eb9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The draft could really use a clear description of a clean = shutdown, similar to what Mike described. However:

GOAWAY= means that I will neither initiate streams nor accept new streams. So how = am I to know that the other side is done initiating streams? It would be be= tter if the GOAWAY were a sort of one-way connection FIN.
=

On Tue, Feb= 21, 2017 at 12:50 PM, Ryan Hamilton <rch@google.com> wrote:


On Tue, Feb 21, = 2017 at 12:19 PM, Mike Bishop <Michael.Bishop@microsoft.com> wrote:

The streams mean that you have a two-layer close to = the connection, which makes a graceful shutdown more complex.=C2=A0 As I un= derstand it, the =E2=80=9Cclean=E2=80=9D connection close flow is:

  • GOAWAY =E2=80=93 no new streams can open (implicit R= ST of streams that were racing the GOAWAY)
  • Service and FIN (or RST as needed) all existing streams<= /u>
  • CONNECTION_CLOSE once all streams have close= d and all data has been ACK=E2=80=99d
=E2=80=8B*nod*
=E2=80=8B<= /div>

Graceless shutdown is simple as ever.=C2=A0 =F0=9F=98=8A=C2=A0 If you skip straight to the CONNECTION_CLOSE, tha= t=E2=80=99s effectively a RST of every stream that=E2=80=99s still open whe= n you get there.


Agreed. This makes sense to me and seems like the right way to think ab= out things.
=E2=80=8B

It sounds like what you=E2=80=99re concerned = about is the window after sending all stream data.=C2=A0 If you transmit th= e CONNECTION_CLOSE too early, you risk losing data in the final flight, eit= her through loss or reordering of the CONNECTION_CLOSE ahead of data packets.


<= div class=3D"gmail_default" style=3D"font-family:"trebuchet ms",s= ans-serif">=E2=80=8BSince QUIC connections are multiplexed, it is common to= keep them around for some period of idle in expectation of new streams bei= ng created. As a result, it's common to only send the CONNECTION_CLOSE = after that period expires. (Or if there is some sort of fatal error on the = connection.)
=E2=80=8B

=C2=A0It seems like the obvious API semantics= would be similar to TCP=E2=80=99s =E2=80=93 one option would GOAWAY, wait,= send the CONNECTION_CLOSE, and finally return.=C2=A0 The other would send = the CONNECTION_CLOSE immediately, and data falls where it may.=C2=A0 Howeve= r, that invites the same application behavior you see with TCP today =E2=80= =93 the application doesn=E2=80=99t want to sit around, and will call the f= aster API if it has gotten everything it needs off the connection.

=C2=A0

From: QUIC [mailto:quic-= bounces@ietf.org] On Behalf Of Patrick McManus
Sent: Tuesday, February 21, 2017 7:14 AM
To: Ryan Hamilton <rch@google.com>
Cc: jri@google.com; ekr@rtfm.com; = Lubashev, Igor <ilubashe@akamai.com>; pmcmanus@mozilla.com; quic@ietf.org=
Subject: Re: tcp rsts, data truncation, and the future of public res= et

=C2=A0

=C2=A0

On Tue, Feb 21, 2017 at 9:53 AM, Ryan Hamilton <<= a href=3D"mailto:rch@google.com" class=3D"m_829067694466169163cremed" targe= t=3D"_blank">rch@google.com> wrote:

A CONNECTION_CLOSE immediately closes the connection. No data i= s retransmitted. It is not equivalent to delivering a FIN on all open strea= ms. I would say that the equivalent of a TCP fin (which is the graceful shutdown of one half of a bidirectional communicati= on) is a stream FIN. The CONNECTION_CLOSE sounds more like a TCP reset.<= /u>

=C2=A0

=C2=A0

would you open an iss= ue to add this type of language to the spec (potentially in both the transp= ort and loss drafts)? its really not defined afaict.. as it would alternati= vely make sense to retransmit unacked stuff after CLOSE - but then it wouldn't be behaving like reset (which= honestly I would rather it didn't behave like reset - reset is leads t= o pain.).

If the only differenc= e between public_reset and connection_close is in the auth (and I guess the= retransmitting of close as necessary?) perhaps they should share a name: p= ublic_connection_close or private_reset or somesuch?

=C2=A0

=C2=A0



--001a113ad9424f2f2c0549109eb9-- From nobody Tue Feb 21 14:02:25 2017 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 3814C129D28 for ; Tue, 21 Feb 2017 14:02:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.488 X-Spam-Level: X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 XdxydV-WC6Ko for ; Tue, 21 Feb 2017 14:02:21 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 50E23129D2D for ; Tue, 21 Feb 2017 14:02:21 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1cgIVn-0002MC-BM for quic@ietf.org; Tue, 21 Feb 2017 23:02:20 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1cgIVl-0007V3-UX for quic@ietf.org; Tue, 21 Feb 2017 17:02:18 -0500 Received: (qmail 22867 invoked from network); 21 Feb 2017 22:02:16 -0000 Received: from unknown (HELO [192.168.1.104]) (Authenticated-user:_huitema@huitema.net@[172.56.42.128]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 21 Feb 2017 22:02:16 -0000 To: Martin Duke , Ryan Hamilton References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> From: Christian Huitema Message-ID: <8888ebdd-a567-b550-7bdd-6c27a78c6fe9@huitema.net> Date: Tue, 21 Feb 2017 14:02:14 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Subject: Re: tcp rsts, data truncation, and the future of public reset X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49KxQtGn3AswOT8Z9YHdvpk1TugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXoAz7fh7Uf7T5yW4VNg4WehRcOb18WfxGyg6Om6u4YYm/UShK9Vomj3SOLU B3UB7eg5hjoyEb9Oq0NWpyO3vrfYnGR8JorokUtMqNDt1Oktij3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSB8y9Ga5iCmdJFIvDEJb+pKRQRCdMNhge1Unb77YyuZq5oTX7wXGfRCne2jcCKwN7iRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU2Z0wfN9VTx9JdR4F4pphrEJ0EukYkH0+QwgTkvGReJqS3AA1zi4L4OJ0M18xnuBW/6 592ULW4vfh/b1HrXegYtxdv0HXS0LGyCtWl7MG6/FXUxHIGhNZ9VOHf2UJ7o/ai6elFFgxvixKHD +ndZqoQq0JFb5sY5yvsuaKnQYvhP+274nM+117vLjWiTA8zC3e5qTjAEzQR26Rr0dPOgWImrit8G 3ADfAJ/PhwShhuOEbdpjXhV8g5C9ZVdQH0yPWSY= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , "Lubashev, Igor" , Patrick McManus , "jri@google.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 22:02:23 -0000 On 2/21/2017 12:56 PM, Martin Duke wrote: > The draft could really use a clear description of a clean shutdown, > similar to what Mike described. However: > > GOAWAY means that I will neither initiate streams nor accept new > streams. So how am I to know that the other side is done initiating > streams? It would be better if the GOAWAY were a sort of one-way > connection FIN. > What should happen if a single packet contains the Connection Close Frame and also a Stop Waiting frame with a delta = 0? -- Christian Huitema From nobody Tue Feb 21 15:00:03 2017 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 5FA8D127077 for ; Tue, 21 Feb 2017 15:00:01 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 3M13wtd2z4XW for ; Tue, 21 Feb 2017 14:59:57 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 68F0A126579 for ; Tue, 21 Feb 2017 14:59:57 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B8311433423; Tue, 21 Feb 2017 22:59:56 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A1494433402; Tue, 21 Feb 2017 22:59:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487717996; bh=tn1JOiadUHR841bg2svZBY3Hr2CkQ3Z4x8konr5fo+Q=; l=11881; h=From:To:CC:Date:References:In-Reply-To:From; b=AjXhJVCroN+3QWvZ4qEmUZe/M0HIwSXksQ6ibMjEwVXuz0/x8Do/JZqgt969Mybfd Uuk2KJ1E0VfmvNRIrQZajbzgU5mpYNaLgQX3p1Q3BYLcWMoCMR+lFd/5M812rxg9iA uWHcRBlln7CwOrJvJX+XXs0CiXAwuXwJfCia3i/Q= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 9DA051FC88; Tue, 21 Feb 2017 22:59:56 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 21 Feb 2017 17:59:55 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Tue, 21 Feb 2017 17:59:56 -0500 From: "Lubashev, Igor" To: "rch@google.com" , "pmcmanus@mozilla.com" , "Michael.Bishop@microsoft.com" Subject: RE: tcp rsts, data truncation, and the future of public reset Thread-Topic: tcp rsts, data truncation, and the future of public reset Thread-Index: AQHSi6tjprq3SA28S0CynFHnEtJTgKFy0yeAgAAIagCAAAAtAIAABM8A///y6r6AAHCOgIAADq0GgACOOYCAAAXOgIAAVXyA///Y45s= Date: Tue, 21 Feb 2017 22:59:55 +0000 Message-ID: <8d1174f25a324cbc864d38db468f1dc2@usma1ex-dag1mb5.msg.corp.akamai.com> References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_8d1174f25a324cbc864d38db468f1dc2usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2017 23:00:01 -0000 --_000_8d1174f25a324cbc864d38db468f1dc2usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > As I understand it, the =93clean=94 connection close flow is: > * GOAWAY =96 no new streams can open (implicit RST of streams that were r= acing the GOAWAY) > * Service and FIN (or RST as needed) all existing streams > * CONNECTION_CLOSE once all streams have closed and all data has been ACK= =92d I do not think this is sufficient. You need to talk about the the other sid= e's semantics on receipt of CONNECTION_CLOSE. In particular, is the receive= r of CONNECTION_CLOSE allowed to drop the connection state immediately? Or = is it required to deliver ACKed data to the application first? If it is req= uired to deliver ACKed data, is it all data or only data from properly clos= ed streams (i.e. excluding streams reset due to STREAM_RST or CONNECTION_CL= OSE). My preference for requiring the delivery of all data belonging to properly = closed streams and a SHOULD NOT for the delivery of any other data not yet = delivered. - Igor -----Original Message----- From: Mike Bishop [Michael.Bishop@microsoft.com] Received: Tuesday, 21 Feb 2017, 3:20PM To: Patrick McManus [pmcmanus@mozilla.com]; Ryan Hamilton [rch@google.com] CC: jri@google.com [jri@google.com]; ekr@rtfm.com [ekr@rtfm.com]; Lubashev,= Igor [ilubashe@akamai.com]; quic@ietf.org [quic@ietf.org] Subject: RE: tcp rsts, data truncation, and the future of public reset The streams mean that you have a two-layer close to the connection, which m= akes a graceful shutdown more complex. As I understand it, the =93clean=94= connection close flow is: * GOAWAY =96 no new streams can open (implicit RST of streams that were= racing the GOAWAY) * Service and FIN (or RST as needed) all existing streams * CONNECTION_CLOSE once all streams have closed and all data has been A= CK=92d Graceless shutdown is simple as ever. ?? If you skip straight to the CONN= ECTION_CLOSE, that=92s effectively a RST of every stream that=92s still ope= n when you get there. It sounds like what you=92re concerned about is the window after sending al= l stream data. If you transmit the CONNECTION_CLOSE too early, you risk lo= sing data in the final flight, either through loss or reordering of the CON= NECTION_CLOSE ahead of data packets. It seems like the obvious API semantics would be similar to TCP=92s =96 one= option would GOAWAY, wait, send the CONNECTION_CLOSE, and finally return. = The other would send the CONNECTION_CLOSE immediately, and data falls wher= e it may. However, that invites the same application behavior you see with= TCP today =96 the application doesn=92t want to sit around, and will call = the faster API if it has gotten everything it needs off the connection. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Patrick McManus Sent: Tuesday, February 21, 2017 7:14 AM To: Ryan Hamilton Cc: jri@google.com; ekr@rtfm.com; Lubashev, Igor ; pmc= manus@mozilla.com; quic@ietf.org Subject: Re: tcp rsts, data truncation, and the future of public reset On Tue, Feb 21, 2017 at 9:53 AM, Ryan Hamilton > wrote: A CONNECTION_CLOSE immediately closes the connection. No data is retransmit= ted. It is not equivalent to delivering a FIN on all open streams. I would = say that the equivalent of a TCP fin (which is the graceful shutdown of one= half of a bidirectional communication) is a stream FIN. The CONNECTION_CLO= SE sounds more like a TCP reset. would you open an issue to add this type of language to the spec (potential= ly in both the transport and loss drafts)? its really not defined afaict.. = as it would alternatively make sense to retransmit unacked stuff after CLOS= E - but then it wouldn't be behaving like reset (which honestly I would rat= her it didn't behave like reset - reset is leads to pain.). If the only difference between public_reset and connection_close is in the = auth (and I guess the retransmitting of close as necessary?) perhaps they s= hould share a name: public_connection_close or private_reset or somesuch? --_000_8d1174f25a324cbc864d38db468f1dc2usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > As I understand it, the =93clean=94 connection close = flow is:
> * GOAWAY =96 no new streams can open (implicit RST of streams that wer= e racing the GOAWAY)
> * Service and FIN (or RST as needed) all existing streams
> * CONNECTION_CLOSE once all streams have closed and all data has been = ACK=92d

I do not think this is sufficient. You need to talk about the the other sid= e's semantics on receipt of CONNECTION_CLOSE. In particular, is the receive= r of CONNECTION_CLOSE allowed to drop the connection state immediately? Or = is it required to deliver ACKed data to the application first? If it is required to deliver ACKed data, is= it all data or only data from properly closed streams (i.e. excluding stre= ams reset due to STREAM_RST or CONNECTION_CLOSE).

My preference for requiring the delivery of all data belonging to properly = closed streams and a SHOULD NOT for the delivery of any other data not yet = delivered.

- Igor



-----Original Message-----
From: Mike Bishop [Michael.Bishop@microsoft.com]
Received: Tuesday, 21 Feb 2017, 3:20PM
To: Patrick McManus [pmcmanus@mozilla.com]; Ryan Hamilton [rch@googl= e.com]
CC: jri@google.com [jri@google.com]; ekr@rtfm.com [ekr@rtfm.com]; Lu= bashev, Igor [ilubashe@akamai.com]; quic@ietf.org [quic@ietf.org]
Subject: RE: tcp rsts, data truncation, and the future of public res= et

The streams mean that you have a two-layer close to = the connection, which makes a graceful shutdown more complex.  As I un= derstand it, the =93clean=94 connection close flow is:

  • GOAWAY =96 no new = streams can open (implicit RST of streams that were racing the GOAWAY)
    • =
  • Service and FIN (o= r RST as needed) all existing streams
  • CONNECTION_CLOSE once all streams have closed and a= ll data has been ACK=92d

 

Graceless shutdown is simple as ever.  😊  If you skip straight to the CONNECTION_CLOSE, that= =92s effectively a RST of every stream that=92s still open when you get the= re.

 

It sounds like what you=92re concerned about is the = window after sending all stream data.  If you transmit the CONNECTION_= CLOSE too early, you risk losing data in the final flight, either through l= oss or reordering of the CONNECTION_CLOSE ahead of data packets.

 

It seems like the obvious API semantics would be sim= ilar to TCP=92s =96 one option would GOAWAY, wait, send the CONNECTION_CLOS= E, and finally return.  The other would send the CONNECTION_CLOSE imme= diately, and data falls where it may.  However, that invites the same application behavior you see with TCP today =96 the = application doesn=92t want to sit around, and will call the faster API if i= t has gotten everything it needs off the connection.

 

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of Patrick McManus
Sent: Tuesday, February 21, 2017 7:14 AM
To: Ryan Hamilton <rch@google.com>
Cc: jri@google.com; ekr@rtfm.com; Lubashev, Igor <ilubashe@akamai= .com>; pmcmanus@mozilla.com; quic@ietf.org
Subject: Re: tcp rsts, data truncation, and the future of public res= et

 

 

On Tue, Feb 21, 2017 at 9:53 AM, Ryan Hamilton <<= a href=3D"mailto:rch@google.com" target=3D"_blank">rch@google.com> w= rote:

A CONNECTION_CLOSE immediately closes the connection. No data i= s retransmitted. It is not equivalent to delivering a FIN on all open strea= ms. I would say that the equivalent of a TCP fin (which is the graceful shutdown of one half of a bidirectional communicati= on) is a stream FIN. The CONNECTION_CLOSE sounds more like a TCP reset.

 

 

would you open an iss= ue to add this type of language to the spec (potentially in both the transp= ort and loss drafts)? its really not defined afaict.. as it would alternati= vely make sense to retransmit unacked stuff after CLOSE - but then it wouldn't be behaving like reset (which hon= estly I would rather it didn't behave like reset - reset is leads to pain.)= .

If the only differenc= e between public_reset and connection_close is in the auth (and I guess the= retransmitting of close as necessary?) perhaps they should share a name: p= ublic_connection_close or private_reset or somesuch?

 

 

--_000_8d1174f25a324cbc864d38db468f1dc2usma1exdag1mb5msgcorpak_-- From nobody Tue Feb 21 20:11:45 2017 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 CC1E3129582 for ; Tue, 21 Feb 2017 20:11:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9kUjFx1unO2 for ; Tue, 21 Feb 2017 20:11:42 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E674129593 for ; Tue, 21 Feb 2017 20:11:00 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id n21so61344794qta.1 for ; Tue, 21 Feb 2017 20:11:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=myTPbh3VcPL/Eza64YQfoGoNRur6MbLyGRhmN2SVhU8=; b=D0QzoBFtz/CvgJhY22Kz8mdkRnbEkg+tpamvLm4XS/4a+K+PkT+q+iSbkTOSrjmtOZ kywXkcLW1Kzx3rSYGH1HUryqEQee/8pMdLPOGJbGwMG7NSrUf1tlxUzY0fWlJlZWhz3g LTIkwyxJXDeHyjfaVp9+um1puGrV4TP0CDuY17dMJZxrY8k7a4hNdmS2eXqxn1tT4K8Q z0xOoEZbuIBQRQ/0wSatXkg9hRe9lawookUidBCIa8h9+6anOvonhp5u3OP5i4tN+XEc hFrPK/SfW74O+O/+GBipUXbZXH+7ZQ1kwtcjjknmRJyADDxh90YhD1tMBf/s/ifcIRoZ 9GCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=myTPbh3VcPL/Eza64YQfoGoNRur6MbLyGRhmN2SVhU8=; b=isyOwnIAYZDWbXU3tHLhmFPlLS3IdY8YXpvCFF6udVJjacLRAIqC343SRR4b89SJm5 SW8c/5cMkH1j+SjLddVUNPJ9krgnuRLMpQoqcckSxe0co5SdSbv5JDPG8ZecOQc6VUVH dzEKvW71rgV8TjdoNERziHpK381rbzrmj2Uc695T5po4CByYZo6CyC4+L9vDeBmZZj59 N/fBA5fRp50qjp4s9em67MICQAPB3xuAWZ6Or/RAY9KbdGcwbk7OqbdYuLjlgqUPa/LM eDed0IlEucVVtOCUntkqJBUqhB0N7ipahBqTPQKYgqLrKgCpmudhvsbvf5ByDh2WMylr tHLA== X-Gm-Message-State: AMke39nJFlffU7OHh99jl899iOhI+De3saocCGDlNIPWaBWzILHPp3PJ1xGIX0zWzU2NVFW4llSZPLqpMogPjw== X-Received: by 10.200.3.214 with SMTP id z22mr17444196qtg.3.1487736659728; Tue, 21 Feb 2017 20:10:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 21 Feb 2017 20:10:59 -0800 (PST) In-Reply-To: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Wed, 22 Feb 2017 15:10:59 +1100 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Martin Duke Content-Type: multipart/alternative; boundary=f4030435c6c01f6095054916af81 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , "Lubashev, Igor" , Ryan Hamilton , Patrick McManus , "jri@google.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 04:11:44 -0000 --f4030435c6c01f6095054916af81 Content-Type: text/plain; charset=UTF-8 On 22 February 2017 at 07:56, Martin Duke wrote: > GOAWAY means that I will neither initiate streams nor accept new streams. > So how am I to know that the other side is done initiating streams? It > would be better if the GOAWAY were a sort of one-way connection FIN. If you do as we allow in HTTP/2, GOAWAY can be sent many times. GOAWAY with a high number allows you to continue creating streams, but puts the other side on notice of imminent shutdown. Sending again with a lower number promises that streams below that number are OK to complete, but higher numbers are all reset. And you can't sent with a higher number. At some point, you are either tired of waiting for streams to close, or they are all closed. Then send CONNECTION_CLOSE. On 22 February 2017 at 09:59, Lubashev, Igor wrote: > I do not think this is sufficient. You need to talk about the the other > side's semantics on receipt of CONNECTION_CLOSE. In particular, is the > receiver of CONNECTION_CLOSE allowed to drop the connection state > immediately? Or is it required to deliver ACKed data to the application > first? If it is required to deliver ACKed data, is it all data or only data > from properly closed streams (i.e. excluding streams reset due to > STREAM_RST or CONNECTION_CLOSE). Well, if there is anything outstanding on a stream, that's a hard cut on those things, throw them away. Unlike TCP, which sometimes throws state away on a RST, I would say that an implementation MUST allow completed streams that weren't delivered to complete. Any local state costs can continue to accrue to the application. I don't know what the relevance of ACKed is when talking about received data, you don't send an ACK for your own benefit. My preference for requiring the delivery of all data belonging to properly > closed streams and a SHOULD NOT for the delivery of any other data not yet > delivered. That's a MUST and a SHOULD NOT, which sounds fine. --f4030435c6c01f6095054916af81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On 22 February 2017 at 07:56, Martin Duke <martin.h.duke@gmail.com> wrote:
G= OAWAY means that I will neither initiate streams nor accept new streams. So= how am I to know that the other side is done initiating streams? It would = be better if the GOAWAY were a sort of one-way connection FIN.
=


If you do as we allow in HTT= P/2, GOAWAY can be sent many times.=C2=A0 GOAWAY with a high number allows = you to continue creating streams, but puts the other side on notice of immi= nent shutdown.=C2=A0 Sending again with a lower number promises that stream= s below that number are OK to complete, but higher numbers are all reset.= =C2=A0 And you can't sent with a higher number.=C2=A0 At some point, yo= u are either tired of waiting for streams to close, or they are all closed.= =C2=A0 Then send CONNECTION_CLOSE.

On 22 = February 2017 at 09:59, Lubashev, Igor <ilubashe@akamai.com> wrote:
I do not think this is sufficient. You need to talk about the the other=20 side's semantics on receipt of CONNECTION_CLOSE. In particular, is the= =20 receiver of CONNECTION_CLOSE allowed to drop the connection state=20 immediately? Or is it required to deliver ACKed data to the application first? If it is required to deliver ACKed data, is it all data or only data from properly closed streams (i.e.=20 excluding streams reset due to STREAM_RST or CONNECTION_CLOSE).

Well, if there is anything outstanding on a stream, that's a= hard cut on those things, throw them away.=C2=A0

Unlike TCP, which= sometimes throws state away on a RST, I would say that an implementation M= UST allow completed streams that weren't delivered to complete.=C2=A0 A= ny local state costs can continue to accrue to the application.

I do= n't know what the relevance of ACKed is when talking about received dat= a, you don't send an ACK for your own benefit.

My preference for requiring the delivery of all data belonging to=20 properly closed streams and a SHOULD NOT for the delivery of any other=20 data not yet delivered.

That's a MUST a= nd a SHOULD NOT, which sounds fine.
--f4030435c6c01f6095054916af81-- From nobody Wed Feb 22 08:46:17 2017 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 72E3512998D for ; Wed, 22 Feb 2017 08:46:15 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 z0b0MR_LQnbQ for ; Wed, 22 Feb 2017 08:46:14 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 6F38312940A for ; Wed, 22 Feb 2017 08:46:11 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F255216C7C6; Wed, 22 Feb 2017 16:46:10 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id DB51816C7AB; Wed, 22 Feb 2017 16:46:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487781970; bh=04Z68+uEYiYFRp+YybfdW0qGtaO5YiKMKoi/9m2GGKA=; l=22386; h=From:To:CC:Date:References:In-Reply-To:From; b=mdMcw8VhlHnv0Rfgz1ZqtxN43d3XQvyEu9gp/o6bwSNUGV7IaCZAYWRpgaxC9Qe3q Mhv0z2dKZbLExA8MULgl9l5Rv5Iv4JGNb6vH4aVI0BFbHI5mHC2AzF/A1BJn2wgylf Qdk549dbrmFCMBUR4AQCfIzR3Y2WRoBC/S+D6PIM= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id A8DBC1E07C; Wed, 22 Feb 2017 16:46:10 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 22 Feb 2017 11:46:10 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Wed, 22 Feb 2017 11:46:10 -0500 From: "Lubashev, Igor" To: Martin Thomson , Martin Duke Subject: RE: tcp rsts, data truncation, and the future of public reset Thread-Topic: tcp rsts, data truncation, and the future of public reset Thread-Index: AQHSi6tjprq3SA28S0CynFHnEtJTgKFy0yeAgAAIagCAAAAtAIAABM8A///y6r6AAHCOgIAADq0GgACOOYCAAAXOgIAAVXyAgAAImgCAAAGzgIAAeVCAgAB893A= Date: Wed, 22 Feb 2017 16:46:09 +0000 Message-ID: <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.243] Content-Type: multipart/alternative; boundary="_000_3e1e15a011f64543bf12e3571411b508usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , Ryan Hamilton , Patrick McManus , "jri@google.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 16:46:15 -0000 --_000_3e1e15a011f64543bf12e3571411b508usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIE15IHByZWZlcmVuY2UgZm9yIHJlcXVpcmluZyB0aGUgZGVsaXZlcnkgb2YgYWxsIGRhdGEg YmVsb25naW5nIHRvIHByb3Blcmx5IGNsb3NlZCBzdHJlYW1zIGFuZCBhIFNIT1VMRCBOT1QgZm9y IHRoZSBkZWxpdmVyeSBvZiBhbnkgb3RoZXIgZGF0YSBub3QgeWV0IGRlbGl2ZXJlZC4NCg0KVGhh dCdzIGEgTVVTVCBhbmQgYSBTSE9VTEQgTk9ULCB3aGljaCBzb3VuZHMgZmluZS4NCg0KR3JlYXQs IEkgYW0gZ2xhZCB5b3Ugc2VlIGl0IHRoZSBzYW1lIHdheSBhYm91dCBDT05ORUNUSU9OX0NMT1NF LiBUaGUgbmV4dCBxdWVzdGlvbiB3b3VsZCBiZSB3aGV0aGVyIHRoZSBzYW1lIGNhbiBiZSBzYWlk IGZvciBQVUJMSUNfUkVTRVQgYXMgd2VsbC4gSWYgd2UgcmVhbGx5IHdhbnQgdG8ga2VlcCB0aGUg dHdvIGlkZW50aWNhbCwgaXQgbWFrZXMgc2Vuc2UgdG8gcmVxdWlyZSB0aGUgc2FtZSBzZW1hbnRp Y3Mgb24gdGhlbS4gQW55IGNvdW50ZXItZXhhbXBsZXM/DQoNCg0KDQrDmCAgSSBkb24ndCBrbm93 IHdoYXQgdGhlIHJlbGV2YW5jZSBvZiBBQ0tlZCBpcyB3aGVuIHRhbGtpbmcgYWJvdXQgcmVjZWl2 ZWQgZGF0YQ0KDQpZb3UgYXJlIGNvcnJlY3QuIEFDS3MgZG8gbm90IG1hdHRlciBoZXJlLg0KDQoN Ci0gICAgICAgICAgSWdvcg0KDQoNCkZyb206IE1hcnRpbiBUaG9tc29uIFttYWlsdG86bWFydGlu LnRob21zb25AZ21haWwuY29tXQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkgMjEsIDIwMTcgMTE6 MTEgUE0NClRvOiBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb20+DQpDYzogUnlh biBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb20+OyBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BA bWljcm9zb2Z0LmNvbT47IGVrckBydGZtLmNvbTsgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFr YW1haS5jb20+OyBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVzQG1vemlsbGEuY29tPjsganJpQGdv b2dsZS5jb207IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiB0Y3AgcnN0cywgZGF0YSB0cnVu Y2F0aW9uLCBhbmQgdGhlIGZ1dHVyZSBvZiBwdWJsaWMgcmVzZXQNCg0KDQpPbiAyMiBGZWJydWFy eSAyMDE3IGF0IDA3OjU2LCBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb208bWFp bHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPj4gd3JvdGU6DQpHT0FXQVkgbWVhbnMgdGhhdCBJ IHdpbGwgbmVpdGhlciBpbml0aWF0ZSBzdHJlYW1zIG5vciBhY2NlcHQgbmV3IHN0cmVhbXMuIFNv IGhvdyBhbSBJIHRvIGtub3cgdGhhdCB0aGUgb3RoZXIgc2lkZSBpcyBkb25lIGluaXRpYXRpbmcg c3RyZWFtcz8gSXQgd291bGQgYmUgYmV0dGVyIGlmIHRoZSBHT0FXQVkgd2VyZSBhIHNvcnQgb2Yg b25lLXdheSBjb25uZWN0aW9uIEZJTi4NCg0KSWYgeW91IGRvIGFzIHdlIGFsbG93IGluIEhUVFAv MiwgR09BV0FZIGNhbiBiZSBzZW50IG1hbnkgdGltZXMuICBHT0FXQVkgd2l0aCBhIGhpZ2ggbnVt YmVyIGFsbG93cyB5b3UgdG8gY29udGludWUgY3JlYXRpbmcgc3RyZWFtcywgYnV0IHB1dHMgdGhl IG90aGVyIHNpZGUgb24gbm90aWNlIG9mIGltbWluZW50IHNodXRkb3duLiAgU2VuZGluZyBhZ2Fp biB3aXRoIGEgbG93ZXIgbnVtYmVyIHByb21pc2VzIHRoYXQgc3RyZWFtcyBiZWxvdyB0aGF0IG51 bWJlciBhcmUgT0sgdG8gY29tcGxldGUsIGJ1dCBoaWdoZXIgbnVtYmVycyBhcmUgYWxsIHJlc2V0 LiAgQW5kIHlvdSBjYW4ndCBzZW50IHdpdGggYSBoaWdoZXIgbnVtYmVyLiAgQXQgc29tZSBwb2lu dCwgeW91IGFyZSBlaXRoZXIgdGlyZWQgb2Ygd2FpdGluZyBmb3Igc3RyZWFtcyB0byBjbG9zZSwg b3IgdGhleSBhcmUgYWxsIGNsb3NlZC4gIFRoZW4gc2VuZCBDT05ORUNUSU9OX0NMT1NFLg0KT24g MjIgRmVicnVhcnkgMjAxNyBhdCAwOTo1OSwgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1h aS5jb208bWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb20+PiB3cm90ZToNCkkgZG8gbm90IHRoaW5r IHRoaXMgaXMgc3VmZmljaWVudC4gWW91IG5lZWQgdG8gdGFsayBhYm91dCB0aGUgdGhlIG90aGVy IHNpZGUncyBzZW1hbnRpY3Mgb24gcmVjZWlwdCBvZiBDT05ORUNUSU9OX0NMT1NFLiBJbiBwYXJ0 aWN1bGFyLCBpcyB0aGUgcmVjZWl2ZXIgb2YgQ09OTkVDVElPTl9DTE9TRSBhbGxvd2VkIHRvIGRy b3AgdGhlIGNvbm5lY3Rpb24gc3RhdGUgaW1tZWRpYXRlbHk/IE9yIGlzIGl0IHJlcXVpcmVkIHRv IGRlbGl2ZXIgQUNLZWQgZGF0YSB0byB0aGUgYXBwbGljYXRpb24gZmlyc3Q/IElmIGl0IGlzIHJl cXVpcmVkIHRvIGRlbGl2ZXIgQUNLZWQgZGF0YSwgaXMgaXQgYWxsIGRhdGEgb3Igb25seSBkYXRh IGZyb20gcHJvcGVybHkgY2xvc2VkIHN0cmVhbXMgKGkuZS4gZXhjbHVkaW5nIHN0cmVhbXMgcmVz ZXQgZHVlIHRvIFNUUkVBTV9SU1Qgb3IgQ09OTkVDVElPTl9DTE9TRSkuDQoNCldlbGwsIGlmIHRo ZXJlIGlzIGFueXRoaW5nIG91dHN0YW5kaW5nIG9uIGEgc3RyZWFtLCB0aGF0J3MgYSBoYXJkIGN1 dCBvbiB0aG9zZSB0aGluZ3MsIHRocm93IHRoZW0gYXdheS4NCg0KVW5saWtlIFRDUCwgd2hpY2gg c29tZXRpbWVzIHRocm93cyBzdGF0ZSBhd2F5IG9uIGEgUlNULCBJIHdvdWxkIHNheSB0aGF0IGFu IGltcGxlbWVudGF0aW9uIE1VU1QgYWxsb3cgY29tcGxldGVkIHN0cmVhbXMgdGhhdCB3ZXJlbid0 IGRlbGl2ZXJlZCB0byBjb21wbGV0ZS4gIEFueSBsb2NhbCBzdGF0ZSBjb3N0cyBjYW4gY29udGlu dWUgdG8gYWNjcnVlIHRvIHRoZSBhcHBsaWNhdGlvbi4NCg0KSSBkb24ndCBrbm93IHdoYXQgdGhl IHJlbGV2YW5jZSBvZiBBQ0tlZCBpcyB3aGVuIHRhbGtpbmcgYWJvdXQgcmVjZWl2ZWQgZGF0YSwg eW91IGRvbid0IHNlbmQgYW4gQUNLIGZvciB5b3VyIG93biBiZW5lZml0Lg0KTXkgcHJlZmVyZW5j ZSBmb3IgcmVxdWlyaW5nIHRoZSBkZWxpdmVyeSBvZiBhbGwgZGF0YSBiZWxvbmdpbmcgdG8gcHJv cGVybHkgY2xvc2VkIHN0cmVhbXMgYW5kIGEgU0hPVUxEIE5PVCBmb3IgdGhlIGRlbGl2ZXJ5IG9m IGFueSBvdGhlciBkYXRhIG5vdCB5ZXQgZGVsaXZlcmVkLg0KDQpUaGF0J3MgYSBNVVNUIGFuZCBh IFNIT1VMRCBOT1QsIHdoaWNoIHNvdW5kcyBmaW5lLg0K --_000_3e1e15a011f64543bf12e3571411b508usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBl OnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNv bG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0 LW9ubHk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdp bjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29y ZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0 LWlkOjM0Mzg3MTYxNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTc0MjYxMTM2MCAtMTAxOTY5NTQ1OCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMDps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjQ7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZhbWls eTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBs aXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1saXN0 LWlkOjk0MTg0MTgxMDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MTg0OTA2OTY2NiAtMTU1NDk5MjQzOCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2 NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTps ZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjQ7DQoJbXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVs DQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2 OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFw ZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi43NWluO3RleHQt aW5kZW50Oi0uMjVpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExp c3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNv LWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBS b21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+TXkgcHJl ZmVyZW5jZSBmb3IgcmVxdWlyaW5nIHRoZSBkZWxpdmVyeSBvZiBhbGwgZGF0YSBiZWxvbmdpbmcg dG8gcHJvcGVybHkgY2xvc2VkIHN0cmVhbXMgYW5kIGEgU0hPVUxEIE5PVCBmb3IgdGhlIGRlbGl2 ZXJ5IG9mIGFueSBvdGhlciBkYXRhIG5vdCB5ZXQgZGVsaXZlcmVkLjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi4yNWluIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouMjVp biI+VGhhdCdzIGEgTVVTVCBhbmQgYSBTSE9VTEQgTk9ULCB3aGljaCBzb3VuZHMgZmluZS4NCjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPkdyZWF0LCBJIGFtIGdsYWQgeW91IHNlZSBpdCB0aGUgc2FtZSB3YXkgYWJvdXQgQ09O TkVDVElPTl9DTE9TRS4gVGhlIG5leHQgcXVlc3Rpb24gd291bGQgYmUgd2hldGhlciB0aGUgc2Ft ZSBjYW4gYmUgc2FpZCBmb3IgUFVCTElDX1JFU0VUIGFzIHdlbGwuIElmIHdlIHJlYWxseSB3YW50 IHRvIGtlZXANCiB0aGUgdHdvIGlkZW50aWNhbCwgaXQgbWFrZXMgc2Vuc2UgdG8gcmVxdWlyZSB0 aGUgc2FtZSBzZW1hbnRpY3Mgb24gdGhlbS4gQW55IGNvdW50ZXItZXhhbXBsZXM/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFy YWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxldmVsMSBsZm8x Ij48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNwYW4g c3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsNCjwv c3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5JIGRvbid0IGtub3cgd2hhdCB0aGUgcmVsZXZh bmNlIG9mIEFDS2VkIGlzIHdoZW4gdGFsa2luZyBhYm91dCByZWNlaXZlZCBkYXRhPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+WW91IGFyZSBjb3JyZWN0LiBBQ0tzIGRvIG5vdCBtYXR0 ZXIgaGVyZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVs MSBsZm8yIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxl PSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBO ZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+SWdvcjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdt YWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBGZWJydWFyeSAyMSwgMjAxNyAx MToxMSBQTTxicj4NCjxiPlRvOjwvYj4gTWFydGluIER1a2UgJmx0O21hcnRpbi5oLmR1a2VAZ21h aWwuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUnlhbiBIYW1pbHRvbiAmbHQ7cmNoQGdvb2dsZS5j b20mZ3Q7OyBNaWtlIEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs7 IGVrckBydGZtLmNvbTsgTHViYXNoZXYsIElnb3IgJmx0O2lsdWJhc2hlQGFrYW1haS5jb20mZ3Q7 OyBQYXRyaWNrIE1jTWFudXMgJmx0O3BtY21hbnVzQG1vemlsbGEuY29tJmd0OzsganJpQGdvb2ds ZS5jb207IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHRjcCByc3RzLCBk YXRhIHRydW5jYXRpb24sIGFuZCB0aGUgZnV0dXJlIG9mIHB1YmxpYyByZXNldDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAyMiBGZWJydWFyeSAyMDE3IGF0IDA3OjU2 LCBNYXJ0aW4gRHVrZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1hcnRpbi5oLmR1a2VAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+bWFydGluLmguZHVrZUBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5HT0FXQVkg bWVhbnMgdGhhdCBJIHdpbGwgbmVpdGhlciBpbml0aWF0ZSBzdHJlYW1zIG5vciBhY2NlcHQgbmV3 IHN0cmVhbXMuIFNvIGhvdyBhbSBJIHRvIGtub3cgdGhhdCB0aGUgb3RoZXIgc2lkZSBpcyBkb25l IGluaXRpYXRpbmcgc3RyZWFtcz8gSXQgd291bGQgYmUgYmV0dGVyIGlmIHRoZSBHT0FXQVkgd2Vy ZSBhIHNvcnQgb2Ygb25lLXdheSBjb25uZWN0aW9uIEZJTi48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SWYgeW91IGRvIGFzIHdl IGFsbG93IGluIEhUVFAvMiwgR09BV0FZIGNhbiBiZSBzZW50IG1hbnkgdGltZXMuJm5ic3A7IEdP QVdBWSB3aXRoIGEgaGlnaCBudW1iZXIgYWxsb3dzIHlvdSB0byBjb250aW51ZSBjcmVhdGluZyBz dHJlYW1zLCBidXQgcHV0cyB0aGUgb3RoZXIgc2lkZSBvbiBub3RpY2Ugb2YgaW1taW5lbnQgc2h1 dGRvd24uJm5ic3A7IFNlbmRpbmcgYWdhaW4gd2l0aA0KIGEgbG93ZXIgbnVtYmVyIHByb21pc2Vz IHRoYXQgc3RyZWFtcyBiZWxvdyB0aGF0IG51bWJlciBhcmUgT0sgdG8gY29tcGxldGUsIGJ1dCBo aWdoZXIgbnVtYmVycyBhcmUgYWxsIHJlc2V0LiZuYnNwOyBBbmQgeW91IGNhbid0IHNlbnQgd2l0 aCBhIGhpZ2hlciBudW1iZXIuJm5ic3A7IEF0IHNvbWUgcG9pbnQsIHlvdSBhcmUgZWl0aGVyIHRp cmVkIG9mIHdhaXRpbmcgZm9yIHN0cmVhbXMgdG8gY2xvc2UsIG9yIHRoZXkgYXJlIGFsbCBjbG9z ZWQuJm5ic3A7IFRoZW4gc2VuZA0KIENPTk5FQ1RJT05fQ0xPU0UuPG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjIgRmVicnVhcnkgMjAxNyBhdCAwOTo1OSwg THViYXNoZXYsIElnb3IgJmx0OzxhIGhyZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG8gbm90IHRoaW5r IHRoaXMgaXMgc3VmZmljaWVudC4gWW91IG5lZWQgdG8gdGFsayBhYm91dCB0aGUgdGhlIG90aGVy IHNpZGUncyBzZW1hbnRpY3Mgb24gcmVjZWlwdCBvZiBDT05ORUNUSU9OX0NMT1NFLiBJbiBwYXJ0 aWN1bGFyLCBpcyB0aGUgcmVjZWl2ZXIgb2YgQ09OTkVDVElPTl9DTE9TRSBhbGxvd2VkIHRvIGRy b3AgdGhlIGNvbm5lY3Rpb24gc3RhdGUgaW1tZWRpYXRlbHk/IE9yIGlzIGl0IHJlcXVpcmVkDQog dG8gZGVsaXZlciBBQ0tlZCBkYXRhIHRvIHRoZSBhcHBsaWNhdGlvbiBmaXJzdD8gSWYgaXQgaXMg cmVxdWlyZWQgdG8gZGVsaXZlciBBQ0tlZCBkYXRhLCBpcyBpdCBhbGwgZGF0YSBvciBvbmx5IGRh dGEgZnJvbSBwcm9wZXJseSBjbG9zZWQgc3RyZWFtcyAoaS5lLiBleGNsdWRpbmcgc3RyZWFtcyBy ZXNldCBkdWUgdG8gU1RSRUFNX1JTVCBvciBDT05ORUNUSU9OX0NMT1NFKS48bzpwPjwvbzpwPjwv cD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpXZWxsLCBpZiB0aGVyZSBpcyBhbnl0aGluZyBvdXRz dGFuZGluZyBvbiBhIHN0cmVhbSwgdGhhdCdzIGEgaGFyZCBjdXQgb24gdGhvc2UgdGhpbmdzLCB0 aHJvdyB0aGVtIGF3YXkuJm5ic3A7DQo8YnI+DQo8YnI+DQpVbmxpa2UgVENQLCB3aGljaCBzb21l dGltZXMgdGhyb3dzIHN0YXRlIGF3YXkgb24gYSBSU1QsIEkgd291bGQgc2F5IHRoYXQgYW4gaW1w bGVtZW50YXRpb24gTVVTVCBhbGxvdyBjb21wbGV0ZWQgc3RyZWFtcyB0aGF0IHdlcmVuJ3QgZGVs aXZlcmVkIHRvIGNvbXBsZXRlLiZuYnNwOyBBbnkgbG9jYWwgc3RhdGUgY29zdHMgY2FuIGNvbnRp bnVlIHRvIGFjY3J1ZSB0byB0aGUgYXBwbGljYXRpb24uPGJyPg0KPGJyPg0KSSBkb24ndCBrbm93 IHdoYXQgdGhlIHJlbGV2YW5jZSBvZiBBQ0tlZCBpcyB3aGVuIHRhbGtpbmcgYWJvdXQgcmVjZWl2 ZWQgZGF0YSwgeW91IGRvbid0IHNlbmQgYW4gQUNLIGZvciB5b3VyIG93biBiZW5lZml0LjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHByZWZlcmVu Y2UgZm9yIHJlcXVpcmluZyB0aGUgZGVsaXZlcnkgb2YgYWxsIGRhdGEgYmVsb25naW5nIHRvIHBy b3Blcmx5IGNsb3NlZCBzdHJlYW1zIGFuZCBhIFNIT1VMRCBOT1QgZm9yIHRoZSBkZWxpdmVyeSBv ZiBhbnkgb3RoZXIgZGF0YSBub3QgeWV0IGRlbGl2ZXJlZC48bzpwPjwvbzpwPjwvcD4NCjwvYmxv Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYXQncyBhIE1VU1QgYW5k IGEgU0hPVUxEIE5PVCwgd2hpY2ggc291bmRzIGZpbmUuIDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_3e1e15a011f64543bf12e3571411b508usma1exdag1mb5msgcorpak_-- From nobody Wed Feb 22 08:58:48 2017 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 A6720129A56 for ; Wed, 22 Feb 2017 08:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 eLRvqiWoDi0T for ; Wed, 22 Feb 2017 08:58:46 -0800 (PST) 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 4C73C12998D for ; Wed, 22 Feb 2017 08:58:46 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id v200so4317467ywc.3 for ; Wed, 22 Feb 2017 08:58:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9VI3R+zhg/EaVIpSZfNn0IePZTh3XzPtzZ3Vav7jEVE=; b=n4HlyDGG1cP/QXGmNUcuA+5+yJ4flsgfgeJd05iCNmeE7KgxTKWVd8rilf69RHElRu sZeo/qQ4/4He8sVCScsEKWnoBAnXw68HhkD7VfoE+FGS9JWoVb0Qtrbvyhl161/s7by9 N03RPjjmept9Qa3/tW9WXHAzbNzOQ5cPL24SGp6vdLDmxGVBx5oaAWwZQxyiQ9401TSx ssVTsrC+HQAQdZ8DXWROCG7PUzekjSmO7TFR33dS6g9JszD57pM2g/+/t/SB1xWbsF5M 0ih/TZfejZWjURkEE4uFClAm+pZpeWEfNElK4jlj+XIbZBAxPCMxZ5My+l14G2rJ5f2h cJMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9VI3R+zhg/EaVIpSZfNn0IePZTh3XzPtzZ3Vav7jEVE=; b=GdjFFk9S8T5tOvlKZ2ZSmlrAqj3QO2LxcLPwE40/sO5y+RHfhFXYqku1eCA/wnD4cN /UxqNGoFsUvTuFTlFer+tfLOuSOYMT8xB4tbXX3hBFmCNeQe9aPlY/T2U061ADezErPS cAckDVAcghUHl2fajMbVltv/+yUfYjEXqfd7TLeHkPxbVFzteudcxhKS0FKRC4xr/mUd YhF/bBlwA2Q5sn0/1iVHX4vlOY8oTMosG59QCFYE/QeaGAuRAkbfkZVA+txxLRqnDRlo Z9Wg1jUXmp5wBJr4Y5O/C0DNdLxuW3ATotBEEHBpVR37WyDxsmZ8e34s3M5AnTyAaBBS pzIw== X-Gm-Message-State: AMke39mlt38GL6Xwr/Xmattndn9OVW3SW3pzZFnCZlH9XdAq3d6cMyrDIR3SE3IqlkXQ118eVxW4PngRN0VYKg== X-Received: by 10.129.92.2 with SMTP id q2mr26560645ywb.87.1487782725480; Wed, 22 Feb 2017 08:58:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.153.200 with HTTP; Wed, 22 Feb 2017 08:58:04 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Wed, 22 Feb 2017 08:58:04 -0800 Message-ID: Subject: Re: Alternate header proposal To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a114d6f16db0edc0549216863 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 16:58:47 -0000 --001a114d6f16db0edc0549216863 Content-Type: text/plain; charset=UTF-8 I'm generally positive on this proposal and I think it's an improvement on the current header, so I'd be fine with merging it on the principle of getting closer to what we want. With that said, there are some things I'm less happy about: On Tue, Feb 14, 2017 at 11:05 PM, Jana Iyengar wrote: > > > The remainder of the packet layout is the same regardless of type, the > difference being what rules for how to fill the values out and their > semantics. > > A client cleartext packet (type = 0x3c) then contains: > * Octets 1-8: connection ID (initially randomly chosen) > * Octets 9-12: version > * Octets 13-16: packet number (low 4 octets, starts at a random 31-bit > value) > * Octets 17+: payload > > The client MUST choose a random value and use it as the Connection ID > until the > server replies with a server-selected connection ID. The client's > connection ID > would have no semantic value, though they might serve to provide proof > that > the server received the packet via echoing, see below. > > A server cleartext packet (type = 0x3e) contains: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version (echoed) > * Octets 13-16: packet number (low 4 octets, random 31-bit initial value) > * Octets 17+: payload > > Both 0-RTT and 1-RTT packets with long-form headers contain: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version > * Octets 13-16: packet number (low 4 octets) > * Octets 17+: payload > > A version negotiation packet contains: > * Octets 1-8: connection ID (server-selected value, may be used in a > subsequent > connection to reach the same server) > * Octets 9-12: version (echoed) > * Octets 13-16: proof (first 4 octets of client-selected connection ID) > * Octets 17+: payload = version list > A public reset packet is sent when the server has no state for a received > packet. A server may therefore have to respond to either a long-form or a > short-form packet. A public reset packet contains: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version > * Octets 13-16: proof (octets 1-5 of received packet) > This "proof" stuff doesn't work properly for a hash-based public reset design, because the proof has to have high entropy. In general, I don't see a lot of value in overloading this field. Just put any required proof-type elements in a data payload. That's probably easier for an implementation anyway. Echoing details from the packet in both version negotiation and public > reset > provides return routeability (#244), while maintaining a consistent header > shape for all packets. > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Connection ID (optional) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number (1/2/4) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ``` > I'm still unpersuaded that it's that important to shave bits on the packet number here, especially on a per-packet basis. Also, maybe I'm missing something, but where's the key change bit? That seems to have gone missing and AFAICT you are still going to need it unless you have some thought of swapping to long headers during the key change period until you see acks or something else equally gross. -Ekr > The short form header is used after the version and 1-RTT keys are > negotiated. > The short form header is defined to be specific to a version. In this > version, > bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, > resulting > in the following packet types. > * Octet 0: Packet Type > * 04 and 84: 1-RTT packet (packet number size = 1) > * 14 and 94: 1-RTT packet (packet number size = 2) > * 34 and b4: 1-RTT packet (packet number size = 4) > * 0c and 8c: 1-RTT packet with Connection ID (packet number size = 1) > * 1c and 9c: 1-RTT packet with Connection ID (packet number size = 2) > * 3c and bc: 1-RTT packet with Connection ID (packet number size = 4) > > --001a114d6f16db0edc0549216863 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --001a1144a44e7b80f8054926f918-- From nobody Wed Feb 22 16:01:54 2017 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 048891293F5 for ; Wed, 22 Feb 2017 16:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-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=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 PVpdFpDOGxlm for ; Wed, 22 Feb 2017 16:01:51 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 290A7129C3F for ; Wed, 22 Feb 2017 16:01:51 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A947A433436; Thu, 23 Feb 2017 00:01:50 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 92756433430; Thu, 23 Feb 2017 00:01:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487808110; bh=EewojKxH/dQ1iNywY32EECPcfNNbiKZKas1B9ZCm/Wo=; l=4842; h=From:To:CC:Date:References:In-Reply-To:From; b=P+6oR1uxEM5h4/wIJPc5oNqeR7vOM2xdtKw1Y2TVzcGoSolYmSnGo5TjEg/SSnN+k MkVM+85U7W8IMJZP4e2EpcsTjz6srhZF9dzxwPhCRBqGRB44S9v6NA5D26XNYinslb bAdfHdCPP37kai5x0nmi9KFwyjVPpvE4VWrxV4zc= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 8E7BC1FC88; Thu, 23 Feb 2017 00:01:50 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 22 Feb 2017 19:01:49 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Wed, 22 Feb 2017 19:01:50 -0500 From: "Lubashev, Igor" To: Martin Thomson , Patrick McManus Subject: RE: tcp rsts, data truncation, and the future of public reset Thread-Topic: tcp rsts, data truncation, and the future of public reset Thread-Index: AQHSi6tjprq3SA28S0CynFHnEtJTgKFy0yeAgAAIagCAAAAtAIAABM8A///y6r6AAHCOgIAADq0GgACOOYCAAAXOgIAAVXyAgAAImgCAAAGzgIAAeVCAgAB893CAALzPgIAAAxOA//+w2MA= Date: Thu, 23 Feb 2017 00:01:49 +0000 Message-ID: <2b1d664dc2134d5fbdbe02d002751b5e@usma1ex-dag1mb5.msg.corp.akamai.com> References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.243] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , Ryan Hamilton , "jri@google.com" , "quic@ietf.org" , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:01:53 -0000 T24gMjMgRmVicnVhcnkgMjAxNyBhdCAwOTo1NCwgUGF0cmljayBNY01hbnVzIDxwbWNtYW51c0Bt b3ppbGxhLmNvbT4gd3JvdGU6DQo+IFVwb24gcmVjZWlwdCBvZiBDTE9TRS9SRVNFVCBhbiBhcHBs aWNhdGlvbiBNVVNUIE5PVCBhYmFuZG9uIGluLW9yZGVyIA0KPiBxdWV1ZWQgZGF0YSBmb3IgdGhl IGFwcGxpY2F0aW9uIGxheWVyICh3aGV0aGVyIG9yIG5vdCBpdCBoYXMgYSBGSU4gZm9yIA0KPiB0 aGUgc3RyZWFtIGl0IGlzIG9uKQ0KDQpJIGFtIG5vdCBsb3ZpbmcgdGhpcy4gIEkgdGhpbmsgaXQg dmVyeSBtdWNoIG1hdHRlcnMgd2hldGhlciBGSU4gaGFzIGJlZW4gcmVjZWl2ZWQgb24gdGhlIHN0 cmVhbSBBTkQgYWxsIGRhdGEgaGFzIGJlZW4gcmVjZWl2ZWQgb24gdGhlIHN0cmVhbSBwcmlvciB0 byB0aGUgQ09OTkVDVElPTl9DTE9TRS9QVUJMSUNfUkVTRVQuICBJbiBteSB2aWV3LCBvbmx5IHN1 Y2ggZGF0YSBNVVNUIGJlIGRlbGl2ZXJlZCwgYW5kIGFsbCBvdGhlciBkYXRhIChubyBGSU4gb3Ig bm90IGFsbCBkYXRhIHJlY2VpdmVkKSBTSE9VTEQgTk9UIGJlIGRlbGl2ZXJlZC4NCg0KRG9pbmcg YW55dGhpbmcgZWxzZSBoYXMgdHdvIHByb2JsZW1zOg0KMSkgQSAiTVVTVCIgZm9yIGFueSBvdGhl ciBjb25kaXRpb24gZG9lcyBub3QgcHJvdmlkZSBndWFyYW50ZWVzIHRvIHRoZSBzZW5kZXIgd2hh dCBkYXRhIHRoZSBhcHBsaWNhdGlvbiB3aWxsIHByb2Nlc3MsIHVubGVzcyB0aGUgc2VuZGVyIGlz IHZlcnkgY2FyZWZ1bCAodG9vIGVycm9yIHByb25lKS4gSWYgeW91J3ZlIHNlbnQgYWxsIHlvdXIg ZGF0YSBhbmQgaGF2ZSBzZWVuIGFsbCB0aGF0IGRhdGEgQUNLZWQsIGp1c3Qgc2VuZCBGSU4gaW4g dGhlIHNhbWUgcGFja2V0IGFzIENPTk5FQ1RJT05fQ0xPU0VELg0KDQoyYSkgSWYgU1RSRUFNX1JT VCByZXF1aXJlcyBhIHBlZXIgdG8gYWJhbmRvbiBpbi1vcmRlciBxdWV1ZWQgZGF0YSB3L28gRklO LCB0aGUgc2VtYW50aWNzIG9mIFBVQkxJQ19SRVNFVCB2cyBTVFJFQU1fUlNUIGFyZSB3ZWlyZCwg YXMgUFVCTElDX1JFU0VUIHJlc2V0cyBsZXNzIHN0YXRlIHRoYW4gU1RSRUFNX1JTVC4NCg0KMmIp IElmIFNUUkVBTV9SU1QgYWxzbyByZXF1aXJlcyBhIHBlZXIgdG8gZGVsaXZlciBpbi1vcmRlciBx dWV1ZWQgZGF0YSB3L28gRklOLCB0aGVuIHRoZXJlIGlzIG5vIHdheSB0byBhc2sgdGhlIHRyYW5z cG9ydCB0byBhYmFuZG9uIGl0cyBub24tZGVsaXZlcmVkIGRhdGEuICBIYXZpbmcgdGhhdCBkYXRh IGRyb3BwZWQgYnkgdHJhbnNwb3J0IG1heSBiZSBhIGRlc2lyZWQgZmVhdHVyZSBmb3IgdmFyaW91 cyBhcHBsaWNhdGlvbnMsIGluY2x1ZGluZyB0cmFuc2FjdGlvbmFsIHN5c3RlbXMgdGhhdCBtYXkg d2lzaCB0byBhYm9ydCBhbiBpbi1mbGlnaHQgdHJhbnNhY3Rpb24gKGFuZCB0aGVyZWZvcmUgZG8g bm90IHdhbnQgdGhlIHBlZXIgYXBwbGljYXRpb24gdG8gcHJvY2VzcyBhbGwgdGhlIGJ1ZmZlcmVk IGRhdGEganVzdCB0byB0aHJvdyBpdCBhd2F5IGxhdGVyKS4NCg0KLSBJZ29yDQoNClAuUy4NCg0K SXQgc2VlbXMgdGhhdCBhbiBvcmRlcmx5IHRlcm1pbmF0aW9uIG9mIGEgY29ubmVjdGlvbiBzaG91 bGQgbG9vayBsaWtlOg0KMS4gR09BV0FZIA0KMi4gUmVzZXQgYWxsIGluY29taW5nIHN0cmVhbXMN CjMuIEZpbmlzaCB3cml0aW5nIGFsbCBzdHJlYW1zLCBpbmNsdWRpbmcgdGhlIEZJTi4NCjQuIFdh aXQgZm9yIGFsbCBBQ0tzIChhbmQgcmV0cmFuc21pdCBhcyBuZWVkZWQpDQo1LiBDT05ORUNUSU9O X0NMT1NFDQoNClAuUC5TLg0KDQpTb21lIGNvc21ldGljIHJlbmFtaW5nIGlzIHdhcnJhbnRlZCwg aW5kZWVkLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNYXJ0aW4gVGhv bXNvbiBbbWFpbHRvOm1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQpTZW50OiBXZWRuZXNkYXks IEZlYnJ1YXJ5IDIyLCAyMDE3IDY6MDUgUE0NClRvOiBQYXRyaWNrIE1jTWFudXMgPHBtY21hbnVz QG1vemlsbGEuY29tPg0KQ2M6IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPjsg TWFydGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPjsgUnlhbiBIYW1pbHRvbiA8cmNo QGdvb2dsZS5jb20+OyBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT47 IGVrckBydGZtLmNvbTsganJpQGdvb2dsZS5jb207IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiB0Y3AgcnN0cywgZGF0YSB0cnVuY2F0aW9uLCBhbmQgdGhlIGZ1dHVyZSBvZiBwdWJsaWMgcmVz ZXQNCg0KT24gMjMgRmVicnVhcnkgMjAxNyBhdCAwOTo1NCwgUGF0cmljayBNY01hbnVzIDxwbWNt YW51c0Btb3ppbGxhLmNvbT4gd3JvdGU6DQo+IFVwb24gcmVjZWlwdCBvZiBDTE9TRS9SRVNFVCBh biBhcHBsaWNhdGlvbiBNVVNUIE5PVCBhYmFuZG9uIGluLW9yZGVyIA0KPiBxdWV1ZWQgZGF0YSBm b3IgdGhlIGFwcGxpY2F0aW9uIGxheWVyICh3aGV0aGVyIG9yIG5vdCBpdCBoYXMgYSBGSU4gZm9y IA0KPiB0aGUgc3RyZWFtIGl0IGlzIG9uKSB0aGUgd2F5IFRDUCBjdXJyZW50bHkgZG9lcy4gQnV0 IGl0IFNIT1VMRCg/KSBkcm9wIA0KPiBmdXR1cmUgcGFja2V0cyByZWNlaXZlZCBvbiB0aGUgY29u bmVjdGlvbiBhbmQgTVVTVCBOT1Qgc2VuZCBhbnkgb24gbW9yZSBvbiB0aGUgY29ubmVjdGlvbi4N Cj4NCj4gQ0xPU0UvUkVTRVQgaGFzIHRoZSBwb3RlbnRpYWwgZm9yIGRhdGEgbG9zcyBmb3IgYW55 IGRhdGEgd2hvc2UgYWNrIGhhcyANCj4gbm90IGJlZW4gcmVjZWl2ZWQgd2hlbiBDTE9TRS9SRVNF VCBpcyBnZW5lcmF0ZWQuIFtJIHJlYWxseSB0aGluayANCj4gc29tZXRoaW5nIGxpa2UgdGhhdCB3 b3VsZCBiZSBjbGFyaWZ5aW5nIHRleHQgaW4gdGhlIGRvY3VtZW50XQ0KDQpJIHRoaW5rIHRoYXQg bmF0dXJhbGx5IGZvbGxvd3MuICBPZiBjb3Vyc2UsIHRoZSByZWNlaXZlZCBtaWdodCBoYXZlIHJl Y2VpdmVkIGRhdGEgYW5kIHRoZXJlZm9yZSBjb3VsZCBoYXZlIGFjdGVkIHVwb24gaXQuICBUaGF0 IG1lYW5zIHRoYXQgdW5hY2tub3dsZWRnZWQgZGF0YSBpcyBpbiBhbiBhbWJpZ3VvdXMgc3RhdGUu ICBIb3BlZnVsbHkgdGhlIGdyYWNlZnVsIGNsb3NlIGhhcHBlbnMgb2Z0ZW4gZW5vdWdoIHRoYXQg dGhpcyBpc24ndCBhIGNvbW1vbiBzaXR1YXRpb24uDQoNCj4NCj4gaW1vIENMT1NFIG91Z2h0IHRv IGJlIG5hbWVkIFJFU0VULi4gZ2VuZXJpY2FsbHkgY2xvc2UgaXNuJ3Qgbm9ybWFsbHkgYSANCj4g ZGVzdHJ1Y3RpdmUgb3BlcmF0aW9uLCB3aGlsZSB0aGUgc2VtYW50aWNzIGhlcmUgY2VydGFpbmx5 IG1pZ2h0IGJlLg0KDQpSZXNldCBpbXBsaWVzIGFuIGFib3J0LCB3aGljaCBpc24ndCByZWFsbHkg dGhlIGNhc2UgZm9yIGEgZ3JhY2VmdWwgY2xvc2UuICBQZXJoYXBzIFRFUk1JTkFURSBoYXMgdGhl IHJpZ2h0IGNvbm5vdGF0aW9ucy4NCg0KKEkgd291bGQgYWxzbyBsaWtlIHRvIGNoYW5nZSBSU1Rf U1RSRUFNIHRvIENBTkNFTF9TVFJFQU0gYW5kIGEgZmV3IG90aGVyIGNvc21ldGljIGNoYW5nZXMu KQ0K From nobody Wed Feb 22 16:12:21 2017 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 CD918129CE4 for ; Wed, 22 Feb 2017 16:12:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 mTekrNZ-PuN8 for ; Wed, 22 Feb 2017 16:12:18 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id 7B74A129445 for ; Wed, 22 Feb 2017 16:12:18 -0800 (PST) Received: from mail-qk0-f177.google.com (mail-qk0-f177.google.com [209.85.220.177]) by linode64.ducksong.com (Postfix) with ESMTPSA id 021BB3A0BC for ; Wed, 22 Feb 2017 19:12:18 -0500 (EST) Received: by mail-qk0-f177.google.com with SMTP id n127so18598486qkf.0 for ; Wed, 22 Feb 2017 16:12:18 -0800 (PST) X-Gm-Message-State: AMke39kVPwnTm5YHjwAzSTs+/nOoLNbLdC05mSwVn1RNJ6d7cxn7vLk9ofpW0rJf2Eyb5DB/xC6Fc/kruIW/Vw== X-Received: by 10.55.43.213 with SMTP id r82mr38807963qkr.28.1487808737720; Wed, 22 Feb 2017 16:12:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.65 with HTTP; Wed, 22 Feb 2017 16:12:17 -0800 (PST) In-Reply-To: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> From: Patrick McManus Date: Wed, 22 Feb 2017 19:12:17 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114943984edf5205492777e3 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , "Lubashev, Igor" , Ryan Hamilton , Patrick McManus , "jri@google.com" , "quic@ietf.org" , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:12:19 -0000 --001a114943984edf5205492777e3 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 22, 2017 at 6:05 PM, Martin Thomson wrote: > think that naturally follows. Of course, the received might have > received data and therefore could have acted upon it. That means that > unacknowledged data is in an ambiguous state. > indeed - but that's the state of things as soon as it is transmitted. no takebacks as my 7 yr old says. --001a114943984edf5205492777e3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Wed, Feb 22, 2017 at 6:05 PM, Martin Thomson <martin.thomson@gma= il.com> wrote:
think that naturally follows.= =C2=A0 Of course, the received might have
received data and therefore could have acted upon it.=C2=A0 That means that=
unacknowledged data is in an ambiguous state.=C2=A0


indeed - but that's the stat= e of things as soon as it is transmitted. no takebacks as my 7 yr old says.=
--001a114943984edf5205492777e3-- From nobody Wed Feb 22 16:20:33 2017 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 EBE5A12940E for ; Wed, 22 Feb 2017 16:20:31 -0800 (PST) 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 Wy9K4adCqdj4 for ; Wed, 22 Feb 2017 16:20:31 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 94D7C1293F4 for ; Wed, 22 Feb 2017 16:20:30 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id z127so9398719lfa.2 for ; Wed, 22 Feb 2017 16:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=+CWFHYtgVZBvpjMsZ5MuYxBMtA62v4iHeIxUWzKCMVc=; b=SqLM93I5Drg6nYoSHVn3jxi18eKdPsA8v3LHDRcTaq6zFItW/jxCcCBCdqSwisqYLc EXvkg7/4apoJm+31l+m56xQIV8ePwRkTXhrXr6ElGLXzOdIAlNuOvMEzNW6J41qj8hUC krnaPUu4ia7rALMZq9HtdYH7QmqrQjEQATkm79U+CdFwKfTAfPN7eFBgkh8WUHneqpEM 0kxqn9UWjVfCST/0BSKzhy1HOWjLmySdprjU5w6jOlLThggGRgLN3oE76fMrH+RsNZ/b S48cSlFUoMNqsZfaou0l3a+6ykUXEHOd4qtxP+asa4DQ6ho/taT2TCATpdMokEUMh3hv TMKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=+CWFHYtgVZBvpjMsZ5MuYxBMtA62v4iHeIxUWzKCMVc=; b=nj4Ru/HOqXeZgGScT/5j1XJ6Nfm9GdH9NNLYj92p4TcYTiHFDk6qGs0HfvAq7WqU0i AGtcahqVMDBATpMiDxhLdDu1V9dIsd7PmrrpP1AHTZJBdkMLWiLILazuo0Oy9wN4iTS4 eX1bS4Ok+OsuQ/1SVoayL3K4RqirXtfjIxBdCeIIJcdetB7ZhgL+mpYakJB2h2ekZCbx ot3KREMoKLrrSiPv9pr3NIkpgUngHVvlZxuyaYgwo+O10rNKVXx5R0xUsS/qWKmjfyLb njVmwUBiFiDgQmjqmrXa6vYZgWbFiNf5E1Ujzm16IypRZJzdDZrCS1xKUntiTFoc4g3f i1Yg== X-Gm-Message-State: AMke39mF0Z0SwsWC1k9mgetZ+5nvsdgBLiOkYj76WdSKT0MeW9BN+CwRunvEJn5QepU5mvU4ytTdUkWmHRk9dA== X-Received: by 10.46.81.18 with SMTP id f18mr9099608ljb.136.1487809228617; Wed, 22 Feb 2017 16:20:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.75.25 with HTTP; Wed, 22 Feb 2017 16:20:28 -0800 (PST) From: Martin Thomson Date: Thu, 23 Feb 2017 11:20:28 +1100 Message-ID: Subject: Orderly close (was Re: tcp rsts, data truncation, and the future of public reset) To: "Lubashev, Igor" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , Ryan Hamilton , Patrick McManus , "jri@google.com" , "quic@ietf.org" , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:20:32 -0000 On 23 February 2017 at 11:01, Lubashev, Igor wrote: > It seems that an orderly termination of a connection should look like: > 1. GOAWAY > 2. Reset all incoming streams > 3. Finish writing all streams, including the FIN. > 4. Wait for all ACKs (and retransmit as needed) > 5. CONNECTION_CLOSE On step 2, GOAWAY creates an implicit reset for all streams higher than the indicated number. You don't need to reset any streams with higher numbered identifiers. On step 3, you need to handle all streams up to the GOAWAY value by either sending a FIN OR by sending a reset. You are definitely right that you need to wait for those to be acknowledged in step 4. Would it be useful to include a short section on shutdown that covered these nuances? From nobody Wed Feb 22 16:26:42 2017 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 4F6EB129CF4 for ; Wed, 22 Feb 2017 16:26:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 yPP1WvJ4jtVA for ; Wed, 22 Feb 2017 16:26:26 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id A2319129D1D for ; Wed, 22 Feb 2017 16:26:20 -0800 (PST) Received: from mail-qk0-f172.google.com (mail-qk0-f172.google.com [209.85.220.172]) by linode64.ducksong.com (Postfix) with ESMTPSA id 3D1233A0BC for ; Wed, 22 Feb 2017 19:26:20 -0500 (EST) Received: by mail-qk0-f172.google.com with SMTP id n127so18807642qkf.0 for ; Wed, 22 Feb 2017 16:26:20 -0800 (PST) X-Gm-Message-State: AMke39k6yc4JmdM3qYWlIb4grDUuYWL9jlMpTX5mFEoyXYT1bnMKvOg+WOtWh6Ev63rNCJZ0RLdC9SntVkyI+w== X-Received: by 10.55.43.213 with SMTP id r82mr38862347qkr.28.1487809580041; Wed, 22 Feb 2017 16:26:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.65 with HTTP; Wed, 22 Feb 2017 16:26:19 -0800 (PST) In-Reply-To: <2b1d664dc2134d5fbdbe02d002751b5e@usma1ex-dag1mb5.msg.corp.akamai.com> References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> <2b1d664dc2134d5fbdbe02d002751b5e@usma1ex-dag1mb5.msg.corp.akamai.com> From: Patrick McManus Date: Wed, 22 Feb 2017 19:26:19 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: "Lubashev, Igor" Content-Type: multipart/alternative; boundary=001a11494398832c7a054927a970 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , Ryan Hamilton , Patrick McManus , "jri@google.com" , "quic@ietf.org" , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:26:27 -0000 --001a11494398832c7a054927a970 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 22, 2017 at 7:01 PM, Lubashev, Igor wrote: > On 23 February 2017 at 09:54, Patrick McManus > wrote: > > Upon receipt of CLOSE/RESET an application MUST NOT abandon in-order > > queued data for the application layer (whether or not it has a FIN for > > the stream it is on) > > I am not loving this. I think it very much matters whether FIN has been > received on the stream AND all data has been received on the stream prior > to the CONNECTION_CLOSE/PUBLIC_RESET. In my view, only such data MUST be > delivered, and all other data (no FIN or not all data received) SHOULD NOT > be delivered. > > If we do it the way I suggested then we get the nice property that no data is lost for which an ack has been received before generating a connection_close (modulo crash etc..) - which is a major improvement over classic TCP which routinely loses data in surprising ways for application developers (see endnotes in the first message in this thread). Doing it the other way (requiring the FIN) just creates ambiguity and race conditions about whether the data has already been streamed to the application. It doesn't create a property you can rely on. I don't think we should have a mechanism designed to "take back" already transmitted data - an application can create that semantic through an application specific signal on another stream if need be, it doesn't need to overload the shutdown behavior. I would hope STREAM_RST would match. (I can't find any text right now on the topic..) It seems that an orderly termination of a connection should look like: > 1. GOAWAY > 2. Reset all incoming streams > 3. Finish writing all streams, including the FIN. > 4. Wait for all ACKs (and retransmit as needed) > 5. CONNECTION_CLOSE > > basically agree, but you don't need #2 because of the last-good-stream-id param of goaway. the rsts are implied. I think TERMINATE sounds like a lovely shade of bikeshed. --001a11494398832c7a054927a970 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Feb 22, 2017 at 7:01 PM, Lubashev, Igor <<= a href=3D"mailto:ilubashe@akamai.com" target=3D"_blank">ilubashe@akamai.com= > wrote:
On 23 February 2017 at 09:54, Patrick McManus <<= a href=3D"mailto:pmcmanus@mozilla.com">pmcmanus@mozilla.com> wrote:<= br> > Upon receipt of CLOSE/RESET an application MUST NOT abandon in-order > queued data for the application layer (whether or not it has a FIN for=
> the stream it is on)

I am not loving this.=C2=A0 I think it very much matters whether FIN= has been received on the stream AND all data has been received on the stre= am prior to the CONNECTION_CLOSE/PUBLIC_RESET.=C2=A0 In my view, only such = data MUST be delivered, and all other data (no FIN or not all data received= ) SHOULD NOT be delivered.

If we do it the way I sugg= ested then we get the nice property that no data is lost for which an ack has been received=20 before generating a connection_close (modulo crash etc..) - which is a majo= r improvement over classic TCP which routinely loses data in surprising ways for application= =20 developers (see endnotes in the first message in this thread).

Doing it the other way (requiring the FIN) just creates ambiguity and race=20 conditions about whether the data has already been streamed to the=20 application. It doesn't create a property you can rely on. I don't = think we should have a mechanism designed to "take back" already trans= mitted=20 data - an application can create that semantic through an application=20 specific signal on another stream if need be, it doesn't need to overlo= ad the=20 shutdown behavior.

=C2=A0I would hope STREAM_RST would ma= tch. (I can't find any text right now on the topic..)

It seems that an orderly termination of a connection should look like:
1. GOAWAY
2. Reset all incoming streams
3. Finish writing all streams, including the FIN.
4. Wait for all ACKs (and retransmit as needed)
5. CONNECTION_CLOSE


basically agree, but you don't nee= d #2 because of the last-good-stream-id param of goaway. the rsts are impli= ed.

I think TERMINATE sounds like a lovely shade of bikes= hed.
=C2=A0

--001a11494398832c7a054927a970-- From nobody Wed Feb 22 16:27:20 2017 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 37138129D3E for ; Wed, 22 Feb 2017 16:27:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 RG_aRnEFLfhN for ; Wed, 22 Feb 2017 16:27:16 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0115.outbound.protection.outlook.com [104.47.38.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22D13129CF4 for ; Wed, 22 Feb 2017 16:26:58 -0800 (PST) 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=m+dkkJssWtM5pMi6Yg6/KkM3UAMCM7/iLhOE5kRK4II=; b=c5X3dQqb9lVrwLgQljQz7zMwEuWigNzxRUbzltGzCiri8tsg/zKZC9NcxyTQEx0aFWnWNHKhBpOowFRtW47IKFwzF6M2oeasjrjU8uye2+arg9LHEGrLQAnlB5I+QXqfuUdPo8ANo/ziB73cbk4Lr+C66Jzh/K5cjmuDVkmAslU= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 00:26:54 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 00:26:54 +0000 From: Mike Bishop To: "Lubashev, Igor" , Martin Thomson , Patrick McManus Subject: RE: tcp rsts, data truncation, and the future of public reset Thread-Topic: tcp rsts, data truncation, and the future of public reset Thread-Index: AQHSi6tlLSNFL2QWbkadxBq6o9w3M6FybpKAgAAIagCAAAAtAIAABM4AgABXgACAABy8gIAAYn4AgAA6aYCAAAXNgIAAUnPAgAALowCAAAGzgIAAeVGAgADS/oCAAGbHgIAAAxOAgAAP34CAAAUJcA== Date: Thu, 23 Feb 2017 00:26:54 +0000 Message-ID: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> <2b1d664dc2134d5fbdbe02d002751b5e@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: <2b1d664dc2134d5fbdbe02d002751b5e@usma1ex-dag1mb5.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: akamai.com; dkim=none (message not signed) header.d=none;akamai.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:5::51f] x-ms-office365-filtering-correlation-id: 6355e127-1eb7-4fdb-3a88-08d45b82ab90 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:lix/8utI2OTY8m373WAA2XZENgrWs0FtHW0x5qb/H0JU7zAsfRunBdwJTDai3raSLJ0dAvfMmd7FVUKMzz5zS+trb7eSYsWfe1wA0vUzwJSyf6cxstPIqvYUjhUZKwWYlvdfOfpJLerLEDqiKAB8nphiV/neJKMA9RSgrNwb98S5UY2kCPRQ5dUBa3nsUKl8LZq9+J0mcantSPmu5FT0CCoe9b+p+ng5LTpMg3yCFDusaYKSpNA5l2VZraQvxOcgyl9VufuL6kzTIque+azaekA9UD0J46A0+VLU4RMFu9WhGZAQI+abS0bjFdF8/z20yp4u87o4NSZE+z9Rkfkv2QKz/JGU6tv9HQYDWgpXrTs= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(278428928389397)(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39850400002)(39450400003)(39410400002)(24454002)(377454003)(51444003)(13464003)(122556002)(7696004)(4326007)(53936002)(86612001)(229853002)(6246003)(3660700001)(6436002)(92566002)(3280700002)(2906002)(86362001)(38730400002)(5660300001)(6506006)(102836003)(189998001)(6116002)(8990500004)(8676002)(5005710100001)(53546006)(50986999)(10290500002)(10090500001)(93886004)(76176999)(305945005)(106116001)(8936002)(33656002)(54356999)(39060400002)(2950100002)(7736002)(9686003)(99286003)(55016002)(74316002)(54906002)(77096006)(81166006)(25786008)(551934003)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 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: 23 Feb 2017 00:26:54.4851 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Cc: "jri@google.com" , "ekr@rtfm.com" , "quic@ietf.org" , Martin Duke , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:27:19 -0000 SWYgd2UgbW92ZSB0byB1bmlkaXJlY3Rpb25hbCByZXNldHMsIEknbGwgbm90ZSB0aGF0IHlvdSBj YW4gY29tcGxldGVseSBpZ25vcmUgYSBSU1RfU1RSRUFNIHRoYXQgYXJyaXZlcyBhZnRlciB0aGUg c3RyZWFtIGhhcyBhbHJlYWR5IGNsb3NlZCAoaS5lLiBhbGwgZGF0YSBhbmQgRklOKS4gIFRoZSBz ZW1hbnRpY3Mgb2YgYSBSU1RfU1RSRUFNIHdvdWxkIGJlICJJIHdpbGwgbm8gbG9uZ2VyIGF0dGVt cHQgdG8gcmV0cmFuc21pdCBkYXRhIG9uIHRoaXMgc3RyZWFtOyBpZiB5b3UgaGF2ZW4ndCByZWNl aXZlZCBpdCwgeW91J3JlIG5vdCBnb2luZyB0by4iICBBbiBpbXBsZW1lbnRhdGlvbiBjb3VsZCAo YW5kIHBlcmhhcHMgU0hPVUxEKSBzdGlsbCBkZWxpdmVyIGFsbCBkYXRhIGlmIHRoZSBmdWxsIHNl cXVlbmNlIHdhcyByZWNlaXZlZCBhbmQgYXNzZW1ibGVkLiAgVGhhdCB3b3VsZCBoYXZlIHRoZSBh ZHZhbnRhZ2Ugb2YgbWFraW5nIHRoYXQgcnVsZSBjb25zaXN0ZW50Lg0KDQpIb3dldmVyLCB0aGUg c3RyZWFtIGluIHRoZSByZXR1cm4gZGlyZWN0aW9uIG1pZ2h0IGFsc28gaGF2ZSBiZWVuIGNsb3Nl ZCwgZS5nLiBieSBhIFJFUVVFU1RfUlNUIG9yIGEgY29ubmVjdGlvbi1sZXZlbCBhY3Rpb24uICBU aGUgYXBwbGljYXRpb24gbGF5ZXIsIHBhcnRpY3VsYXJseSBhIHNlcnZlciwgd291bGQgbmVlZCB0 byBjaGVjayByZXR1cm4tc3RyZWFtIGxpdmVuZXNzIGJlZm9yZSBhY3Rpbmcgb24gYSByZXF1ZXN0 LCBpbiB0aGlzIGNhc2UuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMdWJh c2hldiwgSWdvciBbbWFpbHRvOmlsdWJhc2hlQGFrYW1haS5jb21dIA0KU2VudDogV2VkbmVzZGF5 LCBGZWJydWFyeSAyMiwgMjAxNyA0OjAyIFBNDQpUbzogTWFydGluIFRob21zb24gPG1hcnRpbi50 aG9tc29uQGdtYWlsLmNvbT47IFBhdHJpY2sgTWNNYW51cyA8cG1jbWFudXNAbW96aWxsYS5jb20+ DQpDYzogTWFydGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPjsgUnlhbiBIYW1pbHRv biA8cmNoQGdvb2dsZS5jb20+OyBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0 LmNvbT47IGVrckBydGZtLmNvbTsganJpQGdvb2dsZS5jb207IHF1aWNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJFOiB0Y3AgcnN0cywgZGF0YSB0cnVuY2F0aW9uLCBhbmQgdGhlIGZ1dHVyZSBvZiBwdWJs aWMgcmVzZXQNCg0KT24gMjMgRmVicnVhcnkgMjAxNyBhdCAwOTo1NCwgUGF0cmljayBNY01hbnVz IDxwbWNtYW51c0Btb3ppbGxhLmNvbT4gd3JvdGU6DQo+IFVwb24gcmVjZWlwdCBvZiBDTE9TRS9S RVNFVCBhbiBhcHBsaWNhdGlvbiBNVVNUIE5PVCBhYmFuZG9uIGluLW9yZGVyIA0KPiBxdWV1ZWQg ZGF0YSBmb3IgdGhlIGFwcGxpY2F0aW9uIGxheWVyICh3aGV0aGVyIG9yIG5vdCBpdCBoYXMgYSBG SU4gZm9yIA0KPiB0aGUgc3RyZWFtIGl0IGlzIG9uKQ0KDQpJIGFtIG5vdCBsb3ZpbmcgdGhpcy4g IEkgdGhpbmsgaXQgdmVyeSBtdWNoIG1hdHRlcnMgd2hldGhlciBGSU4gaGFzIGJlZW4gcmVjZWl2 ZWQgb24gdGhlIHN0cmVhbSBBTkQgYWxsIGRhdGEgaGFzIGJlZW4gcmVjZWl2ZWQgb24gdGhlIHN0 cmVhbSBwcmlvciB0byB0aGUgQ09OTkVDVElPTl9DTE9TRS9QVUJMSUNfUkVTRVQuICBJbiBteSB2 aWV3LCBvbmx5IHN1Y2ggZGF0YSBNVVNUIGJlIGRlbGl2ZXJlZCwgYW5kIGFsbCBvdGhlciBkYXRh IChubyBGSU4gb3Igbm90IGFsbCBkYXRhIHJlY2VpdmVkKSBTSE9VTEQgTk9UIGJlIGRlbGl2ZXJl ZC4NCg0KRG9pbmcgYW55dGhpbmcgZWxzZSBoYXMgdHdvIHByb2JsZW1zOg0KMSkgQSAiTVVTVCIg Zm9yIGFueSBvdGhlciBjb25kaXRpb24gZG9lcyBub3QgcHJvdmlkZSBndWFyYW50ZWVzIHRvIHRo ZSBzZW5kZXIgd2hhdCBkYXRhIHRoZSBhcHBsaWNhdGlvbiB3aWxsIHByb2Nlc3MsIHVubGVzcyB0 aGUgc2VuZGVyIGlzIHZlcnkgY2FyZWZ1bCAodG9vIGVycm9yIHByb25lKS4gSWYgeW91J3ZlIHNl bnQgYWxsIHlvdXIgZGF0YSBhbmQgaGF2ZSBzZWVuIGFsbCB0aGF0IGRhdGEgQUNLZWQsIGp1c3Qg c2VuZCBGSU4gaW4gdGhlIHNhbWUgcGFja2V0IGFzIENPTk5FQ1RJT05fQ0xPU0VELg0KDQoyYSkg SWYgU1RSRUFNX1JTVCByZXF1aXJlcyBhIHBlZXIgdG8gYWJhbmRvbiBpbi1vcmRlciBxdWV1ZWQg ZGF0YSB3L28gRklOLCB0aGUgc2VtYW50aWNzIG9mIFBVQkxJQ19SRVNFVCB2cyBTVFJFQU1fUlNU IGFyZSB3ZWlyZCwgYXMgUFVCTElDX1JFU0VUIHJlc2V0cyBsZXNzIHN0YXRlIHRoYW4gU1RSRUFN X1JTVC4NCg0KMmIpIElmIFNUUkVBTV9SU1QgYWxzbyByZXF1aXJlcyBhIHBlZXIgdG8gZGVsaXZl ciBpbi1vcmRlciBxdWV1ZWQgZGF0YSB3L28gRklOLCB0aGVuIHRoZXJlIGlzIG5vIHdheSB0byBh c2sgdGhlIHRyYW5zcG9ydCB0byBhYmFuZG9uIGl0cyBub24tZGVsaXZlcmVkIGRhdGEuICBIYXZp bmcgdGhhdCBkYXRhIGRyb3BwZWQgYnkgdHJhbnNwb3J0IG1heSBiZSBhIGRlc2lyZWQgZmVhdHVy ZSBmb3IgdmFyaW91cyBhcHBsaWNhdGlvbnMsIGluY2x1ZGluZyB0cmFuc2FjdGlvbmFsIHN5c3Rl bXMgdGhhdCBtYXkgd2lzaCB0byBhYm9ydCBhbiBpbi1mbGlnaHQgdHJhbnNhY3Rpb24gKGFuZCB0 aGVyZWZvcmUgZG8gbm90IHdhbnQgdGhlIHBlZXIgYXBwbGljYXRpb24gdG8gcHJvY2VzcyBhbGwg dGhlIGJ1ZmZlcmVkIGRhdGEganVzdCB0byB0aHJvdyBpdCBhd2F5IGxhdGVyKS4NCg0KLSBJZ29y DQoNClAuUy4NCg0KSXQgc2VlbXMgdGhhdCBhbiBvcmRlcmx5IHRlcm1pbmF0aW9uIG9mIGEgY29u bmVjdGlvbiBzaG91bGQgbG9vayBsaWtlOg0KMS4gR09BV0FZDQoyLiBSZXNldCBhbGwgaW5jb21p bmcgc3RyZWFtcw0KMy4gRmluaXNoIHdyaXRpbmcgYWxsIHN0cmVhbXMsIGluY2x1ZGluZyB0aGUg RklOLg0KNC4gV2FpdCBmb3IgYWxsIEFDS3MgKGFuZCByZXRyYW5zbWl0IGFzIG5lZWRlZCkgNS4g Q09OTkVDVElPTl9DTE9TRQ0KDQpQLlAuUy4NCg0KU29tZSBjb3NtZXRpYyByZW5hbWluZyBpcyB3 YXJyYW50ZWQsIGluZGVlZC4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dDQpTZW50OiBX ZWRuZXNkYXksIEZlYnJ1YXJ5IDIyLCAyMDE3IDY6MDUgUE0NClRvOiBQYXRyaWNrIE1jTWFudXMg PHBtY21hbnVzQG1vemlsbGEuY29tPg0KQ2M6IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2Ft YWkuY29tPjsgTWFydGluIER1a2UgPG1hcnRpbi5oLmR1a2VAZ21haWwuY29tPjsgUnlhbiBIYW1p bHRvbiA8cmNoQGdvb2dsZS5jb20+OyBNaWtlIEJpc2hvcCA8TWljaGFlbC5CaXNob3BAbWljcm9z b2Z0LmNvbT47IGVrckBydGZtLmNvbTsganJpQGdvb2dsZS5jb207IHF1aWNAaWV0Zi5vcmcNClN1 YmplY3Q6IFJlOiB0Y3AgcnN0cywgZGF0YSB0cnVuY2F0aW9uLCBhbmQgdGhlIGZ1dHVyZSBvZiBw dWJsaWMgcmVzZXQNCg0KT24gMjMgRmVicnVhcnkgMjAxNyBhdCAwOTo1NCwgUGF0cmljayBNY01h bnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbT4gd3JvdGU6DQo+IFVwb24gcmVjZWlwdCBvZiBDTE9T RS9SRVNFVCBhbiBhcHBsaWNhdGlvbiBNVVNUIE5PVCBhYmFuZG9uIGluLW9yZGVyIA0KPiBxdWV1 ZWQgZGF0YSBmb3IgdGhlIGFwcGxpY2F0aW9uIGxheWVyICh3aGV0aGVyIG9yIG5vdCBpdCBoYXMg YSBGSU4gZm9yIA0KPiB0aGUgc3RyZWFtIGl0IGlzIG9uKSB0aGUgd2F5IFRDUCBjdXJyZW50bHkg ZG9lcy4gQnV0IGl0IFNIT1VMRCg/KSBkcm9wIA0KPiBmdXR1cmUgcGFja2V0cyByZWNlaXZlZCBv biB0aGUgY29ubmVjdGlvbiBhbmQgTVVTVCBOT1Qgc2VuZCBhbnkgb24gbW9yZSBvbiB0aGUgY29u bmVjdGlvbi4NCj4NCj4gQ0xPU0UvUkVTRVQgaGFzIHRoZSBwb3RlbnRpYWwgZm9yIGRhdGEgbG9z cyBmb3IgYW55IGRhdGEgd2hvc2UgYWNrIGhhcyANCj4gbm90IGJlZW4gcmVjZWl2ZWQgd2hlbiBD TE9TRS9SRVNFVCBpcyBnZW5lcmF0ZWQuIFtJIHJlYWxseSB0aGluayANCj4gc29tZXRoaW5nIGxp a2UgdGhhdCB3b3VsZCBiZSBjbGFyaWZ5aW5nIHRleHQgaW4gdGhlIGRvY3VtZW50XQ0KDQpJIHRo aW5rIHRoYXQgbmF0dXJhbGx5IGZvbGxvd3MuICBPZiBjb3Vyc2UsIHRoZSByZWNlaXZlZCBtaWdo dCBoYXZlIHJlY2VpdmVkIGRhdGEgYW5kIHRoZXJlZm9yZSBjb3VsZCBoYXZlIGFjdGVkIHVwb24g aXQuICBUaGF0IG1lYW5zIHRoYXQgdW5hY2tub3dsZWRnZWQgZGF0YSBpcyBpbiBhbiBhbWJpZ3Vv dXMgc3RhdGUuICBIb3BlZnVsbHkgdGhlIGdyYWNlZnVsIGNsb3NlIGhhcHBlbnMgb2Z0ZW4gZW5v dWdoIHRoYXQgdGhpcyBpc24ndCBhIGNvbW1vbiBzaXR1YXRpb24uDQoNCj4NCj4gaW1vIENMT1NF IG91Z2h0IHRvIGJlIG5hbWVkIFJFU0VULi4gZ2VuZXJpY2FsbHkgY2xvc2UgaXNuJ3Qgbm9ybWFs bHkgYSANCj4gZGVzdHJ1Y3RpdmUgb3BlcmF0aW9uLCB3aGlsZSB0aGUgc2VtYW50aWNzIGhlcmUg Y2VydGFpbmx5IG1pZ2h0IGJlLg0KDQpSZXNldCBpbXBsaWVzIGFuIGFib3J0LCB3aGljaCBpc24n dCByZWFsbHkgdGhlIGNhc2UgZm9yIGEgZ3JhY2VmdWwgY2xvc2UuICBQZXJoYXBzIFRFUk1JTkFU RSBoYXMgdGhlIHJpZ2h0IGNvbm5vdGF0aW9ucy4NCg0KKEkgd291bGQgYWxzbyBsaWtlIHRvIGNo YW5nZSBSU1RfU1RSRUFNIHRvIENBTkNFTF9TVFJFQU0gYW5kIGEgZmV3IG90aGVyIGNvc21ldGlj IGNoYW5nZXMuKQ0K From nobody Wed Feb 22 16:28:41 2017 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 58AA1129CFC for ; Wed, 22 Feb 2017 16:28:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.888 X-Spam-Level: X-Spam-Status: No, score=-3.888 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=-1.887, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 JwUQK9mgF8gw for ; Wed, 22 Feb 2017 16:28:38 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0111.outbound.protection.outlook.com [104.47.38.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 3CD8B129CF5 for ; Wed, 22 Feb 2017 16:28:38 -0800 (PST) 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=eNGpRJAxDZMNuewtYRVFzKdRumh2iY6WMQv0XF1SA+s=; b=QvCzkIbl918fgq6DbtH4PvzNPMfFg5KwF3C9ud0chUvODKVezjbxeQ7llffhBzR2BDRYxwbZaY5dUQKZ6YqhH4R9zelKyELBBpOLaBdrx3ily7rbN5SrPzFVp8XXkq+Q5/NJ7Hlz9+6BTO7dua+nR214w1mY4Mv4auHBoREFcR8= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 00:28:35 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 00:28:35 +0000 From: Mike Bishop To: Martin Thomson , "Lubashev, Igor" Subject: RE: Orderly close (was Re: tcp rsts, data truncation, and the future of public reset) Thread-Topic: Orderly close (was Re: tcp rsts, data truncation, and the future of public reset) Thread-Index: AQHSjWqp0hn/nPRnxUmWKWcUqrwcjKF1vIVQ Date: Thu, 23 Feb 2017 00:28:35 +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: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:5::51f] x-ms-office365-filtering-correlation-id: 517f32d0-e16b-4168-9e7c-08d45b82e78d x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:pojIAk66ENdg5TCb1Yp+qHQ4HBiBDkhMOfEgFK9t3kb2TGDqUjif93XTTV4Zkj+Gd9SkGxhV5+lsiMqjYY2KrysuR0XYshXGKhnBBI90YojpCWFYo8iLyA1HL0h/VIhqijoQSSYs5Od/z7U3Q9nd9iOgqfeFtnDkjP9t7WeZo+OdZRNpzOyaV4f++KFMCl/cQivfnf0UCNgRedMsLheEqj/yIjVSMsML+WR5CqSmEBNCQXqgWyjfl6WfzGStbasE9MNKwuB8p6yD7ATTs0cuoLIv8s/XqPel2mFtg294BA5iblU9H1QQxJq8S2PfIporM/nsux97BZMIxmdI4SFCpKfkBwsXQ7ZO+rgOfasIAyM= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(211936372134217); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(20161123555025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39850400002)(39450400003)(39410400002)(24454002)(377454003)(13464003)(122556002)(7696004)(4326007)(53936002)(86612001)(229853002)(6246003)(3660700001)(6436002)(92566002)(3280700002)(2906002)(86362001)(38730400002)(5660300001)(6506006)(102836003)(189998001)(6116002)(8990500004)(8676002)(5005710100001)(53546006)(50986999)(10290500002)(10090500001)(76176999)(305945005)(106116001)(8936002)(33656002)(54356999)(39060400002)(2950100002)(7736002)(9686003)(99286003)(55016002)(74316002)(54906002)(77096006)(81166006)(25786008)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 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: 23 Feb 2017 00:28:35.1764 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: Cc: "ekr@rtfm.com" , Ryan Hamilton , Patrick McManus , "jri@google.com" , "quic@ietf.org" , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:28:39 -0000 SSB0aGluayBzbywgeWVzLiAgQW5kIHdlJ2xsIG5lZWQgdG8gZGlzY3VzcyB3aGF0IGhhcHBlbnMg d2hlbiB0aGluZ3MgaGFwcGVuICJlYXJseSIgaW4gdGhlIHVuY2xlYW4gY2FzZS4NCg0KLS0tLS1P cmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gVGhvbXNvbg0KU2VudDogV2VkbmVzZGF5LCBGZWJy dWFyeSAyMiwgMjAxNyA0OjIwIFBNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1h aS5jb20+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+OyBl a3JAcnRmbS5jb207IFJ5YW4gSGFtaWx0b24gPHJjaEBnb29nbGUuY29tPjsgUGF0cmljayBNY01h bnVzIDxwbWNtYW51c0Btb3ppbGxhLmNvbT47IGpyaUBnb29nbGUuY29tOyBxdWljQGlldGYub3Jn OyBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb20+DQpTdWJqZWN0OiBPcmRlcmx5 IGNsb3NlICh3YXMgUmU6IHRjcCByc3RzLCBkYXRhIHRydW5jYXRpb24sIGFuZCB0aGUgZnV0dXJl IG9mIHB1YmxpYyByZXNldCkNCg0KT24gMjMgRmVicnVhcnkgMjAxNyBhdCAxMTowMSwgTHViYXNo ZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+IHdyb3RlOg0KPiBJdCBzZWVtcyB0aGF0IGFu IG9yZGVybHkgdGVybWluYXRpb24gb2YgYSBjb25uZWN0aW9uIHNob3VsZCBsb29rIGxpa2U6DQo+ IDEuIEdPQVdBWQ0KPiAyLiBSZXNldCBhbGwgaW5jb21pbmcgc3RyZWFtcw0KPiAzLiBGaW5pc2gg d3JpdGluZyBhbGwgc3RyZWFtcywgaW5jbHVkaW5nIHRoZSBGSU4uDQo+IDQuIFdhaXQgZm9yIGFs bCBBQ0tzIChhbmQgcmV0cmFuc21pdCBhcyBuZWVkZWQpIDUuIENPTk5FQ1RJT05fQ0xPU0UNCg0K T24gc3RlcCAyLCBHT0FXQVkgY3JlYXRlcyBhbiBpbXBsaWNpdCByZXNldCBmb3IgYWxsIHN0cmVh bXMgaGlnaGVyIHRoYW4gdGhlIGluZGljYXRlZCBudW1iZXIuICBZb3UgZG9uJ3QgbmVlZCB0byBy ZXNldCBhbnkgc3RyZWFtcyB3aXRoIGhpZ2hlciBudW1iZXJlZCBpZGVudGlmaWVycy4NCg0KT24g c3RlcCAzLCB5b3UgbmVlZCB0byBoYW5kbGUgYWxsIHN0cmVhbXMgdXAgdG8gdGhlIEdPQVdBWSB2 YWx1ZSBieSBlaXRoZXIgc2VuZGluZyBhIEZJTiBPUiBieSBzZW5kaW5nIGEgcmVzZXQuICBZb3Ug YXJlIGRlZmluaXRlbHkgcmlnaHQgdGhhdCB5b3UgbmVlZCB0byB3YWl0IGZvciB0aG9zZSB0byBi ZSBhY2tub3dsZWRnZWQgaW4gc3RlcCA0Lg0KDQpXb3VsZCBpdCBiZSB1c2VmdWwgdG8gaW5jbHVk ZSBhIHNob3J0IHNlY3Rpb24gb24gc2h1dGRvd24gdGhhdCBjb3ZlcmVkIHRoZXNlIG51YW5jZXM/ DQoNCg== From nobody Wed Feb 22 16:29:13 2017 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 BE26B129CF5 for ; Wed, 22 Feb 2017 16:29:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1_ouVUy2jXk for ; Wed, 22 Feb 2017 16:29:10 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 C3989129D35 for ; Wed, 22 Feb 2017 16:29:07 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id g134so9451437lfe.1 for ; Wed, 22 Feb 2017 16:29:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=7eA2p+CtQJhP9wexf6Zr25inQoTJXevu+k2hfFBzyic=; b=jRXE+BTmRpJM4OdS5rJNDcvT01uW+ZElL/nhcjvvj9ln7jQjUdiiGu8ul+6v9wC/Xj BWQqnx4W1zHPOKWrK0x7Slz1Ox8aSdQ9cN9pv8YqjgtGPo4i4L3K/9o2h/5pABl15DZl cZch6hNfVGh54CoVQN1f/5opcZcc70BN6HDv2kk2UyhvNV8B4wV5lGZ6GaAVy6aQ10s0 JTY3dosLh1na3gvUYO68hPJ8Ndwcmyng4vCYIjg6A+O0QgabppAU/ILFPD0aH+DUoYUz J1YkrXqDbJ21ePXyOYrRqLrxFqWNW3RIWClQtsmshN2B/7Vqvwt9/kEoAeuZb/fg4xtl cVyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=7eA2p+CtQJhP9wexf6Zr25inQoTJXevu+k2hfFBzyic=; b=GKIAuxymnoez1LLmPfKgCkXVkFKcNVlD7qCz5OnLN0WdY0AadeHm4unSN8xg0sPbWA tRJIsd6ufdyLjuyR3wFBXu5KSy/VhdxZ8UwR4KHd44QmnhYK3LoMTKhvPJC6buKuV7T6 isCDJz5udc/cSrnmvsqTnsFMksACYNmr6I5UWIYrMui4n2gQvjYWVoEAJPx9h+QLQ5A9 GQnzOEA926Aa6EnXWDZD8G/3Nzx68ZGJFTcCVX+gU2ey70cD415cjz9MrZk+D0/LecFk O4n1iuB4KbAM/7EYh/5SLBVWOs2eyKWaiyDDW0xqme0SpfjV9lrVRw1mkRe0l9bK/jKy IYoQ== X-Gm-Message-State: AMke39nTI0nEBVx0OEcJrm9zFOU/+Qc9ALmVOwV5upR6sR8jY0wgL+AN7sQnvWq9IhVPArZz/snIk+ma6IpTsw== X-Received: by 10.46.88.7 with SMTP id m7mr9736316ljb.58.1487809745935; Wed, 22 Feb 2017 16:29:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.75.25 with HTTP; Wed, 22 Feb 2017 16:29:05 -0800 (PST) From: Martin Thomson Date: Thu, 23 Feb 2017 11:29:05 +1100 Message-ID: Subject: Error handling and Public Reset To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:29:12 -0000 I've put together a PR (hehe) that attempts to close on the discussion we've had about public reset. I've expanded it to include more details on error handling. This includes discussion on what to do with connection close. I have not added anything about what to do with undelivered data. That will follow once the current discussion concludes. https://github.com/quicwg/base-drafts/pull/335 From nobody Wed Feb 22 16:43:13 2017 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 B1EE11293DC for ; Wed, 22 Feb 2017 16:43:12 -0800 (PST) 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=unavailable 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 gMzzFeAUfagu for ; Wed, 22 Feb 2017 16:43:11 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 46E7C129446 for ; Wed, 22 Feb 2017 16:34:57 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id b80so9444626lfe.3 for ; Wed, 22 Feb 2017 16:34:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=trv4lr2RtjY32Il5hJCLeRpUPIm273va4ZjG29SVJsY=; b=ukkS3SIsRG28gzFIVfSBT0AtZq/+jDy2yLzaDNKhnlKLsszBxTCXWE34CyUtL5Jque k2Fi7kjrDpgE31/SJTPcdrzNpqUimeJ4skNSrSALHogKq5EKItVKlHVF48EVOsyzdyNI fxvFs0STS+wLxENf/+ktY4HRtaieUVSAsuBueomdYECKuXN0RtjyxgCTs2wjhi/zxFhd 7bdgY55NFqalQZCZRnfaP94kNT39C73bNgLRVz/yyNqVQMoPWBHeIZRTzJZQAAE1pXze AOyNPDTIltiGtCmjeMC6keX2DszKAMul/cMABrv4lh3lJRi7LCjqNsKyPFLSQL8YXg8a MMYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=trv4lr2RtjY32Il5hJCLeRpUPIm273va4ZjG29SVJsY=; b=uhRUR09/NipPJg+aCA8Bl/YlADxWCNOy8ggF3zkeVE5N04yN9atneA4tKubgo6zgYd sNRVPbZhkgAIWvpCa5wVWCO5QvKLrBdoASQdchM9L0HjjzbbajyHW5lQEOSoCwcNGDdn 6Sv7P3KHv3zGvRrXiBNbnworCrPckSAmQdhB5ttOqSOsex+vJiH7uPcwo7Kw1vWHZKtp uSn+2s0Ll7GFla1X9DghYRChV+3EoMUOKZxUDuO83NVwTUB4WPjpand/MZwPUz8kCMaP ewRnAuKyMR0c2wsXHlHoEQrqIO5yAcQI2ptAH52UXdUzY75wumOZa8wAHZYPhZk/WS/W Qmlw== X-Gm-Message-State: AMke39k4oW+jVWYkQpcKyjQJgv8FPa8hJFFeU2eoU6DjopmRJDou9DegMJohoTU+9qRe1FqoFiWVBb48HVcczA== X-Received: by 10.46.1.201 with SMTP id f70mr9727023lji.21.1487810095549; Wed, 22 Feb 2017 16:34:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.75.25 with HTTP; Wed, 22 Feb 2017 16:34:54 -0800 (PST) In-Reply-To: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> <2b1d664dc2134d5fbdbe02d002751b5e@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Thu, 23 Feb 2017 11:34:54 +1100 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Patrick McManus Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , "Lubashev, Igor" , Ryan Hamilton , "jri@google.com" , "quic@ietf.org" , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 00:43:13 -0000 On 23 February 2017 at 11:26, Patrick McManus wrote: > If we do it the way I suggested then we get the nice property that no data > is lost for which an ack has been received before generating a > connection_close (modulo crash etc..) - which is a major improvement over > classic TCP which routinely loses data in surprising ways for application > developers (see endnotes in the first message in this thread). I think that this is probably the right answer. An application protocol might decide that it doesn't want this feature and then subsequently discard partially received streams, but we already have the case in HTTP where data is progressively processed. If a stream carrying HTTP is reset in the middle, the data that has arrived might still be delivered (even used). If we model CONNECTION_CLOSE as a blanket reset on all open streams, we have a nice basis upon which to model the situation. As Mike says, we can say that any received data gets delivered. We also have a single way to consider how this interacts. From nobody Wed Feb 22 18:35:12 2017 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 76FFE129E44 for ; Wed, 22 Feb 2017 18:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-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=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 tQi7fWhIusma for ; Wed, 22 Feb 2017 18:35:09 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id C7A901294E6 for ; Wed, 22 Feb 2017 18:35:09 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 62863200009; Thu, 23 Feb 2017 02:35:09 +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 4BCBD200008; Thu, 23 Feb 2017 02:35:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487817309; bh=zLRXtXV7QFA9qBgki4unTThvTr7uJ0RLIr6TxPKMsas=; l=5264; h=From:To:CC:Date:References:In-Reply-To:From; b=KVUizu9aaj1kktpvicyF1f4C4+Y6xORqGKNl2rqmBtCEdKyxAr0GXRD4INU7mm+j5 gDzubpXzePbCZj2yKZxzuvCZJMJSF2VN0P00A/2oA4UWlhcJHeEKeNysJMkU9RoCvB b+arq5ljOqjMMkPMwsgkVJPceMn0vHeCx2lJAe64= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 3D5431E090; Thu, 23 Feb 2017 02:35:09 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 22 Feb 2017 21:35:08 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Wed, 22 Feb 2017 21:35:08 -0500 From: "Lubashev, Igor" To: Martin Thomson , Patrick McManus Subject: RE: tcp rsts, data truncation, and the future of public reset Thread-Topic: tcp rsts, data truncation, and the future of public reset Thread-Index: AQHSi6tjprq3SA28S0CynFHnEtJTgKFy0yeAgAAIagCAAAAtAIAABM8A///y6r6AAHCOgIAADq0GgACOOYCAAAXOgIAAVXyAgAAImgCAAAGzgIAAeVCAgAB893CAALzPgIAAAxOA//+w2MCAAGXfgIAAAmYA//+2bpA= Date: Thu, 23 Feb 2017 02:35:08 +0000 Message-ID: <2888fa2fb90443f1b79fca930f02da4c@usma1ex-dag1mb5.msg.corp.akamai.com> References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> <2b1d664dc2134d5fbdbe02d002751b5e@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.243] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , Ryan Hamilton , "jri@google.com" , "quic@ietf.org" , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 02:35:11 -0000 LS0tLS0tLS0tLSBGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb21dIC0tLS0tLS0tLS0NCj4gSWYgd2UgbW92ZSB0byB1bmlkaXJlY3Rpb25hbCByZXNl dHMsIEknbGwgbm90ZSB0aGF0IHlvdSBjYW4gY29tcGxldGVseSBpZ25vcmUgYSBSU1RfU1RSRUFN IHRoYXQgYXJyaXZlcyBhZnRlciB0aGUgc3RyZWFtIGhhcyBhbHJlYWR5IGNsb3NlZCAoaS5lLiBh bGwgZGF0YSBhbmQgRklOKS4NCg0KQSBnb29kIHBvaW50IHRoYXQgc2hvdWxkIGJlIG1hZGUgZXhw bGljaXQuICAoVGhpcyBpcyBvcnRob2dvbmFsIHRvICJyZXF1aXJlL2RvIG5vdCByZXF1aXJlIEZJ TiIuKQ0KDQoNCj4gVGhlIHNlbWFudGljcyBvZiBhIFJTVF9TVFJFQU0gd291bGQgYmUgIkkgd2ls bCBubyBsb25nZXIgYXR0ZW1wdCB0byByZXRyYW5zbWl0IGRhdGEgb24gdGhpcyBzdHJlYW07IGlm IHlvdSBoYXZlbid0IHJlY2VpdmVkIGl0LCB5b3UncmUgbm90IGdvaW5nIHRvLiINCg0KImlmIHlv dSBoYXZlbid0IHJlY2VpdmVkIGl0LCB5b3UncmUgbm90IGdvaW5nIHRvIiBpcyBub3QgdGVjaG5p Y2FsbHkgY29ycmVjdCwgc2luY2UgcGFja2V0cyBjb250YWluaW5nIGRhdGEgYW5kIFJTVF9TVFJF QU0gY291bGQgaGFkIGJlZW4gcmVvcmRlcmVkLg0KDQoNCi0tLS0tLS0tLS0gRnJvbTogTWFydGlu IFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dICAtLS0tLS0tLS0tLQ0K PiB3ZSBhbHJlYWR5IGhhdmUgdGhlIGNhc2UgaW4gSFRUUCB3aGVyZSBkYXRhIGlzIHByb2dyZXNz aXZlbHkgcHJvY2Vzc2VkLiAgSWYgYSBzdHJlYW0gY2FycnlpbmcgSFRUUCBpcyByZXNldCBpbiB0 aGUgbWlkZGxlLCB0aGUgZGF0YSB0aGF0IGhhcyBhcnJpdmVkIG1pZ2h0IHN0aWxsIGJlIGRlbGl2 ZXJlZCAoZXZlbiB1c2VkKS4NCg0KVGhpcyBpcyBhbiBpbnRlcmVzdGluZyBjYXNlIHRoYXQgInJl cXVpcmUgRklOIGFuZCBhbGwgZGF0YSIgY2Fubm90IGFkZHJlc3MgZnVsbHkuICBJdCBzZWVtcyB0 aGF0IGEgbXVjaCBtb3JlIGNvbW1vbiBjYXNlIGlzIHRoYXQgdGhlIGFwcGxpY2F0aW9uIHdpbGwg bm90IHdhbnQgdG8gcHJvY2VzcyBhbiBpbmNvbXBsZXRlIHN0cmVhbSwgdGhvdWdoLiBCdXQgeW91 ciBjYXNlIGlzIHN0aWxsIGNvbXBlbGxpbmcuDQoNCg0KDQotLS0tLS0tLS0tIEZyb206IFBhdHJp Y2sgTWNNYW51cyBbbWFpbHRvOnBtY21hbnVzQG1vemlsbGEuY29tXSAtLS0tLS0tLS0tDQo+IERv aW5nIGl0IHRoZSBvdGhlciB3YXkgKHJlcXVpcmluZyB0aGUgRklOKSBqdXN0IGNyZWF0ZXMgYW1i aWd1aXR5IGFuZCByYWNlIGNvbmRpdGlvbnMgYWJvdXQgd2hldGhlciB0aGUgZGF0YSBoYXMgYWxy ZWFkeSBiZWVuIHN0cmVhbWVkIHRvIHRoZSBhcHBsaWNhdGlvbi4gSXQgZG9lc24ndCBjcmVhdGUg YSBwcm9wZXJ0eSB5b3UgY2FuIHJlbHkgb24uDQoNCkhtLiBUaGUgZW50aXJlIHBvaW50IHdhcyB0 byBhdm9pZCBhbWJpZ3VpdHkgYW5kIGZhbHNlIGFzc3VtcHRpb25zIGZvciB0aGUgYXBwbGljYXRp b24gbGF5ZXIgKG5vdCBwcm90b2NvbCBsYXllcikuICBUaGUgcnVsZSB3YXMgdG8gYmUgInByb3Bl cmx5IGFuZCB0aW1lbHkgY2xvc2UgeW91IHN0cmVhbXMgaWYgeW91IHdhbnQgdG8gYmUgc3VyZSB0 aGF0IGV2ZXJ5IHNpbmdsZSBieXRlIGlzIHJlY2VpdmVkIi4gIE5vIHJ1bGUgKHdoZXRoZXIgcmVx dWlyaW5nIEZJTiBvciBub3QgcmVxdWlyaW5nIEZJTikgY2FuIHBvc3NpYmx5IGNyZWF0ZSBhIHBy b3BlcnR5IHlvdSBjYW4gcmVseSBvbiB0byB0ZWxsIHlvdSAid2hldGhlciB0aGUgZGF0YSBoYXMg YWxyZWFkeSBiZWVuIHN0cmVhbWVkIHRvIHRoZSBhcHBsaWNhdGlvbi4iICBSZWNlaXZpbmcgQUNL cyBmcm9tIHRyYW5zcG9ydCBkZWZpbml0ZWx5IGRvZXMgbm90IGd1YXJhbnRlZSB0aGF0IHRyYW5z cG9ydCBhbHJlYWR5IGRlbGl2ZXJlZCBhbnl0aGluZyB0byB0aGUgYXBwbGljYXRpb24uICBZb3Ug d291bGQgbmVlZCBzb21lIGFwcGxpY2F0aW9uIGxvZ2ljIGZvciB0aGlzLg0KDQpUaGUgIm5vdCBy ZXF1aXJpbmcgRklOIiBydWxlLCBob3dldmVyLCBtYXkgaW5kZWVkIG1ha2UgYWRkaXRpb25hbCBn dWFyYW50ZWVzIHRoYXQgdGhlIHRyYW5zcG9ydCAid2lsbCIgdHJ5IHRvIGRlbGl2ZXIgY2VydGFp biBieXRlcyB0byB0aGUgYXBwbGljYXRpb24gYXQgc29tZSBwb2ludCwgaWYgYWxsIEFDS3MgaGF2 ZSBiZWVuIHJlY2VpdmVkLg0KDQoNCj4gSSBkb24ndCB0aGluayB3ZSBzaG91bGQgaGF2ZSBhIG1l Y2hhbmlzbSBkZXNpZ25lZCB0byAidGFrZSBiYWNrIiBhbHJlYWR5IHRyYW5zbWl0dGVkIGRhdGEN Cg0KSXQgd2FzIHN1cHBvc2VkIHRvIGJlIGEgaGludCB0byB0aGUgdHJhbnNwb3J0OyB0cmFuc3Bv cnQgY2Fubm90IHVuZGVsaXZlciBhbnl0aGluZywgb2YgY291cnNlLg0KDQoNCj4gYW4gYXBwbGlj YXRpb24gY2FuIGNyZWF0ZSB0aGF0IHNlbWFudGljIHRocm91Z2ggYW4gYXBwbGljYXRpb24gc3Bl Y2lmaWMgc2lnbmFsIG9uIGFub3RoZXIgc3RyZWFtIGlmIG5lZWQgYmUsIGl0IGRvZXNuJ3QgbmVl ZCB0byBvdmVybG9hZCB0aGUgc2h1dGRvd24gYmVoYXZpb3IuDQoNClRoaXMgaXMgcG9zc2libGUs IGFsdGhvdWdoIGN1bWJlcnNvbWUuICBJdCB3b3VsZCByZXF1aXJlICJwcmlvcml0eSBzdHJlYW1z IiAoc3RyZWFtcyB0aGF0IGFyZSBub3Qgc3ViamVjdCB0byBjb25uZWN0aW9uLXdpZGUgZmxvdyBj b250cm9sKS4gIEJ1dCB3ZSBhbHJlYWR5IHJlcXVpcmUgc3VjaCBzdHJlYW1zIGZvciBIVFRQIG92 ZXIgUVVJQywgc28gdGhhdCBpcyBub3QgYW4gdW5kdWUgYnVyZGVuLg0KDQpJZiB0aGlzIGlzIHRo ZSB3YXkgd2UgZGVjaWRlIHRvIGdvICJkbyBub3QgcmVxdWlyZSBGSU4iIHJvdXRlLCBJIG1heSBz dWdnZXN0IHRoYXQgUVVJQyBsaWJyYXJpZXMgcHJvdmlkZXMgYSB3YXkgdG8gY2hvb3NlICJyZXF1 aXJlIEZJTiBhbmQgYWxsIGRhdGEiIFJTVCBiZWhhdmlvciBwZXItc3RyZWFtIChldmVuIGlmIGl0 IGlzIG5vdCB0aGUgZGVmYXVsdCkuICBUaGluayBzb2Nrb3B0LiAgVGhpcyB3b3VsZCBsaWtlbHkg YmUgYSBzdWJqZWN0IG9mIGEgZGlmZmVyZW50IHNwZWMsIHRob3VnaC4NCg0KDQoNCj4+IEl0IHNl ZW1zIHRoYXQgYW4gb3JkZXJseSB0ZXJtaW5hdGlvbiBvZiBhIGNvbm5lY3Rpb24gc2hvdWxkIGxv b2sgbGlrZToNCj4+IDEuIEdPQVdBWQ0KPj4gMi4gUmVzZXQgYWxsIGluY29taW5nIHN0cmVhbXMN Cj4+IDMuIEZpbmlzaCB3cml0aW5nIGFsbCBzdHJlYW1zLCBpbmNsdWRpbmcgdGhlIEZJTi4NCj4+ IDQuIFdhaXQgZm9yIGFsbCBBQ0tzIChhbmQgcmV0cmFuc21pdCBhcyBuZWVkZWQpDQo+PiA1LiBD T05ORUNUSU9OX0NMT1NFDQo+DQo+IGJhc2ljYWxseSBhZ3JlZSwgYnV0IHlvdSBkb24ndCBuZWVk ICMyIGJlY2F1c2Ugb2YgdGhlIGxhc3QtZ29vZC1zdHJlYW0taWQgcGFyYW0gb2YgZ29hd2F5LiB0 aGUgcnN0cyBhcmUgaW1wbGllZC4NCg0KR09BV0FZIGRlc2NyaXB0aW9uIGltcGxpZXMgdGhhdCBJ IGNhbm5vdCBpbXBsaWNpdGx5IGNsb3NlIHN0cmVhbXMgdGhhdCBJJ3ZlIGV4cGxpY2l0bHkgYWNj ZXB0ZWQgYW5kIEFDS2VkIGJlZm9yZS4gIElmIG15IGVuZHBvaW50IGRvZXMgbm90IHdhbnQgdG8g aGVhciBhbnl0aGluZyBuZXcgb3ZlciB0aGUgaW5jb21pbmcgc3RyZWFtcywgaXQgc2hvdWxkIHJz dCB0aGVtLiAgT3IgZG8gd2Ugd2FudCB0byBhbGxvdyBzdWNoIGltcGxpY2l0IFJTVCBvZiBzdHJl YW1zIHZpYSBHT0FXQVkgd2l0aCBhIGxvdyBzdHJlYW0gSUQ/IFNlZW1zIGhhY2t5IGJ1dCBwb3Nz aWJseSB1c2VmdWwuDQoNCg0KLSBJZ29yDQo= From nobody Wed Feb 22 18:43:27 2017 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 1B0D412950B for ; Wed, 22 Feb 2017 18:43:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Ieq2Cck6_Pf for ; Wed, 22 Feb 2017 18:43:24 -0800 (PST) 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 5933D1294F9 for ; Wed, 22 Feb 2017 18:43:24 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id p77so10861619ywg.1 for ; Wed, 22 Feb 2017 18:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to; bh=LRIBOUzKdLIehXKEc+0CuJYI0XXmyAMTndJtzD7SMds=; b=jOaKO/IE9OvF4Tk/5izbLsM6ipZZSKTOp8cJFNX5KKzasrc/jG/rhonHPtEnUwutmr QlD1vZ1MiX3qLim1U5VwvYAzSWe/GsG2yc8p4m08ofL8GUCYgp+EMVokit8vGcbvYl8U f9k/dgqWImGVEHSmgTvTgd5NlplmjH5qtDaHg/jYKB6qYoVNKKRWbZZwzHa2gRpBDCqH 0Rv4diZDGyqfP9V4TWsXhMBIP1UXalP0bPLyPcfEKxUeq/6oNW3lPHTzpHlkBz+mNhQb g/NxldWWyELfkJmZ4ZZTIYvyHYsQTX4T/j5wIe4mLscrKR+RvRa4QUpHS70ZDP8ephsD H2Cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to; bh=LRIBOUzKdLIehXKEc+0CuJYI0XXmyAMTndJtzD7SMds=; b=iioFYNPW1VXFlfP2q5pdCwLUB7yITpUdp1Qhtz5pptaep8QIJ1pTwk3yGrwErib4cn U0NzqWzcINcAW9k0SJfvQ2ubczHOmvEbxLIXn/AkLJ0X0wby9kd53vHzqkPFUZJ1Mw6x u1d0mkOqVmAbZ9s5W4au+VGMP+sYcnjDq4SZMsoW/1V03zHl3kBId0fNedEpeUyZ74Tv dMmi+MWz6xlTUjX1Aj1odFPlP56iTm5MI4ah0jhTcTsW8EOfNPuDvVCI/xp0T24KKSc2 cgWFvsMwPoG8d6C+fj1OduKn9B/eUrtsA+bJUAkMs9cEByNelQsBl4de97FxQYrVcL4B lQZA== X-Gm-Message-State: AMke39nf1YPzvtwRe7PcOvZcnQqk8t1RepLLve45D7KZyfx+3QYM5IzzRujkRUocnZ9VUxCLLyXYiqBixb3IFA== X-Received: by 10.129.119.130 with SMTP id s124mr6718851ywc.202.1487817803494; Wed, 22 Feb 2017 18:43:23 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.17.140 with HTTP; Wed, 22 Feb 2017 18:43:22 -0800 (PST) In-Reply-To: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> From: Phillip Hallam-Baker Date: Wed, 22 Feb 2017 21:43:22 -0500 X-Google-Sender-Auth: YuTnb9GKGElVkCmJBXczZZXX_Xk Message-ID: Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a11490382aafd7d054929938b Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 02:43:27 -0000 --001a11490382aafd7d054929938b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Not being sarcastic. I am a security guy, not a transport guy. It is over 25 years since I did work at this level in the stack and the Internet didn't reach where I was at the time so the terms I am familiar with are different. What has meaning for you may not have meaning to me. I am familiar with the concept of congestion control but the acronyms mean nothing to me. The output of a WG is documents. The draft isn't going to become an RFC with that introduction so it is going to have to be fixed some time. Might as well fix it now before it is read by all the other parts of the IETF rather than after they have all scrambled to work out what it is about. QUIC is essentially a replacement for TCP in all but one respect. TCP was only implemented by kernel level hackers and the document only had to be understood by a small set of people. QUIC is not going to be so limited in scope and the documents had better make sense to the wider audience. On Wed, Feb 22, 2017 at 7:30 PM, Mike Bishop wrote: > I read PHB=E2=80=99s comment as a typically-sarcastic way of saying that = the > Introduction of this draft assumes quite a bit of knowledge that is perha= ps > best spelled out with some relevant informative references. That is, aft= er > all, the point of an introduction. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar > *Sent:* Wednesday, February 22, 2017 3:37 PM > *To:* Phillip Hallam-Baker > *Cc:* 'gorry@erg.abdn.ac.uk' (gorry@erg.abdn.ac.uk) ; > Bob Briscoe (ietf@bobbriscoe.net) ; Ingemar > Johansson S ; > mirja.kuehlewind@tik.ee.ethz.ch; marcelo bagnulo braun ; > Piers O'Hanlon ; IETF QUIC WG ; > De Schepper, Koen (Nokia - BE) > *Subject:* Re: FW: New Version Notification for > draft-johansson-quic-ecn-01.txt > > > > On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Baker < > phill@hallambaker.com> wrote: > > This is the entirety of the introduction: > > > > ECN support in transport protocols is a fundamental feature that > > should be included in the QUIC specification as a mandatory element. > > The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits]. The > > ECN support should be implemented to support both present and future > > ECN, the latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation], > > of particular interest is the ability to discriminate between classic > > ECN and L4S ECN by means of differentiation between the use of the > > ECT(0) and ECT(1) code points. This draft does however not delve > > into the details of the congestion control implementation. > > > > I have absolutely no idea what ECN is. I am opposed to the WG spending an= y > time on ECN until it can be explained in terms that do not reference yet > more jargon. > > > > Happy to help. ECN is defined in RFC 3168 > , and is an explicit signal from the > a network switch or router about congestion at a link, so that endpoints > can use this signal instead of loss for detecting and reacting to > congestion. The benefits of doing this are documented int he I-D that is > linked in the abstract. ECN has been a pretty significant thing in > transport for about two decades, but has had an uphill battle since ECN > requires support in the network and at endpoints. > > > > There have been many efforts to try and deploy it in network devices and > at endpoints for about as long as RFC 3168 has existed. ECN has been > deployed in bits at routers and in endpoints, but due to long-standing bu= gs > in older home-routers and wifi boxes, and issues around use of these bits > in the IP header, it was generally not turned on anywhere. This seems to = be > changing now, especially as bufferbloat becomes an increasingly visible > issue. Brian Trammell (IAB) and Mirja Kuehlewind (Transport AD) have been > actively doing measurement about the current deployment state of ECN; > here's a blog post by Brian > from > last summer saying that a large number of webservers do support ECN. > There's support for ECN built into TCP (see Section 3.2 and 4.3 of the TC= P > Roadmap RFC ), there's been a > ton of work around re-using ECN signaling for richer congestion informati= on. > > > > Since TCP and SCTP have support for ECN, and the future may see ECN > deployment increase yet, it's expected that QUIC would have equivalent > mechanisms to support use of ECN. This work is very much in scope, as par= t > of the congestion control aspect of QUIC. > > > > Hope this helps, > > - jana > > > > > > > > On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > Hi > > I just uploaded a new version of the ECN in QUIC draft. The main change a > description of the ECN negotiation. > > /Ingemar > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: den 22 februari 2017 08:56 > To: Ingemar Johansson S > Subject: New Version Notification for draft-johansson-quic-ecn-01.txt > > > A new version of I-D, draft-johansson-quic-ecn-01.txt has been > successfully submitted by Ingemar Johansson and posted to the IETF > repository. > > Name: draft-johansson-quic-ecn > Revision: 01 > Title: ECN support in QUIC > Document date: 2017-02-21 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-johansson-quic= - > ecn-01.txt > Status: https://datatracker.ietf.org/doc/draft-johansson-quic-ecn= / > Htmlized: https://tools.ietf.org/html/draft-johansson-quic-ecn-01 > Diff: https://www.ietf.org/rfcdiff? > url2=3Ddraft-johansson-quic-ecn-01 > > Abstract: > This memo outlines the ECN support in QUIC. The intention is that > most of the material ends up updating other new or existing QUIC > protocol specifications, thus it may be possible that this draft does > not warrant a working group status. > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > > > > --001a11490382aafd7d054929938b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Not= being sarcastic. I am a security guy, not a transport guy. It is over 25 y= ears since I did work at this level in the stack and the Internet didn'= t reach where I was at the time so the terms I am familiar with are differe= nt. What has meaning for you may not have meaning to me. I am familiar with= the concept of congestion control but the acronyms mean nothing to me.

The output of a WG is docume= nts. The draft isn't going to become an RFC with that introduction so i= t is going to have to be fixed some time. Might as well fix it now before i= t is read by all the other parts of the IETF rather than after they have al= l scrambled to work out what it is about.

QUIC is essentially a replacement for TCP in all but one r= espect. TCP was only implemented by kernel level hackers and the document o= nly had to be understood by a small set of people. QUIC is not going to be = so limited in scope and the documents had better make sense to the wider au= dience.


On Wed, = Feb 22, 2017 at 7:30 PM, Mike Bishop <Michael.Bishop@microsoft.= com> wrote:

I read PHB=E2=80=99s comment as a typically-sarcasti= c way of saying that the Introduction of this draft assumes quite a bit of = knowledge that is perhaps best spelled out with some relevant informative r= eferences.=C2=A0 That is, after all, the point of an introduction.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Wednesday, February 22, 2017 3:37 PM
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: 'g= orry@erg.abdn.ac.uk' (gorry@erg.abdn.ac.uk) <gorry@erg.abdn.ac.uk>; Bob Briscoe (ietf@bobbriscoe.net)= <ietf@bobbrisc= oe.net>; Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; mirja.kuehlewind@tik.ee.ethz.ch; marcelo bagnulo braun <marcelo@it.uc3m.es>= ;; Piers O'Hanlon <piers.ohanlon@cs.ox.ac.uk>; IETF QUIC WG <quic@ietf.org>; De Schepper,= Koen (Nokia - BE) <koen.de_schepper@nokia-bell-labs.com>
Subject: Re: FW: New Version Notification for draft-johansson-quic-e= cn-01.txt

=C2=A0

On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Bak= er <phill@hal= lambaker.com> wrote:

This is the entiret= y of the introduction: =C2=A0

=C2=A0

=C2=A0 =C2=A0ECN su= pport in transport protocols is a fundamental feature that

=C2=A0 =C2=A0should= be included in the QUIC specification as a mandatory element.

=C2=A0 =C2=A0The be= nefits of ECN is described in [I-D.ietf-aqm-ecn-benefits].=C2=A0 The=

=C2=A0 =C2=A0ECN su= pport should be implemented to support both present and future

=C2=A0 =C2=A0ECN, t= he latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation],<= u>

=C2=A0 =C2=A0of par= ticular interest is the ability to discriminate between classic

=C2=A0 =C2=A0ECN an= d L4S ECN by means of differentiation between the use of the<= /span>

=C2=A0 =C2=A0ECT(0)= and ECT(1) code points.=C2=A0 This draft does however not delve<= /u>

=C2=A0 =C2=A0into t= he details of the congestion control implementation.

=C2=A0

I have absolutely n= o idea what ECN is. I am opposed to the WG spending any time on ECN until i= t can be explained in terms that do not reference yet more jargon.

=C2=A0

Happy to help. ECN is defined in RFC 3168, and is an explicit signal from the a network switch or router= about congestion at a link, so that endpoints can use this signal instead = of loss for detecting and reacting to congestion. The benefits of doing thi= s are documented int he I-D that is linked in the abstract. ECN has been a pretty significant thing in tran= sport for about two decades, but has had an uphill battle since ECN require= s support in the network and at endpoints.=C2=A0

=C2=A0

There have been many efforts to try and deploy it in= network devices and at endpoints for about as long as RFC 3168 has existed= . ECN has been deployed in bits at routers and in endpoints, but due to lon= g-standing bugs in older home-routers and wifi boxes, and issues around use of these bits in the IP header, it w= as generally not turned on anywhere. This seems to be changing now, especia= lly as bufferbloat becomes an increasingly visible issue. Brian Trammell (I= AB) and Mirja Kuehlewind (Transport AD) have been actively doing measurement about the current deployment stat= e of ECN; here's a blog post by Brian=C2=A0from last summer saying that a large number of = webservers do support ECN. There's support for ECN built into TCP (see = Section 3.2 and 4.3 of the TCP = Roadmap RFC), there's been a ton of work around re-using ECN signal= ing for richer congestion information.

=C2=A0

Since TCP and SCTP have support for ECN, and the fut= ure may see ECN deployment increase yet, it's expected that QUIC would = have equivalent mechanisms to support use of ECN. This work is very much in= scope, as part of the congestion control aspect of QUIC.

=C2=A0

Hope this helps,

- jana

=C2=A0

=C2=A0

=C2=A0

On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson = S <ingemar.s.johansson@ericsson.com> wrote:

Hi

I just uploaded a new version of the ECN in QUIC draft. The main change a d= escription of the ECN negotiation.

/Ingemar

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: den 22 februari 2017 08:56
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: New Version Notification for draft-johansson-quic-ecn-01.txt<= br>

A new version of I-D, draft-johansson-quic-ecn-01.txt has been success= fully submitted by Ingemar Johansson and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-johansson-quic-ecn
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ECN support in QUIC
Document date:=C2=A0 2017-02-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-01.= txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.= ietf.org/doc/draft-johansson-quic-ecn/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/= draft-johansson-quic-ecn-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://ww= w.ietf.org/rfcdiff?url2=3Ddraft-johansson-quic-ecn-01

Abstract:
=C2=A0 =C2=A0This memo outlines the ECN support in QUIC.=C2=A0 The intentio= n is that
=C2=A0 =C2=A0most of the material ends up updating other new or existing QU= IC
=C2=A0 =C2=A0protocol specifications, thus it may be possible that this dra= ft does
=C2=A0 =C2=A0not warrant a working group status.





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

The IETF Secretariat

=C2=A0

=C2=A0


--001a11490382aafd7d054929938b-- From nobody Wed Feb 22 18:47:11 2017 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 B384E129E4D for ; Wed, 22 Feb 2017 18:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 wxv1xuCwarSt for ; Wed, 22 Feb 2017 18:47:07 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::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 0810F1294D2 for ; Wed, 22 Feb 2017 18:47:07 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id g30so14134506uac.3 for ; Wed, 22 Feb 2017 18:47:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sk+qoLkKNf0cK17xFuQJ/Fc43aTQBC+ERbJDmdocesY=; b=GRPXkusaNh97l7FYtKQbeHuccgpZUTy+6mp1/1Dya05FbI5+be6/fVwc4TnPX9TF+7 KGzTXfHskLa68Drbs+lWXWw2KYGQwNRefkbERvNWly/E60Mbw3BfCoFE7IoTa8w54CJI QsqQWHOQ8rlNOro1VYnp1/9jZq9fMPbvblF5YKnm00+82mv5SCju1lgEBFdEaWO1Fram PF1hrLYmFNlszXrD3npeWThI5T+jmhg5nYz4akORCtGfwY/fjQTvEwjQdExm8NN7MHML BoY4n9myf5zF4ysMCDKCg/mBc5pXugA7LuSbQl3KRoaAKwARZ8ebJt6RuJbSQCR3s8Zk wasA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sk+qoLkKNf0cK17xFuQJ/Fc43aTQBC+ERbJDmdocesY=; b=d17/Lzo0MJzyQaDDObTwP2qkIzJpNXqn6zVx0ZOmuO9aK3V1nZztIETvCkCd+BJVio 6urVQJJsjXowRR8IhzkkKL5fuMtRnKyxO6z9KkViX8Xb1jKODQ6JgFJwC6kix9ifALid ySrMjtW+XFWqkwWCLvhg1AuKNkj19oYXIZ6sewwT5L4PqxQWe/YPU7hXNQLQQCJAj5nN BdmjQFGvicpU5tj9OULYEKNc0VQq+xHuMc9DoXqIy1KLMjlLMlk5KlahHHwjIF7lkmFV uX1dIJT6EigWtUIKoIHsw+CQiibuvwODZne26R7eSRLU4Te5/Hz4mhCaOtm1CKSK6n7+ f1Ew== X-Gm-Message-State: AMke39lcdXRHWgs1VXzJo5w0/X5s5m0fupHblo0NmHW+vSXa1QP3/gpld7H8cdzvGkBL0aD1CvrQerJbzB3WHf9C X-Received: by 10.159.40.225 with SMTP id d88mr17501013uad.98.1487818025751; Wed, 22 Feb 2017 18:47:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Wed, 22 Feb 2017 18:47:05 -0800 (PST) In-Reply-To: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> From: Jana Iyengar Date: Wed, 22 Feb 2017 18:47:05 -0800 Message-ID: Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=94eb2c122be8ead136054929a0ef Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 02:47:10 -0000 --94eb2c122be8ead136054929a0ef Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed on the general sentiment. I think we have a good thing here by having folks from various areas in the same wg, in at least that we can make the documents much more readable and understandable than other documents in any of the three areas. On Wed, Feb 22, 2017 at 6:43 PM, Phillip Hallam-Baker wrote: > Not being sarcastic. I am a security guy, not a transport guy. It is over > 25 years since I did work at this level in the stack and the Internet > didn't reach where I was at the time so the terms I am familiar with are > different. What has meaning for you may not have meaning to me. I am > familiar with the concept of congestion control but the acronyms mean > nothing to me. > > The output of a WG is documents. The draft isn't going to become an RFC > with that introduction so it is going to have to be fixed some time. Migh= t > as well fix it now before it is read by all the other parts of the IETF > rather than after they have all scrambled to work out what it is about. > > QUIC is essentially a replacement for TCP in all but one respect. TCP was > only implemented by kernel level hackers and the document only had to be > understood by a small set of people. QUIC is not going to be so limited i= n > scope and the documents had better make sense to the wider audience. > > > On Wed, Feb 22, 2017 at 7:30 PM, Mike Bishop > wrote: > >> I read PHB=E2=80=99s comment as a typically-sarcastic way of saying that= the >> Introduction of this draft assumes quite a bit of knowledge that is perh= aps >> best spelled out with some relevant informative references. That is, af= ter >> all, the point of an introduction. >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Jana Iyengar >> *Sent:* Wednesday, February 22, 2017 3:37 PM >> *To:* Phillip Hallam-Baker >> *Cc:* 'gorry@erg.abdn.ac.uk' (gorry@erg.abdn.ac.uk) ; >> Bob Briscoe (ietf@bobbriscoe.net) ; Ingemar >> Johansson S ; >> mirja.kuehlewind@tik.ee.ethz.ch; marcelo bagnulo braun < >> marcelo@it.uc3m.es>; Piers O'Hanlon ; IETF >> QUIC WG ; De Schepper, Koen (Nokia - BE) < >> koen.de_schepper@nokia-bell-labs.com> >> *Subject:* Re: FW: New Version Notification for >> draft-johansson-quic-ecn-01.txt >> >> >> >> On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Baker < >> phill@hallambaker.com> wrote: >> >> This is the entirety of the introduction: >> >> >> >> ECN support in transport protocols is a fundamental feature that >> >> should be included in the QUIC specification as a mandatory element. >> >> The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits]. The >> >> ECN support should be implemented to support both present and future >> >> ECN, the latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation], >> >> of particular interest is the ability to discriminate between classic >> >> ECN and L4S ECN by means of differentiation between the use of the >> >> ECT(0) and ECT(1) code points. This draft does however not delve >> >> into the details of the congestion control implementation. >> >> >> >> I have absolutely no idea what ECN is. I am opposed to the WG spending >> any time on ECN until it can be explained in terms that do not reference >> yet more jargon. >> >> >> >> Happy to help. ECN is defined in RFC 3168 >> , and is an explicit signal from >> the a network switch or router about congestion at a link, so that >> endpoints can use this signal instead of loss for detecting and reacting= to >> congestion. The benefits of doing this are documented int he I-D that is >> linked in the abstract. ECN has been a pretty significant thing in >> transport for about two decades, but has had an uphill battle since ECN >> requires support in the network and at endpoints. >> >> >> >> There have been many efforts to try and deploy it in network devices and >> at endpoints for about as long as RFC 3168 has existed. ECN has been >> deployed in bits at routers and in endpoints, but due to long-standing b= ugs >> in older home-routers and wifi boxes, and issues around use of these bit= s >> in the IP header, it was generally not turned on anywhere. This seems to= be >> changing now, especially as bufferbloat becomes an increasingly visible >> issue. Brian Trammell (IAB) and Mirja Kuehlewind (Transport AD) have bee= n >> actively doing measurement about the current deployment state of ECN; >> here's a blog post by Brian >> from >> last summer saying that a large number of webservers do support ECN. >> There's support for ECN built into TCP (see Section 3.2 and 4.3 of the T= CP >> Roadmap RFC ), there's been a >> ton of work around re-using ECN signaling for richer congestion informat= ion. >> >> >> >> Since TCP and SCTP have support for ECN, and the future may see ECN >> deployment increase yet, it's expected that QUIC would have equivalent >> mechanisms to support use of ECN. This work is very much in scope, as pa= rt >> of the congestion control aspect of QUIC. >> >> >> >> Hope this helps, >> >> - jana >> >> >> >> >> >> >> >> On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S < >> ingemar.s.johansson@ericsson.com> wrote: >> >> Hi >> >> I just uploaded a new version of the ECN in QUIC draft. The main change = a >> description of the ECN negotiation. >> >> /Ingemar >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: den 22 februari 2017 08:56 >> To: Ingemar Johansson S >> Subject: New Version Notification for draft-johansson-quic-ecn-01.txt >> >> >> A new version of I-D, draft-johansson-quic-ecn-01.txt has been >> successfully submitted by Ingemar Johansson and posted to the IETF >> repository. >> >> Name: draft-johansson-quic-ecn >> Revision: 01 >> Title: ECN support in QUIC >> Document date: 2017-02-21 >> Group: Individual Submission >> Pages: 12 >> URL: https://www.ietf.org/internet- >> drafts/draft-johansson-quic-ecn-01.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-johansson-quic-ecn/ >> Htmlized: https://tools.ietf.org/html/draft-johansson-quic-ecn-01 >> Diff: https://www.ietf.org/rfcdiff? >> url2=3Ddraft-johansson-quic-ecn-01 >> >> Abstract: >> This memo outlines the ECN support in QUIC. The intention is that >> most of the material ends up updating other new or existing QUIC >> protocol specifications, thus it may be possible that this draft does >> not warrant a working group status. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> >> >> >> > > --94eb2c122be8ead136054929a0ef Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Agreed on the general sentiment. I think we have a good th= ing here by having folks from various areas in the same wg, in at least tha= t we can make the documents much more readable and understandable than othe= r documents in any of the three areas.


On Wed, Feb 22, 2017 at 6:43 PM, = Phillip Hallam-Baker <phill@hallambaker.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
Not being sarcastic. I am a security guy, not a = transport guy. It is over 25 years since I did work at this level in the st= ack and the Internet didn't reach where I was at the time so the terms = I am familiar with are different. What has meaning for you may not have mea= ning to me. I am familiar with the concept of congestion control but the ac= ronyms mean nothing to me.

The output of a WG is documents. The draft isn't going to become an R= FC with that introduction so it is going to have to be fixed some time. Mig= ht as well fix it now before it is read by all the other parts of the IETF = rather than after they have all scrambled to work out what it is about.

QUIC is essentially a replac= ement for TCP in all but one respect. TCP was only implemented by kernel le= vel hackers and the document only had to be understood by a small set of pe= ople. QUIC is not going to be so limited in scope and the documents had bet= ter make sense to the wider audience.


On Wed, Feb 22, 2017 at 7:30 PM, Mik= e Bishop <Michael.Bishop@microsoft.com> wrote:

I read PHB=E2=80=99s comment as a typically-sarcasti= c way of saying that the Introduction of this draft assumes quite a bit of = knowledge that is perhaps best spelled out with some relevant informative r= eferences.=C2=A0 That is, after all, the point of an introduction.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Jana Iyengar
Sent: Wednesday, February 22, 2017 3:37 PM
To: Phillip Hallam-Baker <phill@hallambaker.com>
Cc: 'g= orry@erg.abdn.ac.uk' (gorry@erg.abdn.ac.uk) <gorry@erg.abdn.ac.uk>; Bob Briscoe (ietf@bobbriscoe.net)= <ietf@bobbrisc= oe.net>; Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; mirja.kuehlewind@tik.ee.ethz.ch; marcelo bagnulo braun <marcelo@it.uc3m.es>= ;; Piers O'Hanlon <piers.ohanlon@cs.ox.ac.uk>; IETF QUIC WG <quic@ietf.org>; De Schepper,= Koen (Nokia - BE) <koen.de_schepper@nokia-bell-labs.com>
Subject: Re: FW: New Version Notification for draft-johansson-quic-e= cn-01.txt

=C2=A0

On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Bak= er <phill@hal= lambaker.com> wrote:

This is the entiret= y of the introduction: =C2=A0

=C2=A0

=C2=A0 =C2=A0ECN su= pport in transport protocols is a fundamental feature that

=C2=A0 =C2=A0should= be included in the QUIC specification as a mandatory element.

=C2=A0 =C2=A0The be= nefits of ECN is described in [I-D.ietf-aqm-ecn-benefits].=C2=A0 The=

=C2=A0 =C2=A0ECN su= pport should be implemented to support both present and future

=C2=A0 =C2=A0ECN, t= he latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation],<= u>

=C2=A0 =C2=A0of par= ticular interest is the ability to discriminate between classic

=C2=A0 =C2=A0ECN an= d L4S ECN by means of differentiation between the use of the<= /span>

=C2=A0 =C2=A0ECT(0)= and ECT(1) code points.=C2=A0 This draft does however not delve<= /u>

=C2=A0 =C2=A0into t= he details of the congestion control implementation.

=C2=A0

I have absolutely n= o idea what ECN is. I am opposed to the WG spending any time on ECN until i= t can be explained in terms that do not reference yet more jargon.

=C2=A0

Happy to help. ECN is defined in RFC 3168, and is an explicit signal from the a network switch or router= about congestion at a link, so that endpoints can use this signal instead = of loss for detecting and reacting to congestion. The benefits of doing thi= s are documented int he I-D that is linked in the abstract. ECN has been a pretty significant thing in tran= sport for about two decades, but has had an uphill battle since ECN require= s support in the network and at endpoints.=C2=A0

=C2=A0

There have been many efforts to try and deploy it in= network devices and at endpoints for about as long as RFC 3168 has existed= . ECN has been deployed in bits at routers and in endpoints, but due to lon= g-standing bugs in older home-routers and wifi boxes, and issues around use of these bits in the IP header, it w= as generally not turned on anywhere. This seems to be changing now, especia= lly as bufferbloat becomes an increasingly visible issue. Brian Trammell (I= AB) and Mirja Kuehlewind (Transport AD) have been actively doing measurement about the current deployment stat= e of ECN; here's a blog post by Brian=C2=A0from last summer saying that a large number of = webservers do support ECN. There's support for ECN built into TCP (see = Section 3.2 and 4.3 of the TCP = Roadmap RFC), there's been a ton of work around re-using ECN signal= ing for richer congestion information.

=C2=A0

Since TCP and SCTP have support for ECN, and the fut= ure may see ECN deployment increase yet, it's expected that QUIC would = have equivalent mechanisms to support use of ECN. This work is very much in= scope, as part of the congestion control aspect of QUIC.

=C2=A0

Hope this helps,

- jana

=C2=A0

=C2=A0

=C2=A0

On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson = S <ingemar.s.johansson@ericsson.com> wrote:

Hi

I just uploaded a new version of the ECN in QUIC draft. The main change a d= escription of the ECN negotiation.

/Ingemar

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: den 22 februari 2017 08:56
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: New Version Notification for draft-johansson-quic-ecn-01.txt<= br>

A new version of I-D, draft-johansson-quic-ecn-01.txt has been success= fully submitted by Ingemar Johansson and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-johansson-quic-ecn
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ECN support in QUIC
Document date:=C2=A0 2017-02-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-01.= txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.= ietf.org/doc/draft-johansson-quic-ecn/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/= draft-johansson-quic-ecn-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://ww= w.ietf.org/rfcdiff?url2=3Ddraft-johansson-quic-ecn-01

Abstract:
=C2=A0 =C2=A0This memo outlines the ECN support in QUIC.=C2=A0 The intentio= n is that
=C2=A0 =C2=A0most of the material ends up updating other new or existing QU= IC
=C2=A0 =C2=A0protocol specifications, thus it may be possible that this dra= ft does
=C2=A0 =C2=A0not warrant a working group status.





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

The IETF Secretariat

=C2=A0

=C2=A0



--94eb2c122be8ead136054929a0ef-- From nobody Wed Feb 22 20:14:30 2017 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 40E6512A032 for ; Wed, 22 Feb 2017 20:14:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jnWntg-sCzVp for ; Wed, 22 Feb 2017 20:14:25 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::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 4BD1E12A02F for ; Wed, 22 Feb 2017 20:14:25 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id z127so10942307lfa.2 for ; Wed, 22 Feb 2017 20:14:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yNNXglGVHAoP+K0btT2voDMfeP90eBmQzpqT24u5Fdw=; b=FFNGaKAREKje6jeOIx41+153RWTmPCki0FTXzAT7bz4AM5GzsN+RtmSpH8EFB9/Fl0 d8wzAFamCpMQAe/Re0AsydaNSJm4cemd6aUpaMVQ9ldyhT09Bs4t3z6iKMsYZICBTAs7 VG42gYQF+nSvo2PhCBdZWpWivjI7QpcwMlxeKbdxCSFEz4VZDYGwPL2X/R2mwrG+airJ tx6uM4KmI0R+J5/uowhQVYV84rxQ/Tz7ZFndTQy5UtXtcT4wKq541ABwGN2+PTMlEDiE HgfTNoicyvlGhE/unt8izFMwcdApF5FFMHC1UMGU61J3MhxadjsVWb470GI/8Kf3F86g kdHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yNNXglGVHAoP+K0btT2voDMfeP90eBmQzpqT24u5Fdw=; b=pDtI/5rkmD8EztrOvQl1EwULombABUIVSMrTfhcH7LJuKGzTpCc62fZGpyO7IprIc3 XssvQDTm8T7OLRUBujV+jKse2MEObZqQq/Bu0DszhXapGAA9YXjKn1D9Qd8atFCBF8mL xkqz6vGlkkr4u7snq5QsCfGbfoMs3u0ekW9S2IXTfCMziXS3MVoySwmJgSn8Ao9yG0Cj /2HW0gcba63QHKsw+F1MHUX+CBYvi+2vQNBmrcq01zAHTiXYIanXXey78nGljK0PDKt2 kZT//egcnTJ6Cp0EYd6MdgO034rPqHlHmIp5NobamdfIqqh+HIkuX49PgGJ/XVCy53i/ k0Ww== X-Gm-Message-State: AMke39mD62+80AXXlnr8M16GOomjPP6ASKPhEqaJzvtDFcCFyum9Co8NOjAXmJszqLZKCbVO4Wbvp9zq4kgNbw== X-Received: by 10.46.88.85 with SMTP id x21mr9788378ljd.90.1487823263242; Wed, 22 Feb 2017 20:14:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.75.25 with HTTP; Wed, 22 Feb 2017 20:14:22 -0800 (PST) From: Martin Thomson Date: Thu, 23 Feb 2017 15:14:22 +1100 Message-ID: Subject: Packet protection and ACK To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 04:14:27 -0000 Issue 34 has a discussion about what rules we need around the use of packet protection and ACK frames. I've opened https://github.com/quicwg/base-drafts/pull/336 in the hopes that I can close the issue by capturing the conclusion there. In short, ACK can't include acknowledgments for packets that have more protection than the packet that the ACK sits in. This is a little tricky during the handshake, but the rules aren't that complex. This might be a technical change (I'm not 100% sure, but I think that it's at least consistent with practice), so I thought that I'd run this by the list. Feel free to object. From nobody Wed Feb 22 22:59:00 2017 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 734AC1295F6 for ; Wed, 22 Feb 2017 22:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXg_aeAcU7IO for ; Wed, 22 Feb 2017 22:58:54 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7C2812960E for ; Wed, 22 Feb 2017 22:58:53 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id r141so3587562wmg.1 for ; Wed, 22 Feb 2017 22:58:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=Jjqr5PzGxFMNU9Q+XeTbyy1lu45tbu3wRaSNod0zKSY=; b=dyCFO+qTdfNIqwNrIMlR4igEtAucXePjSBX0Wvur/cEMhP/8exkkB8Ou93GWfxTaWo osHvGdruDsB+E1/oIBM4FLV//9KttfPb0cE5+MVRfChmazOBDncZpK24WY2/T8OrjYWa 37DS1POLfJHsnMgkYeoC8UzVRhNJ47t88XEo2V6ii43vh/KUK/688cHpewchEmzebn+6 9creqdNo6ZBYagtwgSzR7SgIBscYNtGUbK0g7DV1nq+/gzcu/IpvqMgHZ4VDC35QAd9T 5QIihyZwaJpvRo2QCuL46FqxPCMAVJYifSheNpIGNeexphdOSYeAs0G0DNbm+2KIsb1V 5ipQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Jjqr5PzGxFMNU9Q+XeTbyy1lu45tbu3wRaSNod0zKSY=; b=dxN5q3nYRHSXrNLvE6NRQQKfUSHcS44g1LB/LdbPdcd2Tsq7aVRyz7YPsc1fcIv3Jp 2nyLC/OCRMcmgPr7ZtBtceH8LmTD9YaZ6L07XUAtlzfGsN9FGnHiSdcqQ1dFuCwvHkM/ MgbSv+Jg3nfjhxoYjY98rENHs6T6MHUf4HuNfe5GWltUWaCuHWXb8R+b53CA21tfFdc4 Vv0TnNhU555gqviq0lRMtg1q3xdItcv9AaEPNK7y6keUa0AvptayiVxcfPRfyPqc6ejg qH9tDlsRDYdHgR4cJQXrbJcMnkeWlfhBvxpPTG8UNCIX9Lt7zWfSgC0VRW4XkNA05Yay M05g== X-Gm-Message-State: AMke39n770ZGqBWFsIvk6J8bG3tmNA4mQgIOXyUUHQivWDT22cybDLjqQiZQEr/Z/J++hXEd X-Received: by 10.28.220.135 with SMTP id t129mr2674307wmg.38.1487833131897; Wed, 22 Feb 2017 22:58:51 -0800 (PST) Received: from Macintosh-6.local ([2001:720:410:1010:b582:5e2b:7da9:21fd]) by smtp.gmail.com with ESMTPSA id z80sm4758881wrc.24.2017.02.22.22.58.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 22 Feb 2017 22:58:51 -0800 (PST) Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: Phillip Hallam-Baker , IETF QUIC WG References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> From: marcelo bagnulo braun Message-ID: <6a7c4ca2-1955-d290-a400-9f9eefe49671@it.uc3m.es> Date: Thu, 23 Feb 2017 07:58:49 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 06:58:57 -0000 below... El 23/02/17 a las 03:43, Phillip Hallam-Baker escribió: > > The output of a WG is documents. The draft isn't going to become an > RFC with that introduction so it is going to have to be fixed some time. Not really The abstract of the document reads: This memo outlines the ECN support in QUIC. The intention is that most of the material ends up updating other new or existing QUIC protocol specifications, thus it may be possible that this draft does not warrant a working group status. IMHO, the current use of the ECN concepts and terminology in the document is ok for a document that is for internal consumption of a TSV area WG. > Might as well fix it now before it is read by all the other parts of > the IETF rather than after they have all scrambled to work out what it > is about. > > QUIC is essentially a replacement for TCP in all but one respect. TCP > was only implemented by kernel level hackers and the document only had > to be understood by a small set of people. QUIC is not going to be so > limited in scope and the documents had better make sense to the wider > audience. > > > On Wed, Feb 22, 2017 at 7:30 PM, Mike Bishop > > > wrote: > > I read PHB’s comment as a typically-sarcastic way of saying that > the Introduction of this draft assumes quite a bit of knowledge > that is perhaps best spelled out with some relevant informative > references. That is, after all, the point of an introduction. > > *From:* QUIC [mailto:quic-bounces@ietf.org > ] *On Behalf Of *Jana Iyengar > *Sent:* Wednesday, February 22, 2017 3:37 PM > *To:* Phillip Hallam-Baker > > *Cc:* 'gorry@erg.abdn.ac.uk ' > (gorry@erg.abdn.ac.uk ) > >; Bob Briscoe > (ietf@bobbriscoe.net ) > >; Ingemar > Johansson S >; > mirja.kuehlewind@tik.ee.ethz.ch > ; marcelo bagnulo braun > >; Piers O'Hanlon > >; > IETF QUIC WG >; De Schepper, > Koen (Nokia - BE) > > *Subject:* Re: FW: New Version Notification for > draft-johansson-quic-ecn-01.txt > > On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Baker > > wrote: > > This is the entirety of the introduction: > > ECN support in transport protocols is a fundamental feature > that > > should be included in the QUIC specification as a mandatory > element. > > The benefits of ECN is described in > [I-D.ietf-aqm-ecn-benefits]. The > > ECN support should be implemented to support both present > and future > > ECN, the latter is outlined in > [I-D.ietf-tsvwg-ecn-experimentation], > > of particular interest is the ability to discriminate > between classic > > ECN and L4S ECN by means of differentiation between the use > of the > > ECT(0) and ECT(1) code points. This draft does however not > delve > > into the details of the congestion control implementation. > > I have absolutely no idea what ECN is. I am opposed to the WG > spending any time on ECN until it can be explained in terms > that do not reference yet more jargon. > > Happy to help. ECN is defined in RFC 3168 > , and is an explicit signal > from the a network switch or router about congestion at a link, so > that endpoints can use this signal instead of loss for detecting > and reacting to congestion. The benefits of doing this are > documented int he I-D that is linked in the abstract. ECN has been > a pretty significant thing in transport for about two decades, but > has had an uphill battle since ECN requires support in the network > and at endpoints. > > There have been many efforts to try and deploy it in network > devices and at endpoints for about as long as RFC 3168 has > existed. ECN has been deployed in bits at routers and in > endpoints, but due to long-standing bugs in older home-routers and > wifi boxes, and issues around use of these bits in the IP header, > it was generally not turned on anywhere. This seems to be changing > now, especially as bufferbloat becomes an increasingly visible > issue. Brian Trammell (IAB) and Mirja Kuehlewind (Transport AD) > have been actively doing measurement about the current deployment > state of ECN; here's a blog post by Brian > from > last summer saying that a large number of webservers do support > ECN. There's support for ECN built into TCP (see Section 3.2 and > 4.3 of the TCP Roadmap RFC > ), there's been a ton of > work around re-using ECN signaling for richer congestion information. > > Since TCP and SCTP have support for ECN, and the future may see > ECN deployment increase yet, it's expected that QUIC would have > equivalent mechanisms to support use of ECN. This work is very > much in scope, as part of the congestion control aspect of QUIC. > > Hope this helps, > > - jana > > On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S > > wrote: > > Hi > > I just uploaded a new version of the ECN in QUIC draft. > The main change a description of the ECN negotiation. > > /Ingemar > > -----Original Message----- > From: internet-drafts@ietf.org > > [mailto:internet-drafts@ietf.org > ] > Sent: den 22 februari 2017 08:56 > To: Ingemar Johansson S > > Subject: New Version Notification for > draft-johansson-quic-ecn-01.txt > > > A new version of I-D, draft-johansson-quic-ecn-01.txt has > been successfully submitted by Ingemar Johansson and > posted to the IETF repository. > > Name: draft-johansson-quic-ecn > Revision: 01 > Title: ECN support in QUIC > Document date: 2017-02-21 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-01.txt > > Status: > https://datatracker.ietf.org/doc/draft-johansson-quic-ecn/ > > Htmlized: > https://tools.ietf.org/html/draft-johansson-quic-ecn-01 > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-johansson-quic-ecn-01 > > > Abstract: > This memo outlines the ECN support in QUIC. The > intention is that > most of the material ends up updating other new or > existing QUIC > protocol specifications, thus it may be possible that > this draft does > not warrant a working group status. > > > > > > Please note that it may take a couple of minutes from the > time of submission until the htmlized version and diff are > available at tools.ietf.org . > > The IETF Secretariat > > From nobody Thu Feb 23 01:09:53 2017 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 57602129682 for ; Thu, 23 Feb 2017 01:09:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JHZo2lGJifDG for ; Thu, 23 Feb 2017 01:09:48 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0091.outbound.protection.outlook.com [104.47.93.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3CF212A14E for ; Thu, 23 Feb 2017 01:09:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=26n/gEpxfJ758ouQJ+vDMkYAlaZwmjsVmwzyLnI/cFU=; b=QAZRHFdPmpoSRhDvrAWbLxsD1FyAhyKgRiOFn5qUjTQxDKXXfa4t8eaXw5NS/j6c+LwuQ1k15iGHcWpM/CrR1ty3SmjzJJWPDRe6PIU5oQlN71HZAO1tmnHbMnNqFy3hA8werhX2AtKil3bGJwCuFBmWrymFci5SPg0+SLRqO/g= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0651.jpnprd01.prod.outlook.com (10.167.158.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 09:09:44 +0000 Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: marcelo bagnulo braun , Phillip Hallam-Baker , IETF QUIC WG References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> <6a7c4ca2-1955-d290-a400-9f9eefe49671@it.uc3m.es> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: Date: Thu, 23 Feb 2017 18:09:42 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <6a7c4ca2-1955-d290-a400-9f9eefe49671@it.uc3m.es> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: OSXPR01CA0053.jpnprd01.prod.outlook.com (10.167.144.33) To TY1PR01MB0651.jpnprd01.prod.outlook.com (10.167.158.14) X-MS-Office365-Filtering-Correlation-Id: 4ccb6bc6-69b0-4629-7802-08d45bcbb58d X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:TY1PR01MB0651; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 3:QnXMQC+O+GiZrQZLHhLhYewgsNMIuENkghj06ZdULyWhgnP94k3BMjdSSNqP98V/uST3IlRZM7AQBklqyIJ0vo5dXF1MNoRdAJ99BnqSnPjrfiPwvYbRgfzTuyQg6Dra3efB6UNBjvBvMZx7Ydv6sZeudyfID7/KqoQTq2ezflSAO2JFdzFMJrLUsYft4jmw6EO9EJESVP53GYVaR5ecmpOh9VaA1uliB+MjfnGNwJ4qxd0FFNDZsf1YMpqyv4FafsGb4Vt14W+NbxeqaHIuLg==; 25:yJVARlm3VSxe8HuLZ1tiFvsiq8/cooWEGoXumDWXK1RbQq6TLCiGTvlzhF6mGSUduR/vK6wYOkxIxPofq1lKMY+Ax9WUgQAzSaxM9cQ7xIxMjxk2bkiLhAje0kAlsELv5s6iLGF0SiMezk2zwFSMk0AAJdmOx1vp7V4ctkiuQYGKitGsAb3G75RzBXARr01TDpqGVAWjrtkhS4wA94f8+ODr2XLs2LVS3IXoUK8CTb3i3DXMMt3FxWuCjnLF6NCfLQ6fTtKtRMxKdO8GIPJgHEo4adBph5SPfoZgKAtk+gojfn/9WHv4vLA2nXYcz5IW30wkMspIsEmbYkCIV7NMLscjjJYxwZNrEa0c1acwOwNszkiFtaV8lkHeT0QywPOSoLnZrjOlE1wdfMyD+Yq5KQMR7CdqpFZ8fGrQb85QDXxqumUMWzohaLR9IA8xMB85RTxFoU7u9NaAMAayAtvTPw== X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 31:1hdrAB4HOha8dOj/ZsFBDVT9IR1dz4omjH2a4SAtfZcrUgB9fv59ys0sLTAEqB1g7+sps/yM31WYPrwkPu52EjJrDTXqHJF+hb36Hu9dkiL1ixtzBLt5qNnLCz3btwjpXRpsoEJnf+L/3NHgxeI+IT7kJ1zRJB1V0d9T6VP9/gaNa8MX7oTkeG/41TSkL9M/HI36QzDkimPci/ffF97WHq+MiFRE2YOWb2ijlY8VeOnpO4d26UCQfwP+VlgvWL+3bV2A0npYRMn8GWvFSuiueA==; 4:qD0zRmnTP06HGkACSVnNFXZfJz1rIU3DGkSS/cXCLfzUvGCP1blOqzOWe2PoiiFlzXlY/EatsjBxuB+Dgk9hB0n49rLkFHafMdpzImiFdD3RNJKkAumUgow4rfDePwByDRdPuTT6LJ71N8FuKdbebRYnH0nyqT25o9MFF28Nn6+/LBgYlFn7fW1vmmyJvy1dggiWrkraSlQumo4woyZGDJUnOJu9od2wVKQ64jG4NkzHDAJnlrrCGWHsAEgtSZAfrhdSnb4W+g6BkKARHeNGXRoY6riDZ85YtQ8LzaSb7ilFqFYDdYMdng89aogz/Sr8ohP1SDtOCwISaelg4xpWrJLqcnonq3UM4VSt4qZpxooAO3UJtyp0hB4kICq4rG3F60vMTP7TJpqNynymf7y7lPXrIvj5VZWWghd98IR2rvhgBdUcIGLyycDfqQZjPl0l4KCCxujSHR2Ga5q0JbsCCGZlOWNV9qmeG/yiRHG07klvX3MDEPzlQgG6KvcVdzWhcCBfyLw9n39q4asbIetQBnVr78h5i4l1r5ygaC+UZE6ZAHSOgJmkAXk8TTqx0oTL8Gxv6pCPNmkNYcWVKTjTkA== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(20161123558025)(6072148); SRVR:TY1PR01MB0651; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0651; X-Forefront-PRVS: 02272225C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(24454002)(199003)(189002)(92566002)(105586002)(86362001)(10710500007)(7110500001)(66066001)(2420400007)(2906002)(189998001)(7736002)(15650500001)(6246003)(31696002)(305945005)(106356001)(2870700001)(25786008)(47776003)(64126003)(97736004)(230783001)(4001350100001)(50466002)(38730400002)(65826007)(83506001)(74482002)(50986999)(53546006)(6306002)(90366009)(54356999)(966004)(68736007)(81166006)(23676002)(101416001)(53936002)(3846002)(2950100002)(81156014)(42882006)(5660300001)(8676002)(76176999)(93886004)(65956001)(65806001)(31686004)(6116002)(229853002)(33646002)(42186005)(6486002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0651; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:3; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwNjUxOzIzOmc1Q2haanovNTh2SE9hQlV1dVVDOUFRci82?= =?utf-8?B?bmV6UCtoT1krbjZ1TkhKUUlKN2FYL204eU1SZ1lSV3A5VnNWTUxwa1p5YXln?= =?utf-8?B?UWIxTDg2TXdHbWdmQ2FsWGxUb0tFZFNDL29OVVdvaTRBRzdWZXJhd1NXdHNx?= =?utf-8?B?QUk3Z0tPK1V5czZ5UEU2SzFGN1dOcmVMN1F6SG1PYzlUanhRRFNhSU8wak1T?= =?utf-8?B?ZGZxRy9tK0dnbHJQWEpYd1M3aXU3WnEyeTJjMk91NEN3eWFucG9iRXZQRzhU?= =?utf-8?B?d094WlNuUkprb3ZMOG8wNXRLY2Q3T2V6cFFlc0pSazVEdnp2MUFnd1lFdUZV?= =?utf-8?B?VktxYWQ2eWd5RWVpRlEzZlhRRXhWdE1rYTFiMFY2WWUrOVJvT0FJRk9ORmpC?= =?utf-8?B?VE51L2ZSdXVqVmJzV04ydXdOOTMyQXB1TjlmSnVlOE1JMmdjUHdDdW52amlp?= =?utf-8?B?R0FhS2tOQTM5alg4Zis5WDVIN2FNUWZMYiswTWoxMXE2eHRmbjZ4SW1MMDJO?= =?utf-8?B?aHorUE5sUXJzQTJzM3dsanQ5NVZRaXgyeWVJeGdYMkNSTFZRWmd2V24xNUpB?= =?utf-8?B?K0w4WmVNN1FPTGh5RzhYRmpsWDYyYUJYU2g5QUl4RXVVY0w2VG9EMkZmUVpu?= =?utf-8?B?Q2t6OG9oR3I5T3RJV2ZhVEs2TUI4a0ZGM3dDRHhxZHZGMjNRWFl1RWdpMXdK?= =?utf-8?B?VVB6aG1TVTdRMDBRTFRRbzRxTlRVemdXeHFMVDYwOWlIYXEwWDFpNGZDWk9p?= =?utf-8?B?amlUd0Jic1RScUh4cThyVlprK3Y5NDlBekYrT1IrK0o0RmhZR1pVdUE3ZzZy?= =?utf-8?B?NXFmUXg3YWlLVktscWNXTXBWZzF3TFAyeWJLY3ZreGs5ditCbVVjVWRZVmVh?= =?utf-8?B?MVRCSXo2TFVkZWtYSEF1d3FYQ1JKQ1V5dHhSdExqa25BRmRPeGdwVk9Xck9t?= =?utf-8?B?a042c2JTbndwZGpWZ0VsUjFsdEM2STBPZUlUK0k5bWNjZmRtK3RCaDBIWmNa?= =?utf-8?B?cjVSa3M1L3VsMTFpTTFDeWk4SHUrUnFIZElSUWpKUkY1YzBzcTZSSS8zVWU1?= =?utf-8?B?TU1ONGFCcFZ4MTR4ekt5czBXTHJySVdOdkszWHBseW9FY1VyUkVtSTdnL2Zn?= =?utf-8?B?S2RhanZFcU1XcjdiT0hQN0V2eVU5RkpNOHZPbTBhY1BrTTh4T0xtbnhoNTZM?= =?utf-8?B?MDVaWm9aTHM3aFhsMG45L2c5TkZnOWZoSjcwVFlDbWRmdktjVFoyRnJkekVx?= =?utf-8?B?djRaWGQwRTRnWHdTUTI1ZzBoVStHWjFRcDkydVlrc1U1N3pJVGF4VUxoVVpY?= =?utf-8?B?cWRCUlJrMDQvRWxFMU4zREMxdDNTZSs2Rys4N2Zyd1hqcmtxOUtVWnpZYk9m?= =?utf-8?B?SmU2ZGV5M3FUb0ZPNkdPbUJoK0h0M1ZDQy8zeFBwaTd4TWlUQ01QSlFMVG8w?= =?utf-8?B?Q3BIZjJQTERWRlNxREtLbjVnb0VlMFJvamh3NHF1Q21pRllQdnZLVjV2NldC?= =?utf-8?B?eHAwR1NYWmZTajlJSStOemNvbVB1ZkNQaCtrMkcwTDFKYURUa1dUM21iYXJl?= =?utf-8?B?cm1tWm80dHZ5ajdLTmFpVk9YNEl6YXU4ZzNjRWNoL3AweU92MEN6K1drWmY4?= =?utf-8?B?blVvdFVjRm83dTBYd2JEclRJa1hMOFJ3VVQ4a251dnhrVVArSWhpM21JRDQ3?= =?utf-8?B?NXNYMG1kTGIrclBnWU9yS0xsanpCNEpzUC9ZdWE4SjJWVmNveU11RUkrRzNi?= =?utf-8?B?aU9zS1k0bHBndjhmQlhXUzJiTEN4a3dKVm15aWl1SVhGdEtJYTZ3SEVWUGZu?= =?utf-8?B?MWxVWkEwZTBkUzhNMzhNK2YvNVhHcWN2eDlVMVF4VXFiRjRMTHpvTWN1TFRJ?= =?utf-8?B?ZFAwcGJNbmt1Q0s4WCswR29yNWE2Wk0yYjd0UVRoUFlOeU4rcTM1U2l1OHA0?= =?utf-8?B?aWdhL3F5TC9JbjREbXZ0YkUvRmpCa25rMWVpRmMweVRIbzhhU1VvT3ZSTVpp?= =?utf-8?B?WG9LdFlZc1EybkRRbDJOSzdOWFV4SU5yMlFvbDVJa3QxbWdOMkhXMW1vNmd5?= =?utf-8?Q?JS/U=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 6:pdWOvtlVz/UV4aL8/1j3YpYJKXsdcPBZCyF37QY4wF5GdOQXHR09N11XeUj28s6SF87Zq1PO8JLoYhbffiV7NACS7N7QygJOsh6QzTBsjkbpxvWrs/aJa6Bp9WC0Z4GF/XDNAbLjDMjIVrSdTTGegSJ6c1Xj4UXHWUeb8Z2g4z7JOLaREYSjeWh9DL3uEgIFTXRyJvUss8Yn4Hd7w35lBIUe5Vj0+Hb2UkKSon/rsLDZQ05w4HxqHOwzxQ7NmYrD8VEuiNTNous3ta4swhxPxKQuCL6lCG2Q4VoJDn4OFBkAbAJN1/gNm87Le5sQVtphgZ8X2rktT0BmVOxMagK+aaqoY6IJx/NVKv5HyjoZ4EGIkSgI2l+wIRraDu4nzWifrKTe01z82CNiaBeKyhg8eA==; 5:v0W2D+4z/cJMHXRv2P+YraFxnrJ1hhOFKez1+XgkXV9BhrTLG6zG936pjL3fEW7KPUvgPG59yePdDeXZyCXIEtHsJNuS3IHDEr10NEhx5fVDPxz1FB0lGIUSw2QcizMkD1Ld+yGvUy8ZNeR4Glxstw==; 24:t5wNYa2thWHnqbG2peMtzyzWxNmJJtLohxGGvtnaFpE6XisqZbA+q3aj/ahh0bik2SG3YU5pVb5yoEmwAQcS3qfLfr8PozQpfmcW5zUljmY= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 7:IYvmYtsw2666yijM42GpC04HWoIY6IvmU0r5ZVj0+jNS3YhuObyUAv8t/8xv9rjwZ/JPgXLVJaxNHCo9uaMYOTOdoSR26gFIGb4JMoMah/Qh+H/Hc+JZVmAk50Pcjjd3H6Y6QU2yvZ8/Kk3nwNsThBHmyew/MbjKUsdbHiPWid1q9/TNsfB+ZrbYySFn7W6Hv0vFohsUqiyQSyJdJRaSRai2sA9hylIyhBvo9CA/+U9bv0yFgJwAil1G1TFjtWOt46SF+hWuV9jEB0dZuiKI62Xq5wz9lRc/3pn99+K2kYCTiyHlx3F9PPCZZMvcI1ht/j6edlnIoVNuEJJsMrXC8A== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 23 Feb 2017 09:09:44.6877 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0651 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 09:09:52 -0000 On 2017/02/23 15:58, marcelo bagnulo braun wrote: > El 23/02/17 a las 03:43, Phillip Hallam-Baker escribió: >> >> The output of a WG is documents. The draft isn't going to become an >> RFC with that introduction so it is going to have to be fixed some time. > Not really > > The abstract of the document reads: > > This memo outlines the ECN support in QUIC. The intention is that > most of the material ends up updating other new or existing QUIC > protocol specifications, thus it may be possible that this draft does > not warrant a working group status. > > IMHO, the current use of the ECN concepts and terminology in the > document is ok for a document that is for internal consumption of a TSV > area WG. It would be nevertheless extremely helpful if that acronym would be expanded once, e.g. early in the introduction. Using "Explicit Congestion Notification" in the title would be even better, there are already many good examples for this: https://tools.ietf.org/html/rfc6679 https://tools.ietf.org/html/rfc7560 https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-00 https://tools.ietf.org/html/draft-ietf-aqm-ecn-benefits-08 https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-00 and to some extent https://tools.ietf.org/html/rfc6789 "Explicit Congestion Notification" is pretty much self-explaining, but "ENC" isn't even on a list like http://acronyms.thefreedictionary.com/ENC. >> Might as well fix it now before it is read by all the other parts of >> the IETF rather than after they have all scrambled to work out what it >> is about. Yes, please. Regards, Martin. From nobody Thu Feb 23 01:35:12 2017 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 8A51B12956A for ; Thu, 23 Feb 2017 01:35:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVW4m4PXAEDa for ; Thu, 23 Feb 2017 01:35:08 -0800 (PST) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930591293FB for ; Thu, 23 Feb 2017 01:35:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3vTTbt5zX2z15Myn; Thu, 23 Feb 2017 10:35:06 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vu5OnwGu_Yib; Thu, 23 Feb 2017 10:35:03 +0100 (CET) X-MtScore: NO score=0 Received: from [82.130.103.143] (nb-10510.ethz.ch [82.130.103.143]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 23 Feb 2017 10:35:03 +0100 (CET) Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: Phillip Hallam-Baker , IETF QUIC WG References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?Mirja_K=c3=bchlewind?= Message-ID: <0404cec1-bbee-0e59-d648-5920428ddd33@tik.ee.ethz.ch> Date: Thu, 23 Feb 2017 10:35:03 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 09:35:11 -0000 This is a completely useless discussion but at this point I really strongly disagree. This is a DRAFT; it not ready for publication and in this case it also will never be published as RFC (as you assume wrongly). This document is discussing different options how to integrate ECN in draft-ietf-quic-transport. If you don't know what ECN is, this draft is probably not directed at you. If you want to learn what ECN, it's easy to find RFC3168 or wikipedia on the Internet. However, the fundamental point here is that I rather see a non-perfect draft as a basis for discussion that everybody who is interested can look at, then having private side-discussions. Putting the bar higher on what a -00 or -01 or whatever version of a draft should be is wrong! On 23.02.2017 03:43, Phillip Hallam-Baker wrote: > Not being sarcastic. I am a security guy, not a transport guy. It is over 25 > years since I did work at this level in the stack and the Internet didn't > reach where I was at the time so the terms I am familiar with are different. > What has meaning for you may not have meaning to me. I am familiar with the > concept of congestion control but the acronyms mean nothing to me. > > The output of a WG is documents. The draft isn't going to become an RFC with > that introduction so it is going to have to be fixed some time. Might as well > fix it now before it is read by all the other parts of the IETF rather than > after they have all scrambled to work out what it is about. > > QUIC is essentially a replacement for TCP in all but one respect. TCP was > only implemented by kernel level hackers and the document only had to be > understood by a small set of people. QUIC is not going to be so limited in > scope and the documents had better make sense to the wider audience. > > > On Wed, Feb 22, 2017 at 7:30 PM, Mike Bishop > wrote: > > I read PHB’s comment as a typically-sarcastic way of saying that the > Introduction of this draft assumes quite a bit of knowledge that is > perhaps best spelled out with some relevant informative references. That > is, after all, the point of an introduction.____ > > __ __ > > *From:* QUIC [mailto:quic-bounces@ietf.org > ] *On Behalf Of *Jana Iyengar > *Sent:* Wednesday, February 22, 2017 3:37 PM > *To:* Phillip Hallam-Baker > > *Cc:* 'gorry@erg.abdn.ac.uk ' > (gorry@erg.abdn.ac.uk ) > >; Bob Briscoe > (ietf@bobbriscoe.net ) >; Ingemar Johansson S > >; > mirja.kuehlewind@tik.ee.ethz.ch ; > marcelo bagnulo braun >; > Piers O'Hanlon >; IETF QUIC WG >; De Schepper, Koen (Nokia - BE) > > > *Subject:* Re: FW: New Version Notification for > draft-johansson-quic-ecn-01.txt____ > > __ __ > > On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Baker > > wrote:____ > > This is the entirety of the introduction: ____ > > __ __ > > ECN support in transport protocols is a fundamental feature that____ > > should be included in the QUIC specification as a mandatory > element.____ > > The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits]. > The____ > > ECN support should be implemented to support both present and > future____ > > ECN, the latter is outlined in > [I-D.ietf-tsvwg-ecn-experimentation],____ > > of particular interest is the ability to discriminate between > classic____ > > ECN and L4S ECN by means of differentiation between the use of the____ > > ECT(0) and ECT(1) code points. This draft does however not delve____ > > into the details of the congestion control implementation.____ > > __ __ > > I have absolutely no idea what ECN is. I am opposed to the WG > spending any time on ECN until it can be explained in terms that do > not reference yet more jargon.____ > > __ __ > > Happy to help. ECN is defined in RFC 3168 > , and is an explicit signal from the > a network switch or router about congestion at a link, so that endpoints > can use this signal instead of loss for detecting and reacting to > congestion. The benefits of doing this are documented int he I-D that is > linked in the abstract. ECN has been a pretty significant thing in > transport for about two decades, but has had an uphill battle since ECN > requires support in the network and at endpoints. ____ > > __ __ > > There have been many efforts to try and deploy it in network devices and > at endpoints for about as long as RFC 3168 has existed. ECN has been > deployed in bits at routers and in endpoints, but due to long-standing > bugs in older home-routers and wifi boxes, and issues around use of these > bits in the IP header, it was generally not turned on anywhere. This > seems to be changing now, especially as bufferbloat becomes an > increasingly visible issue. Brian Trammell (IAB) and Mirja Kuehlewind > (Transport AD) have been actively doing measurement about the current > deployment state of ECN; here's a blog post by Brian > from > last summer saying that a large number of webservers do support ECN. > There's support for ECN built into TCP (see Section 3.2 and 4.3 of the > TCP Roadmap RFC ), there's been > a ton of work around re-using ECN signaling for richer congestion > information.____ > > __ __ > > Since TCP and SCTP have support for ECN, and the future may see ECN > deployment increase yet, it's expected that QUIC would have equivalent > mechanisms to support use of ECN. This work is very much in scope, as > part of the congestion control aspect of QUIC.____ > > __ __ > > Hope this helps,____ > > - jana____ > > __ __ > > __ __ > > __ __ > > On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S > > wrote:____ > > Hi > > I just uploaded a new version of the ECN in QUIC draft. The main > change a description of the ECN negotiation. > > /Ingemar > > -----Original Message----- > From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org ] > Sent: den 22 februari 2017 08:56 > To: Ingemar Johansson S > > Subject: New Version Notification for draft-johansson-quic-ecn-01.txt > > > A new version of I-D, draft-johansson-quic-ecn-01.txt has been > successfully submitted by Ingemar Johansson and posted to the > IETF repository. > > Name: draft-johansson-quic-ecn > Revision: 01 > Title: ECN support in QUIC > Document date: 2017-02-21 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-01.txt > > Status: > https://datatracker.ietf.org/doc/draft-johansson-quic-ecn/ > > Htmlized: > https://tools.ietf.org/html/draft-johansson-quic-ecn-01 > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-johansson-quic-ecn-01 > > > Abstract: > This memo outlines the ECN support in QUIC. The intention is that > most of the material ends up updating other new or existing QUIC > protocol specifications, thus it may be possible that this > draft does > not warrant a working group status. > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org . > > The IETF Secretariat____ > > __ __ > > __ __ > > From nobody Thu Feb 23 04:49:10 2017 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 08AD9129D10 for ; Thu, 23 Feb 2017 04:49:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 heLQm6IQM6XN for ; Thu, 23 Feb 2017 04:49:07 -0800 (PST) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::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 80ABE12970F for ; Thu, 23 Feb 2017 04:49:07 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id v200so15908902ywc.3 for ; Thu, 23 Feb 2017 04:49:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o7SIZGghhF1GViaiBBibj7iI2Xcs/qFMbPZdcxH3Sw4=; b=YlIZOfxTkAZJZfoTjkOckZwLblRkMxauhY0Qw5B/sT3Gqs8hFr12LvR0kP7NdWACUC WbZL/RUYzzs1cRCV7Z6yvnDBO/k5KFSJn/savlsEEXvQq7YgUZ5LH/cGeR5/UK7sAhN4 3YZS1vduqcObmoxRdV/CnBombnIg2Bm82LKUifdtPJHxbzOAb7HbG3bY3U8zwFA4YFcq uZmf+D42aM4m7XUKZXzcXDaWY2LYg3ItavcRI5FVciz5NKYWlxY6p54pdqrKS0dfDxRg oUzMSd8h7pIjAYzqOnoPzoQoV4ZY9VSneoVR+3YG9u3HdkWTTZcB8rzraJpvhZEQdKvo 6tzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o7SIZGghhF1GViaiBBibj7iI2Xcs/qFMbPZdcxH3Sw4=; b=qnfysOTYfFaOvAaeXSJzIcvnvo/tz/Jzaydqfm2GBAPkewq71ZPOSlCc+jpLyn2DY7 71+a9sb9q/XoNQQaVWrqOlfOHAE0TXdPn9ta+j96aJMUNYRIBNWLJ91671KAOIIwctRl ffBN4lxl3kW1kA39ofefL27qA4Vf8N7VhXqRnpecus8DVaekaoorc8CXzFjUw7p7p7PP fv5RsK+LG5vgoKNvwtuc9WwK0YnnAq9yWAHbA1Hr3CejFzI+AeAbG+9iHGlvRsExlDYK JWy/+V1Ugbt+k3Z08muTBmAeWPsqHhl1XuLaNI3AjkK7Y7jecBl0ldNUAn9n6FfvXayc mcfQ== X-Gm-Message-State: AMke39lzFi14qOoezlzQJ+EWAKyBUquo/PE3DfBBcZ1yuWWpzu50rRafYxQ/qsVz7SblNTnOhIEPebed9w1brA== X-Received: by 10.129.108.131 with SMTP id h125mr28067944ywc.71.1487854146673; Thu, 23 Feb 2017 04:49:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 23 Feb 2017 04:48:26 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 23 Feb 2017 04:48:26 -0800 Message-ID: Subject: Re: Error handling and Public Reset To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114dcf78e4101505493209c8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 12:49:09 -0000 --001a114dcf78e4101505493209c8 Content-Type: text/plain; charset=UTF-8 There's been a fair amount of discussion on this PR, but it seems like we first need to resolve the high level design issue of who can send a public reset. Specifically: - Off-path elements - On-path elements which are not endpoints - Endpoints I think we agree that off-path elements should not be able to send acceptable public resets, but disagree about whether on-path elements which are not endpoints should be able to do so and if so whether they should be distinguishable from those sent by endpoints. As I indicated in PR#20 and the subsequent discussion, I don't think it's ideal for on-path elements to be able to send public resets because this leads to easy Great Firewall "man-on-the-side" type attacks, and it is possible to design a public reset mechanism in which the endpoints can have minimal persistent state and yet generate public resets that cannot be forged. If we add such a mechanism we can also, if we like, add one that allows on-path elements to generate public resets, but because these are weaker, they should be distinguishable so that endpoints can reject them. I recognize that there isn't consensus on this view -- at least no declared consensus -- though I don't believe that the contrary view has consensus either, but I think we need to resolve this before dealing with PR#335. -Ekr On Wed, Feb 22, 2017 at 4:29 PM, Martin Thomson wrote: > I've put together a PR (hehe) that attempts to close on the discussion > we've had about public reset. I've expanded it to include more > details on error handling. This includes discussion on what to do > with connection close. > > I have not added anything about what to do with undelivered data. > That will follow once the current discussion concludes. > > https://github.com/quicwg/base-drafts/pull/335 > > --001a114dcf78e4101505493209c8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
There's been a fair amount of discussion on = this PR, but it seems like
we first need to resolve the high leve= l design issue of who can send a
public reset. Specifically:

- Off-path elements
- On-path elements which= are not endpoints
- Endpoints

I think w= e agree that off-path elements should not be able to send
accepta= ble public resets, but disagree about whether on-path elements
wh= ich are not endpoints should be able to do so and if so whether they
<= div>should be distinguishable from those sent by endpoints. As I indicated<= /div>
in PR#20 and the subsequent discussion, I don't think it'= s ideal for
on-path elements to be able to send public resets bec= ause this leads
to easy Great Firewall "man-on-the-side"= ; type attacks, and it is
possible to design a public reset mecha= nism in which the endpoints can
have minimal persistent state and= yet generate public resets that
cannot be forged. If we add such= a mechanism we can also, if we like,
add one that allows on-path= elements to generate public resets, but
because these are weaker= , they should be distinguishable so that
endpoints can reject the= m.

I recognize that there isn't consensus= on this view -- at least no
declared consensus -- though I don&#= 39;t believe that the contrary view
has consensus either, but I t= hink we need to resolve this before
dealing with PR#335.

-Ekr


On Wed, Feb 22, 2017 at 4:29 PM,= Martin Thomson <martin.thomson@gmail.com> wrote:
=
I've put together a PR (hehe) that attem= pts to close on the discussion
we've had about public reset.=C2=A0 I've expanded it to include mor= e
details on error handling.=C2=A0 This includes discussion on what to do
with connection close.

I have not added anything about what to do with undelivered data.
That will follow once the current discussion concludes.

https://github.com/quicwg/base-drafts/pull/335


--001a114dcf78e4101505493209c8-- From nobody Thu Feb 23 05:42:45 2017 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 97EBB12A1CB for ; Thu, 23 Feb 2017 05:42:44 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 DCqlQ1o5SHpE for ; Thu, 23 Feb 2017 05:42:43 -0800 (PST) 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 042EA12978B for ; Thu, 23 Feb 2017 05:42:43 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id p77so16618539ywg.1 for ; Thu, 23 Feb 2017 05:42:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RvnUpXuv09p8fitMkziw0OicGxHoqj5ubs4IRlgaZsg=; b=fDxM40VjMjedTIDrCNk8SHMwUJWzWaqNbRPvUoprYeaWK1o0vGeBpHc1B3jMuQVIW0 JUe9q8xHkoyvip/X26yYrjNDBLBmUhWgwufTm39PwKwu33ayjqYfJlNemAkS1+tOhEdn GVDj+bN6UeWCrDABNI0HPgUK1stZNbmWopI7jdt6clcrQdMWpzkx9kNE4+5YU3w5b4tj 5F+CRWUJ10pn2qLKNHfmfssvHTYwW3JOS22BSKSMbHnEltJU+o0vyNb528Q9lolg9w1n gN0tSVXJGLVSdoFbPu7RIBeQ1xBipt+Pm0c8iz87q5SbWy1hFl6yGkXDlIA24pt1oW3B Z5Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=RvnUpXuv09p8fitMkziw0OicGxHoqj5ubs4IRlgaZsg=; b=pviAo+iXkdVor4e9UDzsargJVdHvljjVD+DSRcnV/i4om1gxSGgdDkS0+tHbje5bMg fRXHTD8DlXI+D1H1tnDgaWHM/7S/THTfbnwJ2R5+b6+Rih/X3f1IKWcxGCLUcVzxT3w0 9/TwULuFKPfT8OYA+OUpBMQhmWMGdG0+hLapz6jnYBDGk0pOpqShgLSgll/4PDz08hWI K3/KJuhHMOu553Fi8nCt0IG79SuPXflqDKcZEfp+1DHA+t7PQUU8xojwJBYwOpxdNgIT DqEja0HehQbV1lTeFDzzQkwle4rUe5sX8nHP2bYTkdR9E2Vyz5Vx60y+iN0OtPrMsuFe 04xg== X-Gm-Message-State: AMke39lF99nGIDsPPeRjI/NKK5ndkru0vt2bqqpZkp48d9irkwHAAJZNUcvwJv3ASKvG791qc97iE4i2R02MsA8v X-Received: by 10.129.182.101 with SMTP id h37mr11940513ywk.177.1487857361987; Thu, 23 Feb 2017 05:42:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.50.139 with HTTP; Thu, 23 Feb 2017 05:42:21 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 23 Feb 2017 08:42:21 -0500 Message-ID: Subject: Re: Packet protection and ACK To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045d20ca8a0f5b054932c9aa Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 13:42:44 -0000 --f403045d20ca8a0f5b054932c9aa Content-Type: text/plain; charset=UTF-8 I think this is definitely the right thing to do. I'm not sure if it's a change, or just specifying correct behavior in a case we'd only recently started thinking about in more detail. Thanks for the PR. On Wed, Feb 22, 2017 at 11:14 PM, Martin Thomson wrote: > Issue 34 has a discussion about what rules we need around the use of > packet protection and ACK frames. > > I've opened https://github.com/quicwg/base-drafts/pull/336 in the > hopes that I can close the issue by capturing the conclusion there. > > In short, ACK can't include acknowledgments for packets that have more > protection than the packet that the ACK sits in. This is a little > tricky during the handshake, but the rules aren't that complex. > > This might be a technical change (I'm not 100% sure, but I think that > it's at least consistent with practice), so I thought that I'd run > this by the list. Feel free to object. > > --f403045d20ca8a0f5b054932c9aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think this is definitely the right thing to do.=C2=A0 I&= #39;m not sure if it's a change, or just specifying correct behavior in= a case we'd only recently started thinking about in more detail.
<= br>
Thanks for the PR.

=
On Wed, Feb 22, 2017 at 11:14 PM, Martin Thomson= <martin.thomson@gmail.com> wrote:
Issue 34 has a discussion about what rules we need around= the use of
packet protection and ACK frames.

I've opened https://github.com/quicwg/base-dr= afts/pull/336 in the
hopes that I can close the issue by capturing the conclusion there.

In short, ACK can't include acknowledgments for packets that have more<= br> protection than the packet that the ACK sits in.=C2=A0 This is a little
tricky during the handshake, but the rules aren't that complex.

This might be a technical change (I'm not 100% sure, but I think that it's at least consistent with practice), so I thought that I'd run<= br> this by the list.=C2=A0 Feel free to object.


--f403045d20ca8a0f5b054932c9aa-- From nobody Thu Feb 23 07:07:30 2017 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 EC432129959 for ; Thu, 23 Feb 2017 07:07:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yMYZ_2h9ynby for ; Thu, 23 Feb 2017 07:07:28 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 A7D51129893 for ; Thu, 23 Feb 2017 07:07:28 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id v200so17794705ywc.3 for ; Thu, 23 Feb 2017 07:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=uGBydrntFUf0SiEMz/gq8ueVtWKrcaZJJfDj5J3mQcw=; b=bC8LC+D607yO29GlLun453ZVA+Ugk1h1WOOK+WzWtkOezFqZv7pYTbKSPs1lCuu1pj mRJvaHwz3SXFaW6A6D6zgnHRJqijL2szP3QM7s/Z4z+U/bG7ZHFfeJ9OGRM+IErfSyKy 8Sfrme+5xDaPZXyB5CV0g8/7aDNFkl+u85xoIX8h+R07O/oXuYLTedsNWMJVk98sGrYk q9tVMZPzaVL8gmjuHmxkGFLES3OU9CUXse17FxPsV0m+c3uRyl0YL19SnA7tJL+361eA zXvtoWAk4GKfWVtB3gvZRPFfVT0MXmiupDCmXk8Z1l3NycGq7CSpCRPDWzjjM3mT/31H pWPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=uGBydrntFUf0SiEMz/gq8ueVtWKrcaZJJfDj5J3mQcw=; b=bC4bGKtyP2CIbe+7WY4gzS9nRwqAqK6abzXIF6MLvj50xCpMwVy+KREizk/9iCr+No vlqS9XPR5/2Kyy12heJdMQhvsrYydA64Mm3QUCAfqA7TPHbs2pKa5fTl66QF92kGcBzY iOUvdncp/ERosUCs+V9n6VMwdposg1RwXnAC91ov256Mu3x80h/ddFYN5kRQrdZNIzg3 9zYhdjB3XZZ6LEGZbkRToMh4Gyk+EDK6wouk8lS8wh5VYmdh+zl075R/dxTOX+7kB4N2 YqvVjrgmjboFNzJ8A3mNsglLwHhLVqjj4MAwpIlRk2462WAJbayd12RQGZG4yNuwENFI Aizg== X-Gm-Message-State: AMke39n/MxO3XGMDLy8+GStKWNCcc+XsAtc0HXZj7wIl50r5L+vd7bawoSO1ia1pp3utaHIWyQdC5HCiUQ6C5A== X-Received: by 10.129.163.202 with SMTP id a193mr27568906ywh.285.1487862447807; Thu, 23 Feb 2017 07:07:27 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.17.140 with HTTP; Thu, 23 Feb 2017 07:07:27 -0800 (PST) In-Reply-To: <0404cec1-bbee-0e59-d648-5920428ddd33@tik.ee.ethz.ch> References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> <0404cec1-bbee-0e59-d648-5920428ddd33@tik.ee.ethz.ch> From: Phillip Hallam-Baker Date: Thu, 23 Feb 2017 10:07:27 -0500 X-Google-Sender-Auth: pADbyxYOMdTB1IzsQaZyoavwzQI Message-ID: Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=94eb2c12901ead2436054933f8a6 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 15:07:30 -0000 --94eb2c12901ead2436054933f8a6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2017 at 4:35 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > This is a completely useless discussion but at this point I really > strongly disagree. This is a DRAFT; it not ready for publication and in > this case it also will never be published as RFC (as you assume wrongly). =E2=80=8BDrafts are for discussion. If the draft is written to limit discus= sion to a small clique then something is wrong.=E2=80=8B > This document is discussing different options how to integrate ECN in > draft-ietf-quic-transport. If you don't know what ECN is, =E2=80=8BOh I know what Explicit Congestion Notification is. But ECN on its= own means nothing to me because I work in so many areas.=E2=80=8B =E2=80=8B To me, ECN means Electronic Communications Network and is a place where stocks and options are being traded. It also means Emergency Communications Network which is another issue we deal with in IETF. =E2=80=8B this draft is probably not directed at you. =E2=80=8BThat was my bigger problem with this particular group. This was no= t the first draft that was rather obviously only written for consideration by a closed circle. If you want to discuss things in closed circles then the IETF probably isn't for you. Having waded through the first set of drafts and found them worse than useless, my tolerance level was not high when I began reading yet another draft that rather obviously assumed that this is all a private discussion and nobody who isn't a member of the club is welcome. However, the latest protocol draft does look like something I can implement from. --94eb2c12901ead2436054933f8a6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Thu, Feb 23, 2017 at 4:35 AM, Mirja K=C3=BChlewind <mirja.ku= ehlewind@tik.ee.ethz.ch> wrote:
This is = a completely useless discussion but at this point I really strongly disagre= e. This is a DRAFT; it not ready for publication and in this case it also w= ill never be published as RFC (as you assume wrongly).
=E2=80= =8BDrafts are for discussion. If the draft is written to limit discussion t= o a small clique then something is wrong.=E2=80=8B

=C2=A0
This document is discuss= ing different options how to integrate ECN in draft-ietf-quic-transport. If= you don't know what ECN is,

=E2=80=8BOh I know what Expli= cit Congestion Notification is. But ECN on its own means nothing to me beca= use I work in so many areas.=E2=80=8B
=E2=80=8B
To me, ECN means Electronic Communications Network = and is a place where stocks and options are being traded. It also means Eme= rgency Communications Network which is another issue we deal with in IETF.= =C2=A0
=E2=80= =8B

this draft is probably not directed at yo= u.

=E2=80=8BThat was my bigger problem with this particular gr= oup. This was not the first draft that was rather obviously only written fo= r consideration by a closed circle. If you want to discuss things in closed= circles then the IETF probably isn't for you.

Having waded through the first set of draft= s and found them worse than useless, my tolerance level was not high when I= began reading yet another draft that rather obviously assumed that this is= all a private discussion and nobody who isn't a member of the club is = welcome.

However, the lat= est protocol draft does look like something I can implement from.
--94eb2c12901ead2436054933f8a6-- From nobody Thu Feb 23 09:20:38 2017 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 E35981296CE for ; Thu, 23 Feb 2017 09:20:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZn-OzcVnri4 for ; Thu, 23 Feb 2017 09:20:35 -0800 (PST) Received: from mail-yb0-x22c.google.com (mail-yb0-x22c.google.com [IPv6:2607:f8b0:4002: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 06A8F129530 for ; Thu, 23 Feb 2017 09:20:35 -0800 (PST) Received: by mail-yb0-x22c.google.com with SMTP id a5so10574065ybb.2 for ; Thu, 23 Feb 2017 09:20:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:from:date:message-id:subject:to; bh=dSviLSuUYsbvlPDiL+rkHY8nGqp23gxr2paHno/lMMw=; b=T0Wp7ryUnfAZQ8HHX7Pfjja1bxRnYTlUpmj/k3Zk15CFFswO9jufkBXhRViu6yU9zf xZmMC3mv91YPAFgdFoM7SzWd1L2ODFTIWhX/RubmZBXogvbSpBGxXkoX5y2FJRT3jJFc iO6vBfPiLMHc0vheOQfFiQrcl7CuCuwMXkqTvUZ3Ha5tlEb7xtai+4lSqy1Nt/IQPOYB 9sn61m1rfMqk/xd2W4dJVPOSNvCuaArceR/NtSVRCJifo53TV/aSNn1PVVf+kq7RYsEz tUi6qayC3NoDNPwvl9dMYfusmZlpHeuK5vBqsQSB+duInD7R17DkuRxpxpPC3JAxwcoR XRFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to; bh=dSviLSuUYsbvlPDiL+rkHY8nGqp23gxr2paHno/lMMw=; b=ZqoUyzSe22gWbvMQaOJ83Rs08yiQFK4ANSrLAByPYdhJ9K77fYGhvAuyCQnj2+ADIo uhCoM7rtx12Zk+RMFdNWAcEQvO+owY+EpXIg5hsU/VrH50ob8sO3ifFcRtavA691YeYx lNAWBovyJBnl2qRunB68ZLQjiw6BvevUiKjBLiilTxM5fe4jQVGfLDY7nnti5vnV2VfH pyU0q3m3WQ82OJ4TXex8K0B0jEVenNpkN41ENf0B6gyVqpFj4CgU9XksADnbK936rCfb HqxvcnmZwnlSJBxiT5DhLaZNyfPmGNQS003Eivlcxl5TDPk1sR85wmGkqyX0/Jh4k1ct /kWQ== X-Gm-Message-State: AMke39nVvQVTrxFKp6f7uF8eL7irXepW63P9MfjrPxJMFNyBwzbvKLbZTymqgN3AOwMFJbnmbyqACbuh6+JpcQ== X-Received: by 10.37.217.132 with SMTP id q126mr16830911ybg.23.1487870433785; Thu, 23 Feb 2017 09:20:33 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.17.140 with HTTP; Thu, 23 Feb 2017 09:20:33 -0800 (PST) From: Phillip Hallam-Baker Date: Thu, 23 Feb 2017 12:20:33 -0500 X-Google-Sender-Auth: RhApe_6fw9BcAYktGilCrKs-_1M Message-ID: Subject: QUIC should be designed for HTTP-Next, not HTTP/2 To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a114fcac6ada1dd054935d46a Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 17:20:37 -0000 --001a114fcac6ada1dd054935d46a Content-Type: text/plain; charset=UTF-8 Like many folk, I had assumed that QUIC should be designed as the next generation TCP to support HTTP/2 which is in turn designed to support Web browsing. I just realized, that is probably a mistake. HTTP for Web browsing is not a protocol I have given much thought to since I left the Web consortium in '96. The chief design goal of HTTP/1.1 was to make the Web work well on dialup. And caching proxies were one of our main tools. HTTP/2 does two things, it optimizes the transfer of header information and it requires use of transport security which has the pleasing (to me) effect of disabling intermediaries. QUIC does many things, including fusing TLS and TCP framing which is a much needed improvement. And it will certainly be a better transport choice for HTTP/2. But what would HTTP for browsing look like if we completely redesigned it for QUIC? BTW, I am aware that HTTP is used for other things, in fact most of my work is on Web Services. But HTTP/2 is even less relevant there as the only HTTP header we usually use are Host and Cache-Control: Never. The best header optimization is not to send them at all. And we can certainly get rid of all the junk that was there for the intermediaries that can't read any of it in any case because it is encrypted. Modern Web pages are by necessity composite objects because most of the expensive to transmit resources appear on multiple pages. The HTTP model is that we request a resource, we get a response, we request another one. First off, content negotiation is not going to change across requests. A browser is not going to learn to interpret a new image format between one request and another for the same page. Or not often enough to bother. So I had assumed we would be using some form of scheme where we push the content negotiation headers at the start of a connection and amortize them across multiple requests. But there is an interesting alternative. A modern Web server can (and usually does) caching internally. So let us assume that the Web server caches the URI stem (the host but not any query part) and the resource it maps to. Out protocol for browsing could then become 1) Request the parent content for the page (i.e. the outer HTML) 2) Send a single request for all the parts that are not cached locally by SHA-256 (URI) 3) Send a single request re-requesting any hashes that were not recognized by the server Each entry in the batched request would consist of: Content identifier [URI or SHA-256(URI)] Cache information [Digest of possibly stale content or other depending on model declared in the cached data] With this model we can reduce requests to 40 bytes and pack ~20 requests into a single packet without even using jumbo frames(!) Of course it would be a mistake to build both together. Error 33, do not build research on research. But the advantages of this approach are going to make it all but inevitable when QUIC matures. The point of raising this now is that what I am seeing in descriptions is QUIC = TCP + TLS + HTTP/2 and I don't think the last bit is going to be right at all. In the Web Services space, all I am interested in really is the ability to define virtual port numbers for my services and some really basic framing. These can be provided by a really simple layer on QUIC that has nothing to do with HTTP. --001a114fcac6ada1dd054935d46a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Lik= e many folk, I had assumed that QUIC should be designed as the next generat= ion TCP to support HTTP/2 which is in turn designed to support Web browsing= .

I just realized, that i= s probably a mistake.

HTT= P for Web browsing is not a protocol I have given much thought to since I l= eft the Web consortium in '96. The chief design goal of HTTP/1.1 was to= make the Web work well on dialup. And caching proxies were one of our main= tools.

HTTP/2 does two t= hings, it optimizes the transfer of header information and it requires use = of transport security which has the pleasing (to me) effect of disabling in= termediaries.
<= br>
QUIC does m= any things, including fusing TLS and TCP framing which is a much needed imp= rovement. And it will certainly be a better transport choice for HTTP/2.


But what would HTTP for browsing look= like if we completely redesigned it for QUIC?

BTW, I am aware that HTTP is used for other things, i= n fact most of my work is on Web Services. But HTTP/2 is even less relevant= there as the only HTTP header we usually use are Host and Cache-Control: N= ever.=C2=A0
The best head= er optimization is not to send them at all. And we can certainly get rid of= all the junk that was there for the intermediaries that can't read any= of it in any case because it is encrypted.

Modern Web pages are by necessity composite objects be= cause most of the expensive to transmit resources appear on multiple pages.= The HTTP model is that we request a resource, we get a response, we reques= t another one.=C2=A0

Firs= t off, content negotiation is not going to change across requests. A browse= r is not going to learn to interpret a new image format between one request= and another for the same page. Or not often enough to bother.

So I had assumed we would be using so= me form of scheme where we push the content negotiation headers at the star= t of a connection and amortize them across multiple requests.

But there is an interesting alternativ= e. A modern Web server can (and usually does) caching internally. So let us= assume that the Web server caches the URI stem (the host but not any query= part) and the resource it maps to. Out protocol for browsing could then be= come

=
1) Request the paren= t content for the page (i.e. the outer HTML)
2) Send a single request for all the parts th= at are not cached locally by SHA-256 (URI)
3) Send a single request re-requesting any hash= es that were not recognized by the server

Each entry in the batched request would consist of:
<= div class=3D"gmail_default" style=3D"font-size:small">
Content identifier [URI or SHA= -256(URI)]
Cach= e information [Digest of possibly stale content or other depending on model= declared in the cached data]

With this model we can reduce requests to 40 bytes and pack ~20 reques= ts into a single packet without even using jumbo frames(!)


Of course it would be a mistake to build both toge= ther. Error 33, do not build research on research. But the advantages of th= is approach are going to make it all but inevitable when QUIC matures. The = point of raising this now is that what I am seeing in descriptions is QUIC = =3D TCP + TLS + HTTP/2 and I don't think the last bit is going to be ri= ght at all.=C2=A0

In the = Web Services space, all I am interested in really is the ability to define = virtual port numbers for my services and some really basic framing. These c= an be provided by a really simple layer on QUIC that has nothing to do with= HTTP.

--001a114fcac6ada1dd054935d46a-- From nobody Thu Feb 23 09:50:00 2017 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 B16BD12A207 for ; Thu, 23 Feb 2017 09:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 tj9L82HzNpcd for ; Thu, 23 Feb 2017 09:49:56 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0121.outbound.protection.outlook.com [104.47.36.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F23E129A6E for ; Thu, 23 Feb 2017 09:49:56 -0800 (PST) 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=/cVlu58doSuNcH7RC4/F+ULOBDOD4ZAHXZO7Gz6KDjg=; b=CxqiJKCPTBJSW6eA3X2pW+2vf4QWlCKoZvAW7Ax549Sx3g9awbP0LEI+qQHjVE5kaoIdc/TXWwehhcmiRnr8FXp5HyQ39dGQbirzotUwjN7Hk7wg97OOxSoUyuG2Q+FNmV3gjr1AXklWD3Wi+vKWyR8yKzC+ZL43lIUgkyEiiac= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.13; Thu, 23 Feb 2017 17:49:54 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0919.018; Thu, 23 Feb 2017 17:49:54 +0000 From: Mike Bishop To: Phillip Hallam-Baker , IETF QUIC WG Subject: RE: QUIC should be designed for HTTP-Next, not HTTP/2 Thread-Topic: QUIC should be designed for HTTP-Next, not HTTP/2 Thread-Index: AQHSjfkpJLAngFcewEmxryIyb1r6RKF23GHg Date: Thu, 23 Feb 2017 17:49:54 +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: hallambaker.com; dkim=none (message not signed) header.d=none;hallambaker.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:9::51f] x-ms-office365-filtering-correlation-id: 69d51a66-824d-46e1-2f0a-08d45c146034 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2708; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2708; 7:wHuar1LKxpzbJyd/jPqdaIThq5U9HGknsELrplQa9YqekPqH2RwOPeV9nSutu6zKTkLVAW2qHRysm8PoDwN7CpBahGqvzZ/kQoNXJ7Ev5K5Jw7ySr2Ibege4kx/s6+Fg3u+Ql4lb4v0WR+3Jbpoyc4imKomiMA5FBH4E0BUCk0LR5fQaxoBmG5VswPpH1lJFZ0kgQbg06r6YAFFSuaiXCTX7iXEHyIj+FlERwiP8zSBs5dN7Z2MU0egI7Q+O4bInkHGzbJm99eT8Gy7edoWBZzKgK2bst55zGXBZ5hCfHzk/idR3itUgp/ucY0HPixdMJDWMwkOUlxdQtK+q2qh2CzAMfoO7/Tc7B5nio9FxzjI= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123560025)(20161123564025)(20161123562025)(20161123555025)(6072148); SRVR:BN6PR03MB2708; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2708; x-forefront-prvs: 02272225C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39860400002)(39840400002)(39450400003)(39850400002)(377454003)(33656002)(106116001)(8936002)(54896002)(2950100002)(10090500001)(8676002)(8990500004)(50986999)(10290500002)(7736002)(76176999)(53546006)(54356999)(77096006)(99286003)(6306002)(55016002)(74316002)(25786008)(2900100001)(9686003)(86612001)(6436002)(229853002)(790700001)(3280700002)(3660700001)(92566002)(53936002)(122556002)(86362001)(7696004)(6116002)(189998001)(102836003)(2906002)(6506006)(5660300001)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2708; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708271FFC7D86DEE881B8AE87530BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2017 17:49:54.7024 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2708 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 17:49:59 -0000 --_000_BN6PR03MB2708271FFC7D86DEE881B8AE87530BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB3b3VsZCBjaGFyYWN0ZXJpemUgSFRUUC8yIGRpZmZlcmVudGx5IOKAkyBhcyB0aGUgUkZDIHNh eXMsIGl04oCZcyBhbiBvcHRpbWl6ZWQgbWFwcGluZyBvZiAodW5jaGFuZ2VkKSBIVFRQIHNlbWFu dGljcyB0byBUQ1AuICBBbmQgSFRUUC9RVUlDIGlzIG5vdCBIVFRQLzIg4oCTIGl0IGlzIGEgbWFw cGluZyBvZiB0aG9zZSBzYW1lIEhUVFAgc2VtYW50aWNzIHRvIFFVSUMuICBUaGVyZSB3aWxsIGJl IHNpbWlsYXJpdGllcyB0byBIVFRQLzIsIGJlY2F1c2UgUVVJQyBwcm92aWRlcyBtYW55IG9mIHRo ZSBmYWN1bHRpZXMgSFRUUC8yIGJ1aWx0IGZvciBpdHNlbGYgaW4gdGhlIGZyYW1pbmcgbGF5ZXIg YXRvcCBUQ1AuICBUaGVyZSB3aWxsIGFsc28gYmUgZGlmZmVyZW5jZXMsIGJlY2F1c2UgUVVJQyBp cyBub3QgVENQICsgZnJhbWluZyBsYXllci4NCg0KV2hhdCB5b3XigJlyZSB0YWxraW5nIGFib3V0 IGlzIGEgbWFqb3IgY2hhbmdlIHRvIEhUVFAgc2VtYW50aWNzIHRoZW1zZWx2ZXMsIHJlZ2FyZGxl c3Mgb2YgdGhlIHRyYW5zcG9ydCBtYXBwaW5nIHRoYXTigJlzIHVzZWQgdG8gY2FycnkgdGhlIG5l dyBzZW1hbnRpY3MuICBJ4oCZbSBjZXJ0YWlubHkgbm90IGF2ZXJzZSB0byB0aGF0LCBhbmQgdGhl IGh0dHBiaXMgV0cgaGFzIGRpc2N1c3NlZCBpbiB0aGUgcGFzdCB0aGF0IHdlIG1pZ2h0IGNvbnNp ZGVyIGEgYnJlYWtpbmctY2hhbmdlIHZlcnNpb24gdGhhdCBldm9sdmVzIHRoZSBIVFRQIHNlbWFu dGljIGxheWVyIGluIHRoZSBmdXR1cmUuICBIb3dldmVyLCBJIHRoaW5rIHlvdeKAmXJlIG9uIHRo ZSByaWdodCBwYWdlIHdpdGgg4oCcZG9u4oCZdCBidWlsZCByZXNlYXJjaCBvbiByZXNlYXJjaC7i gJ0gIFRoaXMgV0cgaXMgY2hhcnRlcmVkIHRvIG1hcCBleGlzdGluZyBIVFRQIHNlbWFudGljcyB0 byB0aGUgbmV3IHRyYW5zcG9ydC4gT25jZSB0aGUgdHJhbnNwb3J0IGl0c2VsZiBpcyBzdGFibGUs IGl0IG1heSB3ZWxsIGJlIHRoZSBiZXN0IHN1YnN0cmF0ZSBmb3IgdGhlIGh0dHBiaXMgV0cgdG8g dXNlIHdoZW4gZGV2ZWxvcGluZyB0aGUgc3VjY2Vzc29yIHRvIEhUVFAsIGJ1dCB0aGF04oCZcyBh biBpdGVtIGZvciB0aGUgZnV0dXJlLiAgKEkgYWxzbyB0aGluayB0aGF0IHRoZSBuZXcgc2VtYW50 aWNzIGNvdWxkIGxpa2VseSBiZSBjYXJyaWVkIG92ZXIgVENQLCBwb3NzaWJseSB3aXRoIGEgZnJh bWluZyBsYXllciwgaWYgdGhlcmXigJlzIGFwcGV0aXRlIHRvIGJ1aWxkIGl0LikNCg0KRnJvbTog UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFBoaWxsaXAg SGFsbGFtLUJha2VyDQpTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMjMsIDIwMTcgOToyMSBBTQ0K VG86IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFFVSUMgc2hvdWxkIGJl IGRlc2lnbmVkIGZvciBIVFRQLU5leHQsIG5vdCBIVFRQLzINCg0KTGlrZSBtYW55IGZvbGssIEkg aGFkIGFzc3VtZWQgdGhhdCBRVUlDIHNob3VsZCBiZSBkZXNpZ25lZCBhcyB0aGUgbmV4dCBnZW5l cmF0aW9uIFRDUCB0byBzdXBwb3J0IEhUVFAvMiB3aGljaCBpcyBpbiB0dXJuIGRlc2lnbmVkIHRv IHN1cHBvcnQgV2ViIGJyb3dzaW5nLg0KDQpJIGp1c3QgcmVhbGl6ZWQsIHRoYXQgaXMgcHJvYmFi bHkgYSBtaXN0YWtlLg0KDQpIVFRQIGZvciBXZWIgYnJvd3NpbmcgaXMgbm90IGEgcHJvdG9jb2wg SSBoYXZlIGdpdmVuIG11Y2ggdGhvdWdodCB0byBzaW5jZSBJIGxlZnQgdGhlIFdlYiBjb25zb3J0 aXVtIGluICc5Ni4gVGhlIGNoaWVmIGRlc2lnbiBnb2FsIG9mIEhUVFAvMS4xIHdhcyB0byBtYWtl IHRoZSBXZWIgd29yayB3ZWxsIG9uIGRpYWx1cC4gQW5kIGNhY2hpbmcgcHJveGllcyB3ZXJlIG9u ZSBvZiBvdXIgbWFpbiB0b29scy4NCg0KSFRUUC8yIGRvZXMgdHdvIHRoaW5ncywgaXQgb3B0aW1p emVzIHRoZSB0cmFuc2ZlciBvZiBoZWFkZXIgaW5mb3JtYXRpb24gYW5kIGl0IHJlcXVpcmVzIHVz ZSBvZiB0cmFuc3BvcnQgc2VjdXJpdHkgd2hpY2ggaGFzIHRoZSBwbGVhc2luZyAodG8gbWUpIGVm ZmVjdCBvZiBkaXNhYmxpbmcgaW50ZXJtZWRpYXJpZXMuDQoNClFVSUMgZG9lcyBtYW55IHRoaW5n cywgaW5jbHVkaW5nIGZ1c2luZyBUTFMgYW5kIFRDUCBmcmFtaW5nIHdoaWNoIGlzIGEgbXVjaCBu ZWVkZWQgaW1wcm92ZW1lbnQuIEFuZCBpdCB3aWxsIGNlcnRhaW5seSBiZSBhIGJldHRlciB0cmFu c3BvcnQgY2hvaWNlIGZvciBIVFRQLzIuDQoNCg0KQnV0IHdoYXQgd291bGQgSFRUUCBmb3IgYnJv d3NpbmcgbG9vayBsaWtlIGlmIHdlIGNvbXBsZXRlbHkgcmVkZXNpZ25lZCBpdCBmb3IgUVVJQz8N Cg0KQlRXLCBJIGFtIGF3YXJlIHRoYXQgSFRUUCBpcyB1c2VkIGZvciBvdGhlciB0aGluZ3MsIGlu IGZhY3QgbW9zdCBvZiBteSB3b3JrIGlzIG9uIFdlYiBTZXJ2aWNlcy4gQnV0IEhUVFAvMiBpcyBl dmVuIGxlc3MgcmVsZXZhbnQgdGhlcmUgYXMgdGhlIG9ubHkgSFRUUCBoZWFkZXIgd2UgdXN1YWxs eSB1c2UgYXJlIEhvc3QgYW5kIENhY2hlLUNvbnRyb2w6IE5ldmVyLg0KDQpUaGUgYmVzdCBoZWFk ZXIgb3B0aW1pemF0aW9uIGlzIG5vdCB0byBzZW5kIHRoZW0gYXQgYWxsLiBBbmQgd2UgY2FuIGNl cnRhaW5seSBnZXQgcmlkIG9mIGFsbCB0aGUganVuayB0aGF0IHdhcyB0aGVyZSBmb3IgdGhlIGlu dGVybWVkaWFyaWVzIHRoYXQgY2FuJ3QgcmVhZCBhbnkgb2YgaXQgaW4gYW55IGNhc2UgYmVjYXVz ZSBpdCBpcyBlbmNyeXB0ZWQuDQoNCk1vZGVybiBXZWIgcGFnZXMgYXJlIGJ5IG5lY2Vzc2l0eSBj b21wb3NpdGUgb2JqZWN0cyBiZWNhdXNlIG1vc3Qgb2YgdGhlIGV4cGVuc2l2ZSB0byB0cmFuc21p dCByZXNvdXJjZXMgYXBwZWFyIG9uIG11bHRpcGxlIHBhZ2VzLiBUaGUgSFRUUCBtb2RlbCBpcyB0 aGF0IHdlIHJlcXVlc3QgYSByZXNvdXJjZSwgd2UgZ2V0IGEgcmVzcG9uc2UsIHdlIHJlcXVlc3Qg YW5vdGhlciBvbmUuDQoNCkZpcnN0IG9mZiwgY29udGVudCBuZWdvdGlhdGlvbiBpcyBub3QgZ29p bmcgdG8gY2hhbmdlIGFjcm9zcyByZXF1ZXN0cy4gQSBicm93c2VyIGlzIG5vdCBnb2luZyB0byBs ZWFybiB0byBpbnRlcnByZXQgYSBuZXcgaW1hZ2UgZm9ybWF0IGJldHdlZW4gb25lIHJlcXVlc3Qg YW5kIGFub3RoZXIgZm9yIHRoZSBzYW1lIHBhZ2UuIE9yIG5vdCBvZnRlbiBlbm91Z2ggdG8gYm90 aGVyLg0KDQpTbyBJIGhhZCBhc3N1bWVkIHdlIHdvdWxkIGJlIHVzaW5nIHNvbWUgZm9ybSBvZiBz Y2hlbWUgd2hlcmUgd2UgcHVzaCB0aGUgY29udGVudCBuZWdvdGlhdGlvbiBoZWFkZXJzIGF0IHRo ZSBzdGFydCBvZiBhIGNvbm5lY3Rpb24gYW5kIGFtb3J0aXplIHRoZW0gYWNyb3NzIG11bHRpcGxl IHJlcXVlc3RzLg0KDQpCdXQgdGhlcmUgaXMgYW4gaW50ZXJlc3RpbmcgYWx0ZXJuYXRpdmUuIEEg bW9kZXJuIFdlYiBzZXJ2ZXIgY2FuIChhbmQgdXN1YWxseSBkb2VzKSBjYWNoaW5nIGludGVybmFs bHkuIFNvIGxldCB1cyBhc3N1bWUgdGhhdCB0aGUgV2ViIHNlcnZlciBjYWNoZXMgdGhlIFVSSSBz dGVtICh0aGUgaG9zdCBidXQgbm90IGFueSBxdWVyeSBwYXJ0KSBhbmQgdGhlIHJlc291cmNlIGl0 IG1hcHMgdG8uIE91dCBwcm90b2NvbCBmb3IgYnJvd3NpbmcgY291bGQgdGhlbiBiZWNvbWUNCg0K MSkgUmVxdWVzdCB0aGUgcGFyZW50IGNvbnRlbnQgZm9yIHRoZSBwYWdlIChpLmUuIHRoZSBvdXRl ciBIVE1MKQ0KMikgU2VuZCBhIHNpbmdsZSByZXF1ZXN0IGZvciBhbGwgdGhlIHBhcnRzIHRoYXQg YXJlIG5vdCBjYWNoZWQgbG9jYWxseSBieSBTSEEtMjU2IChVUkkpDQozKSBTZW5kIGEgc2luZ2xl IHJlcXVlc3QgcmUtcmVxdWVzdGluZyBhbnkgaGFzaGVzIHRoYXQgd2VyZSBub3QgcmVjb2duaXpl ZCBieSB0aGUgc2VydmVyDQoNCkVhY2ggZW50cnkgaW4gdGhlIGJhdGNoZWQgcmVxdWVzdCB3b3Vs ZCBjb25zaXN0IG9mOg0KDQpDb250ZW50IGlkZW50aWZpZXIgW1VSSSBvciBTSEEtMjU2KFVSSSld DQpDYWNoZSBpbmZvcm1hdGlvbiBbRGlnZXN0IG9mIHBvc3NpYmx5IHN0YWxlIGNvbnRlbnQgb3Ig b3RoZXIgZGVwZW5kaW5nIG9uIG1vZGVsIGRlY2xhcmVkIGluIHRoZSBjYWNoZWQgZGF0YV0NCg0K V2l0aCB0aGlzIG1vZGVsIHdlIGNhbiByZWR1Y2UgcmVxdWVzdHMgdG8gNDAgYnl0ZXMgYW5kIHBh Y2sgfjIwIHJlcXVlc3RzIGludG8gYSBzaW5nbGUgcGFja2V0IHdpdGhvdXQgZXZlbiB1c2luZyBq dW1ibyBmcmFtZXMoISkNCg0KDQpPZiBjb3Vyc2UgaXQgd291bGQgYmUgYSBtaXN0YWtlIHRvIGJ1 aWxkIGJvdGggdG9nZXRoZXIuIEVycm9yIDMzLCBkbyBub3QgYnVpbGQgcmVzZWFyY2ggb24gcmVz ZWFyY2guIEJ1dCB0aGUgYWR2YW50YWdlcyBvZiB0aGlzIGFwcHJvYWNoIGFyZSBnb2luZyB0byBt YWtlIGl0IGFsbCBidXQgaW5ldml0YWJsZSB3aGVuIFFVSUMgbWF0dXJlcy4gVGhlIHBvaW50IG9m IHJhaXNpbmcgdGhpcyBub3cgaXMgdGhhdCB3aGF0IEkgYW0gc2VlaW5nIGluIGRlc2NyaXB0aW9u cyBpcyBRVUlDID0gVENQICsgVExTICsgSFRUUC8yIGFuZCBJIGRvbid0IHRoaW5rIHRoZSBsYXN0 IGJpdCBpcyBnb2luZyB0byBiZSByaWdodCBhdCBhbGwuDQoNCkluIHRoZSBXZWIgU2VydmljZXMg c3BhY2UsIGFsbCBJIGFtIGludGVyZXN0ZWQgaW4gcmVhbGx5IGlzIHRoZSBhYmlsaXR5IHRvIGRl ZmluZSB2aXJ0dWFsIHBvcnQgbnVtYmVycyBmb3IgbXkgc2VydmljZXMgYW5kIHNvbWUgcmVhbGx5 IGJhc2ljIGZyYW1pbmcuIFRoZXNlIGNhbiBiZSBwcm92aWRlZCBieSBhIHJlYWxseSBzaW1wbGUg bGF5ZXIgb24gUVVJQyB0aGF0IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggSFRUUC4NCg0K --_000_BN6PR03MB2708271FFC7D86DEE881B8AE87530BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkkgd291bGQgY2hhcmFjdGVyaXplIEhUVFAvMiBkaWZmZXJlbnRseSDigJMgYXMgdGhl IFJGQyBzYXlzLCBpdOKAmXMgYW4gb3B0aW1pemVkIG1hcHBpbmcgb2YgKHVuY2hhbmdlZCkgSFRU UCBzZW1hbnRpY3MgdG8gVENQLiZuYnNwOyBBbmQgSFRUUC9RVUlDIGlzIG5vdCBIVFRQLzIg4oCT IGl0IGlzIGEgbWFwcGluZyBvZiB0aG9zZSBzYW1lIEhUVFAgc2VtYW50aWNzIHRvIFFVSUMuJm5i c3A7IFRoZXJlIHdpbGwgYmUgc2ltaWxhcml0aWVzDQogdG8gSFRUUC8yLCBiZWNhdXNlIFFVSUMg cHJvdmlkZXMgbWFueSBvZiB0aGUgZmFjdWx0aWVzIEhUVFAvMiBidWlsdCBmb3IgaXRzZWxmIGlu IHRoZSBmcmFtaW5nIGxheWVyIGF0b3AgVENQLiZuYnNwOyBUaGVyZSB3aWxsIGFsc28gYmUgZGlm ZmVyZW5jZXMsIGJlY2F1c2UgUVVJQyBpcyBub3QgVENQICYjNDM7IGZyYW1pbmcgbGF5ZXIuPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgeW914oCZcmUgdGFsa2luZyBhYm91dCBpcyBhIG1h am9yIGNoYW5nZSB0byBIVFRQIHNlbWFudGljcyB0aGVtc2VsdmVzLCByZWdhcmRsZXNzIG9mIHRo ZSB0cmFuc3BvcnQgbWFwcGluZyB0aGF04oCZcyB1c2VkIHRvIGNhcnJ5IHRoZSBuZXcgc2VtYW50 aWNzLiZuYnNwOyBJ4oCZbSBjZXJ0YWlubHkgbm90IGF2ZXJzZSB0byB0aGF0LCBhbmQgdGhlIGh0 dHBiaXMgV0cgaGFzIGRpc2N1c3NlZCBpbiB0aGUgcGFzdCB0aGF0IHdlDQogbWlnaHQgY29uc2lk ZXIgYSBicmVha2luZy1jaGFuZ2UgdmVyc2lvbiB0aGF0IGV2b2x2ZXMgdGhlIEhUVFAgc2VtYW50 aWMgbGF5ZXIgaW4gdGhlIGZ1dHVyZS4mbmJzcDsgSG93ZXZlciwgSSB0aGluayB5b3XigJlyZSBv biB0aGUgcmlnaHQgcGFnZSB3aXRoIOKAnGRvbuKAmXQgYnVpbGQgcmVzZWFyY2ggb24gcmVzZWFy Y2gu4oCdJm5ic3A7IFRoaXMgV0cgaXMgY2hhcnRlcmVkIHRvIG1hcCBleGlzdGluZyBIVFRQIHNl bWFudGljcyB0byB0aGUgbmV3IHRyYW5zcG9ydC4gT25jZQ0KIHRoZSB0cmFuc3BvcnQgaXRzZWxm IGlzIHN0YWJsZSwgaXQgbWF5IHdlbGwgYmUgdGhlIGJlc3Qgc3Vic3RyYXRlIGZvciB0aGUgaHR0 cGJpcyBXRyB0byB1c2Ugd2hlbiBkZXZlbG9waW5nIHRoZSBzdWNjZXNzb3IgdG8gSFRUUCwgYnV0 IHRoYXTigJlzIGFuIGl0ZW0gZm9yIHRoZSBmdXR1cmUuJm5ic3A7IChJIGFsc28gdGhpbmsgdGhh dCB0aGUgbmV3IHNlbWFudGljcyBjb3VsZCBsaWtlbHkgYmUgY2FycmllZCBvdmVyIFRDUCwgcG9z c2libHkgd2l0aCBhIGZyYW1pbmcNCiBsYXllciwgaWYgdGhlcmXigJlzIGFwcGV0aXRlIHRvIGJ1 aWxkIGl0Lik8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFFVSUMgW21haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPlBoaWxsaXAgSGFs bGFtLUJha2VyPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAyMywgMjAxNyA5 OjIxIEFNPGJyPg0KPGI+VG86PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFFVSUMgc2hvdWxkIGJlIGRlc2lnbmVkIGZvciBIVFRQLU5l eHQsIG5vdCBIVFRQLzI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+TGlrZSBtYW55IGZvbGssIEkgaGFkIGFzc3VtZWQg dGhhdCBRVUlDIHNob3VsZCBiZSBkZXNpZ25lZCBhcyB0aGUgbmV4dCBnZW5lcmF0aW9uIFRDUCB0 byBzdXBwb3J0IEhUVFAvMiB3aGljaCBpcyBpbiB0dXJuIGRlc2lnbmVkIHRvIHN1cHBvcnQgV2Vi IGJyb3dzaW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+SSBqdXN0IHJlYWxpemVkLCB0aGF0IGlzIHByb2Jh Ymx5IGEgbWlzdGFrZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkhUVFAgZm9yIFdlYiBicm93c2luZyBpcyBu b3QgYSBwcm90b2NvbCBJIGhhdmUgZ2l2ZW4gbXVjaCB0aG91Z2h0IHRvIHNpbmNlIEkgbGVmdCB0 aGUgV2ViIGNvbnNvcnRpdW0gaW4gJzk2LiBUaGUgY2hpZWYgZGVzaWduIGdvYWwgb2YgSFRUUC8x LjEgd2FzIHRvIG1ha2UgdGhlIFdlYiB3b3JrIHdlbGwgb24gZGlhbHVwLiBBbmQgY2FjaGluZyBw cm94aWVzIHdlcmUNCiBvbmUgb2Ygb3VyIG1haW4gdG9vbHMuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5IVFRQ LzIgZG9lcyB0d28gdGhpbmdzLCBpdCBvcHRpbWl6ZXMgdGhlIHRyYW5zZmVyIG9mIGhlYWRlciBp bmZvcm1hdGlvbiBhbmQgaXQgcmVxdWlyZXMgdXNlIG9mIHRyYW5zcG9ydCBzZWN1cml0eSB3aGlj aCBoYXMgdGhlIHBsZWFzaW5nICh0byBtZSkgZWZmZWN0IG9mIGRpc2FibGluZyBpbnRlcm1lZGlh cmllcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlFVSUMgZG9lcyBtYW55IHRoaW5ncywgaW5jbHVkaW5nIGZ1 c2luZyBUTFMgYW5kIFRDUCBmcmFtaW5nIHdoaWNoIGlzIGEgbXVjaCBuZWVkZWQgaW1wcm92ZW1l bnQuIEFuZCBpdCB3aWxsIGNlcnRhaW5seSBiZSBhIGJldHRlciB0cmFuc3BvcnQgY2hvaWNlIGZv ciBIVFRQLzIuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+QnV0IHdoYXQgd291bGQgSFRUUCBmb3IgYnJvd3NpbmcgbG9vayBsaWtlIGlmIHdl IGNvbXBsZXRlbHkgcmVkZXNpZ25lZCBpdCBmb3IgUVVJQz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPkJUVywg SSBhbSBhd2FyZSB0aGF0IEhUVFAgaXMgdXNlZCBmb3Igb3RoZXIgdGhpbmdzLCBpbiBmYWN0IG1v c3Qgb2YgbXkgd29yayBpcyBvbiBXZWIgU2VydmljZXMuIEJ1dCBIVFRQLzIgaXMgZXZlbiBsZXNz IHJlbGV2YW50IHRoZXJlIGFzIHRoZSBvbmx5IEhUVFAgaGVhZGVyIHdlIHVzdWFsbHkgdXNlIGFy ZSBIb3N0IGFuZCBDYWNoZS1Db250cm9sOiBOZXZlci4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPlRo ZSBiZXN0IGhlYWRlciBvcHRpbWl6YXRpb24gaXMgbm90IHRvIHNlbmQgdGhlbSBhdCBhbGwuIEFu ZCB3ZSBjYW4gY2VydGFpbmx5IGdldCByaWQgb2YgYWxsIHRoZSBqdW5rIHRoYXQgd2FzIHRoZXJl IGZvciB0aGUgaW50ZXJtZWRpYXJpZXMgdGhhdCBjYW4ndCByZWFkIGFueSBvZiBpdCBpbiBhbnkg Y2FzZSBiZWNhdXNlIGl0IGlzIGVuY3J5cHRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPk1vZGVybiBXZWIg cGFnZXMgYXJlIGJ5IG5lY2Vzc2l0eSBjb21wb3NpdGUgb2JqZWN0cyBiZWNhdXNlIG1vc3Qgb2Yg dGhlIGV4cGVuc2l2ZSB0byB0cmFuc21pdCByZXNvdXJjZXMgYXBwZWFyIG9uIG11bHRpcGxlIHBh Z2VzLiBUaGUgSFRUUCBtb2RlbCBpcyB0aGF0IHdlIHJlcXVlc3QgYSByZXNvdXJjZSwgd2UgZ2V0 IGEgcmVzcG9uc2UsIHdlIHJlcXVlc3QNCiBhbm90aGVyIG9uZS4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQiPkZpcnN0IG9mZiwgY29udGVudCBuZWdvdGlhdGlvbiBpcyBub3QgZ29pbmcgdG8gY2hhbmdl IGFjcm9zcyByZXF1ZXN0cy4gQSBicm93c2VyIGlzIG5vdCBnb2luZyB0byBsZWFybiB0byBpbnRl cnByZXQgYSBuZXcgaW1hZ2UgZm9ybWF0IGJldHdlZW4gb25lIHJlcXVlc3QgYW5kIGFub3RoZXIg Zm9yIHRoZSBzYW1lIHBhZ2UuIE9yIG5vdCBvZnRlbiBlbm91Z2gNCiB0byBib3RoZXIuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0Ij5TbyBJIGhhZCBhc3N1bWVkIHdlIHdvdWxkIGJlIHVzaW5nIHNvbWUgZm9ybSBv ZiBzY2hlbWUgd2hlcmUgd2UgcHVzaCB0aGUgY29udGVudCBuZWdvdGlhdGlvbiBoZWFkZXJzIGF0 IHRoZSBzdGFydCBvZiBhIGNvbm5lY3Rpb24gYW5kIGFtb3J0aXplIHRoZW0gYWNyb3NzIG11bHRp cGxlIHJlcXVlc3RzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+QnV0IHRoZXJlIGlzIGFuIGludGVyZXN0aW5n IGFsdGVybmF0aXZlLiBBIG1vZGVybiBXZWIgc2VydmVyIGNhbiAoYW5kIHVzdWFsbHkgZG9lcykg Y2FjaGluZyBpbnRlcm5hbGx5LiBTbyBsZXQgdXMgYXNzdW1lIHRoYXQgdGhlIFdlYiBzZXJ2ZXIg Y2FjaGVzIHRoZSBVUkkgc3RlbSAodGhlIGhvc3QgYnV0IG5vdCBhbnkgcXVlcnkgcGFydCkgYW5k IHRoZSByZXNvdXJjZQ0KIGl0IG1hcHMgdG8uIE91dCBwcm90b2NvbCBmb3IgYnJvd3NpbmcgY291 bGQgdGhlbiBiZWNvbWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjEpIFJlcXVlc3QgdGhlIHBhcmVudCBjb250 ZW50IGZvciB0aGUgcGFnZSAoaS5lLiB0aGUgb3V0ZXIgSFRNTCk8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+MikgU2VuZCBhIHNpbmdsZSByZXF1ZXN0IGZvciBhbGwgdGhlIHBhcnRz IHRoYXQgYXJlIG5vdCBjYWNoZWQgbG9jYWxseSBieSBTSEEtMjU2IChVUkkpPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjMpIFNlbmQgYSBzaW5nbGUgcmVxdWVzdCByZS1yZXF1ZXN0 aW5nIGFueSBoYXNoZXMgdGhhdCB3ZXJlIG5vdCByZWNvZ25pemVkIGJ5IHRoZSBzZXJ2ZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQiPkVhY2ggZW50cnkgaW4gdGhlIGJhdGNoZWQgcmVxdWVzdCB3b3VsZCBjb25z aXN0IG9mOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdCI+Q29udGVudCBpZGVudGlmaWVyIFtVUkkgb3IgU0hBLTI1 NihVUkkpXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5DYWNoZSBpbmZvcm1hdGlv biBbRGlnZXN0IG9mIHBvc3NpYmx5IHN0YWxlIGNvbnRlbnQgb3Igb3RoZXIgZGVwZW5kaW5nIG9u IG1vZGVsIGRlY2xhcmVkIGluIHRoZSBjYWNoZWQgZGF0YV08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPldpdGgg dGhpcyBtb2RlbCB3ZSBjYW4gcmVkdWNlIHJlcXVlc3RzIHRvIDQwIGJ5dGVzIGFuZCBwYWNrIH4y MCByZXF1ZXN0cyBpbnRvIGEgc2luZ2xlIHBhY2tldCB3aXRob3V0IGV2ZW4gdXNpbmcganVtYm8g ZnJhbWVzKCEpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdCI+T2YgY291cnNlIGl0IHdvdWxkIGJlIGEgbWlzdGFrZSB0byBidWlsZCBib3RoIHRv Z2V0aGVyLiBFcnJvciAzMywgZG8gbm90IGJ1aWxkIHJlc2VhcmNoIG9uIHJlc2VhcmNoLiBCdXQg dGhlIGFkdmFudGFnZXMgb2YgdGhpcyBhcHByb2FjaCBhcmUgZ29pbmcgdG8gbWFrZSBpdCBhbGwg YnV0IGluZXZpdGFibGUgd2hlbiBRVUlDIG1hdHVyZXMuIFRoZSBwb2ludA0KIG9mIHJhaXNpbmcg dGhpcyBub3cgaXMgdGhhdCB3aGF0IEkgYW0gc2VlaW5nIGluIGRlc2NyaXB0aW9ucyBpcyBRVUlD ID0gVENQICYjNDM7IFRMUyAmIzQzOyBIVFRQLzIgYW5kIEkgZG9uJ3QgdGhpbmsgdGhlIGxhc3Qg Yml0IGlzIGdvaW5nIHRvIGJlIHJpZ2h0IGF0IGFsbC4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPklu IHRoZSBXZWIgU2VydmljZXMgc3BhY2UsIGFsbCBJIGFtIGludGVyZXN0ZWQgaW4gcmVhbGx5IGlz IHRoZSBhYmlsaXR5IHRvIGRlZmluZSB2aXJ0dWFsIHBvcnQgbnVtYmVycyBmb3IgbXkgc2Vydmlj ZXMgYW5kIHNvbWUgcmVhbGx5IGJhc2ljIGZyYW1pbmcuIFRoZXNlIGNhbiBiZSBwcm92aWRlZCBi eSBhIHJlYWxseSBzaW1wbGUgbGF5ZXIgb24gUVVJQw0KIHRoYXQgaGFzIG5vdGhpbmcgdG8gZG8g d2l0aCBIVFRQLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_BN6PR03MB2708271FFC7D86DEE881B8AE87530BN6PR03MB2708namp_-- From nobody Thu Feb 23 10:17:45 2017 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 0BBB4129AB0 for ; Thu, 23 Feb 2017 10:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 j0gGJneV1j6n for ; Thu, 23 Feb 2017 10:17:43 -0800 (PST) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::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 DCB3A1295F3 for ; Thu, 23 Feb 2017 10:17:42 -0800 (PST) Received: by mail-wr0-x234.google.com with SMTP id s27so26969360wrb.2 for ; Thu, 23 Feb 2017 10:17:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=WEpXSex+18GfnnXcOCYPIiW+Pdgju5GW1YGo5VW8VpE=; b=YUIgR3yG598Szz51Nr8xa33OUCmH5Xr92Za0zMthYB6nHfFdzuEVSY/hAUNqR8Sy+g eoi3AR2iI5s53mh9p6r+HsFIlm4Yts1z0Rz81m4DOuiNkZLsGli0n4K2ILLlKXxk1fOG DlVWAlOUKkTb9sirXS4ZG/eSH9vbE+gdfQvRvWIPmz5tCGOuCXktvhr6g2C5duVU/H6e 06qu33mQ3JlMuyYzazrAddAGVkLw4SV4pmaU93mqniORKTXXqnbJNCRMcA3FmnSsBEYc Rw5jL6o3kUVl7uaSROeQwTCQkhNPQKGDvZ9FzVeDdbRLOKrjoYWWcRoBWrUu+rn6IARI J9Rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=WEpXSex+18GfnnXcOCYPIiW+Pdgju5GW1YGo5VW8VpE=; b=Zk8VyTG+ewprXaQhLwISL8Ak7RPAOP1c5x0LGFHFVQzv2Mz84pf+KWgsMLp7BphclK MEMqvy1pXzxRgagUOnme4viRnyKBx1XJYCbHFvXhGjsIrcQhUNnJf0iCsjcsHVQEnkHB Zt0Ash1S1dOwRNX6DSlPbsFjaoyryPt+fs49g1GfVLFbO/mcdS3dqW7a/7pm6hETnz9r LPN/AYQiY0O1DwDj7CYerpUDXqnOLYjuv68xpIlKpg+KD70FPs7G1EkHGk9X5qtyUUta LmhB1u15KMb6g2oqgadGeFcdcEyWIXGvAIqqMACH0m67IzDfF9lvfI+uejX7lJaVSuj6 AVTg== X-Gm-Message-State: AMke39l/4iOt7w27NlCNsIaTRKGrj3YIoY2fS1JAky0M4O1dHSBt+0+RuUHGbp74gLQX67KkvRLk2+2ybauYPg== X-Received: by 10.223.171.229 with SMTP id s92mr9797799wrc.64.1487873861119; Thu, 23 Feb 2017 10:17:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.164.18 with HTTP; Thu, 23 Feb 2017 10:17:40 -0800 (PST) From: Watson Ladd Date: Thu, 23 Feb 2017 10:17:40 -0800 Message-ID: Subject: Quick Elephants To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 18:17:44 -0000 Dear all, I'm not that familiar with the state of play here, but in the future we will have more and more LFN network connections (long fat pipe: high bandwidth-delay product with long delays), as well as wireless networks where packet losses are not necessarily due to contention on the shared channel. My understanding is currently we have a bunch of dirty hacks (like locally resending data over the lossy bit) to make this work, a lot of which will stop working with QUIC. What can we recommend for congestion control algorithms and multiplexing use to alleviate the problems? Sincerely, Watson From nobody Thu Feb 23 10:31:41 2017 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 62C04129A3E for ; Thu, 23 Feb 2017 10:31:40 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tNnYOvUcvbCR for ; Thu, 23 Feb 2017 10:31:39 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c: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 E45F61295F3 for ; Thu, 23 Feb 2017 10:31:38 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id x75so24912968vke.2 for ; Thu, 23 Feb 2017 10:31:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lKfVh9P04AMiXlSHnna8AusGy/vIQj+9nw2t+Zpnlms=; b=lmMxVQ+jTxo7sneKl4u3CEmDFRRkWdJcyuFeC+XT3Bf+s2EXgDmxcDYzxfLeLU6tPq eLU8SU3vWTO2PfH+d6JQdiIW42iYPPThe2hxK0/mChI1p75ewOqqyQkkhJ7xV+mie++W LUK1nO7m9MlWa3iBsxTzLswOKcutS33aGCIqbQC0MjMQ3w01Zwr8UE+eFWTmVpljE/iL ik5hA38kfteaCKW7Q9pESz8sf2TyJkpBj1juVTU7lW4qJET1O2wlpToW9ZUHJoUPSDGS yZ5Lar/g9GM5+ORXwU69j3ADBKBqF5Mx5T1CQk/NgD7Pft0L/aWmCVYK/mmSf2ILzgz3 kz/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lKfVh9P04AMiXlSHnna8AusGy/vIQj+9nw2t+Zpnlms=; b=dbww/gmC1pMGd+3JnRxNboSd+Cv2LsQZ768F0SGA0S8josIQ36KIP2bG1bze1PmKOt iw1zfguI8rMfNAkDcG+MmtJsz9kaStMm+200aGX3W1J+a92TqSpNqV7PCR+UIix8ccli eCyOvdhbGPZLy1CfqHN37DouVFdv97nol/7YL43biJo4SQAoI7JOEVj37T01IcV7tpM8 LlxaSVW+aRzU2k50R+RWAM8Dk+TTzaVACfI5nCgvDMNaBdRqa3nZLNyQ28zc0r+Te8/K SaMdfPMdDcZdCTV+t+1lBGhPT7+wx8F+tB52LXju/i1tIGNDwx2/1vw7Omv9l0x1tQWv hEvw== X-Gm-Message-State: AMke39lcNai8kRkXsM7fkO8VC9Z5GXDVnQnyaa3ofFB5sf2DJckGowt6pFS6K/ZgshyPMkeXhuXMlOKC1j9oRbrA X-Received: by 10.31.51.68 with SMTP id z65mr19216210vkz.40.1487874697653; Thu, 23 Feb 2017 10:31:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 23 Feb 2017 10:31:37 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 23 Feb 2017 10:31:37 -0800 Message-ID: Subject: Re: Quick Elephants To: Watson Ladd Content-Type: multipart/alternative; boundary=001a1144a44ed3814e054936d24b Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 18:31:40 -0000 --001a1144a44ed3814e054936d24b Content-Type: text/plain; charset=UTF-8 Hi Watson, The current plan is to write up NewReno as the congestion controller for QUIC. I don't think we need to make special recommendations for networks with large BDPs in terms of congestion control, since QUIC can use the same congestion controller as TCP for these networks. Specifically, if you have dirty hacks that you use to make TCP (with NewReno or Cubic) work, you ought to be able to do the same trickery with QUIC. (I can't think of new multiplexing recommendations for these networks.) - jana On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd wrote: > Dear all, > > I'm not that familiar with the state of play here, but in the future > we will have more and more LFN network connections (long fat pipe: > high bandwidth-delay product with long delays), as well as wireless > networks where packet losses are not necessarily due to contention on > the shared channel. > > My understanding is currently we have a bunch of dirty hacks (like > locally resending data over the lossy bit) to make this work, a lot of > which will stop working with QUIC. What can we recommend for > congestion control algorithms and multiplexing use to alleviate the > problems? > > Sincerely, > Watson > > --001a1144a44ed3814e054936d24b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Watson,

The current plan is to write= up NewReno as the congestion controller for QUIC. I don't think we nee= d to make special recommendations for networks with large BDPs in terms of = congestion control, since QUIC can use the same congestion controller as TC= P for these networks. Specifically, if you have dirty hacks that you use to= make TCP (with NewReno or Cubic) work, you ought to be able to do the same= trickery with QUIC.

(I can't think of new mul= tiplexing recommendations for these networks.)

- j= ana

On= Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
Dear all,

I'm not that familiar with the state of play here, but in the future we will have more and more LFN network connections (long fat pipe:
high bandwidth-delay product with long delays), as well as wireless
networks where packet losses are not necessarily due to contention on
the shared channel.

My understanding is currently we have a bunch of dirty hacks (like
locally resending data over the lossy bit) to make this work, a lot of
which will stop working with QUIC.=C2=A0 What can we recommend for
congestion control algorithms and multiplexing use to alleviate the
problems?

Sincerely,
Watson


--001a1144a44ed3814e054936d24b-- From nobody Thu Feb 23 10:41:31 2017 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 6305A129849 for ; Thu, 23 Feb 2017 10:41:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 w6vc8jNChJMg for ; Thu, 23 Feb 2017 10:41:29 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (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 CBEB6129690 for ; Thu, 23 Feb 2017 10:41:28 -0800 (PST) Received: from [192.168.178.20] ([93.217.75.127]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M7kwW-1cTzmO2E2i-00vQld; Thu, 23 Feb 2017 19:41:24 +0100 Subject: Re: QUIC should be designed for HTTP-Next, not HTTP/2 To: Phillip Hallam-Baker , IETF QUIC WG References: From: Julian Reschke Message-ID: <409a06de-1fff-c6c2-eb97-e625ae990a3a@gmx.de> Date: Thu, 23 Feb 2017 19:41:24 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K0:lzcn9YwT5gIEVL1q/XF8y8uTS8VJFfC3JNEdYfdx2BmEysI5IS1 tter9YGZSGIzK1ok7cTFKIGTz5FwBdE1GQNFaMkE0EYk3wK2GDEiM+D6XbGGZKkf0Fk/kK6 5jMaHJ++z642dX+6r8Q589j1sxaSTFXfoCYUBFLUjrRVHtwc3fBf/9E3FdB7eijd60PqW4R 66n+EL5NEVBfX6n1q1lTQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:JdHyB7rdZOg=:pf7103RdL+gU0ZTaSQjXiF WHlnZeBK+mDOgAL7WpXHLBLhCuMyAR5xLpW/80jM+lYlHEPYZNmdKPVsXIVFjjB6n1ugqMdft VKxSV2k03MyZ6DBEBUpn6p5fdENkT7iOQnvdr47+aBMTZHKZsm4gnmCfno9dwxumQxcLRDmwR Cf5P3cbQrgzUxs+j8t+01SMx2sMVvocZ0zOLR6PER9rIepoWbVhIlM7Fn8aLGFj6uFMrVG+GW cyGoDo6ZKTHT9h/6hPrDW5Hi31kXJhdIVLptA0SBHUVnn2aCjVV5BjDLKMvI/SC4e3HJQOe0N ZGP2KObfHGpyOWguwpyFQ9+v4+wqEODgh7T/lyLr82oOre2gm8Ec8efwTaN5tWahubKiZy2hQ 9lVVmWEKCvKxZbE+MRifS/2J/pP7hymR7xIta1jK4Nl+oHTqp0DBI66N4TC3i6lPjQ+1pm7T+ sx85hfqCVnBpflcofbuY8EfAQe0orfSyxDuy8UymazJzaygQxA40uLx03Xua7FJwdAMYCsV7E mSYPTLuwsDvEnLPNLxgR9zMvVCaB63oygwn0FJ6KSMrGK057qWDtMTDbmQ2tD/rgtA2zYILDc WE2es9H7xCzO7JY/rFe8CqsqCE6B6ZZ4WrK/QWtcILUXjOJPGMlXpbFTfAqnbP4fkG4rVsDKo BFcR/Bqg9uPiDimMoNCm8n7zkYLPfFkJNF+BOEhvuBcnAmZcNN4FcGARFVxF+LfDw6caefgIR jQrSWHPK+7h9uoYCLXkxkNDLUrRyb69/Q8euWMwExVDE40aofOZtKWCG1RdmxDIjeq3rkbgcG jOIawjn Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 18:41:30 -0000 To state the obvious: then it would need to be defined in the HTTP WG... On 2017-02-23 18:20, Phillip Hallam-Baker wrote: > ... > First off, content negotiation is not going to change across requests. A > browser is not going to learn to interpret a new image format between > one request and another for the same page. Or not often enough to bother. > > So I had assumed we would be using some form of scheme where we push the > content negotiation headers at the start of a connection and amortize > them across multiple requests. > ... That's what HPACK already does in HTTP/2, no? > ... Best regards, Julian From nobody Thu Feb 23 11:38:19 2017 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 CE1B612996D for ; Thu, 23 Feb 2017 11:38:17 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 NEz78Ho4wJ85 for ; Thu, 23 Feb 2017 11:38:16 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DBEA129A47 for ; Thu, 23 Feb 2017 11:38:15 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id r141so8581309wmg.1 for ; Thu, 23 Feb 2017 11:38:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lrmlCnEfe7r09LtoA1DFrTXYljKEK2BLzH/L8GoExwU=; b=o6o9ALEy+0+LitndbPt9M/SHA/F/Efh/1zK1DNhfoYUT+k1dpTWHogyHIF2oDFrMIt orpDbi+lXUBYr0iCR4SF/yFgpuqij2d0hJrESWnfX/ylfg+bgQimpSqD4ZxGcVqD4aqw BL9gdkVPbhLpDKjzZ0iT/Q3Qu+CLa0TUrOLqqgPCkVfQ4m/64b/z9Pm/wOwZRgjaKval XpHisS8DEAwWBeZEPChc5CR7QoMivFauZLaUEGfe4ux/YNa3PtVOJ4aZPDZVcPUjbDaS 2Cm9+Of4yptRmNuiUbR/wAfZKk3EbuOJtuWwLVDtktX74Fv90BR9VgFMKOu89Sw8hapq QI2A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lrmlCnEfe7r09LtoA1DFrTXYljKEK2BLzH/L8GoExwU=; b=oeZsHfPnCgvOoWLOMpLvVqMIPGp79RrEhzVWFO11E6a/s1wKNYEWwoLF0j4BBQh/f4 TeZVn1Svr7cITZfGEc4+Q9l2Hzk5MUd5Ya0U0Nza6cmO+pLNzzR9/Zj3TMcWARt7gqvA Stl8d2K0N/lhyjHq0ULorPvzbYz5O+Exwp+8ajYno/Fp6CNgfTf0+d/h2s5EkTrwjM3C 3Ne67HfbJZ2mSmQqB+sFXmUAjuKoiRl0IXlwHsJSn4qpAemKvhHPSqHFWtpg0+3K4dwh pL5LNWBr9p+9p4ak4AjYXoBfKp9/rgpeQB96UEUwPTm0F9fvL57wFqMPQKWBNWpau/El BjWQ== X-Gm-Message-State: AMke39m6nCCQ9cbjMf1eq0I7C+cbUiNcUGZsdtm0VQF6AIsEbyUmwKCkZosabaUTGZ4Ktx2YhBPqg5FVVM+dpsZt X-Received: by 10.28.38.2 with SMTP id m2mr6400086wmm.44.1487878693636; Thu, 23 Feb 2017 11:38:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Thu, 23 Feb 2017 11:38:12 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 23 Feb 2017 11:38:12 -0800 Message-ID: Subject: Re: Error handling and Public Reset To: Eric Rescorla Content-Type: multipart/alternative; boundary=94eb2c03fb960130b9054937c1f9 Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:38:18 -0000 --94eb2c03fb960130b9054937c1f9 Content-Type: text/plain; charset=UTF-8 My preference would be that valid public reset packet should only be able to be generated by endpoints, for exactly the reasons you lay out in PR#20. On Thu, Feb 23, 2017 at 4:48 AM, Eric Rescorla wrote: > There's been a fair amount of discussion on this PR, but it seems like > we first need to resolve the high level design issue of who can send a > public reset. Specifically: > > - Off-path elements > - On-path elements which are not endpoints > - Endpoints > > I think we agree that off-path elements should not be able to send > acceptable public resets, but disagree about whether on-path elements > which are not endpoints should be able to do so and if so whether they > should be distinguishable from those sent by endpoints. As I indicated > in PR#20 and the subsequent discussion, I don't think it's ideal for > on-path elements to be able to send public resets because this leads > to easy Great Firewall "man-on-the-side" type attacks, and it is > possible to design a public reset mechanism in which the endpoints can > have minimal persistent state and yet generate public resets that > cannot be forged. If we add such a mechanism we can also, if we like, > add one that allows on-path elements to generate public resets, but > because these are weaker, they should be distinguishable so that > endpoints can reject them. > > I recognize that there isn't consensus on this view -- at least no > declared consensus -- though I don't believe that the contrary view > has consensus either, but I think we need to resolve this before > dealing with PR#335. > > -Ekr > > > On Wed, Feb 22, 2017 at 4:29 PM, Martin Thomson > wrote: > >> I've put together a PR (hehe) that attempts to close on the discussion >> we've had about public reset. I've expanded it to include more >> details on error handling. This includes discussion on what to do >> with connection close. >> >> I have not added anything about what to do with undelivered data. >> That will follow once the current discussion concludes. >> >> https://github.com/quicwg/base-drafts/pull/335 >> >> > --94eb2c03fb960130b9054937c1f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
My preference would be that valid public reset packet shou= ld only be able to be generated by endpoints, for exactly the reasons you l= ay out in PR#20.

On Thu, Feb 23, 2017 at 4:48 AM, Eric Rescorla <<= a href=3D"mailto:ekr@rtfm.com" target=3D"_blank" class=3D"cremed">ekr@rtfm.= com> wrote:
There's been a fair amount of discussion on this PR, but it= seems like
we first need to resolve the high level design issue = of who can send a
public reset. Specifically:

- Off-path elements
- On-path elements which are not endpoi= nts
- Endpoints

I think we agree that of= f-path elements should not be able to send
acceptable public rese= ts, but disagree about whether on-path elements
which are not end= points should be able to do so and if so whether they
should be d= istinguishable from those sent by endpoints. As I indicated
in PR= #20 and the subsequent discussion, I don't think it's ideal for
on-path elements to be able to send public resets because this leads=
to easy Great Firewall "man-on-the-side" type attacks,= and it is
possible to design a public reset mechanism in which t= he endpoints can
have minimal persistent state and yet generate p= ublic resets that
cannot be forged. If we add such a mechanism we= can also, if we like,
add one that allows on-path elements to ge= nerate public resets, but
because these are weaker, they should b= e distinguishable so that
endpoints can reject them.
I recognize that there isn't consensus on this view -= - at least no
declared consensus -- though I don't believe th= at the contrary view
has consensus either, but I think we need to= resolve this before
dealing with PR#335.

-Ekr


On Wed,= Feb 22, 2017 at 4:29 PM, Martin Thomson <martin.t= homson@gmail.com> wrote:
I&= #39;ve put together a PR (hehe) that attempts to close on the discussion we've had about public reset.=C2=A0 I've expanded it to include mor= e
details on error handling.=C2=A0 This includes discussion on what to do
with connection close.

I have not added anything about what to do with undelivered data.
That will follow once the current discussion concludes.

https://github.com/quicwg/base-d= rafts/pull/335



--94eb2c03fb960130b9054937c1f9-- From nobody Thu Feb 23 11:38:50 2017 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 8C353129A5C for ; Thu, 23 Feb 2017 11:38:47 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 d4M0phOIU7RN for ; Thu, 23 Feb 2017 11:38:46 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C38BF12A272 for ; Thu, 23 Feb 2017 11:38:45 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id v186so181567229wmd.0 for ; Thu, 23 Feb 2017 11:38:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eEre3FNCjQ7gw8hoNgZ6dYhUu2VMuI8wBLj+M5RsGXo=; b=D3TbC7D+fM82hGldExsy+sw4P0Aw6zl1hl4YGPPt5AvJBlOLHiQDKeRccHre4xFc7a /cJ6LHrOfoy8Ek5TCYdfuTFSUD2NoWpV588kh6Jp/c0h8P0H47tHerdsq5kwhH7AVhmR zMGow5UlXSGB3JoPNiaklP73pfT7qn4TZgnqDRhxTdpMMq11MDC9y2R788tPqSC1un8U my0I+l9jBEuHau7r4Cc7+YmAPjQHfJA+oORcjWrG0tXmgdneOb9G7/J5ckQcpNgm8Au+ GuYQDhfRW56EIvwCFmLSfHgJw0PSB9XpxZ5ViH/7MS/jZeDluFddhx507CDS5tHqpYrd dStw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eEre3FNCjQ7gw8hoNgZ6dYhUu2VMuI8wBLj+M5RsGXo=; b=UrbLuTXR1bUF35XLVVz1+AEWY2pXyfipukv3Fads6xgZ5Nqupj46pS2k4Hx5GjwheO mhz+yzyJby9jPJuy+1pbQKAMXNV/BuekEK8dbUuddVtUg0D6wyscMHBiZj9fcQMBLfp3 nRmKXgHCSAlr3Y31CxipNWk3kYZSQEfqzmYHbWu0pgiQFph2kIFBfhJ8UJgaKmbqSzT2 hchVAJeVtducTCCfYzuD0BsqaYsYoZOdKWSLBe4agQ4EFnZJZ5+HjsqsvAsnm7YPIVeQ L6dpTpUgt1qusc0k2fc30iMIeof6XrqOLiCWG9gm3JIV0tWqqMYOVm1yMVmu4kQEFI29 hlWg== X-Gm-Message-State: AMke39lpoMmpYBZYVil4OFAQTJ1QPA/P4SGO4It37M9Gn46yJO7W/FkBiJVJLI0WDKauuzgdsIvFksV/4UzGz+aS X-Received: by 10.28.199.135 with SMTP id x129mr4024151wmf.21.1487878724268; Thu, 23 Feb 2017 11:38:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Thu, 23 Feb 2017 11:38:43 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Thu, 23 Feb 2017 11:38:43 -0800 Message-ID: Subject: Re: Packet protection and ACK To: Ian Swett Content-Type: multipart/alternative; boundary=94eb2c0d3f6ed48621054937c230 Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:38:47 -0000 --94eb2c0d3f6ed48621054937c230 Content-Type: text/plain; charset=UTF-8 +1! This definitely seems like the right approach to me. On Thu, Feb 23, 2017 at 5:42 AM, Ian Swett wrote: > I think this is definitely the right thing to do. I'm not sure if it's a > change, or just specifying correct behavior in a case we'd only recently > started thinking about in more detail. > > Thanks for the PR. > > On Wed, Feb 22, 2017 at 11:14 PM, Martin Thomson > wrote: > >> Issue 34 has a discussion about what rules we need around the use of >> packet protection and ACK frames. >> >> I've opened https://github.com/quicwg/base-drafts/pull/336 in the >> hopes that I can close the issue by capturing the conclusion there. >> >> In short, ACK can't include acknowledgments for packets that have more >> protection than the packet that the ACK sits in. This is a little >> tricky during the handshake, but the rules aren't that complex. >> >> This might be a technical change (I'm not 100% sure, but I think that >> it's at least consistent with practice), so I thought that I'd run >> this by the list. Feel free to object. >> >> > --94eb2c0d3f6ed48621054937c230 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1! This definitely seems like the right approach to me.

On Thu,= Feb 23, 2017 at 5:42 AM, Ian Swett <ianswett@google.com> = wrote:
I think this is d= efinitely the right thing to do.=C2=A0 I'm not sure if it's a chang= e, or just specifying correct behavior in a case we'd only recently sta= rted thinking about in more detail.

Thanks for the PR.

On Wed, Feb 22, 2017 at 11:14 PM, Martin T= homson <martin.thomson@gmail.com> wrote:
Issue 34 has a discussion about what rules we need ar= ound the use of
packet protection and ACK frames.

I've opened https://github.com/quicwg/base-dr= afts/pull/336 in the
hopes that I can close the issue by capturing the conclusion there.

In short, ACK can't include acknowledgments for packets that have more<= br> protection than the packet that the ACK sits in.=C2=A0 This is a little
tricky during the handshake, but the rules aren't that complex.

This might be a technical change (I'm not 100% sure, but I think that it's at least consistent with practice), so I thought that I'd run<= br> this by the list.=C2=A0 Feel free to object.



--94eb2c0d3f6ed48621054937c230-- From nobody Thu Feb 23 11:48:11 2017 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 C0272129A1F for ; Thu, 23 Feb 2017 11:48:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 mG9FFnxnsqZv for ; Thu, 23 Feb 2017 11:48:07 -0800 (PST) Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 2AF3E129A6C for ; Thu, 23 Feb 2017 11:48:07 -0800 (PST) Received: by mail-ua0-x229.google.com with SMTP id g30so810788uac.3 for ; Thu, 23 Feb 2017 11:48:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BmjZo+VAzCkV45G+ZzFPZCNn9QAofUYwaVb/3QjzqZg=; b=fX6rVrub911MEHayDHv+uxX1Uj2a1kdRMi9SEPoGv8hsGu1v0NJ+Yvo3MrQ1A5Vkcv IIcDQLIHMJ1610gFCTQgoUWstaWxWNI31kq5sKAftYcneg01n7cAa64oAvRcfpXlHl8V nVOxd7BfSVu3ec1VXptlA7111Ua9h4Izv0baOfISAaY6r+eMerQ2uuvKBAbCCndNcPNB Qdvw0WKl1+Q1suTX4KMqN7jULsmeJEwp1mkB1JmaS+APbYuhec/bUkP6Oh8HYC82VmcV Ygi8uco7eUeZ2n3I8GgQwzyo/y5Sla4yw7VveXnwPnpH501q5zAlT3liPSyTMZ4smQHM tUtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BmjZo+VAzCkV45G+ZzFPZCNn9QAofUYwaVb/3QjzqZg=; b=HqcbSDXDtNCtf3LpSgFsxjZHgG0RcPnmmqQqZj/m4ywZeJshwMItXoLXZEQpvcVlyq b71e0UOJWpjQ/I4pJBoPDEz5HimIc3ZoArJwJjS4rhUNwgdMXTohWHdAY4389+r6b4i1 4vYrpEqgxpaBmUfnfJ00c2ympfWI82m39xFpQj1KYuAOqKPdGQ99F38WjRlXK1U/G/oc hJqE8cf5GvpOgqF5GLm2lGXZNRAMBcJJhq8Cd1LhLNuAtKJLT4CVzGaclnjb28O+tolP l4EX/h08f6z8+LTV55i8iCXoAN3loiNbQwznEesgk76/J/35jaSVoaRkhGCRWmu416Sf L69w== X-Gm-Message-State: AMke39lC2KE81sFK1laRF14qZAAM+CCDccbSWgBnVUiaCVPfCU17ILASrfrdJcDwefEBCGCGrcgfbt4sa34Xli4C X-Received: by 10.159.54.205 with SMTP id p71mr16514442uap.61.1487879285931; Thu, 23 Feb 2017 11:48:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 23 Feb 2017 11:48:05 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 23 Feb 2017 11:48:05 -0800 Message-ID: Subject: Re: Error handling and Public Reset To: Ryan Hamilton Content-Type: multipart/alternative; boundary=94eb2c03d92a4f1973054937e400 Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:48:10 -0000 --94eb2c03d92a4f1973054937e400 Content-Type: text/plain; charset=UTF-8 As I mentioned on the PR, I'm not in favor of specifying middlebox use of public reset. That said, without PR#20, I don't understand how a client would know the difference between an on-path middlebox and an endpoint sending a PR. Neither has keys for the connection and both will be able to see the same parts of the packet. I agree that we need to resolve PR#20 before getting to PR#335. On Thu, Feb 23, 2017 at 11:38 AM, Ryan Hamilton wrote: > My preference would be that valid public reset packet should only be able > to be generated by endpoints, for exactly the reasons you lay out in PR#20. > > On Thu, Feb 23, 2017 at 4:48 AM, Eric Rescorla wrote: > >> There's been a fair amount of discussion on this PR, but it seems like >> we first need to resolve the high level design issue of who can send a >> public reset. Specifically: >> >> - Off-path elements >> - On-path elements which are not endpoints >> - Endpoints >> >> I think we agree that off-path elements should not be able to send >> acceptable public resets, but disagree about whether on-path elements >> which are not endpoints should be able to do so and if so whether they >> should be distinguishable from those sent by endpoints. As I indicated >> in PR#20 and the subsequent discussion, I don't think it's ideal for >> on-path elements to be able to send public resets because this leads >> to easy Great Firewall "man-on-the-side" type attacks, and it is >> possible to design a public reset mechanism in which the endpoints can >> have minimal persistent state and yet generate public resets that >> cannot be forged. If we add such a mechanism we can also, if we like, >> add one that allows on-path elements to generate public resets, but >> because these are weaker, they should be distinguishable so that >> endpoints can reject them. >> >> I recognize that there isn't consensus on this view -- at least no >> declared consensus -- though I don't believe that the contrary view >> has consensus either, but I think we need to resolve this before >> dealing with PR#335. >> >> -Ekr >> >> >> On Wed, Feb 22, 2017 at 4:29 PM, Martin Thomson > > wrote: >> >>> I've put together a PR (hehe) that attempts to close on the discussion >>> we've had about public reset. I've expanded it to include more >>> details on error handling. This includes discussion on what to do >>> with connection close. >>> >>> I have not added anything about what to do with undelivered data. >>> That will follow once the current discussion concludes. >>> >>> https://github.com/quicwg/base-drafts/pull/335 >>> >>> >> > --94eb2c03d92a4f1973054937e400 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As I mentioned on the PR, I'm not in favor of specifyi= ng middlebox use of public reset.

That said, without PR#= 20, I don't understand how a client would know the difference between a= n on-path middlebox and an endpoint sending a PR. Neither has keys for the = connection and both will be able to see the same parts of the packet. I agr= ee that we need to resolve PR#20 before getting to PR#335.



On Thu, Feb 23, 2017 at 11:38 AM, Ryan Hamilton &= lt;rch@google.com&g= t; wrote:
My pref= erence would be that valid public reset packet should only be able to be ge= nerated by endpoints, for exactly the reasons you lay out in PR#20.

On Thu, Feb 23, 2017 at 4:48 AM, Eric Rescorla <ekr@rtfm.com> wrote:
There's been a fair amount of discussi= on on this PR, but it seems like
we first need to resolve the hig= h level design issue of who can send a
public reset. Specifically= :

- Off-path elements
- On-path elements= which are not endpoints
- Endpoints

I t= hink we agree that off-path elements should not be able to send
a= cceptable public resets, but disagree about whether on-path elements
<= div>which are not endpoints should be able to do so and if so whether they<= /div>
should be distinguishable from those sent by endpoints. As I indi= cated
in PR#20 and the subsequent discussion, I don't think i= t's ideal for
on-path elements to be able to send public rese= ts because this leads
to easy Great Firewall "man-on-the-sid= e" type attacks, and it is
possible to design a public reset= mechanism in which the endpoints can
have minimal persistent sta= te and yet generate public resets that
cannot be forged. If we ad= d such a mechanism we can also, if we like,
add one that allows o= n-path elements to generate public resets, but
because these are = weaker, they should be distinguishable so that
endpoints can reje= ct them.

I recognize that there isn't con= sensus on this view -- at least no
declared consensus -- though I= don't believe that the contrary view
has consensus either, b= ut I think we need to resolve this before
dealing with PR#335.

-Ekr


On Wed, Feb 22, 201= 7 at 4:29 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I've put together a PR (hehe) that attempts to close on the disc= ussion
we've had about public reset.=C2=A0 I've expanded it to include mor= e
details on error handling.=C2=A0 This includes discussion on what to do
with connection close.

I have not added anything about what to do with undelivered data.
That will follow once the current discussion concludes.

https://github.c= om/quicwg/base-drafts/pull/335




--94eb2c03d92a4f1973054937e400-- From nobody Thu Feb 23 11:55:49 2017 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 E91C01296D3 for ; Thu, 23 Feb 2017 11:55:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 KzIPwGm-XoZa for ; Thu, 23 Feb 2017 11:55:46 -0800 (PST) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38EB71294F0 for ; Thu, 23 Feb 2017 11:55:46 -0800 (PST) Received: by mail-yb0-x232.google.com with SMTP id i66so415995yba.1 for ; Thu, 23 Feb 2017 11:55:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LX9gVEwgXGh02AmAcGmuVbJRQlTkCT3hBZ4m7uybNGs=; b=HW/M6OrdxrOWNeDY5aUIlqX6um/PAPMQg5YlRrvFPxA8R6Ppz33tVdCdBSMIk6yRjc Bruv6JpguNh2qSnpDnlfLbbeDiXjqh6X0xD6tulpzLC5/6y8+38yCwbBwAETKeA9Z/tp IXP3KR3mHBWiRYru9NlPz6GbqlYnoIxozKQoatAbLBDbskNzN1z3GQLz0flbE/rfNAbS Z7VhXBbxqDBMXqnnH2Vkiqnrw1+jN4r6wTx6o3/7q9l1eSp9BfELx4Y0Cr8gZm4gw6fc 8VCJFJy6Zo1oIXb0X/o7cJpXeRfvZ842UCFHEn4Bz351a29jUhu34sP530clln7kY08q 5Vzg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LX9gVEwgXGh02AmAcGmuVbJRQlTkCT3hBZ4m7uybNGs=; b=DE66511/B6vpqCmVmAo2E5c8oF2TILzzpku1GgiP77e+JwlCkwPMBWODDcKr5D3683 Tz2cXTHj3dNR3pkdal02PCxzf5m8Bx5FDp0KUUlfKqMc9thGeJ2ZhLPZl1NBg1PS0EwZ asCmoHF6Q7P2qywzCxQFx20gX09WioqX3zMtMt2ws8dTHWgDUDlfP8p9CF73rjnOuAb6 x0OuJZ5Gi7MoMt4Nv3YwGMoPAbqmMSAJdxwR9AaKwhBeBf2XeDlAdS9hp1uL4nGpKolo 1TADbigkaYMnpmKViGL9aEBb8XzOXt6ltUCvdbhmv932oSY2iVZugUWlUgOzbTVljz47 CNGQ== X-Gm-Message-State: AMke39lmcZxXoMmuUEF+XmTjDtMxLmLKMru9Ll5NaDCs1KOS3yts7UGGhkBtVnuc6zFuX34y+sva4S4WrldiBnpT X-Received: by 10.37.118.13 with SMTP id r13mr27034994ybc.66.1487879745013; Thu, 23 Feb 2017 11:55:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.50.139 with HTTP; Thu, 23 Feb 2017 11:55:24 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 23 Feb 2017 14:55:24 -0500 Message-ID: Subject: Re: Error handling and Public Reset To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a114bd6d6abf8fc054937ffeb Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 19:55:48 -0000 --001a114bd6d6abf8fc054937ffeb Content-Type: text/plain; charset=UTF-8 I agree with EKR's proposal and would like all public resets to be only sent by endpoints and verifiable. If we did allow on-path, non-endpoints to send public resets, they should be easy to distinguish from those of endpoints, but at this point, I've heard no clear argument for why these are necessary, so I don't see a need to specify them. On Thu, Feb 23, 2017 at 2:48 PM, Jana Iyengar wrote: > As I mentioned on the PR, I'm not in favor of specifying middlebox use of > public reset. > > That said, without PR#20, I don't understand how a client would know the > difference between an on-path middlebox and an endpoint sending a PR. > Neither has keys for the connection and both will be able to see the same > parts of the packet. I agree that we need to resolve PR#20 before getting > to PR#335. > > > > On Thu, Feb 23, 2017 at 11:38 AM, Ryan Hamilton wrote: > >> My preference would be that valid public reset packet should only be able >> to be generated by endpoints, for exactly the reasons you lay out in PR#20. >> >> On Thu, Feb 23, 2017 at 4:48 AM, Eric Rescorla wrote: >> >>> There's been a fair amount of discussion on this PR, but it seems like >>> we first need to resolve the high level design issue of who can send a >>> public reset. Specifically: >>> >>> - Off-path elements >>> - On-path elements which are not endpoints >>> - Endpoints >>> >>> I think we agree that off-path elements should not be able to send >>> acceptable public resets, but disagree about whether on-path elements >>> which are not endpoints should be able to do so and if so whether they >>> should be distinguishable from those sent by endpoints. As I indicated >>> in PR#20 and the subsequent discussion, I don't think it's ideal for >>> on-path elements to be able to send public resets because this leads >>> to easy Great Firewall "man-on-the-side" type attacks, and it is >>> possible to design a public reset mechanism in which the endpoints can >>> have minimal persistent state and yet generate public resets that >>> cannot be forged. If we add such a mechanism we can also, if we like, >>> add one that allows on-path elements to generate public resets, but >>> because these are weaker, they should be distinguishable so that >>> endpoints can reject them. >>> >>> I recognize that there isn't consensus on this view -- at least no >>> declared consensus -- though I don't believe that the contrary view >>> has consensus either, but I think we need to resolve this before >>> dealing with PR#335. >>> >>> -Ekr >>> >>> >>> On Wed, Feb 22, 2017 at 4:29 PM, Martin Thomson < >>> martin.thomson@gmail.com> wrote: >>> >>>> I've put together a PR (hehe) that attempts to close on the discussion >>>> we've had about public reset. I've expanded it to include more >>>> details on error handling. This includes discussion on what to do >>>> with connection close. >>>> >>>> I have not added anything about what to do with undelivered data. >>>> That will follow once the current discussion concludes. >>>> >>>> https://github.com/quicwg/base-drafts/pull/335 >>>> >>>> >>> >> > --001a114bd6d6abf8fc054937ffeb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I agree with EKR's proposal and would like all public = resets to be only sent by endpoints and verifiable.

If w= e did allow on-path, non-endpoints to send public resets, they should be ea= sy to distinguish from those of endpoints, but at this point, I've hear= d no clear argument for why these are necessary, so I don't see a need = to specify them.

On Thu, Feb 23, 2017 at 2:48 PM, Jana Iyengar = <jri@google.com&= gt; wrote:
As I m= entioned on the PR, I'm not in favor of specifying middlebox use of pub= lic reset.

That said, without PR#20, I don't underst= and how a client would know the difference between an on-path middlebox and= an endpoint sending a PR. Neither has keys for the connection and both wil= l be able to see the same parts of the packet. I agree that we need to reso= lve PR#20 before getting to PR#335.



On Thu, Feb 23, 2017 at 11:38 AM, Ryan Hamilton <rch= @google.com> wrote:
My preference would be that valid public reset packet should only= be able to be generated by endpoints, for exactly the reasons you lay out = in PR#20.

On Thu, Feb 23, 2017 at 4:48 AM,= Eric Rescorla <ek= r@rtfm.com> wrote:
There's been a fair amount of discussion on this PR,= but it seems like
we first need to resolve the high level design= issue of who can send a
public reset. Specifically:
- Off-path elements
- On-path elements which are not= endpoints
- Endpoints

I think we agree = that off-path elements should not be able to send
acceptable publ= ic resets, but disagree about whether on-path elements
which are = not endpoints should be able to do so and if so whether they
shou= ld be distinguishable from those sent by endpoints. As I indicated
in PR#20 and the subsequent discussion, I don't think it's ideal = for
on-path elements to be able to send public resets because thi= s leads
to easy Great Firewall "man-on-the-side" type a= ttacks, and it is
possible to design a public reset mechanism in = which the endpoints can
have minimal persistent state and yet gen= erate public resets that
cannot be forged. If we add such a mecha= nism we can also, if we like,
add one that allows on-path element= s to generate public resets, but
because these are weaker, they s= hould be distinguishable so that
endpoints can reject them.
=

I recognize that there isn't consensus on this= view -- at least no
declared consensus -- though I don't bel= ieve that the contrary view
has consensus either, but I think we = need to resolve this before
dealing with PR#335.
=
-Ekr


On Wed, Feb 22, 2017 at 4:29 PM, Martin Thomson <martin.thomson@gmail.c= om> wrote:
I've put tog= ether a PR (hehe) that attempts to close on the discussion
we've had about public reset.=C2=A0 I've expanded it to include mor= e
details on error handling.=C2=A0 This includes discussion on what to do
with connection close.

I have not added anything about what to do with undelivered data.
That will follow once the current discussion concludes.

https://github.com/quicwg/base-drafts/pull/335





--001a114bd6d6abf8fc054937ffeb-- From nobody Thu Feb 23 12:14:36 2017 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 04E43129A8B for ; Thu, 23 Feb 2017 12:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 nqph_mveXp4S for ; Thu, 23 Feb 2017 12:14:33 -0800 (PST) Received: from mail-yb0-x235.google.com (mail-yb0-x235.google.com [IPv6:2607:f8b0:4002: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 E8E06129A7E for ; Thu, 23 Feb 2017 12:14:32 -0800 (PST) Received: by mail-yb0-x235.google.com with SMTP id d88so556396ybi.0 for ; Thu, 23 Feb 2017 12:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=w1+rzX453TzlbWSz1gatGH/uvNZKgHuC+o+YTOyK1OM=; b=ALukfuFyOMGRamQJs0Xn0Ex34THpUpdKIzFJhMmciAomj5nbMrX/HT/VDHSQC+/LH7 mGHETWu8F4I0ONZ5WFkfzygPSRac7qPn/1lsdx+X6Va40bkP1NmaP2Lve58LUnM1hltt UgylVz4+NU6DnOFf4wM8C8svNvNmWA2WIlJl65rT4LyMc+RkSW4UAKQdVHlc29J8lnDJ CejbMd7JJmOl26KxHPe4BnbG1AadZ9bt3iVcEKijOAEGL876usZBnkVDnO+SQX6onj0V aWgLJe0+9wsFn52I9TqFmntkd5MP+HSgjJ/QvROxcIRr7pibz71Y+ANwnR8oCAPKxye5 nmzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=w1+rzX453TzlbWSz1gatGH/uvNZKgHuC+o+YTOyK1OM=; b=DtKJCYDAV3gmGGPiDS+3iaHorS9qPU3xfGpwX+QI7ugobKfd970b2JyVpXTSAnA61l evtR1F97kszYX+0XPFHXNum2vYLfJWWt0apkhPDbf8q6J8K0v6Hi4xVpC4un4QFydVfG awNEh1w4FnJCuEfdf91REiOLkytgYE0huALEyO4WjA2vpGQWP7A0UlLLKoUWwax3Ud+z +YxTadSPa2TURdgIwf7qFXdbdHrF2eZi4prHdNV6VEuGtg6DtwrjRjglYxeyjv41yFKB z69q3XbH6tt2T9Yyornmesh1y2SOLFTLR8QmEFr9E4ayjm+tKZcVw2RMFJyTKjVUEej9 uB8w== X-Gm-Message-State: AMke39nJX6NFbNBIAfTRJ0yKOxFJlOnb+oUt0jIRX/AmtrAxUax2qjL6OHNVcaqWVuwa/VGh1d/Cbzq5pXwymQ== X-Received: by 10.37.201.196 with SMTP id z187mr29766322ybf.161.1487880872127; Thu, 23 Feb 2017 12:14:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Thu, 23 Feb 2017 12:13:51 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Thu, 23 Feb 2017 12:13:51 -0800 Message-ID: Subject: Re: Error handling and Public Reset To: Jana Iyengar Content-Type: multipart/alternative; boundary=001a114d88eada07f00549384282 Archived-At: Cc: IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 20:14:35 -0000 --001a114d88eada07f00549384282 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 23, 2017 at 11:48 AM, Jana Iyengar wrote: > As I mentioned on the PR, I'm not in favor of specifying middlebox use of > public reset. > > That said, without PR#20, I don't understand how a client would know the > difference between an on-path middlebox and an endpoint sending a PR. > Neither has keys for the connection and both will be able to see the same > parts of the packet. I agree that we need to resolve PR#20 before getting > to PR#335. > Yes, I think that's the right conclusion. I do think we can land your header patch with a [TODO] in this slot because it's a self-contained issue. -Ekr > > > On Thu, Feb 23, 2017 at 11:38 AM, Ryan Hamilton wrote: > >> My preference would be that valid public reset packet should only be able >> to be generated by endpoints, for exactly the reasons you lay out in PR#20. >> >> On Thu, Feb 23, 2017 at 4:48 AM, Eric Rescorla wrote: >> >>> There's been a fair amount of discussion on this PR, but it seems like >>> we first need to resolve the high level design issue of who can send a >>> public reset. Specifically: >>> >>> - Off-path elements >>> - On-path elements which are not endpoints >>> - Endpoints >>> >>> I think we agree that off-path elements should not be able to send >>> acceptable public resets, but disagree about whether on-path elements >>> which are not endpoints should be able to do so and if so whether they >>> should be distinguishable from those sent by endpoints. As I indicated >>> in PR#20 and the subsequent discussion, I don't think it's ideal for >>> on-path elements to be able to send public resets because this leads >>> to easy Great Firewall "man-on-the-side" type attacks, and it is >>> possible to design a public reset mechanism in which the endpoints can >>> have minimal persistent state and yet generate public resets that >>> cannot be forged. If we add such a mechanism we can also, if we like, >>> add one that allows on-path elements to generate public resets, but >>> because these are weaker, they should be distinguishable so that >>> endpoints can reject them. >>> >>> I recognize that there isn't consensus on this view -- at least no >>> declared consensus -- though I don't believe that the contrary view >>> has consensus either, but I think we need to resolve this before >>> dealing with PR#335. >>> >>> -Ekr >>> >>> >>> On Wed, Feb 22, 2017 at 4:29 PM, Martin Thomson < >>> martin.thomson@gmail.com> wrote: >>> >>>> I've put together a PR (hehe) that attempts to close on the discussion >>>> we've had about public reset. I've expanded it to include more >>>> details on error handling. This includes discussion on what to do >>>> with connection close. >>>> >>>> I have not added anything about what to do with undelivered data. >>>> That will follow once the current discussion concludes. >>>> >>>> https://github.com/quicwg/base-drafts/pull/335 >>>> >>>> >>> >> > --001a114d88eada07f00549384282 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Thu, Feb 23, 2017 at 11:48 AM, Jana Iyengar <jri@google.com>= wrote:
As I mentioned o= n the PR, I'm not in favor of specifying middlebox use of public reset.=

That said, without PR#20, I don't understand how a = client would know the difference between an on-path middlebox and an endpoi= nt sending a PR. Neither has keys for the connection and both will be able = to see the same parts of the packet. I agree that we need to resolve PR#20 = before getting to PR#335.

Yes, = I think that's the right conclusion. I do think we can land your header= patch with a
[TODO] in this slot because it's a self-contain= ed issue.

-Ekr



<= /div>
On Thu, Feb 23, 2017 at 11:38 AM, Ryan Hamilton= <= rch@google.com> wrote:
My preferen= ce would be that valid public reset packet should only be able to be genera= ted by endpoints, for exactly the reasons you lay out in PR#20.
<= div class=3D"m_1072903825262229679h5">

On Thu, Feb 23, 2017 at 4:48 AM, Eric Rescorla <ekr@rtfm.com> wrote:
There= 's been a fair amount of discussion on this PR, but it seems like
=
we first need to resolve the high level design issue of who can send a=
public reset. Specifically:

- Off-path = elements
- On-path elements which are not endpoints
- E= ndpoints

I think we agree that off-path elements s= hould not be able to send
acceptable public resets, but disagree = about whether on-path elements
which are not endpoints should be = able to do so and if so whether they
should be distinguishable fr= om those sent by endpoints. As I indicated
in PR#20 and the subse= quent discussion, I don't think it's ideal for
on-path el= ements to be able to send public resets because this leads
to eas= y Great Firewall "man-on-the-side" type attacks, and it is
<= div>possible to design a public reset mechanism in which the endpoints can<= /div>
have minimal persistent state and yet generate public resets that=
cannot be forged. If we add such a mechanism we can also, if we = like,
add one that allows on-path elements to generate public res= ets, but
because these are weaker, they should be distinguishable= so that
endpoints can reject them.

I recognize that there isn't consensus on this view -- at least no
declared consensus -- though I don't believe that the contrary v= iew
has consensus either, but I think we need to resolve this bef= ore
dealing with PR#335.

-Ekr


On Wed, Feb 22,= 2017 at 4:29 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I've put together a PR (hehe) that atte= mpts to close on the discussion
we've had about public reset.=C2=A0 I've expanded it to include mor= e
details on error handling.=C2=A0 This includes discussion on what to do
with connection close.

I have not added anything about what to do with undelivered data.
That will follow once the current discussion concludes.

https://github.com/quicwg/base-drafts/pull/335





--001a114d88eada07f00549384282-- From nobody Thu Feb 23 12:15:32 2017 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 E0AEF129A8B for ; Thu, 23 Feb 2017 12:15:31 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 xDVmP8YK80Dq for ; Thu, 23 Feb 2017 12:15:29 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c: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 60E54129853 for ; Thu, 23 Feb 2017 12:15:29 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id t8so1160749vke.3 for ; Thu, 23 Feb 2017 12:15:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rZhK69/oN2gcQwOhB6kM0KgjkHcjzUjQ8RypFHTlOtM=; b=KjW7QPDHW/uQu2jlszwJIGpehV5lr3xH6yjz3AC+eGMnhRst23b5SAmMLXWhKCeCPN Kdn8u5TeKM3Tz94L6OaRFjaxFI9TObWt/d5kkHewN+VPVe+99vobD9eZddpMrziVV6Hq epfOyoHlxE/EMOfFJ8l7m6Ko8dC5pqS+lj/c/BlMzrQTkl76l3vMQzWa49lthH3eTVKR KJJs0emzeYl7LaeZFSJqNiV7OiDY3EF3Y3UhRI0oh8CaPxi1oGTvFj/QrQC/5GUomH4q MA6P4DiF6RxJp29pUJdbMxNfS8rvow9YMGwzXItWVZYa91qNUw6tWoO1Vh/rf5a0xSJs BcwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rZhK69/oN2gcQwOhB6kM0KgjkHcjzUjQ8RypFHTlOtM=; b=tKZ9qeu/WiztP1rlfGCjhHmafL5kzoNz8gLfmt6u+hD7r/T2xTsRRRXrutK1jMIajV qKcBxBQRseUEJ5pfzNd6tPn9svKwos5JOi7AqbHVW3hLjJWhLwW87/DZlX0GEOYkXDXa Vv6Qu3uHYlHN+/9va0z8G7iLkDvt6T38ihEYzJTz0ap8bbGhw1iEw8J6P++JYv6jceK4 fVCnDBIg2nHynQhjzbkyRbcFAmfhWzmZCAbT7i1HTicf25KqaE0XmqwgBq3orGp9dDY7 3dBYVnPERRvfkprmUGo4xzN8GppiPBLqrtwuivqw1wa+U6lOmh1MNIi902CU4mGnGTVL h7fQ== X-Gm-Message-State: AMke39myfFsvE8gTwiG8KJ7wsG6X3KNZQALfzOC+i1+qC4k17SU4mAKe2vG9lmUpF/1N0tfJwGiaKCLBXdps/Bsm X-Received: by 10.31.51.68 with SMTP id z65mr19465613vkz.40.1487880928082; Thu, 23 Feb 2017 12:15:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 23 Feb 2017 12:15:27 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 23 Feb 2017 12:15:27 -0800 Message-ID: Subject: Re: Error handling and Public Reset To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a1144a44e304da90549384661 Archived-At: Cc: IETF QUIC WG , Martin Thomson , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 20:15:32 -0000 --001a1144a44e304da90549384661 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 23, 2017 at 12:13 PM, Eric Rescorla wrote: > > On Thu, Feb 23, 2017 at 11:48 AM, Jana Iyengar wrote: > >> As I mentioned on the PR, I'm not in favor of specifying middlebox use of >> public reset. >> >> That said, without PR#20, I don't understand how a client would know the >> difference between an on-path middlebox and an endpoint sending a PR. >> Neither has keys for the connection and both will be able to see the same >> parts of the packet. I agree that we need to resolve PR#20 before getting >> to PR#335. >> > > Yes, I think that's the right conclusion. I do think we can land your > header patch with a > [TODO] in this slot because it's a self-contained issue. > Agreed. (I'll get a PR for the header proposal soon.) > -Ekr > > >> >> >> On Thu, Feb 23, 2017 at 11:38 AM, Ryan Hamilton wrote: >> >>> My preference would be that valid public reset packet should only be >>> able to be generated by endpoints, for exactly the reasons you lay out in >>> PR#20. >>> >>> On Thu, Feb 23, 2017 at 4:48 AM, Eric Rescorla wrote: >>> >>>> There's been a fair amount of discussion on this PR, but it seems like >>>> we first need to resolve the high level design issue of who can send a >>>> public reset. Specifically: >>>> >>>> - Off-path elements >>>> - On-path elements which are not endpoints >>>> - Endpoints >>>> >>>> I think we agree that off-path elements should not be able to send >>>> acceptable public resets, but disagree about whether on-path elements >>>> which are not endpoints should be able to do so and if so whether they >>>> should be distinguishable from those sent by endpoints. As I indicated >>>> in PR#20 and the subsequent discussion, I don't think it's ideal for >>>> on-path elements to be able to send public resets because this leads >>>> to easy Great Firewall "man-on-the-side" type attacks, and it is >>>> possible to design a public reset mechanism in which the endpoints can >>>> have minimal persistent state and yet generate public resets that >>>> cannot be forged. If we add such a mechanism we can also, if we like, >>>> add one that allows on-path elements to generate public resets, but >>>> because these are weaker, they should be distinguishable so that >>>> endpoints can reject them. >>>> >>>> I recognize that there isn't consensus on this view -- at least no >>>> declared consensus -- though I don't believe that the contrary view >>>> has consensus either, but I think we need to resolve this before >>>> dealing with PR#335. >>>> >>>> -Ekr >>>> >>>> >>>> On Wed, Feb 22, 2017 at 4:29 PM, Martin Thomson < >>>> martin.thomson@gmail.com> wrote: >>>> >>>>> I've put together a PR (hehe) that attempts to close on the discussion >>>>> we've had about public reset. I've expanded it to include more >>>>> details on error handling. This includes discussion on what to do >>>>> with connection close. >>>>> >>>>> I have not added anything about what to do with undelivered data. >>>>> That will follow once the current discussion concludes. >>>>> >>>>> https://github.com/quicwg/base-drafts/pull/335 >>>>> >>>>> >>>> >>> >> > --001a1144a44e304da90549384661 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 23, 2017 at 12:13 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:

On Thu, Feb 23, 2017 = at 11:48 AM, Jana Iyengar <jri@google.com> wrote:
As I mentioned on the PR, I'm not= in favor of specifying middlebox use of public reset.

T= hat said, without PR#20, I don't understand how a client would know the= difference between an on-path middlebox and an endpoint sending a PR. Neit= her has keys for the connection and both will be able to see the same parts= of the packet. I agree that we need to resolve PR#20 before getting to PR#= 335.

Yes, I think that&#= 39;s the right conclusion. I do think we can land your header patch with a<= /div>
[TODO] in this slot because it's a self-contained issue.

Agreed. (I'll get a= PR for the header proposal soon.)
=C2=A0
-Ekr




= On Thu, Feb 23, 2017 at 11:38 AM, Ryan Hamilton <rch@google.com> wrote:
My preference would be that valid publi= c reset packet should only be able to be generated by endpoints, for exactl= y the reasons you lay out in PR#20.

On Thu, Feb 23, 2017 at 4:48 AM, Eric Rescorla <ekr@rt= fm.com> wrote:
There's been a fair amount of discussion on this PR, but= it seems like
we first need to resolve the high level design iss= ue of who can send a
public reset. Specifically:

- Off-path elements
- On-path elements which are not end= points
- Endpoints

I think we agree that= off-path elements should not be able to send
acceptable public r= esets, but disagree about whether on-path elements
which are not = endpoints should be able to do so and if so whether they
should b= e distinguishable from those sent by endpoints. As I indicated
in= PR#20 and the subsequent discussion, I don't think it's ideal for<= /div>
on-path elements to be able to send public resets because this le= ads
to easy Great Firewall "man-on-the-side" type attac= ks, and it is
possible to design a public reset mechanism in whic= h the endpoints can
have minimal persistent state and yet generat= e public resets that
cannot be forged. If we add such a mechanism= we can also, if we like,
add one that allows on-path elements to= generate public resets, but
because these are weaker, they shoul= d be distinguishable so that
endpoints can reject them.

I recognize that there isn't consensus on this vie= w -- at least no
declared consensus -- though I don't believe= that the contrary view
has consensus either, but I think we need= to resolve this before
dealing with PR#335.

=
-Ekr


On Wed, Feb 22, 2017 at 4:= 29 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I've put together a PR (hehe= ) that attempts to close on the discussion
we've had about public reset.=C2=A0 I've expanded it to include mor= e
details on error handling.=C2=A0 This includes discussion on what to do
with connection close.

I have not added anything about what to do with undelivered data.
That will follow once the current discussion concludes.

https://github.com/quicwg/base-drafts/pull/= 335






--001a1144a44e304da90549384661-- From nobody Thu Feb 23 13:42:38 2017 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 9C5361296D5 for ; Thu, 23 Feb 2017 13:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no 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 1IuheOeKUzF8 for ; Thu, 23 Feb 2017 13:42:34 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86CC212940A for ; Thu, 23 Feb 2017 13:42:34 -0800 (PST) Received: from mail-ot0-f180.google.com (mail-ot0-f180.google.com [74.125.82.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 72A8E29C01E for ; Fri, 24 Feb 2017 06:42:31 +0900 (JST) Received: by mail-ot0-f180.google.com with SMTP id x10so2990723otb.1 for ; Thu, 23 Feb 2017 13:42:31 -0800 (PST) X-Gm-Message-State: AMke39lKiZG6LDCMAxCsuxcGah9M1sTB2SPwQHq++LXCsPkbmSik7mgQ9wvtDlSjD8cCBGvE3lSLFwKmkQs46Q== X-Received: by 10.157.82.85 with SMTP id q21mr8664158otg.161.1487886150224; Thu, 23 Feb 2017 13:42:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.145 with HTTP; Thu, 23 Feb 2017 13:42:29 -0800 (PST) In-Reply-To: References: From: Yoshifumi Nishida Date: Thu, 23 Feb 2017 13:42:29 -0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Quick Elephants To: Jana Iyengar Content-Type: multipart/alternative; boundary=f403043c3a68735fe10549397d95 Archived-At: Cc: Watson Ladd , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 21:42:36 -0000 --f403043c3a68735fe10549397d95 Content-Type: text/plain; charset=UTF-8 I also think we don't need to make special recommendations. But, if the dirty hacks include transparent PEPs, I guess it will be difficult to do with QUIC. -- Yoshi On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar wrote: > Hi Watson, > > The current plan is to write up NewReno as the congestion controller for > QUIC. I don't think we need to make special recommendations for networks > with large BDPs in terms of congestion control, since QUIC can use the same > congestion controller as TCP for these networks. Specifically, if you have > dirty hacks that you use to make TCP (with NewReno or Cubic) work, you > ought to be able to do the same trickery with QUIC. > > (I can't think of new multiplexing recommendations for these networks.) > > - jana > > On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd > wrote: > >> Dear all, >> >> I'm not that familiar with the state of play here, but in the future >> we will have more and more LFN network connections (long fat pipe: >> high bandwidth-delay product with long delays), as well as wireless >> networks where packet losses are not necessarily due to contention on >> the shared channel. >> >> My understanding is currently we have a bunch of dirty hacks (like >> locally resending data over the lossy bit) to make this work, a lot of >> which will stop working with QUIC. What can we recommend for >> congestion control algorithms and multiplexing use to alleviate the >> problems? >> >> Sincerely, >> Watson >> >> > --f403043c3a68735fe10549397d95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I also think we don't need to make special recomm= endations. But, if the dirty hacks include transparent PEPs, I guess it wil= l be difficult to do with QUIC.
--
Yoshi

On Thu, Feb 23, 2017= at 10:31 AM, Jana Iyengar <jri@google.com> wrote:
Hi Watson,

The cu= rrent plan is to write up NewReno as the congestion controller for QUIC. I = don't think we need to make special recommendations for networks with l= arge BDPs in terms of congestion control, since QUIC can use the same conge= stion controller as TCP for these networks. Specifically, if you have dirty= hacks that you use to make TCP (with NewReno or Cubic) work, you ought to = be able to do the same trickery with QUIC.

(I can&= #39;t think of new multiplexing recommendations for these networks.)
<= span class=3D"HOEnZb">

- jana

On Thu, Feb 23, 2017 at 10:= 17 AM, Watson Ladd <watsonbladd@gmail.com> wrote:
Dear all,

I'm not that familiar with the state of play here, but in the future we will have more and more LFN network connections (long fat pipe:
high bandwidth-delay product with long delays), as well as wireless
networks where packet losses are not necessarily due to contention on
the shared channel.

My understanding is currently we have a bunch of dirty hacks (like
locally resending data over the lossy bit) to make this work, a lot of
which will stop working with QUIC.=C2=A0 What can we recommend for
congestion control algorithms and multiplexing use to alleviate the
problems?

Sincerely,
Watson



--f403043c3a68735fe10549397d95-- From nobody Thu Feb 23 14:03:38 2017 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 015D5129AB3 for ; Thu, 23 Feb 2017 14:03:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.596 X-Spam-Level: X-Spam-Status: No, score=-2.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeSz41yL5ISH for ; Thu, 23 Feb 2017 14:03:34 -0800 (PST) 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 E8D4C129B4F for ; Thu, 23 Feb 2017 14:03:18 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id l19so2273698ywc.2 for ; Thu, 23 Feb 2017 14:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=g56WquHnCaF0VZmC0XENsP0ev3kYd3msDTu3wOwJt6A=; b=sMqBh82fuulogbS+86lSeZdD8JNhTJSdny9fz5b+xkkj57+e9iSicQcCI0aYodFKJn KG5W8Fpz1zD2DDjuDHlm5NOddre3fyLTiftNSbNPXDeTj73HVqv0KepLW0exAybSwneW g/q/pgNQMGcPU81e9VHt2WSccvfclLyI4SkAkcfrluGnhhYDOgTGlerLY3ECJQA97IRc fZvLO2uEU9RtPNuYmPEcI0tD8vwc6cnI+b3KG1sadvcuOzQCFah3P8+imXYp0cqpmXGZ F2vYApZo8duiSSl3yn+u1c25YgXCZ29b0RZI4Ql3pbegBvJD/0aYQzP9QUCRxGNBKn9j DReQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=g56WquHnCaF0VZmC0XENsP0ev3kYd3msDTu3wOwJt6A=; b=rG4hJBKayyoBLNismvdF+fghzrbpCILJLCQw2enZqWMYnn6+2CuLfVGXtN7Q3cIUm7 BCwdxfzNimBZXs1HPhkJvBFdaYdFKHOuQzRP7UbD04DnZCGZFqjm2LKT2uZMqOdyAbID Bl9Ji+eskQ77iEw6ypsDM9nCoMW9bSFR1DLenlzzo0aARPC91hq0ub2dyRlJpUA78Akh PjbBpu4VJx+vz1sypUY4+pqtBOj+PvhMmc6pWjh4cYByTzvxuUNNYVHms1s8k5B5wdU4 Hc3KxNG8RlZG68W7OEEGqgX+IfvZaR9N/Yp+WiJklcMm0me7VvOmVn2d5oqfGWI2Q38Z c12g== X-Gm-Message-State: AMke39nksJ23QPYdGyI1q7pGMy1GbPJ3Ip4Tm74RGN5Q/AhlSg8N5kxZaexxw1DWm8Iun/utLTybgReMRfY04Q== X-Received: by 10.129.121.19 with SMTP id u19mr29082659ywc.237.1487887398165; Thu, 23 Feb 2017 14:03:18 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.17.140 with HTTP; Thu, 23 Feb 2017 14:03:17 -0800 (PST) In-Reply-To: <409a06de-1fff-c6c2-eb97-e625ae990a3a@gmx.de> References: <409a06de-1fff-c6c2-eb97-e625ae990a3a@gmx.de> From: Phillip Hallam-Baker Date: Thu, 23 Feb 2017 17:03:17 -0500 X-Google-Sender-Auth: -P380jon7E7OYFgXuEun99Q-Mhw Message-ID: Subject: Re: QUIC should be designed for HTTP-Next, not HTTP/2 To: Julian Reschke Content-Type: multipart/alternative; boundary=94eb2c0a7160d56473054939c7b7 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 22:03:36 -0000 --94eb2c0a7160d56473054939c7b7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2017 at 1:41 PM, Julian Reschke wrote: > To state the obvious: then it would need to be defined in the HTTP WG... > =E2=80=8BUmmm no. That is the very last place I would want to discuss it.= =E2=80=8B =E2=80=8BThis would not be HTTP/3, it would be a complete discontinuity. It certainly isn't something to start building in QUIC either. But the way I look at it, QUIC is similar to a subway system for a city. When you are building a subway you don't just build it for the city as it is today, you build it for what you expect it to grow into. The easy part of QUIC is going to be building the protocol itself. The part that always ends up being hard is how to move from the legacy base to the new system efficiently in a way that does not foreclose future growth.=E2= =80=8B > On 2017-02-23 18:20, Phillip Hallam-Baker wrote: > >> ... >> First off, content negotiation is not going to change across requests. A >> browser is not going to learn to interpret a new image format between >> one request and another for the same page. Or not often enough to bother= . >> >> So I had assumed we would be using some form of scheme where we push the >> content negotiation headers at the start of a connection and amortize >> them across multiple requests. >> ... >> > > That's what HPACK already does in HTTP/2, no? > =E2=80=8BLike I said, that is the scheme I th=E2=80=8Bought we would be the= end point but I now see it as merely a waypoint to something else. --94eb2c0a7160d56473054939c7b7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On = Thu, Feb 23, 2017 at 1:41 PM, Julian Reschke <julian.reschke@gmx.de> wrote:
To state the obvious: then it would= need to be defined in the HTTP WG...


=E2=80=8BThis= would not be HTTP/3, it would be a complete discontinuity.=C2=A0

It certainly isn't something t= o start building in QUIC either. But the way I look at it, QUIC is similar = to a subway system for a city. When you are building a subway you don't= just build it for the city as it is today, you build it for what you expec= t it to grow into.

The ea= sy part of QUIC is going to be building the protocol itself. The part that = always ends up being hard is how to move from the legacy base to the new sy= stem efficiently in a way that does not foreclose future growth.=E2=80=8B

=C2=A0
...
First off, content negotiation is not going to change across requests. A browser is not going to learn to interpret a new image format between
one request and another for the same page. Or not often enough to bother.
So I had assumed we would be using some form of scheme where we push the content negotiation headers at the start of a connection and amortize
them across multiple requests.
 ...

That's what HPACK already does in HTTP/2, no?

=
=E2=80=8B= Like I said, that is the scheme I th=E2=80=8Bought we would be the end poin= t but I now see it as merely a waypoint to something else.

<= div>=C2=A0
--94eb2c0a7160d56473054939c7b7-- From nobody Thu Feb 23 15:27:54 2017 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 BC2DE129C38 for ; Thu, 23 Feb 2017 15:27:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gXzAzOIOqWak for ; Thu, 23 Feb 2017 15:27:50 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 9CA6A129C3C for ; Thu, 23 Feb 2017 15:27:40 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id w44so4473408otw.2 for ; Thu, 23 Feb 2017 15:27:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=JUBLnEe8xOQH5niMpyCfDslus8OK6etrnFP/hsXFu1U=; b=pUQH454PV8XnoNC0q+QkCxR06UH2GErRbH6KR6qzvh7/x+LhbhiVe2uUovsfiEY4py 4YM0vyE4y6Vdf0QA3/nDDwuztcn2WD0m04dUXikBjVHkvArxZWfWghTnfD9QLGJlL3AR AZoPogo4i13wrrHSJ5wvXo3iRDwYx4YCunvZuC3S0uNiimypOaPHSepMEnuuEXrRL/GD 7c9PkVfV67KMaN0bwibWMS8MFu75zjvCkzcgrzQHRn6QnEIhIWDQI9l2RsHaZIKuhAzl FpM37Dx61ThCdFkWvgAyeFk85V6ICb6SjjaeodQefs7nBRqUwIyMvHPkgdLw7qNwcAz1 ZVJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=JUBLnEe8xOQH5niMpyCfDslus8OK6etrnFP/hsXFu1U=; b=b79exO8ahAwqYTU6xZy2AHU8WvdDY6nc1t8hoSeRqQFKi6tEHHHi9rPqkMxorTNWkN XY5qd/lx7Mku0ycQfJd/IJMyyAsufMnWbI5VKND/q8Itohmmpl/WR9AIyiHxik33w2rU 3b+QCU6zXDirLtQ8PawgzqhJ4TE4/6dkL5RJvLnKJmWblOut8OLt+g/ClpoBA6mCe7+g zktJGEVlQL5dFGI3x1eWgyWnUgepxLdF0sBdLGQhYL8crnr4Hk8y5yf2R7cqL5JEMh7R v1FfN9M2eHASmQ/bNSrnXXe9kZ6y998FGuqcPGW/YGmxwaFyTTtPbge5CaAwodO9+4Vl 2TVA== X-Gm-Message-State: AMke39ntEICdxhzSLXuf7JOtijA62a+i82TNh/sgYRsELgL/DrL8NZ6LN6ISIGoHPQ5fGOtacFtI/NtcucTcmA== X-Received: by 10.157.14.10 with SMTP id c10mr6971794otc.13.1487892459883; Thu, 23 Feb 2017 15:27:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.226 with HTTP; Thu, 23 Feb 2017 15:27:39 -0800 (PST) From: Martin Duke Date: Thu, 23 Feb 2017 15:27:39 -0800 Message-ID: Subject: Clean shutdown semantics To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a113da04a8913de05493af5e7 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2017 23:27:52 -0000 --001a113da04a8913de05493af5e7 Content-Type: text/plain; charset=UTF-8 I am considering opening issue about clean shutdown semantics, but wanted to bounce it off the list first in case there is something obvious I am missing. In TCP, after a clean shutdown both endpoints have a reasonable assurance that (1) All data they sent was acknowledged, and (2) the peer was able to deliver all the data it wanted. This is a property of the connection FIN being a byte in a connection-wide, reliably delivered sequence space. I see two aspects of QUIC that result in this assurance not quite being achievable. This may be a result of editorial incompleteness, or something baked into what Google implemented. (1) GOAWAY is bidirectional. There is no way to say "I am done opening streams, but you can open more streams if you need to." I don't see a way to cleanly close the connection and know for sure that the peer didn't have more streams to open. (2) CONNECTION_CLOSE is ambiguous between abrupt and graceful shutdowns. There are some related logic issues too. (a) Say that I am endpoint A wrapping up a communication with endpoint B. We've already sent GOAWAY(s), and I send a packet that sends the last data and FIN for all remaining streams. (b) I then receive a similar packet from B, delivering some data and FINing all open streams, which I acknowledge. (c) I receive a packet only containing an ACK frame for packet (a). I now have assurance that all my data is delivered, and I have received everything B has for me. There is no ack to send because there is only an ACK frame. (d) I therefore send CONNECTION_CLOSE. But if the ack in (b) is lost, then endpoint B receives CONNECTION_CLOSE while data is still outstanding. I believe the spec, as written, says to treat this as an abrupt shutdown and throw the queued data on the floor. Furthermore, B is required to acknowledge the CONNECTION_CLOSE frame. Even if it were to keep the send queue after CONNECTION_CLOSE, the ack would probably go out first. So A can tear down its connection before B has any assurance that A got all its data. There are several minor protocol edits to avoid all the problems in this scenario. But I don't believe the spec as written is sufficient. Martin Duke --001a113da04a8913de05493af5e7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am considering opening issue about clean shutdown semant= ics, but wanted to bounce it off the list first in case there is something = obvious I am missing.

In TCP, after a clean shutdown bot= h endpoints have a reasonable assurance that (1) All data they sent was ack= nowledged, and (2) the peer was able to deliver all the data it wanted. Thi= s is a property of the connection FIN being a byte in a connection-wide, re= liably delivered sequence space.

I see two aspects= of QUIC that result in this assurance not quite being achievable. This may= be a result of editorial incompleteness, or something baked into what Goog= le implemented.

(1) GOAWAY is bidirectional. There= is no way to say "I am done opening streams, but you can open more st= reams if you need to." I don't see a way to cleanly close the conn= ection and know for sure that the peer didn't have more streams to open= .

(2) CONNECTION_CLOSE is ambiguous between abrupt= and graceful shutdowns. There are some related logic issues too.

(a) Say that I am endpoint A wrapping up a communication wi= th endpoint B. We've already sent GOAWAY(s), and I send a packet that s= ends the last data and FIN for all remaining streams.

<= div>(b) I then receive a similar packet from B, delivering some data and FI= Ning all open streams, which I acknowledge.

(c) I = receive a packet only containing an ACK frame for packet (a). I now have as= surance that all my data is delivered, and I have received everything B has= for me. There is no ack to send because there is only an ACK frame.
<= div>
(d) I therefore send CONNECTION_CLOSE.
 --001a11465b2201ba0605499d3809-- From nobody Tue Feb 28 13:15:13 2017 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 1009A12970F for ; Tue, 28 Feb 2017 13:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 Yw36eiqQFefj for ; Tue, 28 Feb 2017 13:15:10 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0126.outbound.protection.outlook.com [104.47.36.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51EA51296CD for ; Tue, 28 Feb 2017 13:15:10 -0800 (PST) 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=vqegGVuyQyn2b5hNLekdsW+MjtAWjUN1jhHlgWCSdBI=; b=d/UfCDiLWwrSnZ+VlvoghpgPSKWP4xc3PWymO+3oUNjikNEbKQk/OIdz+OpOj8jmyd8WUSTFu+StKRZWrLVltCyo1Zu8Fqk0WKDJCILiMByHA9e2zC6UhGEXhhnWXaOs1NeZaPZXMEW44mAiJ6btG+0oYZ+DXtaWAxwNVG5pDn0= Received: from CY4PR03MB2710.namprd03.prod.outlook.com (10.173.43.141) by CY4PR03MB2712.namprd03.prod.outlook.com (10.173.43.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Tue, 28 Feb 2017 21:15:06 +0000 Received: from CY4PR03MB2710.namprd03.prod.outlook.com ([10.173.43.141]) by CY4PR03MB2710.namprd03.prod.outlook.com ([10.173.43.141]) with mapi id 15.01.0933.019; Tue, 28 Feb 2017 21:15:06 +0000 From: Mike Bishop To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnTgidP6MC1E0yc8zksQ9LKAqF9m5CAgAAA8YCAALU8gIAATWEAgAAa8YCAABKLgIAABAbQgAAIvQCAABLRUA== Date: Tue, 28 Feb 2017 21:15:06 +0000 Message-ID: References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> In-Reply-To: <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: tik.ee.ethz.ch; dkim=none (message not signed) header.d=none;tik.ee.ethz.ch; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [131.107.147.117] x-ms-office365-filtering-correlation-id: 5144339f-72c6-4164-a86e-08d4601ede85 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR03MB2712; x-microsoft-exchange-diagnostics: 1; CY4PR03MB2712; 7:hMDG2nfkP4Gqs3CdHDqawYCPRZtpeDIKYuia6oJ64HYvhuKUiJtnUoHOLZphI9OVxZmMFEXHrVmnrZvmSVYgBU6vMdZtw7t3Z8zqm90FrNdfRCVGvd7LDCLS/bGHXGwxJeqE3vJOvFh8S4tckRGEumfiD9hkVknc7emmWDzw7hhdEMTKokKtG1EB3QRrukmO8zfuw6/mATSR5L0s+OtzISvdo4cj0DwgRgspPnzwHXVrOP/A+CHHTaB0ucpKeaaFnvo8xhO4UfuPowfhUJozpxgC7V/iinJn9LKCpWY6yAWY7iMrAGqoCOM1iY/SS+t5HZY3YV7WJtfFnnou8GjPMwOuNVkwP21C5LqfC0ZJmCk= 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:(158342451672863)(211936372134217)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY4PR03MB2712; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2712; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39450400003)(39850400002)(39410400002)(13464003)(377454003)(24454002)(86362001)(86612001)(7736002)(93886004)(8936002)(39060400002)(2900100001)(81166006)(3660700001)(66066001)(7696004)(10090500001)(77096006)(8676002)(54906002)(305945005)(55016002)(9686003)(10290500002)(5005710100001)(3280700002)(122556002)(99286003)(38730400002)(110136004)(6436002)(25786008)(8990500004)(102836003)(76176999)(189998001)(54356999)(33656002)(50986999)(6116002)(3846002)(6506006)(92566002)(229853002)(2950100002)(53546006)(561944003)(2906002)(106116001)(6916009)(6246003)(74316002)(53936002)(5660300001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2712; H:CY4PR03MB2710.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; 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: 28 Feb 2017 21:15:06.3017 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2712 Archived-At: Cc: Ted Hardie , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:15:12 -0000 SSBkb24ndCB0aGluayB0aGVyZSdzIGEgZGVzaXJlIHRvIGF2b2lkIGxpbmthYmlsaXR5IGJldHdl ZW4gdGhlIGNsaWVudCdzIHByb3Bvc2VkIGNvbm5lY3Rpb24gSUQgYW5kIHRoZSBjb25uZWN0aW9u IElEIGJlaW5nIHVzZWQgZm9yIHRoZSByZW1haW5kZXIgb2YgdGhlIGNvbm5lY3Rpb24gb24gdGhl IHNhbWUgcGF0aC4gIElmIHRoZXJlIGlzLCB0aGF0IGNoYW5nZXMgc29tZSB0aGluZ3MsIGJ1dCBJ J2QgYmUgY3VyaW91cyB0byBrbm93IHRoZSBtb3RpdmF0aW9uLg0KDQpJIGFncmVlIHRoYXQgd2Ug bWlnaHQgd2FudCB0byBhdm9pZCBsaW5rYWJpbGl0eSBiZXR3ZWVuIHRoZSBjb25uZWN0aW9uIElE IG9mIG9uZSBjb25uZWN0aW9uL3BhdGggYW5kIHRoZSBjb25uZWN0aW9uIElEIHRoZSBjbGllbnQg d2lsbCB1c2Ugb24gYSBkaWZmZXJlbnQgcGF0aC4NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IE1pcmphIEvDvGhsZXdpbmQgW21haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5l ZS5ldGh6LmNoXSANClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE3IDEyOjA2IFBNDQpU bzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpDYzogVGVkIEhh cmRpZSA8dGVkLmlldGZAZ21haWwuY29tPjsgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb20+ OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogV2hlbiBzaG91bGQg c2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElEcyBiZSBzZW50IGFuZCBob3cgYXJlIHRoZXkgaW5k aWNhdGVkPw0KDQpFdmVuIGlmIHRoZSBsb2FkIGJhbGFuY2VyIGNvdWxkIHNlZSB0aGUgdHJhZmZp YyBpbiB0aGUgb3RoZXIgZGlyZWN0aW9uLCB0aGUgbmV3IGNvbm5lY3Rpb24gaWRzIHNob3VsZCBu b3QgYmUgZXhwb3NlZCB0byB0aGUgcGF0aCAoYWthIHRoaXMgaW5mb3JtYXRpb24gbXVzdCBiZSBl bmNyeXB0ZWQpLCBvdGhlcndpc2UgaXTigJlzIHN0aWxsIGxpbmthYmxlLiANCg0KSWYgeW91IHdh bnQgdG8gYXZvaWQgYWRkaXRpb25hbCBzaWduYWxpbmcgKHdoaWNoIGNvdWxkIGJlIGRvbmUgaWYg dGhlIGxvYWQgYmFsYW5jZXIgYW5kIHRoZSBzZXJ2ZXIgaGF2ZSBzb21lIGtpbmQgb2YgdHJ1c3Qg cmVsYXRpb25zaGlwKSwgdGhlbiBib3RoIG5lZWQgdG8ga25vdyB0aGUgYWxnb3JpdGhtIHRoYXQg aXMgdXNlZCB0byBjcmVhdGUgdGhlIGFkZGl0aW9uYWwgaWRzLiBJZiB5b3UgZG9u4oCZdCBoYXZl IGFueSB0cnVzdCByZWxhdGlvbnNoaXAgKG5laXRoZXIgZm9yIHNpZ25hbGluZywgbm9yIGZvciBz b21lIGtpbmQgb2YgaW5pdGlhbCBjb25maWd1cmF0aW9uKSB0aGFuIHlvdSBhcmUgdGhlIGtpbmQg b2YgbWlkZGxlYm94IHRoYXQgd2UgZG9u4oCZdCB3YW50IHRvIGJlIGFibGUgdG8gbGluayBkaWZm ZXJlbnQgY29ubmVjdGlvbnMgdG9nZXRoZXIuDQoNCk1pcmphDQoNCg0KPiBBbSAyOC4wMi4yMDE3 IHVtIDIwOjQwIHNjaHJpZWIgTWlrZSBCaXNob3AgPG1pY2hhZWwuYmlzaG9wQG1pY3Jvc29mdC5j b20+Og0KPiANCj4gWWVzLCBidXQgdGhlIHByb2JsZW0gaXMgZGVhbGluZyB3aXRoIGEgc2l0dWF0 aW9uIHdoZXJlIHRoZSBsb2FkIGJhbGFuY2VyIGFuZCB0aGUgc2VydmVyIGFyZSBpbmRlcGVuZGVu dGx5IG1hbmFnZWQsIGFzIGluIGEgaG9zdGluZyBlbnZpcm9ubWVudC4gIFRoZXJlIHdvdWxkIG5l ZWQgdG8gYmUgc29tZXRoaW5nIHN0YW5kYXJkaXplZC4gIChPZiBjb3Vyc2UsIGlmIHRoZSBsb2Fk IGJhbGFuY2VyIGNhbiBiZSBzdGF0ZWZ1bCwgaXQgZG9lc27igJl0IG5lZWQgbmVhcmx5IGFzIG11 Y2ggb2YgdGhpcyBtYWNoaW5lcnkuKQ0KPiANCj4gDQo+IA0KPiBUaGUgb3RoZXIgaXNzdWUgdGhh dCB3YXMgcG9pbnRlZCBvdXQgdG8gbWUgYnkgb25lIG9mIG91ciBTTEIgZ3V5cyBpcyB0aGF0IHRo ZSBsb2FkIGJhbGFuY2VyIG9ubHkgc2VlcyBwYWNrZXRzIGluIHRoZSBjbGllbnQtdG8tc2VydmVy IGRpcmVjdGlvbiwgbm90IHRoZSBzZXJ2ZXLigJlzIHJlc3BvbnNlcy4gIFNvIGEgQ29ubmVjdGlv biBJRCBjaGFuZ2UgcHJvcG9zZWQgYnkgdGhlIHNlcnZlciBpcyBpbnZpc2libGUgdG8gdGhlIGxv YWQgYmFsYW5jZXIgdW50aWwgaXQgc2VlcyBhIGZ1dHVyZSBjbGllbnQgcGFja2V0IHdpdGggdGhl IHNhbWUgNC10dXBsZSBhbmQgYSBkaWZmZXJlbnQgY29ubmVjdGlvbiBJRC4gIEJ1dCBzaW1wbHkg YWxsb3dpbmcgcGFja2V0cyBmcm9tIHRoZSBzYW1lIHNvdXJjZSB3aXRoIGEgZGlmZmVyZW50IElE IHRvIGluZm9ybSB0aGUgbG9hZCBiYWxhbmNlciBvZiBhbiBJRCBjaGFuZ2Ugc2VlbXMgcmlwZSBm b3IgYXR0YWNrIGJ5IHNwb29maW5nIHRoZSBzb3VyY2Ug4oCTIHdl4oCZZCBuZWVkIHRvIHRpZ2h0 bHkgc2NvcGUgaG93IGEgbG9hZCBiYWxhbmNlciBjYW4gaWRlbnRpZnkgdGhhdCBzYWZlbHkuICBJ dCBhbHNvIG1lYW5zIHRoYXQgb3VyIGFncmVlbWVudCB0aGF0IGNsaWVudCBJUC9wb3J0IGNhbuKA mXQgY2hhbmdlIOKAnGR1cmluZyB0aGUgaGFuZHNoYWtl4oCdIGFjdHVhbGx5IGhhcyB0byBleHRl bmQgdW50aWwgdGhlIHNlcnZlciBoYXMgcmVjZWl2ZWQgcGFja2V0cyB3aXRoIHRoZSBuZXcgY29u bmVjdGlvbiBJRC4NCj4gDQo+IA0KPiANCj4gRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBIYXJkaWUNCj4gU2VudDogVHVlc2RheSwgRmVi cnVhcnkgMjgsIDIwMTcgMTE6MjAgQU0NCj4gVG86IFJ5YW4gSGFtaWx0b24gPHJjaEBnb29nbGUu Y29tPg0KPiBDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgTWlyamEgS8O8aGxld2lu ZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4NCj4gU3ViamVjdDogUmU6IFdoZW4g c2hvdWxkIHNlcnZlci1jaG9zZW4gY29ubmVjdGlvbiBJRHMgYmUgc2VudCBhbmQgaG93IGFyZSB0 aGV5IGluZGljYXRlZD8NCj4gDQo+IA0KPiANCj4gT24gVHVlLCBGZWIgMjgsIDIwMTcgYXQgMTA6 MTMgQU0sIFJ5YW4gSGFtaWx0b24gPHJjaEBnb29nbGUuY29tPiB3cm90ZToNCj4gDQo+IA0KPiAN Cj4gT24gVHVlLCBGZWIgMjgsIDIwMTcgYXQgODozNyBBTSwgVGVkIEhhcmRpZSA8dGVkLmlldGZA Z21haWwuY29tPiB3cm90ZToNCj4gDQo+IFRoZXJlIGFyZSB0d28gY2FzZXMgd2UgaGF2ZSB0byBj b25zaWRlcjogbGlua2FiaWxpdHkgZHVlIHRvIGEgY2hhbmdlIGluIHRoZSBuZXR3b3JrIG5vdCB2 aXNpYmxlIHRvIHRoZSBjbGllbnQgYW5kIGxpbmthYmlsaXR5IHRoYXQgb2NjdXJzIGJlY2F1c2Ug b2YgYSBjbGllbnQtaW5pdGlhdGVkIGNoYW5nZS4gIFlvdSdyZSBjb3JyZWN0IHRoYXQgaXQgY2Fu bm90IHVwZGF0ZSB0aGUgY29ubmVjdGlvbiBJRCB0byBhdm9pZCBsaW5rYWdlIHdoZW4gaXQgZG9l c24ndCBrbm93IG9mIHRoZSBjaGFuZ2UsIGJ1dCB3aGVuIHRoZSBjbGllbnQgaW5pdGlhdGVzIHRo ZSBjaGFuZ2UgKGUuZy4gbW92ZXMgZnJvbSBXaUZpIHRvIGNlbGx1bGFyKSwgaXQgY2VydGFpbmx5 IGNvdWxkLiAgSWYgdGhpcyBmZWF0dXJlIGlzIG9wdGlvbmFsLCB0aGVuIHlvdSBsaWtlbHkgZG8g aGF2ZSB0byBoYXZlIGEgY29uZmlndXJhdGlvbiBmcm9iIHRoYXQgdGhlIGNsaWVudCB1c2VzIHRv IHNheSAicmUtdXNlIG9mIGNvbm5lY3QgSURzIGlzIG9rYXkiIHZzLiAibm90IG9rYXksIHBsZWFz ZSB1c2UgMFJUVCB3aGVuIHRyYW5zaXRpb25zIG9jY3VyIGFuZCBvbmx5IG9uZSBjb25uZWN0aW9u IElEIGlzIGF2YWlsYWJsZSIuIA0KPiANCj4gUGVyc29uYWxseSwgSSdkIGJlIGhhcHB5IGlmIGl0 IHdlcmUgbm90IG9wdGlvbmFsLCBhbmQgSSB0aGluayB0aGUgcHJvdG9jb2wgdG8gc2hhcmUgb3V0 IGEgcG9vbCBvZiBjb25uZWN0aW9uIElEcyBmcm9tIGEgbG9hZCBiYWxhbmNlci9sb2FkIGJhbGFu Y2VyIGZhcm0gaXMgbm90IHRoYXQgY29tcGxpY2F0ZWQuIEl0J3Mgbm90IGluIGNoYXJ0ZXIgZm9y IFFVSUMsIGJ1dCBpZiB3ZSB3YW50ZWQgYSBwcm9wb3NhbCBmb3IgaXQsIEknbSBndWVzc2luZyB3 ZSBjb3VsZCBrbm9jayBzb21ldGhpbmcgdG9nZXRoZXIgYnkgdGhlIFBhcmlzIGludGVyaW0gYW5k IHRha2UgaXQgdG8gZGlzcGF0Y2ggaW4gUHJhZ3VlLg0KPiANCj4gDQo+IA0KPiDigItNeSBzZW5z ZSBpcyB0aGF0IHRoZSB3b3JraW5nIGdyb3VwIGJlbGlldmVzIHRoYXQgaXQgaXMgbm90IGFjY2Vw dGFibGUgZm9yIGEgY29ubmVjdGlvbiBJRCB0byBiZSByZXVzZWQgYWNyb3NzIGNsaWVudCBpbml0 aWF0ZWQgbmV0d29yayBjaGFuZ2VzIChXaUZpIHRvIENlbGx1bGFyKS4gSWYgdGhpcyBpcyBhY2N1 cmF0ZSwgdGhlbiBpZiBhIHNlcnZlciBkaWQgbm90IHByZXNlbnQgYW55IGFkZGl0aW9uYWwgY29u bmVjdGlvbiBJRHMgdG8gYSBjbGllbnQsIHRoZSBjbGllbnQgd291bGQgc2ltcGx5IHRlYXIgZG93 biB0aGUgY29ubmVjdGlvbiBpZiBpdCBjaGFuZ2VkIG5ldHdvcmtzLCBqdXN0IGFzIGlmIGl0IHdv dWxkIGRvIHRvIFRDUCBjb25uZWN0aW9ucy4gU28gd2UgY2FuIHN0aWxsIGhhdmUgdGhpcyAibGlz dCBvZiBjb25uZWN0aW9uIElEcyIgZmVhdHVyZSBiZWluZyBvcHRpb25hbCB3aXRob3V0IG5lZWRp bmcgdG8gZW1wb3dlciBjbGllbnRzIHRvIHVzZSB0aGUgY29ubmVjdGlvbiBJRCBhY3Jvc3MgbmV0 d29yayBjaGFuZ2VzLCByaWdodD8NCj4gDQo+IA0KPiANCj4gWWVzLCB0aGF0IHdvdWxkIGJlIHRo ZSBhbHRlcm5hdGUgc3RyYXRlZ3kuICBBdCB0aGF0IHBvaW50LCB0aGUgY2xpZW50IGlzIG5vdCBl eHBlY3RpbmcgdGhlIG5ldyBzZXJ2ZXIgdG8gaGF2ZSBzdGF0ZSwgc28gaXQgaXMgZXhwbGljaXRs eSBnaXZpbmcgdGhhdCB1cCB0byBhdm9pZCBsaW5rYWJpbGl0eS4NCj4gDQo+IA0KPiANCj4gSSdt IGFsc28gbm90IGNvbnZpbmNlZCB0aGF0IGl0IGlzICJub3QgY29tcGxpY2F0ZWQiIGZvciBhIHNl cnZlciB0byBiZSBpbiBwb3NzZXNzaW9uIG9mIGEgc2V0IG9mIGNvbm5lY3Rpb24gSURzIHRoYXQg d2lsbCBtYXAgYmFjayB0byBpdHNlbGYgaW4gc29tZSBkZXBsb3ltZW50cywgYnV0IEknZCBiZSBo YXBweSB0byBiZSB3cm9uZyENCj4gDQo+IA0KPiANCj4gV2VsbCwgdGhlcmUgYXJlIGNsZWFybHkg cHJvcHJpZXRhcnkgc29sdXRpb25zIGluIHRoaXMgc3BhY2UsIGFzIHdlbGwgYXMgZmFpcmx5IGJh c2ljIG1ldGhvZHMgb2YgcmFuZ2UgYXNzaWdubWVudCB3aXRoaW4gdGhlIGZ1bGwgcG9vbCB0aGF0 IHdvcmsgd2l0aCBhIHN0YW5kYXJkIGZhbi1vdXQgb2Ygc2VydmVycyBiZWhpbmQgYSBsb2FkIGJh bGFuY2VyLiAgVGhleSBtYXkgbm90IGNvdmVyIGFsbCBkZXBsb3ltZW50cywgb2YgY291cnNlLg0K PiANCj4gcmVnYXJkcywNCj4gDQo+IFRlZA0KPiANCj4gDQo+IA0KDQo= From nobody Tue Feb 28 13:57:26 2017 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 A92731293F8 for ; Tue, 28 Feb 2017 13:57:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfKFhLY03s2P for ; Tue, 28 Feb 2017 13:57:22 -0800 (PST) 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 61CEA12009C for ; Tue, 28 Feb 2017 13:57:22 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id m124so13130919oig.1 for ; Tue, 28 Feb 2017 13:57:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tkHifLWH9d27sgBLm2MnNidKrOA694PRwB2aWFMtIg4=; b=jTAOLf/ZjlgADipOm2sMQtGr3kj+gx1tQi7JFOeJk7kB0JEis1etf+I+ASM0T04YnL vF1kTF3iBVBVqeVCJdqueZwOfv9e5mJ7yP8QDXtSbIVmh6+LsWryWXifkn+x5NkECy3m YyIX6gc5IZIKIMZywmn2aqUjZH0xyXk5MECXVyXM+E/v+1SHSXoYDsoDtGJk0CbUxwOd J/P8Fwy6b9eMFSYxE73DC7ChqNXCG1DAzQYlIQdiDPYbSahabzZs5MF6LHwVHetgvtgF PzyA8cglQH2S6+xNm9LfpbfO6VmdyA3YUKFzuDxD/ISSgmmcZdGzmf4RjEoEgw49Rets Qb8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tkHifLWH9d27sgBLm2MnNidKrOA694PRwB2aWFMtIg4=; b=JQgr3Z1nkIi7/fODhGobQHStOe7bpyzXwIrRvnXEqcLBbO1dS5xd4pWPhwRWRPo3oJ nuBSEdtOJrfptjdfv9d9kuWioVfStUZ1iHsJaw7DjcOSbUhzEID92PVjfqsGKhSreAGu GdjJIsHZVgWWe8gmQa8IohZMal3vtknhmd85oc9XXQYAO7nyE8lXWqTY2cGQJ1HT5PBq V/R5h8N+r5gxz8gAp9vcduGYj69umG491Wsa18N8EH0k4N0Y4QPOoBLLhZrlotUoVtam kpOruf64aOh2cv+LpmJfkoDUbjwqLnUNzstmWVsRxvGUqQNGPfSZ9+vikXXFaNBQrbKX VnHA== X-Gm-Message-State: AMke39klRzkfG/owGaobwn3dc0p1yc+blUGvzMz5GrQW6ZIeinq9pREDQx4AQaAi0NoCV/2rslqcRN13mBWktA== X-Received: by 10.202.60.86 with SMTP id j83mr2138245oia.27.1488319041497; Tue, 28 Feb 2017 13:57:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.142.85 with HTTP; Tue, 28 Feb 2017 13:56:51 -0800 (PST) In-Reply-To: References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> From: Ted Hardie Date: Tue, 28 Feb 2017 13:56:51 -0800 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Mike Bishop Content-Type: multipart/alternative; boundary=001a113cdd28c7f1c505499e479f Archived-At: Cc: IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 21:57:24 -0000 --001a113cdd28c7f1c505499e479f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2017 at 1:15 PM, Mike Bishop wrote: > I don't think there's a desire to avoid linkability between the client's > proposed connection ID and the connection ID being used for the remainder > of the connection on the same path. If there is, that changes some thing= s, > but I'd be curious to know the motivation. > > I don't want that, as I think there is a likelihood that on-path devices maintaining NAT state might start using connection ID as an input to determining the safety of rebinding. Even if that is safe from a server endpoint perspective (since it will use connection ID), it could trigger differential treatment by network elements using equal-cost multipath or similar mechanisms to spread load. Nat re-binding can, in those cases, cause out-of-order packet arrival, and we don't want to help that along. regards, Ted > I agree that we might want to avoid linkability between the connection ID > of one connection/path and the connection ID the client will use on a > different path. > > -----Original Message----- > From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch] > Sent: Tuesday, February 28, 2017 12:06 PM > To: Mike Bishop > Cc: Ted Hardie ; Ryan Hamilton ; IETF > QUIC WG > Subject: Re: When should server-chosen connection IDs be sent and how are > they indicated? > > Even if the load balancer could see the traffic in the other direction, > the new connection ids should not be exposed to the path (aka this > information must be encrypted), otherwise it=E2=80=99s still linkable. > > If you want to avoid additional signaling (which could be done if the loa= d > balancer and the server have some kind of trust relationship), then both > need to know the algorithm that is used to create the additional ids. If > you don=E2=80=99t have any trust relationship (neither for signaling, nor= for some > kind of initial configuration) than you are the kind of middlebox that we > don=E2=80=99t want to be able to link different connections together. > > Mirja > > > > Am 28.02.2017 um 20:40 schrieb Mike Bishop >: > > > > Yes, but the problem is dealing with a situation where the load balance= r > and the server are independently managed, as in a hosting environment. > There would need to be something standardized. (Of course, if the load > balancer can be stateful, it doesn=E2=80=99t need nearly as much of this = machinery.) > > > > > > > > The other issue that was pointed out to me by one of our SLB guys is > that the load balancer only sees packets in the client-to-server directio= n, > not the server=E2=80=99s responses. So a Connection ID change proposed b= y the > server is invisible to the load balancer until it sees a future client > packet with the same 4-tuple and a different connection ID. But simply > allowing packets from the same source with a different ID to inform the > load balancer of an ID change seems ripe for attack by spoofing the sourc= e > =E2=80=93 we=E2=80=99d need to tightly scope how a load balancer can iden= tify that safely. > It also means that our agreement that client IP/port can=E2=80=99t change= =E2=80=9Cduring > the handshake=E2=80=9D actually has to extend until the server has receiv= ed packets > with the new connection ID. > > > > > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ted Hardie > > Sent: Tuesday, February 28, 2017 11:20 AM > > To: Ryan Hamilton > > Cc: IETF QUIC WG ; Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> > > Subject: Re: When should server-chosen connection IDs be sent and how > are they indicated? > > > > > > > > On Tue, Feb 28, 2017 at 10:13 AM, Ryan Hamilton wrote: > > > > > > > > On Tue, Feb 28, 2017 at 8:37 AM, Ted Hardie wrote: > > > > There are two cases we have to consider: linkability due to a change in > the network not visible to the client and linkability that occurs because > of a client-initiated change. You're correct that it cannot update the > connection ID to avoid linkage when it doesn't know of the change, but wh= en > the client initiates the change (e.g. moves from WiFi to cellular), it > certainly could. If this feature is optional, then you likely do have to > have a configuration frob that the client uses to say "re-use of connect > IDs is okay" vs. "not okay, please use 0RTT when transitions occur and on= ly > one connection ID is available". > > > > Personally, I'd be happy if it were not optional, and I think the > protocol to share out a pool of connection IDs from a load balancer/load > balancer farm is not that complicated. It's not in charter for QUIC, but = if > we wanted a proposal for it, I'm guessing we could knock something togeth= er > by the Paris interim and take it to dispatch in Prague. > > > > > > > > =E2=80=8BMy sense is that the working group believes that it is not acc= eptable > for a connection ID to be reused across client initiated network changes > (WiFi to Cellular). If this is accurate, then if a server did not present > any additional connection IDs to a client, the client would simply tear > down the connection if it changed networks, just as if it would do to TCP > connections. So we can still have this "list of connection IDs" feature > being optional without needing to empower clients to use the connection I= D > across network changes, right? > > > > > > > > Yes, that would be the alternate strategy. At that point, the client i= s > not expecting the new server to have state, so it is explicitly giving th= at > up to avoid linkability. > > > > > > > > I'm also not convinced that it is "not complicated" for a server to be > in possession of a set of connection IDs that will map back to itself in > some deployments, but I'd be happy to be wrong! > > > > > > > > Well, there are clearly proprietary solutions in this space, as well as > fairly basic methods of range assignment within the full pool that work > with a standard fan-out of servers behind a load balancer. They may not > cover all deployments, of course. > > > > regards, > > > > Ted > > > > > > > > --001a113cdd28c7f1c505499e479f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 28, 2017 at 1:15 PM, Mike Bishop <= Michael.Bishop@microsoft.com> wrote:
I don't= think there's a desire to avoid linkability between the client's p= roposed connection ID and the connection ID being used for the remainder of= the connection on the same path.=C2=A0 If there is, that changes some thin= gs, but I'd be curious to know the motivation.

I don't want that, as I think there is a likeliho= od that on-path devices maintaining NAT state might start using connection = ID as an input to determining the safety of rebinding.=C2=A0 Even if that i= s safe from a server endpoint perspective (since it will use connection ID)= , it could trigger differential treatment by network elements using equal-c= ost multipath or similar mechanisms to spread load.=C2=A0 Nat re-binding ca= n, in those cases, cause=C2=A0 out-of-order packet arrival, and we don'= t want to help that along.=C2=A0=C2=A0

regards,

<= /div>
Ted

=C2=A0
I agree that we might want to avoid linkability between the connection ID o= f one connection/path and the connection ID the client will use on a differ= ent path.

-----Original Message-----
From: Mirja K=C3=BChlewind [mailto:mirja.kuehlewind@tik.ee.ethz.ch]
Sent: Tuesday, February 28, = 2017 12:06 PM
To: Mike Bishop <Michael= .Bishop@microsoft.com>
Cc: Ted Hardie <ted.ietf@gmail.com= >; Ryan Hamilton <rch@google.co= m>; IETF QUIC WG <quic@ietf.org<= /a>>
Subject: Re: When should server-chosen connection IDs be sent and how are t= hey indicated?

Even if the load balancer could see the traffic in the other direction, the= new connection ids should not be exposed to the path (aka this information= must be encrypted), otherwise it=E2=80=99s still linkable.

If you want to avoid additional signaling (which could be done if the load = balancer and the server have some kind of trust relationship), then both ne= ed to know the algorithm that is used to create the additional ids. If you = don=E2=80=99t have any trust relationship (neither for signaling, nor for s= ome kind of initial configuration) than you are the kind of middlebox that = we don=E2=80=99t want to be able to link different connections together.
Mirja


> Am 28.02.2017 um 20:40 schrieb Mike Bishop <michael.bishop@microsoft.com>:
>
> Yes, but the problem is dealing with a situation where the load balanc= er and the server are independently managed, as in a hosting environment.= =C2=A0 There would need to be something standardized.=C2=A0 (Of course, if = the load balancer can be stateful, it doesn=E2=80=99t need nearly as much o= f this machinery.)
>
>
>
> The other issue that was pointed out to me by one of our SLB guys is t= hat the load balancer only sees packets in the client-to-server direction, = not the server=E2=80=99s responses.=C2=A0 So a Connection ID change propose= d by the server is invisible to the load balancer until it sees a future cl= ient packet with the same 4-tuple and a different connection ID.=C2=A0 But = simply allowing packets from the same source with a different ID to inform = the load balancer of an ID change seems ripe for attack by spoofing the sou= rce =E2=80=93 we=E2=80=99d need to tightly scope how a load balancer can id= entify that safely.=C2=A0 It also means that our agreement that client IP/p= ort can=E2=80=99t change =E2=80=9Cduring the handshake=E2=80=9D actually ha= s to extend until the server has received packets with the new connection I= D.
>
>
>
> From: QUIC [mailto:quic-bounc= es@ietf.org] On Behalf Of Ted Hardie
> Sent: Tuesday, February 28, 2017 11:20 AM
> To: Ryan Hamilton <rch@google.com= >
> Cc: IETF QUIC WG <quic@ietf.org>; Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch>
> Subject: Re: When should server-chosen connection IDs be sent and how = are they indicated?
>
>
>
> On Tue, Feb 28, 2017 at 10:13 AM, Ryan Hamilton <rch@google.com> wrote:
>
>
>
> On Tue, Feb 28, 2017 at 8:37 AM, Ted Hardie <ted.ietf@gmail.com> wrote:
>
> There are two cases we have to consider: linkability due to a change i= n the network not visible to the client and linkability that occurs because= of a client-initiated change.=C2=A0 You're correct that it cannot upda= te the connection ID to avoid linkage when it doesn't know of the chang= e, but when the client initiates the change (e.g. moves from WiFi to cellul= ar), it certainly could.=C2=A0 If this feature is optional, then you likely= do have to have a configuration frob that the client uses to say "re-= use of connect IDs is okay" vs. "not okay, please use 0RTT when t= ransitions occur and only one connection ID is available".
>
> Personally, I'd be happy if it were not optional, and I think the = protocol to share out a pool of connection IDs from a load balancer/load ba= lancer farm is not that complicated. It's not in charter for QUIC, but = if we wanted a proposal for it, I'm guessing we could knock something t= ogether by the Paris interim and take it to dispatch in Prague.
>
>
>
> =E2=80=8BMy sense is that the working group believes that it is not ac= ceptable for a connection ID to be reused across client initiated network c= hanges (WiFi to Cellular). If this is accurate, then if a server did not pr= esent any additional connection IDs to a client, the client would simply te= ar down the connection if it changed networks, just as if it would do to TC= P connections. So we can still have this "list of connection IDs"= feature being optional without needing to empower clients to use the conne= ction ID across network changes, right?
>
>
>
> Yes, that would be the alternate strategy.=C2=A0 At that point, the cl= ient is not expecting the new server to have state, so it is explicitly giv= ing that up to avoid linkability.
>
>
>
> I'm also not convinced that it is "not complicated" for = a server to be in possession of a set of connection IDs that will map back = to itself in some deployments, but I'd be happy to be wrong!
>
>
>
> Well, there are clearly proprietary solutions in this space, as well a= s fairly basic methods of range assignment within the full pool that work w= ith a standard fan-out of servers behind a load balancer.=C2=A0 They may no= t cover all deployments, of course.
>
> regards,
>
> Ted
>
>
>


--001a113cdd28c7f1c505499e479f-- From nobody Tue Feb 28 14:15:02 2017 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 E2B8C1293E0 for ; Tue, 28 Feb 2017 14:15:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_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 7ZYbYD0MTBm0 for ; Tue, 28 Feb 2017 14:14:58 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0134.outbound.protection.outlook.com [104.47.37.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 193F4127735 for ; Tue, 28 Feb 2017 14:14:58 -0800 (PST) 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=2653X92eniYHPVn9r2yte/JLzBj8MM+HNm3aIu4VluA=; b=GUc8/OdaTulimuF+EbiPgDzMJ22/IPrKUKDwCHAibR/FNEPF1DbOLiIohbncIzWUw8Vo3dy/C+Uu/ZcBvkwV8c+cbIv1EFzynRpGvUKnAuqF1Y2vqldK/fWWOdZzpwpyFnflFTONmxkRCnpqaYHJwQHSYhp3b6BfxofnGB7XLQo= Received: from BN6PR03MB2708.namprd03.prod.outlook.com (10.173.144.15) by BN6PR03MB2706.namprd03.prod.outlook.com (10.173.144.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.12; Tue, 28 Feb 2017 22:14:55 +0000 Received: from BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) by BN6PR03MB2708.namprd03.prod.outlook.com ([10.173.144.15]) with mapi id 15.01.0947.012; Tue, 28 Feb 2017 22:14:55 +0000 From: Mike Bishop To: Ted Hardie Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnTgidP6MC1E0yc8zksQ9LKAqF9m5CAgAAA8YCAALU8gIAATWEAgAAa8YCAABKLgIAABAbQgAAIvQCAABLRUIAADECAgAADEJA= Date: Tue, 28 Feb 2017 22:14:55 +0000 Message-ID: References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:5::51f] x-ms-office365-filtering-correlation-id: a0613c66-5c87-44fb-e1c5-08d4602739f9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:BN6PR03MB2706; x-microsoft-exchange-diagnostics: 1; BN6PR03MB2706; 7:2Fy7D8O4uJDd4w0aZWMYhB5WwyMzjKQAVPzDz7DBI7zhqbgnwtBRhBL0QgXALQMiSSR/cRG85o6LSL1/gVW6JY6dz63rnD5tKHFJPi+/lFHybOHRaVhePf2bqn66K594vIvlMggTXYnkV1J7rZUgEa1OOL7zQjvQXzhyMvMyOegD/OfC/amY35w8LD+uCzasR0dEdX/Qy/lbqVIDrgVhle1dnP++3t+ZvQmVmMVlEoFo7tiFN0V6D/78Kl9fyPRttWLkQLZ/jw+yWgdLmzJ1ZKfjDJ5sOteTJJiRCIcWgBE+0WlljoBXOfIq8CiV5xzi3baoKmT46FQ1E0f4cSiRRpJr1CyKtWcTdAV00MkSSOg= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524)(211936372134217)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(20161123558025)(6072148); SRVR:BN6PR03MB2706; BCL:0; PCL:0; RULEID:; SRVR:BN6PR03MB2706; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39840400002)(39860400002)(39450400003)(39850400002)(39410400002)(24454002)(377454003)(13464003)(10090500001)(189998001)(6116002)(86612001)(102836003)(7696004)(790700001)(93886004)(74316002)(229853002)(99286003)(55016002)(33656002)(106116001)(54896002)(6306002)(9686003)(5660300001)(77096006)(86362001)(6436002)(4326008)(54906002)(19609705001)(6506006)(6916009)(5005710100001)(8990500004)(236005)(2950100002)(25786008)(10290500002)(76176999)(53546006)(39060400002)(110136004)(53936002)(92566002)(7736002)(561944003)(50986999)(54356999)(8936002)(122556002)(81166006)(3280700002)(3660700001)(2906002)(8676002)(2900100001)(6246003)(38730400002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR03MB2706; H:BN6PR03MB2708.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN6PR03MB2708879E1E0CBE7829C1268887560BN6PR03MB2708namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2017 22:14:55.7657 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR03MB2706 Archived-At: Cc: IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 22:15:01 -0000 --_000_BN6PR03MB2708879E1E0CBE7829C1268887560BN6PR03MB2708namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T2theSDigJMgaXTigJlzIGdvb2QgdG8gY2xhcmlmeSB0aGF0IHRoZXJl4oCZcyBhIGRpc2N1c3Np b24gcG9pbnQgaGVyZSB3aGVyZSBJIGRpZG7igJl0IHRoaW5rIHdlIGhhZCBvbmUuICBJZiBRVUlD IHN1cHBvcnRzIHJlYmluZGluZyB2aWEgdGhlIENvbm5lY3Rpb24gSUQsIGlzbuKAmXQgdGhlIHNp bXBsZSBwcmVzZW5jZSBvZiBhIENvbm5lY3Rpb24gSUQgaW4gYSBRVUlDIHBhY2tldCBzdWZmaWNp ZW50IHRvIGRpc2Nsb3NlIHRoYXQgb3VyIGNvbm5lY3Rpb24gaXMg4oCcc2FmZXLigJ0gdG8gcmVi aW5kIHRoYW4gb3RoZXIgVURQIHRyYWZmaWM/ICBBbmQgSSBkb27igJl0IHRoaW5rIHlvdSBjYW4g YXZvaWQgZGlzY2xvc2luZyB0aGUgQ29ubmVjdGlvbiBJRCwgc2luY2UgdGhlIHNlcnZlciBuZWVk cyBpdCB0byBmaW5kIHRoZSBrZXlzIHRvIGRlY3J5cHQgdGhlIG5vbi1kaXNjbG9zZWQgc3R1ZmYu ICBUaGlzIGZlZWxzIGxpa2UgYSBmb3JlZ29uZSBjb25jbHVzaW9uLg0KDQpXZSBjYW4gbWFrZSBu b24tbGlua2FiaWxpdHkgb2YgdGhvc2UgSURzIGEgZnVuY3Rpb24gb2YgdGhlIHByb3RvY29sLCBi dXQgaXQgY29zdHMgdXMgdGhlIGFiaWxpdHkgdG8gaGF2ZSBsZXNzIGNvb3JkaW5hdGlvbiBiZXR3 ZWVuIGxvYWQgYmFsYW5jZXJzIGFuZCBzZXJ2ZXJzIGFuZCBJIGRvbuKAmXQgc2VlIHRoYXQgaXQg cmVhbGx5IGJ1eXMgdXMgYW55dGhpbmcgaW4gZXhjaGFuZ2UgZm9yIHRoYXQuDQoNCkZyb206IFRl ZCBIYXJkaWUgW21haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb21dDQpTZW50OiBUdWVzZGF5LCBGZWJy dWFyeSAyOCwgMjAxNyAxOjU3IFBNDQpUbzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1p Y3Jvc29mdC5jb20+DQpDYzogTWlyamEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsu ZWUuZXRoei5jaD47IFJ5YW4gSGFtaWx0b24gPHJjaEBnb29nbGUuY29tPjsgSUVURiBRVUlDIFdH IDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFdoZW4gc2hvdWxkIHNlcnZlci1jaG9zZW4g Y29ubmVjdGlvbiBJRHMgYmUgc2VudCBhbmQgaG93IGFyZSB0aGV5IGluZGljYXRlZD8NCg0KT24g VHVlLCBGZWIgMjgsIDIwMTcgYXQgMToxNSBQTSwgTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9w QG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+PiB3cm90 ZToNCkkgZG9uJ3QgdGhpbmsgdGhlcmUncyBhIGRlc2lyZSB0byBhdm9pZCBsaW5rYWJpbGl0eSBi ZXR3ZWVuIHRoZSBjbGllbnQncyBwcm9wb3NlZCBjb25uZWN0aW9uIElEIGFuZCB0aGUgY29ubmVj dGlvbiBJRCBiZWluZyB1c2VkIGZvciB0aGUgcmVtYWluZGVyIG9mIHRoZSBjb25uZWN0aW9uIG9u IHRoZSBzYW1lIHBhdGguICBJZiB0aGVyZSBpcywgdGhhdCBjaGFuZ2VzIHNvbWUgdGhpbmdzLCBi dXQgSSdkIGJlIGN1cmlvdXMgdG8ga25vdyB0aGUgbW90aXZhdGlvbi4NCkkgZG9uJ3Qgd2FudCB0 aGF0LCBhcyBJIHRoaW5rIHRoZXJlIGlzIGEgbGlrZWxpaG9vZCB0aGF0IG9uLXBhdGggZGV2aWNl cyBtYWludGFpbmluZyBOQVQgc3RhdGUgbWlnaHQgc3RhcnQgdXNpbmcgY29ubmVjdGlvbiBJRCBh cyBhbiBpbnB1dCB0byBkZXRlcm1pbmluZyB0aGUgc2FmZXR5IG9mIHJlYmluZGluZy4gIEV2ZW4g aWYgdGhhdCBpcyBzYWZlIGZyb20gYSBzZXJ2ZXIgZW5kcG9pbnQgcGVyc3BlY3RpdmUgKHNpbmNl IGl0IHdpbGwgdXNlIGNvbm5lY3Rpb24gSUQpLCBpdCBjb3VsZCB0cmlnZ2VyIGRpZmZlcmVudGlh bCB0cmVhdG1lbnQgYnkgbmV0d29yayBlbGVtZW50cyB1c2luZyBlcXVhbC1jb3N0IG11bHRpcGF0 aCBvciBzaW1pbGFyIG1lY2hhbmlzbXMgdG8gc3ByZWFkIGxvYWQuICBOYXQgcmUtYmluZGluZyBj YW4sIGluIHRob3NlIGNhc2VzLCBjYXVzZSAgb3V0LW9mLW9yZGVyIHBhY2tldCBhcnJpdmFsLCBh bmQgd2UgZG9uJ3Qgd2FudCB0byBoZWxwIHRoYXQgYWxvbmcuDQpyZWdhcmRzLA0KVGVkDQoNCg0K SSBhZ3JlZSB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gYXZvaWQgbGlua2FiaWxpdHkgYmV0d2VlbiB0 aGUgY29ubmVjdGlvbiBJRCBvZiBvbmUgY29ubmVjdGlvbi9wYXRoIGFuZCB0aGUgY29ubmVjdGlv biBJRCB0aGUgY2xpZW50IHdpbGwgdXNlIG9uIGEgZGlmZmVyZW50IHBhdGguDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBNaXJqYSBLw7xobGV3aW5kIFttYWlsdG86bWlyamEu a3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDxtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUu ZXRoei5jaD5dDQpTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyOCwgMjAxNyAxMjowNiBQTQ0KVG86 IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVs LkJpc2hvcEBtaWNyb3NvZnQuY29tPj4NCkNjOiBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5j b208bWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNvbT4+OyBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xl LmNvbTxtYWlsdG86cmNoQGdvb2dsZS5jb20+PjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3Jn PG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBXaGVuIHNob3VsZCBzZXJ2ZXIt Y2hvc2VuIGNvbm5lY3Rpb24gSURzIGJlIHNlbnQgYW5kIGhvdyBhcmUgdGhleSBpbmRpY2F0ZWQ/ DQoNCkV2ZW4gaWYgdGhlIGxvYWQgYmFsYW5jZXIgY291bGQgc2VlIHRoZSB0cmFmZmljIGluIHRo ZSBvdGhlciBkaXJlY3Rpb24sIHRoZSBuZXcgY29ubmVjdGlvbiBpZHMgc2hvdWxkIG5vdCBiZSBl eHBvc2VkIHRvIHRoZSBwYXRoIChha2EgdGhpcyBpbmZvcm1hdGlvbiBtdXN0IGJlIGVuY3J5cHRl ZCksIG90aGVyd2lzZSBpdOKAmXMgc3RpbGwgbGlua2FibGUuDQoNCklmIHlvdSB3YW50IHRvIGF2 b2lkIGFkZGl0aW9uYWwgc2lnbmFsaW5nICh3aGljaCBjb3VsZCBiZSBkb25lIGlmIHRoZSBsb2Fk IGJhbGFuY2VyIGFuZCB0aGUgc2VydmVyIGhhdmUgc29tZSBraW5kIG9mIHRydXN0IHJlbGF0aW9u c2hpcCksIHRoZW4gYm90aCBuZWVkIHRvIGtub3cgdGhlIGFsZ29yaXRobSB0aGF0IGlzIHVzZWQg dG8gY3JlYXRlIHRoZSBhZGRpdGlvbmFsIGlkcy4gSWYgeW91IGRvbuKAmXQgaGF2ZSBhbnkgdHJ1 c3QgcmVsYXRpb25zaGlwIChuZWl0aGVyIGZvciBzaWduYWxpbmcsIG5vciBmb3Igc29tZSBraW5k IG9mIGluaXRpYWwgY29uZmlndXJhdGlvbikgdGhhbiB5b3UgYXJlIHRoZSBraW5kIG9mIG1pZGRs ZWJveCB0aGF0IHdlIGRvbuKAmXQgd2FudCB0byBiZSBhYmxlIHRvIGxpbmsgZGlmZmVyZW50IGNv bm5lY3Rpb25zIHRvZ2V0aGVyLg0KDQpNaXJqYQ0KDQoNCj4gQW0gMjguMDIuMjAxNyB1bSAyMDo0 MCBzY2hyaWViIE1pa2UgQmlzaG9wIDxtaWNoYWVsLmJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0 bzptaWNoYWVsLmJpc2hvcEBtaWNyb3NvZnQuY29tPj46DQo+DQo+IFllcywgYnV0IHRoZSBwcm9i bGVtIGlzIGRlYWxpbmcgd2l0aCBhIHNpdHVhdGlvbiB3aGVyZSB0aGUgbG9hZCBiYWxhbmNlciBh bmQgdGhlIHNlcnZlciBhcmUgaW5kZXBlbmRlbnRseSBtYW5hZ2VkLCBhcyBpbiBhIGhvc3Rpbmcg ZW52aXJvbm1lbnQuICBUaGVyZSB3b3VsZCBuZWVkIHRvIGJlIHNvbWV0aGluZyBzdGFuZGFyZGl6 ZWQuICAoT2YgY291cnNlLCBpZiB0aGUgbG9hZCBiYWxhbmNlciBjYW4gYmUgc3RhdGVmdWwsIGl0 IGRvZXNu4oCZdCBuZWVkIG5lYXJseSBhcyBtdWNoIG9mIHRoaXMgbWFjaGluZXJ5LikNCj4NCj4N Cj4NCj4gVGhlIG90aGVyIGlzc3VlIHRoYXQgd2FzIHBvaW50ZWQgb3V0IHRvIG1lIGJ5IG9uZSBv ZiBvdXIgU0xCIGd1eXMgaXMgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciBvbmx5IHNlZXMgcGFja2V0 cyBpbiB0aGUgY2xpZW50LXRvLXNlcnZlciBkaXJlY3Rpb24sIG5vdCB0aGUgc2VydmVy4oCZcyBy ZXNwb25zZXMuICBTbyBhIENvbm5lY3Rpb24gSUQgY2hhbmdlIHByb3Bvc2VkIGJ5IHRoZSBzZXJ2 ZXIgaXMgaW52aXNpYmxlIHRvIHRoZSBsb2FkIGJhbGFuY2VyIHVudGlsIGl0IHNlZXMgYSBmdXR1 cmUgY2xpZW50IHBhY2tldCB3aXRoIHRoZSBzYW1lIDQtdHVwbGUgYW5kIGEgZGlmZmVyZW50IGNv bm5lY3Rpb24gSUQuICBCdXQgc2ltcGx5IGFsbG93aW5nIHBhY2tldHMgZnJvbSB0aGUgc2FtZSBz b3VyY2Ugd2l0aCBhIGRpZmZlcmVudCBJRCB0byBpbmZvcm0gdGhlIGxvYWQgYmFsYW5jZXIgb2Yg YW4gSUQgY2hhbmdlIHNlZW1zIHJpcGUgZm9yIGF0dGFjayBieSBzcG9vZmluZyB0aGUgc291cmNl IOKAkyB3ZeKAmWQgbmVlZCB0byB0aWdodGx5IHNjb3BlIGhvdyBhIGxvYWQgYmFsYW5jZXIgY2Fu IGlkZW50aWZ5IHRoYXQgc2FmZWx5LiAgSXQgYWxzbyBtZWFucyB0aGF0IG91ciBhZ3JlZW1lbnQg dGhhdCBjbGllbnQgSVAvcG9ydCBjYW7igJl0IGNoYW5nZSDigJxkdXJpbmcgdGhlIGhhbmRzaGFr ZeKAnSBhY3R1YWxseSBoYXMgdG8gZXh0ZW5kIHVudGlsIHRoZSBzZXJ2ZXIgaGFzIHJlY2VpdmVk IHBhY2tldHMgd2l0aCB0aGUgbmV3IGNvbm5lY3Rpb24gSUQuDQo+DQo+DQo+DQo+IEZyb206IFFV SUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZz5dIE9uIEJlaGFsZiBPZiBUZWQgSGFyZGllDQo+IFNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5 IDI4LCAyMDE3IDExOjIwIEFNDQo+IFRvOiBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbTxt YWlsdG86cmNoQGdvb2dsZS5jb20+Pg0KPiBDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3Jn PG1haWx0bzpxdWljQGlldGYub3JnPj47IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdp bmRAdGlrLmVlLmV0aHouY2g8bWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+ Pg0KPiBTdWJqZWN0OiBSZTogV2hlbiBzaG91bGQgc2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElE cyBiZSBzZW50IGFuZCBob3cgYXJlIHRoZXkgaW5kaWNhdGVkPw0KPg0KPg0KPg0KPiBPbiBUdWUs IEZlYiAyOCwgMjAxNyBhdCAxMDoxMyBBTSwgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb208 bWFpbHRvOnJjaEBnb29nbGUuY29tPj4gd3JvdGU6DQo+DQo+DQo+DQo+IE9uIFR1ZSwgRmViIDI4 LCAyMDE3IGF0IDg6MzcgQU0sIFRlZCBIYXJkaWUgPHRlZC5pZXRmQGdtYWlsLmNvbTxtYWlsdG86 dGVkLmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQo+DQo+IFRoZXJlIGFyZSB0d28gY2FzZXMgd2Ug aGF2ZSB0byBjb25zaWRlcjogbGlua2FiaWxpdHkgZHVlIHRvIGEgY2hhbmdlIGluIHRoZSBuZXR3 b3JrIG5vdCB2aXNpYmxlIHRvIHRoZSBjbGllbnQgYW5kIGxpbmthYmlsaXR5IHRoYXQgb2NjdXJz IGJlY2F1c2Ugb2YgYSBjbGllbnQtaW5pdGlhdGVkIGNoYW5nZS4gIFlvdSdyZSBjb3JyZWN0IHRo YXQgaXQgY2Fubm90IHVwZGF0ZSB0aGUgY29ubmVjdGlvbiBJRCB0byBhdm9pZCBsaW5rYWdlIHdo ZW4gaXQgZG9lc24ndCBrbm93IG9mIHRoZSBjaGFuZ2UsIGJ1dCB3aGVuIHRoZSBjbGllbnQgaW5p dGlhdGVzIHRoZSBjaGFuZ2UgKGUuZy4gbW92ZXMgZnJvbSBXaUZpIHRvIGNlbGx1bGFyKSwgaXQg Y2VydGFpbmx5IGNvdWxkLiAgSWYgdGhpcyBmZWF0dXJlIGlzIG9wdGlvbmFsLCB0aGVuIHlvdSBs aWtlbHkgZG8gaGF2ZSB0byBoYXZlIGEgY29uZmlndXJhdGlvbiBmcm9iIHRoYXQgdGhlIGNsaWVu dCB1c2VzIHRvIHNheSAicmUtdXNlIG9mIGNvbm5lY3QgSURzIGlzIG9rYXkiIHZzLiAibm90IG9r YXksIHBsZWFzZSB1c2UgMFJUVCB3aGVuIHRyYW5zaXRpb25zIG9jY3VyIGFuZCBvbmx5IG9uZSBj b25uZWN0aW9uIElEIGlzIGF2YWlsYWJsZSIuDQo+DQo+IFBlcnNvbmFsbHksIEknZCBiZSBoYXBw eSBpZiBpdCB3ZXJlIG5vdCBvcHRpb25hbCwgYW5kIEkgdGhpbmsgdGhlIHByb3RvY29sIHRvIHNo YXJlIG91dCBhIHBvb2wgb2YgY29ubmVjdGlvbiBJRHMgZnJvbSBhIGxvYWQgYmFsYW5jZXIvbG9h ZCBiYWxhbmNlciBmYXJtIGlzIG5vdCB0aGF0IGNvbXBsaWNhdGVkLiBJdCdzIG5vdCBpbiBjaGFy dGVyIGZvciBRVUlDLCBidXQgaWYgd2Ugd2FudGVkIGEgcHJvcG9zYWwgZm9yIGl0LCBJJ20gZ3Vl c3Npbmcgd2UgY291bGQga25vY2sgc29tZXRoaW5nIHRvZ2V0aGVyIGJ5IHRoZSBQYXJpcyBpbnRl cmltIGFuZCB0YWtlIGl0IHRvIGRpc3BhdGNoIGluIFByYWd1ZS4NCj4NCj4NCj4NCj4g4oCLTXkg c2Vuc2UgaXMgdGhhdCB0aGUgd29ya2luZyBncm91cCBiZWxpZXZlcyB0aGF0IGl0IGlzIG5vdCBh Y2NlcHRhYmxlIGZvciBhIGNvbm5lY3Rpb24gSUQgdG8gYmUgcmV1c2VkIGFjcm9zcyBjbGllbnQg aW5pdGlhdGVkIG5ldHdvcmsgY2hhbmdlcyAoV2lGaSB0byBDZWxsdWxhcikuIElmIHRoaXMgaXMg YWNjdXJhdGUsIHRoZW4gaWYgYSBzZXJ2ZXIgZGlkIG5vdCBwcmVzZW50IGFueSBhZGRpdGlvbmFs IGNvbm5lY3Rpb24gSURzIHRvIGEgY2xpZW50LCB0aGUgY2xpZW50IHdvdWxkIHNpbXBseSB0ZWFy IGRvd24gdGhlIGNvbm5lY3Rpb24gaWYgaXQgY2hhbmdlZCBuZXR3b3JrcywganVzdCBhcyBpZiBp dCB3b3VsZCBkbyB0byBUQ1AgY29ubmVjdGlvbnMuIFNvIHdlIGNhbiBzdGlsbCBoYXZlIHRoaXMg Imxpc3Qgb2YgY29ubmVjdGlvbiBJRHMiIGZlYXR1cmUgYmVpbmcgb3B0aW9uYWwgd2l0aG91dCBu ZWVkaW5nIHRvIGVtcG93ZXIgY2xpZW50cyB0byB1c2UgdGhlIGNvbm5lY3Rpb24gSUQgYWNyb3Nz IG5ldHdvcmsgY2hhbmdlcywgcmlnaHQ/DQo+DQo+DQo+DQo+IFllcywgdGhhdCB3b3VsZCBiZSB0 aGUgYWx0ZXJuYXRlIHN0cmF0ZWd5LiAgQXQgdGhhdCBwb2ludCwgdGhlIGNsaWVudCBpcyBub3Qg ZXhwZWN0aW5nIHRoZSBuZXcgc2VydmVyIHRvIGhhdmUgc3RhdGUsIHNvIGl0IGlzIGV4cGxpY2l0 bHkgZ2l2aW5nIHRoYXQgdXAgdG8gYXZvaWQgbGlua2FiaWxpdHkuDQo+DQo+DQo+DQo+IEknbSBh bHNvIG5vdCBjb252aW5jZWQgdGhhdCBpdCBpcyAibm90IGNvbXBsaWNhdGVkIiBmb3IgYSBzZXJ2 ZXIgdG8gYmUgaW4gcG9zc2Vzc2lvbiBvZiBhIHNldCBvZiBjb25uZWN0aW9uIElEcyB0aGF0IHdp bGwgbWFwIGJhY2sgdG8gaXRzZWxmIGluIHNvbWUgZGVwbG95bWVudHMsIGJ1dCBJJ2QgYmUgaGFw cHkgdG8gYmUgd3JvbmchDQo+DQo+DQo+DQo+IFdlbGwsIHRoZXJlIGFyZSBjbGVhcmx5IHByb3By aWV0YXJ5IHNvbHV0aW9ucyBpbiB0aGlzIHNwYWNlLCBhcyB3ZWxsIGFzIGZhaXJseSBiYXNpYyBt ZXRob2RzIG9mIHJhbmdlIGFzc2lnbm1lbnQgd2l0aGluIHRoZSBmdWxsIHBvb2wgdGhhdCB3b3Jr IHdpdGggYSBzdGFuZGFyZCBmYW4tb3V0IG9mIHNlcnZlcnMgYmVoaW5kIGEgbG9hZCBiYWxhbmNl ci4gIFRoZXkgbWF5IG5vdCBjb3ZlciBhbGwgZGVwbG95bWVudHMsIG9mIGNvdXJzZS4NCj4NCj4g cmVnYXJkcywNCj4NCj4gVGVkDQo+DQo+DQo+DQoNCg== --_000_BN6PR03MB2708879E1E0CBE7829C1268887560BN6PR03MB2708namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaW0NCgl7bXNvLXN0eWxlLW5h bWU6aW07fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6 ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9rYXkg4oCTIGl04oCZcyBnb29kIHRvIGNs YXJpZnkgdGhhdCB0aGVyZeKAmXMgYSBkaXNjdXNzaW9uIHBvaW50IGhlcmUgd2hlcmUgSSBkaWRu 4oCZdCB0aGluayB3ZSBoYWQgb25lLiZuYnNwOyBJZiBRVUlDIHN1cHBvcnRzIHJlYmluZGluZyB2 aWEgdGhlIENvbm5lY3Rpb24gSUQsIGlzbuKAmXQgdGhlIHNpbXBsZSBwcmVzZW5jZSBvZiBhIENv bm5lY3Rpb24gSUQgaW4gYSBRVUlDIHBhY2tldCBzdWZmaWNpZW50IHRvIGRpc2Nsb3NlIHRoYXQN CiBvdXIgY29ubmVjdGlvbiBpcyDigJxzYWZlcuKAnSB0byByZWJpbmQgdGhhbiBvdGhlciBVRFAg dHJhZmZpYz8mbmJzcDsgQW5kIEkgZG9u4oCZdCB0aGluayB5b3UgY2FuIGF2b2lkIGRpc2Nsb3Np bmcgdGhlIENvbm5lY3Rpb24gSUQsIHNpbmNlIHRoZSBzZXJ2ZXIgbmVlZHMgaXQgdG8gZmluZCB0 aGUga2V5cyB0byBkZWNyeXB0IHRoZSBub24tZGlzY2xvc2VkIHN0dWZmLiZuYnNwOyBUaGlzIGZl ZWxzIGxpa2UgYSBmb3JlZ29uZSBjb25jbHVzaW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X ZSBjYW4gbWFrZSBub24tbGlua2FiaWxpdHkgb2YgdGhvc2UgSURzIGEgZnVuY3Rpb24gb2YgdGhl IHByb3RvY29sLCBidXQgaXQgY29zdHMgdXMgdGhlIGFiaWxpdHkgdG8gaGF2ZSBsZXNzIGNvb3Jk aW5hdGlvbiBiZXR3ZWVuIGxvYWQgYmFsYW5jZXJzIGFuZCBzZXJ2ZXJzIGFuZCBJIGRvbuKAmXQg c2VlIHRoYXQgaXQgcmVhbGx5IGJ1eXMgdXMgYW55dGhpbmcgaW4gZXhjaGFuZ2UgZm9yIHRoYXQu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBUZWQgSGFyZGllIFttYWlsdG86 dGVkLmlldGZAZ21haWwuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVicnVhcnkg MjgsIDIwMTcgMTo1NyBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0O01pY2hhZWwu QmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaXJqYSBLw7xobGV3aW5k ICZsdDttaXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoJmd0OzsgUnlhbiBIYW1pbHRvbiAm bHQ7cmNoQGdvb2dsZS5jb20mZ3Q7OyBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBXaGVuIHNob3VsZCBzZXJ2ZXItY2hvc2VuIGNvbm5l Y3Rpb24gSURzIGJlIHNlbnQgYW5kIGhvdyBhcmUgdGhleSBpbmRpY2F0ZWQ/PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAyOCwgMjAxNyBhdCAxOjE1IFBNLCBNaWtl IEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20i IHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgZG9uJ3QgdGhpbmsgdGhl cmUncyBhIGRlc2lyZSB0byBhdm9pZCBsaW5rYWJpbGl0eSBiZXR3ZWVuIHRoZSBjbGllbnQncyBw cm9wb3NlZCBjb25uZWN0aW9uIElEIGFuZCB0aGUgY29ubmVjdGlvbiBJRCBiZWluZyB1c2VkIGZv ciB0aGUgcmVtYWluZGVyIG9mIHRoZSBjb25uZWN0aW9uIG9uIHRoZSBzYW1lIHBhdGguJm5ic3A7 IElmIHRoZXJlIGlzLCB0aGF0IGNoYW5nZXMNCiBzb21lIHRoaW5ncywgYnV0IEknZCBiZSBjdXJp b3VzIHRvIGtub3cgdGhlIG1vdGl2YXRpb24uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij5JIGRvbid0IHdhbnQgdGhhdCwgYXMgSSB0aGluayB0aGVyZSBpcyBhIGxpa2VsaWhvb2QgdGhh dCBvbi1wYXRoIGRldmljZXMgbWFpbnRhaW5pbmcgTkFUIHN0YXRlIG1pZ2h0IHN0YXJ0IHVzaW5n IGNvbm5lY3Rpb24gSUQgYXMgYW4gaW5wdXQgdG8gZGV0ZXJtaW5pbmcgdGhlIHNhZmV0eSBvZiBy ZWJpbmRpbmcuJm5ic3A7IEV2ZW4gaWYgdGhhdCBpcyBzYWZlIGZyb20gYQ0KIHNlcnZlciBlbmRw b2ludCBwZXJzcGVjdGl2ZSAoc2luY2UgaXQgd2lsbCB1c2UgY29ubmVjdGlvbiBJRCksIGl0IGNv dWxkIHRyaWdnZXIgZGlmZmVyZW50aWFsIHRyZWF0bWVudCBieSBuZXR3b3JrIGVsZW1lbnRzIHVz aW5nIGVxdWFsLWNvc3QgbXVsdGlwYXRoIG9yIHNpbWlsYXIgbWVjaGFuaXNtcyB0byBzcHJlYWQg bG9hZC4mbmJzcDsgTmF0IHJlLWJpbmRpbmcgY2FuLCBpbiB0aG9zZSBjYXNlcywgY2F1c2UmbmJz cDsgb3V0LW9mLW9yZGVyIHBhY2tldCBhcnJpdmFsLA0KIGFuZCB3ZSBkb24ndCB3YW50IHRvIGhl bHAgdGhhdCBhbG9uZy4mbmJzcDsmbmJzcDsgPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPnJlZ2Fy ZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5U ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SSBhZ3JlZSB0aGF0IHdlIG1pZ2h0IHdhbnQgdG8gYXZvaWQgbGlua2FiaWxp dHkgYmV0d2VlbiB0aGUgY29ubmVjdGlvbiBJRCBvZiBvbmUgY29ubmVjdGlvbi9wYXRoIGFuZCB0 aGUgY29ubmVjdGlvbiBJRCB0aGUgY2xpZW50IHdpbGwgdXNlIG9uIGEgZGlmZmVyZW50IHBhdGgu PGJyPg0KPGJyPg0KPHNwYW4gY2xhc3M9ImltIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTwv c3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaW0iPkZyb206IE1pcmphIEvDvGhsZXdpbmQgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCI+bWlyamEu a3VlaGxld2luZEB0aWsuZWUuZXRoei5jaDwvYT5dPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4w cHQiPlNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE3IDEyOjA2IFBNPGJyPg0KVG86IE1p a2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNv bSI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7PGJyPg0KQ2M6IFRlZCBIYXJk aWUgJmx0OzxhIGhyZWY9Im1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20iPnRlZC5pZXRmQGdtYWls LmNvbTwvYT4mZ3Q7OyBSeWFuIEhhbWlsdG9uICZsdDs8YSBocmVmPSJtYWlsdG86cmNoQGdvb2ds ZS5jb20iPnJjaEBnb29nbGUuY29tPC9hPiZndDs7IElFVEYgUVVJQyBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NClN1YmplY3Q6 IFJlOiBXaGVuIHNob3VsZCBzZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSURzIGJlIHNlbnQgYW5k IGhvdyBhcmUgdGhleSBpbmRpY2F0ZWQ/PGJyPg0KPGJyPg0KRXZlbiBpZiB0aGUgbG9hZCBiYWxh bmNlciBjb3VsZCBzZWUgdGhlIHRyYWZmaWMgaW4gdGhlIG90aGVyIGRpcmVjdGlvbiwgdGhlIG5l dyBjb25uZWN0aW9uIGlkcyBzaG91bGQgbm90IGJlIGV4cG9zZWQgdG8gdGhlIHBhdGggKGFrYSB0 aGlzIGluZm9ybWF0aW9uIG11c3QgYmUgZW5jcnlwdGVkKSwgb3RoZXJ3aXNlIGl04oCZcyBzdGls bCBsaW5rYWJsZS48YnI+DQo8YnI+DQpJZiB5b3Ugd2FudCB0byBhdm9pZCBhZGRpdGlvbmFsIHNp Z25hbGluZyAod2hpY2ggY291bGQgYmUgZG9uZSBpZiB0aGUgbG9hZCBiYWxhbmNlciBhbmQgdGhl IHNlcnZlciBoYXZlIHNvbWUga2luZCBvZiB0cnVzdCByZWxhdGlvbnNoaXApLCB0aGVuIGJvdGgg bmVlZCB0byBrbm93IHRoZSBhbGdvcml0aG0gdGhhdCBpcyB1c2VkIHRvIGNyZWF0ZSB0aGUgYWRk aXRpb25hbCBpZHMuIElmIHlvdSBkb27igJl0IGhhdmUgYW55IHRydXN0IHJlbGF0aW9uc2hpcA0K IChuZWl0aGVyIGZvciBzaWduYWxpbmcsIG5vciBmb3Igc29tZSBraW5kIG9mIGluaXRpYWwgY29u ZmlndXJhdGlvbikgdGhhbiB5b3UgYXJlIHRoZSBraW5kIG9mIG1pZGRsZWJveCB0aGF0IHdlIGRv buKAmXQgd2FudCB0byBiZSBhYmxlIHRvIGxpbmsgZGlmZmVyZW50IGNvbm5lY3Rpb25zIHRvZ2V0 aGVyLjxicj4NCjxicj4NCk1pcmphPGJyPg0KPGJyPg0KPGJyPg0KJmd0OyBBbSAyOC4wMi4yMDE3 IHVtIDIwOjQwIHNjaHJpZWIgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptaWNoYWVs LmJpc2hvcEBtaWNyb3NvZnQuY29tIj5taWNoYWVsLmJpc2hvcEBtaWNyb3NvZnQuY29tPC9hPiZn dDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgWWVzLCBidXQgdGhlIHByb2JsZW0gaXMgZGVhbGluZyB3 aXRoIGEgc2l0dWF0aW9uIHdoZXJlIHRoZSBsb2FkIGJhbGFuY2VyIGFuZCB0aGUgc2VydmVyIGFy ZSBpbmRlcGVuZGVudGx5IG1hbmFnZWQsIGFzIGluIGEgaG9zdGluZyBlbnZpcm9ubWVudC4mbmJz cDsgVGhlcmUgd291bGQgbmVlZCB0byBiZSBzb21ldGhpbmcgc3RhbmRhcmRpemVkLiZuYnNwOyAo T2YgY291cnNlLCBpZiB0aGUgbG9hZCBiYWxhbmNlciBjYW4gYmUgc3RhdGVmdWwsIGl0IGRvZXNu 4oCZdCBuZWVkDQogbmVhcmx5IGFzIG11Y2ggb2YgdGhpcyBtYWNoaW5lcnkuKTxicj4NCiZndDs8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDsgVGhlIG90aGVyIGlzc3VlIHRoYXQgd2FzIHBv aW50ZWQgb3V0IHRvIG1lIGJ5IG9uZSBvZiBvdXIgU0xCIGd1eXMgaXMgdGhhdCB0aGUgbG9hZCBi YWxhbmNlciBvbmx5IHNlZXMgcGFja2V0cyBpbiB0aGUgY2xpZW50LXRvLXNlcnZlciBkaXJlY3Rp b24sIG5vdCB0aGUgc2VydmVy4oCZcyByZXNwb25zZXMuJm5ic3A7IFNvIGEgQ29ubmVjdGlvbiBJ RCBjaGFuZ2UgcHJvcG9zZWQgYnkgdGhlIHNlcnZlciBpcyBpbnZpc2libGUgdG8gdGhlIGxvYWQg YmFsYW5jZXINCiB1bnRpbCBpdCBzZWVzIGEgZnV0dXJlIGNsaWVudCBwYWNrZXQgd2l0aCB0aGUg c2FtZSA0LXR1cGxlIGFuZCBhIGRpZmZlcmVudCBjb25uZWN0aW9uIElELiZuYnNwOyBCdXQgc2lt cGx5IGFsbG93aW5nIHBhY2tldHMgZnJvbSB0aGUgc2FtZSBzb3VyY2Ugd2l0aCBhIGRpZmZlcmVu dCBJRCB0byBpbmZvcm0gdGhlIGxvYWQgYmFsYW5jZXIgb2YgYW4gSUQgY2hhbmdlIHNlZW1zIHJp cGUgZm9yIGF0dGFjayBieSBzcG9vZmluZyB0aGUgc291cmNlIOKAkyB3ZeKAmWQNCiBuZWVkIHRv IHRpZ2h0bHkgc2NvcGUgaG93IGEgbG9hZCBiYWxhbmNlciBjYW4gaWRlbnRpZnkgdGhhdCBzYWZl bHkuJm5ic3A7IEl0IGFsc28gbWVhbnMgdGhhdCBvdXIgYWdyZWVtZW50IHRoYXQgY2xpZW50IElQ L3BvcnQgY2Fu4oCZdCBjaGFuZ2Ug4oCcZHVyaW5nIHRoZSBoYW5kc2hha2XigJ0gYWN0dWFsbHkg aGFzIHRvIGV4dGVuZCB1bnRpbCB0aGUgc2VydmVyIGhhcyByZWNlaXZlZCBwYWNrZXRzIHdpdGgg dGhlIG5ldyBjb25uZWN0aW9uIElELjxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4N CiZndDsgRnJvbTogUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmciPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBUZWQgSGFyZGll PGJyPg0KJmd0OyBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyOCwgMjAxNyAxMToyMCBBTTxicj4N CiZndDsgVG86IFJ5YW4gSGFtaWx0b24gJmx0OzxhIGhyZWY9Im1haWx0bzpyY2hAZ29vZ2xlLmNv bSI+cmNoQGdvb2dsZS5jb208L2E+Jmd0Ozxicj4NCiZndDsgQ2M6IElFVEYgUVVJQyBXRyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzsgTWly amEgS8O8aGxld2luZCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVl LmV0aHouY2giPm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8L2E+Jmd0Ozxicj4NCiZn dDsgU3ViamVjdDogUmU6IFdoZW4gc2hvdWxkIHNlcnZlci1jaG9zZW4gY29ubmVjdGlvbiBJRHMg YmUgc2VudCBhbmQgaG93IGFyZSB0aGV5IGluZGljYXRlZD88YnI+DQomZ3Q7PGJyPg0KJmd0Ozxi cj4NCiZndDs8YnI+DQomZ3Q7IE9uIFR1ZSwgRmViIDI4LCAyMDE3IGF0IDEwOjEzIEFNLCBSeWFu IEhhbWlsdG9uICZsdDs8YSBocmVmPSJtYWlsdG86cmNoQGdvb2dsZS5jb20iPnJjaEBnb29nbGUu Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBPbiBUdWUsIEZlYiAyOCwgMjAxNyBhdCA4OjM3IEFNLCBUZWQgSGFyZGllICZsdDs8YSBocmVm PSJtYWlsdG86dGVkLmlldGZAZ21haWwuY29tIj50ZWQuaWV0ZkBnbWFpbC5jb208L2E+Jmd0OyB3 cm90ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGVyZSBhcmUgdHdvIGNhc2VzIHdlIGhhdmUgdG8g Y29uc2lkZXI6IGxpbmthYmlsaXR5IGR1ZSB0byBhIGNoYW5nZSBpbiB0aGUgbmV0d29yayBub3Qg dmlzaWJsZSB0byB0aGUgY2xpZW50IGFuZCBsaW5rYWJpbGl0eSB0aGF0IG9jY3VycyBiZWNhdXNl IG9mIGEgY2xpZW50LWluaXRpYXRlZCBjaGFuZ2UuJm5ic3A7IFlvdSdyZSBjb3JyZWN0IHRoYXQg aXQgY2Fubm90IHVwZGF0ZSB0aGUgY29ubmVjdGlvbiBJRCB0byBhdm9pZCBsaW5rYWdlIHdoZW4g aXQNCiBkb2Vzbid0IGtub3cgb2YgdGhlIGNoYW5nZSwgYnV0IHdoZW4gdGhlIGNsaWVudCBpbml0 aWF0ZXMgdGhlIGNoYW5nZSAoZS5nLiBtb3ZlcyBmcm9tIFdpRmkgdG8gY2VsbHVsYXIpLCBpdCBj ZXJ0YWlubHkgY291bGQuJm5ic3A7IElmIHRoaXMgZmVhdHVyZSBpcyBvcHRpb25hbCwgdGhlbiB5 b3UgbGlrZWx5IGRvIGhhdmUgdG8gaGF2ZSBhIGNvbmZpZ3VyYXRpb24gZnJvYiB0aGF0IHRoZSBj bGllbnQgdXNlcyB0byBzYXkgJnF1b3Q7cmUtdXNlIG9mIGNvbm5lY3QgSURzDQogaXMgb2theSZx dW90OyB2cy4gJnF1b3Q7bm90IG9rYXksIHBsZWFzZSB1c2UgMFJUVCB3aGVuIHRyYW5zaXRpb25z IG9jY3VyIGFuZCBvbmx5IG9uZSBjb25uZWN0aW9uIElEIGlzIGF2YWlsYWJsZSZxdW90Oy48YnI+ DQomZ3Q7PGJyPg0KJmd0OyBQZXJzb25hbGx5LCBJJ2QgYmUgaGFwcHkgaWYgaXQgd2VyZSBub3Qg b3B0aW9uYWwsIGFuZCBJIHRoaW5rIHRoZSBwcm90b2NvbCB0byBzaGFyZSBvdXQgYSBwb29sIG9m IGNvbm5lY3Rpb24gSURzIGZyb20gYSBsb2FkIGJhbGFuY2VyL2xvYWQgYmFsYW5jZXIgZmFybSBp cyBub3QgdGhhdCBjb21wbGljYXRlZC4gSXQncyBub3QgaW4gY2hhcnRlciBmb3IgUVVJQywgYnV0 IGlmIHdlIHdhbnRlZCBhIHByb3Bvc2FsIGZvciBpdCwgSSdtIGd1ZXNzaW5nDQogd2UgY291bGQg a25vY2sgc29tZXRoaW5nIHRvZ2V0aGVyIGJ5IHRoZSBQYXJpcyBpbnRlcmltIGFuZCB0YWtlIGl0 IHRvIGRpc3BhdGNoIGluIFByYWd1ZS48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+ DQomZ3Q7IOKAi015IHNlbnNlIGlzIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgYmVsaWV2ZXMgdGhh dCBpdCBpcyBub3QgYWNjZXB0YWJsZSBmb3IgYSBjb25uZWN0aW9uIElEIHRvIGJlIHJldXNlZCBh Y3Jvc3MgY2xpZW50IGluaXRpYXRlZCBuZXR3b3JrIGNoYW5nZXMgKFdpRmkgdG8gQ2VsbHVsYXIp LiBJZiB0aGlzIGlzIGFjY3VyYXRlLCB0aGVuIGlmIGEgc2VydmVyIGRpZCBub3QgcHJlc2VudCBh bnkgYWRkaXRpb25hbCBjb25uZWN0aW9uIElEcyB0byBhIGNsaWVudCwNCiB0aGUgY2xpZW50IHdv dWxkIHNpbXBseSB0ZWFyIGRvd24gdGhlIGNvbm5lY3Rpb24gaWYgaXQgY2hhbmdlZCBuZXR3b3Jr cywganVzdCBhcyBpZiBpdCB3b3VsZCBkbyB0byBUQ1AgY29ubmVjdGlvbnMuIFNvIHdlIGNhbiBz dGlsbCBoYXZlIHRoaXMgJnF1b3Q7bGlzdCBvZiBjb25uZWN0aW9uIElEcyZxdW90OyBmZWF0dXJl IGJlaW5nIG9wdGlvbmFsIHdpdGhvdXQgbmVlZGluZyB0byBlbXBvd2VyIGNsaWVudHMgdG8gdXNl IHRoZSBjb25uZWN0aW9uIElEIGFjcm9zcw0KIG5ldHdvcmsgY2hhbmdlcywgcmlnaHQ/PGJyPg0K Jmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBZZXMsIHRoYXQgd291bGQgYmUgdGhl IGFsdGVybmF0ZSBzdHJhdGVneS4mbmJzcDsgQXQgdGhhdCBwb2ludCwgdGhlIGNsaWVudCBpcyBu b3QgZXhwZWN0aW5nIHRoZSBuZXcgc2VydmVyIHRvIGhhdmUgc3RhdGUsIHNvIGl0IGlzIGV4cGxp Y2l0bHkgZ2l2aW5nIHRoYXQgdXAgdG8gYXZvaWQgbGlua2FiaWxpdHkuPGJyPg0KJmd0Ozxicj4N CiZndDs8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJJ20gYWxzbyBub3QgY29udmluY2VkIHRoYXQgaXQg aXMgJnF1b3Q7bm90IGNvbXBsaWNhdGVkJnF1b3Q7IGZvciBhIHNlcnZlciB0byBiZSBpbiBwb3Nz ZXNzaW9uIG9mIGEgc2V0IG9mIGNvbm5lY3Rpb24gSURzIHRoYXQgd2lsbCBtYXAgYmFjayB0byBp dHNlbGYgaW4gc29tZSBkZXBsb3ltZW50cywgYnV0IEknZCBiZSBoYXBweSB0byBiZSB3cm9uZyE8 YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IFdlbGwsIHRoZXJlIGFyZSBj bGVhcmx5IHByb3ByaWV0YXJ5IHNvbHV0aW9ucyBpbiB0aGlzIHNwYWNlLCBhcyB3ZWxsIGFzIGZh aXJseSBiYXNpYyBtZXRob2RzIG9mIHJhbmdlIGFzc2lnbm1lbnQgd2l0aGluIHRoZSBmdWxsIHBv b2wgdGhhdCB3b3JrIHdpdGggYSBzdGFuZGFyZCBmYW4tb3V0IG9mIHNlcnZlcnMgYmVoaW5kIGEg bG9hZCBiYWxhbmNlci4mbmJzcDsgVGhleSBtYXkgbm90IGNvdmVyIGFsbCBkZXBsb3ltZW50cywg b2YgY291cnNlLjxicj4NCiZndDs8YnI+DQomZ3Q7IHJlZ2FyZHMsPGJyPg0KJmd0Ozxicj4NCiZn dDsgVGVkPGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_BN6PR03MB2708879E1E0CBE7829C1268887560BN6PR03MB2708namp_-- From nobody Tue Feb 28 15:16:56 2017 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 504171297CB for ; Tue, 28 Feb 2017 15:16:55 -0800 (PST) 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 Uhu4N2ZuCQrM for ; Tue, 28 Feb 2017 15:16:53 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d: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 BC4881297E4 for ; Tue, 28 Feb 2017 15:16:53 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id n127so43923392qkf.0 for ; Tue, 28 Feb 2017 15:16:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=D+CNCm66CdIsAty4DwluVHb9zibyDKyC4cbTeNPHIUU=; b=RjydyjLjK2YSy449yPBMOCPub+EZVNfUsUkfPlF7mob7ETH4kMkq5sUzKdt4bKXbxg 0pIh3jsqm+4fEj6V+DaMGMEG60A75kdmwVtvjJD1Aoko7MQ+vSgHXHweoINJ4S3oZYJV qYRBs3oIsI7g9/1wpzn8ntTVOMuBPtgzq5Vvc7nLqmeG52hhIqbzelmd3+5wyUbvAUni 1V4ez4h/CeU1mGMMHg7AagtWiSaBGLGSLC1QT1Y1FWQOUofs68cKNStZJWhd9UKSuD/I TLv7GJzQ19JlAJ5Muqq0LtHgSL50+dyCBiZlzo5uxFWPuasfc1MX1u6OzjcHbQI8Z4OV GPJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=D+CNCm66CdIsAty4DwluVHb9zibyDKyC4cbTeNPHIUU=; b=QFug6zZfQRGtuugZ9ToCV4ltGwEBD0rJ5XcdV++JITRIkye4S6uyYWDybSrE+FDZ/R vYqnP1v0F6D5qtRKhAu756fDivUxCAmeWDM701faFhenG5afcKaRh3AzUgMFZCFDnZ5/ bnsNlG3oiXbbRbsdlGSBAMTezgUaXNyzIUlovjUUPs5JVDNMkqmCc/SoOijUnnGVMRLj HwsYhGWzGnmISbgYo9dkv/7zIO0NatCwCLbwrO75nQI28TFB0Twed7CISMr5j7EBkIY1 Jxd1CBNqNO9In6NhPEIucfEBti2xYMzN8ZEHVjeShlUn9leUqp8VAkB0WrvPqNovdsjT FCgA== X-Gm-Message-State: AMke39kKGZCBl6I712jmANNoWu1YRcpzLMjU6ZdTaltE/dd09j+HHS1DyZklY7B54IdrUxD4LGkqXsztxbKFGA== X-Received: by 10.55.217.16 with SMTP id u16mr6243847qki.144.1488323812354; Tue, 28 Feb 2017 15:16:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 28 Feb 2017 15:16:51 -0800 (PST) In-Reply-To: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> From: Martin Thomson Date: Wed, 1 Mar 2017 10:16:51 +1100 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Ted Hardie , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:16:55 -0000 On 28 February 2017 at 23:00, Mirja K=C3=BChlewind wrote: > I also like this proposal a lot but you can never fully avoid likability = e.g. the client might not be aware that the path/5-tuple has changed. You can avoid linkability if you don't include a connection ID. It just makes recovery from a path change essentially impossible. From nobody Tue Feb 28 15:18:26 2017 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 93344129454 for ; Tue, 28 Feb 2017 15:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 95qL-eRkzJlY for ; Tue, 28 Feb 2017 15:18:22 -0800 (PST) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1AC4129426 for ; Tue, 28 Feb 2017 15:18:22 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3vXvdT2vJGzMr56; Wed, 1 Mar 2017 00:18:21 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVz2w65Wbvli; Wed, 1 Mar 2017 00:18:19 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC2BB4.dip0.t-ipconnect.de [93.236.43.180]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 1 Mar 2017 00:18:19 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Wed, 1 Mar 2017 00:18:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <08E986B4-D1F1-4140-9509-08D3971C6828@tik.ee.ethz.ch> References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> To: Martin Thomson X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Ted Hardie , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 23:18:24 -0000 ...and no packet number and in the best case you don=E2=80=99t expose = anything=E2=80=A6 > Am 01.03.2017 um 00:16 schrieb Martin Thomson = : >=20 > On 28 February 2017 at 23:00, Mirja K=C3=BChlewind > wrote: >> I also like this proposal a lot but you can never fully avoid = likability e.g. the client might not be aware that the path/5-tuple has = changed. >=20 > You can avoid linkability if you don't include a connection ID. It > just makes recovery from a path change essentially impossible. From nobody Tue Feb 28 16:12:07 2017 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 DE51712941C for ; Tue, 28 Feb 2017 16:12:05 -0800 (PST) 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 dR8WzLWyIx6B for ; Tue, 28 Feb 2017 16:12:03 -0800 (PST) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 8E76212944A for ; Tue, 28 Feb 2017 16:12:03 -0800 (PST) Received: by mail-pf0-x233.google.com with SMTP id w189so6084787pfb.0 for ; Tue, 28 Feb 2017 16:12:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=gtgWeyZGjM4f3TJgfjkOm3KkdLJlNwfCZD4E9QKERxg=; b=l7D/0hxfDj4BrizWJY9ytibxUbg2KIzNDMyV3OQfvCQTRfgkQFVQ0rZVJwJf8B3avr QvDBPQTh+/GWJ4+QMR9o3hCbhsEPbN71JX13BmKIqZqI6mU023q34zirAYJurGddMp2q PH9FsoLXQqsPu0SkZdr7Q079ZzO9C48CdGo+mpLtu+if7aT7A4ccyFiTHN7Hk5OgioDU Nh9jAYGM4GgqmPIIxOB58nz+jcjfrgtZk2v+mSs4c01vXgAHz81/WafIaujpZ/m4PZTv D6lOzJa7ThHajuMd3W65fo8lN96k/wdXJ/1iFa49xgozRLR4c3AH/JoPBAk8r8le6g1F kBOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=gtgWeyZGjM4f3TJgfjkOm3KkdLJlNwfCZD4E9QKERxg=; b=opBipkzfegv8U0AAVQMD4SfDaA778+EIAvsY3LejGcd2yax8tWn3UHL4VrAdeY/EUd q/w3mH/nteptw15v5HBhMSA/EvtWYeauyV4YEbavmHzddcACkbUAztxfAvQJ2wpIkoVr 4sv3jxUWtlMkpFR8LhxPtXHne5zhhtk7W40yvlgHXYGSInGd/gTvnbvaAJbBnr+yd5tu oJ9u5r4vcu6vI9IpUMqiw2I5+L+6ZLzdfeCRdpE/bfP+hBdm0++g9aCjLShBS5lzRxQ0 UdaVn7E7rFn0BGUUq180PcKB+AWXSh3JSjrYmnKLQUYk6BZuF4xbE1KOPy0S/uu3SkKu H26g== X-Gm-Message-State: AMke39nYR/XiAAWCe0fiF5PZ7byoJqpy9eyfb0DEpFgpXRoumFbmnCD/8gZHArL2i0Vd2aqnCpWsPjtEDFXcKQ== X-Received: by 10.99.45.3 with SMTP id t3mr5594618pgt.162.1488327122941; Tue, 28 Feb 2017 16:12:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.149.13 with HTTP; Tue, 28 Feb 2017 16:12:02 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Wed, 1 Mar 2017 09:12:02 +0900 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Ryan Hamilton Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 00:12:06 -0000 2017-02-28 9:30 GMT+09:00 Ryan Hamilton : > Howdy All, > > I just filed issue #349 to resolve how server-chosen connection IDs are to > be used. To save a click, here's what I wrote there: > > -------------------- > My sense is that we'd like the server to chose the "real" connection ID to > be used for a connection. Among other things, this enables servers to embed > routing/load balancing information into connection IDs. > > I have heard two options for what the client should do before it has a > server-chosen connection ID. > > 1. Send a random connection ID > 2. Send a connection ID of 0 > > If we go with approach 1, then we need some mechanism that load balancers > can use to detect if a packet's connection ID is server-chosen or not. It > seems likely that all packets encrypted with 1-RTT keys could use server > generated connection IDs. But other packets it's not so clear. Consider the > case of a non-0-RTT handshake. The initial client handshake packet would > include a client-chosen connection ID. When the server replies, it could use > a server-chosen connection ID. If so then when the client sends the next > handshake packet it could use the server-chosen connection ID as well. But > that means that we'd need a mechanism to disambiguate client handshake > packets with client-chosen connection IDs from client handshake packets with > server-chosen connection IDs. We could devote bits or packet types to > indicate this. I suspect the same argument might hold for server handshake > packets. We might not want the server to chose a connection ID until it is > ready to accept the handshake. > > One benefit of this approach, however, is that a QUIC server could chose to > simply use the client's connection ID for the duration of the connection. > This would mean that it would not need to be able to generate a new > connection ID that is guaranteed to be sent by the load balancer back to > itself. In cases where the vendor of the load balancer and the server are > not the same, this might be valuable. >From the standpoint of a server developer without having the control of the load balancer that would be used together, I'd be more concerned if the server could be used together with a traditional load balancer that only does balancing based on the 5-tuple. Interoperability with such load balancers is inevitable (if not preferable), and I would rather not want to support another kind of load balancer that routes the packets using the connection ID, especially in case it cannot route the packets accurately (i.e. when 5-tuple changes or when client starts using a new connection ID due to a noticeable IP address change). For servers running behind a load balancer using 5-tuple, it would be a requirement to route packets that arrive at the wrong server to the correct server (in terms of a QUIC connection). I do not think that requirement (i.e. communication between the QUIC servers behind a load balancer) would be an issue, considering the fact that some (if not many) of TLS decryptors (e.g. haproxy) are doing that already for sharing the TLS session cache. > If we go with approach 2, then it's obvious that any packet with a non-zero > connection ID has a server-chosen connection ID (though the server still may > want to verify that it's a "valid" connection ID according to the algorithm > it uses). > > On the other hand, this requires QUIC servers which are behind load > balancers to be able to generate connection IDs which the load balancer will > route back to them. If the server and load balancers are from different > vendors, this might be challenging. > -------------------- > > I look forward to your thoughts. > > Cheers, > > Ryan -- Kazuho Oku From nobody Tue Feb 28 16:33:33 2017 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 D6BED1297F7 for ; Tue, 28 Feb 2017 16:33:31 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 s95V-DgcEibC for ; Tue, 28 Feb 2017 16:33:30 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BCF91297A7 for ; Tue, 28 Feb 2017 16:33:30 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id v186so98171404wmd.0 for ; Tue, 28 Feb 2017 16:33:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=aFLtFYBU3YRGg1i96bzOuJsE3gsNdvqh38rnXx7bAYU=; b=Sw4TPo3JIN9GUEVuIpYwDOQew4jWoNen/kU9qrmZYmlZrIe5cfTLLO86qLr4AMnwJh vW2hG52MYVnWXtjGCR6VIJPrkNUqvz3ngf24+K+mYMVEhwRkELQguveqHVb3ilbjtfu/ tdKcAm83lmz1Mj7ua1wUvTNrn9ME7/KtOv5E9WzhnlEFrsjm+RBEQF+1lwVytMMitjBd XckYFIOIM4e/rrJClLqIsMFpOtPOZCLyMXZW/pKlD0ObmOA8Dpsp9a5nxpQD/JOJZQXt gZlZp7jY2xob+F+tYASbr1I0VjfM3/w21EpUUYNw4OQRYpamNkh4aO4XwCGm8c2t7VVV YjaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aFLtFYBU3YRGg1i96bzOuJsE3gsNdvqh38rnXx7bAYU=; b=Z7LbluCkH2b3etfdT1nKPDTMiJGP3kLN77D3YyA/KoL7gfBQxEx8ZvQI5G2wW8/c2+ 14yV+ANjDkfFK/b7zpl9lp9QvJ21pKVbmDz7Qa44cknPAl/9ukjaPrLmw+5julUPuH1/ gQrE9paWcn4h1LGluTqkRroRhMibbz1QS6IKzK6DUC/vl934lV9XDt6C0WUkazuZq3u7 nfrtZQfVE4+GJU+gzki27/CA5yagEGR1IqsAWgBuekTuh3TprtZ0y+1BP7zSW/60zzqk BKvfpRlULEZJTaba22W20lNGK97zBQAJ7In1Fvp7GcUv/8hc3BwnzAKZD2z4686T9A1G EVtA== X-Gm-Message-State: AMke39l6Z1Nzu4j9pEapnBkXVW6Z4Q7mf2lad8kIDSBZhvyjP/v1oDUaDZOWS9FySANK7pfwPQuSK0ahOF1EMIUa X-Received: by 10.28.105.68 with SMTP id e65mr911737wmc.44.1488328408364; Tue, 28 Feb 2017 16:33:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Tue, 28 Feb 2017 16:33:27 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Tue, 28 Feb 2017 16:33:27 -0800 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Kazuho Oku Content-Type: multipart/alternative; boundary=001a1147c81a1762ab0549a076cd Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 00:33:32 -0000 --001a1147c81a1762ab0549a076cd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2017 at 4:12 PM, Kazuho Oku wrote: > From the standpoint of a server developer without having the control > of the load balancer that would be used together, I'd be more > concerned if the server could be used together with a traditional load > balancer that only does balancing based on the 5-tuple. > =E2=80=8BKeep in mind that =E2=80=8BNAT boxes will occasionally re-bind the= user's source port in the middle of a QUIC connection. So if the load balancer only does 5 tuple hashing, that load balancer will not be able to handle NAT rebinding. Since it's (effectively) not possible to prevent these from happening, it's not clear to me that 5-tuple only hashing works for QUIC. --001a1147c81a1762ab0549a076cd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 28, 2017 at 4:12 PM, Kazuho Oku <kazuhooku@gmai= l.com> wrote:
From the standpoint of a server d= eveloper without having the control
of the load balancer that would be used together, I'd be more
concerned if the server could be used together with a traditional load
balancer that only does balancing based on the 5-tuple.

=E2=80=8BKeep in mind that =E2=80=8BNAT boxes will= occasionally re-bind the user's source port in the middle of a QUIC co= nnection. So if the load balancer only does 5 tuple hashing, that load bala= ncer will not be able to handle NAT rebinding. Since it's (effectively)= not possible to prevent these from happening, it's not clear to me tha= t 5-tuple only hashing works for QUIC.
--001a1147c81a1762ab0549a076cd-- From nobody Tue Feb 28 16:44:33 2017 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 9065812950F for ; Tue, 28 Feb 2017 16:44:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_f5JQyQ3P0k for ; Tue, 28 Feb 2017 16:44:29 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::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 B08F9126DFB for ; Tue, 28 Feb 2017 16:44:29 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id s186so46398826qkb.1 for ; Tue, 28 Feb 2017 16:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=pECPDpyRsxN8/+Ovpt0/sCAKanQP0fUdxVFeOFUPwTo=; b=RUC1yvwTBwizlxir+nniaGdvdqnvrQ8X8sVLHns8awFt+Td3SRach+TJuwOCFpLUOR 7Yssz3A68iaBkgQuo5KaR0Yf+eYJho3LoPYk9I9vY4vhpjrWBpCGOeE/zuRCFYGGmiYd bduoFdSpcGlUnmMinqVNU2baAnqioyQX4AtACdZNa1kptUXrYLhEZO3rYCAfQiIyDLNy DSnkrZmN4kMtF4Pcki+Eyx8qOHpeRgyEt8Wz3XNdlDZpm0KSnJWJdi26uWS26qfgyNxA 7hwCPYMyM3ko9WMLHttWwbqrOo7JkPtb76Ho76v0VuHPJJGXTQGtnYMvaWDnCEJBch9j j1oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=pECPDpyRsxN8/+Ovpt0/sCAKanQP0fUdxVFeOFUPwTo=; b=Hhckq5CYD8UioTc+mpibjAjFgd3WQfQJkw0ZfPWIW1kM2ifvTC+lWvKE2sU5logJ0D YttNa3cjSs2xWD0hF+Tg+OaR0mYmqS5L8bVn7Yljed1Eg3xBAIulfUm2rlIG9uCMTcpL FlWoDGD/XrG8eZyvMSxO2GsUieQANIHkpR/RDYMR+gTYnI66iZMTEEKZ7iaJ7jpI9jWz V1u/BlKboouAWkXj7tf8kEyJa0Us+dYAdpOLnwoWYfJdlx1hki7X5B973EcsHCgeDw5w p6QwC0/gJXMHwwwpuEc8PcA1l1+LUOPaPV8QDylJQQsWS6A3hUzLzYBs+I5CxyIoErpu FzFg== X-Gm-Message-State: AMke39m58cxJN+8/fWAhR4GJ94PLJrjFpxpS71qtjc8AYbJ//QTLMsSWIem3XjLzXFGhldKj3oUiC05JX4zoTg== X-Received: by 10.233.216.68 with SMTP id u65mr6370385qkf.68.1488329068860; Tue, 28 Feb 2017 16:44:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 28 Feb 2017 16:44:28 -0800 (PST) In-Reply-To: <618be199a45448b093a7ae0a03539e54@usma1ex-dag1mb5.msg.corp.akamai.com> References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> <618be199a45448b093a7ae0a03539e54@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Wed, 1 Mar 2017 11:44:28 +1100 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: "Lubashev, Igor" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mike Bishop , Ted Hardie , Kyle Rose , Ryan Hamilton , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 00:44:31 -0000 On 1 March 2017 at 07:39, Lubashev, Igor wrote: > Kyle, so you are thinking of some Rolling Code to replace ConnectionIDs > after a 1-RTT handshake? That=E2=80=99s an interesting idea, though it m= ay be > difficult for Servers to tell apart completely martian packets (unknown > connections) vs very delayed packets (this makes a difference in whether = to > RST the connection or drop the packet). I considered using a PRP (pseudo-random function) for generating new connection IDs. It doesn't work. The need for it to be known to the client means that you need to have a different PRP (or a different PRP key) for every client - otherwise clients could guess the next value in the sequence for any other client (linkability is broken). With many clients, avoiding collisions in that case would be foolish. From nobody Tue Feb 28 16:46:04 2017 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 CD33212950F for ; Tue, 28 Feb 2017 16:46:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LKscg6jNgyhR for ; Tue, 28 Feb 2017 16:46:01 -0800 (PST) Received: from mail-pg0-x232.google.com (mail-pg0-x232.google.com [IPv6:2607:f8b0:400e:c05::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 4B7CA126DFB for ; Tue, 28 Feb 2017 16:46:01 -0800 (PST) Received: by mail-pg0-x232.google.com with SMTP id s67so12981002pgb.3 for ; Tue, 28 Feb 2017 16:46:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lIyIKm3ewR2na8OEeaEOaU6Ah3f7S20fD52YK0sB2O4=; b=WtcerH3hjDlr8Hly++pF+ljbXqnUOQxDwrO+ypjCYTAp7LHQbZVl6RXT2c5CKv3cey JlRyvZDKL3j7rW6QIgk/Hk4gnEqH8PuowM/YRcYf/ZuUUmpM4QHzMgOZN3zZo9PTvZ+2 X4I7li84eKKo5+yKe7eYePJhr0K2aavvfJ5SYjlg9JXNirA0j0JQ1OZdVg7eFTLANpMi dcxd0GniOm6WzszVOByYhewIWoIJk4IuL+l3hPIJiHxttBkPZUGelJ2BqTlZchiG/z+E 9AdpZ7OaMnMKNVJMdbOwgT1Cgn8LGZAIGb1uic/qShcuIAiX/fnqzAERLGWhA6PpAumZ Q07A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lIyIKm3ewR2na8OEeaEOaU6Ah3f7S20fD52YK0sB2O4=; b=tqgk9wHFSTRDNpj50RsRuF++ysJcGzc5BXy6ZkFXEX3BRyRuDjDxKu9Lmib5CbuNKS Xupb8eNu3zFXDvpHDcChg2NYiRSi5Ak2keo26XcKLLf9Guwi/4bqhYuSvIhhG63ZWiOE IbT9Iyc6Qf372NaKP5TTFe340X4ZLlya4ShkKtLwLvQjI/BzSGmeJoiEL71xOq/ef8a1 9J5/FcIImP5H5JNg3+4cKLgE+ABeiE5aZZWV81ZYG9vYoVA0IfzmLBx7lhoYeLuPw6iq 5x7PoSEEyLh+DZIYmc4eUENwjDRNRT3mBIPSpT3tbDeqCrzk6eb/D5pFikzIbRjDWJR7 8KJQ== X-Gm-Message-State: AMke39n594WBObPwPOF5pHe25UbqQIBrZ6TwXTZy2Kzb87rQuiEObagdjwv7kRyz/xeIUKLikbjT4FdENcsePA== X-Received: by 10.98.104.4 with SMTP id d4mr5745209pfc.2.1488329160839; Tue, 28 Feb 2017 16:46:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.149.13 with HTTP; Tue, 28 Feb 2017 16:45:59 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Wed, 1 Mar 2017 09:45:59 +0900 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Ryan Hamilton Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 00:46:03 -0000 2017-03-01 9:33 GMT+09:00 Ryan Hamilton : > On Tue, Feb 28, 2017 at 4:12 PM, Kazuho Oku wrote: >> >> From the standpoint of a server developer without having the control >> of the load balancer that would be used together, I'd be more >> concerned if the server could be used together with a traditional load >> balancer that only does balancing based on the 5-tuple. > > > Keep in mind that NAT boxes will occasionally re-bind the user's source port > in the middle of a QUIC connection. So if the load balancer only does 5 > tuple hashing, that load balancer will not be able to handle NAT rebinding. > Since it's (effectively) not possible to prevent these from happening, it's > not clear to me that 5-tuple only hashing works for QUIC. My understanding is that when a NAT rebinding occurs it is likely that load balancers relying on 5-tuple would start directing packets to the wrong server. In such case, a QUIC server running behind the load balancer would be required to route such packets (arriving at the wrong server) to the correct server. The correct server can send the responding packets directly to the client. This might sound inefficient, but I think it would not be a huge issue assuming that the possibility of a NAT rebinding happening mid-connection is not high. Also, for HTTP over QUIC at least, a server can gracefully tear down the connection (i.e. stop accepting new requests and close the connection after sending all the responses in-flight) so that the client would eventually switch to a newly established connection. -- Kazuho Oku From nobody Tue Feb 28 16:49:00 2017 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 6B80F127078 for ; Tue, 28 Feb 2017 16:49:00 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 zDA8Si9lqt9F for ; Tue, 28 Feb 2017 16:48:59 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id DEB6C126DFB for ; Tue, 28 Feb 2017 16:48:58 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 89ABB20001B; Wed, 1 Mar 2017 00:48:58 +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 64B6320000D; Wed, 1 Mar 2017 00:48:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488329338; bh=kykLnYYTFs51PVe/vToyUxV7L8QZ0+kFhrWPfBAQGMU=; l=13018; h=From:To:CC:Date:References:In-Reply-To:From; b=WEMVoNTEiXGAYqD1JPOzFGO7SRnOP46Gw+/tRiOWrqt0Zk77vmDrqDl0Jy3xevjZL 5iTZfGubM5Ojm7GWcdcxGxEFCJ0yipf/HAquACQEx3fQaYm3DZY0JhrD+wOxWzc0+A 6W1QVvH+VMQirKHaNtEr+hLMeTxclf1eIxrcy5Lk= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 020DB1E080; Wed, 1 Mar 2017 00:48:58 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Feb 2017 19:48:57 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Tue, 28 Feb 2017 19:48:57 -0500 From: "Lubashev, Igor" To: Kazuho Oku , Ryan Hamilton Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnUFyvCyJf5LkySP9zxgM+hCaF/cgQA//+yctA= Date: Wed, 1 Mar 2017 00:48:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.129] Content-Type: multipart/alternative; boundary="_000_a207ff9c94924368aeb8de608094f9cfusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 00:49:00 -0000 --_000_a207ff9c94924368aeb8de608094f9cfusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T24gVHVlLCBGZWIgMjgsIDIwMTcgYXQgNDoxMiBQTSwgS2F6dWhvIE9rdSA8a2F6dWhvb2t1QGdt YWlsLmNvbTxtYWlsdG86a2F6dWhvb2t1QGdtYWlsLmNvbT4+IHdyb3RlOg0KDQoNCg0KRm9yIHNl cnZlcnMgcnVubmluZyBiZWhpbmQgYSBsb2FkIGJhbGFuY2VyIHVzaW5nIDUtdHVwbGUsIGl0IHdv dWxkIGJlIGEgcmVxdWlyZW1lbnQgdG8gcm91dGUgcGFja2V0cyB0aGF0IGFycml2ZSBhdCB0aGUg d3Jvbmcgc2VydmVyIHRvIHRoZSBjb3JyZWN0IHNlcnZlciAoaW4gdGVybXMgb2YgYSBRVUlDIGNv bm5lY3Rpb24pLiBJIGRvIG5vdCB0aGluayB0aGF0IHJlcXVpcmVtZW50IChpLmUuIGNvbW11bmlj YXRpb24gYmV0d2VlbiB0aGUgUVVJQyBzZXJ2ZXJzIGJlaGluZCBhIGxvYWQgYmFsYW5jZXIpIHdv dWxkIGJlIGFuIGlzc3VlLCBjb25zaWRlcmluZyB0aGUgZmFjdCB0aGF0IHNvbWUgKGlmIG5vdCBt YW55KSBvZiBUTFMgZGVjcnlwdG9ycyAoZS5nLiBoYXByb3h5KSBhcmUgZG9pbmcgdGhhdCBhbHJl YWR5IGZvciBzaGFyaW5nIHRoZSBUTFMgc2Vzc2lvbiBjYWNoZS4NCg0KDQoNCk5vdCBhbGwgbG9h ZCBiYWxhbmNlcnMgYXJlIGZyb250aW5nIGJhY2tlbmQgc2VydmVycyBpbiBhIHNpbmdsZSBwb3Au IFdlIGhhdmUgbG9hZCBiYWxhbmNlcnMgdGhhdCBhcmUgZnJvbnRpbmcgc2VydmVycyBkaXN0cmli dXRlZCBhY3Jvc3MgdGhlIGNvbnRpbmVudC4gSXQgd291bGQgbm90IGJlIGZlYXNpYmxlIHRvIHN5 bmMgc3RhdGUgb2YgYWxsIGNvbmN1cnJlbnQgY29ubmVjdGlvbnMgYWNyb3NzIGdlb2dyYXBoaWNh bGx5IGRpc3BlcnNlZCBwb3BzLiBJbiBmYWN0LCBldmVuIHdpdGhpbiBhIHBvcCBJIHdvdWxkIHBy ZWZlciBiYWNrZW5kIHNlcnZlcnMgdG8gY29udGludWUgTk9UIHN5bmNpbmcgc3RhdGVzIG9mIGNv bm5lY3Rpb25zIChldmVuIGlmIHNvbWUgcG9wdWxhciBsb2FkIGJhbGFuY2VyIGltcGxlbWVudGF0 aW9ucyBkbyBpdCkuDQoNCg0KDQpBcyBpdCB3YXMgc2FpZCBlYXJsaWVyLCBpZiB5b3UgaGF2ZSBh IG1pZGRsZSBib3ggKGxvYWQgYmFsYW5jZXIpIHRoYXQgaXMgbm90IGNvb3BlcmF0aW5nIHdpdGgg dGhlIHNlcnZlciwgdGhlbiBlaXRoZXI6DQoNCmEuICAgICAgIFlvdSBjYW5ub3Qgc3Vydml2ZSBO QVQgcmViaW5kaW5nIC8gbmV0d29yayBtaWdyYXRpb24sIG9yDQoNCmIuICAgICAgIFlvdXIgbWlk ZGxlIGJveCBpcyBRVUlDLWF3YXJlLCBidXQgdG8gc3Vydml2ZSBOQVQgcmViaW5kaW5nIC8gbmV0 d29yayBtaWdyYXRpb24sIHlvdXIgUUlVQyBpbXBsZW1lbnRhdGlvbiBtdXN0IGxlYWsgQ29ubmVj dGlvbklkIG9udG8gdGhlIG5ldyBwYXRoDQoNCg0KDQotICAgICAgICAgIElnb3INCg== --_000_a207ff9c94924368aeb8de608094f9cfusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoyMjE0MTAxNzQ7DQoJbXNvLWxpc3Qt dHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1NTcyOTY4MjQgNjc2OTg3MTMg Njc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVs NA0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30N CkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJp Z2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZl bDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWlu ZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NzkxMjQ2MTU0Ow0KCW1zby1s aXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMzc2OTY0MzIyIC05Nzcy MDc5MjYgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2 ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3Qt Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJn aW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwgRmViIDI4 LCAyMDE3IGF0IDQ6MTIgUE0sIEthenVobyBPa3UgJmx0OzxhIGhyZWY9Im1haWx0bzprYXp1aG9v a3VAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFuayI+a2F6dWhvb2t1QGdtYWlsLmNvbTwvYT4mZ3Q7 IHdyb3RlOjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj5Gb3Igc2VydmVycyBy dW5uaW5nIGJlaGluZCBhIGxvYWQgYmFsYW5jZXIgdXNpbmcgNS10dXBsZSwgaXQgd291bGQgYmUg YSByZXF1aXJlbWVudCB0byByb3V0ZSBwYWNrZXRzIHRoYXQgYXJyaXZlIGF0IHRoZSB3cm9uZyBz ZXJ2ZXIgdG8gdGhlIGNvcnJlY3Qgc2VydmVyIChpbiB0ZXJtcyBvZiBhIFFVSUMgY29ubmVjdGlv bikuIEkgZG8gbm90IHRoaW5rIHRoYXQNCiByZXF1aXJlbWVudCAoaS5lLiBjb21tdW5pY2F0aW9u IGJldHdlZW4gdGhlIFFVSUMgc2VydmVycyBiZWhpbmQgYSBsb2FkIGJhbGFuY2VyKSB3b3VsZCBi ZSBhbiBpc3N1ZSwgY29uc2lkZXJpbmcgdGhlIGZhY3QgdGhhdCBzb21lIChpZiBub3QgbWFueSkg b2YgVExTIGRlY3J5cHRvcnMgKGUuZy4gaGFwcm94eSkgYXJlIGRvaW5nIHRoYXQgYWxyZWFkeSBm b3Igc2hhcmluZyB0aGUgVExTIHNlc3Npb24gY2FjaGUuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPk5vdCBhbGwgbG9hZCBiYWxhbmNlcnMgYXJlIGZyb250aW5nIGJhY2tlbmQgc2VydmVy cyBpbiBhIHNpbmdsZSBwb3AuIFdlIGhhdmUgbG9hZCBiYWxhbmNlcnMgdGhhdCBhcmUgZnJvbnRp bmcgc2VydmVycyBkaXN0cmlidXRlZCBhY3Jvc3MgdGhlIGNvbnRpbmVudC4gSXQgd291bGQgbm90 IGJlIGZlYXNpYmxlIHRvIHN5bmMgc3RhdGUgb2YgYWxsIGNvbmN1cnJlbnQgY29ubmVjdGlvbnMg YWNyb3NzIGdlb2dyYXBoaWNhbGx5DQogZGlzcGVyc2VkIHBvcHMuIEluIGZhY3QsIGV2ZW4gd2l0 aGluIGEgcG9wIEkgd291bGQgcHJlZmVyIGJhY2tlbmQgc2VydmVycyB0byBjb250aW51ZSBOT1Qg c3luY2luZyBzdGF0ZXMgb2YgY29ubmVjdGlvbnMgKGV2ZW4gaWYgc29tZSBwb3B1bGFyIGxvYWQg YmFsYW5jZXIgaW1wbGVtZW50YXRpb25zIGRvIGl0KS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu VGV4dCI+QXMgaXQgd2FzIHNhaWQgZWFybGllciwgaWYgeW91IGhhdmUgYSBtaWRkbGUgYm94IChs b2FkIGJhbGFuY2VyKSB0aGF0IGlzIG5vdCBjb29wZXJhdGluZyB3aXRoIHRoZSBzZXJ2ZXIsIHRo ZW4gZWl0aGVyOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUi PmEuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3NwYW4+PCFbZW5k aWZdPllvdSBjYW5ub3Qgc3Vydml2ZSBOQVQgcmViaW5kaW5nIC8gbmV0d29yayBtaWdyYXRpb24s IG9yPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0IiBzdHlsZT0ibWFyZ2lu LWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIiPg0K PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Yi48c3Bh biBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+WW91 ciBtaWRkbGUgYm94IGlzIFFVSUMtYXdhcmUsIGJ1dCB0byBzdXJ2aXZlIE5BVCByZWJpbmRpbmcg LyBuZXR3b3JrIG1pZ3JhdGlvbiwgeW91ciBRSVVDIGltcGxlbWVudGF0aW9uIG11c3QgbGVhayBD b25uZWN0aW9uSWQgb250byB0aGUgbmV3IHBhdGg8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0Omwx IGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOw0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SWdvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_a207ff9c94924368aeb8de608094f9cfusma1exdag1mb5msgcorpak_-- From nobody Tue Feb 28 16:54:04 2017 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 33B631293D9 for ; Tue, 28 Feb 2017 16:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 O62DKx8iHDUQ for ; Tue, 28 Feb 2017 16:54:02 -0800 (PST) Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::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 BC4A3126DFB for ; Tue, 28 Feb 2017 16:54:01 -0800 (PST) Received: by mail-wr0-x22f.google.com with SMTP id g10so19805400wrg.2 for ; Tue, 28 Feb 2017 16:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=K2Ql5TBVqB28OSKmRYx8yvmAykfG96MZwiRACPIkEu0=; b=PlwHwnUNObYqfY2Crb95+ETnMRl/mntX4sGtPQHmv7Qdq+v3nTCGeGdaHrdWxwtAf8 9j/GBwKsK+ETL9dEd2Y44FjrChtmbLv8QMhTyDrCcwRwCIg7Cd4iWAMxHZJmGo1VVmet OVm3TFLC6ubD9ma4n6BLWBrOghx4ZLkH4gLWEc6qUQ6pR7Kxoweeby3Sa2z3A6A4IRJo osMsaL1quwTiEau1quE5bu8yTMrpWmiUa/a0Lhq5rXmu22cCFBwzuR7Po2TP1AwI9VxJ cP6v0AJNJkcXCr35c4RbVswJL+wPV72Knx/khlNaBdY+b1Cj+Bz+Pg+FkpGvMEFxFYYW Zn3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=K2Ql5TBVqB28OSKmRYx8yvmAykfG96MZwiRACPIkEu0=; b=Csj+kmVOBaOtKsX2CyKWreAP8gT/8c94RVCMHmadlxaSz6ipm2zwGpSLAOf7njTd9B SOmuB7WTzd4jH7GfCb+BzNPd5s3qSXtX5xiaLUjQ07ourf+RMGs0HA/vII1kLrATGxB5 Z/fVfqBFVHZK+2Undzkk7sOQXiIOa+NZa7OAB2U1SRsKPzlk3xqdny5K5ZoI+IC+fOha iCG7dCQ7veo80o9kwQ60Cmg3Dp9HqijkScCcmTMnnLBKrnqVtFqS4bQP6+pbWWDOsqmO 1LvheqcbAg9/OHGPGslDqQSscjo53XjXsFideXTGrQTD1cwchJitlfjOa4TrJ0s/n+bB O7vg== X-Gm-Message-State: AMke39mhUCxif+W0pqraXDOKrpUGVxF9EiNPT6YvE1Irn+yRlI+gel76USmyGIioMqWj/6NIDejMYDMdbhLJIR6d X-Received: by 10.223.131.103 with SMTP id 94mr4454410wrd.115.1488329640133; Tue, 28 Feb 2017 16:54:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Tue, 28 Feb 2017 16:53:59 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Tue, 28 Feb 2017 16:53:59 -0800 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Kazuho Oku Content-Type: multipart/alternative; boundary=94eb2c0d204082adb90549a0bfe6 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 00:54:03 -0000 --94eb2c0d204082adb90549a0bfe6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2017 at 4:45 PM, Kazuho Oku wrote: > My understanding is that when a NAT rebinding occurs it is likely that > load balancers relying on 5-tuple would start directing packets to the > wrong server. > > In such case, a QUIC server running behind the load balancer would be > required to route such packets (arriving at the wrong server) to the > correct server. The correct server can send the responding packets > directly to the client. > =E2=80=8BHow would a server know which server to redirect this packet to?= =E2=80=8B --94eb2c0d204082adb90549a0bfe6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 28, 2017 at 4:45 PM, Kazuho Oku <kazuhooku@gmai= l.com> wrote:
My understanding is that when a NA= T rebinding occurs it is likely that
load balancers relying on 5-tuple would start directing packets to the
wrong server.

In such case, a QUIC server running behind the load balancer would be
required to route such packets (arriving at the wrong server) to the
correct server. The correct server can send the responding packets
directly to the client.

=E2=80= =8BHow would a server know which server to redirect this packet to?=E2=80= =8B
--94eb2c0d204082adb90549a0bfe6-- From nobody Tue Feb 28 17:04:33 2017 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 A8FD01293F9 for ; Tue, 28 Feb 2017 17:04:31 -0800 (PST) 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 q5pazf4LmTwu for ; Tue, 28 Feb 2017 17:04:30 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::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 63EA01293DA for ; Tue, 28 Feb 2017 17:04:30 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n186so45706922qkb.3 for ; Tue, 28 Feb 2017 17:04:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FqR7Hkw57iIIHOoZqUpao732BQolaE8Fvo/oZLfQU2Q=; b=Yomx4UCetYDE31kdD4M4dPWEe1jH8mzR8HNtuqGuOJTyGlxirI3R7+WJYFrG+NUSu4 1jqUzE6P9VClCjjWlG9tBjsS6m66hA2HfUIyvVHbTsVIfQAPzbPl8f94eBrroVRxqi4G iuGz5hN0z4ZZbDWPUU1yz2cBjNOFBcVfuIDdGXldktJ4GarNDR57v9v+vVzUast3xLYf beCgxXZ1i6yhvaPZWM+p3LEQzawWkHVPifq+2ThaoKYBfQKXwYa/YvqyG7rP/EmxuSJ5 JpxehStmcdtCRZJrf82MMFtl++vgug8+FKmRjn7q/o6N1MhfQe0tkJWztOANwJuHLmVG hA1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FqR7Hkw57iIIHOoZqUpao732BQolaE8Fvo/oZLfQU2Q=; b=Yfvx9n2B0St00lQTn5huCTuFT+D+4mqvv8zDBK+jZjlfUof5VOV45ughTmthATgRxK JpKx4slQsj6vdGQTx5lmtjzGJXS7ZlN7/hej/VMcf3V5TL8TZUEF2VAQTsWPkacH9mOj JRwxQcnl8WosUWvTXUMa9dHQIfrRmbcQPITSAi+c4mpo4g8tSHbB5868gHpi7alTsjei tb610p3qqS0r6GoGQfhpwhZXCZRyf2tn3M4DwE0i10joQ4aP66HCtH8qWGq/XdU/zA+A pQ3E62QlXnJAhPYUSJzFoL4RGmpxU5O5U1H5nKqVVgB3Wkjub5zCPIvX8ti36pITDoaf 3y+w== X-Gm-Message-State: AMke39lrFhUj+yMl+MgdHBZscRCYa7VBTKCSqr1kCFEjvgMikVlJtUXNxHbdL7LNJeosm/gKUJM/T/q8VNEB6g== X-Received: by 10.237.41.100 with SMTP id s91mr6930143qtd.143.1488330269492; Tue, 28 Feb 2017 17:04:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 28 Feb 2017 17:04:28 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 1 Mar 2017 12:04:28 +1100 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Ryan Hamilton Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG , Kazuho Oku X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:04:31 -0000 On 1 March 2017 at 11:53, Ryan Hamilton wrote: >> In such case, a QUIC server running behind the load balancer would be >> required to route such packets (arriving at the wrong server) to the >> correct server. The correct server can send the responding packets >> directly to the client. > > > How would a server know which server to redirect this packet to? I assume that the server would have more state than the load balancer. From nobody Tue Feb 28 17:05:13 2017 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 371981293DA for ; Tue, 28 Feb 2017 17:05:11 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 UNOCsZqlbkbR for ; Tue, 28 Feb 2017 17:05:09 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6591293F9 for ; Tue, 28 Feb 2017 17:05:09 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 06427433415; Wed, 1 Mar 2017 01:05:09 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id D9C6B43340D; Wed, 1 Mar 2017 01:05:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488330308; bh=xYeO8xQJU5Q9JU/rnkXjmvjBd+g2u6tixIr0XptJ3fo=; l=2242; h=From:To:CC:Date:References:In-Reply-To:From; b=sx7ftnbA0CDOl0Phs3rAheemD0Debv3FKY8cc5NbdGe7mc9uTKGErBd9jF04ROynS ccLZUzuy2PKN50w8tN9pWQCqrzn/7U0j+M13Mnve8d2ju/IhlHPpeLqA6+ZNmpPQ35 VSmO/I5ltFSgBa1TrkEWCvvg0xatCbSw055r8GSg= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id D45D61FC92; Wed, 1 Mar 2017 01:05:08 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Feb 2017 20:05:08 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Tue, 28 Feb 2017 20:05:08 -0500 From: "Lubashev, Igor" To: Martin Thomson Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnUFyvCyJf5LkySP9zxgM+hCaF972KAgAAA8YCAALU8gIAATWEAgAAa8ICAABKLgIAABbOAgAAHEQCAAAVQgP//rmoQgACaKwD//688oA== Date: Wed, 1 Mar 2017 01:05:07 +0000 Message-ID: References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> <618be199a45448b093a7ae0a03539e54@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Mike Bishop , Ted Hardie , Kyle Rose , Ryan Hamilton , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:05:11 -0000 VG8gZWxhYm9yYXRlIG9uIEt5bGUncyBpZGVhLCB0aGUgaW5pdGlhbCBDb25uZWN0aW9uSUQgd291 bGQgYmUgc2VsZWN0ZWQgYXMgZGVzY3JpYmVkLCB0aGVuIGNsaWVudCBhbmQgc2VydmVyIHdvdWxk IG5lZ290aWF0ZSBzb21lIHNlY3VyZSBjb25uZWN0aW9uIG5vbmNlLCBhbmQgdGhlIHN1YnNlcXVl bnQgQ29ubmVjdGlvbklEIHdvdWxkIGJlIGhhc2gobm9uY2UsIHBhY2tldCMpLiAgTm9uY2UgaXMg YSBwZXItY29ubmVjdGlvbiBzZWNyZXQsIHNvIGhhc2gobm9uY2UsIHgpIGNhbm5vdCBiZSBwcmVk aWN0ZWQuDQoNCi0gSWdvciANCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog TWFydGluIFRob21zb24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDog VHVlc2RheSwgRmVicnVhcnkgMjgsIDIwMTcgNzo0NCBQTQ0KVG86IEx1YmFzaGV2LCBJZ29yIDxp bHViYXNoZUBha2FtYWkuY29tPg0KQ2M6IEt5bGUgUm9zZSA8a3Jvc2VAa3Jvc2Uub3JnPjsgTWly amEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD47IE1pa2UgQmlz aG9wIDxtaWNoYWVsLmJpc2hvcEBtaWNyb3NvZnQuY29tPjsgVGVkIEhhcmRpZSA8dGVkLmlldGZA Z21haWwuY29tPjsgSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgUnlhbiBIYW1pbHRvbiA8 cmNoQGdvb2dsZS5jb20+DQpTdWJqZWN0OiBSZTogV2hlbiBzaG91bGQgc2VydmVyLWNob3NlbiBj b25uZWN0aW9uIElEcyBiZSBzZW50IGFuZCBob3cgYXJlIHRoZXkgaW5kaWNhdGVkPw0KDQpPbiAx IE1hcmNoIDIwMTcgYXQgMDc6MzksIEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29t PiB3cm90ZToNCj4gS3lsZSwgc28geW91IGFyZSB0aGlua2luZyBvZiBzb21lIFJvbGxpbmcgQ29k ZSB0byByZXBsYWNlIA0KPiBDb25uZWN0aW9uSURzIGFmdGVyIGEgMS1SVFQgaGFuZHNoYWtlPyAg VGhhdOKAmXMgYW4gaW50ZXJlc3RpbmcgaWRlYSwgDQo+IHRob3VnaCBpdCBtYXkgYmUgZGlmZmlj dWx0IGZvciBTZXJ2ZXJzIHRvIHRlbGwgYXBhcnQgY29tcGxldGVseSANCj4gbWFydGlhbiBwYWNr ZXRzICh1bmtub3duDQo+IGNvbm5lY3Rpb25zKSB2cyB2ZXJ5IGRlbGF5ZWQgcGFja2V0cyAodGhp cyBtYWtlcyBhIGRpZmZlcmVuY2UgaW4gDQo+IHdoZXRoZXIgdG8gUlNUIHRoZSBjb25uZWN0aW9u IG9yIGRyb3AgdGhlIHBhY2tldCkuDQoNCkkgY29uc2lkZXJlZCB1c2luZyBhIFBSUCAocHNldWRv LXJhbmRvbSBmdW5jdGlvbikgZm9yIGdlbmVyYXRpbmcgbmV3IGNvbm5lY3Rpb24gSURzLiAgSXQg ZG9lc24ndCB3b3JrLiAgVGhlIG5lZWQgZm9yIGl0IHRvIGJlIGtub3duIHRvIHRoZSBjbGllbnQg bWVhbnMgdGhhdCB5b3UgbmVlZCB0byBoYXZlIGEgZGlmZmVyZW50IFBSUCAob3IgYSBkaWZmZXJl bnQgUFJQDQprZXkpIGZvciBldmVyeSBjbGllbnQgLSBvdGhlcndpc2UgY2xpZW50cyBjb3VsZCBn dWVzcyB0aGUgbmV4dCB2YWx1ZSBpbiB0aGUgc2VxdWVuY2UgZm9yIGFueSBvdGhlciBjbGllbnQg KGxpbmthYmlsaXR5IGlzIGJyb2tlbikuICBXaXRoIG1hbnkgY2xpZW50cywgYXZvaWRpbmcgY29s bGlzaW9ucyBpbiB0aGF0IGNhc2Ugd291bGQgYmUgZm9vbGlzaC4NCg== From nobody Tue Feb 28 17:07:32 2017 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 D1D121293DA for ; Tue, 28 Feb 2017 17:07:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckihJG45p-Zn for ; Tue, 28 Feb 2017 17:07:29 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e: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 DF183129505 for ; Tue, 28 Feb 2017 17:07:28 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id s67so13248836pgb.3 for ; Tue, 28 Feb 2017 17:07:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fu5IfSkJbVN5u0Svs78Z1ngIz7yK2/+Yb1UGPjL8Dk8=; b=Ds/ScmpqfW4ucg2leHFz6XUbOf5gHSnUFHxW5Q+AZ/2uA/SXwP1/T6PQpbzZ7+Nnaw 258KnpwIJyQ8TROelAXRLcy+kbvNsuWj/A7xMnZoxbIXDdDfMjI+A6zZj5lCTxaNAYWt U2tbCgZJN4oa4ri5jj3469N5BzMqhZHDGO5Ku/F3l8TFRHsxmUw7OHa+CK03RgDxCrsf fRO22cwOToafo8beXWvcUQNb8yMJegTASmgjuZVNQXFboMTyW1YaD38soaBh0+KtPASq XXEbOZgrp6yWuitaxAsHxaep/mzTaYUJK8CeHuImSRmT2dU0FOP7Iu2UFF08mVH/GufF o4Kg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fu5IfSkJbVN5u0Svs78Z1ngIz7yK2/+Yb1UGPjL8Dk8=; b=LZj3y3LDD+F6TSodZIwkL4MiJyzl2bbqvjn/V13PwDu0eUSLo6ExUYdC8XMhDzLyYI pqUOUYHzlT5Uh2smSWRqb6cXpOxnJx0qc/UWcYGgu05NGdXK8sFPtr/qX/30M4MqKS7u hMTc1Z8T6XbelRY6EP4EbfnBMaBGxD6cU5woFb9cVPCEFzPGamebhSkQsOh2reR9LiQn rae6DDMYY5iyjhGe62y/hGVMusgL+9sGGtC9ixpDkjMIDKn5J0CVKt0+gTJWTbTlOz1p gFTza00Fkori88QM/1lTXKoeaDJRJ5c75VvXOJlhwVoLJDe8NyYtvQ8/Wskv8SxRMTCH hK/w== X-Gm-Message-State: AMke39mytRrDAXdCXjVWI4v6iSIt3xltizJlvuUVNpO07PbxpLgYl5decGqZgSP8I1uU71F0xa0slVBB8RND+A== X-Received: by 10.99.149.6 with SMTP id p6mr5693191pgd.122.1488330447849; Tue, 28 Feb 2017 17:07:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.100.149.13 with HTTP; Tue, 28 Feb 2017 17:07:27 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Wed, 1 Mar 2017 10:07:27 +0900 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Ryan Hamilton Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:07:31 -0000 2017-03-01 9:53 GMT+09:00 Ryan Hamilton : > On Tue, Feb 28, 2017 at 4:45 PM, Kazuho Oku wrote: >> >> My understanding is that when a NAT rebinding occurs it is likely that >> load balancers relying on 5-tuple would start directing packets to the >> wrong server. >> >> In such case, a QUIC server running behind the load balancer would be >> required to route such packets (arriving at the wrong server) to the >> correct server. The correct server can send the responding packets >> directly to the client. > > > How would a server know which server to redirect this packet to? Either by proactively sharing the mapping between client-generated connection IDs and the internal address of the server that is handling the connection, or by including the internal address of the server in the connection ID generated by the server. And I think that we kind of agree that the latter is a requirement for multi-POP deployments. Sorry if I am causing confusion; I think that the issue you raised on this thread is important; my intention is to point out that we might not need to worry to much about load balancers that rely on connection ID but that cannot be controlled well from the QUIC servers running behind, when we consider the choice between a client sending a random connection ID or zero. -- Kazuho Oku From nobody Tue Feb 28 17:07:45 2017 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 ADFFE1293DA for ; Tue, 28 Feb 2017 17:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-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=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 D0lC2lODTwgE for ; Tue, 28 Feb 2017 17:07:40 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 7F107129526 for ; Tue, 28 Feb 2017 17:07:40 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 47A5520001B; Wed, 1 Mar 2017 01:07:40 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 2877C200019; Wed, 1 Mar 2017 01:07:40 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488330460; bh=JGUCheTYXgjeaEzr5XvSTsJZTPU4XZWWaxB6bfvCLlQ=; l=514; h=From:To:CC:Date:References:In-Reply-To:From; b=bRYpG5iyMy4p9xrIQIF+lftVUs3o+4plfe4UAqXLqpIVb7UnFDnpJQVNGhkQ+tR6Q tPcXn9hkEo2PuWVSpFdxPS675QAZD41LdmHsedo97UYSraaEQoivtHiITzGuNlqlYQ Xg8zE0eEqRHucTCogquXRzgsjeIMSlz5nmzJ9RlY= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 0145B9808F; Wed, 1 Mar 2017 01:07:40 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Feb 2017 20:07:39 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Feb 2017 20:07:39 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Tue, 28 Feb 2017 20:07:39 -0500 From: "Lubashev, Igor" To: Martin Thomson , Ryan Hamilton Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnUFyvCyJf5LkySP9zxgM+hCaF/cgQAgAAF/ICAAAOBgIAAAjyAgAAC7gD//6yKwA== Date: Wed, 1 Mar 2017 01:07:38 +0000 Message-ID: <00308ab6b0ac4e31bb9ec0c1fa1c22c3@usma1ex-dag1mb5.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IETF QUIC WG , Kazuho Oku X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:07:44 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRv Om1hcnRpbi50aG9tc29uQGdtYWlsLmNvbV0gDQo+DQo+PiBIb3cgd291bGQgYSBzZXJ2ZXIga25v dyB3aGljaCBzZXJ2ZXIgdG8gcmVkaXJlY3QgdGhpcyBwYWNrZXQgdG8/DQo+DQo+IEkgYXNzdW1l IHRoYXQgdGhlIHNlcnZlciB3b3VsZCBoYXZlIG1vcmUgc3RhdGUgdGhhbiB0aGUgbG9hZCBiYWxh bmNlci4NCg0KVW5mb3J0dW5hdGVseSwgdGhpcyBtZWFucyB0aGUgc2VydmVyIHdvdWxkIG5lZWQg bm90IG9ubHkgaXRzIG93biBzdGF0ZSBidXQgYWxzbyB0aGUgc3RhdGUgb2YgYWxsIG9mIGl0cyBw ZWVycyBiZWhpbmQgdGhhdCBsb2FkIGJhbGFuY2VyLg0K From nobody Tue Feb 28 17:13:25 2017 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 632DD129416 for ; Tue, 28 Feb 2017 17:13:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CFLA9owhxDt for ; Tue, 28 Feb 2017 17:13:23 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D37D81289C4 for ; Tue, 28 Feb 2017 17:13:22 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id u188so47362937qkc.2 for ; Tue, 28 Feb 2017 17:13:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=Vr0E2Aur6c/WNTwOAhehI2KbT9k29QfB9iH2esEVFlE=; b=ke5Pe3MQRs3n2bIhGT41caGXhYCrFAqBAjcZCSp/VLD/X4iYOSEY8ROhhQd2rT5PzU FMPBzZyadQsHY3IKMDRe54AzZPn1OIPVD3cNrlfhsZSHyCv3GGnX29DyvPR/U5PzTjgh hQWho11aXF4S/RhRRlWwQLYvwa/ivH0SscZpvuLz0MvGGPuz5H9RlyrI4RB45EEC7jUl WEErdafGqY5VHdD3gaZGpHZLPylFesFD3hdOuRzwnen1yJ0nqHM3GrlnGEKimvi+8tZ4 DCSi/tmGv0U++DKhMcJnMoUapIwGRoGei2IuzPgje/iG1PbAbftc1NiqmttXsAR6Op62 o0ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=Vr0E2Aur6c/WNTwOAhehI2KbT9k29QfB9iH2esEVFlE=; b=dz6tIVi5HKVn2S0bZbh6+IUNA4JrFJprai3Mt/1nUWRHU7diEZuScORhlF4p7KUYp5 JPvU4htP/cqLcIT+PwaR+g4QJDGPZuSEyxjnRuBGIYUTBLK+rGDthFzu23ps1bnpuvNf O47PytmSJtYWWAsPSP5PlgbofJmRFD2/GMiUNQPPTFY7DU7lJZqhKqrNHHqjNFL3uB/2 7koZRNtlVLEpJOD12s+w9WLgRfpoG6k7PxUoiM1I+JhhAWSGQ0x7iNoxugHyrP3ZJ7st QDC2JPhL9h3+h9XGzr+38SxOD5EUSy05d6HOXOOWWSaB2qn83hPPTcO+Q9ybTNeGrnUu xf5w== X-Gm-Message-State: AMke39kqpAciVMJBZO+Yzw4h9Ej2+8hMY7+7RsJ6MPwRKMfV5j9NmS8y1XsSN7IOO1YDl+D+ddxOOlUkjzEbQw== X-Received: by 10.237.51.5 with SMTP id u5mr7074798qtd.247.1488330802001; Tue, 28 Feb 2017 17:13:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 28 Feb 2017 17:13:21 -0800 (PST) In-Reply-To: References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> <618be199a45448b093a7ae0a03539e54@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Wed, 1 Mar 2017 12:13:21 +1100 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: "Lubashev, Igor" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Mike Bishop , Ted Hardie , Kyle Rose , Ryan Hamilton , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:13:24 -0000 On 1 March 2017 at 12:05, Lubashev, Igor wrote: > To elaborate on Kyle's idea, the initial ConnectionID would be selected a= s described, then client and server would negotiate some secure connection = nonce, and the subsequent ConnectionID would be hash(nonce, packet#). Nonc= e is a per-connection secret, so hash(nonce, x) cannot be predicted. Yes, that would work, if you don't care about collisions, which you would get a LOT of. Also, your load balancer is completely in the dark unless you keep it constantly updated with the nonces that every connection (or maybe server) uses. From nobody Tue Feb 28 17:18:23 2017 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 61DF5129862 for ; Tue, 28 Feb 2017 17:18:06 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 HeDcvr4zv4Mx for ; Tue, 28 Feb 2017 17:18:00 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 7FC611296F4 for ; Tue, 28 Feb 2017 17:17:41 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4647320000D; Wed, 1 Mar 2017 01:17:41 +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 22702200004; Wed, 1 Mar 2017 01:17:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488331061; bh=iJy3uXRO3jwa1/nA1IE20KIrPG8bvRmg3T1p31bdnHk=; l=12690; h=From:To:CC:Date:References:In-Reply-To:From; b=ZBVS5Ywuon6V8qEcHt0lcI1QJQLvwv3yiOrGPjtDyas5T8N10395O0uqAF/9ZgOEP 6U4EHzOEWeArOol2sczqGFsW8lWvwNfJKZodONJi9/j4vjyaSao1j7eNxmElRHecAZ NcHNo9e8E125irzXJRjxND6olkgivtZ1UF9amCh0= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id E91581E07C; Wed, 1 Mar 2017 01:17:40 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Feb 2017 20:17:40 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Tue, 28 Feb 2017 20:17:40 -0500 From: "Lubashev, Igor" To: Kazuho Oku , Ryan Hamilton Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnUFyvCyJf5LkySP9zxgM+hCaF/cgQAgAAF/ICAAAOBgIAAAjyAgAADw4D//6yTYA== Date: Wed, 1 Mar 2017 01:17:39 +0000 Message-ID: <21e65e12ba7f483f95ed278c28029bb5@usma1ex-dag1mb5.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.129] Content-Type: multipart/alternative; boundary="_000_21e65e12ba7f483f95ed278c28029bb5usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:18:06 -0000 --_000_21e65e12ba7f483f95ed278c28029bb5usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEZyb206IEthenVobyBPa3UgW21haWx0bzprYXp1aG9va3VAZ21haWwuY29tXQ0KDQrDmA0K DQrDmCAgRWl0aGVyIGJ5IHByb2FjdGl2ZWx5IHNoYXJpbmcgdGhlIG1hcHBpbmcgYmV0d2VlbiBj bGllbnQtZ2VuZXJhdGVkIGNvbm5lY3Rpb24gSURzIGFuZCB0aGUgaW50ZXJuYWwgYWRkcmVzcyBv ZiB0aGUgc2VydmVyIHRoYXQgaXMgaGFuZGxpbmcgdGhlIGNvbm5lY3Rpb24sIG9yIGJ5IGluY2x1 ZGluZyB0aGUgaW50ZXJuYWwgYWRkcmVzcyBvZiB0aGUgc2VydmVyIGluIHRoZSBjb25uZWN0aW9u IElEIGdlbmVyYXRlZCBieSB0aGUgc2VydmVyLiBBbmQgSSB0aGluayB0aGF0IHdlIGtpbmQgb2Yg YWdyZWUgdGhhdCB0aGUgbGF0dGVyIGlzIGEgcmVxdWlyZW1lbnQgZm9yIG11bHRpLVBPUCBkZXBs b3ltZW50cy4NCg0KDQoNClNvcnJ5LCBJIHRob3VnaHQgeW91IHdlcmUgYXJndWluZyBhZ2FpbnN0 IG1hcHBpbmcgYnkgQ29ubmVjdGlvbklELiAgRm9yIG1lLCBmb3J3YXJkaW5nIHBhY2tldHMgdG8g dGhlIGNvcnJlY3QgYmFja2VuZCBzZXJ2ZXIgaXMgbG9hZCBiYWxhbmNlcuKAmXMgam9iLiBJZiBh IHNlcnZlciBpbmNsdWRlcyBlbGVtZW50cyBvZiB0aGUg4oCcbG9hZCBiYWxhbmNlcuKAnSwgdGhh dOKAmXMgZmluZS4gSW4gdGhlIGVuZCBvZiB0aGUgZGF5LCB0aGF04oCZcyBzdGlsbCB0aGUg4oCc c2VydmVy4oCdIHBhcnQgKHRoZSBvbmUgdGhhdCBnZW5lcmF0ZXMgQ29ubmVjdGlvbklEKSBvZiB0 aGUgc2VydmVyIGNvb3BlcmF0aW5nIHdpdGggdGhlIOKAnGxvYWQgYmFsYW5jZXLigJ0gcGFydC4g IFRoZSBrZXkgaXMgdGhhdCB0aGUgZGlzdHJpYnV0ZWQg4oCcbG9hZCBiYWxhbmNlcuKAnSBwYXJ0 IGlzIHN0aWxsIHN0YXRlbGVzcy4NCg0KDQoNCi0gICAgICAgICAgSWdvcg0KDQoNCg== --_000_21e65e12ba7f483f95ed278c28029bb5usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uUGxhaW5UZXh0Q2hhcg0KCXtt c28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmlu aXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDoxMTg1NzU0MzMyOw0KCW1zby1saXN0 LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNDAwNDA1NTAyIDE2MzYzMDMz MDIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlz dCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1p ZDoxNDk2ODcxMDU5Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoyMDk5NjgwMTU2IC0yNTE3ODg5MjQgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDE6bGV2 ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDot Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw4 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpA bGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbjttc28t bGlzdDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxz cGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7 DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+RnJvbTogS2F6dWhvIE9rdSBbbWFpbHRv OmthenVob29rdUBnbWFpbC5jb21dIDxvOnA+DQo8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh aW5UZXh0IiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzEiPg0KPCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjpibGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs YWluVGV4dCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1s aXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTpXaW5nZGluZ3MiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPsOYPHNw YW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij4mbmJzcDsN Cjwvc3Bhbj48L3NwYW4+PC9zcGFuPjwhW2VuZGlmXT5FaXRoZXIgYnkgcHJvYWN0aXZlbHkgc2hh cmluZyB0aGUgbWFwcGluZyBiZXR3ZWVuIGNsaWVudC1nZW5lcmF0ZWQgY29ubmVjdGlvbiBJRHMg YW5kIHRoZSBpbnRlcm5hbCBhZGRyZXNzIG9mIHRoZSBzZXJ2ZXIgdGhhdCBpcyBoYW5kbGluZyB0 aGUgY29ubmVjdGlvbiwgb3IgYnkgaW5jbHVkaW5nIHRoZSBpbnRlcm5hbCBhZGRyZXNzIG9mIHRo ZSBzZXJ2ZXIgaW4gdGhlIGNvbm5lY3Rpb24gSUQNCiBnZW5lcmF0ZWQgYnkgdGhlIHNlcnZlci4g QW5kIEkgdGhpbmsgdGhhdCB3ZSBraW5kIG9mIGFncmVlIHRoYXQgdGhlIGxhdHRlciBpcyBhIHJl cXVpcmVtZW50IGZvciBtdWx0aS1QT1AgZGVwbG95bWVudHMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPlNvcnJ5LCBJIHRob3VnaHQgeW91IHdlcmUgYXJndWluZyBhZ2FpbnN0IG1hcHBp bmcgYnkgQ29ubmVjdGlvbklELiZuYnNwOyBGb3IgbWUsIGZvcndhcmRpbmcgcGFja2V0cyB0byB0 aGUgY29ycmVjdCBiYWNrZW5kIHNlcnZlciBpcyBsb2FkIGJhbGFuY2Vy4oCZcyBqb2IuIElmIGEg c2VydmVyIGluY2x1ZGVzIGVsZW1lbnRzIG9mIHRoZSDigJxsb2FkIGJhbGFuY2Vy4oCdLCB0aGF0 4oCZcyBmaW5lLiBJbiB0aGUgZW5kIG9mIHRoZQ0KIGRheSwgdGhhdOKAmXMgc3RpbGwgdGhlIOKA nHNlcnZlcuKAnSBwYXJ0ICh0aGUgb25lIHRoYXQgZ2VuZXJhdGVzIENvbm5lY3Rpb25JRCkgb2Yg dGhlIHNlcnZlciBjb29wZXJhdGluZyB3aXRoIHRoZSDigJxsb2FkIGJhbGFuY2Vy4oCdIHBhcnQu Jm5ic3A7IFRoZSBrZXkgaXMgdGhhdCB0aGUgZGlzdHJpYnV0ZWQg4oCcbG9hZCBiYWxhbmNlcuKA nSBwYXJ0IGlzIHN0aWxsIHN0YXRlbGVzcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCIg c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwxIGxl dmVsMSBsZm8yIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJ Z25vcmUiPi08c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KPC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SWdvcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv aHRtbD4NCg== --_000_21e65e12ba7f483f95ed278c28029bb5usma1exdag1mb5msgcorpak_-- From nobody Tue Feb 28 17:29:11 2017 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 A9550129461 for ; Tue, 28 Feb 2017 17:29:08 -0800 (PST) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 LeiDsj93AV8j for ; Tue, 28 Feb 2017 17:29:07 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 02232129408 for ; Tue, 28 Feb 2017 17:29:06 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 8F390433415; Wed, 1 Mar 2017 01:29:06 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 57F0143340D; Wed, 1 Mar 2017 01:29:06 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488331746; bh=TSMMARO8Z81sUibsIsK09qZmyVQ95+TZnFkq7TfNZ9Y=; l=2062; h=From:To:CC:Date:References:In-Reply-To:From; b=K3PtEO/sLhTiSxv/yGK1I4maxE6/92ejvlPjKq6BnBg41+Chns3JWnk0xDiOh0sfF idmiYBl0AetdaKllsmFUkDRukLxYfGSLN84UndlNq8hUffk/XVlSWzuN08UEwBEYS1 VaJQGEe24UbV2QWDORUT+1xVuYoyQVYLWI4njB9s= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 52B7A1FC8C; Wed, 1 Mar 2017 01:29:06 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Feb 2017 20:29:05 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Tue, 28 Feb 2017 20:29:05 -0500 From: "Lubashev, Igor" To: Martin Thomson Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnUFyvCyJf5LkySP9zxgM+hCaF972KAgAAA8YCAALU8gIAATWEAgAAa8ICAABKLgIAABbOAgAAHEQCAAAVQgP//rmoQgACaKwD//688oIAAWNaA//+tdeA= Date: Wed, 1 Mar 2017 01:29:05 +0000 Message-ID: References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> <618be199a45448b093a7ae0a03539e54@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Mike Bishop , Ted Hardie , Kyle Rose , Ryan Hamilton , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 01:29:09 -0000 UmlnaHQuICBUaGF0IHNjaGVtZSB3b3VsZCByZWR1Y2UgZW50cm9weSBieSBsb2coI2Nvbm5JRHNf YWNjZXB0ZWQpLiAgQ291bGQgYmUgYSBsb3QuICBBbmQgdGhlIGxvYWQgYmFsYW5jZXIgd291bGQg c3RpbGwgcmVxdWlyZSBzb21lIGFkZGl0aW9uYWwgdW5jaGFuZ2VkIGJpdHMgaW4gdGhlIGNsZWFy IChidXQgZmV3IGVub3VnaCBiaXRzIHRoYXQgaXQgd291bGQgbWFrZSB0cmFja2luZyBoYXJkKS4g IEFuZCBpdCBpcyBzYWNyaWZpY2luZyBzb21lIHJvYnVzdG5lc3MgYW5kIGFkZHMgZXh0cmEgY29t cHV0ZSB0byB0aGUgc2VydmVyLg0KDQpBbGwgaW4gYWxsLCBJIGFtIG5vdCBpbiBsb3ZlIHdpdGgg dGhpcyBhcHByb2FjaCBlaXRoZXIsIGJ1dCBpdCBpcyB3b3J0aCBhIGNvbnNpZGVyYXRpb24uDQoN Ci0gSWdvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIFRob21z b24gW21haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb21dIA0KU2VudDogVHVlc2RheSwgRmVi cnVhcnkgMjgsIDIwMTcgODoxMyBQTQ0KVG86IEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2Ft YWkuY29tPg0KQ2M6IEt5bGUgUm9zZSA8a3Jvc2VAa3Jvc2Uub3JnPjsgTWlyamEgS8O8aGxld2lu ZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD47IE1pa2UgQmlzaG9wIDxtaWNoYWVs LmJpc2hvcEBtaWNyb3NvZnQuY29tPjsgVGVkIEhhcmRpZSA8dGVkLmlldGZAZ21haWwuY29tPjsg SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5j b20+DQpTdWJqZWN0OiBSZTogV2hlbiBzaG91bGQgc2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElE cyBiZSBzZW50IGFuZCBob3cgYXJlIHRoZXkgaW5kaWNhdGVkPw0KDQpPbiAxIE1hcmNoIDIwMTcg YXQgMTI6MDUsIEx1YmFzaGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPiB3cm90ZToNCj4g VG8gZWxhYm9yYXRlIG9uIEt5bGUncyBpZGVhLCB0aGUgaW5pdGlhbCBDb25uZWN0aW9uSUQgd291 bGQgYmUgc2VsZWN0ZWQgYXMgZGVzY3JpYmVkLCB0aGVuIGNsaWVudCBhbmQgc2VydmVyIHdvdWxk IG5lZ290aWF0ZSBzb21lIHNlY3VyZSBjb25uZWN0aW9uIG5vbmNlLCBhbmQgdGhlIHN1YnNlcXVl bnQgQ29ubmVjdGlvbklEIHdvdWxkIGJlIGhhc2gobm9uY2UsIHBhY2tldCMpLiAgTm9uY2UgaXMg YSBwZXItY29ubmVjdGlvbiBzZWNyZXQsIHNvIGhhc2gobm9uY2UsIHgpIGNhbm5vdCBiZSBwcmVk aWN0ZWQuDQoNClllcywgdGhhdCB3b3VsZCB3b3JrLCBpZiB5b3UgZG9uJ3QgY2FyZSBhYm91dCBj b2xsaXNpb25zLCB3aGljaCB5b3Ugd291bGQgZ2V0IGEgTE9UIG9mLiAgQWxzbywgeW91ciBsb2Fk IGJhbGFuY2VyIGlzIGNvbXBsZXRlbHkgaW4gdGhlIGRhcmsgdW5sZXNzIHlvdSBrZWVwIGl0IGNv bnN0YW50bHkgdXBkYXRlZCB3aXRoIHRoZSBub25jZXMgdGhhdCBldmVyeSBjb25uZWN0aW9uIChv ciBtYXliZSBzZXJ2ZXIpIHVzZXMuDQo= From nobody Tue Feb 28 18:29:57 2017 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 20DB2129406 for ; Tue, 28 Feb 2017 18:29:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NEBUkoxNxGad for ; Tue, 28 Feb 2017 18:29:54 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B9712944D for ; Tue, 28 Feb 2017 18:29:52 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id s186so49339010qkb.1 for ; Tue, 28 Feb 2017 18:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=KlsPuk+yL7pvx8SizEq/sFjNuuX6B4itDTAksrmpHKs=; b=u94Oa1xdLPBmCpo/n8hd+JTpXXrOy1Jk3f1JAR9L+t64fhHooNyCGVj5hSUHJCFJin dFaWuIn/CW8rCHpsOh0nZg+Jmt66X2+YRA9vA13uYgaUeGjgSFCvjpnAc02nmBhgrHqU 6gbTyol3Yqns3F3IPJJqgmlkmZ60MRuOqdB4Xrwo3Am4L8A6KLExaoPdkrsYXOxCshLE uey/jw1ZrZIslN5joZif81nCWFPTIvXAN7hvh8Ui0sMMBSliQ6fZEMpZ+FfqK6QGXW7j D/SJ0+QnJ9CekTX25FuEiN3lTy/T+a+7m/oZjFtyEcilGPRBCgE3P+PWJRsRMeWoZ3Dh 3oGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=KlsPuk+yL7pvx8SizEq/sFjNuuX6B4itDTAksrmpHKs=; b=hb4iObQE7YRxF5hjwR+3VSRVpVI6EZmqn+Dmp0bYjywqvssaFLsLs+hB5Sr9MEYVvK ym/T9LOk4W6qgqZjuPHOD4jFR992hDYmatErBuI/nTtflitm+AtQmjUXto5SBCQSFyNG UwsgrVRKUj/HHMWzctyxH2ktAXrEV29eYwef7R3QAret5+l1dv5JXeKAZIPBlIUsyuyB 29IqEuK+haEm3RTN53TigUxGGEppbipGrBxWNvbJcLqLiuaf1fke4ownvsVapCvDMome rfwujuT50zizzE6fUeGjJMSx8vCDvIgdW/6AVPyemtDbjzyraoI0asSBOwtDyOYH3aB0 Eqcg== X-Gm-Message-State: AMke39kH30EEU3yvur9qGglyah6N2eKQAS/RYpM+An4HCA66PLS7y2be7lwlisiz9hmmF7RTFRI088et6xP62w== X-Received: by 10.237.51.5 with SMTP id u5mr7447090qtd.247.1488335391267; Tue, 28 Feb 2017 18:29:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 28 Feb 2017 18:29:50 -0800 (PST) From: Martin Thomson Date: Wed, 1 Mar 2017 13:29:50 +1100 Message-ID: Subject: Bike shed warning: integrity check for unprotected packets To: IETF QUIC WG Content-Type: text/plain; charset=UTF-8 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 02:29:56 -0000 I would like to close https://github.com/quicwg/base-drafts/issues/167 However, I'd like to only close it once. So I'd like to have a small amount of discussion about the hash function we use. Hopefully we only have that discussion once also. These are the choices I think are reasonable (drawing on the reams of literature out there): FNV-1a @128 bits [https://tools.ietf.org/html/draft-eastlake-fnv-03] CRC32 [ITU-T Recommendation V.42] Murmur3 [https://github.com/aappleby/smhasher/wiki/MurmurHash3] GHASH [RFC 5116] or Poly1305 [RFC 7539] with a fixed key AES-GCM or ChaCha20-Poly1305 with a fixed key GQUIC currently uses a 128-bit variant of FNV-1a. I'm guessing that this was simply the best available at the time. In all cases, the cost of these is essentially zero (it's possible that a 128-bit version is slower, but I couldn't find any benchmarks and it's probably still close to zero). In my view, we should not making this decision on performance grounds. I have a preference for CRC32. It's what SCTP uses (see RFC 3309). It's smaller. It's well documented and very widely implemented. It's got hardware support in both Intel and ARM chips, if you care about saving cycles (pro tip: you should not). It's not perfect for picking a bucket in a hash table, though it's not bad for that purpose. Rather, it is designed specifically for detecting errors in transmission, i.e., exactly what we need. In terms of size, I think that 32-bits is plenty. We can't defend against active modification, so this only exists to winnow out Internet noise. The combination of this AND the UDP checksum should be plenty, even if the UDP checksum is basically ineffectual. If speed is a determining factor, then Murmur is much faster. Though FNV-1a is *slightly* faster on some benchmarks I've seen (not all - the one I ran was 15% slower than CRC), most of those concentrate on the 32-bit variants so that they can do like-for-like comparisons. The 128-bit variant probably requires uint128_t support for performance and that's not widespread. If we wanted to reuse code, we could use GHASH (which is part of AES-GCM) or Poly1305 (part of ChaCha20-Poly1305). Or we could encrypt with a fixed key. But I don't see the point in either of these which are considerably more complicated. Final question for those who made it this far: should we bind the hash to the version? We can claim that the hash is always the same for any QUIC version, which would allow a receiver to validate the hash even if it didn't support the selected version. Or we could say that version determines which hash is in use. From nobody Tue Feb 28 18:59:40 2017 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 3303712944D for ; Tue, 28 Feb 2017 18:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 75iTZliftiu6 for ; Tue, 28 Feb 2017 18:59:37 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 3A75C129434 for ; Tue, 28 Feb 2017 18:59:37 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id 72so33284294uaf.3 for ; Tue, 28 Feb 2017 18:59:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jj0J3i/AGx3OWkW6i10ySwLrYYdJv+KZC1n0ZitUTmA=; b=f4asdFmw7Uu2Ixt8x4gH/WG3C0xCK0YmpKBR3o2OsWOge0ZeTscdJDCVEVFe2ZSOg2 JN1msSet0yXNoluI773sp4+RS+YssTjtPsCDxQNVMXfsbwN7jDyL3zdJgHHaEzjQq1JO dgF2YQPKyjMIPYSjxXA+GZ+v5gkXdWVQGqnzAQkPyqmMyhNRyw3XmMu16CSA1yFNRXUP DcH6Z7WeLwullh2o5Cz/B+FbBUV1XzSnwsXE0aHuceVvbNCMFj3FBm+3sSGw7YiWYny5 yweRPKxOegSOmE28dWfN8oZeMMD8VrYW5XgBBRD+kWTXIA6qo9yztqd5j3MT32YLUU1Y ETjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jj0J3i/AGx3OWkW6i10ySwLrYYdJv+KZC1n0ZitUTmA=; b=GPkj/uXZ+/mHpQI5aT1CParTGqbYbgLDmUsOHfpGp3uuWgIFQQTK8az0LukvU+eOVY p/fUnGFbNeMWzQ531YsIztSGNrxU4d5sG3j5U6+tnmuucsXBdaN4q7+mx3xLPdr3Kpg1 OWusQgu3Ktp7P9tx9B/EYzhE8maw2XrqkPNLVv5n0yGLHNlegtfgXeAZWBgKsLtsGttp t5hAXXM3iFWbResKgVu52KJeCa7jGGVA4YNrPlVPyLPWXh/qIAmhIJYetSBo+cg2k/Zf 5jh2+K+msr3HprC8ETIE+SSg8kgrIjREL7Q2W41H47OBQYjcZ6KlI98V9/jGj5MB0q7x R3vA== X-Gm-Message-State: AMke39lQdX3xj3VbMS7noBK7Euu68ixpx/sbVBSLhlVKEckccRCT501LNu99jDDypuHUuUEHwhenJNUoLl/0k2Ym X-Received: by 10.176.16.5 with SMTP id f5mr1129806uab.13.1488337175902; Tue, 28 Feb 2017 18:59:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Tue, 28 Feb 2017 18:59:35 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 28 Feb 2017 18:59:35 -0800 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: Martin Thomson Content-Type: multipart/alternative; boundary=f403045e345eada7e60549a28042 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 02:59:39 -0000 --f403045e345eada7e60549a28042 Content-Type: text/plain; charset=UTF-8 I do not have a strong opinion on this issue, but I'll note that there's running code doing FNV-1a: it is what's used by Google QUIC and QuicGo implementations. It was supposed to be in the original input spec to the wg, but we forgot to mention it. This hash is only computed on cleartext packets (handshake packets), so I don't think the compute difference between the algorithms or hardware support matters. One correction and one comment below: On Tue, Feb 28, 2017 at 6:29 PM, Martin Thomson wrote: > I would like to close https://github.com/quicwg/base-drafts/issues/167 > > However, I'd like to only close it once. So I'd like to have a small > amount of discussion about the hash function we use. Hopefully we > only have that discussion once also. > > These are the choices I think are reasonable (drawing on the reams of > literature out there): > > FNV-1a @128 bits [https://tools.ietf.org/html/draft-eastlake-fnv-03] > CRC32 [ITU-T Recommendation V.42] > Murmur3 [https://github.com/aappleby/smhasher/wiki/MurmurHash3] > GHASH [RFC 5116] or Poly1305 [RFC 7539] with a fixed key > AES-GCM or ChaCha20-Poly1305 with a fixed key > > GQUIC currently uses a 128-bit variant of FNV-1a. I'm guessing that > this was simply the best available at the time. > > In all cases, the cost of these is essentially zero (it's possible > that a 128-bit version is slower, but I couldn't find any benchmarks > and it's probably still close to zero). In my view, we should not > making this decision on performance grounds. > > I have a preference for CRC32. It's what SCTP uses (see RFC 3309). Not that it matters, but SCTP uses CRC-32c. It's only slightly different from CRC-32, but different enough that there's lesser hardware support for CRC-32c. It's smaller. It's well documented and very widely implemented. It's > got hardware support in both Intel and ARM chips, if you care about > saving cycles (pro tip: you should not). It's not perfect for picking > a bucket in a hash table, though it's not bad for that purpose. > Rather, it is designed specifically for detecting errors in > transmission, i.e., exactly what we need. > > In terms of size, I think that 32-bits is plenty. We can't defend > against active modification, so this only exists to winnow out > Internet noise. The combination of this AND the UDP checksum should > be plenty, even if the UDP checksum is basically ineffectual. > > If speed is a determining factor, then Murmur is much faster. Though > FNV-1a is *slightly* faster on some benchmarks I've seen (not all - > the one I ran was 15% slower than CRC), most of those concentrate on > the 32-bit variants so that they can do like-for-like comparisons. > The 128-bit variant probably requires uint128_t support for > performance and that's not widespread. > > If we wanted to reuse code, we could use GHASH (which is part of > AES-GCM) or Poly1305 (part of ChaCha20-Poly1305). Or we could encrypt > with a fixed key. But I don't see the point in either of these which > are considerably more complicated. > > Final question for those who made it this far: should we bind the hash > to the version? We can claim that the hash is always the same for any > QUIC version, which would allow a receiver to validate the hash even > if it didn't support the selected version. Or we could say that > version determines which hash is in use. > It seems reasonable to make the hash version-dependent. If the version was corrupted, a receiver might end up using the wrong hash algorithm, but the chances of a collision there seem quite low. My 2c: document FNV-1a, since that adds no work for existing QUIC implementations, and make it version-dependent so the bikeshed is around later. - jana --f403045e345eada7e60549a28042 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I do not have a strong opinion on this issue, but I'll= note that there's running code doing FNV-1a:=C2=A0it is what's use= d by Google QUIC and QuicGo implementations. It was supposed to be in the o= riginal input spec to the wg, but we forgot to mention it. This hash is onl= y computed on cleartext packets (handshake packets), so I don't think t= he compute difference between the algorithms or hardware support matters. O= ne correction and one comment below:

On Tue, Feb 28, 2017 at 6:29 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
I would like to close https://github.com/quicwg/base-drafts/issues/167

However, I'd like to only close it once.=C2=A0 So I'd like to have = a small
amount of discussion about the hash function we use.=C2=A0 Hopefully we
only have that discussion once also.

These are the choices I think are reasonable (drawing on the reams of
literature out there):

FNV-1a @128 bits [https://tools.ietf.org/html/= draft-eastlake-fnv-03]
CRC32 [ITU-T Recommendation V.42]
Murmur3 [https://github.com/aappleby/smhas= her/wiki/MurmurHash3]
GHASH [RFC 5116] or Poly1305 [RFC 7539] with a fixed key
AES-GCM or ChaCha20-Poly1305 with a fixed key

GQUIC currently uses a 128-bit variant of FNV-1a.=C2=A0 I'm guessing th= at
this was simply the best available at the time.

In all cases, the cost of these is essentially zero (it's possible
that a 128-bit version is slower, but I couldn't find any benchmarks and it's probably still close to zero).=C2=A0 In my view, we should not=
making this decision on performance grounds.

I have a preference for CRC32.=C2=A0 It's what SCTP uses (see RFC 3309)= .

Not that it matters, but SCTP uses CRC-32= c. It's only slightly different from CRC-32, but different enough that = there's lesser hardware support for CRC-32c.

It's smaller.=C2=A0 It'= s well documented and very widely implemented.=C2=A0 It's
got hardware support in both Intel and ARM chips, if you care about
saving cycles (pro tip: you should not).=C2=A0 It's not perfect for pic= king
a bucket in a hash table, though it's not bad for that purpose.
Rather, it is designed specifically for detecting errors in
transmission, i.e., exactly what we need.

In terms of size, I think that 32-bits is plenty.=C2=A0 We can't defend=
against active modification, so this only exists to winnow out
Internet noise.=C2=A0 The combination of this AND the UDP checksum should be plenty, even if the UDP checksum is basically ineffectual.

If speed is a determining factor, then Murmur is much faster.=C2=A0 Though<= br> FNV-1a is *slightly* faster on some benchmarks I've seen (not all -
the one I ran was 15% slower than CRC), most of those concentrate on
the 32-bit variants so that they can do like-for-like comparisons.
The 128-bit variant probably requires uint128_t support for
performance and that's not widespread.

If we wanted to reuse code, we could use GHASH (which is part of
AES-GCM) or Poly1305 (part of ChaCha20-Poly1305).=C2=A0 Or we could encrypt=
with a fixed key.=C2=A0 But I don't see the point in either of these wh= ich
are considerably more complicated.

Final question for those who made it this far: should we bind the hash
to the version?=C2=A0 We can claim that the hash is always the same for any=
QUIC version, which would allow a receiver to validate the hash even
if it didn't support the selected version.=C2=A0 Or we could say that version determines which hash is in use.

It seems reasonable to make the hash version-dependent. If the version wa= s corrupted, a receiver might end up using the wrong hash algorithm, but th= e chances of a collision there seem quite low.

My = 2c: document FNV-1a, since that adds no work for existing QUIC implementati= ons, and make it version-dependent so the bikeshed is around later.
- jana


--f403045e345eada7e60549a28042-- From nobody Tue Feb 28 19:16:12 2017 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 E3F3F129498 for ; Tue, 28 Feb 2017 19:16:10 -0800 (PST) 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 nx8q77xFobmi for ; Tue, 28 Feb 2017 19:16:10 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CCFD8129485 for ; Tue, 28 Feb 2017 19:16:09 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n186so49211305qkb.3 for ; Tue, 28 Feb 2017 19:16:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QLj7P8N1HV6Tg3VRg4ImacOLXa048jNmiq2MwmWv3Ns=; b=txq0bzOEGrLi+HVivCQfpNAIiw538VoetnVENQOOHEOQYtxVOVcQNLmPPVI/iQ0Vw4 /m0rZVm/6l/xypCbwU0xmOnTbccqSZAs/qsXqCdFNA6IemEuNg1Ll9WGi24UB7xQ2h6t FRDQcvK61WVJ397SRMbyDZbeRRsjUpZGkl7JAxb8Rj3dypCbzrpByZr46Qu6wTRJv9Ix vz9iv+JELoE1lyZNeviVsvpmvOrc3o9TAuW2LeDnQ37pOMdBJSHHcx8vJe/oa4agZq3k oPTYhkgerWpRcfAOJMaXMkyYB4wUy02e8L/u7P7m1zzZ01aWK8/qovOnGTJzL9ljlaOj Agkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QLj7P8N1HV6Tg3VRg4ImacOLXa048jNmiq2MwmWv3Ns=; b=W1u8cBMxy1Uaj0gFyMBUnmEN4mgOIL7vc6hKZcb5k6mIMeOZUY30vFNv30jeWO3Qxs /DM5q4Ek+drK7Y9bXUzuxQCzJhLULbtaHGqu1nc0tIswJtNHLHB2RSlyRzIyGF9bOnUJ A8R2RuYsZFgxbbssUhu74KRm162f5uMzMI29fIVO3oUcqOfG7bHtk5Zl+hDjI6z0HeWL X2Est7mVQA4AhrvWAGC/AEFoqjhU2xr+J6rF+P5iENdBTh/wnzOWa+onN/PwHN+aKpZy wXGqEB55k/K3MQHVcINZZYu0iwIo1DSDwfi8WWHrcnJOcpW64hUb7y9B4x0VoaRrPC4N G2bQ== X-Gm-Message-State: AMke39lCMMSYlIA4GQBi+mYIk592/PAczG/ScFVsIjo8mv2iof3zo5LkEvfPjlZWUMJB1YZg6tCTIzfcOiMa2Q== X-Received: by 10.55.151.7 with SMTP id z7mr7077530qkd.316.1488338168991; Tue, 28 Feb 2017 19:16:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 28 Feb 2017 19:16:08 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 1 Mar 2017 14:16:08 +1100 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 03:16:11 -0000 On 1 March 2017 at 13:59, Jana Iyengar wrote: > My 2c: document FNV-1a, since that adds no work for existing QUIC > implementations, and make it version-dependent so the bikeshed is around > later. The reason I opened this thread is to avoid a bikeshed buildup. If you want to argue for FNV-1a-128, then let's hear the argument. (I agree with you about binding hash to version. The faintest hint of any dispute about suitability argues for that.) From nobody Tue Feb 28 19:21:34 2017 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 A6CDB129470 for ; Tue, 28 Feb 2017 19:21:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 ndN9ySOCZczK for ; Tue, 28 Feb 2017 19:21:30 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id BBDC91293F0 for ; Tue, 28 Feb 2017 19:21:30 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4033316C75A; Wed, 1 Mar 2017 03:21:30 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 2005116C73F; Wed, 1 Mar 2017 03:21:30 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488338490; bh=z0EV63rSK7KXXiTNp6o8jakdEDCsmOfGOmQRtnZ7CT4=; l=12591; h=From:To:CC:Date:References:In-Reply-To:From; b=xy9nFatDszbSQ4u6oo+r/aEb2FbenTkJW8S3jYQsLVIpDMZ9flYU1WnaSLNllUYd/ 4v+KG50hCF0c/ziiGZG6s2h3pvczHejIzvBlE5CWD3qBWK3Wc4QRNOsiYBmtzlv3PY 5VI5L33pyXhPh7h0hV9aOIdPlIOuhy5BTqGGuAPU= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id EDEAB1E07C; Wed, 1 Mar 2017 03:21:29 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Feb 2017 22:21:29 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Tue, 28 Feb 2017 22:21:29 -0500 From: "Lubashev, Igor" To: "martin.thomson@gmail.com" , "jri@google.com" Subject: RE: Bike shed warning: integrity check for unprotected packets Thread-Topic: Bike shed warning: integrity check for unprotected packets Thread-Index: AQHSkjO6lru5zftGP0qojvtmiwHwlKF/nyGA//+yTFI= Date: Wed, 1 Mar 2017 03:21:28 +0000 Message-ID: <10faec2f2c0344cc8ac511fded3a36cd@usma1ex-dag1mb5.msg.corp.akamai.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_10faec2f2c0344cc8ac511fded3a36cdusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 03:21:32 -0000 --_000_10faec2f2c0344cc8ac511fded3a36cdusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No strong options here, especially on the choice of the function. I have so= me preference for standardizing it across versions, so a server that got a = packet with an unknown version can figure out whether it got a corrupt pack= et (that it should drop) or just an unsupported version (so it should conti= nue with version negotiation). - Igor -----Original Message----- From: Jana Iyengar [jri@google.com] Received: Tuesday, 28 Feb 2017, 9:59PM To: Martin Thomson [martin.thomson@gmail.com] CC: IETF QUIC WG [quic@ietf.org] Subject: Re: Bike shed warning: integrity check for unprotected packets I do not have a strong opinion on this issue, but I'll note that there's ru= nning code doing FNV-1a: it is what's used by Google QUIC and QuicGo implem= entations. It was supposed to be in the original input spec to the wg, but = we forgot to mention it. This hash is only computed on cleartext packets (h= andshake packets), so I don't think the compute difference between the algo= rithms or hardware support matters. One correction and one comment below: On Tue, Feb 28, 2017 at 6:29 PM, Martin Thomson > wrote: I would like to close https://github.com/quicwg/base-drafts/issues/167 However, I'd like to only close it once. So I'd like to have a small amount of discussion about the hash function we use. Hopefully we only have that discussion once also. These are the choices I think are reasonable (drawing on the reams of literature out there): FNV-1a @128 bits [https://tools.ietf.org/html/draft-eastlake-fnv-03] CRC32 [ITU-T Recommendation V.42] Murmur3 [https://github.com/aappleby/smhasher/wiki/MurmurHash3] GHASH [RFC 5116] or Poly1305 [RFC 7539] with a fixed key AES-GCM or ChaCha20-Poly1305 with a fixed key GQUIC currently uses a 128-bit variant of FNV-1a. I'm guessing that this was simply the best available at the time. In all cases, the cost of these is essentially zero (it's possible that a 128-bit version is slower, but I couldn't find any benchmarks and it's probably still close to zero). In my view, we should not making this decision on performance grounds. I have a preference for CRC32. It's what SCTP uses (see RFC 3309). Not that it matters, but SCTP uses CRC-32c. It's only slightly different fr= om CRC-32, but different enough that there's lesser hardware support for CR= C-32c. It's smaller. It's well documented and very widely implemented. It's got hardware support in both Intel and ARM chips, if you care about saving cycles (pro tip: you should not). It's not perfect for picking a bucket in a hash table, though it's not bad for that purpose. Rather, it is designed specifically for detecting errors in transmission, i.e., exactly what we need. In terms of size, I think that 32-bits is plenty. We can't defend against active modification, so this only exists to winnow out Internet noise. The combination of this AND the UDP checksum should be plenty, even if the UDP checksum is basically ineffectual. If speed is a determining factor, then Murmur is much faster. Though FNV-1a is *slightly* faster on some benchmarks I've seen (not all - the one I ran was 15% slower than CRC), most of those concentrate on the 32-bit variants so that they can do like-for-like comparisons. The 128-bit variant probably requires uint128_t support for performance and that's not widespread. If we wanted to reuse code, we could use GHASH (which is part of AES-GCM) or Poly1305 (part of ChaCha20-Poly1305). Or we could encrypt with a fixed key. But I don't see the point in either of these which are considerably more complicated. Final question for those who made it this far: should we bind the hash to the version? We can claim that the hash is always the same for any QUIC version, which would allow a receiver to validate the hash even if it didn't support the selected version. Or we could say that version determines which hash is in use. It seems reasonable to make the hash version-dependent. If the version was = corrupted, a receiver might end up using the wrong hash algorithm, but the = chances of a collision there seem quite low. My 2c: document FNV-1a, since that adds no work for existing QUIC implement= ations, and make it version-dependent so the bikeshed is around later. - jana --_000_10faec2f2c0344cc8ac511fded3a36cdusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No strong options here, especially on the choice of the fu= nction. I have some preference for standardizing it across versions, so a s= erver that got a packet with an unknown version can figure out whether it got a corrupt packet (that it should dro= p) or just an unsupported version (so it should continue with version negot= iation).

- Igor

-----Original Message-----
From: Jana Iyengar [jri@google.com]
Received: Tuesday, 28 Feb 2017, 9:59PM
To: Martin Thomson [martin.thomson@gmail.com]
CC: IETF QUIC WG [quic@ietf.org]
Subject: Re: Bike shed warning: integrity check for unprotected pack= ets
I do not have a strong opinion on this issue, but I'll not= e that there's running code doing FNV-1a: it is what's used by Google = QUIC and QuicGo implementations. It was supposed to be in the original inpu= t spec to the wg, but we forgot to mention it. This hash is only computed on cleartext packets (handshake packets), s= o I don't think the compute difference between the algorithms or hardware s= upport matters. One correction and one comment below:

On Tue, Feb 28, 2017 at 6:29 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
I would like to close https://github.com/quicwg/base-drafts/issues/167

However, I'd like to only close it once.  So I'd like to have a small<= br> amount of discussion about the hash function we use.  Hopefully we
only have that discussion once also.

These are the choices I think are reasonable (drawing on the reams of
literature out there):

FNV-1a @128 bits [https://tools.ietf.org/html/draft-eastlake-fnv-03]
CRC32 [ITU-T Recommendation V.42]
Murmur3 [http= s://github.com/aappleby/smhasher/wiki/MurmurHash3]
GHASH [RFC 5116] or Poly1305 [RFC 7539] with a fixed key
AES-GCM or ChaCha20-Poly1305 with a fixed key

GQUIC currently uses a 128-bit variant of FNV-1a.  I'm guessing that this was simply the best available at the time.

In all cases, the cost of these is essentially zero (it's possible
that a 128-bit version is slower, but I couldn't find any benchmarks
and it's probably still close to zero).  In my view, we should not
making this decision on performance grounds.

I have a preference for CRC32.  It's what SCTP uses (see RFC 3309).

Not that it matters, but SCTP uses CRC-32c. It's only slightly differe= nt from CRC-32, but different enough that there's lesser hardware support f= or CRC-32c.

It's smaller.  It's well documented and very widely implemented. = It's
got hardware support in both Intel and ARM chips, if you care about
saving cycles (pro tip: you should not).  It's not perfect for picking=
a bucket in a hash table, though it's not bad for that purpose.
Rather, it is designed specifically for detecting errors in
transmission, i.e., exactly what we need.

In terms of size, I think that 32-bits is plenty.  We can't defend
against active modification, so this only exists to winnow out
Internet noise.  The combination of this AND the UDP checksum should be plenty, even if the UDP checksum is basically ineffectual.

If speed is a determining factor, then Murmur is much faster.  Though<= br> FNV-1a is *slightly* faster on some benchmarks I've seen (not all -
the one I ran was 15% slower than CRC), most of those concentrate on
the 32-bit variants so that they can do like-for-like comparisons.
The 128-bit variant probably requires uint128_t support for
performance and that's not widespread.

If we wanted to reuse code, we could use GHASH (which is part of
AES-GCM) or Poly1305 (part of ChaCha20-Poly1305).  Or we could encrypt=
with a fixed key.  But I don't see the point in either of these which<= br> are considerably more complicated.

Final question for those who made it this far: should we bind the hash
to the version?  We can claim that the hash is always the same for any=
QUIC version, which would allow a receiver to validate the hash even
if it didn't support the selected version.  Or we could say that
version determines which hash is in use.

It seems reasonable to make the hash version-dependent. If the version= was corrupted, a receiver might end up using the wrong hash algorithm, but= the chances of a collision there seem quite low.

My 2c: document FNV-1a, since that adds no work for existing QUIC impl= ementations, and make it version-dependent so the bikeshed is around later.=
- jana


--_000_10faec2f2c0344cc8ac511fded3a36cdusma1exdag1mb5msgcorpak_-- From nobody Tue Feb 28 20:55:21 2017 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 4A28E12949A for ; Tue, 28 Feb 2017 20:55:20 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0qpp12cUYzg5 for ; Tue, 28 Feb 2017 20:55:18 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5681B129445 for ; Tue, 28 Feb 2017 20:55:18 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n186so51540144qkb.3 for ; Tue, 28 Feb 2017 20:55:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8aoU8ZE5I6nX1wHLaWG7taKBsZMp9w6JUJi/iuU1CBw=; b=Orkz560ltsbDxJjs7/TSZtwJuq8qNb0oYBJaAaOy/VyLNBrElmIYc35PGE3zbhHqKB 5cN6cmemIXX8tS752r0hq0QQ53nGkCIRWCFggYlzt1tnHo3Lifowftm8A98U8xsRIa/U X19P90mk/oVull2DYcpPpYwoeQc922XiyCa5KOc2khACgxs1MziIih43ouC1fz7ePR02 d67+08x9mc9+21IM96KTSLvp5tlhTFlwMePrdQM1IfYo0UR2SnMKrXz8e956lTbi5bJ+ iDtgcyMRt+JhzidzH9CIBTcYdji68qXPoZgeHg+rN3XEnh79dae4Sl8pEaRvL+7ORtrG X+uQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8aoU8ZE5I6nX1wHLaWG7taKBsZMp9w6JUJi/iuU1CBw=; b=mAdH9qebiGqdhOoiVqylw0THDhP47d8agznVXT4CMlY9hlqt5xwW7IFZf3fmdkMA30 vLlu21KTHYCREinAHFgOKL4wJ8My7ArwzxHLePLin5zBO4Yki94GqZP3Bt5WUW2TXTLa ThFInKxBho3P5UZyGr3P9szbUkTHEfY8K6DRfiyARsjQ0XNB9UBNIBp5wYUiyoiPKB3F zPEu28ma02QM+qCSb8qC8+D+J/ChSZPKnshuOGuKYb3mRxI5T+9+Y7CKiutzQIvorCC5 ZiG9mppyGUELEz9SwgETqyKNC0NfieyxyqCu5Ey9pT0TO/FszBPmcvwutRuvjWP2FfDz hjBA== X-Gm-Message-State: AMke39lJ/q1jMxr3DPTD6CNsviUm1hhzAYFWWpI/h7evnXpTvx6dOWKS1uKaN1t7sEL74mrxc/ccypydz06IG0Fr X-Received: by 10.55.221.1 with SMTP id n1mr7041859qki.221.1488344117376; Tue, 28 Feb 2017 20:55:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.47.4 with HTTP; Tue, 28 Feb 2017 20:55:16 -0800 (PST) In-Reply-To: References: From: Victor Vasiliev Date: Tue, 28 Feb 2017 23:55:16 -0500 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1149d7dc6c0ace0549a41e34 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 04:55:20 -0000 --001a1149d7dc6c0ace0549a41e34 Content-Type: text/plain; charset=UTF-8 I am not entirely clear -- are you suggesting to use CRC-32 (as defined in V.42), or CRC-32Cc (as used in SCTP)? My personal preference here lies with the algorithms which can be implemented on a typical CPU without a lookup table -- that is to say, not CRC or GHASH. GHASH might be fine since it's MTI for TLS anyways. On Tue, Feb 28, 2017 at 9:29 PM, Martin Thomson wrote: > I would like to close https://github.com/quicwg/base-drafts/issues/167 > > However, I'd like to only close it once. So I'd like to have a small > amount of discussion about the hash function we use. Hopefully we > only have that discussion once also. > > These are the choices I think are reasonable (drawing on the reams of > literature out there): > > FNV-1a @128 bits [https://tools.ietf.org/html/draft-eastlake-fnv-03] > CRC32 [ITU-T Recommendation V.42] > Murmur3 [https://github.com/aappleby/smhasher/wiki/MurmurHash3] > GHASH [RFC 5116] or Poly1305 [RFC 7539] with a fixed key > AES-GCM or ChaCha20-Poly1305 with a fixed key > > GQUIC currently uses a 128-bit variant of FNV-1a. I'm guessing that > this was simply the best available at the time. > > In all cases, the cost of these is essentially zero (it's possible > that a 128-bit version is slower, but I couldn't find any benchmarks > and it's probably still close to zero). In my view, we should not > making this decision on performance grounds. > > I have a preference for CRC32. It's what SCTP uses (see RFC 3309). > It's smaller. It's well documented and very widely implemented. It's > got hardware support in both Intel and ARM chips, if you care about > saving cycles (pro tip: you should not). It's not perfect for picking > a bucket in a hash table, though it's not bad for that purpose. > Rather, it is designed specifically for detecting errors in > transmission, i.e., exactly what we need. > > In terms of size, I think that 32-bits is plenty. We can't defend > against active modification, so this only exists to winnow out > Internet noise. The combination of this AND the UDP checksum should > be plenty, even if the UDP checksum is basically ineffectual. > > If speed is a determining factor, then Murmur is much faster. Though > FNV-1a is *slightly* faster on some benchmarks I've seen (not all - > the one I ran was 15% slower than CRC), most of those concentrate on > the 32-bit variants so that they can do like-for-like comparisons. > The 128-bit variant probably requires uint128_t support for > performance and that's not widespread. > > If we wanted to reuse code, we could use GHASH (which is part of > AES-GCM) or Poly1305 (part of ChaCha20-Poly1305). Or we could encrypt > with a fixed key. But I don't see the point in either of these which > are considerably more complicated. > > Final question for those who made it this far: should we bind the hash > to the version? We can claim that the hash is always the same for any > QUIC version, which would allow a receiver to validate the hash even > if it didn't support the selected version. Or we could say that > version determines which hash is in use. > > --001a1149d7dc6c0ace0549a41e34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am not entirely clear -- are you suggesting to use CRC-3= 2 (as defined in V.42), or CRC-32Cc (as used in SCTP)?

M= y personal preference here lies with the algorithms which can be implemente= d on a typical CPU without a lookup table -- that is to say, not CRC or GHA= SH.=C2=A0 GHASH might be fine since it's MTI for TLS anyways.

On Tue, Feb 28,= 2017 at 9:29 PM, Martin Thomson <martin.thomson@gmail.com><= /span> wrote:
I would like to close https://github.com/quicwg/base-drafts/issues/167=

However, I'd like to only close it once.=C2=A0 So I'd like to have = a small
amount of discussion about the hash function we use.=C2=A0 Hopefully we
only have that discussion once also.

These are the choices I think are reasonable (drawing on the reams of
literature out there):

FNV-1a @128 bits [https://tools.ietf.org/html/= draft-eastlake-fnv-03]
CRC32 [ITU-T Recommendation V.42]
Murmur3 [https://github.com/aappleby/smhas= her/wiki/MurmurHash3]
GHASH [RFC 5116] or Poly1305 [RFC 7539] with a fixed key
AES-GCM or ChaCha20-Poly1305 with a fixed key

GQUIC currently uses a 128-bit variant of FNV-1a.=C2=A0 I'm guessing th= at
this was simply the best available at the time.

In all cases, the cost of these is essentially zero (it's possible
that a 128-bit version is slower, but I couldn't find any benchmarks and it's probably still close to zero).=C2=A0 In my view, we should not=
making this decision on performance grounds.

I have a preference for CRC32.=C2=A0 It's what SCTP uses (see RFC 3309)= .
It's smaller.=C2=A0 It's well documented and very widely implemente= d.=C2=A0 It's
got hardware support in both Intel and ARM chips, if you care about
saving cycles (pro tip: you should not).=C2=A0 It's not perfect for pic= king
a bucket in a hash table, though it's not bad for that purpose.
Rather, it is designed specifically for detecting errors in
transmission, i.e., exactly what we need.

In terms of size, I think that 32-bits is plenty.=C2=A0 We can't defend=
against active modification, so this only exists to winnow out
Internet noise.=C2=A0 The combination of this AND the UDP checksum should be plenty, even if the UDP checksum is basically ineffectual.

If speed is a determining factor, then Murmur is much faster.=C2=A0 Though<= br> FNV-1a is *slightly* faster on some benchmarks I've seen (not all -
the one I ran was 15% slower than CRC), most of those concentrate on
the 32-bit variants so that they can do like-for-like comparisons.
The 128-bit variant probably requires uint128_t support for
performance and that's not widespread.

If we wanted to reuse code, we could use GHASH (which is part of
AES-GCM) or Poly1305 (part of ChaCha20-Poly1305).=C2=A0 Or we could encrypt=
with a fixed key.=C2=A0 But I don't see the point in either of these wh= ich
are considerably more complicated.

Final question for those who made it this far: should we bind the hash
to the version?=C2=A0 We can claim that the hash is always the same for any=
QUIC version, which would allow a receiver to validate the hash even
if it didn't support the selected version.=C2=A0 Or we could say that version determines which hash is in use.


--001a1149d7dc6c0ace0549a41e34-- From nobody Tue Feb 28 21:26:41 2017 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 F26C7129407 for ; Tue, 28 Feb 2017 21:26:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 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=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 d6qpclmkatvW for ; Tue, 28 Feb 2017 21:26:39 -0800 (PST) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::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 CE0B5120726 for ; Tue, 28 Feb 2017 21:26:38 -0800 (PST) Received: by mail-ua0-x232.google.com with SMTP id x24so34587563uab.0 for ; Tue, 28 Feb 2017 21:26:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WfgN8Knse/qvJk5HbAkqXoDHfBD5F2Zn+3fxv0cj2ns=; b=dywe95R9r/ACKwVAEzNJ9WbgV1+lFYSVrO0C4CQ+Cooe8oapZ1CrCBJoTdCRfYAn4L gbaOf5zyTkjjKr3Qhhfi5a8fiFNrBOGHrb026cv+t7SJymChbbSe+SXZfG+hvlk2pdKw xZNQspaVrem0cJWYe7hQCqPzAALblT9tjziWSRBN5qkZkQnfbIhTnNJsMSxNp5jYCPP4 suSGkDqlsj029iqxvRxj/BUQu47jhTGvXRS5IsayGF1r3XZr3M9xRJffyC9lh9MH5xuo su1R7w9jzVIjXlFIsgWN2ySCG3hRnZ4WQmG/uVOj0dtG1REo/edwGvhgnZDyeJV6xTnN dNjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WfgN8Knse/qvJk5HbAkqXoDHfBD5F2Zn+3fxv0cj2ns=; b=c+zN2uOUGV4YIBqnb9stcxOXVzF/vWwv60vdYBeGjIBIVRDk5LaBE9imDVDP1BcdIx pFtwH6AUrBgSn1hPRWI+0j//Nk6hIog6OxQnwMiBEzFlRiMam8OuaR/mvh1OetzMrcW8 6lmts5MoeShIftpsa6eDLbjE26rX3HPW8aNZ2BgRYnX/A+GGOymWQpqM4nY6ZplqGst5 mqGk+k2sRkORUusjQEUrnTdAcbhFdw21AstPu9rMrj/Ep5QpKGeRIEg/Ppp+k2nObQ0w bgakuoYWqW8qtNfTKDGqqd3OojQrdG+q/MrE+SM1kde7CbXVVKPVqsFUlL4GNClowFjt HrrQ== X-Gm-Message-State: AMke39lk0UDHCU9kLDkYcGsT86Aq+Gbiv9zJEGKmj5Z8tRYB6KUmIPOmzOzzsXrNgMjpnruqTwO0XyHbFKPoCjng X-Received: by 10.176.2.71 with SMTP id 65mr706389uas.155.1488345997597; Tue, 28 Feb 2017 21:26:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Tue, 28 Feb 2017 21:26:37 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 28 Feb 2017 21:26:37 -0800 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11428a367db9140549a48e34 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 05:26:40 -0000 --001a11428a367db9140549a48e34 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 28, 2017 at 7:16 PM, Martin Thomson wrote: > On 1 March 2017 at 13:59, Jana Iyengar wrote: > > My 2c: document FNV-1a, since that adds no work for existing QUIC > > implementations, and make it version-dependent so the bikeshed is around > > later. > > > The reason I opened this thread is to avoid a bikeshed buildup. If > you want to argue for FNV-1a-128, then let's hear the argument. > Current QUIC implementations do FNV-1a-128. Admittedly not the strongest argument, but I don't think I've heard a strong argument to change the status quo either. (I agree with you about binding hash to version. The faintest hint of > any dispute about suitability argues for that.) > --001a11428a367db9140549a48e34 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 28, 2017 at 7:16 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 1 March 2017 at 13:59, Jana Iyengar <jri@google.com> wrote:
> My 2c: document FNV-1a, since that adds no work for existing QUIC
> implementations, and make it version-dependent so the bikeshed is arou= nd
> later.


The reason I opened this thread is to avoid a bikeshed buildup.=C2= =A0 If
you want to argue for FNV-1a-128, then let's hear the argument.

Current QUIC implementations do FNV-1a-128. Ad= mittedly not the strongest argument, but I don't think I've heard a= strong argument to change the status quo either.

(I agree with you about binding hash to version.=C2=A0 The faintest hint of=
any dispute about suitability argues for that.)

--001a11428a367db9140549a48e34-- From nobody Tue Feb 28 21:28:48 2017 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 3104A129407 for ; Tue, 28 Feb 2017 21:28:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 0kDrNLse_pbi for ; Tue, 28 Feb 2017 21:28:44 -0800 (PST) Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 B9988120726 for ; Tue, 28 Feb 2017 21:28:43 -0800 (PST) Received: by mail-ua0-x233.google.com with SMTP id q7so3752690uaf.2 for ; Tue, 28 Feb 2017 21:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NQ6iK1uJIeJHlK/4qQEKh2NvB2ixjBNWYE5kXFs4xzg=; b=pE3Ho1WDO21aUUaR7pr3sgKFEY2+jHB+5aYUfhP98DS59R9LR8C8w932i7JXA3S1jv I4DUFxWICJIdwcy+30UoUJrAdIcZlvzddjPnjV6LH9Vp2PtNfc4bNVvxupkOcTS/O5Ea AlSOtLRU+1HAMA2H0d7dA4Vx1PJpMV2972RLyJPIh+C6DmoDDnWbYW32iJ3XWDdpZZf8 qRgdQPux/916whyjDmbPgTViT2jd7Go+4vshQ77H1MdRKcVae17gba2p1Ms6vwryRhmE OsnhfCglJtbCouCP68Gv3rCVrmOgmK2j3nR2diEc7eLk7PP/E+qzAnjrbDpsWucv/pip JkCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NQ6iK1uJIeJHlK/4qQEKh2NvB2ixjBNWYE5kXFs4xzg=; b=scYZybC07yujazXaQcqt7WScvfxFPQFw/IJbg6DK+q8pWLbx5b3GnSAuzDOqlUwg2E mFGq/pv2M9SA4MXRWqU/6yPNVKqGcIWWc0i8ZBN5eEmHpQjkBu+60wfbWXG/CUL9MULy bHJ+EboYi7pgiZKknX4yWL349p+HTzVKIM63VbaoDF1/OhMIHSp/fX7xqNlBYNfYP6qX QisFtlqz+C/p4v9fX8J8xeUKFgLQzugu2oqWOSWYXIpKQYhYL2oXZJzXNS8oqjgR903T A+/yrzqUH1p35P/k4K9TN9P0WDKDvjUnLs+vkgtdja38RyfeqQjxAE739ola8Tz8dzy/ LhNg== X-Gm-Message-State: AMke39nqMXTMFTB0OxHbehZ4U9AxVNrHIwRXkev2wzIefDRNnONdoC6xM51WRuTyB9A4xSHjlR7LFgvwjtL19U6L X-Received: by 10.176.80.72 with SMTP id z8mr3076990uaz.139.1488346122593; Tue, 28 Feb 2017 21:28:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Tue, 28 Feb 2017 21:28:42 -0800 (PST) In-Reply-To: <10faec2f2c0344cc8ac511fded3a36cd@usma1ex-dag1mb5.msg.corp.akamai.com> References: <10faec2f2c0344cc8ac511fded3a36cd@usma1ex-dag1mb5.msg.corp.akamai.com> From: Jana Iyengar Date: Tue, 28 Feb 2017 21:28:42 -0800 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: "Lubashev, Igor" Content-Type: multipart/alternative; boundary=94eb2c192556f0e8050549a4958e Archived-At: Cc: "quic@ietf.org" , "martin.thomson@gmail.com" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 05:28:46 -0000 --94eb2c192556f0e8050549a4958e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2017 at 7:21 PM, Lubashev, Igor wrote= : > No strong options here, especially on the choice of the function. I have > some preference for standardizing it across versions, so a server that go= t > a packet with an unknown version can figure out whether it got a corrupt > packet (that it should drop) or just an unsupported version (so it should > continue with version negotiation). > That's a good point... I hadn't thought about the responses being different (drop vs. send version negotiation.) Perhaps that's a good reason to keep this fixed across versions. > > - Igor > > > -----Original Message----- > *From:* Jana Iyengar [jri@google.com] > *Received:* Tuesday, 28 Feb 2017, 9:59PM > *To:* Martin Thomson [martin.thomson@gmail.com] > *CC:* IETF QUIC WG [quic@ietf.org] > *Subject:* Re: Bike shed warning: integrity check for unprotected packets > > I do not have a strong opinion on this issue, but I'll note that there's > running code doing FNV-1a: it is what's used by Google QUIC and QuicGo > implementations. It was supposed to be in the original input spec to the > wg, but we forgot to mention it. This hash is only computed on cleartext > packets (handshake packets), so I don't think the compute difference > between the algorithms or hardware support matters. One correction and on= e > comment below: > > On Tue, Feb 28, 2017 at 6:29 PM, Martin Thomson > wrote: > >> I would like to close https://github.com/quicwg/base-drafts/issues/167 >> >> >> However, I'd like to only close it once. So I'd like to have a small >> amount of discussion about the hash function we use. Hopefully we >> only have that discussion once also. >> >> These are the choices I think are reasonable (drawing on the reams of >> literature out there): >> >> FNV-1a @128 bits [https://tools.ietf.org/html/draft-eastlake-fnv-03 >> >> ] >> CRC32 [ITU-T Recommendation V.42] >> Murmur3 [https://github.com/aappleby/smhasher/wiki/MurmurHash3 >> >> ] >> GHASH [RFC 5116] or Poly1305 [RFC 7539] with a fixed key >> AES-GCM or ChaCha20-Poly1305 with a fixed key >> >> GQUIC currently uses a 128-bit variant of FNV-1a. I'm guessing that >> this was simply the best available at the time. >> >> In all cases, the cost of these is essentially zero (it's possible >> that a 128-bit version is slower, but I couldn't find any benchmarks >> and it's probably still close to zero). In my view, we should not >> making this decision on performance grounds. >> >> I have a preference for CRC32. It's what SCTP uses (see RFC 3309). > > > Not that it matters, but SCTP uses CRC-32c. It's only slightly different > from CRC-32, but different enough that there's lesser hardware support fo= r > CRC-32c. > > It's smaller. It's well documented and very widely implemented. It's >> got hardware support in both Intel and ARM chips, if you care about >> saving cycles (pro tip: you should not). It's not perfect for picking >> a bucket in a hash table, though it's not bad for that purpose. >> Rather, it is designed specifically for detecting errors in >> transmission, i.e., exactly what we need. >> >> In terms of size, I think that 32-bits is plenty. We can't defend >> against active modification, so this only exists to winnow out >> Internet noise. The combination of this AND the UDP checksum should >> be plenty, even if the UDP checksum is basically ineffectual. >> >> If speed is a determining factor, then Murmur is much faster. Though >> FNV-1a is *slightly* faster on some benchmarks I've seen (not all - >> the one I ran was 15% slower than CRC), most of those concentrate on >> the 32-bit variants so that they can do like-for-like comparisons. >> The 128-bit variant probably requires uint128_t support for >> performance and that's not widespread. >> >> If we wanted to reuse code, we could use GHASH (which is part of >> AES-GCM) or Poly1305 (part of ChaCha20-Poly1305). Or we could encrypt >> with a fixed key. But I don't see the point in either of these which >> are considerably more complicated. >> >> Final question for those who made it this far: should we bind the hash >> to the version? We can claim that the hash is always the same for any >> QUIC version, which would allow a receiver to validate the hash even >> if it didn't support the selected version. Or we could say that >> version determines which hash is in use. >> > > It seems reasonable to make the hash version-dependent. If the version wa= s > corrupted, a receiver might end up using the wrong hash algorithm, but th= e > chances of a collision there seem quite low. > > My 2c: document FNV-1a, since that adds no work for existing QUIC > implementations, and make it version-dependent so the bikeshed is around > later. > - jana > > > --94eb2c192556f0e8050549a4958e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 28, 2017 at 7:21 PM, Lubashev, Igor <ilubashe@akamai.com&g= t; wrote:
No strong options here, especially on the choice of the func= tion. I have some preference for standardizing it across versions, so a ser= ver that got a packet with an unknown version can figure out whether it got a corrupt packet (that it should dro= p) or just an unsupported version (so it should continue with version negot= iation).

That's a good poi= nt... I hadn't thought about the responses being different (drop vs. se= nd version negotiation.) Perhaps that's a good reason to keep this fixe= d across versions.

=C2=A0

- Igor


-----Original Message-----
From: Jana Iyengar [jri@google.com]
Received: Tuesday, 28 Feb 2017, 9:59PM
To: Martin Thomson [martin.thomson@gmail.com]
CC: IETF QUIC WG [quic@ietf.org]
Subject: Re: Bike shed warning: integrity check for unprotected pack= ets

I do not have a strong opinion on this issue, but I'll= note that there's running code doing FNV-1a:=C2=A0it is what's use= d by Google QUIC and QuicGo implementations. It was supposed to be in the o= riginal input spec to the wg, but we forgot to mention it. This hash is only computed on cleartext packets (handshake packets), s= o I don't think the compute difference between the algorithms or hardwa= re support matters. One correction and one comment below:

On Tue, Feb 28, 2017 at 6:29 PM, Martin Thomson = <martin.th= omson@gmail.com> wrote:
I would like to close https://github.com/quicwg/base-drafts/issues/167

However, I'd like to only close it once.=C2=A0 So I'd like to have = a small
amount of discussion about the hash function we use.=C2=A0 Hopefully we
only have that discussion once also.

These are the choices I think are reasonable (drawing on the reams of
literature out there):

FNV-1a @128 bits [https://tools.ietf.org/html/draft-eastlake-fnv-03]
CRC32 [ITU-T Recommendation V.42]
Murmur3 [http= s://github.com/aappleby/smhasher/wiki/MurmurHash3]
GHASH [RFC 5116] or Poly1305 [RFC 7539] with a fixed key
AES-GCM or ChaCha20-Poly1305 with a fixed key

GQUIC currently uses a 128-bit variant of FNV-1a.=C2=A0 I'm guessing th= at
this was simply the best available at the time.

In all cases, the cost of these is essentially zero (it's possible
that a 128-bit version is slower, but I couldn't find any benchmarks and it's probably still close to zero).=C2=A0 In my view, we should not=
making this decision on performance grounds.

I have a preference for CRC32.=C2=A0 It's what SCTP uses (see RFC 3309)= .

Not that it matters, but SCTP uses CRC-32c. It's only slightly dif= ferent from CRC-32, but different enough that there's lesser hardware s= upport for CRC-32c.

It's smaller.=C2=A0 It's well documented and very widely implemente= d.=C2=A0 It's
got hardware support in both Intel and ARM chips, if you care about
saving cycles (pro tip: you should not).=C2=A0 It's not perfect for pic= king
a bucket in a hash table, though it's not bad for that purpose.
Rather, it is designed specifically for detecting errors in
transmission, i.e., exactly what we need.

In terms of size, I think that 32-bits is plenty.=C2=A0 We can't defend=
against active modification, so this only exists to winnow out
Internet noise.=C2=A0 The combination of this AND the UDP checksum should be plenty, even if the UDP checksum is basically ineffectual.

If speed is a determining factor, then Murmur is much faster.=C2=A0 Though<= br> FNV-1a is *slightly* faster on some benchmarks I've seen (not all -
the one I ran was 15% slower than CRC), most of those concentrate on
the 32-bit variants so that they can do like-for-like comparisons.
The 128-bit variant probably requires uint128_t support for
performance and that's not widespread.

If we wanted to reuse code, we could use GHASH (which is part of
AES-GCM) or Poly1305 (part of ChaCha20-Poly1305).=C2=A0 Or we could encrypt=
with a fixed key.=C2=A0 But I don't see the point in either of these wh= ich
are considerably more complicated.

Final question for those who made it this far: should we bind the hash
to the version?=C2=A0 We can claim that the hash is always the same for any=
QUIC version, which would allow a receiver to validate the hash even
if it didn't support the selected version.=C2=A0 Or we could say that version determines which hash is in use.

It seems reasonable to make the hash version-dependent. If the version= was corrupted, a receiver might end up using the wrong hash algorithm, but= the chances of a collision there seem quite low.

My 2c: document FNV-1a, since that adds no work for existing QUIC impl= ementations, and make it version-dependent so the bikeshed is around later.=
- jana



--94eb2c192556f0e8050549a4958e-- From nobody Tue Feb 28 21:45:04 2017 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 26972127058 for ; Tue, 28 Feb 2017 21:45:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=itaoyama.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iBoShj13xcvE for ; Tue, 28 Feb 2017 21:45:00 -0800 (PST) Received: from JPN01-OS2-obe.outbound.protection.outlook.com (mail-os2jpn01on0131.outbound.protection.outlook.com [104.47.92.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16ED2120726 for ; Tue, 28 Feb 2017 21:44:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itaoyama.onmicrosoft.com; s=selector1-it-aoyama-ac-jp; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=8+qAVGgSBlWk+PxYKSgeu0jhP/Tgekyox2pmuk2SkLs=; b=e1TCZOwSTBu3eslcA4oee6cv3w18Q/xqVkiFQVImf5JZbASfswzzTqdpgik+3OQUOD5EaKUy5k76573T8lkvuBn+14DkkkvFv4qaaOT1/W7T1gpFfVM4wGZD823F2ZhxpX0D89wdzep/lD1mMpkzTaF7MN1PHy0U5sEIlPpN5IU= Authentication-Results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=it.aoyama.ac.jp; Received: from [133.2.210.64] (133.2.210.64) by TY1PR01MB0651.jpnprd01.prod.outlook.com (10.167.158.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Wed, 1 Mar 2017 05:44:55 +0000 Subject: Re: Bike shed warning: integrity check for unprotected packets To: Jana Iyengar , "Lubashev, Igor" References: <10faec2f2c0344cc8ac511fded3a36cd@usma1ex-dag1mb5.msg.corp.akamai.com> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <777f24af-6192-dd3e-dd2a-1e3a41ea5b66@it.aoyama.ac.jp> Date: Wed, 1 Mar 2017 14:44:52 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: KAWPR01CA0063.jpnprd01.prod.outlook.com (10.174.229.151) To TY1PR01MB0651.jpnprd01.prod.outlook.com (10.167.158.14) X-MS-Office365-Filtering-Correlation-Id: 417caa0d-83df-4dbe-faf3-08d46066174d X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:TY1PR01MB0651; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 3:0lfwn+kCRLkaBFEF4XDvjrafMnJw/j9FsDOLqHcVwZZvn2yVE2za9JFQIjIROSyy2oqk5SFkPWw9Ka/I2SFk8iCBqeW+LBiZBaRM2ZFci53HOPRqvi+TSCjiX7VN3blAdRrbfveyhnVp7BKOGh3jZzurSMGV6lV1QiHoQXE0qt33eYXkFe0bhD4XcNMWvJX+JqTp177RAdSYu1ltZqv4j0FiOcn5oCzqOc9L3kv7LEng6nzpf8356Dem7NKPg1kErc2KRcPER+jXdXxWPGHpwA==; 25:i4XXsvQbRgGiECMLDoyiTvJ/Yf+tcAueHzqABcJDvgoim52QtlXM5C+i1Iu0H8G0hx7o/J9979tNLQBnORfXxaeYn15SGjtGEna6Fz42lG8PQTeSOJQ77/xQJl3Bjw6VQVIWVa69VrBHOwNyn8apkllwFHBC3m7ozD6lYCyU1l7C0p91+oCwZrd4GipG8yu0AXVi+9VtNFI9EC6XGffVNdSAlLvNiDIPEAs039jI2cUF6IUY2Pobi5K0aOvHsej8/ok4GxZasMncMy8LBPHQOUK2Zx7lcta1ZOzS2+KASYfGrhvNUma7ZgMZ/VyjowzrNzAfB/TRXbc6DaQ9LJFnOp1QHxZYiwDslxR6oVshjhl338sueEwDFnQY2A3GePkZPIU5Qj0Sn96IbXCFk8V8pa6/Lc2ZMKAyZgulVqZ4IkHvy6lxNRkEsAu6iBYIvbf9hcgVGHGSB9elKMJLC+zoGg== X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 31:g1OTGVi2sMmp7lvkWHCCMz3P327PC8XpmmZy5TFDP2sgMIM0JWFM9q1Nzlr4LkdmnIRhmA8U8ZVZbqRr4dmQTisEFNRB/Ks0LJAzM9IdnewzwzwzvcBVlnnWwbnySui5T64OVW4e+FnRoFiL72UEOPHQa+aZGrrH/dTMPC4SLhGmea0WcFUslBPRVfliJF6cy896gsoFjyZn9FEChRprJQHoHnXBMAHAkVkQwTPd12MAHnkp+MCiLZvMBagSTlTeWF/HKxsOKSYG/uHGjrXM4s013fouYvXI0qy3N/zxw2I= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123558025)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148); SRVR:TY1PR01MB0651; BCL:0; PCL:0; RULEID:; SRVR:TY1PR01MB0651; X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 4:ASYJu0UfD0JgWpccup3gaqawgUL1YAfMLR04AtFj+0P8XPMEPukL4a2xoW2BhTTXxoty7lOXXNoDSZh0ijNsCSGKlb15K/afvf3xMGEueRiXU+kGGMTvkmowYjgNDCgzRXfBLmnW0nZvPFlVY/wPYyH/3a8aA+tn/gnTgEvzJUtg2Yy+fjVcK7xwQp76/nQqfu8NLZOScf5WAOwKbcpVV0RiK4Mbc9aqjf4lx/GxMAwIIEmCfyqqQzvrEDwcsIPPWAVuMS8rteJTb/l2pRCJd92+a4vZCWWa91cNzVLrXIPbNm15+XYep6EAaZjE3S/Qw+sHvP3asbap+o3GHL20+TBxq8aWnl4QDdaHk4kb2LuFqNv87shHDsN6TJZJeKwO57ky28yalOaYU0QI9uxDl7SSSc9TRsTaH625KiBcJOm0bIQoSaWu7mOjmIPwvoPkk3ZIkcC03rPiQ5JKITqTSOilRYQGuuwyzoxuf3KHBC+2IRPnGFMQa9yQJ+G/EmP6FZsJYR0U2229/X48htkriO7IiJXGoLQJ+SZJDp9tBxLf8SrwI02EQEtJS8yUPGKhm+Zo2fD3gH5YTk1H1F1w+AvWoIAAwp63hvGFQ/ggVV9qIZH/kP847HlAPW6v8flumv7k/fKRkRvIubufXFhKEw== X-Forefront-PRVS: 0233768B38 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(39450400003)(377454003)(24454002)(3846002)(31696002)(86362001)(50466002)(6116002)(42882006)(2950100002)(93886004)(81166006)(7736002)(25786008)(8676002)(5660300001)(54356999)(50986999)(76176999)(305945005)(47776003)(65956001)(65806001)(66066001)(53936002)(230700001)(83506001)(229853002)(90366009)(74482002)(4326008)(38730400002)(189998001)(4001350100001)(6486002)(31686004)(42186005)(2906002)(33646002)(92566002)(6666003)(6246003)(64126003)(23676002)(53546006)(54906002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:TY1PR01MB0651; H:[133.2.210.64]; FPR:; SPF:None; MLV:sfv; LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtUWTFQUjAxTUIwNjUxOzIzOlVzZEgxTjc2UVdYNEhqZm0vNHJ2WllLanVu?= =?utf-8?B?TTRMdC85c3duTXJENDNPWG4ybHpwVm1CTHBvdTZPek01TXJLMnZiMEpXUEZI?= =?utf-8?B?Nm9UQmMzQ2E3MTRkTTRJSW1GdnJRZ2ZKVXhndzcrTUx5aWtuZ3Z6aUljVjlt?= =?utf-8?B?U3Bzak9tMzJMdEVDMEN6OEhYOXQ1SmVhZGpsL0h0d2kxMlI3SEVRSC9mbGM0?= =?utf-8?B?R0hlRG5tZHVyK3E1NGN6eXJ2b0YxNFRIdXhacndkNVJxMWpHaVFELy9pMHFW?= =?utf-8?B?YlgvTURkVVd2MjUvZi9qOHJWbUFzKzF5c2xVSWFQOUZqdGRKT0xjWHZTOHJS?= =?utf-8?B?THZTdzhQMnRxWGFiZEVHd05pb3BNK1VlN1BUZDYrbGphWURJVVFLait0Wldr?= =?utf-8?B?cit2VmZHZWIyak43YmR3YlhaRmJYS0EyV0xsRnRSTmtxODlIWWk2QUw3REI1?= =?utf-8?B?Nm5IblV1N09kY2syNzc4QnkxeUxzRTdOSWxLVUZ4MUZMdEJYMDNSaUZieEh1?= =?utf-8?B?MmxEOS82ZjJrUzIycjF2WG9uTSszcFdpS21ZUVdsL2VqbDc4ZnJ4aXBKMVhm?= =?utf-8?B?STFoOXlkdG1YYm1OcVgrVy9ucTFaRHJZQ3JXUG5zeE1zekREdHRFdDRMU3Fh?= =?utf-8?B?NHhMR2ZPcnRGbGZQaFE2RVk4bWpOcUFCSytPa2s1K3FSemtVSjVEbHNHcUhD?= =?utf-8?B?VzV2RWNGNWluZi9keVZ5SVJLUmVUNS9oMzZUT0hjeHo4cFIrQ0p4ZHhoK0dx?= =?utf-8?B?WjJldy9Sc1dJUHZGRW9iNG4wL2dqK0VubGN4N0tTc0VCcFozOVZMbjAyaFky?= =?utf-8?B?M2dtM2NSd0F0UW9UTDczSjZ5aytnTm1hbk9lMWZMQjkrVVdTUEExcFRnYllk?= =?utf-8?B?QUo4VGNudWFmZzBEbmR1ZXgyaDVTeWdzRDl2VEszczNEOGFLTWI2VjF0USs1?= =?utf-8?B?U0dsSU52OHhwYU0xRUxnbXM5aFgwQVhXdUpLaEhvbnJZMUdyWWJ5ekhoNk1u?= =?utf-8?B?UWhMUTNyNjFXaEhCNDJhNmZoN0Ezd25PTHM3TEg1azdFUnMwMkI1ZU5nYW9X?= =?utf-8?B?czlhZlY1N3cwMk9tTEZHYUZKT2xjanAzZXZkQ0N6bzBXVnY0NVJmc05nbDd2?= =?utf-8?B?b1ZUZklFSWMxYzE0ZTMwNDQxMTB0UEJvVThnSC9VQnVZb1l4ZThIaHhocnVy?= =?utf-8?B?b3E0RE1yckkxMHFzaENMSjJpUUplelltQUYyekFINGJXWWJPMGwrV0FwUTFw?= =?utf-8?B?NXQvd3lwUGRyVWNscC9DM1VBMFdOaktjbks2aTM4VWp3dEJGenB0bTVKU0Vu?= =?utf-8?B?RFN3VXR1WVRaRmZiT3p0cDU1eXhpQ01WdDdBaEZDU0RjVHNnSGZUVTNya05Y?= =?utf-8?B?RjJ5Umo0MTFGZWk5b04zbEZ0TWRLRFEzQTd0b0FEbjNDclhMaVNuNit1ZE1u?= =?utf-8?B?L0RDR3lYU045d2ZTakdwR282bmc2NDMxZ2RjaTFtelg4aHRURDdLRmh5YkZT?= =?utf-8?B?MmJwOTllS2JxYUZOYXI4ZGNtTGVvWXN2YlIwZXFwcHNpS1pTaFhKTFpwNFNp?= =?utf-8?B?NnMzYVUvb2F4eWt6UitOMU9lcktzK09EQWc3R1NHOE1yTVlTZllzcjFnK08v?= =?utf-8?B?VE9NSGlKczllYVl1N2J5bHRNY0d2TUdFeGpuQWxYN2lrRW0wbHI2Z2NVY0xr?= =?utf-8?Q?DayNCo+YZxlAptstjw=3D?= X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 6:BjEolZnnjGJ4vLm9mhS6U2hu+6shy8LRuGkRRO4aKC1G6XLFyHzJYwMsqeWSBDkM0EuhFWQhtnh1fiQ+2DYmTUAXOjZ0hC6EjuuR+j4k4OqsIPMVWBhz4QIPP8G5Ao2fmLJ7YlYille2b9w1eALF8oMWLtcAYZc09No4a4kOsZp9UnZmjy532HSH3BQsY/ghs0TfgbKRFZ5muejYteIQwm/Wb0n5Y0k0YGdqdqnxeKdEyH/rTh+94HqQK/s2DrFKc2XBIUvoy+Toj45Tk1OSILrYYUyzpakWGT+YHnV5hzD+/nEOvY9gdLNyGYfYoIsT+lOz01jMPEQtGiRmzcKRnuzcjXc8Em3Bd5Uq0MPNh/aQWImM6AypuVu1SHcUFm02BAs4MEPrIqkGuHUyP6m3Tg==; 5:PLrBkHiAPLxq+dMwUqH2onG0y11ATW0aCgnv/sqhSVFTzh7ouIMbsiGf2BabQ19alUhzJQ2JkoIsxzBky8b58nRckj62dE8pBX7a5xXOE8r+D1gPSOKfA0z0zoyvEofGrZSAwPH9eZh1qJ6YlcXfjQ==; 24:A1rcEWj2+yvX94gU5PTu0y5fjy4x9ZK0yP0Dxl3KHWBWdMZWxgDaAy+g0qxm8KhT/gFkjVud/5Hc2j1cD84O0Va08l7sziwv54m8zHdbXC4= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; TY1PR01MB0651; 7:3R0P1puTNfjtuclJvkAhRSMbqr3yG5zCCtGYaqZFr3HhXOJdKk3QlYbfZ0yEm7icnBHmT0KMQIw7Zic4HtrExhX+c4JZpWEBjZshslp1taSDNaDJnBjcTfcinF4F+NJARGxYyRhRDRG4th5NLzAD4YeVisvgYKOJiQ4Hhn9KlStsXAacUByrsw875uwZhEJRqFkKpIQGqtmTMgljs9m7czmpZ0ahZqQKiU4nVVReaZRjz4IMnREtu1BWDIeNJt4pDE8p8ZbT3fqCpkXMCTcyrfkZhSOHjLGPnAV+pPsw5bDkt/TurmQfEEvM0awG1h6zIdmlGxSYhxRv2qZUQT2EKg== X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Mar 2017 05:44:55.6093 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: TY1PR01MB0651 Archived-At: Cc: "quic@ietf.org" , "martin.thomson@gmail.com" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 05:45:03 -0000 On 2017/03/01 14:28, Jana Iyengar wrote: > On Tue, Feb 28, 2017 at 7:21 PM, Lubashev, Igor wrote: > >> No strong options here, especially on the choice of the function. I have >> some preference for standardizing it across versions, so a server that got >> a packet with an unknown version can figure out whether it got a corrupt >> packet (that it should drop) or just an unsupported version (so it should >> continue with version negotiation). >> > > That's a good point... I hadn't thought about the responses being different > (drop vs. send version negotiation.) Perhaps that's a good reason to keep > this fixed across versions. Or, to be more precise, at least across the range of versions that we want version negotiation to happen. But that may be more precise than we need to care about now. Regards, Martin. From nobody Tue Feb 28 21:57:57 2017 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 92F3812943C for ; Tue, 28 Feb 2017 21:57:55 -0800 (PST) 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 E3_2JOxVcpHf for ; Tue, 28 Feb 2017 21:57:54 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC93127058 for ; Tue, 28 Feb 2017 21:57:54 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id n127so54538635qkf.0 for ; Tue, 28 Feb 2017 21:57:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NwOXcNazCa46wiRYdoQMy+PdaACL8EVaHYuPD9v0yek=; b=fvseEkhIszTLnqP5UhJ5G+hutNwUryzjzf3E9fAIgHoAnBry+8de7dRRIR0imUo+aP cdIppRho972eYVJ2QN/4pPz9HKWuMLLJEfQHSVHNiYGLeXrydKvjTEAKI9RDCgIKZqtD lBjRUx4HEInV92aAXVYfeNRt/uAR/aTJSADcQ0IqaXNh43wNv/YjX9V7MOeAGNgytX4W rF82viPs4e3qutqqhtQUrPvFzPbODhLcb5ojVcwMMeZprM9Ct8292nZA3iOd4mqAtZs/ vYXEiZKI1/Zuo4JalWUnSvt00YthA2O3HAPRQnuFc1wCI8u2nltnq/hA0I4xbCqeE2o+ s5WA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NwOXcNazCa46wiRYdoQMy+PdaACL8EVaHYuPD9v0yek=; b=dNlXZrcwzv5o3LTTGEuVLqlXH3gOplTrVw0Durow/F+XeKIREvrfhlnKizV2fgCqyF poRvLjYx0IXpUPnUqU3ESx8fP+9QkKmPyKASndUiU3NABkbnfGczA1YwEPIOpqacfqQd M5NmtTfvZ2pT7zfWE85HeEF7Ge102UaqCs7XrR1MZy2lL3pwpCjHVsq3rw9mWXHsphpX BfCVv/Vng5MMdq9ZK69mtTwcrcsINaIAtSTGGeV6eNvI019VE1K8joMEr9IphTXv5v8k Jnl86nmRFkWkwX3I2VkvOAakNzQ/yXVz5RA6UK/oJ5i7vrcfJ2/gTMo8bRnUw49BwkXo 1qoQ== X-Gm-Message-State: AMke39k0bbH4kjMmgcdmtxMJNB3x4S1fnCL/iJMBRsAv3yUzwu3dnS8DJwnAOfGurMt8uA6fIhF8OayXC62csQ== X-Received: by 10.237.41.100 with SMTP id s91mr8174253qtd.143.1488347873808; Tue, 28 Feb 2017 21:57:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Tue, 28 Feb 2017 21:57:53 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Wed, 1 Mar 2017 16:57:53 +1100 Message-ID: Subject: Re: Bike shed warning: integrity check for unprotected packets To: Victor Vasiliev Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Mar 2017 05:57:55 -0000 On 1 March 2017 at 15:55, Victor Vasiliev wrote: > I am not entirely clear -- are you suggesting to use CRC-32 (as defined in > V.42), or CRC-32Cc (as used in SCTP)? My mistake, I intended to state CRC32, the SCTP thing was in error (it's a different polynomial and I failed to recognize that). > My personal preference here lies with the algorithms which can be > implemented on a typical CPU without a lookup table -- that is to say, not > CRC or GHASH. GHASH might be fine since it's MTI for TLS anyways. You don't think that support in recent processors for CRC32 instructions is enough to meet your requirement?
I'm generally positive on this proposal and I think it= 's an improvement on the current
header, so I'd be fine with me= rging it on the principle of getting closer to what we want.

=
With that said, there are some things I'm less happy about:<= /div>


On Tue, Feb 14, 2017 at 11:05 PM, Jana Iyengar <jri@google.com> wrote:

The remainder of the packet layout is the same regardless of type, = the
difference being what rules for how to fill the values out an= d their semantics.

A client cleartext packet (type= =3D 0x3c) then contains:
* Octets 1-8: connection ID (initially = randomly chosen)
* Octets 9-12: version
* Octets 13-16:= packet number (low 4 octets, starts at a random 31-bit value)
* = Octets 17+: payload

The client MUST choose a rando= m value and use it as the Connection ID until the=C2=A0
server re= plies with a server-selected connection ID. The client's connection ID<= /div>
would have no semantic value, though they might serve to provide = proof that=C2=A0
the server received the packet via echoing, see = below.

A server cleartext packet (type =3D 0x3e) c= ontains:
* Octets 1-8: connection ID (server-selected value)
* Octets 9-12: version (echoed)
* Octets 13-16: packet numb= er (low 4 octets, random 31-bit initial value)
* Octets 17+: payl= oad

Both 0-RTT and 1-RTT packets with long-form he= aders contain:
* Octets 1-8: connection ID (server-selected value= )
* Octets 9-12: version
* Octets 13-16: packet number = (low 4 octets)
* Octets 17+: payload

A v= ersion negotiation packet contains:
* Octets 1-8: connection ID (= server-selected value, may be used in a subsequent=C2=A0
=C2=A0 c= onnection to reach the same server)
* Octets 9-12: version (echoe= d)
* Octets 13-16: proof (first 4 octets of client-selected conne= ction ID)
* Octets 17+: payload =3D version list
A publ= ic reset packet is sent when the server has no state for a received
packet. A server may therefore have to respond to either a long-form or = a=C2=A0
short-form packet. A public reset packet contains:
<= div>* Octets 1-8: connection ID (server-selected value)
* Octets = 9-12: version
* Octets 13-16: proof (octets 1-5 of received packe= t)

This "proof"= stuff doesn't work properly for a hash-based public reset design,
because the proof has to have high entropy. In general, I don't s= ee a lot of
value in overloading this field. Just put any require= d proof-type elements
in a data payload. That's probably easi= er for an implementation anyway.


Echoing details from the= packet in both version negotiation and public reset=C2=A0
provid= es return routeability (#244), while maintaining a consistent header=C2=A0<= /div>
shape for all packets.


=C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 3
=C2= =A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
=
| =C2=A0 =C2=A0 =C2=A0Type =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
<= font face=3D"monospace, monospace">+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 |
+ =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Connection ID (opti= onal) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= +
| =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =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 Packet Number (1/2/4) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0Payload =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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
```

I'm still unpersuaded that it's that important to = shave bits on the packet number here,
especially on a per-packet = basis.

Also, maybe I'm missing something, but = where's the key change bit? That seems to have
gone missing a= nd AFAICT you are still going to need it unless you have some thought
=
of swapping to long headers during the key change period until you see= acks or something
else equally gross.

-= Ekr


=C2=A0
The short form header is used af= ter the version and 1-RTT keys are negotiated.
The short form hea= der is defined to be specific to a version. In this version,=C2=A0
bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, resul= ting=C2=A0
in the following packet types.
* Octet 0: Pa= cket Type
=C2=A0 * 04 and 84: 1-RTT packet (packet number size = =3D 1)
=C2=A0 * 14 and 94: 1-RTT packet (packet number size =3D 2= )
=C2=A0 * 34 and b4: 1-RTT packet (packet number size =3D 4)
=C2=A0 * 0c and 8c: 1-RTT packet with Connection ID (packet number s= ize =3D 1)
=C2=A0 * 1c and 9c: 1-RTT packet with Connection ID (p= acket number size =3D 2)
=C2=A0 * 3c and bc: 1-RTT packet with Co= nnection ID (packet number size =3D 4)


--001a114d6f16db0edc0549216863-- From nobody Wed Feb 22 09:22:25 2017 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 8A9A312985F for ; Wed, 22 Feb 2017 09:22:24 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Du5ip0DSYXJH for ; Wed, 22 Feb 2017 09:22:22 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 7C9C3129849 for ; Wed, 22 Feb 2017 09:22:22 -0800 (PST) X-AuditID: c1b4fb30-2868b98000002c77-a9-58adc8cc2ca4 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by (Symantec Mail Security) with SMTP id 1C.EA.11383.CC8CDA85; Wed, 22 Feb 2017 18:22:20 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 22 Feb 2017 18:22:17 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=vYWxxu3qgxO33JDVRElNehoN+O9PeQuDgBKLOHWpnys=; b=WTtAjpHwFdkosEL3b1bD47FEAXVrgy+BMR+aOuShXZwpP2MK8x+4+Zhcwhkgo9RUaJwCzPS7pa8mrYc6yxu3jvhgedkesQPC1sS5uB9lVUqUGZZYDB7IBfJkUkxYq+07CL9lLmZPHRPal2QeJoNtEdwoio1MNfIuelS4VLEzRE0= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB345.eurprd07.prod.outlook.com (10.141.234.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Wed, 22 Feb 2017 17:22:14 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0919.018; Wed, 22 Feb 2017 17:22:13 +0000 From: Ingemar Johansson S To: IETF QUIC WG Subject: FW: New Version Notification for draft-johansson-quic-ecn-01.txt Thread-Topic: New Version Notification for draft-johansson-quic-ecn-01.txt Thread-Index: AQHSjOEdDzxr00Ts+EONPowXtDkG56F1RM/Q Date: Wed, 22 Feb 2017 17:22:13 +0000 Message-ID: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> In-Reply-To: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [213.113.27.92] x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 7:w1heF2qHulTwWPJ17ZixVz7wZfpz8D0c6D1R+CD4KivFviQ7pSgqTJ4DRAd9ZwN3qaqWWJMobF16O/1egNBIGeY01FRjBQ5BWTidtxcqy+Kbm9iMEhEtPrsoqnEaHdMKdZ5o7C94/E0k/EXe0LWj+0NBaNbUn3AUfHZvlUaNxVLOaqeePXZOSqaQxArBQeVOUECGaNHTVPtXjMwfuASnut9DBcNhftN4vs5EQGI7rL9L3X7X9KRnwVR8F0zS/LGhFs8tk1ogRptGEtBoYg77jwlkhB4ntyxCvK3jTiaQNKlNWqWaQNqcPq9Fdvsm7wr2f6URR5GAkxbX0LA1qWlqWw== x-forefront-antispam-report: SFV:SKI; SCL:-1SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(13464003)(377424004)(53546006)(2900100001)(2950100002)(6916009)(55016002)(6306002)(6436002)(3660700001)(107886003)(110136004)(3280700002)(81166006)(189998001)(8936002)(38730400002)(77096006)(4326007)(2906002)(86362001)(15650500001)(122556002)(229853002)(2473003)(6506006)(92566002)(53936002)(106116001)(9686003)(7736002)(54906002)(54356999)(99286003)(6116002)(74316002)(305945005)(76176999)(5660300001)(25786008)(8676002)(33656002)(7696004)(66066001)(3846002)(102836003)(230783001)(50986999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB345; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; MLV:nspm; PTR:InfoNoRecords; LANG:en; x-ms-office365-filtering-correlation-id: 518ae2f9-72f8-46d8-fd56-08d45b4757c9 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB345; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6041248)(20161123555025)(20161123562025)(20161123558025)(20161123560025)(20161123564025)(6072148); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB345; x-forefront-prvs: 022649CC2C spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Feb 2017 17:22:13.7341 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKKsWRmVeSWpSXmKPExsUyM2K7me6ZE2sjDPqfW1q8bpvNaHH04QJW i2PfljJZtD5dxWaxYfUUFotNbZtZLXoWcDuwe7y6f4HV42/HNhaPns8vmDyWLPnJ5PHt+kZW j6Zvi9g8jn34yhbAHsVlk5Kak1mWWqRvl8CVsfFHB2vBJoGK49t+Mzcw/uHvYuTkkBAwkbj8 +TlbFyMXh5DAOkaJ5k9zmSGcE4wS727dYgJxWAR6mSWm794FVTaNSaJz/S8mCOcYo8SZ7gOs IMPYBGwkVh76ztjFyMEhIqAgsaaBE6SGWWA9s0T/2/9MIDXCAp4SJ17uZAOxRQS8JOZ/b2OH qDeS2HLOCCTMIqAq0dV4kxnE5hWIkmj7ewpsvJCAr0Tj16tgcU4BP4nrDw8ygtiMArIS97/f YwGxmQXEJW49mc8E8ZuAxJI955khbFGJl4//sYLcwyjQzSjxYd41JpC9EgKKEkemlIPEJQS6 mSVenZzDCOFcZJU4/HApI0SRr8Sut8EQg3wkem+cZoOwMyXeLH4PtcxbYs2yJqjeGUwSH+5s ZYVIyEi075vFBvG8lMTdK52MELaMxIs7e1knMGrOQnL4LKB1zAKaEut36UOEFSWmdD9knwUO C0GJkzOfsCxgZFnFKFqcWpyUm25kpJdalJlcXJyfp5eXWrKJEZiYDm75bbCD8eVzx0OMAhyM Sjy8hcvXRgixJpYVV+YeYpTgYFYS4f2/GCjEm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAh gfTEktTs1NSC1CKYLBMHp1QDY9rxNufLml59Ond139v08cqX+7+PyTYI6jpa92fKVr/vn5rz xXxWV4blRa/S23E+zW3SAr++tuyrSim/Csr9WW9ODTth8cHz1JqKl3c0TGZ6bFEWqVvROrHT ebnWo0spCrdLdd3XBVmE690zXjclfqLiV805X/ua3Cf7lC62vbT4bewVmVMiSizFGYmGWsxF xYkAi2VRM0gDAAA= Archived-At: Cc: "'gorry@erg.abdn.ac.uk' \(gorry@erg.abdn.ac.uk\)" , "Bob Briscoe \(ietf@bobbriscoe.net\)" , Ingemar Johansson S , "'mirja.kuehlewind@tik.ee.ethz.ch'" , marcelo bagnulo braun , Piers O'Hanlon , "De Schepper, Koen \(Nokia - BE\)" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 17:22:24 -0000 SGkNCg0KSSBqdXN0IHVwbG9hZGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlIEVDTiBpbiBRVUlDIGRy YWZ0LiBUaGUgbWFpbiBjaGFuZ2UgYSBkZXNjcmlwdGlvbiBvZiB0aGUgRUNOIG5lZ290aWF0aW9u Lg0KDQovSW5nZW1hcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJu ZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANClNl bnQ6IGRlbiAyMiBmZWJydWFyaSAyMDE3IDA4OjU2DQpUbzogSW5nZW1hciBKb2hhbnNzb24gUyA8 aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQNCg0KDQpBIG5l dyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxLnR4dCBoYXMgYmVl biBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEluZ2VtYXIgSm9oYW5zc29uIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWpvaGFuc3Nvbi1xdWljLWVj bg0KUmV2aXNpb246CTAxDQpUaXRsZToJCUVDTiBzdXBwb3J0IGluIFFVSUMNCkRvY3VtZW50IGRh dGU6CTIwMTctMDItMjENCkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczoJCTEy DQpVUkw6ICAgICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2Ry YWZ0LWpvaGFuc3Nvbi1xdWljLWVjbi0wMS50eHQgDQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9k YXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLw0KSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qb2hhbnNzb24tcXVp Yy1lY24tMDENCkRpZmY6ICAgICAgICAgICBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtam9oYW5zc29uLXF1aWMtZWNuLTAxDQoNCkFic3RyYWN0Og0KICAgVGhpcyBtZW1v IG91dGxpbmVzIHRoZSBFQ04gc3VwcG9ydCBpbiBRVUlDLiAgVGhlIGludGVudGlvbiBpcyB0aGF0 DQogICBtb3N0IG9mIHRoZSBtYXRlcmlhbCBlbmRzIHVwIHVwZGF0aW5nIG90aGVyIG5ldyBvciBl eGlzdGluZyBRVUlDDQogICBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucywgdGh1cyBpdCBtYXkgYmUg cG9zc2libGUgdGhhdCB0aGlzIGRyYWZ0IGRvZXMNCiAgIG5vdCB3YXJyYW50IGEgd29ya2luZyBn cm91cCBzdGF0dXMuDQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBu b3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9m IHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls YWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Wed Feb 22 12:55:31 2017 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 23C30129B3E for ; Wed, 22 Feb 2017 12:55:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7qP0kksZbPo4 for ; Wed, 22 Feb 2017 12:55:28 -0800 (PST) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002:c09::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 15EF6129B30 for ; Wed, 22 Feb 2017 12:55:28 -0800 (PST) Received: by mail-yb0-x22d.google.com with SMTP id i66so4039616yba.1 for ; Wed, 22 Feb 2017 12:55:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=yEZRtzf8zt/cY0djrVAXkaZvJs9wbe6B15C82+cE3/k=; b=cVyYsrnBeoLZHpiR6NpZAASbWGaj3TYQHRBpeaQxnNCPeZ8OWeVtpex5wmIYR/I0Xc hyxl+M1q8p50eFXSIYFmu7sNs/CeQAlJ6fnpw4/Ght0Fyt8ndDPMNV7pXbDt8MdhJ/Z7 5JJXZEq5+xdFwO1+FqpXGJGG6NnP7OHyA2OzY0CAC1PRQPQvQqr85064Bp9lcLtWkXiT d2/1czW2BtGV3eRhmL6Dtni+uC7wXGFhzgWmh5mg6Q7nifC8Qj/DIMvaT2PxYMfSfO/l 9Jg40URezXVNbTN01gWvkfVihUI4AuU8vYGO4vyc2HG2eAQDBWPXj5gjlGuF6UgAk5Fd CrjA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=yEZRtzf8zt/cY0djrVAXkaZvJs9wbe6B15C82+cE3/k=; b=aHFDjUpPyiGnu0uCuqQB1kyhMe1IJkS43XEBe70t2N4QRqwvS7HqXvfM900dSn44bD uXUAUzzvjbGra/q8QNPB95v9RZ7pJDr5xdHYdwdOp4Ot2HU4A/8p0mP+58YLlYakC0US WY1ZIec1fdiQE/iuBBAf42FEs/Bf38jIngjFT0cgR7Gx63wrujImeallpDTpwODDexiS YHR8DKHiOqt5YMUV7qwl+M5KG/a3A6zgS1e0WPLQWiLk2llxsZ5O7BO9Vv2ccigSx8V1 J4Id8taNx5lTm+fBGkGRgpB7xAFa79dCT2+8GLAc2ad0ALSd+HUuu6DEWEWxeMJ0rGsi 5z1w== X-Gm-Message-State: AMke39nc5cgcK1urG8k2jMYUWIM+SJa/J5yyWSFmm//S4BmVBIu/vOaGQSPPa4T/AGwxVzVYEfgbVhQfoaQ3YA== X-Received: by 10.37.171.130 with SMTP id v2mr17214261ybi.1.1487796927194; Wed, 22 Feb 2017 12:55:27 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.17.140 with HTTP; Wed, 22 Feb 2017 12:55:26 -0800 (PST) In-Reply-To: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> From: Phillip Hallam-Baker Date: Wed, 22 Feb 2017 15:55:26 -0500 X-Google-Sender-Auth: hZcRhBEfZONC5pGPEmarafj6PNQ Message-ID: Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: Ingemar Johansson S Content-Type: multipart/alternative; boundary=94eb2c0b519657ef77054924b7d7 Archived-At: Cc: "'gorry@erg.abdn.ac.uk' \(gorry@erg.abdn.ac.uk\)" , "Bob Briscoe \(ietf@bobbriscoe.net\)" , "mirja.kuehlewind@tik.ee.ethz.ch" , marcelo bagnulo braun , Piers O'Hanlon , IETF QUIC WG , "De Schepper, Koen \(Nokia - BE\)" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:55:30 -0000 --94eb2c0b519657ef77054924b7d7 Content-Type: text/plain; charset=UTF-8 This is the entirety of the introduction: ECN support in transport protocols is a fundamental feature that should be included in the QUIC specification as a mandatory element. The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits]. The ECN support should be implemented to support both present and future ECN, the latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation], of particular interest is the ability to discriminate between classic ECN and L4S ECN by means of differentiation between the use of the ECT(0) and ECT(1) code points. This draft does however not delve into the details of the congestion control implementation. I have absolutely no idea what ECN is. I am opposed to the WG spending any time on ECN until it can be explained in terms that do not reference yet more jargon. On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > > I just uploaded a new version of the ECN in QUIC draft. The main change a > description of the ECN negotiation. > > /Ingemar > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: den 22 februari 2017 08:56 > To: Ingemar Johansson S > Subject: New Version Notification for draft-johansson-quic-ecn-01.txt > > > A new version of I-D, draft-johansson-quic-ecn-01.txt has been > successfully submitted by Ingemar Johansson and posted to the IETF > repository. > > Name: draft-johansson-quic-ecn > Revision: 01 > Title: ECN support in QUIC > Document date: 2017-02-21 > Group: Individual Submission > Pages: 12 > URL: https://www.ietf.org/internet-drafts/draft-johansson-quic- > ecn-01.txt > Status: https://datatracker.ietf.org/doc/draft-johansson-quic-ecn/ > Htmlized: https://tools.ietf.org/html/draft-johansson-quic-ecn-01 > Diff: https://www.ietf.org/rfcdiff? > url2=draft-johansson-quic-ecn-01 > > Abstract: > This memo outlines the ECN support in QUIC. The intention is that > most of the material ends up updating other new or existing QUIC > protocol specifications, thus it may be possible that this draft does > not warrant a working group status. > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org. > > The IETF Secretariat > > --94eb2c0b519657ef77054924b7d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This is the entirety of the introduction: =C2=A0<= /div>

= =C2=A0 =C2=A0ECN support in transport protocols is a fundamental feature th= at
=C2=A0 =C2=A0should be included in the= QUIC specification as a mandatory element.
=C2=A0 =C2=A0The benefits of ECN is described in [I-D.ietf-aqm-ecn-benef= its].=C2=A0 The
=C2=A0 =C2=A0ECN support = should be implemented to support both present and future
=C2=A0 =C2=A0ECN, the latter is outlined in [I-D.ietf-tsvwg= -ecn-experimentation],
=C2=A0 =C2=A0of pa= rticular interest is the ability to discriminate between classic
=C2=A0 =C2=A0ECN and L4S ECN by means of differenti= ation between the use of the
=C2=A0 =C2= =A0ECT(0) and ECT(1) code points.=C2=A0 This draft does however not delve
=C2=A0 =C2=A0into the details of the conge= stion control implementation.

<= div class=3D"gmail_default">I have absolutely no idea what ECN is. I am opp= osed to the WG spending any time on ECN until it can be explained in terms = that do not reference yet more jargon.


On Wed, Feb 22, 2017 at 12:22 PM,= Ingemar Johansson S <ingemar.s.johansson@ericsson.com&= gt; wrote:
Hi

I just uploaded a new version of the ECN in QUIC draft. The main change a d= escription of the ECN negotiation.

/Ingemar

-----Original Message-----
From: internet-drafts@ietf.org<= /a> [mailto:internet-drafts@iet= f.org]
Sent: den 22 februari 2017 08:56
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: New Version Notification for draft-johansson-quic-ecn-01.txt<= br>

A new version of I-D, draft-johansson-quic-ecn-01.txt has been success= fully submitted by Ingemar Johansson and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-johansson-quic-ecn
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ECN support in QUIC
Document date:=C2=A0 2017-02-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-johansson-qui= c-ecn-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-johansson-quic-ecn/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://t= ools.ietf.org/html/draft-johansson-quic-ecn-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-johansson-quic-ecn-= 01

Abstract:
=C2=A0 =C2=A0This memo outlines the ECN support in QUIC.=C2=A0 The intentio= n is that
=C2=A0 =C2=A0most of the material ends up updating other new or existing QU= IC
=C2=A0 =C2=A0protocol specifications, thus it may be possible that this dra= ft does
=C2=A0 =C2=A0not warrant a working group status.





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

The IETF Secretariat


--94eb2c0b519657ef77054924b7d7-- From nobody Wed Feb 22 12:56:24 2017 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 401F5129B3E for ; Wed, 22 Feb 2017 12:56:23 -0800 (PST) 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 pBXEa_RXiM8X for ; Wed, 22 Feb 2017 12:56:22 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::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 B4E4E129B30 for ; Wed, 22 Feb 2017 12:56:21 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id l12so7597024lfe.0 for ; Wed, 22 Feb 2017 12:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wJzPbSOgpNqzs5etj1osD9J6SoO25TNjsPJDud1BmfM=; b=HrraqFVF1pCsMTWAAQL3NlVqzjGfgA7yZDPzWQm/UxWG1ICKNkkNoYtRYl/uRvh5Es 43ABA5l8ExPvyYetc25vHGwdYaJ49MCOBcy2ou28YlSoFQBNMkxr3GoqsjFIoU1BNvD5 8o0LusZPLcLJoevzVLerlHtgtrypexdEzvnU0zjKHldQXTJsCpCI04VvruyF4i9l1AdU wybPt1QHlvSU4urPPgxDtcaR8elrgS6XQK9nlG7gx3fK4oPj0IP7wLqoZHnqoTAsz/Dw PfJMszZDKqHIE4nT0RF5/doEg/MmmP5GYXWUIOeGMQomC3Sc3WB4tZJjT1fOSJZ2IsM+ Skog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wJzPbSOgpNqzs5etj1osD9J6SoO25TNjsPJDud1BmfM=; b=h13t3xhbcWAjEew7aKXRplQDDKIAsb9nGaxBmdv8Py0GQKlTLqlpamYktvVT174caB qQZAhEObm+soYPi6THBFqb9yIIa0fjBPitZVEmBSPpvvfxNUZQBlDBW8aw3piE/5f6gl ZPB4iDV6r4KRi57R5dxDNuX6r1F4Zo0d6zyzJlTgYU4+Sbko6P5QGUJk0gDgnjMbn4xs 3Et22N3x9Rb433LAu8jt3PtVdbTLzs9d1Q1dnxmd07rHX7461xI+RFEa7wjzFxVbZlwa 8y7G7jHrWpxT3NAa0bkecMJdE5+bYba5a6fl0Lh/iESvpI9o+H+COU6ZUL5uhgoc6Vhm /YJw== X-Gm-Message-State: AMke39lnlAwL+CaareimVmfWxcp8HWzvvuwBUb19Z5eEv45/nKUkMLXHkOuVfWrnz1h7AGpT1IZD3Suh2jp8Lg== X-Received: by 10.25.129.147 with SMTP id c141mr9656284lfd.93.1487796980105; Wed, 22 Feb 2017 12:56:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.75.25 with HTTP; Wed, 22 Feb 2017 12:56:19 -0800 (PST) In-Reply-To: <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Thu, 23 Feb 2017 07:56:19 +1100 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: "Lubashev, Igor" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , Ryan Hamilton , Patrick McManus , "jri@google.com" , "quic@ietf.org" , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 20:56:23 -0000 On 23 February 2017 at 03:46, Lubashev, Igor wrote: > Great, I am glad you see it the same way about CONNECTION_CLOSE. The next > question would be whether the same can be said for PUBLIC_RESET as well. If > we really want to keep the two identical, it makes sense to require the same > semantics on them. Any counter-examples? Yes, there is a big difference, though we won't see it just yet. Absent a connection-level cryptographic payload that is successfully authenticated, Public Reset needs to kill a path, not an entire connection. From nobody Wed Feb 22 13:56:41 2017 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 722B1129BD3 for ; Wed, 22 Feb 2017 13:56:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zXCAPKq0lAl4 for ; Wed, 22 Feb 2017 13:56:39 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 0D27E129BBD for ; Wed, 22 Feb 2017 13:56:38 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id x10so12001108otb.1 for ; Wed, 22 Feb 2017 13:56:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NjwwrA5LpABmY2NPUqY6rttMm7+FEdQCtM+hSVfS4/E=; b=QOSYkNm4elG5zRplna/ZO8Mr6HsC5Dm3mxQSnRTI1FqInBEIoCI79vpf2exGwaSoGw jaPgPw5Kbsgq8LLPFZjNjEbADJBxa3s1SAI7azdcAUll7X03i5tzeiuRbHWhZQF77O8j LLSD7wROuQVCj+42keXzZQ/7TxjbkuafvZClUuBEZ0W5RmR6RqXcA8MzuGFAcra83BFw 28tthhzyHneufsNW00pTMjUERRrPyFDv6FuoHkD0m228pyIHnU1VQvrERRL04Fgh+ksl t9vQ/hmPt+gom0ZNVTMg1S9GWEava8/LLlBLL6Rt3x7mMrRVHY9nSI3Qjpfh9ul89eZj pehA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NjwwrA5LpABmY2NPUqY6rttMm7+FEdQCtM+hSVfS4/E=; b=R4oAmr0yv3U8stQHRUB9OXNpih8xV/UpN/uN6w5xsvNCz6oIFhJU9s1jYvswyWvDqJ Jnx5mcEPLYQnLXxGm5hMSHu5FdmxgM14UCEXnIcTkObJzw2sRseQ8KQqsYyH7qpUoHHe KAXqfZd+cpKbDVVDJfonscYReo5B4DCrU/d5vs/rQ/Rqm/DQSr9s9CSiZKIG+8mX1SXC eEV4zb5gF1KxnKyUDQ+85po+kjL5LjZip53eExcSD/xZM1+gyQ6FWb2hd+ASENiXdBP5 OboTBK9mFMEvxBaEufArkfAubE0Maa/GbNh9pXK8CatV3MrfbMBiYlX1ZYVMsDtPvIAz MKtg== X-Gm-Message-State: AMke39kHn7J1MJRLICn7l6O2zFKy5FPZGspD2dQYcVl1GpQFBGjaPCPTfu5V4ITltNKOby12Njrf/r4T2pJ66A== X-Received: by 10.157.12.205 with SMTP id o13mr5372469otd.99.1487800598316; Wed, 22 Feb 2017 13:56:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.226 with HTTP; Wed, 22 Feb 2017 13:56:37 -0800 (PST) In-Reply-To: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Duke Date: Wed, 22 Feb 2017 13:56:37 -0800 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11351ee628d0e3054925921c Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , "Lubashev, Igor" , Ryan Hamilton , Patrick McManus , "jri@google.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 21:56:40 -0000 --001a11351ee628d0e3054925921c Content-Type: text/plain; charset=UTF-8 I think the positions this are scattered about enough -- I have some heretical ones not even ready for prime time -- that this probably should be discussed in Chicago or Paris.Can someone open in issue? On Wed, Feb 22, 2017 at 12:56 PM, Martin Thomson wrote: > On 23 February 2017 at 03:46, Lubashev, Igor wrote: > > Great, I am glad you see it the same way about CONNECTION_CLOSE. The next > > question would be whether the same can be said for PUBLIC_RESET as well. > If > > we really want to keep the two identical, it makes sense to require the > same > > semantics on them. Any counter-examples? > > Yes, there is a big difference, though we won't see it just yet. > Absent a connection-level cryptographic payload that is successfully > authenticated, Public Reset needs to kill a path, not an entire > connection. > --001a11351ee628d0e3054925921c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I think the positions this are scattered about enough -- I= have some heretical ones not even ready for prime time -- that this probab= ly should be discussed in Chicago or Paris.Can someone open in issue?
=

On Wed, Feb 22, 2= 017 at 12:56 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 23 Febru= ary 2017 at 03:46, Lubashev, Igor <ilubashe@akamai.com> wrote:
> Great, I am glad you see it the same way about CONNECTION_CLOSE. The n= ext
> question would be whether the same can be said for PUBLIC_RESET as wel= l. If
> we really want to keep the two identical, it makes sense to require th= e same
> semantics on them. Any counter-examples?

Yes, there is a big difference, though we won't see it just yet.=
Absent a connection-level cryptographic payload that is successfully
authenticated, Public Reset needs to kill a path, not an entire
connection.

--001a11351ee628d0e3054925921c-- From nobody Wed Feb 22 14:15:33 2017 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 1FF1E129C4D for ; Wed, 22 Feb 2017 14:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 btRFkfZvZlXZ for ; Wed, 22 Feb 2017 14:15:30 -0800 (PST) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id F0616129C44 for ; Wed, 22 Feb 2017 14:15:29 -0800 (PST) Received: from mail-qt0-f176.google.com (mail-qt0-f176.google.com [209.85.216.176]) by linode64.ducksong.com (Postfix) with ESMTPSA id 719C43A021 for ; Wed, 22 Feb 2017 17:15:29 -0500 (EST) Received: by mail-qt0-f176.google.com with SMTP id x35so14964380qtc.2 for ; Wed, 22 Feb 2017 14:15:29 -0800 (PST) X-Gm-Message-State: AMke39nrXRK4TeIExF1jEY76o8l2VO1M/5SPmdzGoxTVincNci3AkZI5uSr0oFFTQ2dD5GNdL9FwBsAz9e1jsA== X-Received: by 10.200.43.184 with SMTP id m53mr33096100qtm.6.1487801729089; Wed, 22 Feb 2017 14:15:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.139.218 with HTTP; Wed, 22 Feb 2017 14:15:28 -0800 (PST) In-Reply-To: <8888ebdd-a567-b550-7bdd-6c27a78c6fe9@huitema.net> References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <8888ebdd-a567-b550-7bdd-6c27a78c6fe9@huitema.net> From: Patrick McManus Date: Wed, 22 Feb 2017 17:15:28 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Christian Huitema Content-Type: multipart/alternative; boundary=001a113ff2e68f5aab054925d5f5 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , "Lubashev, Igor" , Ryan Hamilton , Patrick McManus , "jri@google.com" , "quic@ietf.org" , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 22:15:32 -0000 --001a113ff2e68f5aab054925d5f5 Content-Type: text/plain; charset=UTF-8 On Tue, Feb 21, 2017 at 5:02 PM, Christian Huitema wrote: > What should happen if a single packet contains the Connection Close > Frame and also a Stop Waiting frame with a delta = 0? > my recollection from tokyo is that stop_waiting is being removed https://github.com/quicwg/base-drafts/issues/66 is marked editor-ready --001a113ff2e68f5aab054925d5f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 21, 2017 at 5:02 PM, Christian Huitema <huitema@huitema.net<= /a>> wrote:
=
What should happen if a single packet contains the Connection Close
Frame and also a Stop Waiting frame with a delta =3D 0?
<= /div>


my recollection from tokyo is that stop_waiting is being removed https://github.com/qui= cwg/base-drafts/issues/66 is marked editor-ready

--001a113ff2e68f5aab054925d5f5-- From nobody Wed Feb 22 14:54:06 2017 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 51AFB129BC4 for ; Wed, 22 Feb 2017 14:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.735 X-Spam-Level: X-Spam-Status: No, score=-0.735 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_HELO_PASS=-0.001, SPF_SOFTFAIL=0.665] autolearn=no 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 ILP56IBW3NPh for ; Wed, 22 Feb 2017 14:54:03 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 4D958129C68 for ; Wed, 22 Feb 2017 14:54:03 -0800 (PST) Received: from mail-qk0-f181.google.com (mail-qk0-f181.google.com [209.85.220.181]) by linode64.ducksong.com (Postfix) with ESMTPSA id B9FE83A0B1 for ; Wed, 22 Feb 2017 17:54:02 -0500 (EST) Received: by mail-qk0-f181.google.com with SMTP id u188so17255823qkc.2 for ; Wed, 22 Feb 2017 14:54:02 -0800 (PST) X-Gm-Message-State: AMke39lzDYxaa4HLBDiMmvp8Xq/UNjP+18o0Kkv1/YxW18tKve33CbibkT04Btuk8GF8eZtxjFzkFyp0bzgixw== X-Received: by 10.55.43.213 with SMTP id r82mr38461400qkr.28.1487804042476; Wed, 22 Feb 2017 14:54:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.162.65 with HTTP; Wed, 22 Feb 2017 14:54:01 -0800 (PST) In-Reply-To: <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> From: Patrick McManus Date: Wed, 22 Feb 2017 17:54:01 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: "Lubashev, Igor" Content-Type: multipart/alternative; boundary=001a11494398728e6c0549265fae Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , Ryan Hamilton , Patrick McManus , "jri@google.com" , "quic@ietf.org" , Martin Thomson , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 22:54:05 -0000 --001a11494398728e6c0549265fae Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Is this where we are? Upon receipt of CLOSE/RESET an application MUST NOT abandon in-order queued data for the application layer (whether or not it has a FIN for the stream it is on) the way TCP currently does. But it SHOULD(?) drop future packets received on the connection and MUST NOT send any on more on the connection. CLOSE/RESET has the potential for data loss for any data whose ack has not been received when CLOSE/RESET is generated. [I really think something like that would be clarifying text in the document] imo CLOSE ought to be named RESET.. generically close isn't normally a destructive operation, while the semantics here certainly might be. On Wed, Feb 22, 2017 at 11:46 AM, Lubashev, Igor wrote: > =C3=98 My preference for requiring the delivery of all data belonging to > properly closed streams and a SHOULD NOT for the delivery of any other da= ta > not yet delivered. > > > > That's a MUST and a SHOULD NOT, which sounds fine. > > > > Great, I am glad you see it the same way about CONNECTION_CLOSE. The next > question would be whether the same can be said for PUBLIC_RESET as well. = If > we really want to keep the two identical, it makes sense to require the > same semantics on them. Any counter-examples? > > > > > > =C3=98 I don't know what the relevance of ACKed is when talking about > received data > > > > You are correct. ACKs do not matter here. > > > > - Igor > > > > > > *From:* Martin Thomson [mailto:martin.thomson@gmail.com] > *Sent:* Tuesday, February 21, 2017 11:11 PM > *To:* Martin Duke > *Cc:* Ryan Hamilton ; Mike Bishop < > Michael.Bishop@microsoft.com>; ekr@rtfm.com; Lubashev, Igor < > ilubashe@akamai.com>; Patrick McManus ; > jri@google.com; quic@ietf.org > *Subject:* Re: tcp rsts, data truncation, and the future of public reset > > > > > > On 22 February 2017 at 07:56, Martin Duke wrote= : > > GOAWAY means that I will neither initiate streams nor accept new streams. > So how am I to know that the other side is done initiating streams? It > would be better if the GOAWAY were a sort of one-way connection FIN. > > > > If you do as we allow in HTTP/2, GOAWAY can be sent many times. GOAWAY > with a high number allows you to continue creating streams, but puts the > other side on notice of imminent shutdown. Sending again with a lower > number promises that streams below that number are OK to complete, but > higher numbers are all reset. And you can't sent with a higher number. = At > some point, you are either tired of waiting for streams to close, or they > are all closed. Then send CONNECTION_CLOSE. > > On 22 February 2017 at 09:59, Lubashev, Igor wrote: > > I do not think this is sufficient. You need to talk about the the other > side's semantics on receipt of CONNECTION_CLOSE. In particular, is the > receiver of CONNECTION_CLOSE allowed to drop the connection state > immediately? Or is it required to deliver ACKed data to the application > first? If it is required to deliver ACKed data, is it all data or only da= ta > from properly closed streams (i.e. excluding streams reset due to > STREAM_RST or CONNECTION_CLOSE). > > > Well, if there is anything outstanding on a stream, that's a hard cut on > those things, throw them away. > > Unlike TCP, which sometimes throws state away on a RST, I would say that > an implementation MUST allow completed streams that weren't delivered to > complete. Any local state costs can continue to accrue to the applicatio= n. > > I don't know what the relevance of ACKed is when talking about received > data, you don't send an ACK for your own benefit. > > My preference for requiring the delivery of all data belonging to properl= y > closed streams and a SHOULD NOT for the delivery of any other data not ye= t > delivered. > > > > That's a MUST and a SHOULD NOT, which sounds fine. > --001a11494398728e6c0549265fae Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Is this where we are?

Upon receipt of CLOSE/RESET an application MUST NOT abandon in-order= queued data for the application layer (whether or not it has a FIN for the= stream it is on) the way TCP currently does. But it SHOULD(?) drop future = packets received on the connection and MUST NOT send any on more on the con= nection.

CLOSE/RESET has the potential for data loss for any data whose ack has not been received when CLOSE/RESET is generated. [I= really think something like that would be clarifying text in the document]=

imo CLOSE ought to be named RESET.. generical= ly close isn't normally a destructive operation, while the semantics he= re certainly might be.

=


On Wed, Feb 22, 2017 at 11:46 AM, Lubashev, Igor <= ilubashe@akamai.com> wrote:

=C3=98=C2=A0 My preference for requiring the delivery of all= data belonging to properly closed streams and a SHOULD NOT for the deliver= y of any other data not yet delivered.

=C2=A0

That's a MUST and a = SHOULD NOT, which sounds fine.

=C2=A0

Great, I am glad you see it the same way abo= ut CONNECTION_CLOSE. The next question would be whether the same can be sai= d for PUBLIC_RESET as well. If we really want to keep the two identical, it makes sense to require the same semantics on them. A= ny counter-examples?

=C2=A0

=C2=A0

=C3=98=C2=A0 I don't know what the relevance of ACKed is= when talking about received data

=C2=A0

You are correct. ACKs do not matter here.=

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Igor

=C2=A0

=C2=A0

From: Martin Thomson [mailto:martin.thomson@gmail= .com]
Sent: Tuesday, February 21, 2017 11:11 PM
To: Martin Duke <martin.h.duke@gmail.com>
Cc: Ryan Hamilton <rch@google.com>; Mike Bishop <Michael.Bishop@microsoft.com>; ekr@rtfm.com; Lu= bashev, Igor <i= lubashe@akamai.com>; Patrick McManus <pmcmanus@mozilla.com>; jri@google.com; quic@ietf.org
Subject: Re: tcp rsts, data truncation, and the future of public res= et

=C2=A0

=C2=A0

On 22 February 2017 at 07:56, Martin Duke <martin.h.duke@gmail.= com> wrote:

GOAWAY means that I will neither initiate streams no= r accept new streams. So how am I to know that the other side is done initi= ating streams? It would be better if the GOAWAY were a sort of one-way conn= ection FIN.

=C2=A0<= /p>

If you do as we allow= in HTTP/2, GOAWAY can be sent many times.=C2=A0 GOAWAY with a high number = allows you to continue creating streams, but puts the other side on notice = of imminent shutdown.=C2=A0 Sending again with a lower number promises that streams below that number are OK to complete,= but higher numbers are all reset.=C2=A0 And you can't sent with a high= er number.=C2=A0 At some point, you are either tired of waiting for streams= to close, or they are all closed.=C2=A0 Then send CONNECTION_CLOSE.


Well, if there is anything outstanding on a stream, that's a hard cut o= n those things, throw them away.=C2=A0

Unlike TCP, which sometimes throws state away on a RST, I would say that an= implementation MUST allow completed streams that weren't delivered to = complete.=C2=A0 Any local state costs can continue to accrue to the applica= tion.

I don't know what the relevance of ACKed is when talking about received= data, you don't send an ACK for your own benefit.

My preference for requiring the delivery of all data= belonging to properly closed streams and a SHOULD NOT for the delivery of = any other data not yet delivered.

=C2=A0

That's a MUST and a SHOULD NOT, which sounds fin= e.


--001a11494398728e6c0549265fae-- From nobody Wed Feb 22 15:05:06 2017 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 9249B124281 for ; Wed, 22 Feb 2017 15:05:05 -0800 (PST) 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 vWEFjWXE6FSX for ; Wed, 22 Feb 2017 15:05:04 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 28535129CA2 for ; Wed, 22 Feb 2017 15:05:04 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id g134so8842975lfe.1 for ; Wed, 22 Feb 2017 15:05:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tecyWzq3xrd/1Z2/m+gHv/er1sLUoOEsw/7mSaM9MDE=; b=g1nznR9cRFhAyzJbn+3OQNY30P9NNlcQYX9hN99m5ucHq0NrBj++HtBjHrmv3Kyf76 dWc4ANgXSJYLjTSYY5LH/2GhuPIrZVWN8pzo6++2uyU7SEyPWS4LQkw8jtqEUD1GaOO6 O0Tt8FTpoV0fjvjBvomr6/T3yX+Kf0WHD3o+n3t7kQcMoZgraFwhzgTW1+ZxfPq17Giq dnGNK+464Xxl+k8caeCYHM4f8yKn/mJlDOxU0JIHy7CVcSCwB7Hfnb8NjNtYKrdrHZUS BevpducmVplBjB55YPijyvu/Grpa+rDZD3LhpWBaocYBLLnZ37bCuxYbR9jVqu5HC/BM QW7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tecyWzq3xrd/1Z2/m+gHv/er1sLUoOEsw/7mSaM9MDE=; b=KZYx6+jYllH2gFKOluBmqANT1dysY3QQUQiKsiz8XPHkrLsJAYzwq9+e47kOZ4IgdA lA98KAi3/1JtEQmecpj3i9imQGQrdX5efkQqi6mXsmqVM1qA41mQpHRMKnkteyvbgj/y yWi91eZ5iiL/AHQBBENL7/MZKySH/v7nJgEJNbVLSyuR2U25AjXljO043WfXjopbAnN9 q673f3lg5r19ihtnu2A8XwmgJUYsZSDQArY3GV6hPrr/fij9oB52cV24ib9Hxs4DjgQX ekiddQ2Y9/zvo+9iq/FGWbATFnYLnvcRf7lUbogpoLPZPpYb53+aTARRj12DFgAr0bQU nWVg== X-Gm-Message-State: AMke39n6ftq4nUINrMi+zBcGUlgYclj5NqFwnyOnjTM5/fE35bKIE+u86wbMwDm/xdImPwwU32o2Fv7aorILcA== X-Received: by 10.25.68.1 with SMTP id r1mr9775009lfa.86.1487804702428; Wed, 22 Feb 2017 15:05:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.46.75.25 with HTTP; Wed, 22 Feb 2017 15:05:01 -0800 (PST) In-Reply-To: References: <866396fe7d31416e9e57b0d0500c87f1@usma1ex-dag1mb5.msg.corp.akamai.com> <3e1e15a011f64543bf12e3571411b508@usma1ex-dag1mb5.msg.corp.akamai.com> From: Martin Thomson Date: Thu, 23 Feb 2017 10:05:01 +1100 Message-ID: Subject: Re: tcp rsts, data truncation, and the future of public reset To: Patrick McManus Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Mike Bishop , "ekr@rtfm.com" , "Lubashev, Igor" , Ryan Hamilton , "jri@google.com" , "quic@ietf.org" , Martin Duke X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 23:05:05 -0000 On 23 February 2017 at 09:54, Patrick McManus wrote: > Upon receipt of CLOSE/RESET an application MUST NOT abandon in-order queued > data for the application layer (whether or not it has a FIN for the stream > it is on) the way TCP currently does. But it SHOULD(?) drop future packets > received on the connection and MUST NOT send any on more on the connection. > > CLOSE/RESET has the potential for data loss for any data whose ack has not > been received when CLOSE/RESET is generated. [I really think something like > that would be clarifying text in the document] I think that naturally follows. Of course, the received might have received data and therefore could have acted upon it. That means that unacknowledged data is in an ambiguous state. Hopefully the graceful close happens often enough that this isn't a common situation. > > imo CLOSE ought to be named RESET.. generically close isn't normally a > destructive operation, while the semantics here certainly might be. Reset implies an abort, which isn't really the case for a graceful close. Perhaps TERMINATE has the right connotations. (I would also like to change RST_STREAM to CANCEL_STREAM and a few other cosmetic changes.) From nobody Wed Feb 22 15:25:00 2017 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 E9B2E129D09 for ; Wed, 22 Feb 2017 15:24:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vp0vG6Mmg0RM for ; Wed, 22 Feb 2017 15:24:56 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19AA9129D08 for ; Wed, 22 Feb 2017 15:24:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1487805893; l=8968; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=rTzT4EWPP8hIWxVHq7hJ4oAJiNU+KY9+2P/xQ0OM/3k=; b=LtubsiJdIFAj7X/8vmyi1IZQ9F4fN3SztHn+yP5ASQRoOGpg+WUd9RBiMg98shj6Iy lhJ78UlVVLN0EvWyOYcpbzJk4Jh+ySubt3CmVNw/3YNRG+9G1dtU1xP464G+We5ce2O4 QqlIX5FtOaUDx1euKsFwbxz8ffW5ngQzuyxTE= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzU8vh0LBB+HOmbLwmKbQ2UARML+w== X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:e96c:8216:226b:dded] ([2001:4dd0:ff67:0:e96c:8216:226b:dded]) by smtp.strato.de (RZmta 39.13 AUTH) with ESMTPSA id j01705t1MNOqPHx (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Thu, 23 Feb 2017 00:24:52 +0100 (CET) Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: quic@ietf.org References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> From: Roland Zink Message-ID: <95e7b600-784f-5308-168f-7c55c278747f@zinks.de> Date: Thu, 23 Feb 2017 00:24:53 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DDD06D48CF9E50EFE2F2BA9D" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 23:24:59 -0000 This is a multi-part message in MIME format. --------------DDD06D48CF9E50EFE2F2BA9D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit ECN is Explicit Congestion Notification which I think already explains what it tries to achieve. For more information Wikipedia has something at https://en.wikipedia.org/wiki/Explicit_Congestion_Notification. Regards, Roland Am 22.02.2017 um 21:55 schrieb Phillip Hallam-Baker: > This is the entirety of the introduction: > > ECN support in transport protocols is a fundamental feature that > should be included in the QUIC specification as a mandatory element. > The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits]. The > ECN support should be implemented to support both present and future > ECN, the latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation], > of particular interest is the ability to discriminate between classic > ECN and L4S ECN by means of differentiation between the use of the > ECT(0) and ECT(1) code points. This draft does however not delve > into the details of the congestion control implementation. > > I have absolutely no idea what ECN is. I am opposed to the WG spending > any time on ECN until it can be explained in terms that do not > reference yet more jargon. > > > > On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S > > wrote: > > Hi > > I just uploaded a new version of the ECN in QUIC draft. The main > change a description of the ECN negotiation. > > /Ingemar > > -----Original Message----- > From: internet-drafts@ietf.org > [mailto:internet-drafts@ietf.org ] > Sent: den 22 februari 2017 08:56 > To: Ingemar Johansson S > > Subject: New Version Notification for draft-johansson-quic-ecn-01.txt > > > A new version of I-D, draft-johansson-quic-ecn-01.txt has been > successfully submitted by Ingemar Johansson and posted to the IETF > repository. > > Name: draft-johansson-quic-ecn > Revision: 01 > Title: ECN support in QUIC > Document date: 2017-02-21 > Group: Individual Submission > Pages: 12 > URL: > https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-01.txt > > Status: https://datatracker.ietf.org/doc/draft-johansson-quic-ecn/ > > Htmlized: https://tools.ietf.org/html/draft-johansson-quic-ecn-01 > > Diff: > https://www.ietf.org/rfcdiff?url2=draft-johansson-quic-ecn-01 > > > Abstract: > This memo outlines the ECN support in QUIC. The intention is that > most of the material ends up updating other new or existing QUIC > protocol specifications, thus it may be possible that this > draft does > not warrant a working group status. > > > > > > Please note that it may take a couple of minutes from the time of > submission until the htmlized version and diff are available at > tools.ietf.org . > > The IETF Secretariat > > --------------DDD06D48CF9E50EFE2F2BA9D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

ECN is Explicit Congestion Notification which I think already explains what it tries to achieve. For more information Wikipedia has something at https://en.wikipedia.org/wiki/Explicit_Congestion_Notification.


Regards,

Roland


Am 22.02.2017 um 21:55 schrieb Phillip Hallam-Baker:
This is the entirety of the introduction:  

   ECN support in transport protocols is a fundamental feature that
   should be included in the QUIC specification as a mandatory element.
   The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits].  The
   ECN support should be implemented to support both present and future
   ECN, the latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation],
   of particular interest is the ability to discriminate between classic
   ECN and L4S ECN by means of differentiation between the use of the
   ECT(0) and ECT(1) code points.  This draft does however not delve
   into the details of the congestion control implementation.

I have absolutely no idea what ECN is. I am opposed to the WG spending any time on ECN until it can be explained in terms that do not reference yet more jargon.



On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi

I just uploaded a new version of the ECN in QUIC draft. The main change a description of the ECN negotiation.

/Ingemar

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: den 22 februari 2017 08:56
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: New Version Notification for draft-johansson-quic-ecn-01.txt


A new version of I-D, draft-johansson-quic-ecn-01.txt has been successfully submitted by Ingemar Johansson and posted to the IETF repository.

Name:           draft-johansson-quic-ecn
Revision:       01
Title:          ECN support in QUIC
Document date:  2017-02-21
Group:          Individual Submission
Pages:          12
URL:            https://www.ietf.org/internet-drafts/draft-johansson-quic-ecn-01.txt
Status:         https://datatracker.ietf.org/doc/draft-johansson-quic-ecn/
Htmlized:       https://tools.ietf.org/html/draft-johansson-quic-ecn-01
Diff:           https://www.ietf.org/rfcdiff?url2=draft-johansson-quic-ecn-01

Abstract:
   This memo outlines the ECN support in QUIC.  The intention is that
   most of the material ends up updating other new or existing QUIC
   protocol specifications, thus it may be possible that this draft does
   not warrant a working group status.





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

The IETF Secretariat



--------------DDD06D48CF9E50EFE2F2BA9D-- From nobody Wed Feb 22 15:37:11 2017 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 58D40129D28 for ; Wed, 22 Feb 2017 15:37:10 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 mSbRrjoqM4dp for ; Wed, 22 Feb 2017 15:37:08 -0800 (PST) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B9AA129D0B for ; Wed, 22 Feb 2017 15:37:08 -0800 (PST) Received: by mail-vk0-x235.google.com with SMTP id k127so11189943vke.0 for ; Wed, 22 Feb 2017 15:37:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EiSJlVwiRlCcj5SibXsZRKSncrjGrr1HiAoJASn2xWI=; b=u9spETQNVGpExoV7fA4ittEzKNcZ+OcXDoldJmn1Anqsa24zRuYolLNQEEC5oQXWyi Q1p7q9P6HGAZ2XrZkXrtcsN0lnne0Cwi3EOTD/NSeG61z9G3+ik36nfhFMRMS+jrDfmp 2ga3siomEB/d+wyWAoyN9kgAfVJfOLRY9vCJnGY/mZmUPafkLH+3mbR016/l6Fbc0zKW yu3cYoRjykbkDRmht1lPD7YkowsObWXjpVt/1vdpggpcnABq4Y2XXNiRBVxtDhaymc5e Q99i0lqJA3hqSxVaRASBslCdZbJfKOLt91yaPo5Wlb/huY8lHvyQUBFOmY1whnvT5wHi Ue0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EiSJlVwiRlCcj5SibXsZRKSncrjGrr1HiAoJASn2xWI=; b=m7y6ooNmWl3s7gQj9lH7NT8s8n33bFUzzl+xO/Sz8yQ0RLTEs0TJO1Y07gvvI2VAcT +EGf2xBzQVvl7uRSmI/DA1N5j1CHCWjQj0sGT/XdTVctFn6kXoZyPEHUJTAhlT8BwOhX Xtqg0HpWBG9iFzcB51Ij0YSe9TT6OBGmWV7nm7ayCGZRsMNZDy0v1JXK+p1ItYSalkfY +raVCtF/DOT8Q6GLCyeW647/XfgFeXZhTUyNShMKrkYEBmFHwDYzHPVlFcpR1HxhlvDQ bGHDhBdO8d/c0FZbdWejq4gUYRYxuQ4AlLAyuA2q/vDo1pYbgmOve5bEIY3EQjQMC3vI kW1g== X-Gm-Message-State: AMke39nyPb/LHyhn9arom05Db8c2rxhxv98V8pUB7htlB4uIISkDQMijyXzjpiW30rC0eP95SevLfw+FQufDky0W X-Received: by 10.31.51.68 with SMTP id z65mr17111603vkz.40.1487806626719; Wed, 22 Feb 2017 15:37:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Wed, 22 Feb 2017 15:37:06 -0800 (PST) In-Reply-To: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> From: Jana Iyengar Date: Wed, 22 Feb 2017 15:37:06 -0800 Message-ID: Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: Phillip Hallam-Baker Content-Type: multipart/alternative; boundary=001a1144a44e7b80f8054926f918 Archived-At: Cc: "'gorry@erg.abdn.ac.uk' \(gorry@erg.abdn.ac.uk\)" , "Bob Briscoe \(ietf@bobbriscoe.net\)" , Ingemar Johansson S , "mirja.kuehlewind@tik.ee.ethz.ch" , marcelo bagnulo braun , Piers O'Hanlon , IETF QUIC WG , "De Schepper, Koen \(Nokia - BE\)" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2017 23:37:10 -0000 --001a1144a44e7b80f8054926f918 Content-Type: text/plain; charset=UTF-8 On Wed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Baker < phill@hallambaker.com> wrote: > This is the entirety of the introduction: > > ECN support in transport protocols is a fundamental feature that > should be included in the QUIC specification as a mandatory element. > The benefits of ECN is described in [I-D.ietf-aqm-ecn-benefits]. The > ECN support should be implemented to support both present and future > ECN, the latter is outlined in [I-D.ietf-tsvwg-ecn-experimentation], > of particular interest is the ability to discriminate between classic > ECN and L4S ECN by means of differentiation between the use of the > ECT(0) and ECT(1) code points. This draft does however not delve > into the details of the congestion control implementation. > > I have absolutely no idea what ECN is. I am opposed to the WG spending any > time on ECN until it can be explained in terms that do not reference yet > more jargon. > Happy to help. ECN is defined in RFC 3168 , and is an explicit signal from the a network switch or router about congestion at a link, so that endpoints can use this signal instead of loss for detecting and reacting to congestion. The benefits of doing this are documented int he I-D that is linked in the abstract. ECN has been a pretty significant thing in transport for about two decades, but has had an uphill battle since ECN requires support in the network and at endpoints. There have been many efforts to try and deploy it in network devices and at endpoints for about as long as RFC 3168 has existed. ECN has been deployed in bits at routers and in endpoints, but due to long-standing bugs in older home-routers and wifi boxes, and issues around use of these bits in the IP header, it was generally not turned on anywhere. This seems to be changing now, especially as bufferbloat becomes an increasingly visible issue. Brian Trammell (IAB) and Mirja Kuehlewind (Transport AD) have been actively doing measurement about the current deployment state of ECN; here's a blog post by Brian from last summer saying that a large number of webservers do support ECN. There's support for ECN built into TCP (see Section 3.2 and 4.3 of the TCP Roadmap RFC ), there's been a ton of work around re-using ECN signaling for richer congestion information. Since TCP and SCTP have support for ECN, and the future may see ECN deployment increase yet, it's expected that QUIC would have equivalent mechanisms to support use of ECN. This work is very much in scope, as part of the congestion control aspect of QUIC. Hope this helps, - jana > > On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > >> Hi >> >> I just uploaded a new version of the ECN in QUIC draft. The main change a >> description of the ECN negotiation. >> >> /Ingemar >> >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: den 22 februari 2017 08:56 >> To: Ingemar Johansson S >> Subject: New Version Notification for draft-johansson-quic-ecn-01.txt >> >> >> A new version of I-D, draft-johansson-quic-ecn-01.txt has been >> successfully submitted by Ingemar Johansson and posted to the IETF >> repository. >> >> Name: draft-johansson-quic-ecn >> Revision: 01 >> Title: ECN support in QUIC >> Document date: 2017-02-21 >> Group: Individual Submission >> Pages: 12 >> URL: https://www.ietf.org/internet- >> drafts/draft-johansson-quic-ecn-01.txt >> Status: https://datatracker.ietf.org/ >> doc/draft-johansson-quic-ecn/ >> Htmlized: https://tools.ietf.org/html/draft-johansson-quic-ecn-01 >> Diff: https://www.ietf.org/rfcdiff? >> url2=draft-johansson-quic-ecn-01 >> >> Abstract: >> This memo outlines the ECN support in QUIC. The intention is that >> most of the material ends up updating other new or existing QUIC >> protocol specifications, thus it may be possible that this draft does >> not warrant a working group status. >> >> >> >> >> >> Please note that it may take a couple of minutes from the time of >> submission until the htmlized version and diff are available at >> tools.ietf.org. >> >> The IETF Secretariat >> >> > --001a1144a44e7b80f8054926f918 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Feb 22, 2017 at 12:55 PM, Phillip Hallam-Baker <phill@hallambaker.= com> wrote:
This is the entire= ty of the introduction: =C2=A0

=C2=A0 =C2=A0ECN su= pport in transport protocols is a fundamental feature that
=C2=A0= =C2=A0should be included in the QUIC specification as a mandatory element.=
=C2=A0 =C2=A0The benefits of ECN is described in [I-D.ietf-aqm-e= cn-benefits].=C2=A0 The
=C2=A0 =C2=A0ECN support should be implem= ented to support both present and future
=C2=A0 =C2=A0ECN, the la= tter is outlined in [I-D.ietf-tsvwg-ecn-experimentation],
= =C2=A0 =C2=A0of particular interest is the ability to discriminate between = classic
=C2=A0 =C2=A0ECN and L4S ECN by means of differentiation = between the use of the
=C2=A0 =C2=A0ECT(0) and ECT(1) code points= .=C2=A0 This draft does however not delve
=C2=A0 =C2=A0into the d= etails of the congestion control implementation.

I= have absolutely no idea what ECN is. I am opposed to the WG spending any t= ime on ECN until it can be explained in terms that do not reference yet mor= e jargon.

Happy to help. = ECN is defined in RFC 3168<= /a>, and is an explicit signal from the a network switch or router about co= ngestion at a link, so that endpoints can use this signal instead of loss f= or detecting and reacting to congestion. The benefits of doing this are doc= umented int he I-D that is linked in the abstract. ECN has been a pretty si= gnificant thing in transport for about two decades, but has had an uphill b= attle since ECN requires support in the network and at endpoints.=C2=A0

There have been many efforts to try and deploy it in = network devices and at endpoints for about as long as RFC 3168 has existed.= ECN has been deployed in bits at routers and in endpoints, but due to long= -standing bugs in older home-routers and wifi boxes, and issues around use = of these bits in the IP header, it was generally not turned on anywhere. Th= is seems to be changing now, especially as bufferbloat becomes an increasin= gly visible issue. Brian Trammell (IAB) and Mirja Kuehlewind (Transport AD)= have been actively doing measurement about the current deployment state of= ECN; here's a blog post by Brian=C2=A0from last= summer saying that a large number of webservers do support ECN. There'= s support for ECN built into TCP (see Section 3.2 and 4.3 of the TCP Roadmap RFC), there'= s been a ton of work around re-using ECN signaling for richer congestion in= formation.

Since TCP and SCTP have support for ECN= , and the future may see ECN deployment increase yet, it's expected tha= t QUIC would have equivalent mechanisms to support use of ECN. This work is= very much in scope, as part of the congestion control aspect of QUIC.

Hope this helps,
- jana

=


On Wed, Feb 22, 2017 at 12:22 PM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:
Hi

I just uploaded a new version of the ECN in QUIC draft. The main change a d= escription of the ECN negotiation.

/Ingemar

-----Original Message-----
From: interne= t-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: den 22 februari 2017 08:56
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>
Subject: New Version Notification for draft-johansson-quic-ecn-01.txt<= br>

A new version of I-D, draft-johansson-quic-ecn-01.txt has been success= fully submitted by Ingemar Johansson and posted to the IETF repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-johansson-quic-ecn
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A001
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ECN support in QUIC
Document date:=C2=A0 2017-02-21
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 12
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-johansson-qui= c-ecn-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://datatracker.ietf.org/doc/draft-johansson-quic-ecn/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://t= ools.ietf.org/html/draft-johansson-quic-ecn-01
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-johansson-quic-ecn-= 01

Abstract:
=C2=A0 =C2=A0This memo outlines the ECN support in QUIC.=C2=A0 The intentio= n is that
=C2=A0 =C2=A0most of the material ends up updating other new or existing QU= IC
=C2=A0 =C2=A0protocol specifications, thus it may be possible that this dra= ft does
=C2=A0 =C2=A0not warrant a working group status.





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

The IETF Secretariat




But if the ack in (b) is lost, then endpoint B receives CONNECTION_= CLOSE while data is still outstanding. I believe the spec, as written, says= to treat this as an abrupt shutdown and throw the queued data on the floor= .

Furthermore, B is required to acknowledge the CO= NNECTION_CLOSE frame. Even if it were to keep the send queue after CONNECTI= ON_CLOSE, the ack would probably go out first. So A can tear down its conne= ction before B has any assurance that A got all its data.

There are several minor protocol edits to avoid all the problems in= this scenario. But I don't believe the spec as written is sufficient.<= br>

Martin Duke
--001a113da04a8913de05493af5e7-- From nobody Thu Feb 23 16:39:39 2017 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 C75781293F8 for ; Thu, 23 Feb 2017 16:39:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.488 X-Spam-Level: X-Spam-Status: No, score=-4.488 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-1.887, 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 CBHeHmf5uedq for ; Thu, 23 Feb 2017 16:39:33 -0800 (PST) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 A55831293E8 for ; Thu, 23 Feb 2017 16:39:33 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1ch3v2-0005jK-0q for quic@ietf.org; Fri, 24 Feb 2017 01:39:33 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1ch3ux-0005BG-Rw for quic@ietf.org; Thu, 23 Feb 2017 19:39:31 -0500 Received: (qmail 3242 invoked from network); 24 Feb 2017 00:39:27 -0000 Received: from unknown (HELO [192.168.1.105]) (Authenticated-user:_huitema@huitema.net@[172.56.42.108]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Feb 2017 00:39:27 -0000 To: quic@ietf.org References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> <6a7c4ca2-1955-d290-a400-9f9eefe49671@it.uc3m.es> From: Christian Huitema Message-ID: <2a86ab62-9d7f-87a7-1d81-8faa2fa06787@huitema.net> Date: Thu, 23 Feb 2017 16:39:29 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt X-Originating-IP: 168.144.250.190 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlVTHAar8Je/lORhy3PZJU8LERWeKKG4PAQY Nyavp7c49Nd7AN7sevoJn7jQtAGeOfdTugiLDom8V25hond3K4RsO76XSTAwtV4mg4i2ouCDa4AU hvIWAV5xUW/+gAh4vXqT3GX+XQDNdOaBhI8+RiXcRcOb18WfxGyg6Om6u4YYm1OHPxBZow7yPTaZ U4TjqsU5hjoyEb9Oq0NWpyO3vrfYvxyiiU8VkSVtodr6VFoM0T3dKxLhoxcmaInYbR5vlqGudzLe k2TYFBStSOMccbr5Uz0sPgnpAk2KA2vJwMd1uWhCmLzOxTAcQmFWVARhgNqBNFD3an3wiMp49rVr ybSBCDRZgQnFYkq0SOLrmvxpFxQRCdMNhge1Unb77YyuZq6r2tukjs2g1RDPktDz6lIbRBdQ80wr wyng3wNtDYr6IWSdEOMftBjsWb6BDQzjSsEw7+KMtoemwN8keIAcPKMBBQ67muZNm3G2c8/Pjjqy k0k0bdVHmDm5y9NcoZdM30MpNkbYYJ8YZ7d5zi74j6F/pxvnk7PJGygctl3LC86in/6DwZpjxPTx I2S/vwoydU3rc+Iv2rc9L0aEB794CHU7QkUmTDfMv/tVj9RPDK26f1ZS3ljmeFVRIgA8pd5GE2NV TgVI3tePcP+0TP9kyYEYG2p7i/1b6pIUFLqL55u/1geYUOp7A73HI6oJg7w/VodqDS3jhFVyYvjB Ar8iUjNZzB9tfY+mOJVw0e2xMRa7D2P5RYOa/miinTReZ5OdasFBlor8ikxQTKPsYxS4ne8tEzDd JFEeZx0L8qYzBLK5yNBqLkXGaznuCfaQ1w/JpOE= X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 00:39:38 -0000 On 2/23/2017 1:09 AM, Martin J. Dürst wrote: > > It would be nevertheless extremely helpful if that acronym would be > expanded once, e.g. early in the introduction. Using "Explicit > Congestion Notification" in the title would be even better, there are > already many good examples for this: > > https://tools.ietf.org/html/rfc6679 > https://tools.ietf.org/html/rfc7560 > https://tools.ietf.org/html/draft-bagnulo-tcpm-generalized-ecn-00 > https://tools.ietf.org/html/draft-ietf-aqm-ecn-benefits-08 > https://tools.ietf.org/html/draft-ietf-tsvwg-ecn-experimentation-00 > and to some extent https://tools.ietf.org/html/rfc6789 > > "Explicit Congestion Notification" is pretty much self-explaining, but > "ENC" isn't even on a list like > http://acronyms.thefreedictionary.com/ENC. Yes, please. I understand where Mirja comes from, and I also understand what ECN means in this context, but Philip has a good point. QUIC straddles several layers of our stack, from transport to application through security. Three letters acronyms are way more ambiguous than you may think, even inside the IETF. For example, I guess you all know that FEC means Forward Error Correction, right? But if you have to use MPLS, FEC means Forwarding Equivalence Class. So, please, just be conservative. Use the full spelling of the acronyms in the title, abstract and introduction of documents! -- Christian Huitema From nobody Thu Feb 23 17:31:22 2017 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 727FB129442 for ; Thu, 23 Feb 2017 17:31:19 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 ruXzwqDqfHw0 for ; Thu, 23 Feb 2017 17:31:17 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 583A312943F for ; Thu, 23 Feb 2017 17:31:17 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C2467200015; Fri, 24 Feb 2017 01:31:16 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id A7850200010; Fri, 24 Feb 2017 01:31:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487899876; bh=elMd63sASxoIlgfSxGN3RCpiIU+LI8M2rH7+sHyT5Ks=; l=23466; h=From:To:Date:References:In-Reply-To:From; b=r6sxTdBAxyXw0gvrvvS4X3cZxGIhIZKMge4g6jteJfF8MJYjR4D4/pKnzP8GM7o4G sVZR+3EyBzmtVMbRBPyRpvUkHGNO1Va6w4gNG/JLQ1ZdDvFW7FhUsFW7oW5aKGYaPD B/e1nF4kCWXEeAtZ6i+a7ZtIRDXtIF7dE/rB8Fb4= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 7717298082; Fri, 24 Feb 2017 01:31:16 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 23 Feb 2017 20:31:16 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 23 Feb 2017 20:31:15 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Thu, 23 Feb 2017 20:31:15 -0500 From: "Lubashev, Igor" To: Martin Duke , IETF QUIC WG Subject: RE: Clean shutdown semantics Thread-Topic: Clean shutdown semantics Thread-Index: AQHSjix9ndCie+YYTUKntRh+CYNgNKF3Wizg Date: Fri, 24 Feb 2017 01:31:15 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.36.22] Content-Type: multipart/alternative; boundary="_000_db9695fdf973460b9e62d38fa473bd6cusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 01:31:19 -0000 --_000_db9695fdf973460b9e62d38fa473bd6cusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2XigJl2ZSBhY3R1YWxseSBkaXNjdXNzZWQgcmVsYXRlZCBpc3N1ZXMgZWFybGllciB0b2RheS4g IFlvdSBjYW4gYWxzbyBzZWUgaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9p c3N1ZXMvMzMwDQoNCg0KDQrDmCAgQnV0IGlmIHRoZSBhY2sgaW4gKGIpIGlzIGxvc3QsIHRoZW4g ZW5kcG9pbnQgQiByZWNlaXZlcyBDT05ORUNUSU9OX0NMT1NFIHdoaWxlIGRhdGEgaXMgc3RpbGwg b3V0c3RhbmRpbmcuIEkgYmVsaWV2ZSB0aGUgc3BlYywgYXMgd3JpdHRlbiwgc2F5cyB0byB0cmVh dCB0aGlzIGFzIGFuIGFicnVwdCBzaHV0ZG93biBhbmQgdGhyb3cgdGhlIHF1ZXVlZCBkYXRhIG9u IHRoZSBmbG9vci4NCg0KTm8gZGF0YSBpcyBhY3R1YWxseSBvdXRzdGFuZGluZyBpbiB0aGlzIHNj ZW5hcmlvLCBzaW5jZSBwZXIgKGIpLCBBIHJlY2VpdmVkIGFsbCBkYXRhLiAgV2hlbiBCIHNlZXMg Q09OTkVDVElPTl9DTE9TRSwgaXQga25vd3MgdGhhdCBlaXRoZXIgQSByZWNlaXZlZCBhbGwgZGF0 YSAoaW5jbHVkaW5nIEZJTiksIG9yIEEgaXMgbm8gbG9uZ2VyIGludGVyZXN0ZWQgaW4gYW55IGRh dGEgZnJvbSBCLiBJbiBhbnkgY2FzZSwgdGhlcmUgaXMgbm8gcHJvYmxlbSBmb3IgQiB0byBkcm9w IGl0cyBxdWV1ZSBhbmQgYmUgZG9uZS4NCg0KSWYgQiByZWFsbHkgZGVzaXJlcyB0byBkaWZmZXJl bnRpYXRlIGJldHdlZW4gd2hldGhlciBBIHJlY2VpdmVkIGFsbCBkYXRhIG9yIHN1ZGRlbmx5IGxv c3QgaW50ZXJlc3QgaW4gZGF0YSwgdGhlcmUgaXMgYW4gZXJyb3IgY29kZSBvbiBDT05ORUNUSU9O X0NMT1NFLiBJIHN1cHBvc2UgUVVJQ19TVFJFQU1fTk9fRVJST1Igd291bGQgbWVhbiBhbiBvcmRl cmx5IHNodXRkb3duLCB3aGljaCBpcyB0aGUgY2FzZSBvZiBBIHJlY2VpdmluZyBhbGwgZGF0YS4g IEluIGFueSBjYXNlLCB5b3UgY2Fubm90IHRlbGwgdGhpcyBvbmUgZm9yIHN1cmUgd2l0aCBUQ1Ag ZWl0aGVyLCBzaW5jZSBldmVuIGlmIHRoZSB0cmFuc3BvcnQgY2FuIGdpdmUgeW91IGFuIGFzc3Vy YW5jZSB0aGF0IGFsbCBkYXRhIGhhcyBiZWVuIHJlY2VpdmVkLCB0aGVyZSBpcyBubyBndWFyYW50 ZWUgdGhhdCB0aGUgYXBwbGljYXRpb24gd291bGQgcmVhZCB0aGF0IGRhdGEuDQoNCg0KLSAgICAg ICAgICBJZ29yDQoNCg0KRnJvbTogTWFydGluIER1a2UgW21haWx0bzptYXJ0aW4uaC5kdWtlQGdt YWlsLmNvbV0NClNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyMywgMjAxNyA2OjI4IFBNDQpUbzog SUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogQ2xlYW4gc2h1dGRvd24gc2Vt YW50aWNzDQoNCkkgYW0gY29uc2lkZXJpbmcgb3BlbmluZyBpc3N1ZSBhYm91dCBjbGVhbiBzaHV0 ZG93biBzZW1hbnRpY3MsIGJ1dCB3YW50ZWQgdG8gYm91bmNlIGl0IG9mZiB0aGUgbGlzdCBmaXJz dCBpbiBjYXNlIHRoZXJlIGlzIHNvbWV0aGluZyBvYnZpb3VzIEkgYW0gbWlzc2luZy4NCg0KSW4g VENQLCBhZnRlciBhIGNsZWFuIHNodXRkb3duIGJvdGggZW5kcG9pbnRzIGhhdmUgYSByZWFzb25h YmxlIGFzc3VyYW5jZSB0aGF0ICgxKSBBbGwgZGF0YSB0aGV5IHNlbnQgd2FzIGFja25vd2xlZGdl ZCwgYW5kICgyKSB0aGUgcGVlciB3YXMgYWJsZSB0byBkZWxpdmVyIGFsbCB0aGUgZGF0YSBpdCB3 YW50ZWQuIFRoaXMgaXMgYSBwcm9wZXJ0eSBvZiB0aGUgY29ubmVjdGlvbiBGSU4gYmVpbmcgYSBi eXRlIGluIGEgY29ubmVjdGlvbi13aWRlLCByZWxpYWJseSBkZWxpdmVyZWQgc2VxdWVuY2Ugc3Bh Y2UuDQoNCkkgc2VlIHR3byBhc3BlY3RzIG9mIFFVSUMgdGhhdCByZXN1bHQgaW4gdGhpcyBhc3N1 cmFuY2Ugbm90IHF1aXRlIGJlaW5nIGFjaGlldmFibGUuIFRoaXMgbWF5IGJlIGEgcmVzdWx0IG9m IGVkaXRvcmlhbCBpbmNvbXBsZXRlbmVzcywgb3Igc29tZXRoaW5nIGJha2VkIGludG8gd2hhdCBH b29nbGUgaW1wbGVtZW50ZWQuDQoNCigxKSBHT0FXQVkgaXMgYmlkaXJlY3Rpb25hbC4gVGhlcmUg aXMgbm8gd2F5IHRvIHNheSAiSSBhbSBkb25lIG9wZW5pbmcgc3RyZWFtcywgYnV0IHlvdSBjYW4g b3BlbiBtb3JlIHN0cmVhbXMgaWYgeW91IG5lZWQgdG8uIiBJIGRvbid0IHNlZSBhIHdheSB0byBj bGVhbmx5IGNsb3NlIHRoZSBjb25uZWN0aW9uIGFuZCBrbm93IGZvciBzdXJlIHRoYXQgdGhlIHBl ZXIgZGlkbid0IGhhdmUgbW9yZSBzdHJlYW1zIHRvIG9wZW4uDQoNCigyKSBDT05ORUNUSU9OX0NM T1NFIGlzIGFtYmlndW91cyBiZXR3ZWVuIGFicnVwdCBhbmQgZ3JhY2VmdWwgc2h1dGRvd25zLiBU aGVyZSBhcmUgc29tZSByZWxhdGVkIGxvZ2ljIGlzc3VlcyB0b28uDQoNCihhKSBTYXkgdGhhdCBJ IGFtIGVuZHBvaW50IEEgd3JhcHBpbmcgdXAgYSBjb21tdW5pY2F0aW9uIHdpdGggZW5kcG9pbnQg Qi4gV2UndmUgYWxyZWFkeSBzZW50IEdPQVdBWShzKSwgYW5kIEkgc2VuZCBhIHBhY2tldCB0aGF0 IHNlbmRzIHRoZSBsYXN0IGRhdGEgYW5kIEZJTiBmb3IgYWxsIHJlbWFpbmluZyBzdHJlYW1zLg0K DQooYikgSSB0aGVuIHJlY2VpdmUgYSBzaW1pbGFyIHBhY2tldCBmcm9tIEIsIGRlbGl2ZXJpbmcg c29tZSBkYXRhIGFuZCBGSU5pbmcgYWxsIG9wZW4gc3RyZWFtcywgd2hpY2ggSSBhY2tub3dsZWRn ZS4NCg0KKGMpIEkgcmVjZWl2ZSBhIHBhY2tldCBvbmx5IGNvbnRhaW5pbmcgYW4gQUNLIGZyYW1l IGZvciBwYWNrZXQgKGEpLiBJIG5vdyBoYXZlIGFzc3VyYW5jZSB0aGF0IGFsbCBteSBkYXRhIGlz IGRlbGl2ZXJlZCwgYW5kIEkgaGF2ZSByZWNlaXZlZCBldmVyeXRoaW5nIEIgaGFzIGZvciBtZS4g VGhlcmUgaXMgbm8gYWNrIHRvIHNlbmQgYmVjYXVzZSB0aGVyZSBpcyBvbmx5IGFuIEFDSyBmcmFt ZS4NCg0KKGQpIEkgdGhlcmVmb3JlIHNlbmQgQ09OTkVDVElPTl9DTE9TRS4NCg0KQnV0IGlmIHRo ZSBhY2sgaW4gKGIpIGlzIGxvc3QsIHRoZW4gZW5kcG9pbnQgQiByZWNlaXZlcyBDT05ORUNUSU9O X0NMT1NFIHdoaWxlIGRhdGEgaXMgc3RpbGwgb3V0c3RhbmRpbmcuIEkgYmVsaWV2ZSB0aGUgc3Bl YywgYXMgd3JpdHRlbiwgc2F5cyB0byB0cmVhdCB0aGlzIGFzIGFuIGFicnVwdCBzaHV0ZG93biBh bmQgdGhyb3cgdGhlIHF1ZXVlZCBkYXRhIG9uIHRoZSBmbG9vci4NCg0KRnVydGhlcm1vcmUsIEIg aXMgcmVxdWlyZWQgdG8gYWNrbm93bGVkZ2UgdGhlIENPTk5FQ1RJT05fQ0xPU0UgZnJhbWUuIEV2 ZW4gaWYgaXQgd2VyZSB0byBrZWVwIHRoZSBzZW5kIHF1ZXVlIGFmdGVyIENPTk5FQ1RJT05fQ0xP U0UsIHRoZSBhY2sgd291bGQgcHJvYmFibHkgZ28gb3V0IGZpcnN0LiBTbyBBIGNhbiB0ZWFyIGRv d24gaXRzIGNvbm5lY3Rpb24gYmVmb3JlIEIgaGFzIGFueSBhc3N1cmFuY2UgdGhhdCBBIGdvdCBh bGwgaXRzIGRhdGEuDQoNClRoZXJlIGFyZSBzZXZlcmFsIG1pbm9yIHByb3RvY29sIGVkaXRzIHRv IGF2b2lkIGFsbCB0aGUgcHJvYmxlbXMgaW4gdGhpcyBzY2VuYXJpby4gQnV0IEkgZG9uJ3QgYmVs aWV2ZSB0aGUgc3BlYyBhcyB3cml0dGVuIGlzIHN1ZmZpY2llbnQuDQoNCk1hcnRpbiBEdWtlDQo= --_000_db9695fdf973460b9e62d38fa473bd6cusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29MaXN0UGFyYWdy YXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBpbjsNCgltYXJnaW4t cmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47DQoJbWFy Z2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCglt YXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28t bGlzdC1pZDoxNjUwMjA1NzA7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOjIxMDQwMDI0MjIgMTk3NTU3NDMyNCA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxDQoJe21zby1s aXN0LWlkOjE0MjE3NTY5NDg7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVt cGxhdGUtaWRzOi0xMzA3Nzc2NzEyIDczMTgxNTg1NiA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBs MTpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFyZWFzdC1mb250LWZhbWlseTpDYWxp YnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwx OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVT IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5XZeKAmXZlIGFjdHVh bGx5IGRpc2N1c3NlZCByZWxhdGVkIGlzc3VlcyBlYXJsaWVyIHRvZGF5LiZuYnNwOyBZb3UgY2Fu IGFsc28gc2VlDQo8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRz L2lzc3Vlcy8zMzAiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvaXNzdWVz LzMzMDwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxp c3Q6bDEgbGV2ZWwxIGxmbzEiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0 Oklnbm9yZSI+w5g8c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDsiPiZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPkJ1dCBpZiB0aGUg YWNrIGluIChiKSBpcyBsb3N0LCB0aGVuIGVuZHBvaW50IEIgcmVjZWl2ZXMgQ09OTkVDVElPTl9D TE9TRSB3aGlsZSBkYXRhIGlzIHN0aWxsIG91dHN0YW5kaW5nLiBJIGJlbGlldmUgdGhlIHNwZWMs IGFzIHdyaXR0ZW4sIHNheXMgdG8gdHJlYXQgdGhpcyBhcyBhbiBhYnJ1cHQgc2h1dGRvd24gYW5k IHRocm93IHRoZSBxdWV1ZWQgZGF0YSBvbiB0aGUgZmxvb3IuPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Tm8gZGF0YSBpcyBhY3R1YWxseSBvdXRzdGFuZGluZyBpbiB0aGlzIHNjZW5h cmlvLCBzaW5jZSBwZXIgKGIpLCBBIHJlY2VpdmVkIGFsbCBkYXRhLiZuYnNwOyBXaGVuIEIgc2Vl cyBDT05ORUNUSU9OX0NMT1NFLCBpdCBrbm93cyB0aGF0IGVpdGhlciBBIHJlY2VpdmVkIGFsbCBk YXRhIChpbmNsdWRpbmcgRklOKSwNCiBvciBBIGlzIG5vIGxvbmdlciBpbnRlcmVzdGVkIGluIGFu eSBkYXRhIGZyb20gQi4gSW4gYW55IGNhc2UsIHRoZXJlIGlzIG5vIHByb2JsZW0gZm9yIEIgdG8g ZHJvcCBpdHMgcXVldWUgYW5kIGJlIGRvbmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPklmIEIgcmVhbGx5IGRl c2lyZXMgdG8gZGlmZmVyZW50aWF0ZSBiZXR3ZWVuIHdoZXRoZXIgQSByZWNlaXZlZCBhbGwgZGF0 YSBvciBzdWRkZW5seSBsb3N0IGludGVyZXN0IGluIGRhdGEsIHRoZXJlIGlzIGFuIGVycm9yIGNv ZGUgb24gQ09OTkVDVElPTl9DTE9TRS4gSSBzdXBwb3NlIFFVSUNfU1RSRUFNX05PX0VSUk9SDQog d291bGQgbWVhbiBhbiBvcmRlcmx5IHNodXRkb3duLCB3aGljaCBpcyB0aGUgY2FzZSBvZiBBIHJl Y2VpdmluZyBhbGwgZGF0YS4mbmJzcDsgSW4gYW55IGNhc2UsIHlvdSBjYW5ub3QgdGVsbCB0aGlz IG9uZSBmb3Igc3VyZSB3aXRoIFRDUCBlaXRoZXIsIHNpbmNlIGV2ZW4gaWYgdGhlIHRyYW5zcG9y dCBjYW4gZ2l2ZSB5b3UgYW4gYXNzdXJhbmNlIHRoYXQgYWxsIGRhdGEgaGFzIGJlZW4gcmVjZWl2 ZWQsIHRoZXJlIGlzIG5vIGd1YXJhbnRlZSB0aGF0IHRoZQ0KIGFwcGxpY2F0aW9uIHdvdWxkIHJl YWQgdGhhdCBkYXRhLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzIiPjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4g c3R5bGU9Im1zby1saXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1Rp bWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj5JZ29yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+IE1hcnRpbiBEdWtlIFttYWlsdG86bWFydGluLmguZHVrZUBn bWFpbC5jb21dDQo8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDIzLCAyMDE3 IDY6MjggUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gQ2xlYW4gc2h1dGRvd24gc2VtYW50aWNzPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBjb25zaWRlcmluZyBvcGVuaW5nIGlz c3VlIGFib3V0IGNsZWFuIHNodXRkb3duIHNlbWFudGljcywgYnV0IHdhbnRlZCB0byBib3VuY2Ug aXQgb2ZmIHRoZSBsaXN0IGZpcnN0IGluIGNhc2UgdGhlcmUgaXMgc29tZXRoaW5nIG9idmlvdXMg SSBhbSBtaXNzaW5nLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gVENQLCBhZnRlciBhIGNsZWFuIHNodXRkb3duIGJvdGggZW5kcG9pbnRzIGhhdmUgYSBy ZWFzb25hYmxlIGFzc3VyYW5jZSB0aGF0ICgxKSBBbGwgZGF0YSB0aGV5IHNlbnQgd2FzIGFja25v d2xlZGdlZCwgYW5kICgyKSB0aGUgcGVlciB3YXMgYWJsZSB0byBkZWxpdmVyIGFsbCB0aGUgZGF0 YSBpdCB3YW50ZWQuIFRoaXMgaXMgYSBwcm9wZXJ0eSBvZiB0aGUgY29ubmVjdGlvbiBGSU4gYmVp bmcgYSBieXRlIGluDQogYSBjb25uZWN0aW9uLXdpZGUsIHJlbGlhYmx5IGRlbGl2ZXJlZCBzZXF1 ZW5jZSBzcGFjZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBzZWUgdHdvIGFzcGVjdHMgb2YgUVVJQyB0aGF0IHJlc3VsdCBpbiB0aGlzIGFz c3VyYW5jZSBub3QgcXVpdGUgYmVpbmcgYWNoaWV2YWJsZS4gVGhpcyBtYXkgYmUgYSByZXN1bHQg b2YgZWRpdG9yaWFsIGluY29tcGxldGVuZXNzLCBvciBzb21ldGhpbmcgYmFrZWQgaW50byB3aGF0 IEdvb2dsZSBpbXBsZW1lbnRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+KDEpIEdPQVdBWSBpcyBiaWRpcmVjdGlvbmFsLiBUaGVyZSBpcyBu byB3YXkgdG8gc2F5ICZxdW90O0kgYW0gZG9uZSBvcGVuaW5nIHN0cmVhbXMsIGJ1dCB5b3UgY2Fu IG9wZW4gbW9yZSBzdHJlYW1zIGlmIHlvdSBuZWVkIHRvLiZxdW90OyBJIGRvbid0IHNlZSBhIHdh eSB0byBjbGVhbmx5IGNsb3NlIHRoZSBjb25uZWN0aW9uIGFuZCBrbm93IGZvciBzdXJlIHRoYXQg dGhlIHBlZXIgZGlkbid0IGhhdmUgbW9yZSBzdHJlYW1zIHRvDQogb3Blbi48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KDIpIENPTk5FQ1RJT05f Q0xPU0UgaXMgYW1iaWd1b3VzIGJldHdlZW4gYWJydXB0IGFuZCBncmFjZWZ1bCBzaHV0ZG93bnMu IFRoZXJlIGFyZSBzb21lIHJlbGF0ZWQgbG9naWMgaXNzdWVzIHRvby48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGEpIFNheSB0aGF0IEkgYW0g ZW5kcG9pbnQgQSB3cmFwcGluZyB1cCBhIGNvbW11bmljYXRpb24gd2l0aCBlbmRwb2ludCBCLiBX ZSd2ZSBhbHJlYWR5IHNlbnQgR09BV0FZKHMpLCBhbmQgSSBzZW5kIGEgcGFja2V0IHRoYXQgc2Vu ZHMgdGhlIGxhc3QgZGF0YSBhbmQgRklOIGZvciBhbGwgcmVtYWluaW5nIHN0cmVhbXMuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihiKSBJIHRo ZW4gcmVjZWl2ZSBhIHNpbWlsYXIgcGFja2V0IGZyb20gQiwgZGVsaXZlcmluZyBzb21lIGRhdGEg YW5kIEZJTmluZyBhbGwgb3BlbiBzdHJlYW1zLCB3aGljaCBJIGFja25vd2xlZGdlLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oYykgSSByZWNl aXZlIGEgcGFja2V0IG9ubHkgY29udGFpbmluZyBhbiBBQ0sgZnJhbWUgZm9yIHBhY2tldCAoYSku IEkgbm93IGhhdmUgYXNzdXJhbmNlIHRoYXQgYWxsIG15IGRhdGEgaXMgZGVsaXZlcmVkLCBhbmQg SSBoYXZlIHJlY2VpdmVkIGV2ZXJ5dGhpbmcgQiBoYXMgZm9yIG1lLiBUaGVyZSBpcyBubyBhY2sg dG8gc2VuZCBiZWNhdXNlIHRoZXJlIGlzIG9ubHkgYW4gQUNLIGZyYW1lLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oZCkgSSB0aGVyZWZvcmUg c2VuZCBDT05ORUNUSU9OX0NMT1NFLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5CdXQgaWYgdGhlIGFjayBpbiAoYikgaXMgbG9zdCwgdGhlbiBl bmRwb2ludCBCIHJlY2VpdmVzIENPTk5FQ1RJT05fQ0xPU0Ugd2hpbGUgZGF0YSBpcyBzdGlsbCBv dXRzdGFuZGluZy4gSSBiZWxpZXZlIHRoZSBzcGVjLCBhcyB3cml0dGVuLCBzYXlzIHRvIHRyZWF0 IHRoaXMgYXMgYW4gYWJydXB0IHNodXRkb3duIGFuZCB0aHJvdyB0aGUgcXVldWVkIGRhdGEgb24g dGhlIGZsb29yLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5GdXJ0aGVybW9yZSwgQiBpcyByZXF1aXJlZCB0byBhY2tub3dsZWRnZSB0aGUgQ09O TkVDVElPTl9DTE9TRSBmcmFtZS4gRXZlbiBpZiBpdCB3ZXJlIHRvIGtlZXAgdGhlIHNlbmQgcXVl dWUgYWZ0ZXIgQ09OTkVDVElPTl9DTE9TRSwgdGhlIGFjayB3b3VsZCBwcm9iYWJseSBnbyBvdXQg Zmlyc3QuIFNvIEEgY2FuIHRlYXIgZG93biBpdHMgY29ubmVjdGlvbiBiZWZvcmUgQiBoYXMgYW55 IGFzc3VyYW5jZSB0aGF0DQogQSBnb3QgYWxsIGl0cyBkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBhcmUgc2V2ZXJhbCBtaW5v ciBwcm90b2NvbCBlZGl0cyB0byBhdm9pZCBhbGwgdGhlIHByb2JsZW1zIGluIHRoaXMgc2NlbmFy aW8uIEJ1dCBJIGRvbid0IGJlbGlldmUgdGhlIHNwZWMgYXMgd3JpdHRlbiBpcyBzdWZmaWNpZW50 LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5N YXJ0aW4gRHVrZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_db9695fdf973460b9e62d38fa473bd6cusma1exdag1mb5msgcorpak_-- From nobody Thu Feb 23 18:25:21 2017 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 5532112948F for ; Thu, 23 Feb 2017 18:25:20 -0800 (PST) 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 1a7QdS2ZD8NA for ; Thu, 23 Feb 2017 18:25:18 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4FA12948B for ; Thu, 23 Feb 2017 18:25:18 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id t18so6427728wmt.0 for ; Thu, 23 Feb 2017 18:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6zUEwVo9QRnG5Q4PI784jHICpI0Iw9LbBb8eY3SFN6U=; b=Mmbr+DV/hYYmMcpnwOTmZKb11pS65et0YsL3fcwj6N4ks2/pPRVsdNlROstzgoUJIC UQwvsVuzdjGu8tzD7fVWr8mcSURyGm5B7W2T2Vd74jnoQ+dwzotXLo0qgAlF8tShRYSb jmkO5O+G9+1cmiy1RbyJGbZ3iRiAgbG+UuOYY9LCzSgGbcwn9drl8nt4+2IEQugX1xZR KiXsfIlXSdG4SqxliJyn1imqCX/c7jfpi6fXm43jEWkS0I8fs70pynRYqdN0AorThssj aOCYRIWNWOlC01DoZBjrMTHlgCu61AQBmEwHebJKzFIyP6lx10627R++GlxPRZug2aCA m/6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6zUEwVo9QRnG5Q4PI784jHICpI0Iw9LbBb8eY3SFN6U=; b=dParbmMqNo8vH1COBFbTKmaJ94PeY9sKr0EmBrpozR9FKkT7yA/PV/m0ofPyODjsxU 43KcqdoKHEKaXcDYLm41FSk8NIIAksYFRZlotL3UN1LciyAKjECe18Wz+Ezd7G7CTHHd rQDWM/CtGu5a5G+HLRS2Xl90SEiuj6ExCi6NBXRUCEF2c9ulGMJ29TuQehjmPSJdVy1/ Q/j7jgy2gR0N8aEXJBLgrYzvHmhcclUnnJu9q/NIUZdHkPRKsa0qHTx/cKpzjxJ9Fg4Y SBZ4EmzrP1cSnpQUyP742wsCPao6WsBcqOeOsA5sJLEJeVAR070gIWeQq0X36APAoOg5 21Rg== X-Gm-Message-State: AMke39n/0ozRbQT/ONdjO6NjYpy/xtJPZb+0xT1rWb1va3dZNcSyhGsM1CFbTVPYHmgHL0WNyXMb2EXPsuXriQ== X-Received: by 10.28.210.139 with SMTP id j133mr473606wmg.67.1487903116867; Thu, 23 Feb 2017 18:25:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.164.18 with HTTP; Thu, 23 Feb 2017 18:25:16 -0800 (PST) In-Reply-To: References: <409a06de-1fff-c6c2-eb97-e625ae990a3a@gmx.de> From: Watson Ladd Date: Thu, 23 Feb 2017 18:25:16 -0800 Message-ID: Subject: Re: QUIC should be designed for HTTP-Next, not HTTP/2 To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Julian Reschke , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 02:25:20 -0000 On Thu, Feb 23, 2017 at 2:03 PM, Phillip Hallam-Baker wrote: > On Thu, Feb 23, 2017 at 1:41 PM, Julian Reschke > wrote: >> >> To state the obvious: then it would need to be defined in the HTTP WG... > > > Ummm no. That is the very last place I would want to discuss it. > > This would not be HTTP/3, it would be a complete discontinuity. > > It certainly isn't something to start building in QUIC either. But the way I > look at it, QUIC is similar to a subway system for a city. When you are > building a subway you don't just build it for the city as it is today, you > build it for what you expect it to grow into. > > The easy part of QUIC is going to be building the protocol itself. The part > that always ends up being hard is how to move from the legacy base to the > new system efficiently in a way that does not foreclose future growth. Dear Philip, QUIC provides a negotiation mechanism for the transported protocol. It provides multiplexed schemes. What specifically do you think is forclosing the possibility of other transports? Sincerely, Watson > > > >> >> On 2017-02-23 18:20, Phillip Hallam-Baker wrote: >>> >>> ... >>> First off, content negotiation is not going to change across requests. A >>> browser is not going to learn to interpret a new image format between >>> one request and another for the same page. Or not often enough to bother. >>> >>> So I had assumed we would be using some form of scheme where we push the >>> content negotiation headers at the start of a connection and amortize >>> them across multiple requests. >>> ... >> >> >> That's what HPACK already does in HTTP/2, no? > > > Like I said, that is the scheme I thought we would be the end point but I > now see it as merely a waypoint to something else. > > -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Thu Feb 23 18:40:22 2017 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 DE16B12949E for ; Thu, 23 Feb 2017 18:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 9HcgK4aD67eZ for ; Thu, 23 Feb 2017 18:40:19 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::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 496A5129443 for ; Thu, 23 Feb 2017 18:40:19 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id p77so4623256ywg.1 for ; Thu, 23 Feb 2017 18:40:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=WItxnnTE9DHcvJEzXWjizfsJ0jjHU+1/zQSlNAB22NA=; b=BZz+4JrgqpGehFXOqUlCj5OIHzTf2ZYLqYrai7MmJ+BcSiG5iPrEMggKa765SFYGGu GIZmy8aIvRB3FgHuhnlAK063sjsKNT8j0ovCV5np20cTP46lYbFQcfS1lRP5GhUdrvWw e4oQqGQvWhY9XuKNXV+l+5i3tKwPu3YMywt9J7RHBP99fE4aZenKsc3qOn7NkyYTIKHy 4e5cppTGr3KTQDyHXPp56Ds8dgh7rUOwoKfibwMc8Ghr2oeti+A1TQ1JVMr7G3yt1Yc9 N8idm/3rG6DVhUndhdQLz2TcpSrNzWfk6ynFNUsPypNq7ukfRDYsCN3YxSBqJIqvI+v8 RfLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=WItxnnTE9DHcvJEzXWjizfsJ0jjHU+1/zQSlNAB22NA=; b=ceRVYXfYz5xqy2v6r1Om619ytHu7wyqxi48X6kpOUR9DAg74kSl5Ear5N9CINdKKg8 8F0vJ9Cr5yF9bSwHPH9u0i4sGl2kDmu8pwlOjhMKVH9+GAEvjlKyM6XTNmt+IsYk12Gy BHe28Lj/CVVSMyEIxDcM3MJtpx8bDf02xo3R78WzCKWs72MoyVUT9wVf6vQtY8zOkATA 2hWVD8kEBp0xMnLXBQE9SBsqC9grS3s3518KQb4RwPFbJ5vViD/SjkqNyY7GAnAPQQ/4 /Zg9LxjLtEgx2QvQoB1cB1vwENc57ZgumPirbfPi302CUAJN6usj5WnBcTOcGfAiYm11 IVxQ== X-Gm-Message-State: AMke39mPHV96+SU920FdG/uc6LUWZHMolK1bF3zKEjCm8gvoU9PXwQYZzqU3ulShxl4vdWqEmKOAFDDC65+5Og== X-Received: by 10.129.153.19 with SMTP id q19mr283943ywg.186.1487904018576; Thu, 23 Feb 2017 18:40:18 -0800 (PST) MIME-Version: 1.0 Sender: hallam@gmail.com Received: by 10.83.19.20 with HTTP; Thu, 23 Feb 2017 18:40:18 -0800 (PST) In-Reply-To: References: <409a06de-1fff-c6c2-eb97-e625ae990a3a@gmx.de> From: Phillip Hallam-Baker Date: Thu, 23 Feb 2017 21:40:18 -0500 X-Google-Sender-Auth: rXY9YNG7iIRXdup9kznknr7MkNI Message-ID: Subject: Re: QUIC should be designed for HTTP-Next, not HTTP/2 To: Watson Ladd Content-Type: multipart/alternative; boundary=94eb2c0b7a5c7cbf1f05493da68a Archived-At: Cc: Julian Reschke , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 02:40:21 -0000 --94eb2c0b7a5c7cbf1f05493da68a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Feb 23, 2017 at 9:25 PM, Watson Ladd wrote: > On Thu, Feb 23, 2017 at 2:03 PM, Phillip Hallam-Baker > wrote: > > On Thu, Feb 23, 2017 at 1:41 PM, Julian Reschke > > wrote: > >> > >> To state the obvious: then it would need to be defined in the HTTP WG.= .. > > > > > > Ummm no. That is the very last place I would want to discuss it. > > > > This would not be HTTP/3, it would be a complete discontinuity. > > > > It certainly isn't something to start building in QUIC either. But the > way I > > look at it, QUIC is similar to a subway system for a city. When you are > > building a subway you don't just build it for the city as it is today, > you > > build it for what you expect it to grow into. > > > > The easy part of QUIC is going to be building the protocol itself. The > part > > that always ends up being hard is how to move from the legacy base to t= he > > new system efficiently in a way that does not foreclose future growth. > > Dear Philip, > QUIC provides a negotiation mechanism for the transported protocol. It > provides multiplexed schemes. What specifically do you think is > forclosing the possibility of other transports? > Sincerely, > Watson > > =E2=80=8BThe fact that I expect certain parties to demand it be achieved in= zero round trips (or less). =E2=80=8B --94eb2c0b7a5c7cbf1f05493da68a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Thu, Fe= b 23, 2017 at 9:25 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
On Thu, Feb 23= , 2017 at 2:03 PM, Phillip Hallam-Baker
<phill@hallambaker.com> = wrote:
> On Thu, Feb 23, 2017 at 1:41 PM, Julian Reschke <julian.reschke@gmx.de>
> wrote:
>>
>> To state the obvious: then it would need to be defined in the HTTP= WG...
>
>
> Ummm no. That is the very last place I would want to discuss it.
>
> This would not be HTTP/3, it would be a complete discontinuity.
>
> It certainly isn't something to start building in QUIC either. But= the way I
> look at it, QUIC is similar to a subway system for a city. When you ar= e
> building a subway you don't just build it for the city as it is to= day, you
> build it for what you expect it to grow into.
>
> The easy part of QUIC is going to be building the protocol itself. The= part
> that always ends up being hard is how to move from the legacy base to = the
> new system efficiently in a way that does not foreclose future growth.=

Dear Philip,
QUIC provides a negotiation mechanism for the transported protocol. It
provides multiplexed schemes. What specifically do you think is
forclosing the possibility of other transports?
Sincerely,
Watson

<= br>
=E2=80=8BTh= e fact that I expect certain parties to demand it be achieved in zero round= trips (or less). =E2=80=8B

--94eb2c0b7a5c7cbf1f05493da68a-- From nobody Thu Feb 23 19:10:56 2017 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 85CA41294E8 for ; Thu, 23 Feb 2017 19:10:55 -0800 (PST) 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 GYT9RY6inhKd for ; Thu, 23 Feb 2017 19:10:54 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d: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 365F51294DB for ; Thu, 23 Feb 2017 19:10:54 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id x71so9101280qkb.3 for ; Thu, 23 Feb 2017 19:10:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pgjPc87uFWq5PtoL+9WZ1LZFYFABpLtLTR2At8iq+SA=; b=Hu3+dRR6U8kOflf7GhwP4wZLu+/CNhNbeBPGZb6xOxC23dt0/Z2XARxJm9fRiG0MmZ R5X/Kjkt3dw3VAb5D/mC1ikdsXzSd62/0b53C/UX2NNNCagQYBdD4hl3kQdMRSwEQ52A PTzxvb2Ko28Du4mghQPPPJOzeh6GJOvAgTSUDz5UeqGHO2i5+m04NNR9PX3H/Fr82jTd BTozHZMxpbAOUjQTr2pCEILr4/RrgqpBsH3Qm36oW2lwOqxRYU1qEsnL4YOkJt0lvWdc pqzUn7lta8msvzppmZHFZ2up/CFdi6ZdjjLB7rfcjQBY8vnA0VN3HoRs4ndZs4HQqM6p n53g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pgjPc87uFWq5PtoL+9WZ1LZFYFABpLtLTR2At8iq+SA=; b=NbqjMlErsXL3Cb17hHjfgBUndgl4BcLx9UnQrS+CEAZp035N003EQIMGc7k2+vd7+7 8qXJhFkZD8Fl1vXLUxhsFVIB0982zG7W23VnKobgL6Nr0NIMLdyx5OyXzPp2zFZ/KR46 Lyilk3J/lM4wqXx1k4K1isBw66NxzZ3cN5oZ0BMWFjWPQvmqovwD8qRKXk+KlRTWMF/X rmkfYCZtEe3xSAdo+8yAeD7QTFKrtrWuZA2ho9ahN/ZKGEgS4eV7R8u86mpnyLjdF7AT 9VOLATyzVTTA1wuiJTvgBzAvftsxxRKZHUlDmCTrLN7MydJvaKxKN0yxGwcdeGAzrtbZ 9R0w== X-Gm-Message-State: AMke39k/ShOSFq3TKgpxs5m5RcBwQAI0TZRZuXPtYitfnObCxvX3oTfUuQML4DL4Ifb3dIgTyedKnRj1sJx6vg== X-Received: by 10.55.209.86 with SMTP id s83mr508704qki.144.1487905853408; Thu, 23 Feb 2017 19:10:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 23 Feb 2017 19:10:52 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 24 Feb 2017 14:10:52 +1100 Message-ID: Subject: Re: Alternate header proposal To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:10:55 -0000 On 23 February 2017 at 03:58, Eric Rescorla wrote: > > Also, maybe I'm missing something, but where's the key change bit? That > seems to have > gone missing and AFAICT you are still going to need it unless you have some > thought > of swapping to long headers during the key change period until you see acks > or something > else equally gross. Wasn't there another set of types for that? They must have gone missing, which I'm sure is an accident. I'm of the opinion that we probably just want to use a bit for this and the long/short marker as well. Even more so for the latter. From nobody Thu Feb 23 19:13:36 2017 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 A57F71294DB for ; Thu, 23 Feb 2017 19:13:34 -0800 (PST) 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 N8ffrwVtHJQV for ; Thu, 23 Feb 2017 19:13:33 -0800 (PST) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::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 700341294E6 for ; Thu, 23 Feb 2017 19:13:33 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id r45so8170164qte.3 for ; Thu, 23 Feb 2017 19:13:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GKhutEcliC52EKhLYyetxA095Eh6rTMiqZXmjXeoZGI=; b=JnOmxcoQxAf+uf+jlxPzcJlzL4isUasgoiMh9tU51f2jQnaJvteT9jBSehltQJnVtF T4y4nqWU6eTcwFJ+43gStK6jb7RugaTRjDWNIpqMfuOTcAAsZjd7enlUgUDiJ2gR4qv2 gU5B9meX5Xy0ojq2ETSUQQ6opYU0O4KPtCqnKrCSDhJnAuPaJfiWbPmux4MY6hVLtbnh T5ZQIH1yIpeJqak3uil7IeD9Kg+Vb+LEeZN15rh43N7eBzW4h9Iqf8rgchiVQMLV6PeL 30Jqg+Ve6C1TRlRxJj8tBTWWNY4TtXqJu3TizZWhHXxuYhfxGbZdPYgj7QNV4jvaYAMj RvMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GKhutEcliC52EKhLYyetxA095Eh6rTMiqZXmjXeoZGI=; b=o6D5EB9olxy9KJvbMEsnsYRKkzuTjwi0hvh1c7gxnElFA2vd3/9n7doICffK0HXaRR T8FN9bo4j8wzzhEcABP7fmDyyYTGefKKz6UP//2+WhEZWWEhq/+/NoNR07tT4ZZfYpk8 tPcxa89zfynWUI636u+xKVJoB3/vbSm7EqQIc4wuH4FrAPxQFmMQJ2AjYW1GHFT/H+kx epb5yB807OL8gRlH1p+sVBh2rBGiB8gh2oWNs/L9jD+XbkT1FIQJ9PlcAxidI0gKv13/ Jh6XBbgYQbhF0mjoRQH8NEnLOoV8bTqBVM9Yn+kA7QNTcn1lzRWoyMHlwugfhvim7uGC ZRoA== X-Gm-Message-State: AMke39nClkbqm/wBl+SDmSV2LqH8kFNSO5hSqvhxCQIQqLwqs7cNK/R7kYwyMa8gN0Z01k/V1tF6uGHmwS+rHQ== X-Received: by 10.200.39.200 with SMTP id x8mr460047qtx.159.1487906012572; Thu, 23 Feb 2017 19:13:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 23 Feb 2017 19:13:32 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 24 Feb 2017 14:13:32 +1100 Message-ID: Subject: Re: Error handling and Public Reset To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Eric Rescorla , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:13:34 -0000 On 24 February 2017 at 07:15, Jana Iyengar wrote: >> Yes, I think that's the right conclusion. I do think we can land your >> header patch with a >> [TODO] in this slot because it's a self-contained issue. > > > Agreed. (I'll get a PR for the header proposal soon.) Based on this (I was just hoping to include what was in the draft), it seems like it would be easier to require that unauthenticated public resets be dropped. We can later decide whether to include a proof that consists of "I saw a packet from you" as opposed to "I was part of the initial connection setup" if that is the way the wind blows on that day. I have excised the offending text. I would prefer to make progress on those parts that I was really trying to hit: how to signal errors, not overusing public resets, and so forth. From nobody Thu Feb 23 19:17:04 2017 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 1E6DB129CCE for ; Thu, 23 Feb 2017 19:17:03 -0800 (PST) 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 bTLehqbeavYN for ; Thu, 23 Feb 2017 19:17:01 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAE7D129CAB for ; Thu, 23 Feb 2017 19:17:01 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id u188so9207175qkc.2 for ; Thu, 23 Feb 2017 19:17:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SZxHt46gZiurLwuikiaaywBXnhBPW1yXcvMl7U8o5Zk=; b=CKXYjz++994yfHbI7YD+kIj4p4Q2ijZxf4mMxlgXPTxSVw+uh1K1axC7f1qSpvCOxl fvBAkCQsCZEpMhJlwuY8o826PAOEQHXPLJraSz6c8XFpsensLsiDLZrhJrzChBgsXdZI mdQYulUH5/hIvk9QVH/H7X9nrCCAhH7ovs8s1ZwvThEL/2gxuKoj2xoUXpUAwxOJxsym XMclp/nnmMMG3QV7FLYQ/pHJHU46yTFtZ//MAQUqTsQfzSUy9Refsnwdzu2rqXr9wKr6 8ugN/nUEgchaeezclJwhFuSaVTSTUycLabzw0mWg4YxgivnL/azp+gn5qF8y/LLnipKM q7Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SZxHt46gZiurLwuikiaaywBXnhBPW1yXcvMl7U8o5Zk=; b=kwPa61njSqXICDSwXt3cSMTHEZOPqQ+N9D6I2PlM9h+AC6+2A0IjOeq5zDUd6n3l7X 8bzFP4i6D+ccUSBh0AA5cMwguZAoyPejKSP3RMzQSxWvv8AM+Kvk5xNYJLakNKfNOGyC I2BpNw4KIWiTn8kRaohFqwfJ9bQ+nb8UM2gCcWGMskH53mpt3WetB2v6sjvCc2OpbBXS FvBiXvo3hCzC6ZDBqupWxioL8p8og+OIgoTgKrVqtyQSf3ubyB1KXDREU66eYtmC/Qib aogbCGmPOdLCYLwjE//YjvPtYcmpNEISF1akSP2BEvuXX1RmoZnKsIob4bZRi0DSjetc zssQ== X-Gm-Message-State: AMke39l9jj7IGVA0WwQi34xx525uhQlx53zTjF6pxR5lRVnXQHFjGwsUGgWdL6UNSFHm5iu+J+aPJDBT1Lj3Vg== X-Received: by 10.55.185.131 with SMTP id j125mr462842qkf.115.1487906220881; Thu, 23 Feb 2017 19:17:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.19.112 with HTTP; Thu, 23 Feb 2017 19:17:00 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 24 Feb 2017 14:17:00 +1100 Message-ID: Subject: Re: Clean shutdown semantics To: Martin Duke Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 03:17:03 -0000 It might not be helpful to think of QUIC as whole being in one of two states: cleanly closed, or broken. Considering individual streams to be either complete or cancelled helps a lot. To that end, I model GOAWAY as a selective RST_STREAM that cuts the stream space into two and cancels all the streams on one side. CONNECTION_CLOSE then is a universal RST_STREAM. That allows this to be reduced to thinking in terms of the stream state machine. On 24 February 2017 at 10:27, Martin Duke wrote: > I am considering opening issue about clean shutdown semantics, but wanted to > bounce it off the list first in case there is something obvious I am > missing. > > In TCP, after a clean shutdown both endpoints have a reasonable assurance > that (1) All data they sent was acknowledged, and (2) the peer was able to > deliver all the data it wanted. This is a property of the connection FIN > being a byte in a connection-wide, reliably delivered sequence space. > > I see two aspects of QUIC that result in this assurance not quite being > achievable. This may be a result of editorial incompleteness, or something > baked into what Google implemented. > > (1) GOAWAY is bidirectional. There is no way to say "I am done opening > streams, but you can open more streams if you need to." I don't see a way to > cleanly close the connection and know for sure that the peer didn't have > more streams to open. > > (2) CONNECTION_CLOSE is ambiguous between abrupt and graceful shutdowns. > There are some related logic issues too. > > (a) Say that I am endpoint A wrapping up a communication with endpoint B. > We've already sent GOAWAY(s), and I send a packet that sends the last data > and FIN for all remaining streams. > > (b) I then receive a similar packet from B, delivering some data and FINing > all open streams, which I acknowledge. > > (c) I receive a packet only containing an ACK frame for packet (a). I now > have assurance that all my data is delivered, and I have received everything > B has for me. There is no ack to send because there is only an ACK frame. > > (d) I therefore send CONNECTION_CLOSE. > > But if the ack in (b) is lost, then endpoint B receives CONNECTION_CLOSE > while data is still outstanding. I believe the spec, as written, says to > treat this as an abrupt shutdown and throw the queued data on the floor. > > Furthermore, B is required to acknowledge the CONNECTION_CLOSE frame. Even > if it were to keep the send queue after CONNECTION_CLOSE, the ack would > probably go out first. So A can tear down its connection before B has any > assurance that A got all its data. > > There are several minor protocol edits to avoid all the problems in this > scenario. But I don't believe the spec as written is sufficient. > > Martin Duke From nobody Thu Feb 23 20:51:37 2017 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 4359F12953B for ; Thu, 23 Feb 2017 20:51:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzmHY9KZe1FB for ; Thu, 23 Feb 2017 20:51:34 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::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 A02A012952D for ; Thu, 23 Feb 2017 20:51:34 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id 65so5842038oig.1 for ; Thu, 23 Feb 2017 20:51:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g4yI1ZhzcRIP4A9PkdOjfUZu0TqKSuK0zQPQeH0PFKE=; b=tPAl80lyhCAJ6U4zyHtRSDg5DEn3SiYygO5jsJUdKsZibYXaIKPEV/efT7Fj6WJXaM MnKztB0Q4x6iR9SFtrQFq1RdT4raAWl+7yMW85CVog/ghqo/W904h8jlEqndR54PzepW 2MHIEsID1WhXgo3RBVb8N7iCCFmeYVaQR6APcLhZrvKIBZxych3rlVVRXszcD+A/oz3h 2UYb3jLhTe+8bBnFKrPwMoLgDagBokrTzbGkwILnuDGv75U9uG3k9hHKb/TW+lJuutZa x2m+FKg5cp818ThZCNcE8TqiS8rfSqX/uc/qkLseiycuHCzneasuUPgX/WETQtJm50R9 k3lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g4yI1ZhzcRIP4A9PkdOjfUZu0TqKSuK0zQPQeH0PFKE=; b=ody2+EnaoUmoGfHlVTr3IaU7RZYN9zyZsoeMgIfnXVlwsIpLYcS0nkowvayFma4MMN 5948jHsK/V1JdDNkjb8ip8bbreipF0PSio4Z9BXIfjqJtJZRljQ6EFGUQ0aX9ouKO79/ hw9xYe0CNgZ20nRcITBWC1gwJOeAwMvMvYFtzAKMQwBA/bdvciJvHZwyf9NJIBEDRK0o YbxYsUpcGudJs82UGSOlA4uz9QQAXIaCYbK/sUgXQag8xDBaHX76Qk9XhLblbssYgyfm AM6kETy0/fjAV2xrIe7AxlAv8bnMEc53QKU4FRvOVaJz6a1hvL1+DgDvmNEPsBWyjKgU vD/A== X-Gm-Message-State: AMke39m/9bvE8AIKWLb5Qs7RDdHXx2r3pZfuDs4uHb5/uRuMPolUjIfy4tBhHjeGuMBZgwT7JN2kd6hoXxQuVQ== X-Received: by 10.202.93.66 with SMTP id r63mr451925oib.208.1487911893995; Thu, 23 Feb 2017 20:51:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.1.226 with HTTP; Thu, 23 Feb 2017 20:51:33 -0800 (PST) In-Reply-To: References: From: Martin Duke Date: Thu, 23 Feb 2017 20:51:33 -0800 Message-ID: Subject: Re: Clean shutdown semantics To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113d4cb4e6174605493f7b95 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 04:51:36 -0000 --001a113d4cb4e6174605493f7b95 Content-Type: text/plain; charset=UTF-8 Thanks, I don't quite agree with everything said here, but I'll dive in to #330. On Thu, Feb 23, 2017 at 7:17 PM, Martin Thomson wrote: > It might not be helpful to think of QUIC as whole being in one of two > states: cleanly closed, or broken. Considering individual streams to > be either complete or cancelled helps a lot. > > To that end, I model GOAWAY as a selective RST_STREAM that cuts the > stream space into two and cancels all the streams on one side. > CONNECTION_CLOSE then is a universal RST_STREAM. That allows this to > be reduced to thinking in terms of the stream state machine. > > > On 24 February 2017 at 10:27, Martin Duke wrote: > > I am considering opening issue about clean shutdown semantics, but > wanted to > > bounce it off the list first in case there is something obvious I am > > missing. > > > > In TCP, after a clean shutdown both endpoints have a reasonable assurance > > that (1) All data they sent was acknowledged, and (2) the peer was able > to > > deliver all the data it wanted. This is a property of the connection FIN > > being a byte in a connection-wide, reliably delivered sequence space. > > > > I see two aspects of QUIC that result in this assurance not quite being > > achievable. This may be a result of editorial incompleteness, or > something > > baked into what Google implemented. > > > > (1) GOAWAY is bidirectional. There is no way to say "I am done opening > > streams, but you can open more streams if you need to." I don't see a > way to > > cleanly close the connection and know for sure that the peer didn't have > > more streams to open. > > > > (2) CONNECTION_CLOSE is ambiguous between abrupt and graceful shutdowns. > > There are some related logic issues too. > > > > (a) Say that I am endpoint A wrapping up a communication with endpoint B. > > We've already sent GOAWAY(s), and I send a packet that sends the last > data > > and FIN for all remaining streams. > > > > (b) I then receive a similar packet from B, delivering some data and > FINing > > all open streams, which I acknowledge. > > > > (c) I receive a packet only containing an ACK frame for packet (a). I now > > have assurance that all my data is delivered, and I have received > everything > > B has for me. There is no ack to send because there is only an ACK frame. > > > > (d) I therefore send CONNECTION_CLOSE. > > > > But if the ack in (b) is lost, then endpoint B receives CONNECTION_CLOSE > > while data is still outstanding. I believe the spec, as written, says to > > treat this as an abrupt shutdown and throw the queued data on the floor. > > > > Furthermore, B is required to acknowledge the CONNECTION_CLOSE frame. > Even > > if it were to keep the send queue after CONNECTION_CLOSE, the ack would > > probably go out first. So A can tear down its connection before B has any > > assurance that A got all its data. > > > > There are several minor protocol edits to avoid all the problems in this > > scenario. But I don't believe the spec as written is sufficient. > > > > Martin Duke > --001a113d4cb4e6174605493f7b95 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thanks, I don't quite agree with everything said here,= but I'll dive in to #330.

On Thu, Feb 23, 2017 at 7:17 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
It might not be helpful to think of QUIC as whole being in one of tw= o
states: cleanly closed, or broken.=C2=A0 Considering individual streams to<= br> be either complete or cancelled helps a lot.

To that end, I model GOAWAY as a selective RST_STREAM that cuts the
stream space into two and cancels all the streams on one side.
CONNECTION_CLOSE then is a universal RST_STREAM.=C2=A0 That allows this to<= br> be reduced to thinking in terms of the stream state machine.


On 24 February 2017 at 10:27, Martin Duke <martin.h.duke@gmail.com> wrote:
> I am considering opening issue about clean shutdown semantics, but wan= ted to
> bounce it off the list first in case there is something obvious I am > missing.
>
> In TCP, after a clean shutdown both endpoints have a reasonable assura= nce
> that (1) All data they sent was acknowledged, and (2) the peer was abl= e to
> deliver all the data it wanted. This is a property of the connection F= IN
> being a byte in a connection-wide, reliably delivered sequence space.<= br> >
> I see two aspects of QUIC that result in this assurance not quite bein= g
> achievable. This may be a result of editorial incompleteness, or somet= hing
> baked into what Google implemented.
>
> (1) GOAWAY is bidirectional. There is no way to say "I am done op= ening
> streams, but you can open more streams if you need to." I don'= ;t see a way to
> cleanly close the connection and know for sure that the peer didn'= t have
> more streams to open.
>
> (2) CONNECTION_CLOSE is ambiguous between abrupt and graceful shutdown= s.
> There are some related logic issues too.
>
> (a) Say that I am endpoint A wrapping up a communication with endpoint= B.
> We've already sent GOAWAY(s), and I send a packet that sends the l= ast data
> and FIN for all remaining streams.
>
> (b) I then receive a similar packet from B, delivering some data and F= INing
> all open streams, which I acknowledge.
>
> (c) I receive a packet only containing an ACK frame for packet (a). I = now
> have assurance that all my data is delivered, and I have received ever= ything
> B has for me. There is no ack to send because there is only an ACK fra= me.
>
> (d) I therefore send CONNECTION_CLOSE.
>
> But if the ack in (b) is lost, then endpoint B receives CONNECTION_CLO= SE
> while data is still outstanding. I believe the spec, as written, says = to
> treat this as an abrupt shutdown and throw the queued data on the floo= r.
>
> Furthermore, B is required to acknowledge the CONNECTION_CLOSE frame. = Even
> if it were to keep the send queue after CONNECTION_CLOSE, the ack woul= d
> probably go out first. So A can tear down its connection before B has = any
> assurance that A got all its data.
>
> There are several minor protocol edits to avoid all the problems in th= is
> scenario. But I don't believe the spec as written is sufficient. >
> Martin Duke

--001a113d4cb4e6174605493f7b95-- From nobody Thu Feb 23 22:55:39 2017 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 837421295C6 for ; Thu, 23 Feb 2017 22:55:38 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 aPDE72XCntGg for ; Thu, 23 Feb 2017 22:55:36 -0800 (PST) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::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 B2CF61295B8 for ; Thu, 23 Feb 2017 22:55:36 -0800 (PST) Received: by mail-vk0-x232.google.com with SMTP id r136so7400013vke.1 for ; Thu, 23 Feb 2017 22:55:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vxCDlCY6t4v0M39nKFMLzCOPxgndxsr0Y7n753XNuSY=; b=t8JqfaOy5zLexJnj3+yua7NNQkkEi+7cJp6yLLDXZiqTkxM5B4aVzrzJYhimODAb1s Bbu/jHaYhmKmCLXXzoj9XYvYaKgqbz9CkLjQSfqSk9Pa+DjxS34NQvaC+eEMwmTB6qKV MhRihSQowStK0g2o/hCAHNFWRTThkI5bjHi4pz4PQszbp07EJzUb3Dj8hMRS91ZD+/Je SEe+b57OqBLlLE5kNGoL/Mb2NK/LuJ9joaTUYYqc4IkmUEec8dGuXeQ9cQExrIR7ZyGH 7IX+NS6t5F9X+SyfyQNKwgihKQVx87OqhgSt8R3pjhILGEDERGq/SBGNnu8YFgfKna5x EwUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vxCDlCY6t4v0M39nKFMLzCOPxgndxsr0Y7n753XNuSY=; b=aBI5F/xKuAdzW0zogo5JGLdPh7lw876y1qWok/7E9Dlx3ygWPafuWQ27QgNRgtZ/o+ AgA1aEJnM9Fzc5nGc5C6IM3zBUvspIm8dXE0rYPoHi6rvN1K+P1o6o8kfhSeB/9XJ4ZZ WYssJI4tKLkghb0eTVfctu1ecKaYIzPfpYNeWvzQRkViILevz+cIzpn8Vwr7+Wa2uNde Osr4R4VuvYo1tEronWhnVCfCjPpTzbn8y67bC/iy536qK3zumfLSXxokXaYbg2D4C6oB hqQlkneS6dzLPG0fHUkYHjx1Ude7J1ODeg5jORxiIuD7Rc8RdJIhgBGwOfb5YmEmqDh8 1wnQ== X-Gm-Message-State: AMke39kcWLjsUvi9onxVghAxECEYB4jJ1d9HbA2DrtjWNjLeg5p9f0srgZHN/8TA9qvhBwfdRRa1yZr5f5VpFAXd X-Received: by 10.31.200.199 with SMTP id y190mr499353vkf.115.1487919335352; Thu, 23 Feb 2017 22:55:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Thu, 23 Feb 2017 22:55:34 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Thu, 23 Feb 2017 22:55:34 -0800 Message-ID: Subject: Re: Alternate header proposal To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114d9d4870843f05494137f3 Archived-At: Cc: Eric Rescorla , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 06:55:38 -0000 --001a114d9d4870843f05494137f3 Content-Type: text/plain; charset=UTF-8 On Thu, Feb 23, 2017 at 7:10 PM, Martin Thomson wrote: > On 23 February 2017 at 03:58, Eric Rescorla wrote: > > > > Also, maybe I'm missing something, but where's the key change bit? That > > seems to have > > gone missing and AFAICT you are still going to need it unless you have > some > > thought > > of swapping to long headers during the key change period until you see > acks > > or something > > else equally gross. > > Wasn't there another set of types for that? They must have gone > missing, which I'm sure is an accident. > > I'm of the opinion that we probably just want to use a bit for this > and the long/short marker as well. Even more so for the latter. > Yeah, it's there... I just didn't write it out in the figure to keep the Type byte the same for both. I'll write it out separately in my PR. I'm leaning towards long/short marker as well. I'll add that in the PR too. --001a114d9d4870843f05494137f3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Feb 23, 2017 at 7:10 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
On 23 February 2017 at 03:58, Eric Rescorla <ekr@rtfm.com> wrote:
>
> Also, maybe I'm missing something, but where's the key change = bit? That
> seems to have
> gone missing and AFAICT you are still going to need it unless you have= some
> thought
> of swapping to long headers during the key change period until you see= acks
> or something
> else equally gross.

Wasn't there another set of types for that?=C2=A0 They must have= gone
missing, which I'm sure is an accident.

I'm of the opinion that we probably just want to use a bit for this
and the long/short marker as well.=C2=A0 Even more so for the latter.
=C2=A0
Yeah, it's there... I just didn&#= 39;t write it out in the figure to keep the Type byte the same for both.
I'll write it out separately in my PR. I&= #39;m leaning towards long/short marker as well. I'll add that in the P= R too.
--001a114d9d4870843f05494137f3-- From nobody Fri Feb 24 00:14:55 2017 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 890BE129489 for ; Fri, 24 Feb 2017 00:14:53 -0800 (PST) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1vKXvMUkeOj for ; Fri, 24 Feb 2017 00:14:49 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (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 3BB071293F9 for ; Fri, 24 Feb 2017 00:14:46 -0800 (PST) X-AuditID: c1b4fb25-93e1698000001738-19-58afeb74def8 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.124]) by (Symantec Mail Security) with SMTP id E0.50.05944.47BEFA85; Fri, 24 Feb 2017 09:14:44 +0100 (CET) Received: from EUR02-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 24 Feb 2017 09:14:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jIfmdpck8AwlD+BrHr9GZ7R3fKnuQevfZXeXw91Zyso=; b=llaWFAYllMefUjjMNySQ/rECyEG3s0rpf7X4JEgcG1EuR+CxEUKNnbO/wBa8eRc+HLSrtN31fo+8cHIemlnFMc5o3hlzv75u7N598Olp3bKlJAXtsb04J1tLX9aQ/m0FKHlGweoGcL6DaJ6UvTegjAJHtz44/kZzPJJf7IaapVE= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.919.10; Fri, 24 Feb 2017 08:14:32 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) by DB4PR07MB348.eurprd07.prod.outlook.com ([10.141.234.148]) with mapi id 15.01.0919.018; Fri, 24 Feb 2017 08:14:32 +0000 From: Ingemar Johansson S To: Christian Huitema , "quic@ietf.org" Subject: RE: FW: New Version Notification for draft-johansson-quic-ecn-01.txt Thread-Topic: FW: New Version Notification for draft-johansson-quic-ecn-01.txt Thread-Index: AQHSjOEdDzxr00Ts+EONPowXtDkG56F3zvxw Date: Fri, 24 Feb 2017 08:14:32 +0000 Message-ID: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> <6a7c4ca2-1955-d290-a400-9f9eefe49671@it.uc3m.es> <2a86ab62-9d7f-87a7-1d81-8faa2fa06787@huitema.net> In-Reply-To: <2a86ab62-9d7f-87a7-1d81-8faa2fa06787@huitema.net> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.85] x-ms-office365-filtering-correlation-id: 1dc04463-0954-42ec-ff13-08d45c8d29b4 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DB4PR07MB346; x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 7:su2ZAqvqS/CcjPyMOzBlJuvlM2cj/p3thZh3Oux+9pLBLLaCXbqGOOcCDnsM8RmmcjfL2gFFU+3fNEsCusQjJJQ/6cx+wwy7Wh/b1m5WgtjlpaiVln71HrImyCWO/bsplDZQ6+mj+iwVrDFevywdbMxMo8fRY1OmHsHxAVFWatT1EMQ7VgWlgyVW1XQ++Mzi74lfwLCa6NGxMTEUHJATjKL9lD1E4GiaAW21icBqFG9/5PC5XeeD8K/xrtYSThAfkpoPlfDfBhxz72WxBxBQfroM8XhU9pBepeE2sOyCN+HqMDduV3p2tL+tbsyu8aAJZSaaFxkmXmYs8zy4agavJw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123558025)(20161123560025)(6072148); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:; SRVR:DB4PR07MB346; x-forefront-prvs: 0228DDDDD7 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(24454002)(377454003)(199003)(189002)(13464003)(106356001)(7696004)(6306002)(106116001)(2501003)(68736007)(101416001)(305945005)(122556002)(15650500001)(8936002)(92566002)(2420400007)(33656002)(5660300001)(81156014)(81166006)(50986999)(86362001)(105586002)(54356999)(76176999)(74316002)(9686003)(53936002)(8676002)(93886004)(55016002)(7110500001)(53546006)(77096006)(3280700002)(38730400002)(66066001)(2906002)(189998001)(99286003)(10710500007)(25786008)(966004)(97736004)(2900100001)(2950100002)(6436002)(3660700001)(7736002)(229853002)(6116002)(102836003)(230783001)(6246003)(3846002)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.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-MS-Exchange-CrossTenant-originalarrivaltime: 24 Feb 2017 08:14:32.3372 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpkleLIzCtJLcpLzFFi42KZGfG3Rrfk9foIg9VdIhaTG2ezW/Qs4HZg 8rg14xSLx5IlP5kCmKK4bFJSczLLUov07RK4Mjbd2cZasEG44tlHqwbGD0JdjJwcEgImEi8b T7GD2EIC6xklelZ5dDFyAdknGCVWz33ACuKwCPQySxx6v5UVIjONSWLByqNMEM4xRokLqz8z gvSzCdhIrDz0HcwWEfCROLxiIguILSzgK7HzWCs7RNxP4smFlSwQtpHEiimPwWwWAVWJmXtX s4HYvAJREhc2TIO66QWLxN1bfiA2p4C9xIf5v5lAbEYBWYn73++B9TILiEvcejKfCeIfAYkl e84zQ9iiEi8f/2OFqE+W+HSzF8jmAIorSDzc6gdR4iuxcsImdgjbR+L39TXsIH9JCHQzS3w6 cAYqkSlx9fF1qJlWEj+WLIAqmsEk0bfwBlRCRuL6wyNsEPYqNom/q2MgHkiVWL62lRESEFIS d690QtkyEi/u7GWdwKg5C8kPs4DuYxbQlFi/Sx8irCgxpfsh+yxwsAhKnJz5hGUBI8sqRtHi 1OKk3HQjY73Uoszk4uL8PL281JJNjMCEcXDLb9UdjJffOB5iFOBgVOLh/fBjXYQQa2JZcWXu IUYJDmYlEd7uZ+sjhHhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl 4uCUamAssHf+WNoqWH7uENser8+N5kYpml3cR9pmc8z8mzXrWjuXhXm0o9zyjWz5lbwf9RRf Oe6Ty1NXZd1ZbKomZF9/hz1HIWYpw6Zr6c6ND3TrHHqYFs86WlmrPW3bWz5mBgn5l1FLFHUZ elh5L8etc3325dA9L7s7qk3VeSbcyUpidy/+MmDeoMRSnJFoqMVcVJwIAAPf9vcUAwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 08:14:53 -0000 SGkNCkZhaXIgZW5vdWdoLCBJIHdpbGwgaW1wcm92ZSB0aGUgZHJhZnQgaW4gdGhlIG5leHQgcmVs ZWFzZS4NCg0KUmVnYXJkcw0KL0luZ2VtYXINCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KPiBGcm9tOiBDaHJpc3RpYW4gSHVpdGVtYSBbbWFpbHRvOmh1aXRlbWFAaHVpdGVtYS5uZXRd DQo+IFNlbnQ6IGRlbiAyNCBmZWJydWFyaSAyMDE3IDAxOjM5DQo+IFRvOiBxdWljQGlldGYub3Jn DQo+IFN1YmplY3Q6IFJlOiBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1q b2hhbnNzb24tcXVpYy1lY24tDQo+IDAxLnR4dA0KPiANCj4gDQo+IA0KPiBPbiAyLzIzLzIwMTcg MTowOSBBTSwgTWFydGluIEouIETDvHJzdCB3cm90ZToNCj4gPg0KPiA+IEl0IHdvdWxkIGJlIG5l dmVydGhlbGVzcyBleHRyZW1lbHkgaGVscGZ1bCBpZiB0aGF0IGFjcm9ueW0gd291bGQgYmUNCj4g PiBleHBhbmRlZCBvbmNlLCBlLmcuIGVhcmx5IGluIHRoZSBpbnRyb2R1Y3Rpb24uIFVzaW5nICJF eHBsaWNpdA0KPiA+IENvbmdlc3Rpb24gTm90aWZpY2F0aW9uIiBpbiB0aGUgdGl0bGUgd291bGQg YmUgZXZlbiBiZXR0ZXIsIHRoZXJlIGFyZQ0KPiA+IGFscmVhZHkgbWFueSBnb29kIGV4YW1wbGVz IGZvciB0aGlzOg0KPiA+DQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzY2NzkN Cj4gPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNzU2MA0KPiA+IGh0dHBzOi8vdG9v bHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1iYWdudWxvLXRjcG0tZ2VuZXJhbGl6ZWQtZWNuLTAwDQo+ ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtYXFtLWVjbi1iZW5lZml0 cy0wOA0KPiA+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRzdndnLWVj bi1leHBlcmltZW50YXRpb24tMDANCj4gPiBhbmQgdG8gc29tZSBleHRlbnQgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzY3ODkNCj4gPg0KPiA+ICJFeHBsaWNpdCBDb25nZXN0aW9uIE5v dGlmaWNhdGlvbiIgaXMgcHJldHR5IG11Y2ggc2VsZi1leHBsYWluaW5nLCBidXQNCj4gPiAiRU5D IiBpc24ndCBldmVuIG9uIGEgbGlzdCBsaWtlDQo+ID4gaHR0cDovL2Fjcm9ueW1zLnRoZWZyZWVk aWN0aW9uYXJ5LmNvbS9FTkMuDQo+IA0KPiBZZXMsIHBsZWFzZS4gSSB1bmRlcnN0YW5kIHdoZXJl IE1pcmphIGNvbWVzIGZyb20sIGFuZCBJIGFsc28gdW5kZXJzdGFuZA0KPiB3aGF0IEVDTiBtZWFu cyBpbiB0aGlzIGNvbnRleHQsIGJ1dCBQaGlsaXAgaGFzIGEgZ29vZCBwb2ludC4gUVVJQyBzdHJh ZGRsZXMNCj4gc2V2ZXJhbCBsYXllcnMgb2Ygb3VyIHN0YWNrLCBmcm9tIHRyYW5zcG9ydCB0byBh cHBsaWNhdGlvbiB0aHJvdWdoIHNlY3VyaXR5Lg0KPiBUaHJlZSBsZXR0ZXJzIGFjcm9ueW1zIGFy ZSB3YXkgbW9yZSBhbWJpZ3VvdXMgdGhhbiB5b3UgbWF5IHRoaW5rLCBldmVuDQo+IGluc2lkZSB0 aGUgSUVURi4gRm9yIGV4YW1wbGUsIEkgZ3Vlc3MgeW91IGFsbCBrbm93IHRoYXQgRkVDIG1lYW5z IEZvcndhcmQNCj4gRXJyb3IgQ29ycmVjdGlvbiwgcmlnaHQ/IEJ1dCBpZiB5b3UgaGF2ZSB0byB1 c2UgTVBMUywgRkVDIG1lYW5zIEZvcndhcmRpbmcNCj4gRXF1aXZhbGVuY2UgQ2xhc3MuIFNvLCBw bGVhc2UsIGp1c3QgYmUgY29uc2VydmF0aXZlLiBVc2UgdGhlIGZ1bGwgc3BlbGxpbmcgb2YNCj4g dGhlIGFjcm9ueW1zIGluIHRoZSB0aXRsZSwgYWJzdHJhY3QgYW5kIGludHJvZHVjdGlvbiBvZiBk b2N1bWVudHMhDQo+IA0KPiAtLSBDaHJpc3RpYW4gSHVpdGVtYQ0KPiANCg0K From nobody Fri Feb 24 05:20:28 2017 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 5D4D412945D for ; Fri, 24 Feb 2017 05:20:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 YojoRxd0loJ9 for ; Fri, 24 Feb 2017 05:20:24 -0800 (PST) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E595312973D for ; Fri, 24 Feb 2017 05:20:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3vVBYL58spz15N9y; Fri, 24 Feb 2017 14:20:22 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ghG0j663-Tk; Fri, 24 Feb 2017 14:20:21 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC2653.dip0.t-ipconnect.de [93.236.38.83]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 24 Feb 2017 14:20:21 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: New Version Notification for draft-johansson-quic-ecn-01.txt From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 24 Feb 2017 14:20:21 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> <0404cec1-bbee-0e59-d648-5920428ddd33@tik.ee.ethz.ch> To: Phillip Hallam-Baker X-Mailer: Apple Mail (2.3259) Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 13:20:25 -0000 I don=E2=80=99t think that submitting a public draft and starting a = discussion on a public mailing list can be seen as "written for = consideration by a closed circle=E2=80=9C. > Am 23.02.2017 um 16:07 schrieb Phillip Hallam-Baker = : >=20 > On Thu, Feb 23, 2017 at 4:35 AM, Mirja K=C3=BChlewind = wrote: > This is a completely useless discussion but at this point I really = strongly disagree. This is a DRAFT; it not ready for publication and in = this case it also will never be published as RFC (as you assume = wrongly). >=20 > =E2=80=8BDrafts are for discussion. If the draft is written to limit = discussion to a small clique then something is wrong.=E2=80=8B >=20 > =20 > This document is discussing different options how to integrate ECN in = draft-ietf-quic-transport. If you don't know what ECN is, >=20 > =E2=80=8BOh I know what Explicit Congestion Notification is. But ECN = on its own means nothing to me because I work in so many areas.=E2=80=8B > =E2=80=8B > To me, ECN means Electronic Communications Network and is a place = where stocks and options are being traded. It also means Emergency = Communications Network which is another issue we deal with in IETF.=20 > =E2=80=8B >=20 > this draft is probably not directed at you. >=20 > =E2=80=8BThat was my bigger problem with this particular group. This = was not the first draft that was rather obviously only written for = consideration by a closed circle. If you want to discuss things in = closed circles then the IETF probably isn't for you. >=20 > Having waded through the first set of drafts and found them worse than = useless, my tolerance level was not high when I began reading yet = another draft that rather obviously assumed that this is all a private = discussion and nobody who isn't a member of the club is welcome. >=20 > However, the latest protocol draft does look like something I can = implement from. From nobody Fri Feb 24 05:40:09 2017 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 59CE3129759 for ; Fri, 24 Feb 2017 05:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 3EDcYkLbjgj4 for ; Fri, 24 Feb 2017 05:40:05 -0800 (PST) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A678129736 for ; Fri, 24 Feb 2017 05:40:05 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3vVC035qZHz15N1K; Fri, 24 Feb 2017 14:40:03 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KeVmq2uKmAvg; Fri, 24 Feb 2017 14:40:02 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC2653.dip0.t-ipconnect.de [93.236.38.83]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Fri, 24 Feb 2017 14:40:01 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: Quick Elephants From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Fri, 24 Feb 2017 14:40:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> References: To: Yoshifumi Nishida X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Jana Iyengar , IETF QUIC WG , Watson Ladd X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 13:40:07 -0000 Yes, the problem is that you don=E2=80=99t see anymore with quic that a = packet was lost, so you can=E2=80=99t retransmit locally (I think this = is totally independent of the congestion control though=E2=80=A6) Mirja > Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishida = : >=20 > I also think we don't need to make special recommendations. But, if = the dirty hacks include transparent PEPs, I guess it will be difficult = to do with QUIC. > -- > Yoshi >=20 > On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar wrote: > Hi Watson, >=20 > The current plan is to write up NewReno as the congestion controller = for QUIC. I don't think we need to make special recommendations for = networks with large BDPs in terms of congestion control, since QUIC can = use the same congestion controller as TCP for these networks. = Specifically, if you have dirty hacks that you use to make TCP (with = NewReno or Cubic) work, you ought to be able to do the same trickery = with QUIC. >=20 > (I can't think of new multiplexing recommendations for these = networks.) >=20 > - jana >=20 > On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd = wrote: > Dear all, >=20 > I'm not that familiar with the state of play here, but in the future > we will have more and more LFN network connections (long fat pipe: > high bandwidth-delay product with long delays), as well as wireless > networks where packet losses are not necessarily due to contention on > the shared channel. >=20 > My understanding is currently we have a bunch of dirty hacks (like > locally resending data over the lossy bit) to make this work, a lot of > which will stop working with QUIC. What can we recommend for > congestion control algorithms and multiplexing use to alleviate the > problems? >=20 > Sincerely, > Watson >=20 >=20 >=20 From nobody Fri Feb 24 07:12:09 2017 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 3787A129DF8 for ; Fri, 24 Feb 2017 07:12:08 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 e6M7S3Svtf2M for ; Fri, 24 Feb 2017 07:12:05 -0800 (PST) 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 3B93E129DF5 for ; Fri, 24 Feb 2017 07:12:04 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id l19so10970503ywc.2 for ; Fri, 24 Feb 2017 07:12:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xk0gqai03IzdASiSI/vbz3eP7c4ZneJTnTTGatBC/6o=; b=IB1273R5j9FhvZvGcZWXx7ph/VXKYDyEGb13Kjt0SKW/kI/uadRtn7nH6z52oMEt1U Or1tN4QEByKtfsWBPsE5eY8WqOTH8GLaEknj/wduN4zpZOmi2WvbiJuVsp/LbVRqQ7oX 2qPBQjS4kv65dfAHQX0tQs+n90Oj6xZKzlvBkgIoA3Exm2nqeoCIuVI+EBHILJN5JzDN ZvGDelNkIXhv5R6Jy0PeittnrOgevdjKWZHX7CSMZR/xdc2UQAQY3etWSWQKugou1rZx +DYT5IrFDOl4ymjmO73CUk6wrQJ6hiaZl7UxlGq5v0TfrvPjX9uSFp6vY7PKyaIPPOLZ 7msQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xk0gqai03IzdASiSI/vbz3eP7c4ZneJTnTTGatBC/6o=; b=g4HYPAS8ilJ5xQ/kvGSXK5HHphaLJO2bJ6dR5/AVK87/AjTZTjoghaZqMJS95tGn/1 SC3rCN8Xt8io/dGNXS6tKLesGCm3R/bgrq3ad9zvCEJa40qyvVsAuvlLOkWrrkVD4ymD CNH+DVGaO3mSOEXDiguQ3xttDMImWqGm+a+qhXjsibVz5qzItxCW9Qd0yctryhEIhqMU oDUKsOtyblhdwN5NnEIQYUP6UAqu0FjvzOB2zHDCAP8d+JyRGUgn7AywC2VY/LXSvZoX mFDK4Ve/ns/UmqOW/vdndNMXLO13Ae1YtHX0LT4BhkALf6VcEemCicS5n2jfoqXWcxXY 6Mog== X-Gm-Message-State: AMke39kElfIyh4s1f7k51TEK9/h9vrU7MTNreFy98lV8WrAA4hkF7xzkF689dEU7mQ/FsHYauAxAomkz4mtKDFc3 X-Received: by 10.129.182.101 with SMTP id h37mr1841952ywk.177.1487949123388; Fri, 24 Feb 2017 07:12:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.57.201 with HTTP; Fri, 24 Feb 2017 07:11:42 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Fri, 24 Feb 2017 10:11:42 -0500 Message-ID: Subject: Re: Clean shutdown semantics To: Martin Duke Content-Type: multipart/alternative; boundary=f403045d20caf1c0910549482632 Archived-At: Cc: IETF QUIC WG , Martin Thomson X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 15:12:08 -0000 --f403045d20caf1c0910549482632 Content-Type: text/plain; charset=UTF-8 When Ryan and I were discussing GOAWAY today, he noted it didn't indicate what the largest stream the sender would create is. It says "GOAWAY will not initiate any additional streams and will not accept any new incoming streams.", but there's no way to indicate the largest stream it has/will create. It says "active streams will continue to be processed", but that doesn't actually indicate whether they'll be properly finished in some way, ie: will all outstanding data be delivered by the sender of the GOAWAY and the stream be properly fin'd or reset? I filed this as a new issue for GOAWAY(#347 ), since I think it'd be nice to clarify both connection close and goaway at the same time. On Thu, Feb 23, 2017 at 11:51 PM, Martin Duke wrote: > Thanks, I don't quite agree with everything said here, but I'll dive in to > #330. > > On Thu, Feb 23, 2017 at 7:17 PM, Martin Thomson > wrote: > >> It might not be helpful to think of QUIC as whole being in one of two >> states: cleanly closed, or broken. Considering individual streams to >> be either complete or cancelled helps a lot. >> >> To that end, I model GOAWAY as a selective RST_STREAM that cuts the >> stream space into two and cancels all the streams on one side. >> CONNECTION_CLOSE then is a universal RST_STREAM. That allows this to >> be reduced to thinking in terms of the stream state machine. >> >> >> On 24 February 2017 at 10:27, Martin Duke >> wrote: >> > I am considering opening issue about clean shutdown semantics, but >> wanted to >> > bounce it off the list first in case there is something obvious I am >> > missing. >> > >> > In TCP, after a clean shutdown both endpoints have a reasonable >> assurance >> > that (1) All data they sent was acknowledged, and (2) the peer was able >> to >> > deliver all the data it wanted. This is a property of the connection FIN >> > being a byte in a connection-wide, reliably delivered sequence space. >> > >> > I see two aspects of QUIC that result in this assurance not quite being >> > achievable. This may be a result of editorial incompleteness, or >> something >> > baked into what Google implemented. >> > >> > (1) GOAWAY is bidirectional. There is no way to say "I am done opening >> > streams, but you can open more streams if you need to." I don't see a >> way to >> > cleanly close the connection and know for sure that the peer didn't have >> > more streams to open. >> > >> > (2) CONNECTION_CLOSE is ambiguous between abrupt and graceful shutdowns. >> > There are some related logic issues too. >> > >> > (a) Say that I am endpoint A wrapping up a communication with endpoint >> B. >> > We've already sent GOAWAY(s), and I send a packet that sends the last >> data >> > and FIN for all remaining streams. >> > >> > (b) I then receive a similar packet from B, delivering some data and >> FINing >> > all open streams, which I acknowledge. >> > >> > (c) I receive a packet only containing an ACK frame for packet (a). I >> now >> > have assurance that all my data is delivered, and I have received >> everything >> > B has for me. There is no ack to send because there is only an ACK >> frame. >> > >> > (d) I therefore send CONNECTION_CLOSE. >> > >> > But if the ack in (b) is lost, then endpoint B receives CONNECTION_CLOSE >> > while data is still outstanding. I believe the spec, as written, says to >> > treat this as an abrupt shutdown and throw the queued data on the floor. >> > >> > Furthermore, B is required to acknowledge the CONNECTION_CLOSE frame. >> Even >> > if it were to keep the send queue after CONNECTION_CLOSE, the ack would >> > probably go out first. So A can tear down its connection before B has >> any >> > assurance that A got all its data. >> > >> > There are several minor protocol edits to avoid all the problems in this >> > scenario. But I don't believe the spec as written is sufficient. >> > >> > Martin Duke >> > > --f403045d20caf1c0910549482632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When Ryan and I were discussing GOAWAY today, he noted it = didn't indicate what the largest stream the sender would create is.=C2= =A0 It says "GOAWAY will not initiate any additional streams and will = not accept any new incoming streams.", but there's no way to indic= ate the largest stream it has/will create.

It says "= ;active streams will continue to be processed", but that doesn't a= ctually indicate whether they'll be properly finished in some way, ie: = will all outstanding data be delivered by the sender of the GOAWAY and the = stream be properly fin'd or reset?

I filed thi= s as a new issue for GOAWAY(#347), since I think it'd be nice to clarify both con= nection close and goaway at the same time.

On Thu, Feb 23, 2017 at 11:51 PM, Mart= in Duke <martin.h.duke@gmail.com> wrote:
Thanks, I don't quite agree with = everything said here, but I'll dive in to #330.

On Thu, Feb 23, 2017 at 7:17 PM, Martin Thomson <= martin.thomso= n@gmail.com> wrote:
It migh= t not be helpful to think of QUIC as whole being in one of two
states: cleanly closed, or broken.=C2=A0 Considering individual streams to<= br> be either complete or cancelled helps a lot.

To that end, I model GOAWAY as a selective RST_STREAM that cuts the
stream space into two and cancels all the streams on one side.
CONNECTION_CLOSE then is a universal RST_STREAM.=C2=A0 That allows this to<= br> be reduced to thinking in terms of the stream state machine.


On 24 February 2017 at 10:27, Martin Duke <martin.h.duke@gmail.com> wrote:
> I am considering opening issue about clean shutdown semantics, but wan= ted to
> bounce it off the list first in case there is something obvious I am > missing.
>
> In TCP, after a clean shutdown both endpoints have a reasonable assura= nce
> that (1) All data they sent was acknowledged, and (2) the peer was abl= e to
> deliver all the data it wanted. This is a property of the connection F= IN
> being a byte in a connection-wide, reliably delivered sequence space.<= br> >
> I see two aspects of QUIC that result in this assurance not quite bein= g
> achievable. This may be a result of editorial incompleteness, or somet= hing
> baked into what Google implemented.
>
> (1) GOAWAY is bidirectional. There is no way to say "I am done op= ening
> streams, but you can open more streams if you need to." I don'= ;t see a way to
> cleanly close the connection and know for sure that the peer didn'= t have
> more streams to open.
>
> (2) CONNECTION_CLOSE is ambiguous between abrupt and graceful shutdown= s.
> There are some related logic issues too.
>
> (a) Say that I am endpoint A wrapping up a communication with endpoint= B.
> We've already sent GOAWAY(s), and I send a packet that sends the l= ast data
> and FIN for all remaining streams.
>
> (b) I then receive a similar packet from B, delivering some data and F= INing
> all open streams, which I acknowledge.
>
> (c) I receive a packet only containing an ACK frame for packet (a). I = now
> have assurance that all my data is delivered, and I have received ever= ything
> B has for me. There is no ack to send because there is only an ACK fra= me.
>
> (d) I therefore send CONNECTION_CLOSE.
>
> But if the ack in (b) is lost, then endpoint B receives CONNECTION_CLO= SE
> while data is still outstanding. I believe the spec, as written, says = to
> treat this as an abrupt shutdown and throw the queued data on the floo= r.
>
> Furthermore, B is required to acknowledge the CONNECTION_CLOSE frame. = Even
> if it were to keep the send queue after CONNECTION_CLOSE, the ack woul= d
> probably go out first. So A can tear down its connection before B has = any
> assurance that A got all its data.
>
> There are several minor protocol edits to avoid all the problems in th= is
> scenario. But I don't believe the spec as written is sufficient. >
> Martin Duke


--f403045d20caf1c0910549482632-- From nobody Fri Feb 24 07:14:15 2017 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 7D6C51296B0 for ; Fri, 24 Feb 2017 07:14:13 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pvIFyGRAfJ-7 for ; Fri, 24 Feb 2017 07:14:11 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::5]) (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 6C989129868 for ; Fri, 24 Feb 2017 07:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1487949249; l=2312; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=d2jmj+YLj1VxtOtOcon4PorR9PU5iFpZA7pqyEXjcZw=; b=k/Ldz7iq5TZUjQgC21qBa8P4I5Xl/HIGdxbk6vYWhqAMhS9vMFnfR+T0+SOFlqLCvD ZBuFrp0037VU3R64HJNOmr5u175MFuMl6FLjKacVFdj6trDobmrePvZXUxxti07a+qiU 79HatMFWE7RySuISn1ewqhGYVQx/eFAlaRnVA= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzS7fJ+yDu/8JxqiNqn6jjGVYPa X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:c850:2882:1b1:58d2] ([2001:4dd0:ff67:0:c850:2882:1b1:58d2]) by smtp.strato.de (RZmta 39.13 AUTH) with ESMTPSA id D02dd0t1OFE8dpq (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 24 Feb 2017 16:14:08 +0100 (CET) Subject: Re: Quick Elephants To: quic@ietf.org References: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> From: Roland Zink Message-ID: <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> Date: Fri, 24 Feb 2017 16:14:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 15:14:13 -0000 Don't think this is completely independent of the congestion control. Resending lost packets also make the ack coming earlier. The congestion algorithm will behave different, for example packet losses may be hidden. As this doesn't work with QUIC the NewReno or Cubic congestion control algorithms may show bad performance and will be unable to fill the pipe depending on the link error rate. Roland Am 24.02.2017 um 14:40 schrieb Mirja Kühlewind: > Yes, the problem is that you don’t see anymore with quic that a packet was lost, so you can’t retransmit locally (I think this is totally independent of the congestion control though…) > > Mirja > > >> Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishida : >> >> I also think we don't need to make special recommendations. But, if the dirty hacks include transparent PEPs, I guess it will be difficult to do with QUIC. >> -- >> Yoshi >> >> On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar wrote: >> Hi Watson, >> >> The current plan is to write up NewReno as the congestion controller for QUIC. I don't think we need to make special recommendations for networks with large BDPs in terms of congestion control, since QUIC can use the same congestion controller as TCP for these networks. Specifically, if you have dirty hacks that you use to make TCP (with NewReno or Cubic) work, you ought to be able to do the same trickery with QUIC. >> >> (I can't think of new multiplexing recommendations for these networks.) >> >> - jana >> >> On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd wrote: >> Dear all, >> >> I'm not that familiar with the state of play here, but in the future >> we will have more and more LFN network connections (long fat pipe: >> high bandwidth-delay product with long delays), as well as wireless >> networks where packet losses are not necessarily due to contention on >> the shared channel. >> >> My understanding is currently we have a bunch of dirty hacks (like >> locally resending data over the lossy bit) to make this work, a lot of >> which will stop working with QUIC. What can we recommend for >> congestion control algorithms and multiplexing use to alleviate the >> problems? >> >> Sincerely, >> Watson >> >> >> From nobody Fri Feb 24 07:45:21 2017 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 5F4F112986B for ; Fri, 24 Feb 2017 07:45:19 -0800 (PST) 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 si-S4jnK4SYi for ; Fri, 24 Feb 2017 07:45:18 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6073129893 for ; Fri, 24 Feb 2017 07:45:17 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id 196so9322170wmm.1 for ; Fri, 24 Feb 2017 07:45:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xVAOBX9bQazvNCJc2VakdNVniaCszJdv+WggR6HLXkw=; b=jsSFZcXA/2Cay148v1I+iUxd5p/RegZNjv3nzepOKCqPYZdxVohHsq8b93hTfJAR7k aNLQI58vcgjfioFGUQiyhQ+zg97H5UPY2RZ6cxnqcshXvn3XUUD8gi0ILGm98Gx21Jp1 2gBbal0yJ5blnlH+Jhm6oZGn0Sx1y/Xf6CLfzmDsshNWcpANkJeYOzNAV+C6HvZewo6q YvuWlpaRYAz6h20E3WGlyil5651u9ZF0cTMVWiRRL7c3dlJ2lXbq9idnlCYqZbVv5S2F N/QmZb3PyoWH8jvL72Zi3IGhZxpiSdyv+RDpsFb2StsHnt9P+lHV13LCgVp0IqF5aMa5 4l0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xVAOBX9bQazvNCJc2VakdNVniaCszJdv+WggR6HLXkw=; b=IthA99QuD5I3f+65LPTH4p84JE6y4mmM80dDC1qkLRkDnr8OSFni/NzHt0ctUtox9a xFcQB4UG4lTy/PnsL9jRCykfYkWiCZRRUMH/lNV4UT/PZDTDCg5x6AbLL+j1Tlw+X7L/ 96RaYKkTdOkIsvb+7/MTPnmTWNUdkHMO5+vZLSld+SJAEsaLne1WgWZhFtIUutF8Ur/q Ewl4U/tVaGuuGA1ZDPCHENrKY6hYBbyQha/naBbeaPjtwM9HFPgKZDz9f7UenIhpUuX2 O8x9f2ZpH28ZhaJYDRcSIRvC77XA2hwIoiVTsdQ+tIsF/hIhAUTtUicX591kYY26O51d zkrA== X-Gm-Message-State: AMke39ljFu7AaZcIoMozNW9lxXFEzrvFzJhBvFgAWfehcLBgVw/wW4Za5w4SGgxW+Ymxe3QYcUcofa7oRmkKxg== X-Received: by 10.28.47.15 with SMTP id v15mr3281267wmv.67.1487951116239; Fri, 24 Feb 2017 07:45:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.164.18 with HTTP; Fri, 24 Feb 2017 07:45:15 -0800 (PST) In-Reply-To: <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> References: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> From: Watson Ladd Date: Fri, 24 Feb 2017 07:45:15 -0800 Message-ID: Subject: Re: Quick Elephants To: Roland Zink Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 15:45:19 -0000 On Fri, Feb 24, 2017 at 7:14 AM, Roland Zink wrote: > Don't think this is completely independent of the congestion control. > Resending lost packets also make the ack coming earlier. The congestion > algorithm will behave different, for example packet losses may be hidden.= As > this doesn't work with QUIC the NewReno or Cubic congestion control > algorithms may show bad performance and will be unable to fill the pipe > depending on the link error rate. There are new link error insensitive algorithms which learn the error rate and congestion separately. We might want to recommend using one of those. > > Roland > > > > Am 24.02.2017 um 14:40 schrieb Mirja K=C3=BChlewind: >> >> Yes, the problem is that you don=E2=80=99t see anymore with quic that a = packet was >> lost, so you can=E2=80=99t retransmit locally (I think this is totally i= ndependent >> of the congestion control though=E2=80=A6) >> >> Mirja >> >> >>> Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishida >>> : >>> >>> I also think we don't need to make special recommendations. But, if the >>> dirty hacks include transparent PEPs, I guess it will be difficult to d= o >>> with QUIC. >>> -- >>> Yoshi >>> >>> On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar wrote: >>> Hi Watson, >>> >>> The current plan is to write up NewReno as the congestion controller fo= r >>> QUIC. I don't think we need to make special recommendations for network= s >>> with large BDPs in terms of congestion control, since QUIC can use the = same >>> congestion controller as TCP for these networks. Specifically, if you h= ave >>> dirty hacks that you use to make TCP (with NewReno or Cubic) work, you = ought >>> to be able to do the same trickery with QUIC. >>> >>> (I can't think of new multiplexing recommendations for these networks.) >>> >>> - jana >>> >>> On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd >>> wrote: >>> Dear all, >>> >>> I'm not that familiar with the state of play here, but in the future >>> we will have more and more LFN network connections (long fat pipe: >>> high bandwidth-delay product with long delays), as well as wireless >>> networks where packet losses are not necessarily due to contention on >>> the shared channel. >>> >>> My understanding is currently we have a bunch of dirty hacks (like >>> locally resending data over the lossy bit) to make this work, a lot of >>> which will stop working with QUIC. What can we recommend for >>> congestion control algorithms and multiplexing use to alleviate the >>> problems? >>> >>> Sincerely, >>> Watson >>> >>> >>> > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Feb 24 08:04:47 2017 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 A50F91299A2 for ; Fri, 24 Feb 2017 08:04:46 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=zinks.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HhiKmc3K_U6r for ; Fri, 24 Feb 2017 08:04:45 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBC4112994F for ; Fri, 24 Feb 2017 08:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1487952282; l=2970; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=tljlaq6zwYbk+a8/C+UKpOqzePpMyaz3Ok0BFBWpgeA=; b=rKHuCTBmmTA3V4t0gKRB57thpKphjREP+h0viMw6v+kx7m2rYahe8EgcV2DBiB7ymg EejLpT/Rtnz9oZR9jYGH0gJ1XfUVKUXGD/3bZNuuYcKselghqO3tYWgoLg9m0zbF4Urd A1a/ZmsG1HLflF7Gn7KpjeNf+ziEcKZJV16+o= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9KAK33vRJaCwLQNJU2mlIkBC0t1G+0bSVECAiLzS7fJ+yDu/8JxqiNqn6jjGVYPa X-RZG-CLASS-ID: mo00 Received: from [IPv6:2001:4dd0:ff67:0:c850:2882:1b1:58d2] ([2001:4dd0:ff67:0:c850:2882:1b1:58d2]) by smtp.strato.de (RZmta 39.13 AUTH) with ESMTPSA id e00f8dt1OG4gfgK (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Fri, 24 Feb 2017 17:04:42 +0100 (CET) Subject: Re: Quick Elephants To: quic@ietf.org References: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> From: Roland Zink Message-ID: <8b12ccfe-dd03-60b3-461e-17e0b55a1b86@zinks.de> Date: Fri, 24 Feb 2017 17:04:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 16:04:46 -0000 Sounds good to me. However when the endpoing vendors / operators don't consider this the link vendor / operator can't do anything about it. So this may cause network ossification. Roland Am 24.02.2017 um 16:45 schrieb Watson Ladd: > On Fri, Feb 24, 2017 at 7:14 AM, Roland Zink wrote: >> Don't think this is completely independent of the congestion control. >> Resending lost packets also make the ack coming earlier. The congestion >> algorithm will behave different, for example packet losses may be hidden. As >> this doesn't work with QUIC the NewReno or Cubic congestion control >> algorithms may show bad performance and will be unable to fill the pipe >> depending on the link error rate. > There are new link error insensitive algorithms which learn the error > rate and congestion separately. We might want > to recommend using one of those. > >> Roland >> >> >> >> Am 24.02.2017 um 14:40 schrieb Mirja Kühlewind: >>> Yes, the problem is that you don’t see anymore with quic that a packet was >>> lost, so you can’t retransmit locally (I think this is totally independent >>> of the congestion control though…) >>> >>> Mirja >>> >>> >>>> Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishida >>>> : >>>> >>>> I also think we don't need to make special recommendations. But, if the >>>> dirty hacks include transparent PEPs, I guess it will be difficult to do >>>> with QUIC. >>>> -- >>>> Yoshi >>>> >>>> On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar wrote: >>>> Hi Watson, >>>> >>>> The current plan is to write up NewReno as the congestion controller for >>>> QUIC. I don't think we need to make special recommendations for networks >>>> with large BDPs in terms of congestion control, since QUIC can use the same >>>> congestion controller as TCP for these networks. Specifically, if you have >>>> dirty hacks that you use to make TCP (with NewReno or Cubic) work, you ought >>>> to be able to do the same trickery with QUIC. >>>> >>>> (I can't think of new multiplexing recommendations for these networks.) >>>> >>>> - jana >>>> >>>> On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd >>>> wrote: >>>> Dear all, >>>> >>>> I'm not that familiar with the state of play here, but in the future >>>> we will have more and more LFN network connections (long fat pipe: >>>> high bandwidth-delay product with long delays), as well as wireless >>>> networks where packet losses are not necessarily due to contention on >>>> the shared channel. >>>> >>>> My understanding is currently we have a bunch of dirty hacks (like >>>> locally resending data over the lossy bit) to make this work, a lot of >>>> which will stop working with QUIC. What can we recommend for >>>> congestion control algorithms and multiplexing use to alleviate the >>>> problems? >>>> >>>> Sincerely, >>>> Watson >>>> >>>> >>>> > > From nobody Fri Feb 24 09:37:13 2017 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 5701112943F for ; Fri, 24 Feb 2017 09:37:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 dTBHwqex3VII for ; Fri, 24 Feb 2017 09:37:09 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id D235B129437 for ; Fri, 24 Feb 2017 09:37:08 -0800 (PST) Received: from dhcp-207-152.erg.abdn.ac.uk (unknown [IPv6:2001:630:241:207:ad93:b031:ada7:e29d]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 22F4C1B00221; Fri, 24 Feb 2017 19:34:54 +0000 (GMT) Subject: Re: Quick Elephants References: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> <8b12ccfe-dd03-60b3-461e-17e0b55a1b86@zinks.de> To: Roland Zink , quic@ietf.org From: Gorry Fairhurst Organization: The University of Aberdeen is a charity registered in Scotland, No SC013683. Message-ID: Date: Fri, 24 Feb 2017 17:37:06 +0000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <8b12ccfe-dd03-60b3-461e-17e0b55a1b86@zinks.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: gorry@erg.abdn.ac.uk List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:37:11 -0000 On 24/02/2017 16:04, Roland Zink wrote: > Sounds good to me. However when the endpoing vendors / operators don't > consider this the link vendor / operator can't do anything about it. So > this may cause network ossification. > > Roland > > > > Am 24.02.2017 um 16:45 schrieb Watson Ladd: >> On Fri, Feb 24, 2017 at 7:14 AM, Roland Zink wrote: >>> Don't think this is completely independent of the congestion control. >>> Resending lost packets also make the ack coming earlier. The congestion >>> algorithm will behave different, for example packet losses may be >>> hidden. As >>> this doesn't work with QUIC the NewReno or Cubic congestion control >>> algorithms may show bad performance and will be unable to fill the pipe >>> depending on the link error rate. >> There are new link error insensitive algorithms which learn the error >> rate and congestion separately. We might want >> to recommend using one of those. >> >>> Roland >>> >>> >>> >>> Am 24.02.2017 um 14:40 schrieb Mirja Kühlewind: >>>> Yes, the problem is that you don’t see anymore with quic that a >>>> packet was >>>> lost, so you can’t retransmit locally (I think this is totally >>>> independent of the congestion control though…) >>>> >>>> Mirja >>>> >>>> >>>>> Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishida >>>>> : >>>>> >>>>> I also think we don't need to make special recommendations. But, if >>>>> the >>>>> dirty hacks include transparent PEPs, I guess it will be difficult >>>>> to do >>>>> with QUIC. >>>>> -- >>>>> Yoshi >>>>> >>>>> On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar wrote: >>>>> Hi Watson, >>>>> >>>>> The current plan is to write up NewReno as the congestion >>>>> controller for >>>>> QUIC. I don't think we need to make special recommendations for >>>>> networks >>>>> with large BDPs in terms of congestion control, since QUIC can use >>>>> the same >>>>> congestion controller as TCP for these networks. Specifically, if >>>>> you have >>>>> dirty hacks that you use to make TCP (with NewReno or Cubic) work, >>>>> you ought >>>>> to be able to do the same trickery with QUIC. >>>>> >>>>> (I can't think of new multiplexing recommendations for these >>>>> networks.) >>>>> >>>>> - jana >>>>> >>>>> On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd >>>>> wrote: >>>>> Dear all, >>>>> >>>>> I'm not that familiar with the state of play here, but in the future >>>>> we will have more and more LFN network connections (long fat pipe: >>>>> high bandwidth-delay product with long delays), as well as wireless >>>>> networks where packet losses are not necessarily due to contention on >>>>> the shared channel. >>>>> >>>>> My understanding is currently we have a bunch of dirty hacks (like >>>>> locally resending data over the lossy bit) to make this work, a lot of >>>>> which will stop working with QUIC. What can we recommend for >>>>> congestion control algorithms and multiplexing use to alleviate the >>>>> problems? >>>>> >>>>> Sincerely, >>>>> Watson >>>>> >>>>> >>>>> >> >> > Normally new congestion control methods need to be reviewed by ICCRG before they are progressed by a TSV working group. Have any of these algorithms being presented to the IETF (point me please to presentations i can look at). I'm assuming the same applies for QUIC also when it comes to this sort change? Gorry From nobody Fri Feb 24 09:39:39 2017 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 CE4E6129445 for ; Fri, 24 Feb 2017 09:39:37 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 ZASyva11MU7W for ; Fri, 24 Feb 2017 09:39:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 549D412943F for ; Fri, 24 Feb 2017 09:39:36 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DFFBF433413 for ; Fri, 24 Feb 2017 17:39:35 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C5BCB433407 for ; Fri, 24 Feb 2017 17:39:35 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487957975; bh=UYhXU+m0nkBOH8los750czGu7tKytB0R1ZDGItA3Jlc=; l=2598; h=To:References:From:Date:In-Reply-To:From; b=TDzGPTsxmHtp7sc31LQ9XzegUYygyR8U7ohJmV5iufIBvIuQO3mL77OKoaRG+kO3v QCG+qBuBUp8S2dkfbawEkqlL2dV9vTpZnUAV1CTXa91Y6wWF2tDMaxTjEnWzVP7SYW xT0jCCuoZGhyOtOjXpTTtIHgaAFkgfI5Lr4ZQ54Q= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A72721FC8B for ; Fri, 24 Feb 2017 17:39:35 +0000 (GMT) Subject: Re: FW: New Version Notification for draft-johansson-quic-ecn-01.txt To: quic@ietf.org References: <148775013501.16692.8977264819064966788.idtracker@ietfa.amsl.com> <6a7c4ca2-1955-d290-a400-9f9eefe49671@it.uc3m.es> <2a86ab62-9d7f-87a7-1d81-8faa2fa06787@huitema.net> From: Benjamin Kaduk Message-ID: <67df2fa7-e6eb-23d0-f16d-1fa73253a93c@akamai.com> Date: Fri, 24 Feb 2017 11:39:35 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <2a86ab62-9d7f-87a7-1d81-8faa2fa06787@huitema.net> Content-Type: multipart/alternative; boundary="------------36823E2607FCAB4FBB21F18A" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:39:38 -0000 This is a multi-part message in MIME format. --------------36823E2607FCAB4FBB21F18A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 02/23/2017 06:39 PM, Christian Huitema wrote: > > > Yes, please. I understand where Mirja comes from, and I also > understand what ECN means in this context, but Philip has a good > point. QUIC straddles several layers of our stack, from transport to > application through security. Three letters acronyms are way more > ambiguous than you may think, even inside the IETF. For example, I > guess you all know that FEC means Forward Error Correction, right? But > if you have to use MPLS, FEC means Forwarding Equivalence Class. So, > please, just be conservative. Use the full spelling of the acronyms in > the title, abstract and introduction of documents! I'll also throw a mention out there of https://www.rfc-editor.org/materials/abbrev.expansion.txt which has a lot of acronym expansions. It also marks a limited subset as not needing expansion in RFCs due to being well-known (ECN is not one such). -Ben --------------36823E2607FCAB4FBB21F18A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 02/23/2017 06:39 PM, Christian Huitema wrote:


Yes, please. I understand where Mirja comes from, and I also understand what ECN means in this context, but Philip has a good point. QUIC straddles several layers of our stack, from transport to application through security. Three letters acronyms are way more ambiguous than you may think, even inside the IETF. For example, I guess you all know that FEC means Forward Error Correction, right? But if you have to use MPLS, FEC means Forwarding Equivalence Class. So, please, just be conservative. Use the full spelling of the acronyms in the title, abstract and introduction of documents!

I'll also throw a mention out there of https://www.rfc-editor.org/materials/abbrev.expansion.txt which has a lot of acronym expansions.  It also marks a limited subset as not needing expansion in RFCs due to being well-known (ECN is not one such).

-Ben
--------------36823E2607FCAB4FBB21F18A-- From nobody Fri Feb 24 09:43:28 2017 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 3D2EB129444 for ; Fri, 24 Feb 2017 09:43:27 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 gcs9PNMDsirU for ; Fri, 24 Feb 2017 09:43:24 -0800 (PST) Received: from mail-vk0-x22b.google.com (mail-vk0-x22b.google.com [IPv6:2607:f8b0:400c: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 3C546129448 for ; Fri, 24 Feb 2017 09:43:24 -0800 (PST) Received: by mail-vk0-x22b.google.com with SMTP id x75so15631629vke.2 for ; Fri, 24 Feb 2017 09:43:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tzMQphjqhC172298szbN8vWxRcPfKxCbuMgLQk8B4jQ=; b=HbnbZCw1a8dXmlZsfsjUYHCNzaZyLt+z4s51NL/7HkW1UtJPtqvMfacuI/nNj3lhXZ J2QO+5x7K3AsNLyOTXBTSgk+91A1MdEbac4d191OO0wXn4GTP29LKhPEN5JWLaykcdab 6rRd05JGKFhFm3kx92ZekLAT1mwBN5gteVj2VGIOO3dnucer6px6ymxxdbWk3AOjLTjR eXTyNFpJbGqpTQKx+HXbIjNPtwtLu7c3v0v0hVRtyiqgOLPQRJEraNEUhdh/uafs0ktt az4yiSJWXih5zdj93eg8X5FhT4UQvYV5995brpTD2bJ1BVgXj0kdLVYyFe0QqzkrItWF ZZXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tzMQphjqhC172298szbN8vWxRcPfKxCbuMgLQk8B4jQ=; b=o2osMNMHAXdiaPJ3rRTih6/l4NFOJxGs6VbDa4obz/KZ8YMkhH0UPWHRrYSj/Be7ga ys8v8jAKtO7cWJ08HH2PM6l7TNydq/HV7LOMFD1440lWKYR99/DDEo/xMPmiMuU7vN2m nzA14XOq7LP1VkQ7HHeloYTHjNx7mj0ZZOJT5qbP5iyuf+9iXFhpbYPAWt9tbBEb0xIT ZjBRmSHrxegyoQt1C2/Qnwc3FRjJWKr144EbasoEn59Gp4whT3YUgdSYgwpkdlF5gz6A 4j08Wh9bmq9tkjPmcnOi4LfWzOCRCji4/t5rOL1kMxtZpsCdrCz/aICw/ARzujoHVxVH j9tA== X-Gm-Message-State: AMke39knM1uZo+mUshL1A5o4NDUZioc1YW5DFIQOaOvY84KPiQROFr0cyAVndFi8bDMF+sjoVNVnJJkw9rkTf4vR X-Received: by 10.31.99.1 with SMTP id x1mr1664910vkb.161.1487958202939; Fri, 24 Feb 2017 09:43:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Fri, 24 Feb 2017 09:43:22 -0800 (PST) In-Reply-To: References: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> <8b12ccfe-dd03-60b3-461e-17e0b55a1b86@zinks.de> From: Jana Iyengar Date: Fri, 24 Feb 2017 09:43:22 -0800 Message-ID: Subject: Re: Quick Elephants To: "Gorry (erg)" Content-Type: multipart/alternative; boundary=94eb2c07b17820bc0905494a44c4 Archived-At: Cc: IETF QUIC WG , Roland Zink X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 17:43:27 -0000 --94eb2c07b17820bc0905494a44c4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable The charter says: "Work on congestion control will describe use of a standardized congestion controller as a default scheme for QUIC. Defining new congestion control schemes is explicitly out of scope for this group." The current plan is to describe NewReno for QUIC in draft-ietf-quic-recovery. If there's interest in writing a Cubic for QUIC document after the cubic doc is finished in TCPM, I'd be fine with that being a later additional doc. Subsequent non-standardized controllers however should follow a similar process as we expect for TCP today. At any rate, this won't appear in any of the current QUIC wg documents unless we re-charter. On Fri, Feb 24, 2017 at 9:37 AM, Gorry Fairhurst wrote: > On 24/02/2017 16:04, Roland Zink wrote: > >> Sounds good to me. However when the endpoing vendors / operators don't >> consider this the link vendor / operator can't do anything about it. So >> this may cause network ossification. >> >> Roland >> >> >> >> Am 24.02.2017 um 16:45 schrieb Watson Ladd: >> >>> On Fri, Feb 24, 2017 at 7:14 AM, Roland Zink wrote: >>> >>>> Don't think this is completely independent of the congestion control. >>>> Resending lost packets also make the ack coming earlier. The congestio= n >>>> algorithm will behave different, for example packet losses may be >>>> hidden. As >>>> this doesn't work with QUIC the NewReno or Cubic congestion control >>>> algorithms may show bad performance and will be unable to fill the pip= e >>>> depending on the link error rate. >>>> >>> There are new link error insensitive algorithms which learn the error >>> rate and congestion separately. We might want >>> to recommend using one of those. >>> >>> Roland >>>> >>>> >>>> >>>> Am 24.02.2017 um 14:40 schrieb Mirja K=C3=BChlewind: >>>> >>>>> Yes, the problem is that you don=E2=80=99t see anymore with quic that= a >>>>> packet was >>>>> lost, so you can=E2=80=99t retransmit locally (I think this is totall= y >>>>> independent of the congestion control though=E2=80=A6) >>>>> >>>>> Mirja >>>>> >>>>> >>>>> Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishida >>>>>> : >>>>>> >>>>>> I also think we don't need to make special recommendations. But, if >>>>>> the >>>>>> dirty hacks include transparent PEPs, I guess it will be difficult >>>>>> to do >>>>>> with QUIC. >>>>>> -- >>>>>> Yoshi >>>>>> >>>>>> On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar >>>>>> wrote: >>>>>> Hi Watson, >>>>>> >>>>>> The current plan is to write up NewReno as the congestion >>>>>> controller for >>>>>> QUIC. I don't think we need to make special recommendations for >>>>>> networks >>>>>> with large BDPs in terms of congestion control, since QUIC can use >>>>>> the same >>>>>> congestion controller as TCP for these networks. Specifically, if >>>>>> you have >>>>>> dirty hacks that you use to make TCP (with NewReno or Cubic) work, >>>>>> you ought >>>>>> to be able to do the same trickery with QUIC. >>>>>> >>>>>> (I can't think of new multiplexing recommendations for these >>>>>> networks.) >>>>>> >>>>>> - jana >>>>>> >>>>>> On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd >>>>>> wrote: >>>>>> Dear all, >>>>>> >>>>>> I'm not that familiar with the state of play here, but in the future >>>>>> we will have more and more LFN network connections (long fat pipe: >>>>>> high bandwidth-delay product with long delays), as well as wireless >>>>>> networks where packet losses are not necessarily due to contention o= n >>>>>> the shared channel. >>>>>> >>>>>> My understanding is currently we have a bunch of dirty hacks (like >>>>>> locally resending data over the lossy bit) to make this work, a lot = of >>>>>> which will stop working with QUIC. What can we recommend for >>>>>> congestion control algorithms and multiplexing use to alleviate the >>>>>> problems? >>>>>> >>>>>> Sincerely, >>>>>> Watson >>>>>> >>>>>> >>>>>> >>>>>> >>> >>> >> > Normally new congestion control methods need to be reviewed by ICCRG > before they are progressed by a TSV working group. Have any of these > algorithms being presented to the IETF (point me please to presentations = i > can look at). I'm assuming the same applies for QUIC also when it comes = to > this sort change? > > Gorry > > --94eb2c07b17820bc0905494a44c4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The charter says:=C2=A0

"Work on c= ongestion control will describe use of a=C2=A0
standardized congestion = controller as a default scheme for
QUIC. Defining new congestion = control schemes is explicitly out of=C2=A0
scope for this group.&= quot;

The current plan is to describe NewRen= o for QUIC in draft-ietf-quic-recovery. If there's interest in writing = a Cubic for QUIC document after the cubic doc is finished in TCPM, I'd = be fine with that being a later additional doc.

Subsequen= t non-standardized controllers however should follow a similar process as w= e expect for TCP today. At any rate, this won't appear in any of the cu= rrent QUIC wg documents unless we re-charter.

On Fri, Feb 24, 2017 at 9:37 AM, Go= rry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 24/02/2017 = 16:04, Roland Zink wrote:
Sounds good to me. However when the endpoing vendors / operators don't<= br> consider this the link vendor / operator can't do anything about it. So=
this may cause network ossification.

Roland



Am 24.02.2017 um 16:45 schrieb Watson Ladd:
On Fri, Feb 24, 2017 at 7:14 AM, Roland Zink <roland@zinks.de> wrote:
Don't think this is completely independent of the congestion control. Resending lost packets also make the ack coming earlier. The congestion
algorithm will behave different, for example packet losses may be
hidden. As
this doesn't work with QUIC the NewReno or Cubic congestion control
algorithms may show bad performance and will be unable to fill the pipe
depending on the link error rate.
There are new link error insensitive algorithms which learn the error
rate and congestion separately. We might want
to recommend using one of those.

Roland



Am 24.02.2017 um 14:40 schrieb Mirja K=C3=BChlewind:
Yes, the problem is that you don=E2=80=99t see anymore with quic that a
packet was
lost, so you can=E2=80=99t retransmit locally (I think this is totally
independent of the congestion control though=E2=80=A6)

Mirja


Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishida
<nishida@sfc= .wide.ad.jp>:

I also think we don't need to make special recommendations. But, if
the
dirty hacks include transparent PEPs, I guess it will be difficult
to do
with QUIC.
--
Yoshi

On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar <jri@google.com> wrote:
Hi Watson,

The current plan is to write up NewReno as the congestion
controller for
QUIC. I don't think we need to make special recommendations for
networks
with large BDPs in terms of congestion control, since QUIC can use
the same
congestion controller as TCP for these networks. Specifically, if
you have
dirty hacks that you use to make TCP (with NewReno or Cubic) work,
you ought
to be able to do the same trickery with QUIC.

(I can't think of new multiplexing recommendations for these
networks.)

- jana

On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd <watsonbladd@gmail.com>
wrote:
Dear all,

I'm not that familiar with the state of play here, but in the future we will have more and more LFN network connections (long fat pipe:
high bandwidth-delay product with long delays), as well as wireless
networks where packet losses are not necessarily due to contention on
the shared channel.

My understanding is currently we have a bunch of dirty hacks (like
locally resending data over the lossy bit) to make this work, a lot of
which will stop working with QUIC.=C2=A0 What can we recommend for
congestion control algorithms and multiplexing use to alleviate the
problems?

Sincerely,
Watson







Normally new=C2=A0 congestion control methods need to be reviewed by ICCRG = before they are progressed by a TSV working group. Have any of these algori= thms being presented to the IETF (point me please to presentations i can lo= ok at).=C2=A0 I'm assuming the same applies for QUIC also when it comes= to this sort change?

Gorry


--94eb2c07b17820bc0905494a44c4-- From nobody Fri Feb 24 12:18:09 2017 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 69E841294FC for ; Fri, 24 Feb 2017 12:18:08 -0800 (PST) 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=unavailable 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 9Ww4hICEcjWK for ; Fri, 24 Feb 2017 12:18:07 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F05031294EF for ; Fri, 24 Feb 2017 12:12:50 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id t18so10425076wmt.0 for ; Fri, 24 Feb 2017 12:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xlBUBqCXv7MdiwL3JIa9A1/KITfDAQIqygJAsr3F9yw=; b=GciM+5S7MekxAGcYLa7rQ9PiJbED8pdRIUCMl90aJnDJIX74iIARKtIylo+0A/wnU6 3JhCW7pK0rMoynVC8++sIFyBM8owzsxawW90jZ05P9dp7jMoEBU2GVVatgLbx2dAD9tx Mg8UGz9luyusX5ynOOb/NP/uiMQtD9EZsdpPD2X5dba8i7tqyIWCjxuSljVmbn0N1PuD rdxLUaO91OSW7wPcWoOKuH43gPi7bliJUQczLBuLL+zwVckDl0Pz12FPNImE/p+JMKta FBsj9V+bLe7LE44HrpWJXtJvRX5ASeRWFlnsFxJtTf/AkM93fYllXwKUEDh/W5YVrYUM H//Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xlBUBqCXv7MdiwL3JIa9A1/KITfDAQIqygJAsr3F9yw=; b=VPZ4A9QxtkxDiElTmvz+2H8gQPLpU4OI6ORV2FewQVTOatfNsf3WqQirpZvftYRe6i XIEuzRMwKaroge8cleSiQ8zqj9jiS2BdhwFz/j0omim3vaUdonKjAaO0xLNhGTX31JZo wgRlUQx0R74I3zlg/7vntd+t6V8fv1HeeDNBC/GcuBkc0HLtivSFlmZq/lWB2J12QM/G oAes7cwNiKYNr+3KeYYMs98ML6H8zISnPX9TyyHGA5ywLAP90CqfN+1WoolzvKqpejzc PvKfZ2EYp9V3pvuhbb8gHX6EAmXHEmk/oq6Z2Rw0dIh1er7xpIptOHrtoSSt36tqY5Jl hYfQ== X-Gm-Message-State: AMke39l/9nkmcPCUZ/LD0RLkrZZd1BAGjAxM73IX6AB9VqQOGzR2ei+KdwuUY0RcxNeR3w+4cHOo5yWvyyKuRA== X-Received: by 10.28.47.15 with SMTP id v15mr4225420wmv.67.1487967169337; Fri, 24 Feb 2017 12:12:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.164.18 with HTTP; Fri, 24 Feb 2017 12:12:48 -0800 (PST) In-Reply-To: References: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> <8b12ccfe-dd03-60b3-461e-17e0b55a1b86@zinks.de> From: Watson Ladd Date: Fri, 24 Feb 2017 12:12:48 -0800 Message-ID: Subject: Re: Quick Elephants To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "Gorry \(erg\)" , IETF QUIC WG , Roland Zink X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 20:18:08 -0000 On Fri, Feb 24, 2017 at 9:43 AM, Jana Iyengar wrote: > The charter says: > > "Work on congestion control will describe use of a > standardized congestion controller as a default scheme for > QUIC. Defining new congestion control schemes is explicitly out of > scope for this group." > > The current plan is to describe NewReno for QUIC in > draft-ietf-quic-recovery. If there's interest in writing a Cubic for QUIC > document after the cubic doc is finished in TCPM, I'd be fine with that > being a later additional doc. After 12 years since Cubic escaped onto the Internet and was used by default in Linux, it still isn't standardized... I imagine Google's new one isn't going to even start. http://queue.acm.org/detail.cfm?id=3D3022184 > > Subsequent non-standardized controllers however should follow a similar > process as we expect for TCP today. At any rate, this won't appear in any= of > the current QUIC wg documents unless we re-charter. Ah, I hadn't realized that there were no loss-tolerant control protocols standardized yet. I guess we're going to be stuck with this wireless problem then, absent some creative vendor solutions (like per-packet acks? aggressive coding?). What can we do to help some of these solutions? > On Fri, Feb 24, 2017 at 9:37 AM, Gorry Fairhurst > wrote: >> >> On 24/02/2017 16:04, Roland Zink wrote: >>> >>> Sounds good to me. However when the endpoing vendors / operators don't >>> consider this the link vendor / operator can't do anything about it. So >>> this may cause network ossification. >>> >>> Roland >>> >>> >>> >>> Am 24.02.2017 um 16:45 schrieb Watson Ladd: >>>> >>>> On Fri, Feb 24, 2017 at 7:14 AM, Roland Zink wrote: >>>>> >>>>> Don't think this is completely independent of the congestion control. >>>>> Resending lost packets also make the ack coming earlier. The congesti= on >>>>> algorithm will behave different, for example packet losses may be >>>>> hidden. As >>>>> this doesn't work with QUIC the NewReno or Cubic congestion control >>>>> algorithms may show bad performance and will be unable to fill the pi= pe >>>>> depending on the link error rate. >>>> >>>> There are new link error insensitive algorithms which learn the error >>>> rate and congestion separately. We might want >>>> to recommend using one of those. >>>> >>>>> Roland >>>>> >>>>> >>>>> >>>>> Am 24.02.2017 um 14:40 schrieb Mirja K=C3=BChlewind: >>>>>> >>>>>> Yes, the problem is that you don=E2=80=99t see anymore with quic tha= t a >>>>>> packet was >>>>>> lost, so you can=E2=80=99t retransmit locally (I think this is total= ly >>>>>> independent of the congestion control though=E2=80=A6) >>>>>> >>>>>> Mirja >>>>>> >>>>>> >>>>>>> Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishida >>>>>>> : >>>>>>> >>>>>>> I also think we don't need to make special recommendations. But, if >>>>>>> the >>>>>>> dirty hacks include transparent PEPs, I guess it will be difficult >>>>>>> to do >>>>>>> with QUIC. >>>>>>> -- >>>>>>> Yoshi >>>>>>> >>>>>>> On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar >>>>>>> wrote: >>>>>>> Hi Watson, >>>>>>> >>>>>>> The current plan is to write up NewReno as the congestion >>>>>>> controller for >>>>>>> QUIC. I don't think we need to make special recommendations for >>>>>>> networks >>>>>>> with large BDPs in terms of congestion control, since QUIC can use >>>>>>> the same >>>>>>> congestion controller as TCP for these networks. Specifically, if >>>>>>> you have >>>>>>> dirty hacks that you use to make TCP (with NewReno or Cubic) work, >>>>>>> you ought >>>>>>> to be able to do the same trickery with QUIC. >>>>>>> >>>>>>> (I can't think of new multiplexing recommendations for these >>>>>>> networks.) >>>>>>> >>>>>>> - jana >>>>>>> >>>>>>> On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd >>>>>>> wrote: >>>>>>> Dear all, >>>>>>> >>>>>>> I'm not that familiar with the state of play here, but in the futur= e >>>>>>> we will have more and more LFN network connections (long fat pipe: >>>>>>> high bandwidth-delay product with long delays), as well as wireless >>>>>>> networks where packet losses are not necessarily due to contention = on >>>>>>> the shared channel. >>>>>>> >>>>>>> My understanding is currently we have a bunch of dirty hacks (like >>>>>>> locally resending data over the lossy bit) to make this work, a lot >>>>>>> of >>>>>>> which will stop working with QUIC. What can we recommend for >>>>>>> congestion control algorithms and multiplexing use to alleviate the >>>>>>> problems? >>>>>>> >>>>>>> Sincerely, >>>>>>> Watson >>>>>>> >>>>>>> >>>>>>> >>>> >>>> >>> >> >> Normally new congestion control methods need to be reviewed by ICCRG >> before they are progressed by a TSV working group. Have any of these >> algorithms being presented to the IETF (point me please to presentations= i >> can look at). I'm assuming the same applies for QUIC also when it comes= to >> this sort change? >> >> Gorry >> > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Fri Feb 24 12:32:44 2017 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 9126F1294FB for ; Fri, 24 Feb 2017 12:32:41 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 UQ3RE_Qo0OHD for ; Fri, 24 Feb 2017 12:32:39 -0800 (PST) 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 F20D31294EF for ; Fri, 24 Feb 2017 12:32:38 -0800 (PST) Received: by mail-vk0-x233.google.com with SMTP id k127so18058704vke.0 for ; Fri, 24 Feb 2017 12:32:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Fs9cH2vd5Equp85ooDX+SxesQcsgij9JfdR2u7vSbZs=; b=LEbfYvINw9dgbPyH0CBi2pKsBD7G38dEZUcbJDWDFm43yFWJYu+WtUI0+jfTi5PMyb bGMXGp8+88bIZqVDwV9jSxREyCuzOODYyMDJp5mu4tRWq+AGDn3GC6m/bPf7+RwI3+QO BTG19evUjE47XOoWWzxyBFt5FYuA0Y+sGlwIOcZXq3CrzoNh3ElM8I4tlh651uSlrLtJ IwIIJAshc5oRgjDpfV1QchcUA2ahUkTQU1AuxSoOdJIaCLBxjTbRF10aAW/vDocyf3C6 /Nm1rUHU7S2mmxrK4vYbNXwDqIapMd16vhNPtvBXuqkGp9U0ADZJOxaHca3q3cP1I0/v ROqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Fs9cH2vd5Equp85ooDX+SxesQcsgij9JfdR2u7vSbZs=; b=nXXGlgG/w76xfi0dR0oyqjBW4mJ2WT6I3JRbtJq0daszHDDGTUNQkH2dO9TaQeBtVT szjQs8nMK6hfrCQcrlgGvu5xXMRZjFP21FOTbT1UWp/TcN4Gm1jwwNNX1ZuZ3jwRSPzn ARYBnj4pPsfa4YzKSeWgbil2oSuu4HY2DgGnubSJMN0XFY64ppF1ChA68PmpNnols+lx tWPg7lKMh8RBiKQ67QN8im4ZtSFCjA661LV1n2LF6pnVfoVuMOrRTMiDbMV6LXleLm6B fusznIDSokEY/usgSWVfxw4FpeVOykefXTniB55GMCobl/4S97n3pkeFHj7HhQuDO4UZ bF6w== X-Gm-Message-State: AMke39nFnR0Y0MMSHB8UZ2junsC1AqUjkbwNZ8VOl7MpzwSnpttcVhQroxUNf0J/KVWOgxOp4XQEVkqzF4tBlEdN X-Received: by 10.31.89.197 with SMTP id n188mr1609648vkb.58.1487968357723; Fri, 24 Feb 2017 12:32:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.15.6 with HTTP; Fri, 24 Feb 2017 12:32:37 -0800 (PST) In-Reply-To: References: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> <8b12ccfe-dd03-60b3-461e-17e0b55a1b86@zinks.de> From: Jana Iyengar Date: Fri, 24 Feb 2017 12:32:37 -0800 Message-ID: Subject: Re: Quick Elephants To: Watson Ladd Content-Type: multipart/alternative; boundary=001a114e19b066904305494ca131 Archived-At: Cc: "Gorry \(erg\)" , IETF QUIC WG , Roland Zink X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 20:32:41 -0000 --001a114e19b066904305494ca131 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Feb 24, 2017 at 12:12 PM, Watson Ladd wrote= : > On Fri, Feb 24, 2017 at 9:43 AM, Jana Iyengar wrote: > > The charter says: > > > > "Work on congestion control will describe use of a > > standardized congestion controller as a default scheme for > > QUIC. Defining new congestion control schemes is explicitly out of > > scope for this group." > > > > The current plan is to describe NewReno for QUIC in > > draft-ietf-quic-recovery. If there's interest in writing a Cubic for QU= IC > > document after the cubic doc is finished in TCPM, I'd be fine with that > > being a later additional doc. > > After 12 years since Cubic escaped onto the Internet and was used by > default in Linux, it still isn't standardized... I imagine Google's > new one isn't going to even start. > http://queue.acm.org/detail.cfm?id=3D3022184 There are a lot more congestion controllers in use today than those standardized. There are about a dozen of these available to any Linux server today for TCP. This is partly because congestion control does not need interoperability, and the ones that the IETF ends up documenting are still Informational (see cubic draft .) The reason for IETF documentation of these controllers is not to write "yet another standard that's late," but to have a reference for others wanting to implement it because it's proven. Bear in mind that before the IETF documented LEDBAT, there was no documentation for it, and there's no real documentation for Cubic either (modulo their paper, which is inadequate for an implementer.) Sure Cubic could have been documented earlier, but AIUI, Lars had to expend some energy getting the Cubic designers to do this at the IETF. Implementations haven been free to choose their own controller for TCP; indeed that's how Google experimented with BBR. Google is experimenting with BBR in QUIC as well, but I don't think it ought to be documented in the IETF yet since it's still quite experimental. > > > Subsequent non-standardized controllers however should follow a similar > > process as we expect for TCP today. At any rate, this won't appear in > any of > > the current QUIC wg documents unless we re-charter. > > Ah, I hadn't realized that there were no loss-tolerant control > protocols standardized yet. I guess we're going to be stuck with this > wireless problem then, absent some creative vendor solutions (like > per-packet acks? aggressive coding?). What can we do to help some of > these solutions? Yeah there aren't any loss tolerant ones standardized yet because we have very little publicly-shared experience with those as a community. I suspect that the most widely deployed controllers right now for TCP are Cubic, NewReno, and FastTCP, but only two of those are documented in the IETF. This shouldn't keep folks from trying with loss-tolerant ones though! And if you know of any such work, please get them to show up in ICCRG! (ICCRG-chair hat on :-)) > > On Fri, Feb 24, 2017 at 9:37 AM, Gorry Fairhurst > > wrote: > >> > >> On 24/02/2017 16:04, Roland Zink wrote: > >>> > >>> Sounds good to me. However when the endpoing vendors / operators don'= t > >>> consider this the link vendor / operator can't do anything about it. = So > >>> this may cause network ossification. > >>> > >>> Roland > >>> > >>> > >>> > >>> Am 24.02.2017 um 16:45 schrieb Watson Ladd: > >>>> > >>>> On Fri, Feb 24, 2017 at 7:14 AM, Roland Zink wrote= : > >>>>> > >>>>> Don't think this is completely independent of the congestion contro= l. > >>>>> Resending lost packets also make the ack coming earlier. The > congestion > >>>>> algorithm will behave different, for example packet losses may be > >>>>> hidden. As > >>>>> this doesn't work with QUIC the NewReno or Cubic congestion control > >>>>> algorithms may show bad performance and will be unable to fill the > pipe > >>>>> depending on the link error rate. > >>>> > >>>> There are new link error insensitive algorithms which learn the erro= r > >>>> rate and congestion separately. We might want > >>>> to recommend using one of those. > >>>> > >>>>> Roland > >>>>> > >>>>> > >>>>> > >>>>> Am 24.02.2017 um 14:40 schrieb Mirja K=C3=BChlewind: > >>>>>> > >>>>>> Yes, the problem is that you don=E2=80=99t see anymore with quic t= hat a > >>>>>> packet was > >>>>>> lost, so you can=E2=80=99t retransmit locally (I think this is tot= ally > >>>>>> independent of the congestion control though=E2=80=A6) > >>>>>> > >>>>>> Mirja > >>>>>> > >>>>>> > >>>>>>> Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishida > >>>>>>> : > >>>>>>> > >>>>>>> I also think we don't need to make special recommendations. But, = if > >>>>>>> the > >>>>>>> dirty hacks include transparent PEPs, I guess it will be difficul= t > >>>>>>> to do > >>>>>>> with QUIC. > >>>>>>> -- > >>>>>>> Yoshi > >>>>>>> > >>>>>>> On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar > >>>>>>> wrote: > >>>>>>> Hi Watson, > >>>>>>> > >>>>>>> The current plan is to write up NewReno as the congestion > >>>>>>> controller for > >>>>>>> QUIC. I don't think we need to make special recommendations for > >>>>>>> networks > >>>>>>> with large BDPs in terms of congestion control, since QUIC can us= e > >>>>>>> the same > >>>>>>> congestion controller as TCP for these networks. Specifically, if > >>>>>>> you have > >>>>>>> dirty hacks that you use to make TCP (with NewReno or Cubic) work= , > >>>>>>> you ought > >>>>>>> to be able to do the same trickery with QUIC. > >>>>>>> > >>>>>>> (I can't think of new multiplexing recommendations for these > >>>>>>> networks.) > >>>>>>> > >>>>>>> - jana > >>>>>>> > >>>>>>> On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd < > watsonbladd@gmail.com> > >>>>>>> wrote: > >>>>>>> Dear all, > >>>>>>> > >>>>>>> I'm not that familiar with the state of play here, but in the > future > >>>>>>> we will have more and more LFN network connections (long fat pipe= : > >>>>>>> high bandwidth-delay product with long delays), as well as wirele= ss > >>>>>>> networks where packet losses are not necessarily due to contentio= n > on > >>>>>>> the shared channel. > >>>>>>> > >>>>>>> My understanding is currently we have a bunch of dirty hacks (lik= e > >>>>>>> locally resending data over the lossy bit) to make this work, a l= ot > >>>>>>> of > >>>>>>> which will stop working with QUIC. What can we recommend for > >>>>>>> congestion control algorithms and multiplexing use to alleviate t= he > >>>>>>> problems? > >>>>>>> > >>>>>>> Sincerely, > >>>>>>> Watson > >>>>>>> > >>>>>>> > >>>>>>> > >>>> > >>>> > >>> > >> > >> Normally new congestion control methods need to be reviewed by ICCRG > >> before they are progressed by a TSV working group. Have any of these > >> algorithms being presented to the IETF (point me please to > presentations i > >> can look at). I'm assuming the same applies for QUIC also when it > comes to > >> this sort change? > >> > >> Gorry > >> > > > > > > -- > "Man is born free, but everywhere he is in chains". > --Rousseau. > --001a114e19b066904305494ca131 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 24, 2017 at 12:12 PM, Watson Ladd <watsonbladd@gmail.com&g= t; wrote:
On Fri,= Feb 24, 2017 at 9:43 AM, Jana Iyengar <jri@google.com> wrote:
> The charter says:
>
> "Work on congestion control will describe use of a
> standardized congestion controller as a default scheme for
> QUIC. Defining new congestion control schemes is explicitly out of
> scope for this group."
>
> The current plan is to describe NewReno for QUIC in
> draft-ietf-quic-recovery. If there's interest in writing a Cubic f= or QUIC
> document after the cubic doc is finished in TCPM, I'd be fine with= that
> being a later additional doc.

After 12 years since Cubic escaped onto the Internet and was used by=
default in Linux, it still isn't standardized... I imagine Google's=
new one isn't going to even start.
http://queue.acm.org/detail.cfm?id=3D3022184

There are a lot more congestion controllers i= n use today than those standardized. There are about a dozen of these avail= able to any Linux server today for TCP. This is partly because congestion c= ontrol does not need interoperability, and the ones that the IETF ends up d= ocumenting are still Informational (see cubic draft.)=C2=A0

<= div>The reason for IETF documentation of these controllers is not to write = "yet another standard that's late," but to have a reference f= or others wanting to implement it because it's proven. Bear in mind tha= t before the IETF documented LEDBAT, there was no documentation for it, and= there's no real documentation for Cubic either (modulo their paper, wh= ich is inadequate for an implementer.) Sure Cubic could have been documente= d earlier, but AIUI, Lars had to expend some energy getting the Cubic desig= ners to do this at the IETF.

Implementations haven= been free to choose their own controller for TCP; indeed that's how Go= ogle experimented with BBR. Google is experimenting with BBR in QUI= C=C2=A0as well, but I don't think it ought to be documented in the = IETF yet since it's still quite experimental.

>
> Subsequent non-standardized controllers however should follow a simila= r
> process as we expect for TCP today. At any rate, this won't appear= in any of
> the current QUIC wg documents unless we re-charter.

Ah, I hadn't realized that there were no loss-tolerant control protocols standardized yet. I guess we're going to be stuck with this wireless problem then, absent some creative vendor solutions (like
per-packet acks? aggressive coding?). What can we do to help some of
these solutions?

Yeah there aren't any = loss tolerant ones standardized yet because we have very little publicly-sh= ared experience with those as a community. I suspect that the most widely d= eployed controllers right now for TCP are Cubic, NewReno, and FastTCP, but = only two of those are documented in the IETF. This shouldn't keep folks= from trying with loss-tolerant ones though!

And i= f you know of any such work, please get them to show up in ICCRG! (ICCRG-ch= air hat on :-))
=C2=A0
> On Fri, Feb 24, 2017 at 9:37 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk>
> wrote:
>>
>> On 24/02/2017 16:04, Roland Zink wrote:
>>>
>>> Sounds good to me. However when the endpoing vendors / operato= rs don't
>>> consider this the link vendor / operator can't do anything= about it. So
>>> this may cause network ossification.
>>>
>>> Roland
>>>
>>>
>>>
>>> Am 24.02.2017 um 16:45 schrieb Watson Ladd:
>>>>
>>>> On Fri, Feb 24, 2017 at 7:14 AM, Roland Zink <roland@zinks.de> wrote:
>>>>>
>>>>> Don't think this is completely independent of the = congestion control.
>>>>> Resending lost packets also make the ack coming earlie= r. The congestion
>>>>> algorithm will behave different, for example packet lo= sses may be
>>>>> hidden. As
>>>>> this doesn't work with QUIC the NewReno or Cubic c= ongestion control
>>>>> algorithms may show bad performance and will be unable= to fill the pipe
>>>>> depending on the link error rate.
>>>>
>>>> There are new link error insensitive algorithms which lear= n the error
>>>> rate and congestion separately. We might want
>>>> to recommend using one of those.
>>>>
>>>>> Roland
>>>>>
>>>>>
>>>>>
>>>>> Am 24.02.2017 um 14:40 schrieb Mirja K=C3=BChlewind: >>>>>>
>>>>>> Yes, the problem is that you don=E2=80=99t see any= more with quic that a
>>>>>> packet was
>>>>>> lost, so you can=E2=80=99t retransmit locally (I t= hink this is totally
>>>>>> independent of the congestion control though=E2=80= =A6)
>>>>>>
>>>>>> Mirja
>>>>>>
>>>>>>
>>>>>>> Am 23.02.2017 um 22:42 schrieb Yoshifumi Nishi= da
>>>>>>> <= nishida@sfc.wide.ad.jp>:
>>>>>>>
>>>>>>> I also think we don't need to make special= recommendations. But, if
>>>>>>> the
>>>>>>> dirty hacks include transparent PEPs, I guess = it will be difficult
>>>>>>> to do
>>>>>>> with QUIC.
>>>>>>> --
>>>>>>> Yoshi
>>>>>>>
>>>>>>> On Thu, Feb 23, 2017 at 10:31 AM, Jana Iyengar= <jri@google.com>
>>>>>>> wrote:
>>>>>>> Hi Watson,
>>>>>>>
>>>>>>> The current plan is to write up NewReno as the= congestion
>>>>>>> controller for
>>>>>>> QUIC. I don't think we need to make specia= l recommendations for
>>>>>>> networks
>>>>>>> with large BDPs in terms of congestion control= , since QUIC can use
>>>>>>> the same
>>>>>>> congestion controller as TCP for these network= s. Specifically, if
>>>>>>> you have
>>>>>>> dirty hacks that you use to make TCP (with New= Reno or Cubic) work,
>>>>>>> you ought
>>>>>>> to be able to do the same trickery with QUIC.<= br> >>>>>>>
>>>>>>> (I can't think of new multiplexing recomme= ndations for these
>>>>>>> networks.)
>>>>>>>
>>>>>>> - jana
>>>>>>>
>>>>>>> On Thu, Feb 23, 2017 at 10:17 AM, Watson Ladd = <watsonbladd@gmail.com><= br> >>>>>>> wrote:
>>>>>>> Dear all,
>>>>>>>
>>>>>>> I'm not that familiar with the state of pl= ay here, but in the future
>>>>>>> we will have more and more LFN network connect= ions (long fat pipe:
>>>>>>> high bandwidth-delay product with long delays)= , as well as wireless
>>>>>>> networks where packet losses are not necessari= ly due to contention on
>>>>>>> the shared channel.
>>>>>>>
>>>>>>> My understanding is currently we have a bunch = of dirty hacks (like
>>>>>>> locally resending data over the lossy bit) to = make this work, a lot
>>>>>>> of
>>>>>>> which will stop working with QUIC.=C2=A0 What = can we recommend for
>>>>>>> congestion control algorithms and multiplexing= use to alleviate the
>>>>>>> problems?
>>>>>>>
>>>>>>> Sincerely,
>>>>>>> Watson
>>>>>>>
>>>>>>>
>>>>>>>
>>>>
>>>>
>>>
>>
>> Normally new=C2=A0 congestion control methods need to be reviewed = by ICCRG
>> before they are progressed by a TSV working group. Have any of the= se
>> algorithms being presented to the IETF (point me please to present= ations i
>> can look at).=C2=A0 I'm assuming the same applies for QUIC als= o when it comes to
>> this sort change?
>>
>> Gorry
>>
>



--
"Man is born free, but everywhere he is in chains".
--Rousseau.

--001a114e19b066904305494ca131-- From nobody Fri Feb 24 13:20:24 2017 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 D81DF1294F8 for ; Fri, 24 Feb 2017 13:20:21 -0800 (PST) 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, 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 (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OE_y6r1B6bsr for ; Fri, 24 Feb 2017 13:20:19 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB1B1129511 for ; Fri, 24 Feb 2017 13:20:18 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id r45so26920159qte.3 for ; Fri, 24 Feb 2017 13:20:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3gR0F+CGDVCfv8BDGbBHBezN0EzCPCC8ICTBb33wXz8=; b=I2ciQK+tvEaokNJpvezrt/GXG9vjwbpCykvljIDTwek8leLkmDZjgZsWGfjZjMIQ+i Oa00Cho/v/SnwhxnTpKj/KqoF9PUxdEdWSQ+3R/LpvBFUTje76BzaNYMVls4fZWquVof 6aiT39B1TXB1WIa47tYdjEyAGvtWwJf9Knd8E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3gR0F+CGDVCfv8BDGbBHBezN0EzCPCC8ICTBb33wXz8=; b=Jpx0F2z0r/N8a9n/ZMiWIx36l/OxcTZ04N7LoSLokEwTIknzzHgSkf6ZCXReWM+5o/ BVfEulK9Lq8K3HZ3N5nyV42/CVfEHHgYegoSk1oLp8UQ2oPK1r4BhDwxxZSIK+nzgoEt SM9uxL0tL5lhRXPAAjTAO1+zpuNb5irHAQI8GRUVFlbD7JTVLfzVTW/3VhW5WRSuVjGA VTOiqj2nTZwBnLGuzdRzYDAXn3YjW2Tm5IBUqb3zO8Ws5r/OswfMEjSrWHZyl2s13U9+ 21Rl+5QIlwNhs2OaOeaM4FOYKN/xVFD4L81wLVypt0NpftEMYuQqTr7mDfgZ3MeK0DXc xhZA== X-Gm-Message-State: AMke39mjFEqHLzhq34X7sCPGLUfxbLTjeD7HUcOHHOf7ynGENB7Fsu/UhYrmxq86VRBAtnIgH/z6tWgG1OMMqQ== X-Received: by 10.237.46.129 with SMTP id k1mr5504525qtd.135.1487971217736; Fri, 24 Feb 2017 13:20:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Fri, 24 Feb 2017 13:20:17 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: References: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> <8b12ccfe-dd03-60b3-461e-17e0b55a1b86@zinks.de> From: Kyle Rose Date: Fri, 24 Feb 2017 16:20:17 -0500 Message-ID: Subject: Re: Quick Elephants To: Jana Iyengar Content-Type: multipart/alternative; boundary=94eb2c065a60decb6505494d4b90 Archived-At: Cc: "Gorry \(erg\)" , Watson Ladd , IETF QUIC WG , Roland Zink X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 21:20:22 -0000 --94eb2c065a60decb6505494d4b90 Content-Type: text/plain; charset=UTF-8 On Fri, Feb 24, 2017 at 3:32 PM, Jana Iyengar wrote: > There are a lot more congestion controllers in use today than those > standardized. There are about a dozen of these available to any Linux > server today for TCP. This is partly because congestion control does not > need interoperability, and the ones that the IETF ends up documenting are > still Informational (see cubic draft > .) > I didn't think about this during charter-bashing, but is the charter boxing QUIC into a set of congestion control algorithms limited to TCP-style metrics (packets in flight, RTT, etc., plus ECN), and is there any downside to that? A strength of the TCP approach of completely abstracting congestion control is that there is a well-defined space for experimentation, where such experimentation does not require interop. Does QUIC as-proposed provide sufficient feedback from the peer to cover any known or proposed congestion control that (at least in theory) might provide benefit over what is possible with TCP today? Kyle --94eb2c065a60decb6505494d4b90 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Feb 24, 2017 at 3:32 PM, Jana Iyengar <jri@google.com> wrot= e:
There are a lot more congestion controllers in use today than those standa= rdized. There are about a dozen of these available to any Linux server toda= y for TCP. This is partly because congestion control does not need interope= rability, and the ones that the IETF ends up documenting are still Informat= ional (see cubic draft.)

I didn't think about this during charter-bashin= g, but is the charter boxing QUIC into a set of congestion control algorith= ms limited to TCP-style metrics (packets in flight, RTT, etc., plus ECN), a= nd is there any downside to that?

A strength of the TCP approach of = completely abstracting congestion control is that there is a well-defined s= pace for experimentation, where such experimentation does not require inter= op. Does QUIC as-proposed provide sufficient feedback from the peer to cove= r any known or proposed congestion control that (at least in theory) might = provide benefit over what is possible with TCP today?

Kyle

--94eb2c065a60decb6505494d4b90-- From nobody Fri Feb 24 14:39:17 2017 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 DBF7F1294F8; Fri, 24 Feb 2017 14:39:15 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: Subject: quic - Update to a Meeting Session Request for IETF 98 X-Test-IDTracker: no X-IETF-IDTracker: 6.46.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148797595586.3194.8381285317708426448.idtracker@ietfa.amsl.com> Date: Fri, 24 Feb 2017 14:39:15 -0800 Archived-At: Cc: quic@ietf.org, spencerdawkins.ietf@gmail.com, smccammon@amsl.com, quic-chairs@ietf.org X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2017 22:39:16 -0000 An update to a meeting session request has just been submitted by Stephanie McCammon, on behalf of the quic working group. --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Stephanie McCammon Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 250 Conflicts to Avoid: First Priority: irtfopen artarea taps mptcp tcpinc tcpm iccrg tsvwg maprg dispatch httpbis tls saag tsvarea Second Priority: rtcweb webpush acme t2trg People who must be present: Sean Turner Mark Nottingham Janardhan Iyengar Martin Thomson Spencer Dawkins Lars Eggert Mike Bishop Ian Swett Resources Requested: Special Requests: Please ping us if you have agenda pressure, to see if we can give up the second slot. --------------------------------------------------------- From nobody Fri Feb 24 18:05:16 2017 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 552061296B6 for ; Fri, 24 Feb 2017 18:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BaG_MqzolSxI for ; Fri, 24 Feb 2017 18:05:13 -0800 (PST) Received: from mail-ot0-x22a.google.com (mail-ot0-x22a.google.com [IPv6:2607:f8b0:4003:c0f::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 2FDEE1296B5 for ; Fri, 24 Feb 2017 18:05:13 -0800 (PST) Received: by mail-ot0-x22a.google.com with SMTP id k4so25339565otc.0 for ; Fri, 24 Feb 2017 18:05:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BX6iK5UBkodfafp2BIucDU/qxBRyUm0oa4Qm5qzoy6s=; b=jUZ+ZbvfyCCCxFbl5FxdRsb0FUkYzO0AOnfAen+cb0plfpXazaF8M5pS2Efpx7xQvS KtPAKqvZJr2gvDr4kHoBEF3ZX6zI3Yabq5WnJzXFVILaMjJD9geQkFM5p4lPYC0lOb50 //ZbaawMbCR6UAZPDgYbaqORWNzloWw7lDdRClQO0NEz4cBN+CIzH/ashZ5o7Zt4qVLQ Iejo5Lbph+U818K/r6lL5gmRrhZaxusSqBYQj5/g/tYrzxMjRj+xcvOlSbMhnO91xnqj O0PsY6lJsIcP3qZ/8w16uH5vQkfko3wX7u8L/Zmr3Vi3q5pZE2s3ZEZqfcpVxOJZGCDT wSLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BX6iK5UBkodfafp2BIucDU/qxBRyUm0oa4Qm5qzoy6s=; b=BnkbTpgVQBqZpd/JtAHwIyMcpdG5D6N1b6SDpsY0xcorI9w0fq5nHYuLJwwJpqXxpm ryxYW2rK2uniY9HeuXAYdOMV7srTz5yin1AcZJxG8iiHb2U6nQa6+Vx/SdlKUojIg6xT HcYHeeniBaQfz3jV+qVAGSJO9rLsKlAPNUL7+t2AznDW39oW8qzwTAxfybXN1n781+s2 eQ/3U28iSQjpEnc1F7atUydkoRmO6BLIe8EE7/w7XvCc2auiYw2NuxRtfvDnBsi9644c nWCz+SDtFPz8har9FUzxE7SqlH6v29UyuVt/1U7onQQKxB4eM7q3idlqB1eTilWa9Qjv jazA== X-Gm-Message-State: AMke39lXMiRGaRJ7x/6q4H8+Syt/ugXz1XD5n0jVFlc483zet0Luf/Lcd/JQy/qJGbVgzoedR5fVnA8mQ4C6Vw== X-Received: by 10.157.45.100 with SMTP id v91mr2968724ota.102.1487988312317; Fri, 24 Feb 2017 18:05:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.27.72 with HTTP; Fri, 24 Feb 2017 18:05:11 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Sat, 25 Feb 2017 11:05:11 +0900 Message-ID: Subject: Re: Alternate header proposal To: Jana Iyengar Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 02:05:15 -0000 Hi, I generally like the proposed scheme, it looks like much simpler and would be easier to route. That said, I have one question. Under the proposed new scheme, would it be possible to distinguish between a client-generated and a server-generated connection ID? If that is possible, could you please let me know how that should be done? One of the reasons why server-driven connection ID generation is preferred (note that in Tokyo we agreed to abandon the use of client-driven ID generation in favor of server-driven generation) is because server deployments using anycast IPs would like to make the POP identifiers part of the connection ID, so that they would be able to continue serving the connection when packets start arriving at a different POP when the client address changes due to roaming. In such deployment, a POP that receives a QUIC packet will forward the packet to a POP that deems responsible for handling the packet based on the value of the connection ID, unless the packet (by looking at the connection ID) is known to be operable within the POP. The fact means that unless the use of client-generated connection ID is abandoned or unless there is an easy way to distinguish between a client-gerenated and a server-generated connection ID, such deployments would be forced into making contacts between POPs to determine if there is already an established state for an incoming connection ID. This would be especially problematic during connection establishment. One of the motives under the development of QUIC is to reduce time spent in connection establishment. We would not like to see communications between POPs of CDNs (that are located at distinct places around the globe) happening during connection establishment. 2017-02-15 16:05 GMT+09:00 Jana Iyengar : > After discussion with various folks, I have put together an alternate > proposal for packet header organization, described below (also on github > here.) This borrows the long/short header idea from Martin's formulation, > but turns the flags field into a type byte, with only 18 codepoints defined. > This proposal eliminates the need for an explicit magic field, and uses > packet types for directionality of cleartext packets. > > Hope this makes sense, and happy to discuss modifications to this format. > Details can of course be changed, but I'm quite liking the use of a 1-byte > codepoint instead of bits for various fields. > > ------------------- > > QUIC packet headers can be separated into long form and short form headers. > Long form headers are used for version negotiation, connection > establishment, > and public reset packets. Short form headers are version-specific, and are > used > for 1-RTT packets, minimizing their header size. > > While all packets are identified using the same Type octet, headers are > separated into the two categories for two reasons: (i) short form headers > are > only used after version negotiation and establishment of 1-RTT keys, and > (ii) editorial convenience. > > This formulation eschews specific bits indicating the presence of > various fields in favor of an octet indicating one of 256 packet types. > Of these 256 types, this version defines and uses only 18: 6 with long-form > headers for the initial phase of the connection, and 12 with short-form > headers > for after the version negotiation and 1-RTT keys are established. > > > # Long-Form Headers > > ``` > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Connection ID + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number / Proof | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ``` > > These long-form headers are used for anything that doesn't have 1-RTT packet > protection and prior to the completion of version negotiation. Once both > conditions are met, a sender may switch to sending short-form headers. > While inefficient, long headers may also be used for 1-RTT packets. The long > form allows for special packets, such as the version negotiation and the > public > reset packets to be represented in this uniform fixed-length packet format. > > * Octet 0: Packet Type > * 39: Version Negotiation packet > * 3a: Public Reset packet > * 3d: 0-RTT packet > * 3e: Server cleartext packet > * 3f: Client cleartext packet > * 1c: 1-RTT packet with version field, connection ID, > and 2-byte packet number > > The remainder of the packet layout is the same regardless of type, the > difference being what rules for how to fill the values out and their > semantics. > > A client cleartext packet (type = 0x3c) then contains: > * Octets 1-8: connection ID (initially randomly chosen) > * Octets 9-12: version > * Octets 13-16: packet number (low 4 octets, starts at a random 31-bit > value) > * Octets 17+: payload > > The client MUST choose a random value and use it as the Connection ID until > the > server replies with a server-selected connection ID. The client's connection > ID > would have no semantic value, though they might serve to provide proof that > the server received the packet via echoing, see below. > > A server cleartext packet (type = 0x3e) contains: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version (echoed) > * Octets 13-16: packet number (low 4 octets, random 31-bit initial value) > * Octets 17+: payload > > Both 0-RTT and 1-RTT packets with long-form headers contain: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version > * Octets 13-16: packet number (low 4 octets) > * Octets 17+: payload > > A version negotiation packet contains: > * Octets 1-8: connection ID (server-selected value, may be used in a > subsequent > connection to reach the same server) > * Octets 9-12: version (echoed) > * Octets 13-16: proof (first 4 octets of client-selected connection ID) > * Octets 17+: payload = version list > > A public reset packet is sent when the server has no state for a received > packet. A server may therefore have to respond to either a long-form or a > short-form packet. A public reset packet contains: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version > * Octets 13-16: proof (octets 1-5 of received packet) > > Echoing details from the packet in both version negotiation and public reset > provides return routeability (#244), while maintaining a consistent header > shape for all packets. > > > # Short Form Header > > ``` > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Connection ID (optional) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number (1/2/4) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ``` > > The short form header is used after the version and 1-RTT keys are > negotiated. > The short form header is defined to be specific to a version. In this > version, > bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, > resulting > in the following packet types. > * Octet 0: Packet Type > * 04 and 84: 1-RTT packet (packet number size = 1) > * 14 and 94: 1-RTT packet (packet number size = 2) > * 34 and b4: 1-RTT packet (packet number size = 4) > * 0c and 8c: 1-RTT packet with Connection ID (packet number size = 1) > * 1c and 9c: 1-RTT packet with Connection ID (packet number size = 2) > * 3c and bc: 1-RTT packet with Connection ID (packet number size = 4) > -- Kazuho Oku From nobody Sat Feb 25 08:19:34 2017 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 82B2F12A142 for ; Sat, 25 Feb 2017 08:19:33 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 3POAEqR2Wb-I for ; Sat, 25 Feb 2017 08:19:31 -0800 (PST) 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 B405F12A141 for ; Sat, 25 Feb 2017 08:19:31 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id v200so21324459ywc.3 for ; Sat, 25 Feb 2017 08:19:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pppabY2xm8jj0I+AO+3aKVzqgqHherhnXilqAChslN4=; b=cCLhOZntnfcmuBlbjjxHafux5t6LyRu5DkTupIHHCf4RZ1iac4/YuH4GbC1IoBBHHE UvqgD0giQbKFhTkQtkveooh5BjfBcA//PyqiF+R27O2xODhkW8flD0FYjbv6GVRIPu6+ /u1+Tf9suWxmkfnxrHtkqSDXh5E7MioM7ryRew54KJr86NpYvzT/mxby0AJG29piKVxy 7Cbg0Jr+RspEY55Iie3s7FtgmLWOlGSITA+OaWPngSABz41RDTgkvKknU0Uwbf3CrTw/ Q5hqqGTRHPbQ/zruvYq/SWcpvHu0BKiXyjF8rYbUNLZEv0M4+ZhGsWTO3Rltm4UpBFMD CnzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pppabY2xm8jj0I+AO+3aKVzqgqHherhnXilqAChslN4=; b=MX92uDeorFfqzE/46pAiusnfn5tQNRFXuuHSLfuRbonc9WQCQrSwr4xi3zLSbx1npq 1LncupnBIquPWqOQ9cr5IzLhRKlpVmV9Pmsd55OhUi/ai1BHogzLHqvIUjgbTHJaGyyp OLzHK74Zq1EXx4Y27vXBBNMqBjtrn5Pu5mYmXu57B+/XxdeZY5Me4RtRB/IHnCIkD+Cu u7+eL2NuHkk+qOsFh833RgFMOAMVG0pVEfJJu/68WaVMs1TX+5rP2Mcu7VTqbaJ0FBCd GD6Xl9/ftf4Aq2oRIl7moQsqwY3REttKOQtDfYVZCYHbOv2Gz+NLyU0zPNOTgluz8iDc rrfA== X-Gm-Message-State: AMke39ls0RRJ8IqQ+PXZPr/uSQpRkCa8G2Yon2M7A+2FBONEwCgjF+3wT3RR7kWlBHLymC6UjV+WsrFGhmMdlPYr X-Received: by 10.129.125.5 with SMTP id y5mr3307481ywc.120.1488039570585; Sat, 25 Feb 2017 08:19:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.50.139 with HTTP; Sat, 25 Feb 2017 08:19:09 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Sat, 25 Feb 2017 11:19:09 -0500 Message-ID: Subject: Re: Alternate header proposal To: Kazuho Oku Content-Type: multipart/alternative; boundary=001a1149364404abb105495d3665 Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 16:19:33 -0000 --001a1149364404abb105495d3665 Content-Type: text/plain; charset=UTF-8 I'm not sure this fully solves your issue, but I don't believe QUIC will allow port or IP migration during the handshake, so landing at a different POP is only an issue to deal with once 1RTT keys are available. Possibly you can do conventional IP/port load balancing on all long form unprotected client packets, and then switch to using connection ID on all short form packets? Alternately, if only the SHLO could change the connection ID, then all(except Finished?) unprotected client to server packets would use the client's connection ID and the change of connection ID would follow the change to 1RTT keys. I don't think the rules on when a server can change the connection ID are fully fleshed out yet. On Fri, Feb 24, 2017 at 9:05 PM, Kazuho Oku wrote: > Hi, > > I generally like the proposed scheme, it looks like much simpler and > would be easier to route. > > That said, I have one question. > > Under the proposed new scheme, would it be possible to distinguish > between a client-generated and a server-generated connection ID? If > that is possible, could you please let me know how that should be > done? > > One of the reasons why server-driven connection ID generation is > preferred (note that in Tokyo we agreed to abandon the use of > client-driven ID generation in favor of server-driven generation) is > because server deployments using anycast IPs would like to make the > POP identifiers part of the connection ID, so that they would be able > to continue serving the connection when packets start arriving at a > different POP when the client address changes due to roaming. > > In such deployment, a POP that receives a QUIC packet will forward the > packet to a POP that deems responsible for handling the packet based > on the value of the connection ID, unless the packet (by looking at > the connection ID) is known to be operable within the POP. > > The fact means that unless the use of client-generated connection ID > is abandoned or unless there is an easy way to distinguish between a > client-gerenated and a server-generated connection ID, such > deployments would be forced into making contacts between POPs to > determine if there is already an established state for an incoming > connection ID. > > This would be especially problematic during connection establishment. > One of the motives under the development of QUIC is to reduce time > spent in connection establishment. We would not like to see > communications between POPs of CDNs (that are located at distinct > places around the globe) happening during connection establishment. > > 2017-02-15 16:05 GMT+09:00 Jana Iyengar : > > After discussion with various folks, I have put together an alternate > > proposal for packet header organization, described below (also on github > > here.) This borrows the long/short header idea from Martin's formulation, > > but turns the flags field into a type byte, with only 18 codepoints > defined. > > This proposal eliminates the need for an explicit magic field, and uses > > packet types for directionality of cleartext packets. > > > > Hope this makes sense, and happy to discuss modifications to this format. > > Details can of course be changed, but I'm quite liking the use of a > 1-byte > > codepoint instead of bits for various fields. > > > > ------------------- > > > > QUIC packet headers can be separated into long form and short form > headers. > > Long form headers are used for version negotiation, connection > > establishment, > > and public reset packets. Short form headers are version-specific, and > are > > used > > for 1-RTT packets, minimizing their header size. > > > > While all packets are identified using the same Type octet, headers are > > separated into the two categories for two reasons: (i) short form headers > > are > > only used after version negotiation and establishment of 1-RTT keys, and > > (ii) editorial convenience. > > > > This formulation eschews specific bits indicating the presence of > > various fields in favor of an octet indicating one of 256 packet types. > > Of these 256 types, this version defines and uses only 18: 6 with > long-form > > headers for the initial phase of the connection, and 12 with short-form > > headers > > for after the version negotiation and 1-RTT keys are established. > > > > > > # Long-Form Headers > > > > ``` > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+ > > | Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > + Connection ID + > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Version | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Packet Number / Proof | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ``` > > > > These long-form headers are used for anything that doesn't have 1-RTT > packet > > protection and prior to the completion of version negotiation. Once both > > conditions are met, a sender may switch to sending short-form headers. > > While inefficient, long headers may also be used for 1-RTT packets. The > long > > form allows for special packets, such as the version negotiation and the > > public > > reset packets to be represented in this uniform fixed-length packet > format. > > > > * Octet 0: Packet Type > > * 39: Version Negotiation packet > > * 3a: Public Reset packet > > * 3d: 0-RTT packet > > * 3e: Server cleartext packet > > * 3f: Client cleartext packet > > * 1c: 1-RTT packet with version field, connection ID, > > and 2-byte packet number > > > > The remainder of the packet layout is the same regardless of type, the > > difference being what rules for how to fill the values out and their > > semantics. > > > > A client cleartext packet (type = 0x3c) then contains: > > * Octets 1-8: connection ID (initially randomly chosen) > > * Octets 9-12: version > > * Octets 13-16: packet number (low 4 octets, starts at a random 31-bit > > value) > > * Octets 17+: payload > > > > The client MUST choose a random value and use it as the Connection ID > until > > the > > server replies with a server-selected connection ID. The client's > connection > > ID > > would have no semantic value, though they might serve to provide proof > that > > the server received the packet via echoing, see below. > > > > A server cleartext packet (type = 0x3e) contains: > > * Octets 1-8: connection ID (server-selected value) > > * Octets 9-12: version (echoed) > > * Octets 13-16: packet number (low 4 octets, random 31-bit initial value) > > * Octets 17+: payload > > > > Both 0-RTT and 1-RTT packets with long-form headers contain: > > * Octets 1-8: connection ID (server-selected value) > > * Octets 9-12: version > > * Octets 13-16: packet number (low 4 octets) > > * Octets 17+: payload > > > > A version negotiation packet contains: > > * Octets 1-8: connection ID (server-selected value, may be used in a > > subsequent > > connection to reach the same server) > > * Octets 9-12: version (echoed) > > * Octets 13-16: proof (first 4 octets of client-selected connection ID) > > * Octets 17+: payload = version list > > > > A public reset packet is sent when the server has no state for a received > > packet. A server may therefore have to respond to either a long-form or a > > short-form packet. A public reset packet contains: > > * Octets 1-8: connection ID (server-selected value) > > * Octets 9-12: version > > * Octets 13-16: proof (octets 1-5 of received packet) > > > > Echoing details from the packet in both version negotiation and public > reset > > provides return routeability (#244), while maintaining a consistent > header > > shape for all packets. > > > > > > # Short Form Header > > > > ``` > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+ > > | Type | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > + Connection ID (optional) + > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Packet Number (1/2/4) | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Payload ... > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > ``` > > > > The short form header is used after the version and 1-RTT keys are > > negotiated. > > The short form header is defined to be specific to a version. In this > > version, > > bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, > > resulting > > in the following packet types. > > * Octet 0: Packet Type > > * 04 and 84: 1-RTT packet (packet number size = 1) > > * 14 and 94: 1-RTT packet (packet number size = 2) > > * 34 and b4: 1-RTT packet (packet number size = 4) > > * 0c and 8c: 1-RTT packet with Connection ID (packet number size = 1) > > * 1c and 9c: 1-RTT packet with Connection ID (packet number size = 2) > > * 3c and bc: 1-RTT packet with Connection ID (packet number size = 4) > > > > > > -- > Kazuho Oku > > --001a1149364404abb105495d3665 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm not sure this fully solves your issue, but I = don't believe QUIC will allow port or IP migration during the handshake= , so landing at a different POP is only an issue to deal with once 1RTT key= s are available.

Possibly you can do conventio= nal IP/port load balancing on all long form unprotected client packets, and= then switch to using connection ID on all short form packets?
Alternately, if only the SHLO could change the connection ID, = then all(except Finished?) unprotected client to server packets would use t= he client's connection ID and the change of connection ID would follow = the change to 1RTT keys.=C2=A0 I don't think the rules on when a server= can change the connection ID are fully fleshed out yet.

On Fri, Feb 24, 2017 at = 9:05 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
Hi,

I generally like the proposed scheme, it looks like much simpler and
would be easier to route.

That said, I have one question.

Under the proposed new scheme, would it be possible to distinguish
between a client-generated and a server-generated connection ID? If
that is possible, could you please let me know how that should be
done?

One of the reasons why server-driven connection ID generation is
preferred (note that in Tokyo we agreed to abandon the use of
client-driven ID generation in favor of server-driven generation) is
because server deployments using anycast IPs would like to make the
POP identifiers part of the connection ID, so that they would be able
to continue serving the connection when packets start arriving at a
different POP when the client address changes due to roaming.

In such deployment, a POP that receives a QUIC packet will forward the
packet to a POP that deems responsible for handling the packet based
on the value of the connection ID, unless the packet (by looking at
the connection ID) is known to be operable within the POP.

The fact means that unless the use of client-generated connection ID
is abandoned or unless there is an easy way to distinguish between a
client-gerenated and a server-generated connection ID, such
deployments would be forced into making contacts between POPs to
determine if there is already an established state for an incoming
connection ID.

This would be especially problematic during connection establishment.
One of the motives under the development of QUIC is to reduce time
spent in connection establishment. We would not like to see
communications between POPs of CDNs (that are located at distinct
places around the globe) happening during connection establishment.

2017-02-15 16:05 GMT+09:00 Jana Iyengar <jri@google.com>:
> After discussion with various folks, I have put together an alternate<= br> > proposal for packet header organization, described below (also on gith= ub
> here.) This borrows the long/short header idea from Martin's formu= lation,
> but turns the flags field into a type byte, with only 18 codepoints de= fined.
> This proposal eliminates the need for an explicit magic field, and use= s
> packet types for directionality of cleartext packets.
>
> Hope this makes sense, and happy to discuss modifications to this form= at.
> Details can of course be changed, but I'm quite liking the use of = a 1-byte
> codepoint instead of bits for various fields.
>
> -------------------
>
> QUIC packet headers can be separated into long form and short form hea= ders.
> Long form headers are used for version negotiation, connection
> establishment,
> and public reset packets. Short form headers are version-specific, and= are
> used
> for 1-RTT packets, minimizing their header size.
>
> While all packets are identified using the same Type octet, headers ar= e
> separated into the two categories for two reasons: (i) short form head= ers
> are
> only used after version negotiation and establishment of 1-RTT keys, a= nd
> (ii) editorial convenience.
>
> This formulation eschews specific bits indicating the presence of
> various fields in favor of an octet indicating one of 256 packet types= .
> Of these 256 types, this version defines and uses only 18: 6 with long= -form
> headers for the initial phase of the connection, and 12 with short-for= m
> headers
> for after the version negotiation and 1-RTT keys are established.
>
>
> # Long-Form Headers
>
> ```
>=C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03<= br> >=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<= br> > +-+-+-+-+-+-+-+-+
> |=C2=A0 =C2=A0 =C2=A0Type=C2=A0 =C2=A0 =C2=A0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 Connection ID=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Version=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Packet= Number / Proof=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Payload=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 ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> ```
>
> These long-form headers are used for anything that doesn't have 1-= RTT packet
> protection and prior to the completion of version negotiation. Once bo= th
> conditions are met, a sender may switch to sending short-form headers.=
> While inefficient, long headers may also be used for 1-RTT packets. Th= e long
> form allows for special packets, such as the version negotiation and t= he
> public
> reset packets to be represented in this uniform fixed-length packet fo= rmat.
>
> * Octet 0: Packet Type
>=C2=A0 =C2=A0* 39: Version Negotiation packet
>=C2=A0 =C2=A0* 3a: Public Reset packet
>=C2=A0 =C2=A0* 3d: 0-RTT packet
>=C2=A0 =C2=A0* 3e: Server cleartext packet
>=C2=A0 =C2=A0* 3f: Client cleartext packet
>=C2=A0 =C2=A0* 1c: 1-RTT packet with version field, connection ID,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0and 2-byte packet number
>
> The remainder of the packet layout is the same regardless of type, the=
> difference being what rules for how to fill the values out and their > semantics.
>
> A client cleartext packet (type =3D 0x3c) then contains:
> * Octets 1-8: connection ID (initially randomly chosen)
> * Octets 9-12: version
> * Octets 13-16: packet number (low 4 octets, starts at a random 31-bit=
> value)
> * Octets 17+: payload
>
> The client MUST choose a random value and use it as the Connection ID = until
> the
> server replies with a server-selected connection ID. The client's = connection
> ID
> would have no semantic value, though they might serve to provide proof= that
> the server received the packet via echoing, see below.
>
> A server cleartext packet (type =3D 0x3e) contains:
> * Octets 1-8: connection ID (server-selected value)
> * Octets 9-12: version (echoed)
> * Octets 13-16: packet number (low 4 octets, random 31-bit initial val= ue)
> * Octets 17+: payload
>
> Both 0-RTT and 1-RTT packets with long-form headers contain:
> * Octets 1-8: connection ID (server-selected value)
> * Octets 9-12: version
> * Octets 13-16: packet number (low 4 octets)
> * Octets 17+: payload
>
> A version negotiation packet contains:
> * Octets 1-8: connection ID (server-selected value, may be used in a > subsequent
>=C2=A0 =C2=A0connection to reach the same server)
> * Octets 9-12: version (echoed)
> * Octets 13-16: proof (first 4 octets of client-selected connection ID= )
> * Octets 17+: payload =3D version list
>
> A public reset packet is sent when the server has no state for a recei= ved
> packet. A server may therefore have to respond to either a long-form o= r a
> short-form packet. A public reset packet contains:
> * Octets 1-8: connection ID (server-selected value)
> * Octets 9-12: version
> * Octets 13-16: proof (octets 1-5 of received packet)
>
> Echoing details from the packet in both version negotiation and public= reset
> provides return routeability (#244), while maintaining a consistent he= ader
> shape for all packets.
>
>
> # Short Form Header
>
> ```
>=C2=A0 0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A01=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A03<= br> >=C2=A0 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<= br> > +-+-+-+-+-+-+-+-+
> |=C2=A0 =C2=A0 =C2=A0 Type=C2=A0 =C2=A0 =C2=A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Connection ID (optional)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 +
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0Packet Number (1/2/4)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Payload=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 ...
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+
> ```
>
> The short form header is used after the version and 1-RTT keys are
> negotiated.
> The short form header is defined to be specific to a version. In this<= br> > version,
> bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, > resulting
> in the following packet types.
> * Octet 0: Packet Type
>=C2=A0 =C2=A0* 04 and 84: 1-RTT packet (packet number size =3D 1)
>=C2=A0 =C2=A0* 14 and 94: 1-RTT packet (packet number size =3D 2)
>=C2=A0 =C2=A0* 34 and b4: 1-RTT packet (packet number size =3D 4)
>=C2=A0 =C2=A0* 0c and 8c: 1-RTT packet with Connection ID (packet numbe= r size =3D 1)
>=C2=A0 =C2=A0* 1c and 9c: 1-RTT packet with Connection ID (packet numbe= r size =3D 2)
>=C2=A0 =C2=A0* 3c and bc: 1-RTT packet with Connection ID (packet numbe= r size =3D 4)
>



--
Kazuho Oku


--001a1149364404abb105495d3665-- From nobody Sat Feb 25 09:51:51 2017 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 DBB1F129454 for ; Sat, 25 Feb 2017 09:51:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZDzGwWTAkzYw for ; Sat, 25 Feb 2017 09:51:48 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (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 CE65F12A1E7 for ; Sat, 25 Feb 2017 09:51:48 -0800 (PST) Received: from mbp-4.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id v1PHoxJe055930 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT); Sat, 25 Feb 2017 17:50:59 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mbp-4.local Subject: Re: Quick Elephants To: Watson Ladd , Jana Iyengar References: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> <8b12ccfe-dd03-60b3-461e-17e0b55a1b86@zinks.de> From: joel jaeggli Message-ID: Date: Sat, 25 Feb 2017 09:50:53 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="xD7nbPErmM8fcR0PwtX9D02Dl4m3ao9Sv" Archived-At: Cc: "Gorry \(erg\)" , IETF QUIC WG , Roland Zink X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 17:51:50 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xD7nbPErmM8fcR0PwtX9D02Dl4m3ao9Sv Content-Type: multipart/mixed; boundary="kIBcATOMvrHiJMvauxNTd1Obs1Vtewm2D"; protected-headers="v1" From: joel jaeggli To: Watson Ladd , Jana Iyengar Cc: "Gorry (erg)" , IETF QUIC WG , Roland Zink Message-ID: Subject: Re: Quick Elephants References: <1AE3E096-9538-40E2-B6BD-E5F5FA5641C5@tik.ee.ethz.ch> <5feb7d0b-1410-50ba-f3a1-76a57562c187@zinks.de> <8b12ccfe-dd03-60b3-461e-17e0b55a1b86@zinks.de> In-Reply-To: --kIBcATOMvrHiJMvauxNTd1Obs1Vtewm2D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2/24/17 12:12 PM, Watson Ladd wrote: > On Fri, Feb 24, 2017 at 9:43 AM, Jana Iyengar wrote: >> The charter says: >> >> "Work on congestion control will describe use of a >> standardized congestion controller as a default scheme for >> QUIC. Defining new congestion control schemes is explicitly out of >> scope for this group." >> >> The current plan is to describe NewReno for QUIC in >> draft-ietf-quic-recovery. If there's interest in writing a Cubic for Q= UIC >> document after the cubic doc is finished in TCPM, I'd be fine with tha= t >> being a later additional doc. > After 12 years since Cubic escaped onto the Internet and was used by > default in Linux, it still isn't standardized... I imagine Google's > new one isn't going to even start. > http://queue.acm.org/detail.cfm?id=3D3022184 > >> Subsequent non-standardized controllers however should follow a simila= r >> process as we expect for TCP today. At any rate, this won't appear in = any of >> the current QUIC wg documents unless we re-charter. > Ah, I hadn't realized that there were no loss-tolerant control > protocols standardized yet. I guess we're going to be stuck with this > wireless problem then, absent some creative vendor solutions (like > per-packet acks? aggressive coding?). What can we do to help some of > these solutions? 802.11foo variants feature reliable delivery for unicast traffic even when you wish they wouldn't. --kIBcATOMvrHiJMvauxNTd1Obs1Vtewm2D-- --xD7nbPErmM8fcR0PwtX9D02Dl4m3ao9Sv Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iEYEARECAAYFAlixw/0ACgkQ8AA1q7Z/VrKiNQCdGATkfjgZ5OdLkryZ3seNBX0T q6AAn2OxJvKcBD7xiqtSg1gWdtw+gEn7 =X/AX -----END PGP SIGNATURE----- --xD7nbPErmM8fcR0PwtX9D02Dl4m3ao9Sv-- From nobody Sat Feb 25 09:55:34 2017 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 8E4C4128DF6 for ; Sat, 25 Feb 2017 09:55:32 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 BmDzHg4Zgttg for ; Sat, 25 Feb 2017 09:55:29 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id B341D1289C4 for ; Sat, 25 Feb 2017 09:55:29 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F33FA16C061; Sat, 25 Feb 2017 17:55:28 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id D251416BE88; Sat, 25 Feb 2017 17:55:28 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488045328; bh=Xr31+0e08ALwyzyx6m/6i4mceu5tvFeKJXxFugFDRIM=; l=27227; h=From:To:CC:Date:References:In-Reply-To:From; b=fRkUIjmtS0/SrfyCZTImsdLPbZfmFaH2DXxvUui01L6CYxt+Zz3muvHG0DZI7KR7L y7DTqI7LAn3a78B9Mz/gilEhsbxOzbaXzhG3GKBblQ1OCL53jQL7d3NfJ9jGPVbP7D rP1SrOuvF4h5A+Tc7G0TEyQHIWWkOA+rSa1uX8S8= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 8C98D1E07C; Sat, 25 Feb 2017 17:55:28 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 25 Feb 2017 09:55:27 -0800 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Sat, 25 Feb 2017 12:55:27 -0500 From: "Lubashev, Igor" To: "ianswett@google.com" , "kazuhooku@gmail.com" Subject: RE: Alternate header proposal Thread-Topic: Alternate header proposal Thread-Index: AQHSh1nkMtEA9mJcekOWXtTA1wxkXaF5XE6AgADumID//8cXng== Date: Sat, 25 Feb 2017 17:55:27 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_aaa5f1cab45f4d9ab08b73913ab8280dusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: "jri@google.com" , "quic@ietf.org" X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Feb 2017 17:55:32 -0000 --_000_aaa5f1cab45f4d9ab08b73913ab8280dusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's how I read the proposal, too. The load balancing is stateless (*) on= ly after 1rtt keys are available. Before that, there must be state, so the = availability of connections depends on the packets arriving on the same loa= d balancer before 1 rtt keys are available. We can try hard to ensure that = pre-1rtt packets arriving within a pop are routed to the same load balancer= (if it is still available). If a pre-1rtt packet arrives to a different pop (only a problem for anycast= -routed CDN service, not a problem for DNS-based CDN service), the connecti= on will be reset, and the client needs to try again. - Igor (*) The load balancing will become truly stateless if you encode not just t= he identity of a pop but the identity of the backend server in the connecti= on id. -----Original Message----- From: Ian Swett [ianswett@google.com] Received: Saturday, 25 Feb 2017, 11:19AM To: Kazuho Oku [kazuhooku@gmail.com] CC: Jana Iyengar [jri@google.com]; IETF QUIC WG [quic@ietf.org] Subject: Re: Alternate header proposal I'm not sure this fully solves your issue, but I don't believe QUIC will al= low port or IP migration during the handshake, so landing at a different PO= P is only an issue to deal with once 1RTT keys are available. Possibly you can do conventional IP/port load balancing on all long form un= protected client packets, and then switch to using connection ID on all sho= rt form packets? Alternately, if only the SHLO could change the connection ID, then all(exce= pt Finished?) unprotected client to server packets would use the client's c= onnection ID and the change of connection ID would follow the change to 1RT= T keys. I don't think the rules on when a server can change the connection= ID are fully fleshed out yet. On Fri, Feb 24, 2017 at 9:05 PM, Kazuho Oku > wrote: Hi, I generally like the proposed scheme, it looks like much simpler and would be easier to route. That said, I have one question. Under the proposed new scheme, would it be possible to distinguish between a client-generated and a server-generated connection ID? If that is possible, could you please let me know how that should be done? One of the reasons why server-driven connection ID generation is preferred (note that in Tokyo we agreed to abandon the use of client-driven ID generation in favor of server-driven generation) is because server deployments using anycast IPs would like to make the POP identifiers part of the connection ID, so that they would be able to continue serving the connection when packets start arriving at a different POP when the client address changes due to roaming. In such deployment, a POP that receives a QUIC packet will forward the packet to a POP that deems responsible for handling the packet based on the value of the connection ID, unless the packet (by looking at the connection ID) is known to be operable within the POP. The fact means that unless the use of client-generated connection ID is abandoned or unless there is an easy way to distinguish between a client-gerenated and a server-generated connection ID, such deployments would be forced into making contacts between POPs to determine if there is already an established state for an incoming connection ID. This would be especially problematic during connection establishment. One of the motives under the development of QUIC is to reduce time spent in connection establishment. We would not like to see communications between POPs of CDNs (that are located at distinct places around the globe) happening during connection establishment. 2017-02-15 16:05 GMT+09:00 Jana Iyengar >: > After discussion with various folks, I have put together an alternate > proposal for packet header organization, described below (also on github > here.) This borrows the long/short header idea from Martin's formulation, > but turns the flags field into a type byte, with only 18 codepoints defin= ed. > This proposal eliminates the need for an explicit magic field, and uses > packet types for directionality of cleartext packets. > > Hope this makes sense, and happy to discuss modifications to this format. > Details can of course be changed, but I'm quite liking the use of a 1-byt= e > codepoint instead of bits for various fields. > > ------------------- > > QUIC packet headers can be separated into long form and short form header= s. > Long form headers are used for version negotiation, connection > establishment, > and public reset packets. Short form headers are version-specific, and ar= e > used > for 1-RTT packets, minimizing their header size. > > While all packets are identified using the same Type octet, headers are > separated into the two categories for two reasons: (i) short form headers > are > only used after version negotiation and establishment of 1-RTT keys, and > (ii) editorial convenience. > > This formulation eschews specific bits indicating the presence of > various fields in favor of an octet indicating one of 256 packet types. > Of these 256 types, this version defines and uses only 18: 6 with long-fo= rm > headers for the initial phase of the connection, and 12 with short-form > headers > for after the version negotiation and 1-RTT keys are established. > > > # Long-Form Headers > > ``` > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Connection ID + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Version | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number / Proof | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ``` > > These long-form headers are used for anything that doesn't have 1-RTT pac= ket > protection and prior to the completion of version negotiation. Once both > conditions are met, a sender may switch to sending short-form headers. > While inefficient, long headers may also be used for 1-RTT packets. The l= ong > form allows for special packets, such as the version negotiation and the > public > reset packets to be represented in this uniform fixed-length packet forma= t. > > * Octet 0: Packet Type > * 39: Version Negotiation packet > * 3a: Public Reset packet > * 3d: 0-RTT packet > * 3e: Server cleartext packet > * 3f: Client cleartext packet > * 1c: 1-RTT packet with version field, connection ID, > and 2-byte packet number > > The remainder of the packet layout is the same regardless of type, the > difference being what rules for how to fill the values out and their > semantics. > > A client cleartext packet (type =3D 0x3c) then contains: > * Octets 1-8: connection ID (initially randomly chosen) > * Octets 9-12: version > * Octets 13-16: packet number (low 4 octets, starts at a random 31-bit > value) > * Octets 17+: payload > > The client MUST choose a random value and use it as the Connection ID unt= il > the > server replies with a server-selected connection ID. The client's connect= ion > ID > would have no semantic value, though they might serve to provide proof th= at > the server received the packet via echoing, see below. > > A server cleartext packet (type =3D 0x3e) contains: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version (echoed) > * Octets 13-16: packet number (low 4 octets, random 31-bit initial value) > * Octets 17+: payload > > Both 0-RTT and 1-RTT packets with long-form headers contain: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version > * Octets 13-16: packet number (low 4 octets) > * Octets 17+: payload > > A version negotiation packet contains: > * Octets 1-8: connection ID (server-selected value, may be used in a > subsequent > connection to reach the same server) > * Octets 9-12: version (echoed) > * Octets 13-16: proof (first 4 octets of client-selected connection ID) > * Octets 17+: payload =3D version list > > A public reset packet is sent when the server has no state for a received > packet. A server may therefore have to respond to either a long-form or a > short-form packet. A public reset packet contains: > * Octets 1-8: connection ID (server-selected value) > * Octets 9-12: version > * Octets 13-16: proof (octets 1-5 of received packet) > > Echoing details from the packet in both version negotiation and public re= set > provides return routeability (#244), while maintaining a consistent heade= r > shape for all packets. > > > # Short Form Header > > ``` > 0 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+ > | Type | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > + Connection ID (optional) + > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Packet Number (1/2/4) | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | Payload ... > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > ``` > > The short form header is used after the version and 1-RTT keys are > negotiated. > The short form header is defined to be specific to a version. In this > version, > bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, > resulting > in the following packet types. > * Octet 0: Packet Type > * 04 and 84: 1-RTT packet (packet number size =3D 1) > * 14 and 94: 1-RTT packet (packet number size =3D 2) > * 34 and b4: 1-RTT packet (packet number size =3D 4) > * 0c and 8c: 1-RTT packet with Connection ID (packet number size =3D 1) > * 1c and 9c: 1-RTT packet with Connection ID (packet number size =3D 2) > * 3c and bc: 1-RTT packet with Connection ID (packet number size =3D 4) > -- Kazuho Oku --_000_aaa5f1cab45f4d9ab08b73913ab8280dusma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That's how I read the proposal, too. The load balancing is= stateless (*) only after 1rtt keys are available. Before that, there must = be state, so the availability of connections depends on the packets arriving on the same load balancer before 1 rtt key= s are available. We can try hard to ensure that pre-1rtt packets arriving w= ithin a pop are routed to the same load balancer (if it is still available)= .

If a pre-1rtt packet arrives to a different pop (only a problem for anycast= -routed CDN service, not a problem for DNS-based CDN service), the connecti= on will be reset, and the client needs to try again.

- Igor

(*) The load balancing will become truly stateless if you encode not just t= he identity of a pop but the identity of the backend server in the connecti= on id.

-----Original Message-----
From: Ian Swett [ianswett@google.com]
Received: Saturday, 25 Feb 2017, 11:19AM
To: Kazuho Oku [kazuhooku@gmail.com]
CC: Jana Iyengar [jri@google.com]; IETF QUIC WG [quic@ietf.org]
Subject: Re: Alternate header proposal
I'm not sure this fully solves your issue, but I don't believe QUIC wi= ll allow port or IP migration during the handshake, so landing at a differe= nt POP is only an issue to deal with once 1RTT keys are available.

Possibly you can do conventional IP/port load balancing on all long fo= rm unprotected client packets, and then switch to using connection ID on al= l short form packets?

Alternately, if only the SHLO could change the connection ID, then all= (except Finished?) unprotected client to server packets would use the clien= t's connection ID and the change of connection ID would follow the change t= o 1RTT keys.  I don't think the rules on when a server can change the connection ID are fully fleshed out = yet.

On Fri, Feb 24, 2017 at 9:05 PM, Kazuho Oku <kazuhooku@gmai= l.com> wrote:
Hi,

I generally like the proposed scheme, it looks like much simpler and
would be easier to route.

That said, I have one question.

Under the proposed new scheme, would it be possible to distinguish
between a client-generated and a server-generated connection ID? If
that is possible, could you please let me know how that should be
done?

One of the reasons why server-driven connection ID generation is
preferred (note that in Tokyo we agreed to abandon the use of
client-driven ID generation in favor of server-driven generation) is
because server deployments using anycast IPs would like to make the
POP identifiers part of the connection ID, so that they would be able
to continue serving the connection when packets start arriving at a
different POP when the client address changes due to roaming.

In such deployment, a POP that receives a QUIC packet will forward the
packet to a POP that deems responsible for handling the packet based
on the value of the connection ID, unless the packet (by looking at
the connection ID) is known to be operable within the POP.

The fact means that unless the use of client-generated connection ID
is abandoned or unless there is an easy way to distinguish between a
client-gerenated and a server-generated connection ID, such
deployments would be forced into making contacts between POPs to
determine if there is already an established state for an incoming
connection ID.

This would be especially problematic during connection establishment.
One of the motives under the development of QUIC is to reduce time
spent in connection establishment. We would not like to see
communications between POPs of CDNs (that are located at distinct
places around the globe) happening during connection establishment.

2017-02-15 16:05 GMT+09:00 Jana Iyengar <jri@google.com>:
> After discussion with various folks, I have put together an alternate<= br> > proposal for packet header organization, described below (also on gith= ub
> here.) This borrows the long/short header idea from Martin's formulati= on,
> but turns the flags field into a type byte, with only 18 codepoints de= fined.
> This proposal eliminates the need for an explicit magic field, and use= s
> packet types for directionality of cleartext packets.
>
> Hope this makes sense, and happy to discuss modifications to this form= at.
> Details can of course be changed, but I'm quite liking the use of a 1-= byte
> codepoint instead of bits for various fields.
>
> -------------------
>
> QUIC packet headers can be separated into long form and short form hea= ders.
> Long form headers are used for version negotiation, connection
> establishment,
> and public reset packets. Short form headers are version-specific, and= are
> used
> for 1-RTT packets, minimizing their header size.
>
> While all packets are identified using the same Type octet, headers ar= e
> separated into the two categories for two reasons: (i) short form head= ers
> are
> only used after version negotiation and establishment of 1-RTT keys, a= nd
> (ii) editorial convenience.
>
> This formulation eschews specific bits indicating the presence of
> various fields in favor of an octet indicating one of 256 packet types= .
> Of these 256 types, this version defines and uses only 18: 6 with long= -form
> headers for the initial phase of the connection, and 12 with short-for= m
> headers
> for after the version negotiation and 1-RTT keys are established.
>
>
> # Long-Form Headers
>
> ```
>  0                  =  1                   = ;2                   3 >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<= br> > +-+-+-+-+-+-+-+-+
> |     Type      |
> +-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+
> |                   =                     &nbs= p;                     &n= bsp;|
> +                  &n= bsp;     Connection ID            &= nbsp;             +
> |                   =                     &nbs= p;                     &n= bsp;|
> +-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+
> |                   =        Version           = ;                  |
> +-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+
> |                  Packet= Number / Proof                &nbs= p;       |
> +-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+
> |                   =         Payload          &nbs= p;               ...
> +-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+
> ```
>
> These long-form headers are used for anything that doesn't have 1-RTT = packet
> protection and prior to the completion of version negotiation. Once bo= th
> conditions are met, a sender may switch to sending short-form headers.=
> While inefficient, long headers may also be used for 1-RTT packets. Th= e long
> form allows for special packets, such as the version negotiation and t= he
> public
> reset packets to be represented in this uniform fixed-length packet fo= rmat.
>
> * Octet 0: Packet Type
>   * 39: Version Negotiation packet
>   * 3a: Public Reset packet
>   * 3d: 0-RTT packet
>   * 3e: Server cleartext packet
>   * 3f: Client cleartext packet
>   * 1c: 1-RTT packet with version field, connection ID,
>         and 2-byte packet number
>
> The remainder of the packet layout is the same regardless of type, the=
> difference being what rules for how to fill the values out and their > semantics.
>
> A client cleartext packet (type =3D 0x3c) then contains:
> * Octets 1-8: connection ID (initially randomly chosen)
> * Octets 9-12: version
> * Octets 13-16: packet number (low 4 octets, starts at a random 31-bit=
> value)
> * Octets 17+: payload
>
> The client MUST choose a random value and use it as the Connection ID = until
> the
> server replies with a server-selected connection ID. The client's conn= ection
> ID
> would have no semantic value, though they might serve to provide proof= that
> the server received the packet via echoing, see below.
>
> A server cleartext packet (type =3D 0x3e) contains:
> * Octets 1-8: connection ID (server-selected value)
> * Octets 9-12: version (echoed)
> * Octets 13-16: packet number (low 4 octets, random 31-bit initial val= ue)
> * Octets 17+: payload
>
> Both 0-RTT and 1-RTT packets with long-form headers contain:
> * Octets 1-8: connection ID (server-selected value)
> * Octets 9-12: version
> * Octets 13-16: packet number (low 4 octets)
> * Octets 17+: payload
>
> A version negotiation packet contains:
> * Octets 1-8: connection ID (server-selected value, may be used in a > subsequent
>   connection to reach the same server)
> * Octets 9-12: version (echoed)
> * Octets 13-16: proof (first 4 octets of client-selected connection ID= )
> * Octets 17+: payload =3D version list
>
> A public reset packet is sent when the server has no state for a recei= ved
> packet. A server may therefore have to respond to either a long-form o= r a
> short-form packet. A public reset packet contains:
> * Octets 1-8: connection ID (server-selected value)
> * Octets 9-12: version
> * Octets 13-16: proof (octets 1-5 of received packet)
>
> Echoing details from the packet in both version negotiation and public= reset
> provides return routeability (#244), while maintaining a consistent he= ader
> shape for all packets.
>
>
> # Short Form Header
>
> ```
>  0                  =  1                   = ;2                   3 >  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<= br> > +-+-+-+-+-+-+-+-+
> |      Type     |
> +-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+
> |                   =                     &nbs= p;                     &n= bsp;|
> +                  &n= bsp;Connection ID (optional)             = ;       +
> |                   =                     &nbs= p;                     &n= bsp;|
> +-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+
> |                   =  Packet Number (1/2/4)             = ;        |
> +-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+
> |                   =         Payload          &nbs= p;               ...
> +-+-+-+-+-+-+-+-+-+-+-+= ;-+-+-+-+-+-+-+-+-+-+-+-&#= 43;-+-+-+-+-+-+-+-+-+
> ```
>
> The short form header is used after the version and 1-RTT keys are
> negotiated.
> The short form header is defined to be specific to a version. In this<= br> > version,
> bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, > resulting
> in the following packet types.
> * Octet 0: Packet Type
>   * 04 and 84: 1-RTT packet (packet number size =3D 1)
>   * 14 and 94: 1-RTT packet (packet number size =3D 2)
>   * 34 and b4: 1-RTT packet (packet number size =3D 4)
>   * 0c and 8c: 1-RTT packet with Connection ID (packet numbe= r size =3D 1)
>   * 1c and 9c: 1-RTT packet with Connection ID (packet numbe= r size =3D 2)
>   * 3c and bc: 1-RTT packet with Connection ID (packet numbe= r size =3D 4)
>



--
Kazuho Oku


--_000_aaa5f1cab45f4d9ab08b73913ab8280dusma1exdag1mb5msgcorpak_-- From nobody Sun Feb 26 21:36:02 2017 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 B2A9112986E for ; Sun, 26 Feb 2017 21:36:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cizcjkcb9DUi for ; Sun, 26 Feb 2017 21:36:00 -0800 (PST) Received: from mail-ot0-x229.google.com (mail-ot0-x229.google.com [IPv6:2607:f8b0:4003:c0f::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 43A431293F4 for ; Sun, 26 Feb 2017 21:36:00 -0800 (PST) Received: by mail-ot0-x229.google.com with SMTP id k4so45304923otc.0 for ; Sun, 26 Feb 2017 21:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=93Om1/OSOfxuOxN27OocUm0NJUDN6p061wbfze9IIpY=; b=mh5LVBeRQNmM8t4i/rjkyPKfiZksp7hP2w7iRrXyr2Zr+WeB6SxBdX1jvTb+bnbfi1 o5A4ZvB3R+8jB2RC9PTfUFVPfqDqIBIJBwVqG2VHVT5fhU9SIATQzq4LW+fITRzQnzoi Ki/SiTSLhfvgYv3Ymz1dWSHhjhKrj+ALiub64kAOMf/Y0wtyPAi5/BVCrJ+a+NGbTx3R wYB9ritHRozAYgu1Qz+CDlvQL3PzU0crikE70uUdls0KwK/HGayxJg2wvjRQnnWa8hcS qj3AV/m0qWDPJu8zS+sJMlXw1wxHZXbaBQnEQI/Vhzzc50ko/wbLIo5b83+XhwVv/HDL kwGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=93Om1/OSOfxuOxN27OocUm0NJUDN6p061wbfze9IIpY=; b=OVIRgA3/ZtHhgfL1BSCkIh1B3wBPh2+x7MN4lG/ITVFehHxvlK68BnIc1Z/bnxNvST AGDboYs0D+LLBRAnyOjlF6brsyby0UR9m5SJCjNDsLvyCoN04LIYQA3ap+O/GyaYN65t 0T4ayLpTjoo4TDzDh4rMYf11wMQdrpD9z6tKXY01FKlgTQ1/hfPJfS/KblLeTheX0ETQ sM4oUjlXEfcgMucZ44Utuu3fSJg1nAVNgkcr2QhYjdRrBIo/e/HmANur2t5tKrKnjcuf 85adL/tPM78iqVxoRsdkYQ5eKznkWmobi3/C1YBPbpZFuXR9TftXkVU0pAqpYpJNy2t+ z6xQ== X-Gm-Message-State: AMke39kAFz1C3m7OpGfEL07MtW5fNYTOnJZrd5cjyYZA/qMKHkqvV75+drxoiiNsZAKC8LS6o/qVtxr60RgG7Q== X-Received: by 10.157.42.1 with SMTP id t1mr6916846ota.237.1488173759323; Sun, 26 Feb 2017 21:35:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.27.72 with HTTP; Sun, 26 Feb 2017 21:35:58 -0800 (PST) In-Reply-To: References: From: Kazuho Oku Date: Mon, 27 Feb 2017 14:35:58 +0900 Message-ID: Subject: Re: Alternate header proposal To: Ian Swett , ilubashe@akamai.com Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Jana Iyengar , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 05:36:01 -0000 Ian, Igor, Thank you for your answers. 2017-02-26 1:19 GMT+09:00 Ian Swett : > I'm not sure this fully solves your issue, but I don't believe QUIC will > allow port or IP migration during the handshake, so landing at a different > POP is only an issue to deal with once 1RTT keys are available. > > Possibly you can do conventional IP/port load balancing on all long form > unprotected client packets, and then switch to using connection ID on all > short form packets? > > Alternately, if only the SHLO could change the connection ID, then > all(except Finished?) unprotected client to server packets would use the > client's connection ID and the change of connection ID would follow the > change to 1RTT keys. I don't think the rules on when a server can change > the connection ID are fully fleshed out yet. Yes. I think it would be possible to implement either of the two approaches. I was worrying if we would need to add to the spec. a bit within the connection ID to distinguish between client-generated and server-generated ones. But I am happy to know that, by reading your advice, it seems like that it would be possible to distinguish between the two using the type of the packet. Once this change gets merged, I will try to confirm that such distinction can be made by using the types. Thank you in advance. > On Fri, Feb 24, 2017 at 9:05 PM, Kazuho Oku wrote: >> >> Hi, >> >> I generally like the proposed scheme, it looks like much simpler and >> would be easier to route. >> >> That said, I have one question. >> >> Under the proposed new scheme, would it be possible to distinguish >> between a client-generated and a server-generated connection ID? If >> that is possible, could you please let me know how that should be >> done? >> >> One of the reasons why server-driven connection ID generation is >> preferred (note that in Tokyo we agreed to abandon the use of >> client-driven ID generation in favor of server-driven generation) is >> because server deployments using anycast IPs would like to make the >> POP identifiers part of the connection ID, so that they would be able >> to continue serving the connection when packets start arriving at a >> different POP when the client address changes due to roaming. >> >> In such deployment, a POP that receives a QUIC packet will forward the >> packet to a POP that deems responsible for handling the packet based >> on the value of the connection ID, unless the packet (by looking at >> the connection ID) is known to be operable within the POP. >> >> The fact means that unless the use of client-generated connection ID >> is abandoned or unless there is an easy way to distinguish between a >> client-gerenated and a server-generated connection ID, such >> deployments would be forced into making contacts between POPs to >> determine if there is already an established state for an incoming >> connection ID. >> >> This would be especially problematic during connection establishment. >> One of the motives under the development of QUIC is to reduce time >> spent in connection establishment. We would not like to see >> communications between POPs of CDNs (that are located at distinct >> places around the globe) happening during connection establishment. >> >> 2017-02-15 16:05 GMT+09:00 Jana Iyengar : >> > After discussion with various folks, I have put together an alternate >> > proposal for packet header organization, described below (also on github >> > here.) This borrows the long/short header idea from Martin's >> > formulation, >> > but turns the flags field into a type byte, with only 18 codepoints >> > defined. >> > This proposal eliminates the need for an explicit magic field, and uses >> > packet types for directionality of cleartext packets. >> > >> > Hope this makes sense, and happy to discuss modifications to this >> > format. >> > Details can of course be changed, but I'm quite liking the use of a >> > 1-byte >> > codepoint instead of bits for various fields. >> > >> > ------------------- >> > >> > QUIC packet headers can be separated into long form and short form >> > headers. >> > Long form headers are used for version negotiation, connection >> > establishment, >> > and public reset packets. Short form headers are version-specific, and >> > are >> > used >> > for 1-RTT packets, minimizing their header size. >> > >> > While all packets are identified using the same Type octet, headers are >> > separated into the two categories for two reasons: (i) short form >> > headers >> > are >> > only used after version negotiation and establishment of 1-RTT keys, and >> > (ii) editorial convenience. >> > >> > This formulation eschews specific bits indicating the presence of >> > various fields in favor of an octet indicating one of 256 packet types. >> > Of these 256 types, this version defines and uses only 18: 6 with >> > long-form >> > headers for the initial phase of the connection, and 12 with short-form >> > headers >> > for after the version negotiation and 1-RTT keys are established. >> > >> > >> > # Long-Form Headers >> > >> > ``` >> > 0 1 2 3 >> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> > +-+-+-+-+-+-+-+-+ >> > | Type | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | | >> > + Connection ID + >> > | | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Version | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Packet Number / Proof | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Payload ... >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > ``` >> > >> > These long-form headers are used for anything that doesn't have 1-RTT >> > packet >> > protection and prior to the completion of version negotiation. Once both >> > conditions are met, a sender may switch to sending short-form headers. >> > While inefficient, long headers may also be used for 1-RTT packets. The >> > long >> > form allows for special packets, such as the version negotiation and the >> > public >> > reset packets to be represented in this uniform fixed-length packet >> > format. >> > >> > * Octet 0: Packet Type >> > * 39: Version Negotiation packet >> > * 3a: Public Reset packet >> > * 3d: 0-RTT packet >> > * 3e: Server cleartext packet >> > * 3f: Client cleartext packet >> > * 1c: 1-RTT packet with version field, connection ID, >> > and 2-byte packet number >> > >> > The remainder of the packet layout is the same regardless of type, the >> > difference being what rules for how to fill the values out and their >> > semantics. >> > >> > A client cleartext packet (type = 0x3c) then contains: >> > * Octets 1-8: connection ID (initially randomly chosen) >> > * Octets 9-12: version >> > * Octets 13-16: packet number (low 4 octets, starts at a random 31-bit >> > value) >> > * Octets 17+: payload >> > >> > The client MUST choose a random value and use it as the Connection ID >> > until >> > the >> > server replies with a server-selected connection ID. The client's >> > connection >> > ID >> > would have no semantic value, though they might serve to provide proof >> > that >> > the server received the packet via echoing, see below. >> > >> > A server cleartext packet (type = 0x3e) contains: >> > * Octets 1-8: connection ID (server-selected value) >> > * Octets 9-12: version (echoed) >> > * Octets 13-16: packet number (low 4 octets, random 31-bit initial >> > value) >> > * Octets 17+: payload >> > >> > Both 0-RTT and 1-RTT packets with long-form headers contain: >> > * Octets 1-8: connection ID (server-selected value) >> > * Octets 9-12: version >> > * Octets 13-16: packet number (low 4 octets) >> > * Octets 17+: payload >> > >> > A version negotiation packet contains: >> > * Octets 1-8: connection ID (server-selected value, may be used in a >> > subsequent >> > connection to reach the same server) >> > * Octets 9-12: version (echoed) >> > * Octets 13-16: proof (first 4 octets of client-selected connection ID) >> > * Octets 17+: payload = version list >> > >> > A public reset packet is sent when the server has no state for a >> > received >> > packet. A server may therefore have to respond to either a long-form or >> > a >> > short-form packet. A public reset packet contains: >> > * Octets 1-8: connection ID (server-selected value) >> > * Octets 9-12: version >> > * Octets 13-16: proof (octets 1-5 of received packet) >> > >> > Echoing details from the packet in both version negotiation and public >> > reset >> > provides return routeability (#244), while maintaining a consistent >> > header >> > shape for all packets. >> > >> > >> > # Short Form Header >> > >> > ``` >> > 0 1 2 3 >> > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 >> > +-+-+-+-+-+-+-+-+ >> > | Type | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | | >> > + Connection ID (optional) + >> > | | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Packet Number (1/2/4) | >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > | Payload ... >> > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >> > ``` >> > >> > The short form header is used after the version and 1-RTT keys are >> > negotiated. >> > The short form header is defined to be specific to a version. In this >> > version, >> > bit 0 of the first octet (i.e., 0x80) is used as the key phase bit, >> > resulting >> > in the following packet types. >> > * Octet 0: Packet Type >> > * 04 and 84: 1-RTT packet (packet number size = 1) >> > * 14 and 94: 1-RTT packet (packet number size = 2) >> > * 34 and b4: 1-RTT packet (packet number size = 4) >> > * 0c and 8c: 1-RTT packet with Connection ID (packet number size = 1) >> > * 1c and 9c: 1-RTT packet with Connection ID (packet number size = 2) >> > * 3c and bc: 1-RTT packet with Connection ID (packet number size = 4) >> > >> >> >> >> -- >> Kazuho Oku >> > -- Kazuho Oku From nobody Mon Feb 27 00:58:08 2017 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 C4A8D128824 for ; Mon, 27 Feb 2017 00:58:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=netapp.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnTd-Munv7_U for ; Mon, 27 Feb 2017 00:58:07 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [216.240.21.19]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D7E1299C0 for ; Mon, 27 Feb 2017 00:50:45 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.35,213,1484035200"; d="asc'?scan'208";a="173790241" Received: from hioexcmbx04-prd.hq.netapp.com ([10.122.105.37]) by mx142-out.netapp.com with ESMTP; 27 Feb 2017 00:41:39 -0800 Received: from VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) by hioexcmbx04-prd.hq.netapp.com (10.122.105.37) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 27 Feb 2017 00:50:25 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) with Microsoft SMTP Server (TLS) id 15.0.1210.3 via Frontend Transport; Mon, 27 Feb 2017 00:50:26 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netapp.onmicrosoft.com; s=selector1-netapp-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R7CHd8iTDbO937UT+Bl7otSwIJJgSyI0E/J1glOTMcg=; b=P+YLnhog++neNenVLyyiXb7tp3mi35i3/UcQ0X1qgfqPYcZJ1ugnTBmwC7M6MiGhYMzIW8DkPnIoq/Cx8KNB9T4vip3xDux1jcPSAtbZY4l2QK/oWaOCSv4Hr0ILQZXRsIEMB0B4HnTQQSnq89SERLjnF5WwUx5LEuN30bvMI6U= Received: from BN3PR0601MB1153.namprd06.prod.outlook.com (10.160.157.18) by BN3PR0601MB1155.namprd06.prod.outlook.com (10.160.157.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Mon, 27 Feb 2017 08:50:27 +0000 Received: from BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) by BN3PR0601MB1153.namprd06.prod.outlook.com ([10.160.157.18]) with mapi id 15.01.0933.016; Mon, 27 Feb 2017 08:50:25 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: Chicago meeting; alternative room setup Thread-Topic: Chicago meeting; alternative room setup Thread-Index: AQHSkNaJ3D8B9xl0SUaAd+BpCioF8Q== Date: Mon, 27 Feb 2017 08:50:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [217.70.211.15] x-ms-office365-filtering-correlation-id: 804b8934-087e-42f8-7d20-08d45eedac73 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0601MB1155; x-microsoft-exchange-diagnostics: 1; BN3PR0601MB1155; 7:Uwmc7q34QCjtXpOMCdH7YQ8wY82Vm59tnHJ4GovXlrqct5tGegX9VCMwP5c/LHmnH0eonLydlzBBFFYRNpdaHWepSS7ufzpkQ2yFw/ltYaqmwxCzZusVisikLF8wXjQR6uwxXAUjR41dxF564zpm5qJ1lKqMiPeiRGYLr14E/acdfNvDy4QQ0z0j7+t+BS0V9SeGVOpKVzCL293GQ3VAJ0wM2F2TNmNgaKPXgLABGfLlmN+8jD8+6Gax/U7gLaiuqrCm9N42MNeR2kxDxqAoecrkcxPz0Mi5E4vbh8x0u5PZb+Qo0gvaK6QEuEqvOhzXsQj53t2/PQD7tNyE76YRxg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0601MB1155; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0601MB1155; x-forefront-prvs: 02318D10FB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(39450400003)(199003)(189002)(101416001)(305945005)(6506006)(7736002)(6436002)(105586002)(106356001)(106116001)(5660300001)(68736007)(450100001)(81156014)(8676002)(81166006)(66066001)(33656002)(122556002)(8936002)(2900100001)(50226002)(92566002)(97736004)(82746002)(2906002)(3846002)(38730400002)(110136004)(86362001)(53936002)(102836003)(6116002)(25786008)(36756003)(50986999)(57306001)(6916009)(3660700001)(99286003)(83716003)(189998001)(3280700002)(6512007)(77096006)(99936001)(6486002)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN3PR0601MB1155; H:BN3PR0601MB1153.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: netapp.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail=_44DA033B-F68E-4A5B-8DAB-EEDA22A5B8BF"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2017 08:50:25.6623 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0601MB1155 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2017 08:58:08 -0000 --Apple-Mail=_44DA033B-F68E-4A5B-8DAB-EEDA22A5B8BF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi folks, if you've looked at the agenda, you see that we're currently scheduled = for Thursday, March 30, 2017 in the 9:00-11:30 Thursday Morning slot. As always, this may still move. One thing to note is that we're likely going to be participating in the = "alternative room layout" experiment. Unlike in the regular IETF = "classroom" seating arrangement, this room will have a conference or = U-shape table up front, with space for about 30 people. It will also = have classroom-style seating for about another 120. The idea of the experiment is to get away from the = mic-line-statement-style of interaction, to a more free-flowing = discussion the table, which hopefully will allow for better = communication and faster progress. If you are a regular participant, please do sit at the conference table, = no need to ask. This obviously includes our document editors, folks in = the "contributors" team on GitHub, but also everyone else who expects to = comment on things. If you're in doubt whether you should sit at the = table, sit at the table. There will obviously still be the regular floor mics, and all = contributions carry the same weight and will be recognized in the same = way. The conference table setup is simply an experiment to see if a = different kind of room arrangement would better suit certain WGs. Please do let the chairs and ADs know afterwards if you felt like the = experiment worked out or not, and why! Lars PS: There is also a QUIC Tutorial on Sunday afternoon. If you are new to = QUIC, I highly suggest attending that before coming to the WG meeting. --Apple-Mail=_44DA033B-F68E-4A5B-8DAB-EEDA22A5B8BF Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIcBAEBCgAGBQJYs+hRAAoJEFS1wwm/cMFXOAAQAKXy/m3IgJ36ac+sfNm6PIYx 7gepKmxVFWozOnFRU4ClSmvGmVSKPzzEvTNcCY6RcWRbdAlQ4wUrRZmbE5fAPXLF Xy5biBmX+LP5DRAa5rjVmmDsZYsi53MiFX6TQVya37lzNezFxBQZ2LG/0DHp7rzz 12UZhI3sus7jgB/2Wkt5Wv4zq8S2vUwQyUVo81Ugp9lD9xPXfpO4d/MAWSH81RF+ LlcTkWWqmNfziytWwNjPQtAWxTP5eCrucscoYTAl/QGexwW8eo+ALVHsoeFQwx9Z 1kTgrljMNDQa5AndIO3++TIwV5M/dFcSOOYDrGW3vHVSWZcoGHa5QVbrPqvDQidS cmQg5mz40pznXdw/E25G2FWifKEWUD+fxlWWJ0vjgkG7fwyKhSdeZPB3Ie3b+B4h mpd9l1wZCaqZ1FsuNFI4KThWrpaHY3TzBATy/QN2I1hB3Fry4VDkZBeCxc/SXv4i Dggu1WdB3V+Pl6gY2y03XnvNRJGo98JuJnjobjuX6hEehzyDLN7D4y4vi+AaZRDY 2xvCNjcUTvPtS53Bz69TWY+zIhGjL7QvyX7xgzgdGhFjw+rWtIDgN//8WOMSzFvc zQXvw3bME9O2e/Av+wuC2c0Tot5x44A7i8ExeUAwnEKMlZBkPckEbGXf0MzBzRJf tOHJZAWVsJ4QwsacV2jf =wCvp -----END PGP SIGNATURE----- --Apple-Mail=_44DA033B-F68E-4A5B-8DAB-EEDA22A5B8BF-- From nobody Mon Feb 27 16:30:08 2017 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 4491A12944E for ; Mon, 27 Feb 2017 16:30:07 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 SwJFzeTYUWRh for ; Mon, 27 Feb 2017 16:30:05 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::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 80B0E129467 for ; Mon, 27 Feb 2017 16:30:04 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id v186so73656414wmd.0 for ; Mon, 27 Feb 2017 16:30:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=3Z9x3PiUL7t57h9Jy/g9zC9sE+33aHOzUX3iXfJOjYg=; b=hmiTKed4hSjcKvHYJEwpgA2pM+jFAHKG9zU0Nv/zEYy8tSuwGbDtspYZuQClCz0Va+ Oc9QQ5Ddf96eezHbmu79trJm2oa1GFTFXqQM5JosnWkDTktZZWIKZx40rwspJBb4cSdy ttOl1WHl7tgZ/ktvTDy647j6G1vflWbyG1iFNqzGYXQ6EtvCC6uby/3sFqFvIAb2Z4ke 5226v+J/G2hGKEwx5rx/X7pTClRHYxzuVVjN9ahB2S/8X4vT/LPrKZY0DMIc17ftMn9R uFx+BKjpYIEp/jn5dPDTvfQwIhLj4+RfEBXcfakrHvFXJlPu+3AYh5tTgxW0fIH23PbQ r0AQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=3Z9x3PiUL7t57h9Jy/g9zC9sE+33aHOzUX3iXfJOjYg=; b=UEYU5n6Xq3ugriCtBEzCdcheRfB/oCdjgbGaFcnZpL8OLHXcMTBjynUcPGCVZn3nvX BrRSgRhEDPDtyoLd+3fjFmqrLReSmfKneE55zEolK72MrWQ7cQP0X88QIHl+LXfSwT20 a/Kw49R3wGRKPdiF2+CRZyKA/cNBEkyFxS1bdUW7RaO5mKnSGJV1iZnXDPK+rQXBD5kz feiWFlAA2aVpNwlXnPgHEDjl0zOaIPGRqV0O23utOsXfvJGcsvFEiV0qzf4VMngPvpZ7 wlaihJGHpm2XOLt9++RAB9ombI+BjOMG495xgkv52LeX7iyeGPVS7GTpHli9I9oJKBho 2BxQ== X-Gm-Message-State: AMke39l5flYPqOQ4rbVD3G3mYq0hF33hc1f11/PNdyMptLhhxoVmoq9QAKK0N6VcnSc2Sd8a9O7LDwImknVJT+EB X-Received: by 10.28.109.93 with SMTP id i90mr3529800wmc.44.1488241802724; Mon, 27 Feb 2017 16:30:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.154.139 with HTTP; Mon, 27 Feb 2017 16:30:02 -0800 (PST) From: Ryan Hamilton Date: Mon, 27 Feb 2017 16:30:02 -0800 Message-ID: Subject: When should server-chosen connection IDs be sent and how are they indicated? To: IETF QUIC WG Content-Type: multipart/alternative; boundary=001a1147c434fe344d05498c4b04 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 00:30:07 -0000 --001a1147c434fe344d05498c4b04 Content-Type: text/plain; charset=UTF-8 Howdy All, I just filed issue #349 to resolve how server-chosen connection IDs are to be used. To save a click, here's what I wrote there: -------------------- My sense is that we'd like the server to chose the "real" connection ID to be used for a connection. Among other things, this enables servers to embed routing/load balancing information into connection IDs. I have heard two options for what the client should do before it has a server-chosen connection ID. 1. Send a random connection ID 2. Send a connection ID of 0 If we go with approach 1, then we need some mechanism that load balancers can use to detect if a packet's connection ID is server-chosen or not. It seems likely that all packets encrypted with 1-RTT keys could use server generated connection IDs. But other packets it's not so clear. Consider the case of a non-0-RTT handshake. The initial client handshake packet would include a client-chosen connection ID. When the server replies, it could use a server-chosen connection ID. If so then when the client sends the next handshake packet it could use the server-chosen connection ID as well. But that means that we'd need a mechanism to disambiguate client handshake packets with client-chosen connection IDs from client handshake packets with server-chosen connection IDs. We could devote bits or packet types to indicate this. I suspect the same argument might hold for server handshake packets. We might not want the server to chose a connection ID until it is ready to accept the handshake. One benefit of this approach, however, is that a QUIC server could chose to simply use the client's connection ID for the duration of the connection. This would mean that it would not need to be able to generate a new connection ID that is guaranteed to be sent by the load balancer back to itself. In cases where the vendor of the load balancer and the server are not the same, this might be valuable. If we go with approach 2, then it's obvious that any packet with a non-zero connection ID has a server-chosen connection ID (though the server still may want to verify that it's a "valid" connection ID according to the algorithm it uses). On the other hand, this requires QUIC servers which are behind load balancers to be able to generate connection IDs which the load balancer will route back to them. If the server and load balancers are from different vendors, this might be challenging. -------------------- I look forward to your thoughts. Cheers, Ryan --001a1147c434fe344d05498c4b04 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Howdy All,

I just filed issue #349= =C2=A0to resolve how server-chosen connection IDs are to be used. To save a= click, here's what I wrote there:

--------------------
My sense is that we= 'd like the server to chose the "real" connection ID to be us= ed for a connection. Among other things, this enables servers to embed rout= ing/load balancing information into connection IDs.

I hav= e heard two options for what the client should do before it has a server-ch= osen connection ID.

1. Send a random connection ID<= /div>
2= . Send a connection ID of 0

If we go with approach 1, then= we need some mechanism that load balancers can use to detect if a packet&#= 39;s connection ID is server-chosen or not. It seems likely that all packet= s encrypted with 1-RTT keys could use server generated connection IDs. But = other packets it's not so clear. Consider the case of a non-0-RTT hands= hake. The initial client handshake packet would include a client-chosen con= nection ID. When the server replies, it could use a server-chosen connectio= n ID. If so then when the client sends the next handshake packet it could u= se the server-chosen connection ID as well. But that means that we'd ne= ed a mechanism to disambiguate client handshake packets with client-chosen = connection IDs from client handshake packets with server-chosen connection = IDs. We could devote bits or packet types to indicate this. I suspect the s= ame argument might hold for server handshake packets. We might not want the= server to chose a connection ID until it is ready to accept the handshake.=

One benefit of this approach, however, is that a QUIC ser= ver could chose to simply use the client's connection ID for the durati= on of the connection. This would mean that it would not need to be able to = generate a new connection ID that is guaranteed to be sent by the load bala= ncer back to itself. In cases where the vendor of the load balancer and the= server are not the same, this might be valuable.

If we go= with approach 2, then it's obvious that any packet with a non-zero con= nection ID has a server-chosen connection ID (though the server still may w= ant to verify that it's a "valid" connection ID according to = the algorithm it uses).

On the other hand, this requires Q= UIC servers which are behind load balancers to be able to generate connecti= on IDs which the load balancer will route back to them. If the server and l= oad balancers are from different vendors, this might be challenging.=
--------------------

I look forward to your thoughts.=C2=A0

Cheers,

Ryan
--001a1147c434fe344d05498c4b04-- From nobody Mon Feb 27 17:08:50 2017 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 E5100129469 for ; Mon, 27 Feb 2017 17:08:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z2brl4GNiecV for ; Mon, 27 Feb 2017 17:08:45 -0800 (PST) Received: from mail-ot0-x235.google.com (mail-ot0-x235.google.com [IPv6:2607:f8b0:4003:c0f::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 302911293FD for ; Mon, 27 Feb 2017 17:08:45 -0800 (PST) Received: by mail-ot0-x235.google.com with SMTP id i1so23290862ota.3 for ; Mon, 27 Feb 2017 17:08:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SL1jszXwHdLGYPbOSYxcvsYtlHs5x+mKd/uYOvJKcUc=; b=dPPqBZUgMr86zMb6s8P7fkUU7x00xabDe7kIPBcVpJqeUkRmEoVS3khQaZGxkUJ0gN C+MHragCIhrwXXeK7lkL+divxs6RFFsv0uRY/Rf/DDmm4XCzFg0gsaRO3+q/vEMGne7i e1Q2mCQ6PwV4qILUwS+3Or4KpOtma+1GVj83ZUMTIuD26CKWqgETXJDdlLcpXGeC0nte 0w0HbasYrj1MWJz7eqqhW7ld9FZ5JzDul1BK3Cyvz4hj1P1UiFNVCWEmCm1zEEomPlB7 n/VsMQhNX3uzajiODn2TMDr5Sb+UCjRwNVo5DeKI4+jK7xw/oRqWGADG74OODete9pyA fp0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SL1jszXwHdLGYPbOSYxcvsYtlHs5x+mKd/uYOvJKcUc=; b=dJcdyIXlNOX5VfKhmYYBHiRjhPZDUDM1ZpG6MsCQcr4kCMpgq9CIJ64nA4j9ROMNS6 0bF5LG6juTHmfvjDAJOdWUVxeuZk0kgl/NtLYV7fbXs/SvWM1mkGGcHJMkXBj6OfDYsN o/9u3ZHS3OyBbZW2Y1KIEXLrjqkw1NyJTtUISJ7vcSMqWca/xlSG46ZGFWvDLf1nczAA j66mWgeVo2qrj+acUGuwHCjw5w0qIPgG5ThX15piFKdrdTEJbDfegNmFjgwZF9Uwmu9i XO9LWofxR+JEEjiieoCVinbDstfIt08quInNT3+ekrsd0oayTRBXqpwZ0CzU0/EQLDy6 3cOQ== X-Gm-Message-State: AMke39lW+/nK8vAZ8hssyLO4C6AaB4rd2OwS46HN50q2x55LDidDKCRKOZima3G0KLuPOn3OPQb8Zry3Joa7Jg== X-Received: by 10.157.21.26 with SMTP id u26mr5705569otf.187.1488244124293; Mon, 27 Feb 2017 17:08:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.142.85 with HTTP; Mon, 27 Feb 2017 17:08:13 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Mon, 27 Feb 2017 17:08:13 -0800 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Ryan Hamilton Content-Type: multipart/alternative; boundary=94eb2c1924f45e213105498cd675 Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 01:08:48 -0000 --94eb2c1924f45e213105498cd675 Content-Type: text/plain; charset=UTF-8 Comment in-line. On Mon, Feb 27, 2017 at 4:30 PM, Ryan Hamilton wrote: > Howdy All, > > I just filed issue #349 to > resolve how server-chosen connection IDs are to be used. To save a click, > here's what I wrote there: > > -------------------- > My sense is that we'd like the server to chose the "real" connection ID to > be used for a connection. Among other things, this enables servers to embed > routing/load balancing information into connection IDs. > > I have heard two options for what the client should do before it has a > server-chosen connection ID. > > 1. Send a random connection ID > 2. Send a connection ID of 0 > > If we go with approach 1, then we need some mechanism that load balancers > can use to detect if a packet's connection ID is server-chosen or not. It > seems likely that all packets encrypted with 1-RTT keys could use server > generated connection IDs. But other packets it's not so clear. Consider the > case of a non-0-RTT handshake. The initial client handshake packet would > include a client-chosen connection ID. When the server replies, it could > use a server-chosen connection ID. If so then when the client sends the > next handshake packet it could use the server-chosen connection ID as well. > But that means that we'd need a mechanism to disambiguate client handshake > packets with client-chosen connection IDs from client handshake packets > with server-chosen connection IDs. We could devote bits or packet types to > indicate this. I suspect the same argument might hold for server handshake > packets. We might not want the server to chose a connection ID until it is > ready to accept the handshake. > > One benefit of this approach, however, is that a QUIC server could chose > to simply use the client's connection ID for the duration of the > connection. This would mean that it would not need to be able to generate a > new connection ID that is guaranteed to be sent by the load balancer back > to itself. In cases where the vendor of the load balancer and the server > are not the same, this might be valuable. > > ekr has made a proposal that the server be able to supply multiple connection IDs to a client, so that it can use a fresh connection ID when shifting link origin or engaging in another change where continuing to use the same connection ID would provide linkability. I like that property a lot, but I think that means the QUIC server still needs to be able to generate new connection IDs that are guaranteed to be sent by the load balancer back to itself, even if it retains this connection ID for the duration of the unaltered connection. (Note that sending a fresh connection ID from the pool provided by a server is not enough to avoid linkability; as dkg has pointed out, you'd also have to shift sequence number and watch for other signals). regards, Ted > If we go with approach 2, then it's obvious that any packet with a > non-zero connection ID has a server-chosen connection ID (though the server > still may want to verify that it's a "valid" connection ID according to the > algorithm it uses). > > On the other hand, this requires QUIC servers which are behind load > balancers to be able to generate connection IDs which the load balancer > will route back to them. If the server and load balancers are from > different vendors, this might be challenging. > -------------------- > > I look forward to your thoughts. > > Cheers, > > Ryan > --94eb2c1924f45e213105498cd675 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Comment in-line.

On Mon, Feb 27, 2017 at 4:30 PM, Ryan Hamilton <rch@googl= e.com> wrote:
Howdy Al= l,

=
I just= filed issue #349=C2=A0to resolve how server-chosen connection IDs are t= o be used. To save a click, here's what I wrote there:

--------------------
My sense is that = we'd like the server to chose the "real" connection ID to be = used for a connection. Among other things, this enables servers to embed ro= uting/load balancing information into connection IDs.

I have heard two options for what the client should = do before it has a server-chosen connection ID.

1. Send a random connection ID
2. Send a connection ID of 0

If we go with approach 1, then we need some m= echanism that load balancers can use to detect if a packet's connection= ID is server-chosen or not. It seems likely that all packets encrypted wit= h 1-RTT keys could use server generated connection IDs. But other packets i= t's not so clear. Consider the case of a non-0-RTT handshake. The initi= al client handshake packet would include a client-chosen connection ID. Whe= n the server replies, it could use a server-chosen connection ID. If so the= n when the client sends the next handshake packet it could use the server-c= hosen connection ID as well. But that means that we'd need a mechanism = to disambiguate client handshake packets with client-chosen connection IDs = from client handshake packets with server-chosen connection IDs. We could d= evote bits or packet types to indicate this. I suspect the same argument mi= ght hold for server handshake packets. We might not want the server to chos= e a connection ID until it is ready to accept the handshake.

One benefit of this approach, however, is tha= t a QUIC server could chose to simply use the client's connection ID fo= r the duration of the connection. This would mean that it would not need to= be able to generate a new connection ID that is guaranteed to be sent by t= he load balancer back to itself. In cases where the vendor of the load bala= ncer and the server are not the same, this might be valuable.
<= div>

ekr has made a proposal that the server be a= ble to supply multiple connection IDs to a client, so that it can use a fre= sh connection ID when shifting link origin or engaging in another change wh= ere continuing to use the same connection ID would provide linkability.=C2= =A0 I like that property a lot, but I think that means the QUIC server stil= l needs to be able to generate new connection IDs that are guaranteed to be= sent by the load balancer back to itself, even if it retains this connecti= on ID for the duration of the unaltered connection.=C2=A0 (Note that sendin= g a fresh connection ID from the pool provided by a server is not enough to= avoid linkability; as dkg has pointed out, you'd also have to shift se= quence number and watch for other signals).

re= gards,

Ted
=C2=A0
If we go with = approach 2, then it's obvious that any packet with a non-zero connectio= n ID has a server-chosen connection ID (though the server still may want to= verify that it's a "valid" connection ID according to the al= gorithm it uses).
=
On the other = hand, this requires QUIC servers which are behind load balancers to be able= to generate connection IDs which the load balancer will route back to them= . If the server and load balancers are from different vendors, this might b= e challenging.
--------------------

I look forward to your thoughts.=C2=A0=

Cheers,<= /div>

Ryan

--94eb2c1924f45e213105498cd675-- From nobody Mon Feb 27 17:11:47 2017 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 4B9B1129470 for ; Mon, 27 Feb 2017 17:11:45 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 dNetxByAmqIX for ; Mon, 27 Feb 2017 17:11:43 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D7841293FD for ; Mon, 27 Feb 2017 17:11:43 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id v186so74084848wmd.0 for ; Mon, 27 Feb 2017 17:11:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=t+g8SI7yXpEPo/OatP0Q0QmGSt7FdxulHA6sqf7GA48=; b=DEcg+bxC8/lHJrpSDlYHXWP5ThfEl+CjpLIl1YM1XcGEcwhyu3/z81T4lhmNQIpdAi NDWN9WiNu51Loatn9vmk6XTEoR231mzlhL++F5TQgclZuWHdcoCpuTqjzSr5BrSVgLUb t0uPjPgI7GAjWBHd4Xkbhqle+mWd3PGMXihLP3qMjcZ7O6smQjMY4icLZVqzCEhnguMn tIHHBvrAEjt0fiYjUBR15lbThzJ/RqkD7xlgecQf6GXoQugGbvVWn/ChisyixPOndRre 6K9NX6X71l2S2mhq8nidRbhicbHAQ12fivHigMd+kmkc7JB2ZHvfRsClwqxH+aXAQlW3 EfhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=t+g8SI7yXpEPo/OatP0Q0QmGSt7FdxulHA6sqf7GA48=; b=tyyrJCBPKkgOUWjgigLXI27OvrKL0SSzYb47hIRt3udXYRNqUp6hDEmd1nHBo+XFR3 srcQ3/7OHLDSLxC7Kn9nKKu2CW+HujoEV+seJFbxKF7Ehv+WQd19EEuPnWWTFzkVst3A 6qoCd+0vtOiMbxVato1DpQIpYNDegUG1CqqRAGejwyVKNsGcC6FvwvukcVAVn60HZSeu Y44vfVc5oM+jdGxHiIwhjOsfZzxWgWG25PLvjB6UbxdS44IHa1QN4/txvSVNfO3/YKnI d52E88c3FtRva1bZer6xDjxbgvlYjtJA2KRfWivDemMNrjqNuYVLFhZ2cGVmo5Xnfl1L a7Zg== X-Gm-Message-State: AMke39k+gGuP7aCmSBrvSCtUKPVvPLyJ5VJ+G65M/asqX9prP5FjkK6K7f4UfcJGdQH++PZaYHGNU6wkuYa264os X-Received: by 10.28.224.69 with SMTP id x66mr9674352wmg.21.1488244301910; Mon, 27 Feb 2017 17:11:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.28.198.15 with HTTP; Mon, 27 Feb 2017 17:11:35 -0800 (PST) In-Reply-To: References: From: Ryan Hamilton Date: Mon, 27 Feb 2017 17:11:35 -0800 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Ted Hardie Content-Type: multipart/alternative; boundary=001a114b0a64f4b08405498ce0da Archived-At: Cc: IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 01:11:45 -0000 --001a114b0a64f4b08405498ce0da Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Feb 27, 2017 at 5:08 PM, Ted Hardie wrote: > One benefit of this approach, however, is that a QUIC server could chose >> to simply use the client's connection ID for the duration of the >> connection. This would mean that it would not need to be able to generat= e a >> new connection ID that is guaranteed to be sent by the load balancer bac= k >> to itself. In cases where the vendor of the load balancer and the server >> are not the same, this might be valuable. >> >> > ekr has made a proposal that the server be able to supply multiple > connection IDs to a client, so that it can use a fresh connection ID when > shifting link origin or engaging in another change where continuing to us= e > the same connection ID would provide linkability. I like that property a > lot, but I think that means the QUIC server still needs to be able to > generate new connection IDs that are guaranteed to be sent by the load > balancer back to itself, even if it retains this connection ID for the > duration of the unaltered connection. (Note that sending a fresh > connection ID from the pool provided by a server is not enough to avoid > linkability; as dkg has pointed out, you'd also have to shift sequence > number and watch for other signals). > =E2=80=8BIndeed. In such a world, a connection in which the same client-cho= sen connection ID is used throughout the connection would be prohibited from performing such actions and a new connection would need to be opened instead. This is, obviously, not the highest performance solution but it is simple. =E2=80=8B --001a114b0a64f4b08405498ce0da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Feb 27, 2017 at 5:08 PM, Ted Hardie <ted.ietf@= gmail.com> wrote:
One benefit of this approach, however, is t= hat a QUIC server could chose to simply use the client's connection ID = for the duration of the connection. This would mean that it would not need = to be able to generate a new connection ID that is guaranteed to be sent by= the load balancer back to itself. In cases where the vendor of the load ba= lancer and the server are not the same, this might be valuable.

=

ekr has made a proposal that the se= rver be able to supply multiple connection IDs to a client, so that it can = use a fresh connection ID when shifting link origin or engaging in another = change where continuing to use the same connection ID would provide linkabi= lity.=C2=A0 I like that property a lot, but I think that means the QUIC ser= ver still needs to be able to generate new connection IDs that are guarante= ed to be sent by the load balancer back to itself, even if it retains this = connection ID for the duration of the unaltered connection.=C2=A0 (Note tha= t sending a fresh connection ID from the pool provided by a server is not e= nough to avoid linkability; as dkg has pointed out, you'd also have to = shift sequence number and watch for other signals).

=E2=80=8BIndeed. In such a world, a connect= ion in which the same client-chosen connection ID is used throughout the co= nnection would be prohibited from performing such actions and a new connect= ion would need to be opened instead. This is, obviously, not the highest pe= rformance solution but it is simple. =E2=80=8B

--001a114b0a64f4b08405498ce0da-- From nobody Mon Feb 27 17:16:32 2017 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 3B88A129434 for ; Mon, 27 Feb 2017 17:16:30 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 nLnIpaYPMM62 for ; Mon, 27 Feb 2017 17:16:28 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 9962A1293FD for ; Mon, 27 Feb 2017 17:16:28 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0F586200014; Tue, 28 Feb 2017 01:16:28 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id CC87320000F; Tue, 28 Feb 2017 01:16:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488244587; bh=d/QH5RAwqsZoaay0olPhML2tu2PKUHviQ8pzA0RQwH8=; l=27276; h=From:To:Date:References:In-Reply-To:From; b=gRrEj5gjeDmDjfcTGyZR09k2lLJutdEVoGEw0jIA2fBJ8p+qDrTe49h5bCcI2WET6 LTG/Uk105Kuds+R++E/d1pAa3uwJ6x1uYiVsh1B/WfKeeMwfZjFoA5pnmgstZNkkZH T+OvVerVqwsJYXBFsXLTmDGIjB63004LiWGF51T4= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 8F1AD98094; Tue, 28 Feb 2017 01:16:27 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 27 Feb 2017 20:16:26 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Mon, 27 Feb 2017 20:16:26 -0500 From: "Lubashev, Igor" To: Ryan Hamilton , IETF QUIC WG Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnUFyvCyJf5LkySP9zxgM+hCaF9nZFQ Date: Tue, 28 Feb 2017 01:16:26 +0000 Message-ID: <25f64b963642425b99196aba0438b8d3@usma1ex-dag1mb5.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.61] Content-Type: multipart/alternative; boundary="_000_25f64b963642425b99196aba0438b8d3usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 01:16:30 -0000 --_000_25f64b963642425b99196aba0438b8d3usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHN1cmUgd2hldGhlciBhIGRpc2N1c3Npb24gaGVyZSBvciBvbiB0aGUgaXNzdWUgcGFnZSBp cyBwcmVmZXJhYmxlLCBzbyBib3RoLiDimLoNCg0KDQrDmCAgV2UgbWlnaHQgbm90IHdhbnQgdGhl IHNlcnZlciB0byBjaG9zZSBhIGNvbm5lY3Rpb24gSUQgdW50aWwgaXQgaXMgcmVhZHkgdG8gYWNj ZXB0IHRoZSBoYW5kc2hha2UuDQoNCk9yIG1heWJlIHRoZSBvcHBvc2l0ZSAtLSB0aGUgc2VydmVy IGNhbiBjaG9vc2UgdGhlIGFzc2lnbiBhIGNvbm5lY3Rpb24gSUQgdG8gdGhpcyBjb25uZWN0aW9u IGF0IHRoZSBmaXJzdCBvcHBvcnR1bml0eSBldmVuIGlmIGl0IGlzIG5vdCB5ZXQgcmVhZHkgdG8g YWNjZXB0IHRoZSBjb25uZWN0aW9uLg0KDQpBbiBleGFtcGxlIG9mIHRoaXMgaXMgdmVyc2lvbiBu ZWdvdGlhdGlvbi4gRHVyaW5nIG5ldyBzb2Z0d2FyZSByb2xsb3V0LCBiYWNrZW5kIHNlcnZlcnMg bWF5IGJlIHJ1bm5pbmcgZGlmZmVyZW50IHZlcnNpb25zIG9mIHRoZSBzb2Z0d2FyZSBhbmQgaGVu Y2Ugc3VwcG9ydGluZyBkaWZmZXJlbnQgUVVJQyB2ZXJzaW9ucy4gV2hlbiB0aGUgc2VydmVyIGlz IGRvaW5nIHZlcnNpb24gbmVnb3RpYXRpb24sIGl0IG1heSBiZSB2ZXJ5IGludGVyZXN0ZWQgaW4g ZW5zdXJpbmcgdGhhdCB0aGUgY2xpZW50IGNvbWVzIGJhY2sgdG8gdGhpcyBiYWNrZW5kIHNlcnZl ciB1c2luZyB0aGUgUVVJQyB2ZXJzaW9uIGl0IHJlcXVlc3RlZC4gSWYgQ29ubmVjdGlvbklEIGlz IHVzZWQgYnkgdGhlIGxvYWQgYmFsYW5jZXJzIHRvIHJvdXRlIHRvIGJhY2tlbmQgc2VydmVycywg dGhlIHNlcnZlciB3aWxsIGxpa2VseSB3YW50IHRvIGdlbmVyYXRlIGEgbmV3IENvbm5lY3Rpb25J RCBkdXJpbmcgdmVyc2lvbiBuZWdvdGlhdGlvbiBhbmQgYmVmb3JlIGl0IGlzIHJlYWR5IHRvIGFj Y2VwdCB0aGUgaGFuZHNoYWtlLg0KDQpPZiBjb3Vyc2UsIHRoZXJlIG11c3QgYmUgYSB3YXkgdG8g bG9vayBhdCBhIHBhY2tldCBhbmQga25vdyB0aGF0IGl0IGlzIHVzaW5nIFNlcnZlcidzIENvbm5l Y3Rpb24gSUQuDQoNCg0KLSAgICAgICAgICBJZ29yDQoNCg0KRnJvbTogUnlhbiBIYW1pbHRvbiBb bWFpbHRvOnJjaEBnb29nbGUuY29tXQ0KU2VudDogTW9uZGF5LCBGZWJydWFyeSAyNywgMjAxNyA3 OjMwIFBNDQpUbzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPg0KU3ViamVjdDogV2hlbiBz aG91bGQgc2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElEcyBiZSBzZW50IGFuZCBob3cgYXJlIHRo ZXkgaW5kaWNhdGVkPw0KDQpIb3dkeSBBbGwsDQoNCkkganVzdCBmaWxlZCBpc3N1ZSAjMzQ5PGh0 dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZ2l0aHVi LmNvbV9xdWljd2dfYmFzZS0yRGRyYWZ0c19pc3N1ZXNfMzQ5JmQ9RHdNRmFRJmM9OTZaYlpaY2FN RjR3MEY0anBONkxaZyZyPURqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1Bt bG8mbT1MUVBhNk1HYlBKaUI4OHhRTF9BSU5GTzRIdUhDVHRkVXNmMUk1ckRidXpFJnM9UHh1cHVX aC1lbzZENzNlN0tjZFNlYjI4Y25PUTkwVzVHblJDRUFpN2YyNCZlPT4gdG8gcmVzb2x2ZSBob3cg c2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElEcyBhcmUgdG8gYmUgdXNlZC4gVG8gc2F2ZSBhIGNs aWNrLCBoZXJlJ3Mgd2hhdCBJIHdyb3RlIHRoZXJlOg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLQ0K TXkgc2Vuc2UgaXMgdGhhdCB3ZSdkIGxpa2UgdGhlIHNlcnZlciB0byBjaG9zZSB0aGUgInJlYWwi IGNvbm5lY3Rpb24gSUQgdG8gYmUgdXNlZCBmb3IgYSBjb25uZWN0aW9uLiBBbW9uZyBvdGhlciB0 aGluZ3MsIHRoaXMgZW5hYmxlcyBzZXJ2ZXJzIHRvIGVtYmVkIHJvdXRpbmcvbG9hZCBiYWxhbmNp bmcgaW5mb3JtYXRpb24gaW50byBjb25uZWN0aW9uIElEcy4NCg0KSSBoYXZlIGhlYXJkIHR3byBv cHRpb25zIGZvciB3aGF0IHRoZSBjbGllbnQgc2hvdWxkIGRvIGJlZm9yZSBpdCBoYXMgYSBzZXJ2 ZXItY2hvc2VuIGNvbm5lY3Rpb24gSUQuDQoNCjEuIFNlbmQgYSByYW5kb20gY29ubmVjdGlvbiBJ RA0KMi4gU2VuZCBhIGNvbm5lY3Rpb24gSUQgb2YgMA0KDQpJZiB3ZSBnbyB3aXRoIGFwcHJvYWNo IDEsIHRoZW4gd2UgbmVlZCBzb21lIG1lY2hhbmlzbSB0aGF0IGxvYWQgYmFsYW5jZXJzIGNhbiB1 c2UgdG8gZGV0ZWN0IGlmIGEgcGFja2V0J3MgY29ubmVjdGlvbiBJRCBpcyBzZXJ2ZXItY2hvc2Vu IG9yIG5vdC4gSXQgc2VlbXMgbGlrZWx5IHRoYXQgYWxsIHBhY2tldHMgZW5jcnlwdGVkIHdpdGgg MS1SVFQga2V5cyBjb3VsZCB1c2Ugc2VydmVyIGdlbmVyYXRlZCBjb25uZWN0aW9uIElEcy4gQnV0 IG90aGVyIHBhY2tldHMgaXQncyBub3Qgc28gY2xlYXIuIENvbnNpZGVyIHRoZSBjYXNlIG9mIGEg bm9uLTAtUlRUIGhhbmRzaGFrZS4gVGhlIGluaXRpYWwgY2xpZW50IGhhbmRzaGFrZSBwYWNrZXQg d291bGQgaW5jbHVkZSBhIGNsaWVudC1jaG9zZW4gY29ubmVjdGlvbiBJRC4gV2hlbiB0aGUgc2Vy dmVyIHJlcGxpZXMsIGl0IGNvdWxkIHVzZSBhIHNlcnZlci1jaG9zZW4gY29ubmVjdGlvbiBJRC4g SWYgc28gdGhlbiB3aGVuIHRoZSBjbGllbnQgc2VuZHMgdGhlIG5leHQgaGFuZHNoYWtlIHBhY2tl dCBpdCBjb3VsZCB1c2UgdGhlIHNlcnZlci1jaG9zZW4gY29ubmVjdGlvbiBJRCBhcyB3ZWxsLiBC dXQgdGhhdCBtZWFucyB0aGF0IHdlJ2QgbmVlZCBhIG1lY2hhbmlzbSB0byBkaXNhbWJpZ3VhdGUg Y2xpZW50IGhhbmRzaGFrZSBwYWNrZXRzIHdpdGggY2xpZW50LWNob3NlbiBjb25uZWN0aW9uIElE cyBmcm9tIGNsaWVudCBoYW5kc2hha2UgcGFja2V0cyB3aXRoIHNlcnZlci1jaG9zZW4gY29ubmVj dGlvbiBJRHMuIFdlIGNvdWxkIGRldm90ZSBiaXRzIG9yIHBhY2tldCB0eXBlcyB0byBpbmRpY2F0 ZSB0aGlzLiBJIHN1c3BlY3QgdGhlIHNhbWUgYXJndW1lbnQgbWlnaHQgaG9sZCBmb3Igc2VydmVy IGhhbmRzaGFrZSBwYWNrZXRzLiBXZSBtaWdodCBub3Qgd2FudCB0aGUgc2VydmVyIHRvIGNob3Nl IGEgY29ubmVjdGlvbiBJRCB1bnRpbCBpdCBpcyByZWFkeSB0byBhY2NlcHQgdGhlIGhhbmRzaGFr ZS4NCg0KT25lIGJlbmVmaXQgb2YgdGhpcyBhcHByb2FjaCwgaG93ZXZlciwgaXMgdGhhdCBhIFFV SUMgc2VydmVyIGNvdWxkIGNob3NlIHRvIHNpbXBseSB1c2UgdGhlIGNsaWVudCdzIGNvbm5lY3Rp b24gSUQgZm9yIHRoZSBkdXJhdGlvbiBvZiB0aGUgY29ubmVjdGlvbi4gVGhpcyB3b3VsZCBtZWFu IHRoYXQgaXQgd291bGQgbm90IG5lZWQgdG8gYmUgYWJsZSB0byBnZW5lcmF0ZSBhIG5ldyBjb25u ZWN0aW9uIElEIHRoYXQgaXMgZ3VhcmFudGVlZCB0byBiZSBzZW50IGJ5IHRoZSBsb2FkIGJhbGFu Y2VyIGJhY2sgdG8gaXRzZWxmLiBJbiBjYXNlcyB3aGVyZSB0aGUgdmVuZG9yIG9mIHRoZSBsb2Fk IGJhbGFuY2VyIGFuZCB0aGUgc2VydmVyIGFyZSBub3QgdGhlIHNhbWUsIHRoaXMgbWlnaHQgYmUg dmFsdWFibGUuDQoNCklmIHdlIGdvIHdpdGggYXBwcm9hY2ggMiwgdGhlbiBpdCdzIG9idmlvdXMg dGhhdCBhbnkgcGFja2V0IHdpdGggYSBub24temVybyBjb25uZWN0aW9uIElEIGhhcyBhIHNlcnZl ci1jaG9zZW4gY29ubmVjdGlvbiBJRCAodGhvdWdoIHRoZSBzZXJ2ZXIgc3RpbGwgbWF5IHdhbnQg dG8gdmVyaWZ5IHRoYXQgaXQncyBhICJ2YWxpZCIgY29ubmVjdGlvbiBJRCBhY2NvcmRpbmcgdG8g dGhlIGFsZ29yaXRobSBpdCB1c2VzKS4NCg0KT24gdGhlIG90aGVyIGhhbmQsIHRoaXMgcmVxdWly ZXMgUVVJQyBzZXJ2ZXJzIHdoaWNoIGFyZSBiZWhpbmQgbG9hZCBiYWxhbmNlcnMgdG8gYmUgYWJs ZSB0byBnZW5lcmF0ZSBjb25uZWN0aW9uIElEcyB3aGljaCB0aGUgbG9hZCBiYWxhbmNlciB3aWxs IHJvdXRlIGJhY2sgdG8gdGhlbS4gSWYgdGhlIHNlcnZlciBhbmQgbG9hZCBiYWxhbmNlcnMgYXJl IGZyb20gZGlmZmVyZW50IHZlbmRvcnMsIHRoaXMgbWlnaHQgYmUgY2hhbGxlbmdpbmcuDQotLS0t LS0tLS0tLS0tLS0tLS0tLQ0KDQpJIGxvb2sgZm9yd2FyZCB0byB5b3VyIHRob3VnaHRzLg0KDQpD aGVlcnMsDQoNClJ5YW4NCg== --_000_25f64b963642425b99196aba0438b8d3usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJUcmVidWNoZXQg TVMiOw0KCXBhbm9zZS0xOjIgMTEgNiAzIDIgMiAyIDIgMiA0O30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVy bGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4t bGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0K QGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6ODY3MTgzNDU3Ow0KCW1zby1saXN0LXR5cGU6aHlicmlk Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczo2NTAyNzYwODQgLTEyOTkxNDEzMjQgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDox NjkwMDYwMzQ1Ow0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoyODc4Nzg4MjQgOTcyODc1MTMwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwxOmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1m YXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBs MTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0Kb2wN Cgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KLS0+PC9z dHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVk aXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28g OV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJl ZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9o ZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Tm90IHN1cmUgd2hldGhlciBhIGRpc2N1c3Npb24gaGVyZSBvciBvbiB0aGUgaXNzdWUg cGFnZSBpcyBwcmVmZXJhYmxlLCBzbyBib3RoLg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OldpbmdkaW5ncyI+Sjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzEi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OldpbmdkaW5ncyI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+w5g8c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOw0KPC9z cGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+V2UgbWlnaHQgbm90 IHdhbnQgdGhlIHNlcnZlciB0byBjaG9zZSBhIGNvbm5lY3Rpb24gSUQgdW50aWwgaXQgaXMgcmVh ZHkgdG8gYWNjZXB0IHRoZSBoYW5kc2hha2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk9yIG1heWJlIHRoZSBv cHBvc2l0ZSAtLSB0aGUgc2VydmVyIGNhbiBjaG9vc2UgdGhlIGFzc2lnbiBhIGNvbm5lY3Rpb24g SUQgdG8gdGhpcyBjb25uZWN0aW9uIGF0IHRoZSBmaXJzdCBvcHBvcnR1bml0eSBldmVuIGlmIGl0 IGlzIG5vdCB5ZXQgcmVhZHkgdG8gYWNjZXB0IHRoZSBjb25uZWN0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5BbiBleGFtcGxlIG9mIHRoaXMgaXMgdmVyc2lvbiBuZWdvdGlhdGlvbi4gRHVyaW5nIG5ldyBz b2Z0d2FyZSByb2xsb3V0LCBiYWNrZW5kIHNlcnZlcnMgbWF5IGJlIHJ1bm5pbmcgZGlmZmVyZW50 IHZlcnNpb25zIG9mIHRoZSBzb2Z0d2FyZSBhbmQgaGVuY2Ugc3VwcG9ydGluZyBkaWZmZXJlbnQg UVVJQw0KIHZlcnNpb25zLiBXaGVuIHRoZSBzZXJ2ZXIgaXMgZG9pbmcgdmVyc2lvbiBuZWdvdGlh dGlvbiwgaXQgbWF5IGJlIHZlcnkgaW50ZXJlc3RlZCBpbiBlbnN1cmluZyB0aGF0IHRoZSBjbGll bnQgY29tZXMgYmFjayB0byB0aGlzIGJhY2tlbmQgc2VydmVyIHVzaW5nIHRoZSBRVUlDIHZlcnNp b24gaXQgcmVxdWVzdGVkLiBJZiBDb25uZWN0aW9uSUQgaXMgdXNlZCBieSB0aGUgbG9hZCBiYWxh bmNlcnMgdG8gcm91dGUgdG8gYmFja2VuZCBzZXJ2ZXJzLA0KIHRoZSBzZXJ2ZXIgd2lsbCBsaWtl bHkgd2FudCB0byBnZW5lcmF0ZSBhIG5ldyBDb25uZWN0aW9uSUQgZHVyaW5nIHZlcnNpb24gbmVn b3RpYXRpb24gYW5kIGJlZm9yZSBpdCBpcyByZWFkeSB0byBhY2NlcHQgdGhlIGhhbmRzaGFrZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+T2YgY291cnNlLCB0aGVyZSBtdXN0IGJlIGEgd2F5IHRvIGxvb2sgYXQg YSBwYWNrZXQgYW5kIGtub3cgdGhhdCBpdCBpcyB1c2luZyBTZXJ2ZXIncyBDb25uZWN0aW9uIElE LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotLjI1aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzIi PjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gc3R5bGU9Im1zby1s aXN0Oklnbm9yZSI+LTxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5J Z29yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+IFJ5YW4gSGFtaWx0b24gW21haWx0bzpyY2hAZ29vZ2xlLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIEZlYnJ1YXJ5IDI3LCAyMDE3IDc6MzAgUE08YnI+DQo8Yj5Ubzo8 L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gV2hlbiBzaG91bGQgc2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElEcyBiZSBzZW50IGFuZCBo b3cgYXJlIHRoZXkgaW5kaWNhdGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1 b3Q7LHNhbnMtc2VyaWYiPkhvd2R5IEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+SSBqdXN0IGZp bGVkIGlzc3VlDQo8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv dXJsP3U9aHR0cHMtM0FfX2dpdGh1Yi5jb21fcXVpY3dnX2Jhc2UtMkRkcmFmdHNfaXNzdWVzXzM0 OSZhbXA7ZD1Ed01GYVEmYW1wO2M9OTZaYlpaY2FNRjR3MEY0anBONkxaZyZhbXA7cj1Eam4zYlE1 dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJmFtcDttPUxRUGE2TUdiUEppQjg4 eFFMX0FJTkZPNEh1SENUdGRVc2YxSTVyRGJ1ekUmYW1wO3M9UHh1cHVXaC1lbzZENzNlN0tjZFNl YjI4Y25PUTkwVzVHblJDRUFpN2YyNCZhbXA7ZT0iPg0KIzM0OTwvYT4mbmJzcDt0byByZXNvbHZl IGhvdyBzZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSURzIGFyZSB0byBiZSB1c2VkLiBUbyBzYXZl IGEgY2xpY2ssIGhlcmUncyB3aGF0IEkgd3JvdGUgdGhlcmU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYi Pi0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+TXkgc2Vuc2UgaXMgdGhhdCB3ZSdk IGxpa2UgdGhlIHNlcnZlciB0byBjaG9zZSB0aGUgJnF1b3Q7cmVhbCZxdW90OyBjb25uZWN0aW9u IElEIHRvIGJlIHVzZWQgZm9yIGEgY29ubmVjdGlvbi4gQW1vbmcgb3RoZXIgdGhpbmdzLCB0aGlz IGVuYWJsZXMgc2VydmVycyB0byBlbWJlZCByb3V0aW5nL2xvYWQgYmFsYW5jaW5nIGluZm9ybWF0 aW9uDQogaW50byBjb25uZWN0aW9uIElEcy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+SSBoYXZlIGhlYXJkIHR3byBvcHRp b25zIGZvciB3aGF0IHRoZSBjbGllbnQgc2hvdWxkIGRvIGJlZm9yZSBpdCBoYXMgYSBzZXJ2ZXIt Y2hvc2VuIGNvbm5lY3Rpb24gSUQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPjEuIFNlbmQgYSByYW5kb20gY29ubmVjdGlv biBJRDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDss c2Fucy1zZXJpZiI+Mi4gU2VuZCBhIGNvbm5lY3Rpb24gSUQgb2YgMDwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5JZiB3ZSBn byB3aXRoIGFwcHJvYWNoIDEsIHRoZW4gd2UgbmVlZCBzb21lIG1lY2hhbmlzbSB0aGF0IGxvYWQg YmFsYW5jZXJzIGNhbiB1c2UgdG8gZGV0ZWN0IGlmIGEgcGFja2V0J3MgY29ubmVjdGlvbiBJRCBp cyBzZXJ2ZXItY2hvc2VuIG9yIG5vdC4gSXQgc2VlbXMgbGlrZWx5IHRoYXQgYWxsIHBhY2tldHMg ZW5jcnlwdGVkDQogd2l0aCAxLVJUVCBrZXlzIGNvdWxkIHVzZSBzZXJ2ZXIgZ2VuZXJhdGVkIGNv bm5lY3Rpb24gSURzLiBCdXQgb3RoZXIgcGFja2V0cyBpdCdzIG5vdCBzbyBjbGVhci4gQ29uc2lk ZXIgdGhlIGNhc2Ugb2YgYSBub24tMC1SVFQgaGFuZHNoYWtlLiBUaGUgaW5pdGlhbCBjbGllbnQg aGFuZHNoYWtlIHBhY2tldCB3b3VsZCBpbmNsdWRlIGEgY2xpZW50LWNob3NlbiBjb25uZWN0aW9u IElELiBXaGVuIHRoZSBzZXJ2ZXIgcmVwbGllcywgaXQgY291bGQgdXNlDQogYSBzZXJ2ZXItY2hv c2VuIGNvbm5lY3Rpb24gSUQuIElmIHNvIHRoZW4gd2hlbiB0aGUgY2xpZW50IHNlbmRzIHRoZSBu ZXh0IGhhbmRzaGFrZSBwYWNrZXQgaXQgY291bGQgdXNlIHRoZSBzZXJ2ZXItY2hvc2VuIGNvbm5l Y3Rpb24gSUQgYXMgd2VsbC4gQnV0IHRoYXQgbWVhbnMgdGhhdCB3ZSdkIG5lZWQgYSBtZWNoYW5p c20gdG8gZGlzYW1iaWd1YXRlIGNsaWVudCBoYW5kc2hha2UgcGFja2V0cyB3aXRoIGNsaWVudC1j aG9zZW4gY29ubmVjdGlvbg0KIElEcyBmcm9tIGNsaWVudCBoYW5kc2hha2UgcGFja2V0cyB3aXRo IHNlcnZlci1jaG9zZW4gY29ubmVjdGlvbiBJRHMuIFdlIGNvdWxkIGRldm90ZSBiaXRzIG9yIHBh Y2tldCB0eXBlcyB0byBpbmRpY2F0ZSB0aGlzLiBJIHN1c3BlY3QgdGhlIHNhbWUgYXJndW1lbnQg bWlnaHQgaG9sZCBmb3Igc2VydmVyIGhhbmRzaGFrZSBwYWNrZXRzLiBXZSBtaWdodCBub3Qgd2Fu dCB0aGUgc2VydmVyIHRvIGNob3NlIGEgY29ubmVjdGlvbiBJRCB1bnRpbCBpdA0KIGlzIHJlYWR5 IHRvIGFjY2VwdCB0aGUgaGFuZHNoYWtlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5PbmUgYmVuZWZpdCBvZiB0aGlzIGFw cHJvYWNoLCBob3dldmVyLCBpcyB0aGF0IGEgUVVJQyBzZXJ2ZXIgY291bGQgY2hvc2UgdG8gc2lt cGx5IHVzZSB0aGUgY2xpZW50J3MgY29ubmVjdGlvbiBJRCBmb3IgdGhlIGR1cmF0aW9uIG9mIHRo ZSBjb25uZWN0aW9uLiBUaGlzIHdvdWxkIG1lYW4gdGhhdCBpdCB3b3VsZCBub3QNCiBuZWVkIHRv IGJlIGFibGUgdG8gZ2VuZXJhdGUgYSBuZXcgY29ubmVjdGlvbiBJRCB0aGF0IGlzIGd1YXJhbnRl ZWQgdG8gYmUgc2VudCBieSB0aGUgbG9hZCBiYWxhbmNlciBiYWNrIHRvIGl0c2VsZi4gSW4gY2Fz ZXMgd2hlcmUgdGhlIHZlbmRvciBvZiB0aGUgbG9hZCBiYWxhbmNlciBhbmQgdGhlIHNlcnZlciBh cmUgbm90IHRoZSBzYW1lLCB0aGlzIG1pZ2h0IGJlIHZhbHVhYmxlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj5JZiB3ZSBn byB3aXRoIGFwcHJvYWNoIDIsIHRoZW4gaXQncyBvYnZpb3VzIHRoYXQgYW55IHBhY2tldCB3aXRo IGEgbm9uLXplcm8gY29ubmVjdGlvbiBJRCBoYXMgYSBzZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24g SUQgKHRob3VnaCB0aGUgc2VydmVyIHN0aWxsIG1heSB3YW50IHRvIHZlcmlmeSB0aGF0IGl0J3Mg YSAmcXVvdDt2YWxpZCZxdW90Ow0KIGNvbm5lY3Rpb24gSUQgYWNjb3JkaW5nIHRvIHRoZSBhbGdv cml0aG0gaXQgdXNlcykuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVj aGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIHRoZSBvdGhlciBoYW5kLCB0aGlzIHJlcXVpcmVz IFFVSUMgc2VydmVycyB3aGljaCBhcmUgYmVoaW5kIGxvYWQgYmFsYW5jZXJzIHRvIGJlIGFibGUg dG8gZ2VuZXJhdGUgY29ubmVjdGlvbiBJRHMgd2hpY2ggdGhlIGxvYWQgYmFsYW5jZXIgd2lsbCBy b3V0ZSBiYWNrIHRvIHRoZW0uIElmIHRoZSBzZXJ2ZXIgYW5kIGxvYWQNCiBiYWxhbmNlcnMgYXJl IGZyb20gZGlmZmVyZW50IHZlbmRvcnMsIHRoaXMgbWlnaHQgYmUgY2hhbGxlbmdpbmcuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNh bnMtc2VyaWYiPi0tLS0tLS0tLS0tLS0tLS0tLS0tPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkkgbG9v ayBmb3J3YXJkIHRvIHlvdXIgdGhvdWdodHMuJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1RyZWJ1Y2hldCBNUyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPkNo ZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7VHJlYnVjaGV0IE1TJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVi dWNoZXQgTVMmcXVvdDssc2Fucy1zZXJpZiI+UnlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_25f64b963642425b99196aba0438b8d3usma1exdag1mb5msgcorpak_-- From nobody Tue Feb 28 04:00:23 2017 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 2160E129531 for ; Tue, 28 Feb 2017 04:00:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 1MpvsafHmyXo for ; Tue, 28 Feb 2017 04:00:20 -0800 (PST) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35AE2129524 for ; Tue, 28 Feb 2017 04:00:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3vXcb64s6Cz15NHr; Tue, 28 Feb 2017 13:00:18 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Rie9Yfmzekh; Tue, 28 Feb 2017 13:00:16 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC2EE9.dip0.t-ipconnect.de [93.236.46.233]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 28 Feb 2017 13:00:16 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 28 Feb 2017 13:00:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> References: To: Ryan Hamilton X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Ted Hardie , IETF QUIC WG X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 12:00:22 -0000 Hi all, > Am 28.02.2017 um 02:11 schrieb Ryan Hamilton : >=20 >=20 > On Mon, Feb 27, 2017 at 5:08 PM, Ted Hardie = wrote: > One benefit of this approach, however, is that a QUIC server could = chose to simply use the client's connection ID for the duration of the = connection. This would mean that it would not need to be able to = generate a new connection ID that is guaranteed to be sent by the load = balancer back to itself. In cases where the vendor of the load balancer = and the server are not the same, this might be valuable. >=20 >=20 > ekr has made a proposal that the server be able to supply multiple = connection IDs to a client, so that it can use a fresh connection ID = when shifting link origin or engaging in another change where continuing = to use the same connection ID would provide linkability. I like that = property a lot, but I think that means the QUIC server still needs to be = able to generate new connection IDs that are guaranteed to be sent by = the load balancer back to itself, even if it retains this connection ID = for the duration of the unaltered connection. (Note that sending a = fresh connection ID from the pool provided by a server is not enough to = avoid linkability; as dkg has pointed out, you'd also have to shift = sequence number and watch for other signals). >=20 > =E2=80=8BIndeed. In such a world, a connection in which the same = client-chosen connection ID is used throughout the connection would be = prohibited from performing such actions and a new connection would need = to be opened instead. This is, obviously, not the highest performance = solution but it is simple. =E2=80=8B >=20 I also like this proposal a lot but you can never fully avoid likability = e.g. the client might not be aware that the path/5-tuple has changed. = Also I think this will always be an optional feature because the server = might just not provide you additional connection ids for whatever = reason. In this case the client can use the old one which might make it = possible to link to connections or it can start a new connection eating = the penalty of having to re-request any data that was under = transmission.= From nobody Tue Feb 28 08:37:46 2017 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 81A4A12962F for ; Tue, 28 Feb 2017 08:37:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulF_AEbhgafd for ; Tue, 28 Feb 2017 08:37:43 -0800 (PST) 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 94CB3129624 for ; Tue, 28 Feb 2017 08:37:43 -0800 (PST) Received: by mail-oi0-x232.google.com with SMTP id 2so8630715oif.0 for ; Tue, 28 Feb 2017 08:37:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ruSMHqUQNor/yZJRvZ4JIkJgXALBb81pS5Hi320hTPg=; b=mpVL/A0MpupedMbxjMCD/a8rlZHVZWH/8mhXl9WV1Q28TYck2BZxei58WFx65P7RhP Ercmi0l1rcg8y3qQlLG7p76ZrybjQW6foUVsjbT3BBUEC2d1m2eltO10J9LsTCw+HPjn rf/c3SVBKBYll1hLALZzXUdZbGbRPuoD9UNGADNOeuNxHVuF2kmbUzOw0jPO200ZgWW1 gQ/BbDLwydEzfedgYibGiUbffrS50UWPqtUakG9E7CPDPJhUn3nywXbU4FGbyzU+dVfL 1eF7ZJlcB5T1L4WsUZ9GG2+7r3MEPl+qm7rK0EbpEBMwu6HOVnhmyDroTVl4Miv/YMk5 5T+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ruSMHqUQNor/yZJRvZ4JIkJgXALBb81pS5Hi320hTPg=; b=LhSivCpgYgsraTSED8e+g32bxldOjx0E3fUoETT+s5F5EcUG+9pFk+P91qO6FnikED lrCVv0cSkrOG6gVpwYgvHFADCj8xKCNkreP/SGhnOAVRbfuAnY6kkqEWyL5vvCglQp07 bRAH3MelnCFzY29CjH9wM0R/2+5YZtTd1UbkW5EphbmX7XVbTEc5bumyWdrR4crjGpel KfhQaMGS7mQnsRu7CJvdGTZxDix9Im84hSfLrYZhq27u+m4mn3bMsv2ql+ARGtk3tD4J w+AG3JGDX62tL5at0By99NPJoqSOz2V4aJhUPpayg9mu5MceiAhxyPNyJAzxmSBtVHLC AzeQ== X-Gm-Message-State: AMke39lgXX7qurvHbLD3+VMaghUMbelA+1Q5dHGCYKwjKQTy/xbxjvv2fDSZDlwOjcMZOVWFhrFtwyNbzYi/8g== X-Received: by 10.202.72.2 with SMTP id v2mr1716526oia.179.1488299862689; Tue, 28 Feb 2017 08:37:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.142.85 with HTTP; Tue, 28 Feb 2017 08:37:12 -0800 (PST) In-Reply-To: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> From: Ted Hardie Date: Tue, 28 Feb 2017 08:37:12 -0800 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a113e4eaca28d1a054999d0c0 Archived-At: Cc: IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 16:37:45 -0000 --001a113e4eaca28d1a054999d0c0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2017 at 4:00 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi all, > > > > > ekr has made a proposal that the server be able to supply multiple > connection IDs to a client, so that it can use a fresh connection ID when > shifting link origin or engaging in another change where continuing to us= e > the same connection ID would provide linkability. I like that property a > lot, but I think that means the QUIC server still needs to be able to > generate new connection IDs that are guaranteed to be sent by the load > balancer back to itself, even if it retains this connection ID for the > duration of the unaltered connection. (Note that sending a fresh > connection ID from the pool provided by a server is not enough to avoid > linkability; as dkg has pointed out, you'd also have to shift sequence > number and watch for other signals). > > > > =E2=80=8BIndeed. In such a world, a connection in which the same client= -chosen > connection ID is used throughout the connection would be prohibited from > performing such actions and a new connection would need to be opened > instead. This is, obviously, not the highest performance solution but it = is > simple. =E2=80=8B > > > I also like this proposal a lot but you can never fully avoid likability > e.g. the client might not be aware that the path/5-tuple has changed. Als= o > I think this will always be an optional feature because the server might > just not provide you additional connection ids for whatever reason. In th= is > case the client can use the old one which might make it possible to link = to > connections or it can start a new connection eating the penalty of having > to re-request any data that was under transmission. There are two cases we have to consider: linkability due to a change in the network not visible to the client and linkability that occurs because of a client-initiated change. You're correct that it cannot update the connection ID to avoid linkage when it doesn't know of the change, but when the client initiates the change (e.g. moves from WiFi to cellular), it certainly could. If this feature is optional, then you likely do have to have a configuration frob that the client uses to say "re-use of connect IDs is okay" vs. "not okay, please use 0RTT when transitions occur and only one connection ID is available". Personally, I'd be happy if it were not optional, and I think the protocol to share out a pool of connection IDs from a load balancer/load balancer farm is not that complicated. It's not in charter for QUIC, but if we wanted a proposal for it, I'm guessing we could knock something together by the Paris interim and take it to dispatch in Prague. Ted --001a113e4eaca28d1a054999d0c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 28, 2017 at 4:00 AM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
Hi all,

>
> ekr has made a proposal that the server be able to supply multiple con= nection IDs to a client, so that it can use a fresh connection ID when shif= ting link origin or engaging in another change where continuing to use the = same connection ID would provide linkability.=C2=A0 I like that property a = lot, but I think that means the QUIC server still needs to be able to gener= ate new connection IDs that are guaranteed to be sent by the load balancer = back to itself, even if it retains this connection ID for the duration of t= he unaltered connection.=C2=A0 (Note that sending a fresh connection ID fro= m the pool provided by a server is not enough to avoid linkability; as dkg = has pointed out, you'd also have to shift sequence number and watch for= other signals).
>
> =E2=80=8BIndeed. In such a world, a connection in which the same clien= t-chosen connection ID is used throughout the connection would be prohibite= d from performing such actions and a new connection would need to be opened= instead. This is, obviously, not the highest performance solution but it i= s simple. =E2=80=8B
>
I also like this proposal a lot but you can never fully avoid l= ikability e.g. the client might not be aware that the path/5-tuple has chan= ged. Also I think this will always be an optional feature because the serve= r might just not provide you additional connection ids for whatever reason.= In this case the client can use the old one which might make it possible t= o link to connections or it can start a new connection eating the penalty o= f having to re-request any data that was under transmission.

There are two cases we have to con= sider: linkability due to a change in the network not visible to the client= and linkability that occurs because of a client-initiated change.=C2=A0 Yo= u're correct that it cannot update the connection ID to avoid linkage w= hen it doesn't know of the change, but when the client initiates the ch= ange (e.g. moves from WiFi to cellular), it certainly could.=C2=A0 If this = feature is optional, then you likely do have to have a configuration frob t= hat the client uses to say "re-use of connect IDs is okay" vs. &q= uot;not okay, please use 0RTT when transitions occur and only one connectio= n ID is available".=C2=A0

Per= sonally, I'd be happy if it were not optional, and I think the protocol= to share out a pool of connection IDs from a load balancer/load balancer f= arm is not that complicated. It's not in charter for QUIC, but if we wa= nted a proposal for it, I'm guessing we could knock something together = by the Paris interim and take it to dispatch in Prague.

Ted


=

--001a113e4eaca28d1a054999d0c0-- From nobody Tue Feb 28 10:12:21 2017 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 01854129664 for ; Tue, 28 Feb 2017 10:12:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-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 s4CjIjQEfKal for ; Tue, 28 Feb 2017 10:12:19 -0800 (PST) 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 798CD129662 for ; Tue, 28 Feb 2017 10:12:19 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id p77so14683853ywg.1 for ; Tue, 28 Feb 2017 10:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xg3VkyjmKhutms+37ObmZLnaYQDnGucTf8ccxgsH5mE=; b=auLK5WMWaqCt75/XMgC+mBt4duyImb/kSwwOw1RPLs+PIObgc3bP33aKOKxMiFtETJ ILMc0F4kkLE0VJdBKx7G3O5DniF5UYCSD5QEjiP/abnVGx0uK3Q2de0rgA/cWkKXQF66 bFDPIrcONVmY9Amxy4JAWARi9fkuJQOJLCwsA7GomIbdTpObUcAAuMeCg5mmZ7DD7MdK 50Oi8/50AFai9z83NNS2LrQ0yoB99J9xYou+m64EuJoW5fXfi1MJe+Z3P5Uk4GJfoqeb xMaeETIwXkQiTZLHNz11TQkSG32ZSx40Xt0Cfp3TYRy15p+OM48F/fnRLM9A3QNcjqNJ US/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xg3VkyjmKhutms+37ObmZLnaYQDnGucTf8ccxgsH5mE=; b=FwID3QD2L06OJlnW0mBvq0URBmL8QEtT+fZMjmEqro4bDcWRt1Wt72nsFQkwC5u0L8 07CvaXeWW/D/+FwOGSI+CPmdSAJFr++ycu4qfXIkduUE/6kz1KogD6eLTGVfuc1hcsih yEHd45fQmkFZgbogdzKeLY5FKZsuIzFDfQGSPiBzicEaraVG7T6hWOr/DMf/7acMwS70 gJgWotv0akzkyIj/T0VpMbS5IAyknvSonImKTahi2KnQSYg2trkxfStu2NHhS0vTpeCf FYayo1mA6D8QYVB8PTbL92TyZV2kQ1Kdiql5Qcfi5LUUK+FZOIPsKiPVthghrvIjn3Cq 5JKQ== X-Gm-Message-State: AMke39k18RrBOQcAL2dLp3AfJRhQUpIO4Rq3FnPCtuSyAEJbNH8NvYlVUU3Vrj7C65/sTOgAUCIuC8CKsByg0w== X-Received: by 10.129.125.5 with SMTP id y5mr1275605ywc.120.1488305538591; Tue, 28 Feb 2017 10:12:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.154.210 with HTTP; Tue, 28 Feb 2017 10:11:37 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 28 Feb 2017 12:11:37 -0600 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Ted Hardie Content-Type: multipart/alternative; boundary=001a11493644f20ed705499b2208 Archived-At: Cc: IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 18:12:21 -0000 --001a11493644f20ed705499b2208 Content-Type: text/plain; charset=UTF-8 On Mon, Feb 27, 2017 at 7:08 PM, Ted Hardie wrote: > Comment in-line. > > On Mon, Feb 27, 2017 at 4:30 PM, Ryan Hamilton wrote: > >> Howdy All, >> >> I just filed issue #349 >> to resolve how >> server-chosen connection IDs are to be used. To save a click, here's what I >> wrote there: >> >> -------------------- >> My sense is that we'd like the server to chose the "real" connection ID >> to be used for a connection. Among other things, this enables servers to >> embed routing/load balancing information into connection IDs. >> >> I have heard two options for what the client should do before it has a >> server-chosen connection ID. >> >> 1. Send a random connection ID >> 2. Send a connection ID of 0 >> >> If we go with approach 1, then we need some mechanism that load balancers >> can use to detect if a packet's connection ID is server-chosen or not. It >> seems likely that all packets encrypted with 1-RTT keys could use server >> generated connection IDs. But other packets it's not so clear. Consider the >> case of a non-0-RTT handshake. The initial client handshake packet would >> include a client-chosen connection ID. When the server replies, it could >> use a server-chosen connection ID. If so then when the client sends the >> next handshake packet it could use the server-chosen connection ID as well. >> But that means that we'd need a mechanism to disambiguate client handshake >> packets with client-chosen connection IDs from client handshake packets >> with server-chosen connection IDs. We could devote bits or packet types to >> indicate this. I suspect the same argument might hold for server handshake >> packets. We might not want the server to chose a connection ID until it is >> ready to accept the handshake. >> >> One benefit of this approach, however, is that a QUIC server could chose >> to simply use the client's connection ID for the duration of the >> connection. This would mean that it would not need to be able to generate a >> new connection ID that is guaranteed to be sent by the load balancer back >> to itself. In cases where the vendor of the load balancer and the server >> are not the same, this might be valuable. >> >> > ekr has made a proposal that the server be able to supply multiple > connection IDs to a client, so that it can use a fresh connection ID when > shifting link origin or engaging in another change where continuing to use > the same connection ID would provide linkability. I like that property a > lot, but I think that means the QUIC server still needs to be able to > generate new connection IDs that are guaranteed to be sent by the load > balancer back to itself, even if it retains this connection ID for the > duration of the unaltered connection. (Note that sending a fresh > connection ID from the pool provided by a server is not enough to avoid > linkability; as dkg has pointed out, you'd also have to shift sequence > number and watch for other signals). > I'm sure I did mention this option at one point or another, but for the reasons we discussed in Tokyo, I don't think it actually works that well. Rather, I think you probably need some mechanism where a different conn id field appears in each message, but somehow tied back to the connection. As you say, you would also need to do something about the sequence number (see previous comments on that). I don't have any really good designs here, but there are not-great designs :) -Ekr regards, > > Ted > > >> If we go with approach 2, then it's obvious that any packet with a >> non-zero connection ID has a server-chosen connection ID (though the server >> still may want to verify that it's a "valid" connection ID according to the >> algorithm it uses). >> >> On the other hand, this requires QUIC servers which are behind load >> balancers to be able to generate connection IDs which the load balancer >> will route back to them. If the server and load balancers are from >> different vendors, this might be challenging. >> -------------------- >> >> I look forward to your thoughts. >> >> Cheers, >> >> Ryan >> > > --001a11493644f20ed705499b2208 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Mon, Feb 27, 2017 at 7:08 PM, Ted Hardie <ted.ietf@gmail.com>= wrote:
Comment i= n-line.

= On Mon, Feb 27, 2017 at 4:30 PM, Ryan Hamilton <rch@google.com>= wrote:
Howdy All,

I just filed issue #349=C2=A0to resolve how server-chosen connection = IDs are to be used. To save a click, here's what I wrote there:

----------------= ----
My sense is= that we'd like the server to chose the "real" connection ID = to be used for a connection. Among other things, this enables servers to em= bed routing/load balancing information into connection IDs.

I have heard two options for what the client = should do before it has a server-chosen connection ID.

1. Send a random connection ID
2. Send a connection ID of 0

If we go with approach 1, then we need s= ome mechanism that load balancers can use to detect if a packet's conne= ction ID is server-chosen or not. It seems likely that all packets encrypte= d with 1-RTT keys could use server generated connection IDs. But other pack= ets it's not so clear. Consider the case of a non-0-RTT handshake. The = initial client handshake packet would include a client-chosen connection ID= . When the server replies, it could use a server-chosen connection ID. If s= o then when the client sends the next handshake packet it could use the ser= ver-chosen connection ID as well. But that means that we'd need a mecha= nism to disambiguate client handshake packets with client-chosen connection= IDs from client handshake packets with server-chosen connection IDs. We co= uld devote bits or packet types to indicate this. I suspect the same argume= nt might hold for server handshake packets. We might not want the server to= chose a connection ID until it is ready to accept the handshake.

One benefit of this approach, however, i= s that a QUIC server could chose to simply use the client's connection = ID for the duration of the connection. This would mean that it would not ne= ed to be able to generate a new connection ID that is guaranteed to be sent= by the load balancer back to itself. In cases where the vendor of the load= balancer and the server are not the same, this might be valuable.


ekr has made a proposal that the= server be able to supply multiple connection IDs to a client, so that it c= an use a fresh connection ID when shifting link origin or engaging in anoth= er change where continuing to use the same connection ID would provide link= ability.=C2=A0 I like that property a lot, but I think that means the QUIC = server still needs to be able to generate new connection IDs that are guara= nteed to be sent by the load balancer back to itself, even if it retains th= is connection ID for the duration of the unaltered connection.=C2=A0 (Note = that sending a fresh connection ID from the pool provided by a server is no= t enough to avoid linkability; as dkg has pointed out, you'd also have = to shift sequence number and watch for other signals).

I'm sure I did mention this option = at one point or another, but for the reasons we discussed in
Toky= o, I don't think it actually works that well. Rather, I think you proba= bly need some mechanism
where a different conn id field appears i= n each message, but somehow tied back to the connection.
As you s= ay, you would also need to do something about the sequence number (see prev= ious
comments on that). I don't have any really good designs = here, but there are not-great designs :)

-Ekr



regards,

Ted
=C2=A0
If = we go with approach 2, then it's obvious that any packet with a non-zer= o connection ID has a server-chosen connection ID (though the server still = may want to verify that it's a "valid" connection ID accordin= g to the algorithm it uses).

On= the other hand, this requires QUIC servers which are behind load balancers= to be able to generate connection IDs which the load balancer will route b= ack to them. If the server and load balancers are from different vendors, t= his might be challenging.
--------------------

I look forward to your thou= ghts.=C2=A0

Cheers,

IDs is okay" vs. "not okay, please use 0RTT when transitions occur and on= ly > one connection ID is available". > > Personally, I'd be happy if it were not optional, and I think the protoco= l > to share out a pool of connection IDs from a load balancer/load balancer > farm is not that complicated. It's not in charter for QUIC, but if we > wanted a proposal for it, I'm guessing we could knock something together = by > the Paris interim and take it to dispatch in Prague. > =E2=80=8BMy sense is that the working group believes that it is not accepta= ble for a connection ID to be reused across client initiated network changes (WiFi to Cellular). If this is accurate, then if a server did not present any additional connection IDs to a client, the client would simply tear down the connection if it changed networks, just as if it would do to TCP connections. So we can still have this "list of connection IDs" feature being optional without needing to empower clients to use the connection ID across network changes, right? I'm also not convinced that it is "not complicated" for a server to be in possession of a set of connection IDs that will map back to itself in some deployments, but I'd be happy to be wrong! --001a1147c434b4988205499b2763 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Feb 28, 2017 at 8:37 AM, Ted Hardie <ted.ietf@= gmail.com> wrote:
There are two cases we have to consider: linkability due= to a change in the network not visible to the client and linkability that = occurs because of a client-initiated change.=C2=A0 You're correct that = it cannot update the connection ID to avoid linkage when it doesn't kno= w of the change, but when the client initiates the change (e.g. moves from = WiFi to cellular), it certainly could.=C2=A0 If this feature is optional, t= hen you likely do have to have a configuration frob that the client uses to= say "re-use of connect IDs is okay" vs. "not okay, please u= se 0RTT when transitions occur and only one connection ID is available"= ;.=C2=A0

Personally, I'd be ha= ppy if it were not optional, and I think the protocol to share out a pool o= f connection IDs from a load balancer/load balancer farm is not that compli= cated. It's not in charter for QUIC, but if we wanted a proposal for it= , I'm guessing we could knock something together by the Paris interim a= nd take it to dispatch in Prague.

=E2=80=8BMy sense is that the working group believes that it is not acc= eptable for a connection ID to be reused across client initiated network ch= anges (WiFi to Cellular). If this is accurate, then if a server did not pre= sent any additional connection IDs to a client, the client would simply tea= r down the connection if it changed networks, just as if it would do to TCP= connections. So we can still have this "list of connection IDs" = feature being optional without needing to empower clients to use the connec= tion ID across network changes, right?

I'm also not convinced that it is "not complicated" for a = server to be in possession of a set of connection IDs that will map back to= itself in some deployments, but I'd be happy to be wrong!
<= /div>
--001a1147c434b4988205499b2763-- From nobody Tue Feb 28 11:20:32 2017 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 2D2E3129697 for ; Tue, 28 Feb 2017 11:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VofRD8Eys5KC for ; Tue, 28 Feb 2017 11:20:31 -0800 (PST) Received: from mail-ot0-x232.google.com (mail-ot0-x232.google.com [IPv6:2607:f8b0:4003:c0f::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 14D8F129692 for ; Tue, 28 Feb 2017 11:20:31 -0800 (PST) Received: by mail-ot0-x232.google.com with SMTP id k4so14636766otc.0 for ; Tue, 28 Feb 2017 11:20:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6MXNyFXzoVtzHDjHi8AQAxYMZ/qcHg1dkI9LL12F7Zs=; b=Xwx1B2qvKEwWkQmpbO7Rs7AlFCKv9nc4UzZ/QSb79mReMTSV50kAri6IXvfIEN2/4v 3sROQkou7wGnpydrv2ik46SlGw4iy6NJsVvaN190+gdpBb0ELPqxPso4hNeNy8q8bL2Q aLdeVWI5FiLNkgwEu2/PEl9pd6XWc2V/iGJdFHzs30JfEQz3O7wtR7xegxNpE/qDhgfl eePqu6yLDQncO2X5qHiwjGyt2oC/7E74DJG2k9jBo/UCTPvxC3AVbTzN4Kfm7GnpiuTd 8A7RlpcCEaipj0wpAVrhY4PLJEoVGhWMr08DFneEicSxFK1cKmqn0qvghDgyxrdqx7dU Ix4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6MXNyFXzoVtzHDjHi8AQAxYMZ/qcHg1dkI9LL12F7Zs=; b=bel/VRFbW/yOfBzVCGjWta37djWtA4ix55BaonXMUMAk6QDi384t6y2CudWP5igPDu zhWAD0f1BsRhQehV5ILbiKihbidkAb9/gFCYy84unbrMA0TrohvhdeN1asLrDF66ucp2 qVCVi+rw9O+gQZA2ny73u5VjL+TtW39Fyl9lc1pPBwgg7AjrvF+vvGLhcdmCZu2RGpx6 Xfqpw2doNTYNKo+MJeBKWLPuwNoOfK00Tn9+WUaUShQC0ETuFi4DsYgRh5TawbkgXDBY 0gYdYKpMeS+MWS38wLwmkj80WC2fWOixvNorPNfBROt6cm6FxR1PSVnQ7dgCxOfyW4x8 0pnQ== X-Gm-Message-State: AMke39n4YP8NvBEtf53zKvjmHiHRQvhl0NNnIGykqpMs1bXoUuU78iymiHi23TCH5DeDAwWwwvMG/5PHTGernA== X-Received: by 10.157.21.82 with SMTP id z18mr2320656otz.29.1488309630136; Tue, 28 Feb 2017 11:20:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.142.85 with HTTP; Tue, 28 Feb 2017 11:19:59 -0800 (PST) In-Reply-To: References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> From: Ted Hardie Date: Tue, 28 Feb 2017 11:19:59 -0800 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: Ryan Hamilton Content-Type: multipart/alternative; boundary=94eb2c1917a2d1fbca05499c16cc Archived-At: Cc: IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 19:20:32 -0000 --94eb2c1917a2d1fbca05499c16cc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2017 at 10:13 AM, Ryan Hamilton wrote: > > On Tue, Feb 28, 2017 at 8:37 AM, Ted Hardie wrote: > >> There are two cases we have to consider: linkability due to a change in >> the network not visible to the client and linkability that occurs becaus= e >> of a client-initiated change. You're correct that it cannot update the >> connection ID to avoid linkage when it doesn't know of the change, but w= hen >> the client initiates the change (e.g. moves from WiFi to cellular), it >> certainly could. If this feature is optional, then you likely do have t= o >> have a configuration frob that the client uses to say "re-use of connect >> IDs is okay" vs. "not okay, please use 0RTT when transitions occur and o= nly >> one connection ID is available". >> >> Personally, I'd be happy if it were not optional, and I think the >> protocol to share out a pool of connection IDs from a load balancer/load >> balancer farm is not that complicated. It's not in charter for QUIC, but= if >> we wanted a proposal for it, I'm guessing we could knock something toget= her >> by the Paris interim and take it to dispatch in Prague. >> > > =E2=80=8BMy sense is that the working group believes that it is not accep= table for > a connection ID to be reused across client initiated network changes (WiF= i > to Cellular). If this is accurate, then if a server did not present any > additional connection IDs to a client, the client would simply tear down > the connection if it changed networks, just as if it would do to TCP > connections. So we can still have this "list of connection IDs" feature > being optional without needing to empower clients to use the connection I= D > across network changes, right? > > Yes, that would be the alternate strategy. At that point, the client is not expecting the new server to have state, so it is explicitly giving that up to avoid linkability. > I'm also not convinced that it is "not complicated" for a server to be in > possession of a set of connection IDs that will map back to itself in som= e > deployments, but I'd be happy to be wrong! > Well, there are clearly proprietary solutions in this space, as well as fairly basic methods of range assignment within the full pool that work with a standard fan-out of servers behind a load balancer. They may not cover all deployments, of course. regards, Ted --94eb2c1917a2d1fbca05499c16cc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Feb 28, 2017 at 10:13 AM, Ryan Hamilton <rch@google= .com> wrote:

On Tue, Feb 28, 20= 17 at 8:37 AM, Ted Hardie <ted.ietf= @gmail.com> wrote:
There are two cases we have to consider: linkability due= to a change in the network not visible to the client and linkability that = occurs because of a client-initiated change.=C2=A0 You're correct that = it cannot update the connection ID to avoid linkage when it doesn't kno= w of the change, but when the client initiates the change (e.g. moves from = WiFi to cellular), it certainly could.=C2=A0 If this feature is optional, t= hen you likely do have to have a configuration frob that the client uses to= say "re-use of connect IDs is okay" vs. "not okay, please u= se 0RTT when transitions occur and only one connection ID is available"= ;.=C2=A0

Personally, I'd be ha= ppy if it were not optional, and I think the protocol to share out a pool o= f connection IDs from a load balancer/load balancer farm is not that compli= cated. It's not in charter for QUIC, but if we wanted a proposal for it= , I'm guessing we could knock something together by the Paris interim a= nd take it to dispatch in Prague.

<= div style=3D"font-family:"trebuchet ms",sans-serif">=E2=80=8BMy s= ense is that the working group believes that it is not acceptable for a con= nection ID to be reused across client initiated network changes (WiFi to Ce= llular). If this is accurate, then if a server did not present any addition= al connection IDs to a client, the client would simply tear down the connec= tion if it changed networks, just as if it would do to TCP connections. So = we can still have this "list of connection IDs" feature being opt= ional without needing to empower clients to use the connection ID across ne= twork changes, right?

Yes, that woul= d be the alternate strategy.=C2=A0 At that point, the client is not expecti= ng the new server to have state, so it is explicitly giving that up to avoi= d linkability.
=C2=A0
I'm also not convi= nced that it is "not complicated" for a server to be in possessio= n of a set of connection IDs that will map back to itself in some deploymen= ts, but I'd be happy to be wrong!

Well, there are cle= arly proprietary solutions in this space, as well as fairly basic methods o= f range assignment within the full pool that work with a standard fan-out o= f servers behind a load balancer.=C2=A0 They may not cover all deployments,= of course.

regards,

<= div class=3D"gmail_extra">Ted


<= /div>
--94eb2c1917a2d1fbca05499c16cc-- From nobody Tue Feb 28 11:40:30 2017 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 C539A1296AE for ; Tue, 28 Feb 2017 11:40:28 -0800 (PST) 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, HTML_MESSAGE=0.001, 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 zg6roTyLE7xU for ; Tue, 28 Feb 2017 11:40:26 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0132.outbound.protection.outlook.com [104.47.41.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743AE1296AB for ; Tue, 28 Feb 2017 11:40:26 -0800 (PST) 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=y8VACwgCo3IdsB6Lnku/VpXoThy5CLeEt9jPwgs2buk=; b=jwLGnblcI4vkQGJHUbZDsfPwwUWHT6z+iIOVOUvZj3A+XWFeNl1Hlf9HPau1+IXow3kTetQgMf0mMoH4Gp8+jjdwSkHIJXd+lE5xP+PwFgLLnsPE5dwuRlnD+lnPIDIBOj/ttp9jSheMtfF0GtSDSm5nsK2qIOXAE4u6/hOAu/s= Received: from CY4PR03MB2710.namprd03.prod.outlook.com (10.173.43.141) by CY4PR03MB2712.namprd03.prod.outlook.com (10.173.43.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.933.12; Tue, 28 Feb 2017 19:40:23 +0000 Received: from CY4PR03MB2710.namprd03.prod.outlook.com ([10.173.43.141]) by CY4PR03MB2710.namprd03.prod.outlook.com ([10.173.43.141]) with mapi id 15.01.0933.019; Tue, 28 Feb 2017 19:40:24 +0000 From: Mike Bishop To: Ted Hardie , Ryan Hamilton Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnTgidP6MC1E0yc8zksQ9LKAqF9m5CAgAAA8YCAALU8gIAATWEAgAAa8YCAABKLgIAABAbQ Date: Tue, 28 Feb 2017 19:40:23 +0000 Message-ID: References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8::51f] x-ms-office365-filtering-correlation-id: 8c750dae-3c90-473b-89c6-08d46011a393 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR03MB2712; x-microsoft-exchange-diagnostics: 1; CY4PR03MB2712; 7:cg5z0kl4qEKvAo14LK6u4siddL+RhieJTyBnXjIkDOkqEjzYw2hto94Q5HhauQ07E+AXuTqmDricJ/yU9i64yopC0dnZ4ibxn13ZTsl9CjVJ8KoWNqMoLjs1qH8iMl5ETKuBPhK211ywfZZdO8idHMMG2+7ggVOdlIBmLHDHNs+YbdtYKlBasvcTez/xMcJjQy0mSKIll0cJSHyiJtbZYv1+xvfQoPuXuBhmZMg5lLv0j2lcLsJSqunoO6dcTN6mMv2abuAQN1vhUJLMuXz3QscrHWvumOHfcMiXqFvliqyJJ8VQBfvqXTe/pOJ50ORQvB7pijEnKI4194ppdzh+PPatENacyx2lAJq8z+A4nrU= x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(211936372134217)(21748063052155)(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123558025)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:CY4PR03MB2712; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2712; x-forefront-prvs: 0232B30BBC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(39450400003)(39850400002)(39840400002)(39860400002)(39410400002)(377454003)(24454002)(7736002)(86612001)(86362001)(93886004)(8936002)(39060400002)(2900100001)(10090500001)(7696004)(3660700001)(77096006)(81166006)(8676002)(54906002)(19609705001)(236005)(6306002)(54896002)(55016002)(9686003)(5005710100001)(10290500002)(99286003)(3280700002)(122556002)(38730400002)(790700001)(6436002)(25786008)(8990500004)(54356999)(102836003)(50986999)(189998001)(76176999)(33656002)(6506006)(6116002)(92566002)(229853002)(53546006)(2950100002)(561944003)(2906002)(106116001)(6246003)(74316002)(53936002)(5660300001)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR03MB2712; H:CY4PR03MB2710.namprd03.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR03MB27105305B41743510094BE5287560CY4PR03MB2710namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2017 19:40:23.7823 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2712 Archived-At: Cc: IETF QUIC WG , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 19:40:28 -0000 --_000_CY4PR03MB27105305B41743510094BE5287560CY4PR03MB2710namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCBidXQgdGhlIHByb2JsZW0gaXMgZGVhbGluZyB3aXRoIGEgc2l0dWF0aW9uIHdoZXJlIHRo ZSBsb2FkIGJhbGFuY2VyIGFuZCB0aGUgc2VydmVyIGFyZSBpbmRlcGVuZGVudGx5IG1hbmFnZWQs IGFzIGluIGEgaG9zdGluZyBlbnZpcm9ubWVudC4gIFRoZXJlIHdvdWxkIG5lZWQgdG8gYmUgc29t ZXRoaW5nIHN0YW5kYXJkaXplZC4gIChPZiBjb3Vyc2UsIGlmIHRoZSBsb2FkIGJhbGFuY2VyIGNh biBiZSBzdGF0ZWZ1bCwgaXQgZG9lc27igJl0IG5lZWQgbmVhcmx5IGFzIG11Y2ggb2YgdGhpcyBt YWNoaW5lcnkuKQ0KDQpUaGUgb3RoZXIgaXNzdWUgdGhhdCB3YXMgcG9pbnRlZCBvdXQgdG8gbWUg Ynkgb25lIG9mIG91ciBTTEIgZ3V5cyBpcyB0aGF0IHRoZSBsb2FkIGJhbGFuY2VyIG9ubHkgc2Vl cyBwYWNrZXRzIGluIHRoZSBjbGllbnQtdG8tc2VydmVyIGRpcmVjdGlvbiwgbm90IHRoZSBzZXJ2 ZXLigJlzIHJlc3BvbnNlcy4gIFNvIGEgQ29ubmVjdGlvbiBJRCBjaGFuZ2UgcHJvcG9zZWQgYnkg dGhlIHNlcnZlciBpcyBpbnZpc2libGUgdG8gdGhlIGxvYWQgYmFsYW5jZXIgdW50aWwgaXQgc2Vl cyBhIGZ1dHVyZSBjbGllbnQgcGFja2V0IHdpdGggdGhlIHNhbWUgNC10dXBsZSBhbmQgYSBkaWZm ZXJlbnQgY29ubmVjdGlvbiBJRC4gIEJ1dCBzaW1wbHkgYWxsb3dpbmcgcGFja2V0cyBmcm9tIHRo ZSBzYW1lIHNvdXJjZSB3aXRoIGEgZGlmZmVyZW50IElEIHRvIGluZm9ybSB0aGUgbG9hZCBiYWxh bmNlciBvZiBhbiBJRCBjaGFuZ2Ugc2VlbXMgcmlwZSBmb3IgYXR0YWNrIGJ5IHNwb29maW5nIHRo ZSBzb3VyY2Ug4oCTIHdl4oCZZCBuZWVkIHRvIHRpZ2h0bHkgc2NvcGUgaG93IGEgbG9hZCBiYWxh bmNlciBjYW4gaWRlbnRpZnkgdGhhdCBzYWZlbHkuICBJdCBhbHNvIG1lYW5zIHRoYXQgb3VyIGFn cmVlbWVudCB0aGF0IGNsaWVudCBJUC9wb3J0IGNhbuKAmXQgY2hhbmdlIOKAnGR1cmluZyB0aGUg aGFuZHNoYWtl4oCdIGFjdHVhbGx5IGhhcyB0byBleHRlbmQgdW50aWwgdGhlIHNlcnZlciBoYXMg cmVjZWl2ZWQgcGFja2V0cyB3aXRoIHRoZSBuZXcgY29ubmVjdGlvbiBJRC4NCg0KRnJvbTogUVVJ QyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFRlZCBIYXJkaWUN ClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE3IDExOjIwIEFNDQpUbzogUnlhbiBIYW1p bHRvbiA8cmNoQGdvb2dsZS5jb20+DQpDYzogSUVURiBRVUlDIFdHIDxxdWljQGlldGYub3JnPjsg TWlyamEgS8O8aGxld2luZCA8bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaD4NClN1Ympl Y3Q6IFJlOiBXaGVuIHNob3VsZCBzZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSURzIGJlIHNlbnQg YW5kIGhvdyBhcmUgdGhleSBpbmRpY2F0ZWQ/DQoNCk9uIFR1ZSwgRmViIDI4LCAyMDE3IGF0IDEw OjEzIEFNLCBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbTxtYWlsdG86cmNoQGdvb2dsZS5j b20+PiB3cm90ZToNCg0KT24gVHVlLCBGZWIgMjgsIDIwMTcgYXQgODozNyBBTSwgVGVkIEhhcmRp ZSA8dGVkLmlldGZAZ21haWwuY29tPG1haWx0bzp0ZWQuaWV0ZkBnbWFpbC5jb20+PiB3cm90ZToN ClRoZXJlIGFyZSB0d28gY2FzZXMgd2UgaGF2ZSB0byBjb25zaWRlcjogbGlua2FiaWxpdHkgZHVl IHRvIGEgY2hhbmdlIGluIHRoZSBuZXR3b3JrIG5vdCB2aXNpYmxlIHRvIHRoZSBjbGllbnQgYW5k IGxpbmthYmlsaXR5IHRoYXQgb2NjdXJzIGJlY2F1c2Ugb2YgYSBjbGllbnQtaW5pdGlhdGVkIGNo YW5nZS4gIFlvdSdyZSBjb3JyZWN0IHRoYXQgaXQgY2Fubm90IHVwZGF0ZSB0aGUgY29ubmVjdGlv biBJRCB0byBhdm9pZCBsaW5rYWdlIHdoZW4gaXQgZG9lc24ndCBrbm93IG9mIHRoZSBjaGFuZ2Us IGJ1dCB3aGVuIHRoZSBjbGllbnQgaW5pdGlhdGVzIHRoZSBjaGFuZ2UgKGUuZy4gbW92ZXMgZnJv bSBXaUZpIHRvIGNlbGx1bGFyKSwgaXQgY2VydGFpbmx5IGNvdWxkLiAgSWYgdGhpcyBmZWF0dXJl IGlzIG9wdGlvbmFsLCB0aGVuIHlvdSBsaWtlbHkgZG8gaGF2ZSB0byBoYXZlIGEgY29uZmlndXJh dGlvbiBmcm9iIHRoYXQgdGhlIGNsaWVudCB1c2VzIHRvIHNheSAicmUtdXNlIG9mIGNvbm5lY3Qg SURzIGlzIG9rYXkiIHZzLiAibm90IG9rYXksIHBsZWFzZSB1c2UgMFJUVCB3aGVuIHRyYW5zaXRp b25zIG9jY3VyIGFuZCBvbmx5IG9uZSBjb25uZWN0aW9uIElEIGlzIGF2YWlsYWJsZSIuDQpQZXJz b25hbGx5LCBJJ2QgYmUgaGFwcHkgaWYgaXQgd2VyZSBub3Qgb3B0aW9uYWwsIGFuZCBJIHRoaW5r IHRoZSBwcm90b2NvbCB0byBzaGFyZSBvdXQgYSBwb29sIG9mIGNvbm5lY3Rpb24gSURzIGZyb20g YSBsb2FkIGJhbGFuY2VyL2xvYWQgYmFsYW5jZXIgZmFybSBpcyBub3QgdGhhdCBjb21wbGljYXRl ZC4gSXQncyBub3QgaW4gY2hhcnRlciBmb3IgUVVJQywgYnV0IGlmIHdlIHdhbnRlZCBhIHByb3Bv c2FsIGZvciBpdCwgSSdtIGd1ZXNzaW5nIHdlIGNvdWxkIGtub2NrIHNvbWV0aGluZyB0b2dldGhl ciBieSB0aGUgUGFyaXMgaW50ZXJpbSBhbmQgdGFrZSBpdCB0byBkaXNwYXRjaCBpbiBQcmFndWUu DQoNCuKAi015IHNlbnNlIGlzIHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgYmVsaWV2ZXMgdGhhdCBp dCBpcyBub3QgYWNjZXB0YWJsZSBmb3IgYSBjb25uZWN0aW9uIElEIHRvIGJlIHJldXNlZCBhY3Jv c3MgY2xpZW50IGluaXRpYXRlZCBuZXR3b3JrIGNoYW5nZXMgKFdpRmkgdG8gQ2VsbHVsYXIpLiBJ ZiB0aGlzIGlzIGFjY3VyYXRlLCB0aGVuIGlmIGEgc2VydmVyIGRpZCBub3QgcHJlc2VudCBhbnkg YWRkaXRpb25hbCBjb25uZWN0aW9uIElEcyB0byBhIGNsaWVudCwgdGhlIGNsaWVudCB3b3VsZCBz aW1wbHkgdGVhciBkb3duIHRoZSBjb25uZWN0aW9uIGlmIGl0IGNoYW5nZWQgbmV0d29ya3MsIGp1 c3QgYXMgaWYgaXQgd291bGQgZG8gdG8gVENQIGNvbm5lY3Rpb25zLiBTbyB3ZSBjYW4gc3RpbGwg aGF2ZSB0aGlzICJsaXN0IG9mIGNvbm5lY3Rpb24gSURzIiBmZWF0dXJlIGJlaW5nIG9wdGlvbmFs IHdpdGhvdXQgbmVlZGluZyB0byBlbXBvd2VyIGNsaWVudHMgdG8gdXNlIHRoZSBjb25uZWN0aW9u IElEIGFjcm9zcyBuZXR3b3JrIGNoYW5nZXMsIHJpZ2h0Pw0KDQpZZXMsIHRoYXQgd291bGQgYmUg dGhlIGFsdGVybmF0ZSBzdHJhdGVneS4gIEF0IHRoYXQgcG9pbnQsIHRoZSBjbGllbnQgaXMgbm90 IGV4cGVjdGluZyB0aGUgbmV3IHNlcnZlciB0byBoYXZlIHN0YXRlLCBzbyBpdCBpcyBleHBsaWNp dGx5IGdpdmluZyB0aGF0IHVwIHRvIGF2b2lkIGxpbmthYmlsaXR5Lg0KDQpJJ20gYWxzbyBub3Qg Y29udmluY2VkIHRoYXQgaXQgaXMgIm5vdCBjb21wbGljYXRlZCIgZm9yIGEgc2VydmVyIHRvIGJl IGluIHBvc3Nlc3Npb24gb2YgYSBzZXQgb2YgY29ubmVjdGlvbiBJRHMgdGhhdCB3aWxsIG1hcCBi YWNrIHRvIGl0c2VsZiBpbiBzb21lIGRlcGxveW1lbnRzLCBidXQgSSdkIGJlIGhhcHB5IHRvIGJl IHdyb25nIQ0KDQpXZWxsLCB0aGVyZSBhcmUgY2xlYXJseSBwcm9wcmlldGFyeSBzb2x1dGlvbnMg aW4gdGhpcyBzcGFjZSwgYXMgd2VsbCBhcyBmYWlybHkgYmFzaWMgbWV0aG9kcyBvZiByYW5nZSBh c3NpZ25tZW50IHdpdGhpbiB0aGUgZnVsbCBwb29sIHRoYXQgd29yayB3aXRoIGEgc3RhbmRhcmQg ZmFuLW91dCBvZiBzZXJ2ZXJzIGJlaGluZCBhIGxvYWQgYmFsYW5jZXIuICBUaGV5IG1heSBub3Qg Y292ZXIgYWxsIGRlcGxveW1lbnRzLCBvZiBjb3Vyc2UuDQpyZWdhcmRzLA0KVGVkDQoNCg== --_000_CY4PR03MB27105305B41743510094BE5287560CY4PR03MB2710namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiVHJlYnVjaGV0IE1TIjsNCglwYW5vc2Ut MToyIDExIDYgMyAyIDIgMiAyIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAu bXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5h bWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZv bnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlllcywgYnV0IHRoZSBwcm9ibGVtIGlzIGRlYWxpbmcgd2l0aCBh IHNpdHVhdGlvbiB3aGVyZSB0aGUgbG9hZCBiYWxhbmNlciBhbmQgdGhlIHNlcnZlciBhcmUgaW5k ZXBlbmRlbnRseSBtYW5hZ2VkLCBhcyBpbiBhIGhvc3RpbmcgZW52aXJvbm1lbnQuJm5ic3A7IFRo ZXJlIHdvdWxkIG5lZWQgdG8gYmUgc29tZXRoaW5nIHN0YW5kYXJkaXplZC4mbmJzcDsgKE9mIGNv dXJzZSwgaWYgdGhlIGxvYWQgYmFsYW5jZXIgY2FuIGJlIHN0YXRlZnVsLA0KIGl0IGRvZXNu4oCZ dCBuZWVkIG5lYXJseSBhcyBtdWNoIG9mIHRoaXMgbWFjaGluZXJ5Lik8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+VGhlIG90aGVyIGlzc3VlIHRoYXQgd2FzIHBvaW50ZWQgb3V0IHRvIG1lIGJ5IG9u ZSBvZiBvdXIgU0xCIGd1eXMgaXMgdGhhdCB0aGUgbG9hZCBiYWxhbmNlciBvbmx5IHNlZXMgcGFj a2V0cyBpbiB0aGUgY2xpZW50LXRvLXNlcnZlciBkaXJlY3Rpb24sIG5vdCB0aGUgc2VydmVy4oCZ cyByZXNwb25zZXMuJm5ic3A7IFNvIGEgQ29ubmVjdGlvbiBJRCBjaGFuZ2UgcHJvcG9zZWQgYnkg dGhlIHNlcnZlciBpcyBpbnZpc2libGUNCiB0byB0aGUgbG9hZCBiYWxhbmNlciB1bnRpbCBpdCBz ZWVzIGEgZnV0dXJlIGNsaWVudCBwYWNrZXQgd2l0aCB0aGUgc2FtZSA0LXR1cGxlIGFuZCBhIGRp ZmZlcmVudCBjb25uZWN0aW9uIElELiZuYnNwOyBCdXQgc2ltcGx5IGFsbG93aW5nIHBhY2tldHMg ZnJvbSB0aGUgc2FtZSBzb3VyY2Ugd2l0aCBhIGRpZmZlcmVudCBJRCB0byBpbmZvcm0gdGhlIGxv YWQgYmFsYW5jZXIgb2YgYW4gSUQgY2hhbmdlIHNlZW1zIHJpcGUgZm9yIGF0dGFjayBieSBzcG9v ZmluZw0KIHRoZSBzb3VyY2Ug4oCTIHdl4oCZZCBuZWVkIHRvIHRpZ2h0bHkgc2NvcGUgaG93IGEg bG9hZCBiYWxhbmNlciBjYW4gaWRlbnRpZnkgdGhhdCBzYWZlbHkuJm5ic3A7IEl0IGFsc28gbWVh bnMgdGhhdCBvdXIgYWdyZWVtZW50IHRoYXQgY2xpZW50IElQL3BvcnQgY2Fu4oCZdCBjaGFuZ2Ug 4oCcZHVyaW5nIHRoZSBoYW5kc2hha2XigJ0gYWN0dWFsbHkgaGFzIHRvIGV4dGVuZCB1bnRpbCB0 aGUgc2VydmVyIGhhcyByZWNlaXZlZCBwYWNrZXRzIHdpdGggdGhlIG5ldyBjb25uZWN0aW9uDQog SUQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5UZWQgSGFyZGllPGJyPg0K PGI+U2VudDo8L2I+IFR1ZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE3IDExOjIwIEFNPGJyPg0KPGI+ VG86PC9iPiBSeWFuIEhhbWlsdG9uICZsdDtyY2hAZ29vZ2xlLmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IElFVEYgUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IE1pcmphIEvDvGhsZXdpbmQg Jmx0O21pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2gmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJlOiBXaGVuIHNob3VsZCBzZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSURzIGJlIHNlbnQg YW5kIGhvdyBhcmUgdGhleSBpbmRpY2F0ZWQ/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PbiBUdWUsIEZlYiAyOCwgMjAxNyBhdCAxMDoxMyBBTSwgUnlhbiBIYW1pbHRvbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJjaEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+cmNoQGdvb2dsZS5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBGZWIgMjgsIDIwMTcgYXQg ODozNyBBTSwgVGVkIEhhcmRpZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnRlZC5pZXRmQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPnRlZC5pZXRmQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0 LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPlRoZXJlIGFyZSB0d28gY2FzZXMgd2UgaGF2ZSB0byBj b25zaWRlcjogbGlua2FiaWxpdHkgZHVlIHRvIGEgY2hhbmdlIGluIHRoZSBuZXR3b3JrIG5vdCB2 aXNpYmxlIHRvIHRoZSBjbGllbnQgYW5kIGxpbmthYmlsaXR5IHRoYXQgb2NjdXJzIGJlY2F1c2Ug b2YgYSBjbGllbnQtaW5pdGlhdGVkIGNoYW5nZS4mbmJzcDsgWW91J3JlIGNvcnJlY3QgdGhhdCBp dCBjYW5ub3QNCiB1cGRhdGUgdGhlIGNvbm5lY3Rpb24gSUQgdG8gYXZvaWQgbGlua2FnZSB3aGVu IGl0IGRvZXNuJ3Qga25vdyBvZiB0aGUgY2hhbmdlLCBidXQgd2hlbiB0aGUgY2xpZW50IGluaXRp YXRlcyB0aGUgY2hhbmdlIChlLmcuIG1vdmVzIGZyb20gV2lGaSB0byBjZWxsdWxhciksIGl0IGNl cnRhaW5seSBjb3VsZC4mbmJzcDsgSWYgdGhpcyBmZWF0dXJlIGlzIG9wdGlvbmFsLCB0aGVuIHlv dSBsaWtlbHkgZG8gaGF2ZSB0byBoYXZlIGEgY29uZmlndXJhdGlvbiBmcm9iDQogdGhhdCB0aGUg Y2xpZW50IHVzZXMgdG8gc2F5ICZxdW90O3JlLXVzZSBvZiBjb25uZWN0IElEcyBpcyBva2F5JnF1 b3Q7IHZzLiAmcXVvdDtub3Qgb2theSwgcGxlYXNlIHVzZSAwUlRUIHdoZW4gdHJhbnNpdGlvbnMg b2NjdXIgYW5kIG9ubHkgb25lIGNvbm5lY3Rpb24gSUQgaXMgYXZhaWxhYmxlJnF1b3Q7LiZuYnNw Ow0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q ZXJzb25hbGx5LCBJJ2QgYmUgaGFwcHkgaWYgaXQgd2VyZSBub3Qgb3B0aW9uYWwsIGFuZCBJIHRo aW5rIHRoZSBwcm90b2NvbCB0byBzaGFyZSBvdXQgYSBwb29sIG9mIGNvbm5lY3Rpb24gSURzIGZy b20gYSBsb2FkIGJhbGFuY2VyL2xvYWQgYmFsYW5jZXIgZmFybSBpcyBub3QgdGhhdCBjb21wbGlj YXRlZC4gSXQncyBub3QgaW4gY2hhcnRlciBmb3IgUVVJQywgYnV0IGlmIHdlIHdhbnRlZCBhIHBy b3Bvc2FsDQogZm9yIGl0LCBJJ20gZ3Vlc3Npbmcgd2UgY291bGQga25vY2sgc29tZXRoaW5nIHRv Z2V0aGVyIGJ5IHRoZSBQYXJpcyBpbnRlcmltIGFuZCB0YWtlIGl0IHRvIGRpc3BhdGNoIGluIFBy YWd1ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPuKAizwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 VHJlYnVjaGV0IE1TJnF1b3Q7LHNhbnMtc2VyaWYiPk15IHNlbnNlIGlzIHRoYXQgdGhlIHdvcmtp bmcgZ3JvdXAgYmVsaWV2ZXMgdGhhdCBpdCBpcyBub3QgYWNjZXB0YWJsZSBmb3IgYSBjb25uZWN0 aW9uIElEIHRvIGJlIHJldXNlZCBhY3Jvc3MgY2xpZW50IGluaXRpYXRlZCBuZXR3b3JrDQogY2hh bmdlcyAoV2lGaSB0byBDZWxsdWxhcikuIElmIHRoaXMgaXMgYWNjdXJhdGUsIHRoZW4gaWYgYSBz ZXJ2ZXIgZGlkIG5vdCBwcmVzZW50IGFueSBhZGRpdGlvbmFsIGNvbm5lY3Rpb24gSURzIHRvIGEg Y2xpZW50LCB0aGUgY2xpZW50IHdvdWxkIHNpbXBseSB0ZWFyIGRvd24gdGhlIGNvbm5lY3Rpb24g aWYgaXQgY2hhbmdlZCBuZXR3b3JrcywganVzdCBhcyBpZiBpdCB3b3VsZCBkbyB0byBUQ1AgY29u bmVjdGlvbnMuIFNvIHdlIGNhbiBzdGlsbA0KIGhhdmUgdGhpcyAmcXVvdDtsaXN0IG9mIGNvbm5l Y3Rpb24gSURzJnF1b3Q7IGZlYXR1cmUgYmVpbmcgb3B0aW9uYWwgd2l0aG91dCBuZWVkaW5nIHRv IGVtcG93ZXIgY2xpZW50cyB0byB1c2UgdGhlIGNvbm5lY3Rpb24gSUQgYWNyb3NzIG5ldHdvcmsg Y2hhbmdlcywgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1RyZWJ1Y2hl dCBNUyZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5ZZXMsIHRoYXQgd291bGQgYmUgdGhlIGFsdGVybmF0ZSBzdHJhdGVneS4m bmJzcDsgQXQgdGhhdCBwb2ludCwgdGhlIGNsaWVudCBpcyBub3QgZXhwZWN0aW5nIHRoZSBuZXcg c2VydmVyIHRvIGhhdmUgc3RhdGUsIHNvIGl0IGlzIGV4cGxpY2l0bHkgZ2l2aW5nIHRoYXQgdXAg dG8gYXZvaWQgbGlua2FiaWxpdHkuDQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2tx dW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtw YWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDow aW4iPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtUcmVidWNoZXQgTVMmcXVvdDssc2Fucy1zZXJp ZiI+SSdtIGFsc28gbm90IGNvbnZpbmNlZCB0aGF0IGl0IGlzICZxdW90O25vdCBjb21wbGljYXRl ZCZxdW90OyBmb3IgYSBzZXJ2ZXIgdG8gYmUgaW4gcG9zc2Vzc2lvbiBvZiBhIHNldCBvZiBjb25u ZWN0aW9uIElEcyB0aGF0IHdpbGwgbWFwIGJhY2sgdG8gaXRzZWxmIGluIHNvbWUgZGVwbG95bWVu dHMsIGJ1dCBJJ2QgYmUgaGFwcHkgdG8gYmUNCiB3cm9uZyE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPldlbGws IHRoZXJlIGFyZSBjbGVhcmx5IHByb3ByaWV0YXJ5IHNvbHV0aW9ucyBpbiB0aGlzIHNwYWNlLCBh cyB3ZWxsIGFzIGZhaXJseSBiYXNpYyBtZXRob2RzIG9mIHJhbmdlIGFzc2lnbm1lbnQgd2l0aGlu IHRoZSBmdWxsIHBvb2wgdGhhdCB3b3JrIHdpdGggYSBzdGFuZGFyZCBmYW4tb3V0IG9mIHNlcnZl cnMgYmVoaW5kIGEgbG9hZCBiYWxhbmNlci4mbmJzcDsgVGhleQ0KIG1heSBub3QgY292ZXIgYWxs IGRlcGxveW1lbnRzLCBvZiBjb3Vyc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPnJlZ2FyZHMs PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UZWQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_CY4PR03MB27105305B41743510094BE5287560CY4PR03MB2710namp_-- From nobody Tue Feb 28 12:05:48 2017 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 918E01296AE for ; Tue, 28 Feb 2017 12:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham 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 AW7QVXsINzU9 for ; Tue, 28 Feb 2017 12:05:45 -0800 (PST) Received: from virgo02.ee.ethz.ch (virgo02.ee.ethz.ch [129.132.72.10]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE3281296AA for ; Tue, 28 Feb 2017 12:05:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3vXqMD28h6z15Mk2; Tue, 28 Feb 2017 21:05:44 +0100 (CET) X-Virus-Scanned: Debian amavisd-new at virgo02.ee.ethz.ch Received: from virgo02.ee.ethz.ch ([127.0.0.1]) by localhost (virgo02.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eP-fQf1hxM_t; Tue, 28 Feb 2017 21:05:42 +0100 (CET) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC2BB4.dip0.t-ipconnect.de [93.236.43.180]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Tue, 28 Feb 2017 21:05:42 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: Date: Tue, 28 Feb 2017 21:05:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> To: Mike Bishop X-Mailer: Apple Mail (2.3259) Archived-At: Cc: Ted Hardie , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:05:47 -0000 Even if the load balancer could see the traffic in the other direction, = the new connection ids should not be exposed to the path (aka this = information must be encrypted), otherwise it=E2=80=99s still linkable.=20= If you want to avoid additional signaling (which could be done if the = load balancer and the server have some kind of trust relationship), then = both need to know the algorithm that is used to create the additional = ids. If you don=E2=80=99t have any trust relationship (neither for = signaling, nor for some kind of initial configuration) than you are the = kind of middlebox that we don=E2=80=99t want to be able to link = different connections together. Mirja > Am 28.02.2017 um 20:40 schrieb Mike Bishop = : >=20 > Yes, but the problem is dealing with a situation where the load = balancer and the server are independently managed, as in a hosting = environment. There would need to be something standardized. (Of = course, if the load balancer can be stateful, it doesn=E2=80=99t need = nearly as much of this machinery.) >=20 >=20 >=20 > The other issue that was pointed out to me by one of our SLB guys is = that the load balancer only sees packets in the client-to-server = direction, not the server=E2=80=99s responses. So a Connection ID = change proposed by the server is invisible to the load balancer until it = sees a future client packet with the same 4-tuple and a different = connection ID. But simply allowing packets from the same source with a = different ID to inform the load balancer of an ID change seems ripe for = attack by spoofing the source =E2=80=93 we=E2=80=99d need to tightly = scope how a load balancer can identify that safely. It also means that = our agreement that client IP/port can=E2=80=99t change =E2=80=9Cduring = the handshake=E2=80=9D actually has to extend until the server has = received packets with the new connection ID. >=20 >=20 >=20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ted Hardie > Sent: Tuesday, February 28, 2017 11:20 AM > To: Ryan Hamilton > Cc: IETF QUIC WG ; Mirja K=C3=BChlewind = > Subject: Re: When should server-chosen connection IDs be sent and how = are they indicated? >=20 >=20 >=20 > On Tue, Feb 28, 2017 at 10:13 AM, Ryan Hamilton = wrote: >=20 >=20 >=20 > On Tue, Feb 28, 2017 at 8:37 AM, Ted Hardie = wrote: >=20 > There are two cases we have to consider: linkability due to a change = in the network not visible to the client and linkability that occurs = because of a client-initiated change. You're correct that it cannot = update the connection ID to avoid linkage when it doesn't know of the = change, but when the client initiates the change (e.g. moves from WiFi = to cellular), it certainly could. If this feature is optional, then you = likely do have to have a configuration frob that the client uses to say = "re-use of connect IDs is okay" vs. "not okay, please use 0RTT when = transitions occur and only one connection ID is available".=20 >=20 > Personally, I'd be happy if it were not optional, and I think the = protocol to share out a pool of connection IDs from a load balancer/load = balancer farm is not that complicated. It's not in charter for QUIC, but = if we wanted a proposal for it, I'm guessing we could knock something = together by the Paris interim and take it to dispatch in Prague. >=20 >=20 >=20 > =E2=80=8BMy sense is that the working group believes that it is not = acceptable for a connection ID to be reused across client initiated = network changes (WiFi to Cellular). If this is accurate, then if a = server did not present any additional connection IDs to a client, the = client would simply tear down the connection if it changed networks, = just as if it would do to TCP connections. So we can still have this = "list of connection IDs" feature being optional without needing to = empower clients to use the connection ID across network changes, right? >=20 >=20 >=20 > Yes, that would be the alternate strategy. At that point, the client = is not expecting the new server to have state, so it is explicitly = giving that up to avoid linkability. >=20 >=20 >=20 > I'm also not convinced that it is "not complicated" for a server to be = in possession of a set of connection IDs that will map back to itself in = some deployments, but I'd be happy to be wrong! >=20 >=20 >=20 > Well, there are clearly proprietary solutions in this space, as well = as fairly basic methods of range assignment within the full pool that = work with a standard fan-out of servers behind a load balancer. They = may not cover all deployments, of course. >=20 > regards, >=20 > Ted >=20 >=20 >=20 From nobody Tue Feb 28 12:24:46 2017 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 254271296C4 for ; Tue, 28 Feb 2017 12:24:45 -0800 (PST) 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, 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 (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKtdaGkAfFY7 for ; Tue, 28 Feb 2017 12:24:43 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 537311296C0 for ; Tue, 28 Feb 2017 12:24:43 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id n186so36061456qkb.3 for ; Tue, 28 Feb 2017 12:24:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kwy/Km3SHfwaOtv0ChaEk/zslRfcrfM5qdzHyt6XGhQ=; b=AXeHl1DYFHVH3aeuiGVwgA2IKbY6/Vp/jRCzIAZe/h7FA2nwasRKkB15rYbnET3GcE ShShVjJKQQcOfyc4TEOHmcRMlz/PbvPlCLetgLzXU0BAia2OA4HaWjdMO6KZKE47toyj /c4Gn/pw26HjWtCPkVWHc3XdXwB7SqWQEJVzo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kwy/Km3SHfwaOtv0ChaEk/zslRfcrfM5qdzHyt6XGhQ=; b=eH+sFedX7fny+r++uRuGPGNTFu17mXs8e8Wpd1IdyDpQ+mJ3wW5fs90krhC1XchLf5 KRghuzaCGrRv2KFYGA13JOzG1UZObqwiuNm+01Eq8Bf2TtMz07Sbvz+1QvsuKZykW0QF 3Q4NL0lmwvWXmRM1tvF3uwHE3T5XLDVCvYpkV1LfD37c8PNQjO6pDNUQqYFkl43h1OO0 XW1RlWdPcOo/e9b6mzJUfmGKl3UYPZ+9dKv8Wo7cAlMcrqLgbTMMhW1wLLFYLFsA+y7o WeRxhbAQa36c9XvKh5OR4l7gE/wlihcVAiIUO/0J+f9zWjbevoFIBgQ0/CprQx3bWgDG T+uA== X-Gm-Message-State: AMke39mLxCyImOWbuKHdFxJtgR51aJDjIcvsMZ6wuwdL/LN5LUEosX0Wc7LAVIAzgZD/ZxBnzVcM8YXLOUQUxg== X-Received: by 10.55.69.72 with SMTP id s69mr5319346qka.21.1488313482298; Tue, 28 Feb 2017 12:24:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Tue, 28 Feb 2017 12:24:41 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> From: Kyle Rose Date: Tue, 28 Feb 2017 15:24:41 -0500 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Content-Type: multipart/alternative; boundary=001a114ac8746d995005499cfcf4 Archived-At: Cc: Mike Bishop , Ted Hardie , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:24:45 -0000 --001a114ac8746d995005499cfcf4 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Feb 28, 2017 at 3:05 PM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Even if the load balancer could see the traffic in the other direction, > the new connection ids should not be exposed to the path (aka this > information must be encrypted), otherwise it=E2=80=99s still linkable. > > If you want to avoid additional signaling (which could be done if the loa= d > balancer and the server have some kind of trust relationship), then both > need to know the algorithm that is used to create the additional ids. If > you don=E2=80=99t have any trust relationship (neither for signaling, nor= for some > kind of initial configuration) than you are the kind of middlebox that we > don=E2=80=99t want to be able to link different connections together. > Whenever I've thought about this problem, it always comes back to indexing: since the whole goal is to figure out the connection context (including encryption key, something probably completely unknown to the load balancer) from some plaintext signal that must be different in each packet, the system needs one of the following: (1) A sufficient, but presumably limited, table of IDs that index to connections (sized perhaps on the basis of # of packets in flight), plus the ability to reuse IDs or otherwise re-synchronize (e.g., fall back to PKC) in case of packet loss (2) A shared ID generation algorithm that may only be computed by endpoints, plus some recovery algorithm in case of de-synchronization (e.g., due to packet reordering) (3) PKC (expensive on a per-packet basis) In practice, there may be little enough reordering that with some reasonable window (say 2x # packets in flight worth of IDs), reasonable heuristics around use of IDs to prevent de-synchronization, and loss-recovery that simply doesn't care about packets that are too out-of-order, that PKC fallback would be rare. Kyle --001a114ac8746d995005499cfcf4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Feb 28, 2017 at 3:05 PM, Mirja K=C3=BChlewind <mirja.kue= hlewind@tik.ee.ethz.ch> wrote:
Even if the load balancer could see the traffic in the other direction,= the new connection ids should not be exposed to the path (aka this informa= tion must be encrypted), otherwise it=E2=80=99s still linkable.

If you want to avoid additional signaling (which could be done if the load = balancer and the server have some kind of trust relationship), then both ne= ed to know the algorithm that is used to create the additional ids. If you = don=E2=80=99t have any trust relationship (neither for signaling, nor for s= ome kind of initial configuration) than you are the kind of middlebox that = we don=E2=80=99t want to be able to link different connections together.

Whenever I&#= 39;ve thought about this problem, it always comes back to indexing: since t= he whole goal is to figure out the connection context (including encryption= key, something probably completely unknown to the load balancer) from some= plaintext signal that must be different in each packet, the system needs o= ne of the following:

(1) A sufficient, but presumably limited, table= of IDs that index to connections (sized perhaps on the basis of # of packe= ts in flight), plus the ability to reuse IDs or otherwise re-synchronize (e= .g., fall back to PKC) in case of packet loss
(2) A shared ID= generation algorithm that may only be computed by endpoints, plus some rec= overy algorithm in case of de-synchronization (e.g., due to packet reorderi= ng)
(3) PKC (expensive on a per-packet basis)
<= br>
In practice, there may be little enough reordering that with = some reasonable window (say 2x # packets in flight worth of IDs), reasonabl= e heuristics around use of IDs to prevent de-synchronization, and loss-reco= very that simply doesn't care about packets that are too out-of-order, = that PKC fallback would be rare.

Kyle
--001a114ac8746d995005499cfcf4-- From nobody Tue Feb 28 12:26:57 2017 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 0D6A41296C7 for ; Tue, 28 Feb 2017 12:26:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.702 X-Spam-Level: X-Spam-Status: No, score=-2.702 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=-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=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 G9E0-cz3vAJo for ; Tue, 28 Feb 2017 12:26:54 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 66EFE1296C6 for ; Tue, 28 Feb 2017 12:26:54 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C5A7543343B; Tue, 28 Feb 2017 20:26:53 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AF7A843340E; Tue, 28 Feb 2017 20:26:53 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488313613; bh=RFEGhPA2flqn0gFdp+yVsCkhFD1lMSH1/46l5u+Cmrw=; l=7542; h=From:To:CC:Date:References:In-Reply-To:From; b=Qq0wwoes0pnp/zgqTEkV8U+juDUnj5GhO1sNoDWwbHBRfYfjPIZDNdssRMpRVI4bo du3PmNMetmOx4985mUTSEZLwGnhTcKl3xFVIshmddp546E2b1YUTQH+jxU86Lufx9L aR+6tF4dcqDFj3fgcpTASjU3YcsPtn2MLc/KKbzU= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id A34251FC94; Tue, 28 Feb 2017 20:26:53 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Feb 2017 15:26:53 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Tue, 28 Feb 2017 15:26:53 -0500 From: "Lubashev, Igor" To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= , Mike Bishop Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnUFyvCyJf5LkySP9zxgM+hCaF972KAgAAA8YCAALU8gIAATWEAgAAa8ICAABKLgIAABbOAgAAHEQD//7B+YA== Date: Tue, 28 Feb 2017 20:26:52 +0000 Message-ID: <4c4f3578acab4b2d8f43c75cf88a5197@usma1ex-dag1mb5.msg.corp.akamai.com> References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> In-Reply-To: <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> 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.34.129] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Ted Hardie , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:26:56 -0000 V2hlbiBsYWQgYmFsYW5jZXJzIGFuZCB0aGUgc2VydmVycyBhcmUgd29ya2luZyB0b2dldGhlciwg dGhlIHNlcnZlciBwaWNrcyB0aGUgQ29ubmVjdGlvbiBJRCB0aGF0IGVuY29kZXMgaXRzIGlkZW50 aXR5IGZvciB0aGUgbG9hZCBiYWxhbmNlci4gIEluIHRoZSBkZWdlbmVyYXRlIGNhc2UsICIxMCBN U0JzIG9mIGEgQ29ubmVjdGlvbiBJRCBpcyB0aGUgU2VydmVyIElEIi4gIEl0IGlzIHZlcnkgZWFz eSBmb3IgYSBTZXJ2ZXIgdG8gZ2VuZXJhdGUgYSBoYW5kZnVsIG9mIHN1Y2ggSURzIHRoYXQgd2ls bCBhbGwgcG9pbnQgdG8gaXRzZWxmLg0KDQpUaGVyZSBpcyBubyBkaXJlY3Qgc2lnbmFsIHRoYXQg Y2FuIHRpZSB0aGVzZSBDb25uZWN0aW9uIElEcyB0b2dldGhlciBvdGhlciB0aGFuIHRoZXkgYXJl IGFsbCBwb2ludGluZyBhdCB0aGUgc2FtZSBzZXJ2ZXIuICBJdCBpcyBvbmx5IHNsaWdodGx5IG1v cmUgYml0cyBvZiBpbmZvcm1hdGlvbiB0aGFuIGlzIGNvbnRhaW5lZCBpbiB0aGUgZGVzdC1pcCBv ZiB0aGUgcGFja2V0Lg0KDQotIElnb3INCg0KIA0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N CkZyb206IE1pcmphIEvDvGhsZXdpbmQgW21haWx0bzptaXJqYS5rdWVobGV3aW5kQHRpay5lZS5l dGh6LmNoXSANClNlbnQ6IFR1ZXNkYXksIEZlYnJ1YXJ5IDI4LCAyMDE3IDM6MDYgUE0NClRvOiBN aWtlIEJpc2hvcCA8bWljaGFlbC5iaXNob3BAbWljcm9zb2Z0LmNvbT4NCkNjOiBUZWQgSGFyZGll IDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBSeWFu IEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJlOiBXaGVuIHNob3VsZCBzZXJ2 ZXItY2hvc2VuIGNvbm5lY3Rpb24gSURzIGJlIHNlbnQgYW5kIGhvdyBhcmUgdGhleSBpbmRpY2F0 ZWQ/DQoNCkV2ZW4gaWYgdGhlIGxvYWQgYmFsYW5jZXIgY291bGQgc2VlIHRoZSB0cmFmZmljIGlu IHRoZSBvdGhlciBkaXJlY3Rpb24sIHRoZSBuZXcgY29ubmVjdGlvbiBpZHMgc2hvdWxkIG5vdCBi ZSBleHBvc2VkIHRvIHRoZSBwYXRoIChha2EgdGhpcyBpbmZvcm1hdGlvbiBtdXN0IGJlIGVuY3J5 cHRlZCksIG90aGVyd2lzZSBpdOKAmXMgc3RpbGwgbGlua2FibGUuIA0KDQpJZiB5b3Ugd2FudCB0 byBhdm9pZCBhZGRpdGlvbmFsIHNpZ25hbGluZyAod2hpY2ggY291bGQgYmUgZG9uZSBpZiB0aGUg bG9hZCBiYWxhbmNlciBhbmQgdGhlIHNlcnZlciBoYXZlIHNvbWUga2luZCBvZiB0cnVzdCByZWxh dGlvbnNoaXApLCB0aGVuIGJvdGggbmVlZCB0byBrbm93IHRoZSBhbGdvcml0aG0gdGhhdCBpcyB1 c2VkIHRvIGNyZWF0ZSB0aGUgYWRkaXRpb25hbCBpZHMuIElmIHlvdSBkb27igJl0IGhhdmUgYW55 IHRydXN0IHJlbGF0aW9uc2hpcCAobmVpdGhlciBmb3Igc2lnbmFsaW5nLCBub3IgZm9yIHNvbWUg a2luZCBvZiBpbml0aWFsIGNvbmZpZ3VyYXRpb24pIHRoYW4geW91IGFyZSB0aGUga2luZCBvZiBt aWRkbGVib3ggdGhhdCB3ZSBkb27igJl0IHdhbnQgdG8gYmUgYWJsZSB0byBsaW5rIGRpZmZlcmVu dCBjb25uZWN0aW9ucyB0b2dldGhlci4NCg0KTWlyamENCg0KDQo+IEFtIDI4LjAyLjIwMTcgdW0g MjA6NDAgc2NocmllYiBNaWtlIEJpc2hvcCA8bWljaGFlbC5iaXNob3BAbWljcm9zb2Z0LmNvbT46 DQo+IA0KPiBZZXMsIGJ1dCB0aGUgcHJvYmxlbSBpcyBkZWFsaW5nIHdpdGggYSBzaXR1YXRpb24g d2hlcmUgdGhlIGxvYWQgYmFsYW5jZXIgYW5kIHRoZSBzZXJ2ZXIgYXJlIGluZGVwZW5kZW50bHkg bWFuYWdlZCwgYXMgaW4gYSBob3N0aW5nIGVudmlyb25tZW50LiAgVGhlcmUgd291bGQgbmVlZCB0 byBiZSBzb21ldGhpbmcgc3RhbmRhcmRpemVkLiAgKE9mIGNvdXJzZSwgaWYgdGhlIGxvYWQgYmFs YW5jZXIgY2FuIGJlIHN0YXRlZnVsLCBpdCBkb2VzbuKAmXQgbmVlZCBuZWFybHkgYXMgbXVjaCBv ZiB0aGlzIG1hY2hpbmVyeS4pDQo+IA0KPiANCj4gDQo+IFRoZSBvdGhlciBpc3N1ZSB0aGF0IHdh cyBwb2ludGVkIG91dCB0byBtZSBieSBvbmUgb2Ygb3VyIFNMQiBndXlzIGlzIHRoYXQgdGhlIGxv YWQgYmFsYW5jZXIgb25seSBzZWVzIHBhY2tldHMgaW4gdGhlIGNsaWVudC10by1zZXJ2ZXIgZGly ZWN0aW9uLCBub3QgdGhlIHNlcnZlcuKAmXMgcmVzcG9uc2VzLiAgU28gYSBDb25uZWN0aW9uIElE IGNoYW5nZSBwcm9wb3NlZCBieSB0aGUgc2VydmVyIGlzIGludmlzaWJsZSB0byB0aGUgbG9hZCBi YWxhbmNlciB1bnRpbCBpdCBzZWVzIGEgZnV0dXJlIGNsaWVudCBwYWNrZXQgd2l0aCB0aGUgc2Ft ZSA0LXR1cGxlIGFuZCBhIGRpZmZlcmVudCBjb25uZWN0aW9uIElELiAgQnV0IHNpbXBseSBhbGxv d2luZyBwYWNrZXRzIGZyb20gdGhlIHNhbWUgc291cmNlIHdpdGggYSBkaWZmZXJlbnQgSUQgdG8g aW5mb3JtIHRoZSBsb2FkIGJhbGFuY2VyIG9mIGFuIElEIGNoYW5nZSBzZWVtcyByaXBlIGZvciBh dHRhY2sgYnkgc3Bvb2ZpbmcgdGhlIHNvdXJjZSDigJMgd2XigJlkIG5lZWQgdG8gdGlnaHRseSBz Y29wZSBob3cgYSBsb2FkIGJhbGFuY2VyIGNhbiBpZGVudGlmeSB0aGF0IHNhZmVseS4gIEl0IGFs c28gbWVhbnMgdGhhdCBvdXIgYWdyZWVtZW50IHRoYXQgY2xpZW50IElQL3BvcnQgY2Fu4oCZdCBj aGFuZ2Ug4oCcZHVyaW5nIHRoZSBoYW5kc2hha2XigJ0gYWN0dWFsbHkgaGFzIHRvIGV4dGVuZCB1 bnRpbCB0aGUgc2VydmVyIGhhcyByZWNlaXZlZCBwYWNrZXRzIHdpdGggdGhlIG5ldyBjb25uZWN0 aW9uIElELg0KPiANCj4gDQo+IA0KPiBGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgVGVkIEhhcmRpZQ0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFy eSAyOCwgMjAxNyAxMToyMCBBTQ0KPiBUbzogUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb20+ DQo+IENjOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBNaXJqYSBLw7xobGV3aW5kIDxt aXJqYS5rdWVobGV3aW5kQHRpay5lZS5ldGh6LmNoPg0KPiBTdWJqZWN0OiBSZTogV2hlbiBzaG91 bGQgc2VydmVyLWNob3NlbiBjb25uZWN0aW9uIElEcyBiZSBzZW50IGFuZCBob3cgYXJlIHRoZXkg aW5kaWNhdGVkPw0KPiANCj4gDQo+IA0KPiBPbiBUdWUsIEZlYiAyOCwgMjAxNyBhdCAxMDoxMyBB TSwgUnlhbiBIYW1pbHRvbiA8cmNoQGdvb2dsZS5jb20+IHdyb3RlOg0KPiANCj4gDQo+IA0KPiBP biBUdWUsIEZlYiAyOCwgMjAxNyBhdCA4OjM3IEFNLCBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFp bC5jb20+IHdyb3RlOg0KPiANCj4gVGhlcmUgYXJlIHR3byBjYXNlcyB3ZSBoYXZlIHRvIGNvbnNp ZGVyOiBsaW5rYWJpbGl0eSBkdWUgdG8gYSBjaGFuZ2UgaW4gdGhlIG5ldHdvcmsgbm90IHZpc2li bGUgdG8gdGhlIGNsaWVudCBhbmQgbGlua2FiaWxpdHkgdGhhdCBvY2N1cnMgYmVjYXVzZSBvZiBh IGNsaWVudC1pbml0aWF0ZWQgY2hhbmdlLiAgWW91J3JlIGNvcnJlY3QgdGhhdCBpdCBjYW5ub3Qg dXBkYXRlIHRoZSBjb25uZWN0aW9uIElEIHRvIGF2b2lkIGxpbmthZ2Ugd2hlbiBpdCBkb2Vzbid0 IGtub3cgb2YgdGhlIGNoYW5nZSwgYnV0IHdoZW4gdGhlIGNsaWVudCBpbml0aWF0ZXMgdGhlIGNo YW5nZSAoZS5nLiBtb3ZlcyBmcm9tIFdpRmkgdG8gY2VsbHVsYXIpLCBpdCBjZXJ0YWlubHkgY291 bGQuICBJZiB0aGlzIGZlYXR1cmUgaXMgb3B0aW9uYWwsIHRoZW4geW91IGxpa2VseSBkbyBoYXZl IHRvIGhhdmUgYSBjb25maWd1cmF0aW9uIGZyb2IgdGhhdCB0aGUgY2xpZW50IHVzZXMgdG8gc2F5 ICJyZS11c2Ugb2YgY29ubmVjdCBJRHMgaXMgb2theSIgdnMuICJub3Qgb2theSwgcGxlYXNlIHVz ZSAwUlRUIHdoZW4gdHJhbnNpdGlvbnMgb2NjdXIgYW5kIG9ubHkgb25lIGNvbm5lY3Rpb24gSUQg aXMgYXZhaWxhYmxlIi4gDQo+IA0KPiBQZXJzb25hbGx5LCBJJ2QgYmUgaGFwcHkgaWYgaXQgd2Vy ZSBub3Qgb3B0aW9uYWwsIGFuZCBJIHRoaW5rIHRoZSBwcm90b2NvbCB0byBzaGFyZSBvdXQgYSBw b29sIG9mIGNvbm5lY3Rpb24gSURzIGZyb20gYSBsb2FkIGJhbGFuY2VyL2xvYWQgYmFsYW5jZXIg ZmFybSBpcyBub3QgdGhhdCBjb21wbGljYXRlZC4gSXQncyBub3QgaW4gY2hhcnRlciBmb3IgUVVJ QywgYnV0IGlmIHdlIHdhbnRlZCBhIHByb3Bvc2FsIGZvciBpdCwgSSdtIGd1ZXNzaW5nIHdlIGNv dWxkIGtub2NrIHNvbWV0aGluZyB0b2dldGhlciBieSB0aGUgUGFyaXMgaW50ZXJpbSBhbmQgdGFr ZSBpdCB0byBkaXNwYXRjaCBpbiBQcmFndWUuDQo+IA0KPiANCj4gDQo+IOKAi015IHNlbnNlIGlz IHRoYXQgdGhlIHdvcmtpbmcgZ3JvdXAgYmVsaWV2ZXMgdGhhdCBpdCBpcyBub3QgYWNjZXB0YWJs ZSBmb3IgYSBjb25uZWN0aW9uIElEIHRvIGJlIHJldXNlZCBhY3Jvc3MgY2xpZW50IGluaXRpYXRl ZCBuZXR3b3JrIGNoYW5nZXMgKFdpRmkgdG8gQ2VsbHVsYXIpLiBJZiB0aGlzIGlzIGFjY3VyYXRl LCB0aGVuIGlmIGEgc2VydmVyIGRpZCBub3QgcHJlc2VudCBhbnkgYWRkaXRpb25hbCBjb25uZWN0 aW9uIElEcyB0byBhIGNsaWVudCwgdGhlIGNsaWVudCB3b3VsZCBzaW1wbHkgdGVhciBkb3duIHRo ZSBjb25uZWN0aW9uIGlmIGl0IGNoYW5nZWQgbmV0d29ya3MsIGp1c3QgYXMgaWYgaXQgd291bGQg ZG8gdG8gVENQIGNvbm5lY3Rpb25zLiBTbyB3ZSBjYW4gc3RpbGwgaGF2ZSB0aGlzICJsaXN0IG9m IGNvbm5lY3Rpb24gSURzIiBmZWF0dXJlIGJlaW5nIG9wdGlvbmFsIHdpdGhvdXQgbmVlZGluZyB0 byBlbXBvd2VyIGNsaWVudHMgdG8gdXNlIHRoZSBjb25uZWN0aW9uIElEIGFjcm9zcyBuZXR3b3Jr IGNoYW5nZXMsIHJpZ2h0Pw0KPiANCj4gDQo+IA0KPiBZZXMsIHRoYXQgd291bGQgYmUgdGhlIGFs dGVybmF0ZSBzdHJhdGVneS4gIEF0IHRoYXQgcG9pbnQsIHRoZSBjbGllbnQgaXMgbm90IGV4cGVj dGluZyB0aGUgbmV3IHNlcnZlciB0byBoYXZlIHN0YXRlLCBzbyBpdCBpcyBleHBsaWNpdGx5IGdp dmluZyB0aGF0IHVwIHRvIGF2b2lkIGxpbmthYmlsaXR5Lg0KPiANCj4gDQo+IA0KPiBJJ20gYWxz byBub3QgY29udmluY2VkIHRoYXQgaXQgaXMgIm5vdCBjb21wbGljYXRlZCIgZm9yIGEgc2VydmVy IHRvIGJlIGluIHBvc3Nlc3Npb24gb2YgYSBzZXQgb2YgY29ubmVjdGlvbiBJRHMgdGhhdCB3aWxs IG1hcCBiYWNrIHRvIGl0c2VsZiBpbiBzb21lIGRlcGxveW1lbnRzLCBidXQgSSdkIGJlIGhhcHB5 IHRvIGJlIHdyb25nIQ0KPiANCj4gDQo+IA0KPiBXZWxsLCB0aGVyZSBhcmUgY2xlYXJseSBwcm9w cmlldGFyeSBzb2x1dGlvbnMgaW4gdGhpcyBzcGFjZSwgYXMgd2VsbCBhcyBmYWlybHkgYmFzaWMg bWV0aG9kcyBvZiByYW5nZSBhc3NpZ25tZW50IHdpdGhpbiB0aGUgZnVsbCBwb29sIHRoYXQgd29y ayB3aXRoIGEgc3RhbmRhcmQgZmFuLW91dCBvZiBzZXJ2ZXJzIGJlaGluZCBhIGxvYWQgYmFsYW5j ZXIuICBUaGV5IG1heSBub3QgY292ZXIgYWxsIGRlcGxveW1lbnRzLCBvZiBjb3Vyc2UuDQo+IA0K PiByZWdhcmRzLA0KPiANCj4gVGVkDQo+IA0KPiANCj4gDQoNCg== From nobody Tue Feb 28 12:39:05 2017 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 CED401296CB for ; Tue, 28 Feb 2017 12:39:03 -0800 (PST) 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 NKkZSTtJzv5T for ; Tue, 28 Feb 2017 12:39:02 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 59CDF12963A for ; Tue, 28 Feb 2017 12:39:02 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DEA16200019; Tue, 28 Feb 2017 20:39:01 +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 C840E200004; Tue, 28 Feb 2017 20:39:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1488314341; bh=6fji8fXhhjJ8ihXbHAeekGm58d1fwo5Q7Kjg19C4IaU=; l=16754; h=From:To:CC:Date:References:In-Reply-To:From; b=gG0SM0PIt9dsgI6j77uJfMSbsu724HvbR5rNcz/ZZ7o9jtdOUaehY3W3fDsZaySqf dddTaG7skaLPGLZ1Ps93vcxLWt4FhnpIgimzjuJdBSxL6SeAP38ufImGJEP8iLc2XH beBwmN44iiYRVQU5lwyXP+BJRD2/ntS9HwWm9tuk= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 99A521E07C; Tue, 28 Feb 2017 20:39:01 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 28 Feb 2017 15:39:01 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Tue, 28 Feb 2017 15:39:00 -0500 From: "Lubashev, Igor" To: Kyle Rose , =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= Subject: RE: When should server-chosen connection IDs be sent and how are they indicated? Thread-Topic: When should server-chosen connection IDs be sent and how are they indicated? Thread-Index: AQHSkVnUFyvCyJf5LkySP9zxgM+hCaF972KAgAAA8YCAALU8gIAATWEAgAAa8ICAABKLgIAABbOAgAAHEQCAAAVQgP//rmoQ Date: Tue, 28 Feb 2017 20:39:00 +0000 Message-ID: <618be199a45448b093a7ae0a03539e54@usma1ex-dag1mb5.msg.corp.akamai.com> References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.34.129] Content-Type: multipart/alternative; boundary="_000_618be199a45448b093a7ae0a03539e54usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 Archived-At: Cc: Mike Bishop , Ted Hardie , IETF QUIC WG , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:39:04 -0000 --_000_618be199a45448b093a7ae0a03539e54usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 S3lsZSwgc28geW91IGFyZSB0aGlua2luZyBvZiBzb21lIFJvbGxpbmcgQ29kZTxodHRwczovL2Vu Lndpa2lwZWRpYS5vcmcvd2lraS9Sb2xsaW5nX2NvZGU+IHRvIHJlcGxhY2UgQ29ubmVjdGlvbklE cyBhZnRlciBhIDEtUlRUIGhhbmRzaGFrZT8gIFRoYXTigJlzIGFuIGludGVyZXN0aW5nIGlkZWEs IHRob3VnaCBpdCBtYXkgYmUgZGlmZmljdWx0IGZvciBTZXJ2ZXJzIHRvIHRlbGwgYXBhcnQgY29t cGxldGVseSBtYXJ0aWFuIHBhY2tldHMgKHVua25vd24gY29ubmVjdGlvbnMpIHZzIHZlcnkgZGVs YXllZCBwYWNrZXRzICh0aGlzIG1ha2VzIGEgZGlmZmVyZW5jZSBpbiB3aGV0aGVyIHRvIFJTVCB0 aGUgY29ubmVjdGlvbiBvciBkcm9wIHRoZSBwYWNrZXQpLg0KDQpXZSB3b3VsZCBzdGlsbCB3YW50 IHNvbWUgYWRkaXRpb25hbCBpbW11dGFibGUgU2VydmVyLUNvbnRyaWJ1dGVkIGRhdGEgZm9yIGxv YWQgYmFsYW5jZXJzLCB0aG91Z2guDQoNCg0KLSAgICAgICAgICBJZ29yDQoNCg0KRnJvbTogS3ls ZSBSb3NlIFttYWlsdG86a3Jvc2VAa3Jvc2Uub3JnXQ0KU2VudDogVHVlc2RheSwgRmVicnVhcnkg MjgsIDIwMTcgMzoyNSBQTQ0KVG86IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRA dGlrLmVlLmV0aHouY2g+DQpDYzogTWlrZSBCaXNob3AgPG1pY2hhZWwuYmlzaG9wQG1pY3Jvc29m dC5jb20+OyBUZWQgSGFyZGllIDx0ZWQuaWV0ZkBnbWFpbC5jb20+OyBJRVRGIFFVSUMgV0cgPHF1 aWNAaWV0Zi5vcmc+OyBSeWFuIEhhbWlsdG9uIDxyY2hAZ29vZ2xlLmNvbT4NClN1YmplY3Q6IFJl OiBXaGVuIHNob3VsZCBzZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSURzIGJlIHNlbnQgYW5kIGhv dyBhcmUgdGhleSBpbmRpY2F0ZWQ/DQoNCk9uIFR1ZSwgRmViIDI4LCAyMDE3IGF0IDM6MDUgUE0s IE1pcmphIEvDvGhsZXdpbmQgPG1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g8bWFpbHRv Om1pcmphLmt1ZWhsZXdpbmRAdGlrLmVlLmV0aHouY2g+PiB3cm90ZToNCkV2ZW4gaWYgdGhlIGxv YWQgYmFsYW5jZXIgY291bGQgc2VlIHRoZSB0cmFmZmljIGluIHRoZSBvdGhlciBkaXJlY3Rpb24s IHRoZSBuZXcgY29ubmVjdGlvbiBpZHMgc2hvdWxkIG5vdCBiZSBleHBvc2VkIHRvIHRoZSBwYXRo IChha2EgdGhpcyBpbmZvcm1hdGlvbiBtdXN0IGJlIGVuY3J5cHRlZCksIG90aGVyd2lzZSBpdOKA mXMgc3RpbGwgbGlua2FibGUuDQoNCklmIHlvdSB3YW50IHRvIGF2b2lkIGFkZGl0aW9uYWwgc2ln bmFsaW5nICh3aGljaCBjb3VsZCBiZSBkb25lIGlmIHRoZSBsb2FkIGJhbGFuY2VyIGFuZCB0aGUg c2VydmVyIGhhdmUgc29tZSBraW5kIG9mIHRydXN0IHJlbGF0aW9uc2hpcCksIHRoZW4gYm90aCBu ZWVkIHRvIGtub3cgdGhlIGFsZ29yaXRobSB0aGF0IGlzIHVzZWQgdG8gY3JlYXRlIHRoZSBhZGRp dGlvbmFsIGlkcy4gSWYgeW91IGRvbuKAmXQgaGF2ZSBhbnkgdHJ1c3QgcmVsYXRpb25zaGlwIChu ZWl0aGVyIGZvciBzaWduYWxpbmcsIG5vciBmb3Igc29tZSBraW5kIG9mIGluaXRpYWwgY29uZmln dXJhdGlvbikgdGhhbiB5b3UgYXJlIHRoZSBraW5kIG9mIG1pZGRsZWJveCB0aGF0IHdlIGRvbuKA mXQgd2FudCB0byBiZSBhYmxlIHRvIGxpbmsgZGlmZmVyZW50IGNvbm5lY3Rpb25zIHRvZ2V0aGVy Lg0KDQpXaGVuZXZlciBJJ3ZlIHRob3VnaHQgYWJvdXQgdGhpcyBwcm9ibGVtLCBpdCBhbHdheXMg Y29tZXMgYmFjayB0byBpbmRleGluZzogc2luY2UgdGhlIHdob2xlIGdvYWwgaXMgdG8gZmlndXJl IG91dCB0aGUgY29ubmVjdGlvbiBjb250ZXh0IChpbmNsdWRpbmcgZW5jcnlwdGlvbiBrZXksIHNv bWV0aGluZyBwcm9iYWJseSBjb21wbGV0ZWx5IHVua25vd24gdG8gdGhlIGxvYWQgYmFsYW5jZXIp IGZyb20gc29tZSBwbGFpbnRleHQgc2lnbmFsIHRoYXQgbXVzdCBiZSBkaWZmZXJlbnQgaW4gZWFj aCBwYWNrZXQsIHRoZSBzeXN0ZW0gbmVlZHMgb25lIG9mIHRoZSBmb2xsb3dpbmc6DQoNCigxKSBB IHN1ZmZpY2llbnQsIGJ1dCBwcmVzdW1hYmx5IGxpbWl0ZWQsIHRhYmxlIG9mIElEcyB0aGF0IGlu ZGV4IHRvIGNvbm5lY3Rpb25zIChzaXplZCBwZXJoYXBzIG9uIHRoZSBiYXNpcyBvZiAjIG9mIHBh Y2tldHMgaW4gZmxpZ2h0KSwgcGx1cyB0aGUgYWJpbGl0eSB0byByZXVzZSBJRHMgb3Igb3RoZXJ3 aXNlIHJlLXN5bmNocm9uaXplIChlLmcuLCBmYWxsIGJhY2sgdG8gUEtDKSBpbiBjYXNlIG9mIHBh Y2tldCBsb3NzDQooMikgQSBzaGFyZWQgSUQgZ2VuZXJhdGlvbiBhbGdvcml0aG0gdGhhdCBtYXkg b25seSBiZSBjb21wdXRlZCBieSBlbmRwb2ludHMsIHBsdXMgc29tZSByZWNvdmVyeSBhbGdvcml0 aG0gaW4gY2FzZSBvZiBkZS1zeW5jaHJvbml6YXRpb24gKGUuZy4sIGR1ZSB0byBwYWNrZXQgcmVv cmRlcmluZykNCigzKSBQS0MgKGV4cGVuc2l2ZSBvbiBhIHBlci1wYWNrZXQgYmFzaXMpDQoNCklu IHByYWN0aWNlLCB0aGVyZSBtYXkgYmUgbGl0dGxlIGVub3VnaCByZW9yZGVyaW5nIHRoYXQgd2l0 aCBzb21lIHJlYXNvbmFibGUgd2luZG93IChzYXkgMnggIyBwYWNrZXRzIGluIGZsaWdodCB3b3J0 aCBvZiBJRHMpLCByZWFzb25hYmxlIGhldXJpc3RpY3MgYXJvdW5kIHVzZSBvZiBJRHMgdG8gcHJl dmVudCBkZS1zeW5jaHJvbml6YXRpb24sIGFuZCBsb3NzLXJlY292ZXJ5IHRoYXQgc2ltcGx5IGRv ZXNuJ3QgY2FyZSBhYm91dCBwYWNrZXRzIHRoYXQgYXJlIHRvbyBvdXQtb2Ytb3JkZXIsIHRoYXQg UEtDIGZhbGxiYWNrIHdvdWxkIGJlIHJhcmUuDQoNCkt5bGUNCg== --_000_618be199a45448b093a7ae0a03539e54usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29u b3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0K CW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmhvZW56 Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpA bGlzdCBsMA0KCXttc28tbGlzdC1pZDo1NTQ3Nzk4OTQ7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNjQ3Nzk4NzEwIDIxMDk3NzcxMDYgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDotOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6Q2Fs aWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBs MDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBO ZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1i b2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5LeWxlLCBzbyB5b3UgYXJl IHRoaW5raW5nIG9mIHNvbWUNCjxhIGhyZWY9Imh0dHBzOi8vZW4ud2lraXBlZGlhLm9yZy93aWtp L1JvbGxpbmdfY29kZSI+Um9sbGluZyBDb2RlPC9hPiB0byByZXBsYWNlIENvbm5lY3Rpb25JRHMg YWZ0ZXIgYSAxLVJUVCBoYW5kc2hha2U/Jm5ic3A7IFRoYXTigJlzIGFuIGludGVyZXN0aW5nIGlk ZWEsIHRob3VnaCBpdCBtYXkgYmUgZGlmZmljdWx0IGZvciBTZXJ2ZXJzIHRvIHRlbGwgYXBhcnQg Y29tcGxldGVseSBtYXJ0aWFuIHBhY2tldHMgKHVua25vd24gY29ubmVjdGlvbnMpIHZzIHZlcnkN CiBkZWxheWVkIHBhY2tldHMgKHRoaXMgbWFrZXMgYSBkaWZmZXJlbmNlIGluIHdoZXRoZXIgdG8g UlNUIHRoZSBjb25uZWN0aW9uIG9yIGRyb3AgdGhlIHBhY2tldCkuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldl IHdvdWxkIHN0aWxsIHdhbnQgc29tZSBhZGRpdGlvbmFsIGltbXV0YWJsZSBTZXJ2ZXItQ29udHJp YnV0ZWQgZGF0YSBmb3IgbG9hZCBiYWxhbmNlcnMsIHRob3VnaC48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIHN0eWxlPSJtc28tbGlzdDpJZ25vcmUiPi08c3BhbiBz dHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bh bj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SWdvcjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBLeWxlIFJvc2Ug W21haWx0bzprcm9zZUBrcm9zZS5vcmddDQo8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgRmVi cnVhcnkgMjgsIDIwMTcgMzoyNSBQTTxicj4NCjxiPlRvOjwvYj4gTWlyamEgS8O8aGxld2luZCAm bHQ7bWlyamEua3VlaGxld2luZEB0aWsuZWUuZXRoei5jaCZndDs8YnI+DQo8Yj5DYzo8L2I+IE1p a2UgQmlzaG9wICZsdDttaWNoYWVsLmJpc2hvcEBtaWNyb3NvZnQuY29tJmd0OzsgVGVkIEhhcmRp ZSAmbHQ7dGVkLmlldGZAZ21haWwuY29tJmd0OzsgSUVURiBRVUlDIFdHICZsdDtxdWljQGlldGYu b3JnJmd0OzsgUnlhbiBIYW1pbHRvbiAmbHQ7cmNoQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBXaGVuIHNob3VsZCBzZXJ2ZXItY2hvc2VuIGNvbm5lY3Rpb24gSURzIGJl IHNlbnQgYW5kIGhvdyBhcmUgdGhleSBpbmRpY2F0ZWQ/PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBUdWUsIEZlYiAyOCwgMjAxNyBhdCAzOjA1 IFBNLCBNaXJqYSBLw7xobGV3aW5kICZsdDs8YSBocmVmPSJtYWlsdG86bWlyamEua3VlaGxld2lu ZEB0aWsuZWUuZXRoei5jaCIgdGFyZ2V0PSJfYmxhbmsiPm1pcmphLmt1ZWhsZXdpbmRAdGlrLmVl LmV0aHouY2g8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5FdmVuIGlmIHRoZSBsb2FkIGJhbGFuY2VyIGNvdWxkIHNlZSB0aGUg dHJhZmZpYyBpbiB0aGUgb3RoZXIgZGlyZWN0aW9uLCB0aGUgbmV3IGNvbm5lY3Rpb24gaWRzIHNo b3VsZCBub3QgYmUgZXhwb3NlZCB0byB0aGUgcGF0aCAoYWthIHRoaXMgaW5mb3JtYXRpb24gbXVz dCBiZSBlbmNyeXB0ZWQpLCBvdGhlcndpc2UgaXTigJlzIHN0aWxsIGxpbmthYmxlLjxicj4NCjxi cj4NCklmIHlvdSB3YW50IHRvIGF2b2lkIGFkZGl0aW9uYWwgc2lnbmFsaW5nICh3aGljaCBjb3Vs ZCBiZSBkb25lIGlmIHRoZSBsb2FkIGJhbGFuY2VyIGFuZCB0aGUgc2VydmVyIGhhdmUgc29tZSBr aW5kIG9mIHRydXN0IHJlbGF0aW9uc2hpcCksIHRoZW4gYm90aCBuZWVkIHRvIGtub3cgdGhlIGFs Z29yaXRobSB0aGF0IGlzIHVzZWQgdG8gY3JlYXRlIHRoZSBhZGRpdGlvbmFsIGlkcy4gSWYgeW91 IGRvbuKAmXQgaGF2ZSBhbnkgdHJ1c3QgcmVsYXRpb25zaGlwDQogKG5laXRoZXIgZm9yIHNpZ25h bGluZywgbm9yIGZvciBzb21lIGtpbmQgb2YgaW5pdGlhbCBjb25maWd1cmF0aW9uKSB0aGFuIHlv dSBhcmUgdGhlIGtpbmQgb2YgbWlkZGxlYm94IHRoYXQgd2UgZG9u4oCZdCB3YW50IHRvIGJlIGFi bGUgdG8gbGluayBkaWZmZXJlbnQgY29ubmVjdGlvbnMgdG9nZXRoZXIuPG86cD48L286cD48L3A+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVuZXZlciBJ J3ZlIHRob3VnaHQgYWJvdXQgdGhpcyBwcm9ibGVtLCBpdCBhbHdheXMgY29tZXMgYmFjayB0byBp bmRleGluZzogc2luY2UgdGhlIHdob2xlIGdvYWwgaXMgdG8gZmlndXJlIG91dCB0aGUgY29ubmVj dGlvbiBjb250ZXh0IChpbmNsdWRpbmcgZW5jcnlwdGlvbiBrZXksIHNvbWV0aGluZyBwcm9iYWJs eSBjb21wbGV0ZWx5IHVua25vd24gdG8gdGhlIGxvYWQgYmFsYW5jZXIpIGZyb20gc29tZSBwbGFp bnRleHQNCiBzaWduYWwgdGhhdCBtdXN0IGJlIGRpZmZlcmVudCBpbiBlYWNoIHBhY2tldCwgdGhl IHN5c3RlbSBuZWVkcyBvbmUgb2YgdGhlIGZvbGxvd2luZzo8YnI+DQo8YnI+DQooMSkgQSBzdWZm aWNpZW50LCBidXQgcHJlc3VtYWJseSBsaW1pdGVkLCB0YWJsZSBvZiBJRHMgdGhhdCBpbmRleCB0 byBjb25uZWN0aW9ucyAoc2l6ZWQgcGVyaGFwcyBvbiB0aGUgYmFzaXMgb2YgIyBvZiBwYWNrZXRz IGluIGZsaWdodCksIHBsdXMgdGhlIGFiaWxpdHkgdG8gcmV1c2UgSURzIG9yIG90aGVyd2lzZSBy ZS1zeW5jaHJvbml6ZSAoZS5nLiwgZmFsbCBiYWNrIHRvIFBLQykgaW4gY2FzZSBvZiBwYWNrZXQg bG9zczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ KDIpIEEgc2hhcmVkIElEIGdlbmVyYXRpb24gYWxnb3JpdGhtIHRoYXQgbWF5IG9ubHkgYmUgY29t cHV0ZWQgYnkgZW5kcG9pbnRzLCBwbHVzIHNvbWUgcmVjb3ZlcnkgYWxnb3JpdGhtIGluIGNhc2Ug b2YgZGUtc3luY2hyb25pemF0aW9uIChlLmcuLCBkdWUgdG8gcGFja2V0IHJlb3JkZXJpbmcpPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oMykgUEtD IChleHBlbnNpdmUgb24gYSBwZXItcGFja2V0IGJhc2lzKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBwcmFjdGljZSwgdGhlcmUgbWF5IGJl IGxpdHRsZSBlbm91Z2ggcmVvcmRlcmluZyB0aGF0IHdpdGggc29tZSByZWFzb25hYmxlIHdpbmRv dyAoc2F5IDJ4ICMgcGFja2V0cyBpbiBmbGlnaHQgd29ydGggb2YgSURzKSwgcmVhc29uYWJsZSBo ZXVyaXN0aWNzIGFyb3VuZCB1c2Ugb2YgSURzIHRvIHByZXZlbnQgZGUtc3luY2hyb25pemF0aW9u LCBhbmQgbG9zcy1yZWNvdmVyeSB0aGF0IHNpbXBseSBkb2Vzbid0DQogY2FyZSBhYm91dCBwYWNr ZXRzIHRoYXQgYXJlIHRvbyBvdXQtb2Ytb3JkZXIsIHRoYXQgUEtDIGZhbGxiYWNrIHdvdWxkIGJl IHJhcmUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkt5bGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_618be199a45448b093a7ae0a03539e54usma1exdag1mb5msgcorpak_-- From nobody Tue Feb 28 12:41:35 2017 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 C5B961296FC for ; Tue, 28 Feb 2017 12:41:32 -0800 (PST) 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, 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 (1024-bit key) header.d=krose.org Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AO9RjiFcpkaP for ; Tue, 28 Feb 2017 12:41:23 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D99B91296F2 for ; Tue, 28 Feb 2017 12:41:22 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id s186so37770947qkb.1 for ; Tue, 28 Feb 2017 12:41:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pseFJGY0TPJCtu7RfaTxFbQSK64I9z20MgcbdA4N6XA=; b=cZP5R4VBNZ/qGK6c1bPodEqi4/JMNDQMTVCq9g+NwsYNKhnxmFWu+cWDwkRYuWp/Xe /6FRNYy9chbogGxWbVQ0wdOa2HPfRRbBPls3p+C9gD62YZ0BDjDG1ZJB1cSFOfYpmqeJ PZ6olk+cq5PFWCbUipYXRZ67jRZshT2pPCQsI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pseFJGY0TPJCtu7RfaTxFbQSK64I9z20MgcbdA4N6XA=; b=EGXSfcRcKLfF+5RaFlUmB3vuF4q1eBZ0tmLBrW7uwQ9EMUAXNOhTz12oBg+5vO3uNE crLpH+N9gqo9A5Iu2g43bGceOru+mDVbLjVTqjXT4enFTO2sfdkYzeVSsdRt7tpM0LC5 pIweH1rMpV586N3TAQ2jwBmVg5NMcopNZOujc3Ms8O49OpVqPUlVCaN+vCO3syIsntyw g4M/GX/x1KF5N+GN6g0SErboGMyFWFZ0T2XgCMqkvZmcOJ/sq0QCFWNVzFiCFkjC5nPP IJ2Dy74vXrXkTW/HsmttOC1Dytta/9+UyR2SbxqOTzsUvRCXfg44WlWhYRZxY/UyBK91 7+Hw== X-Gm-Message-State: AMke39mcpoOXzRKUNSXuMdmdP4SuL5zoFUEP748m9cBZe6uX07tTTA2bk84//IxGs/S9mt95jOZFg4ON1o2Ahw== X-Received: by 10.55.214.21 with SMTP id t21mr5146272qki.41.1488314481823; Tue, 28 Feb 2017 12:41:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.129.194 with HTTP; Tue, 28 Feb 2017 12:41:21 -0800 (PST) X-Originating-IP: [72.246.0.14] In-Reply-To: <618be199a45448b093a7ae0a03539e54@usma1ex-dag1mb5.msg.corp.akamai.com> References: <5B97FDE8-060A-43B7-8B3F-8322B43B8428@tik.ee.ethz.ch> <0527B2AE-CEEA-4139-A63D-6080ECDA7BDC@tik.ee.ethz.ch> <618be199a45448b093a7ae0a03539e54@usma1ex-dag1mb5.msg.corp.akamai.com> From: Kyle Rose Date: Tue, 28 Feb 2017 15:41:21 -0500 Message-ID: Subject: Re: When should server-chosen connection IDs be sent and how are they indicated? To: "Lubashev, Igor" Content-Type: multipart/alternative; boundary=001a11465b2201ba0605499d3809 Archived-At: Cc: Mike Bishop , Ted Hardie , IETF QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= , Ryan Hamilton X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Main mailing list of the IETF QUIC working group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2017 20:41:33 -0000 --001a11465b2201ba0605499d3809 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Exactly. Good to know this has a name. (We can probably also do better than a garage door opener.) Kyle On Tue, Feb 28, 2017 at 3:39 PM, Lubashev, Igor wrote= : > Kyle, so you are thinking of some Rolling Code > to replace ConnectionIDs > after a 1-RTT handshake? That=E2=80=99s an interesting idea, though it m= ay be > difficult for Servers to tell apart completely martian packets (unknown > connections) vs very delayed packets (this makes a difference in whether = to > RST the connection or drop the packet). > > > > We would still want some additional immutable Server-Contributed data for > load balancers, though. > > > > - Igor > > > > > > *From:* Kyle Rose [mailto:krose@krose.org] > *Sent:* Tuesday, February 28, 2017 3:25 PM > *To:* Mirja K=C3=BChlewind > *Cc:* Mike Bishop ; Ted Hardie < > ted.ietf@gmail.com>; IETF QUIC WG ; Ryan Hamilton < > rch@google.com> > *Subject:* Re: When should server-chosen connection IDs be sent and how > are they indicated? > > > > On Tue, Feb 28, 2017 at 3:05 PM, Mirja K=C3=BChlewind < > mirja.kuehlewind@tik.ee.ethz.ch> wrote: > > Even if the load balancer could see the traffic in the other direction, > the new connection ids should not be exposed to the path (aka this > information must be encrypted), otherwise it=E2=80=99s still linkable. > > If you want to avoid additional signaling (which could be done if the loa= d > balancer and the server have some kind of trust relationship), then both > need to know the algorithm that is used to create the additional ids. If > you don=E2=80=99t have any trust relationship (neither for signaling, nor= for some > kind of initial configuration) than you are the kind of middlebox that we > don=E2=80=99t want to be able to link different connections together. > > > > Whenever I've thought about this problem, it always comes back to > indexing: since the whole goal is to figure out the connection context > (including encryption key, something probably completely unknown to the > load balancer) from some plaintext signal that must be different in each > packet, the system needs one of the following: > > (1) A sufficient, but presumably limited, table of IDs that index to > connections (sized perhaps on the basis of # of packets in flight), plus > the ability to reuse IDs or otherwise re-synchronize (e.g., fall back to > PKC) in case of packet loss > > (2) A shared ID generation algorithm that may only be computed by > endpoints, plus some recovery algorithm in case of de-synchronization > (e.g., due to packet reordering) > > (3) PKC (expensive on a per-packet basis) > > > > In practice, there may be little enough reordering that with some > reasonable window (say 2x # packets in flight worth of IDs), reasonable > heuristics around use of IDs to prevent de-synchronization, and > loss-recovery that simply doesn't care about packets that are too > out-of-order, that PKC fallback would be rare. > > > > Kyle > --001a11465b2201ba0605499d3809 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Exactly. Good to know this has a name. (We can probab= ly also do better than a garage door opener.)

Kyle


On Tue, Feb= 28, 2017 at 3:39 PM, Lubashev, Igor <ilubashe@akamai.com>= wrote:

Kyle, so you are thinking of some Ro= lling Code to replace ConnectionIDs after a 1-RTT handshake?=C2=A0 That= =E2=80=99s an interesting idea, though it may be difficult for Servers to t= ell apart completely martian packets (unknown connections) vs very delayed packets (this makes a difference in whether to RST the connection = or drop the packet).

=C2=A0

We would still want some additional immutable Serve= r-Contributed data for load balancers, though.

=C2=A0

-=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 Igor

=C2=A0

=C2=A0

From: Kyle Rose [mailto:krose@krose.org]
Sent: Tuesday, February 28, 2017 3:25 PM
To: Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch><= br> Cc: Mike Bishop <michael.bishop@microsoft.com>; Ted Hardie <= ;ted.ietf@gmail.com= >; IETF QUIC WG <quic@ietf.org>; Ryan Hamilton <rch@google.com>
Subject: Re: When should server-chosen connection IDs be sent and ho= w are they indicated?

=C2=A0

On Tue, Feb 28, 2017 at 3:05 PM, Mirja K=C3=BChlewin= d <= mirja.kuehlewind@tik.ee.ethz.ch> wrote:

<= div class=3D"h5">

Even if the load balancer could see the traffic in t= he other direction, the new connection ids should not be exposed to the pat= h (aka this information must be encrypted), otherwise it=E2=80=99s still li= nkable.

If you want to avoid additional signaling (which could be done if the load = balancer and the server have some kind of trust relationship), then both ne= ed to know the algorithm that is used to create the additional ids. If you = don=E2=80=99t have any trust relationship (neither for signaling, nor for some kind of initial configuration) than y= ou are the kind of middlebox that we don=E2=80=99t want to be able to link = different connections together.

=C2=A0

Whenever I've thought about this problem, it alw= ays comes back to indexing: since the whole goal is to figure out the conne= ction context (including encryption key, something probably completely unkn= own to the load balancer) from some plaintext signal that must be different in each packet, the system needs one of the = following:

(1) A sufficient, but presumably limited, table of IDs that index to connec= tions (sized perhaps on the basis of # of packets in flight), plus the abil= ity to reuse IDs or otherwise re-synchronize (e.g., fall back to PKC) in ca= se of packet loss

(2) A shared ID generation algorithm that may only b= e computed by endpoints, plus some recovery algorithm in case of de-synchro= nization (e.g., due to packet reordering)

(3) PKC (expensive on a per-packet basis)<= /u>

=C2=A0

In practice, there may be little enough reordering t= hat with some reasonable window (say 2x # packets in flight worth of IDs), = reasonable heuristics around use of IDs to prevent de-synchronization, and = loss-recovery that simply doesn't care about packets that are too out-of-order, that PKC fallback would be r= are.

=C2=A0

Kyle