From nobody Wed Nov 1 00:16: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 7800913FE40 for ; Wed, 1 Nov 2017 00:16:35 -0700 (PDT) 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 67WBFYZ8yMi4 for ; Wed, 1 Nov 2017 00:16:33 -0700 (PDT) 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 2DE6113F772 for ; Wed, 1 Nov 2017 00:16:33 -0700 (PDT) Received: by mail-ua0-x22f.google.com with SMTP id b11so936453uae.12 for ; Wed, 01 Nov 2017 00:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vC8R0QpZGBCkQQiVw7wQykgeqrY86pO/GPZzl5TXSZg=; b=WC7SxHDvhE7jYWLtno3W0rTej7bP4aeQunwO8a93BWmsghvi9DQIyzTRXFzz8m/IJS bMloLy0DoLq1LduKLCklue+kUEhexEz5uEHEa3jvFWK+bV6M4cqTO678hCTfEXtTZdon opm862zgMe19SMhcdqDSisituWlRrjjGm0Gp3agOr5nssmkwSBZeE+t6mNVQKlZkA/nY p9t3MEtZz5P0qsxV7+L21Ex5IlFUnLCkJchs6xKByzOcRhiLtEzB49V/7jfsPAbEfx3B 1KcksbsHXJ/LXO5G0Ia8DGzuXwYhLQATGpdE3e2nZEWIjmXCgYvp/P4krJwMBDgdsLTB k9wQ== 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=vC8R0QpZGBCkQQiVw7wQykgeqrY86pO/GPZzl5TXSZg=; b=YzWILh5gjOlulmyT4+lgfz8aNwWk06ASpcudVaOKnqzD/FtXN9X4E4Jdg+wblAGOq1 71Sj6sS60C7rNLbPqyQmeM/otZyP7lKZtMEp3FwmwU5VJ2/x0wSBKa6VLnwCfrYGfJzM veL2ZweYLduDPl/lf4b/iy6ArZkHPCxHVSxeAd5QYiBVPJYAUpEw5ACHAuVznLcbx8RO 3q7+gfSme5AkrVofHcM0OvzaXHQygfTpxxLar5bWLTykeSGJlyXYbmFRlXlWYGqIPHT/ 2aRPRaKR6mfss5MEglcdAV/JpqgJk2rn9Kv1yusb5VVaB36Z6QEBRVItUUndMx7Mw8Zj hhcA== X-Gm-Message-State: AMCzsaWD+wVcm6zq1LWDQnvit3zsGk1UtUWUFhtoQxoxpKUcctX3BzEK 3R0306ekRmjO8p2OFyr8bRldknPpGABRS73mEcA= X-Google-Smtp-Source: ABhQp+Q9vmobUeymST8ySb22TbuQuJPjMm5Qo4bEV52KJlc7b3ckQqiPiVe7dCOhDdiYSBsVRh76An+E/ICv8+/Imns= X-Received: by 10.176.81.68 with SMTP id f4mr3400472uaa.52.1509520591958; Wed, 01 Nov 2017 00:16:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Wed, 1 Nov 2017 00:16:11 -0700 (PDT) In-Reply-To: References: From: Bernard Aboba Date: Wed, 1 Nov 2017 00:16:11 -0700 Message-ID: Subject: Re: QUIC - Our schedule and scope To: Colin Perkins Cc: "Brian Trammell (IETF)" , Mark Nottingham , QUIC WG , Lars Eggert , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="94eb2c191318aa3954055ce6a61c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:16:35 -0000 --94eb2c191318aa3954055ce6a61c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Colin Perkins said: "I do think that peer-to-peer uses of QUIC need attention pre-V1, if they=E2=80=99re to be supported cleanly. At minimum, we need to arrange the= QUIC headers to easily demultiplex with STUN on the same UDP port, otherwise we=E2=80=99ll end-up re-inventing STUN within QUIC. Focussing solely on HTT= P is going to make this difficult. See draft-aboba-avtcore-quic-multiplexing-00 for more discussion." [BA] Peer-to-peer uses of QUIC are under development, and are quite likely to be deployed in advance of a v2 specification. As the multiplexing draft makes clear, there is an alternative (a single octet shim) that enables de-multiplexing of QUIC without modification (or even consideration) of QUIC headers. So while native demultiplexing QUIC headers from STUN might be preferred, this probably can't be characterized as a "must have". Given that some of the most popular peer-to-peer uses involve unreliable data exchange (e.g. in games), support for that is a basic requirement. A "quick and dirty" approach would be to utilize a QUIC stream for each message, while setting a timer so as to approximate a data channel's maxPacketLifetime parameter. A more thorough solution would be to support unreliable QUIC streams natively, allowing maxPacketLifetime or maxRetransmits to be enforced on a per-packet basis, mimicing the behavior of an unreliable RTCDataChannel running over SCTP/DTLS/UDP. The problem with the "quick and dirty" approach is that many peer-to-peer data exchange developers are obsessed with latency and therefore may prefer no retransmissions at all. This could lead to widespread deployment of draft-tiesel-quic-unreliable-streams prior to standardization. On Sun, Oct 29, 2017 at 11:08 AM, Colin Perkins wrote: > > > On 28 Oct 2017, at 09:04, Brian Trammell (IETF) > wrote: > > > > hi Mark, all, > > > > Broadly, I support Patrick's intepretation here. I'll point out that > there seems to be some inconsistency between two points below: > > > >> On 27 Oct 2017, at 08:26, Mark Nottingham wrote: > >> > >> 2) V1 of QUIC should *only* address the use case of HTTP. > > > > and > > > >> * V1 will need to document the "invariants" of QUIC -- i.e., the parts > on the wire that will not change -- to allow other use cases to be > addressed by V2 and beyond. > > > > That QUIC's handshake, pre-version-negotiation wire image, and > ossification-prevention features will be "baked in" in V1 is clear, and I > thought it already had been, though thanks for calling it out here. > > > > Focusing on *only* addressing HTTP in this wire image, though, seems > like it might be dangerous in ways I can't fully articulate yet... HTTP i= s > an explicitly asymmetric protocol, with different roles for client and > server well beyond the initial handshake, and as it is presently most > commonly deployed, wildly different architectures for client-side and > server-side implementations. Many of the things that we suspect we'll wan= t > to bring on top of QUIC in the future are less so; even Web protocols lik= e > WebSockets fit here. Will this focus lead to invariants that will make le= ss > asymmetric applications harder to build and deploy? Should we be concerne= d > about that at this point? > > > I do think that peer-to-peer uses of QUIC need attention pre-V1, if > they=E2=80=99re to be supported cleanly. At minimum, we need to arrange t= he QUIC > headers to easily demultiplex with STUN on the same UDP port, otherwise > we=E2=80=99ll end-up re-inventing STUN within QUIC. Focussing solely on H= TTP is > going to make this difficult. > > See draft-aboba-avtcore-quic-multiplexing-00 for more discussion. > > -- > Colin Perkins > https://csperkins.org/ > > > > > --94eb2c191318aa3954055ce6a61c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Colin Perkins said:=C2=A0

"I do think that peer-to-peer uses of QUIC need at= tention pre-V1, if they=E2=80=99re to be supported cleanly. At minimum, we = need to arrange the QUIC headers to easily demultiplex with STUN on the sam= e UDP port, otherwise we=E2=80=99ll end-up re-inventing STUN within QUIC. F= ocussing solely on HTTP is going to make this difficult.

See draft-ab= oba-avtcore-quic-multiplexing-00 for more discussion."
<= br>
[BA]=C2=A0 Peer-to-peer uses of QUIC are under development, a= nd are quite likely to be deployed in advance of a v2 specification.=C2=A0= =C2=A0

=C2=A0As the multiplexing draft makes clear= , there is an alternative (a single octet shim) that enables de-multiplexin= g of QUIC without modification (or even consideration) of QUIC headers.=C2= =A0 So while native demultiplexing QUIC headers from STUN might be preferre= d, this probably can't be characterized as a "must have".=C2= =A0

Given that some of the most popular peer-to-pe= er uses involve unreliable data exchange (e.g. in games), support for that = is a basic requirement.=C2=A0 A "quick and dirty" approach would = be to utilize a QUIC stream for each message, while setting a timer so as t= o approximate a data channel's maxPacketLifetime parameter.=C2=A0 A mor= e thorough solution would be to support unreliable QUIC streams natively, a= llowing maxPacketLifetime or maxRetransmits to be enforced on a per-packet = basis, mimicing the behavior of an unreliable RTCDataChannel running over S= CTP/DTLS/UDP.=C2=A0

The problem with the "qui= ck and dirty" approach is that many peer-to-peer data exchange develop= ers are obsessed with latency and therefore may prefer no retransmissions a= t all.=C2=A0 This could lead to widespread deployment of=C2=A0draft-tiesel-= quic-unreliable-streams prior to standardization.

=

O= n Sun, Oct 29, 2017 at 11:08 AM, Colin Perkins <csp@csperkins.org><= /span> wrote:

> On 28 Oct 2017, at 09:04, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
>
> hi Mark, all,
>
> Broadly, I support Patrick's intepretation here. I'll point ou= t that there seems to be some inconsistency between two points below:
>
>> On 27 Oct 2017, at 08:26, Mark Nottingham <mnot@mnot.net> wrote:
>>
>> 2) V1 of QUIC should *only* address the use case of HTTP.
>
> and
>
>> * V1 will need to document the "invariants" of QUIC -- i= .e., the parts on the wire that will not change -- to allow other use cases= to be addressed by V2 and beyond.
>
> That QUIC's handshake, pre-version-negotiation wire image, and oss= ification-prevention features will be "baked in" in V1 is clear, = and I thought it already had been, though thanks for calling it out here. >
> Focusing on *only* addressing HTTP in this wire image, though, seems l= ike it might be dangerous in ways I can't fully articulate yet... HTTP = is an explicitly asymmetric protocol, with different roles for client and s= erver well beyond the initial handshake, and as it is presently most common= ly deployed, wildly different architectures for client-side and server-side= implementations. Many of the things that we suspect we'll want to brin= g on top of QUIC in the future are less so; even Web protocols like WebSock= ets fit here. Will this focus lead to invariants that will make less asymme= tric applications harder to build and deploy? Should we be concerned about = that at this point?


I do think that peer-to-peer uses of QUIC need attention pre-V1, if = they=E2=80=99re to be supported cleanly. At minimum, we need to arrange the= QUIC headers to easily demultiplex with STUN on the same UDP port, otherwi= se we=E2=80=99ll end-up re-inventing STUN within QUIC. Focussing solely on = HTTP is going to make this difficult.

See draft-aboba-avtcore-quic-multiplexing-00 for more discussion.

--
Colin Perkins
htt= ps://csperkins.org/





--94eb2c191318aa3954055ce6a61c-- From nobody Wed Nov 1 02: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 487F613F417 for ; Wed, 1 Nov 2017 02:50:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 b_ub9A80niP5 for ; Wed, 1 Nov 2017 02:50:43 -0700 (PDT) Received: from balrog.mythic-beasts.com (balrog.mythic-beasts.com [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E9CE13F6AF for ; Wed, 1 Nov 2017 02:50:42 -0700 (PDT) Received: from [161.23.164.219] (port=60840) by balrog.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1e9pfS-0005vT-0p; Wed, 01 Nov 2017 09:50:39 +0000 From: Colin Perkins Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_6AADF253-40DD-416E-B09A-7BC01AEDDE1F" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: QUIC - Our schedule and scope Date: Wed, 1 Nov 2017 09:50:28 +0000 In-Reply-To: Cc: "Brian Trammell (IETF)" , Mark Nottingham , QUIC WG , Lars Eggert , Spencer Dawkins at IETF To: Bernard Aboba References: X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 14 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:50:45 -0000 --Apple-Mail=_6AADF253-40DD-416E-B09A-7BC01AEDDE1F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 1 Nov 2017, at 07:16, Bernard Aboba = wrote: >=20 > Colin Perkins said:=20 >=20 > "I do think that peer-to-peer uses of QUIC need attention pre-V1, if = they=E2=80=99re to be supported cleanly. At minimum, we need to arrange = the QUIC headers to easily demultiplex with STUN on the same UDP port, = otherwise we=E2=80=99ll end-up re-inventing STUN within QUIC. Focussing = solely on HTTP is going to make this difficult. >=20 > See draft-aboba-avtcore-quic-multiplexing-00 for more discussion." >=20 > [BA] Peer-to-peer uses of QUIC are under development, and are quite = likely to be deployed in advance of a v2 specification. =20 >=20 > As the multiplexing draft makes clear, there is an alternative (a = single octet shim) that enables de-multiplexing of QUIC without = modification (or even consideration) of QUIC headers. So while native = demultiplexing QUIC headers from STUN might be preferred, this probably = can=E2=80=99t be characterized as a "must have".=20 There are several options for the packet format, and a shim is only one.=20= Whether we define a shim, or change the QUIC header format to allow = demuxing, we should do it early enough so middleboxes are aware. = Otherwise, we=E2=80=99ll see ossification around a format that prevents = peer-to-peer use. > Given that some of the most popular peer-to-peer uses involve = unreliable data exchange (e.g. in games), support for that is a basic = requirement. A "quick and dirty" approach would be to utilize a QUIC = stream for each message, while setting a timer so as to approximate a = data channel's maxPacketLifetime parameter. A more thorough solution = would be to support unreliable QUIC streams natively, allowing = maxPacketLifetime or maxRetransmits to be enforced on a per-packet = basis, mimicing the behavior of an unreliable RTCDataChannel running = over SCTP/DTLS/UDP.=20 >=20 > The problem with the "quick and dirty" approach is that many = peer-to-peer data exchange developers are obsessed with latency and = therefore may prefer no retransmissions at all. This could lead to = widespread deployment of draft-tiesel-quic-unreliable-streams prior to = standardization. >=20 >=20 >=20 > On Sun, Oct 29, 2017 at 11:08 AM, Colin Perkins > wrote: >=20 > > On 28 Oct 2017, at 09:04, Brian Trammell (IETF) > wrote: > > > > hi Mark, all, > > > > Broadly, I support Patrick's intepretation here. I'll point out that = there seems to be some inconsistency between two points below: > > > >> On 27 Oct 2017, at 08:26, Mark Nottingham > wrote: > >> > >> 2) V1 of QUIC should *only* address the use case of HTTP. > > > > and > > > >> * V1 will need to document the "invariants" of QUIC -- i.e., the = parts on the wire that will not change -- to allow other use cases to be = addressed by V2 and beyond. > > > > That QUIC's handshake, pre-version-negotiation wire image, and = ossification-prevention features will be "baked in" in V1 is clear, and = I thought it already had been, though thanks for calling it out here. > > > > Focusing on *only* addressing HTTP in this wire image, though, seems = like it might be dangerous in ways I can't fully articulate yet... HTTP = is an explicitly asymmetric protocol, with different roles for client = and server well beyond the initial handshake, and as it is presently = most commonly deployed, wildly different architectures for client-side = and server-side implementations. Many of the things that we suspect = we'll want to bring on top of QUIC in the future are less so; even Web = protocols like WebSockets fit here. Will this focus lead to invariants = that will make less asymmetric applications harder to build and deploy? = Should we be concerned about that at this point? >=20 >=20 > I do think that peer-to-peer uses of QUIC need attention pre-V1, if = they=E2=80=99re to be supported cleanly. At minimum, we need to arrange = the QUIC headers to easily demultiplex with STUN on the same UDP port, = otherwise we=E2=80=99ll end-up re-inventing STUN within QUIC. Focussing = solely on HTTP is going to make this difficult. >=20 > See draft-aboba-avtcore-quic-multiplexing-00 for more discussion. >=20 > -- > Colin Perkins > https://csperkins.org/ >=20 >=20 >=20 >=20 >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_6AADF253-40DD-416E-B09A-7BC01AEDDE1F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 1 Nov 2017, at 07:16, Bernard Aboba <bernard.aboba@gmail.com> wrote:

Colin Perkins said: 

"I do think that peer-to-peer uses of QUIC need attention = pre-V1, if they=E2=80=99re to be supported cleanly. At minimum, we need = to arrange the QUIC headers to easily demultiplex with STUN on the same = UDP port, otherwise we=E2=80=99ll end-up re-inventing STUN within QUIC. = Focussing solely on HTTP is going to make this = difficult.

See = draft-aboba-avtcore-quic-multiplexing-00 = for more discussion."

[BA]  Peer-to-peer uses of QUIC = are under development, and are quite likely to be deployed in advance of = a v2 specification.  

 As the multiplexing draft makes = clear, there is an alternative (a single octet shim) that enables = de-multiplexing of QUIC without modification (or even consideration) of = QUIC headers.  So while native demultiplexing QUIC headers from = STUN might be preferred, this probably can=E2=80=99t be characterized as = a "must have". 

There are several options for the packet format, = and a shim is only one. 

Whether = we define a shim, or change the QUIC header format to allow demuxing, we = should do it early enough so middleboxes are aware. Otherwise, we=E2=80=99= ll see ossification around a format that prevents peer-to-peer = use.

Given that some = of the most popular peer-to-peer uses involve unreliable data exchange = (e.g. in games), support for that is a basic requirement.  A "quick = and dirty" approach would be to utilize a QUIC stream for each message, = while setting a timer so as to approximate a data channel's = maxPacketLifetime parameter.  A more thorough solution would be to = support unreliable QUIC streams natively, allowing maxPacketLifetime or = maxRetransmits to be enforced on a per-packet basis, mimicing the = behavior of an unreliable RTCDataChannel running over = SCTP/DTLS/UDP. 

The problem with the "quick and dirty" approach is that many = peer-to-peer data exchange developers are obsessed with latency and = therefore may prefer no retransmissions at all.  This could lead to = widespread deployment of draft-tiesel-quic-unreliable-streams prior = to standardization.



On Sun, Oct 29, 2017 at 11:08 AM, = Colin Perkins <csp@csperkins.org> wrote:

> On 28 Oct 2017, at 09:04, Brian Trammell (IETF) <ietf@trammell.ch> = wrote:
>
> hi Mark, all,
>
> Broadly, I support Patrick's intepretation here. I'll point out = that there seems to be some inconsistency between two points below:
>
>> On 27 Oct 2017, at 08:26, Mark Nottingham <mnot@mnot.net> wrote:
>>
>> 2) V1 of QUIC should *only* address the use case of HTTP.
>
> and
>
>> * V1 will need to document the "invariants" of QUIC -- i.e., = the parts on the wire that will not change -- to allow other use cases = to be addressed by V2 and beyond.
>
> That QUIC's handshake, pre-version-negotiation wire image, and = ossification-prevention features will be "baked in" in V1 is clear, and = I thought it already had been, though thanks for calling it out here.
>
> Focusing on *only* addressing HTTP in this wire image, though, = seems like it might be dangerous in ways I can't fully articulate yet... = HTTP is an explicitly asymmetric protocol, with different roles for = client and server well beyond the initial handshake, and as it is = presently most commonly deployed, wildly different architectures for = client-side and server-side implementations. Many of the things that we = suspect we'll want to bring on top of QUIC in the future are less so; = even Web protocols like WebSockets fit here. Will this focus lead to = invariants that will make less asymmetric applications harder to build = and deploy? Should we be concerned about that at this point?


I do think that peer-to-peer uses of QUIC need attention pre-V1, = if they=E2=80=99re to be supported cleanly. At minimum, we need to = arrange the QUIC headers to easily demultiplex with STUN on the same UDP = port, otherwise we=E2=80=99ll end-up re-inventing STUN within QUIC. = Focussing solely on HTTP is going to make this difficult.

See draft-aboba-avtcore-quic-multiplexing-00 for more = discussion.

--
Colin Perkins
https://csperkins.org/








-- 
Colin Perkins
https://csperkins.org/




= --Apple-Mail=_6AADF253-40DD-416E-B09A-7BC01AEDDE1F-- From nobody Wed Nov 1 06:04: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 DAD2213F7D6 for ; Wed, 1 Nov 2017 06:04:07 -0700 (PDT) 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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y0KhuWh-yYEo for ; Wed, 1 Nov 2017 06:04:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CDF8313F442 for ; Wed, 1 Nov 2017 06:04:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZB71595; Wed, 01 Nov 2017 13:04:03 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 1 Nov 2017 13:04:02 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Wed, 1 Nov 2017 21:03:55 +0800 From: Roni Even To: QUIC WG Subject: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Topic: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Index: AdNTERoY+irKmTeUSwyYPYwl1z5CzA== Date: Wed, 1 Nov 2017 13:03:54 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.65] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD82A735DGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59F9C644.0074, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.18, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 7229b9a4854beb459fd5145ae36f10d9 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 13:04:08 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD82A735DGGEMM506MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think support for unreliable streams is important for unidirectional and = bi-directional streams and even if it is V2 we still need to take support f= or it into account. One use case is RTP over QUIC. Small comments: In section 4.2 " The loss of such a frame does not introduce state at the p= erceived receiver". If new streams are opened with higher stream ID, it im= plicitly opens this one frame stream that was lost in the receiver. I think= it still requires the sender to send a reliable FIN to close this stream. In the security section " An active, on path attacker can drop selected fra= mes " . What does it mean selected frames, the whole payload is encrypted. Roni ________________________________ --_000_6E58094ECC8D8344914996DAD28F1CCD82A735DGGEMM506MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I think support for unreliable streams is important = for unidirectional and bi-directional streams and even if it is V2 we still= need to take support for it into account. One use case is RTP over QUIC.

 

Small comments:

 

In section 4.2 “ The loss of such a frame does= not introduce state at the perceived receiver”. If new streams are o= pened with higher stream ID,  it implicitly opens this one frame strea= m that was lost in the receiver. I think it still requires the sender to send a reliable FIN to close this stream.

 

In the security section “ An active, on path a= ttacker can drop selected frames “ . What does it mean selected frames, the who= le payload is encrypted.

 

 

Roni

 

--_000_6E58094ECC8D8344914996DAD28F1CCD82A735DGGEMM506MBSchina_-- From nobody Wed Nov 1 08:15: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 CBDAC1386A2 for ; Wed, 1 Nov 2017 08:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Br9zg202qpKI for ; Wed, 1 Nov 2017 08:15:10 -0700 (PDT) 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 ietfa.amsl.com (Postfix) with ESMTPS id EBA2813F74C for ; Wed, 1 Nov 2017 08:15:09 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id BA83B340E57; Wed, 1 Nov 2017 16:15:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.27820); Wed, 1 Nov 2017 16:15:08 +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; Wed, 1 Nov 2017 16:15:08 +0100 (CET) Received: from [161.23.247.65] (account ietf@trammell.ch [161.23.247.65] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 34609569; Wed, 01 Nov 2017 16:15:08 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_75043DE2-987F-45A8-BF8C-3ED5698A00A3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I-D Action: draft-ietf-quic-manageability-01.txt Date: Wed, 1 Nov 2017 15:15:07 +0000 In-Reply-To: <6D868BC1-8BE5-4CAA-BEFC-79046C887505@in-panik.de> Cc: QUIC WG To: "Philipp S. Tiesel" References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> <6D868BC1-8BE5-4CAA-BEFC-79046C887505@in-panik.de> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 15:15:13 -0000 --Apple-Mail=_75043DE2-987F-45A8-BF8C-3ED5698A00A3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Oct 2017, at 13:38, Philipp S. Tiesel wrote: >=20 > Hi, >=20 > I really like the listing of which information QUIC exposes. > I have just one little question about it: Should Section 3 also state = which information is exposed my the integrated TLS handshake? Yes, it should. > AFAIK, the TLS handshake exposes the application protocol and host = name in clear. As I understand it, TLS1.3 should fix this. > I am not sure whether it also exposes the initial QUIC connection = parameters in clear. As I read it, the cleartext packets only contain the TLS1.3 handshake. Cheers, Brian > AVE! > Philipp S. Tiesel / phils=E2=80=A6 >=20 >> On 25. Oct 2017, at 10:11, internet-drafts@ietf.org wrote: >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the QUIC WG of the IETF. >>=20 >> Title : Manageability of the QUIC Transport Protocol >> Authors : Mirja Kuehlewind >> Brian Trammell >> Filename : draft-ietf-quic-manageability-01.txt >> Pages : 13 >> Date : 2017-10-25 >>=20 >> Abstract: >> This document discusses manageability of the QUIC transport = protocol, >> focusing on caveats impacting network operations involving QUIC >> traffic. Its intended audience is network operators, as well as >> content providers that rely on the use of QUIC-aware middleboxes, >> e.g. for load balancing. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/ >>=20 >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-quic-manageability-01 >> = https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-01 >>=20 >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-quic-manageability-01 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >=20 >=20 --Apple-Mail=_75043DE2-987F-45A8-BF8C-3ED5698A00A3 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAln55PsACgkQihK3vwvq RqNfOQ/9FI2p0gyzzTNVw2p5GUchpEbvcb/5JbhkhMyIEcjRgmHF0elHxkvK+BgX UYQJ2J5fptrUuvissCkvCvoTx11KmnxJ0Ty56jRncQcPkO/hLi0xU1SZ3whC+o/F 20NX6Rt40hGCXmdiaL70XSPAiIHgVIWOZ4AEFusxJyOgRLuFB9jMh75EYhdMDLzz 71oPoje461GsUQaUYB85+RSgjR4JuloBsIr3g/LGLKd0O4EFVYpRLYsOTgEZEja/ voKvu1JcrHPUYhaAVJMbdB57mNzBstuWTIMe+6eKJ/Bv4GlGCwdHN83pdrX0sAcP ktdIg92JC4vVWPG2NZ6D+isBOZmZtRfP6UbsshZHuNMJr4O1dHiaD3+1Je/u7vvN dnzQ8oq1HH927qXVI94mh9TAQlIFPlfpMpce+hGGw9/bSpnMi5W1MpxokwPKEx29 ZN7FkNoEZK4cwpeaIO6I2l2VIl7gl473g+DEM0yfR9Leh71o0P1CJ0TCxv6h1bOw R4wM7OBiD/B/wDz14ZDrq9PB6ImX6f4Rf6iL7RMIknLQmef4k/du/j36oKjSggU3 c1sVrZ55oJf6Mmy5v1h5KwUHNRZI+i4sGTQQwPJT9oqCF/UOBCaIZDqRK+FebMqD kyXkI+VIaZ/kjSfDtBPQZWb7HlGNEdsg3CfqlSdJ1Jem6+mmw+Y= =OMCC -----END PGP SIGNATURE----- --Apple-Mail=_75043DE2-987F-45A8-BF8C-3ED5698A00A3-- From nobody Wed Nov 1 08:26: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 89DBF13FD98 for ; Wed, 1 Nov 2017 08:26:30 -0700 (PDT) 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 n5CbdEgNZiXz for ; Wed, 1 Nov 2017 08:26:28 -0700 (PDT) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4090813FD88 for ; Wed, 1 Nov 2017 08:26:28 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u142so2140896ywg.4 for ; Wed, 01 Nov 2017 08:26:28 -0700 (PDT) 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=YRP8WmEYjKZ2B4EjRtFjmOCNGgaTg4ES+awQepG96ao=; b=PDQsT8E62m6S99TM5ghFDASWBHo5aVEHGNsOnObUUXLJF4jJNcwG/GiCSvBy5XGtQz KqbAFOlyE/OYvW85ljU1vyftQnDHxR29pmIz3WkdQdxOH/aMTDpZSuMBPVOpK8zr+WQd PFymeog2iBDEYd4wUeP6XyA8nW69KHOMGXiyzUg/n+uGPaNpcoFVcebkzHvBZxGbRlqD +p43r3gw0BR3XS4domZ+GS2+3qXdfA50/c8FaFs5f4Y6DpC0CgqSrc2oWQVllyScqS2h 0/HXwzCBzlyMg1Blc3XdcskYw54t0beMemto7HJqux8qfudVDXi7/cvXQIWDYm6WP968 2udA== 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=YRP8WmEYjKZ2B4EjRtFjmOCNGgaTg4ES+awQepG96ao=; b=GYqpfBlc21Yek993g0Q/pvLUDKzLop9zZbiI8HZTNco9Nh595rtnrK2wsWAs5kf4Mq dpA9/ak6Z+E/QQm2Xn5lmgqO2bbfjV+1QaOLYYIZ1RI3OT4GftfCsJVuRZ7qS0tbqJlU uzr+aWHzCsd8oozcBoPpoMsPa0Ft5umSrW1VMD3txwrYOY6vmL0tHeDHZNAhocyg7tpH nfEanu2vxPwLoZavMGudrnutnyK5wEnRyr1Z0IED1SJ6h1UMQ/r1MHW2hEzE1xdtOvpd vdLsKtfcTEUAcJopymL7rgfh/x07VVO3OCMv1apHe1k2V9sj0GXnnHrkdCZt5XehaB5J cYpA== X-Gm-Message-State: AMCzsaXkwPM/DJVUuoVzmlPPIolhp4j8VIyuvhkwmUTvzWMB6Y05jtpf Zb7swYfx7BwjsCwZ6XrTGWOKiUNVf8+U2vRrwR0cvxoT X-Google-Smtp-Source: ABhQp+S+C9r7tJ7Texa7NV40IDu0j7ep3tjByYaegsQngbJA0Qa3L5tipaC6ePPbVi+DJg/qZDD7boYVfV70m5H9Qhc= X-Received: by 10.129.36.1 with SMTP id k1mr129753ywk.485.1509549987441; Wed, 01 Nov 2017 08:26:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Wed, 1 Nov 2017 08:25:46 -0700 (PDT) In-Reply-To: References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> <6D868BC1-8BE5-4CAA-BEFC-79046C887505@in-panik.de> From: Eric Rescorla Date: Wed, 1 Nov 2017 08:25:46 -0700 Message-ID: Subject: Re: I-D Action: draft-ietf-quic-manageability-01.txt To: "Brian Trammell (IETF)" Cc: "Philipp S. Tiesel" , QUIC WG Content-Type: multipart/alternative; boundary="001a1142e4ccc5c61b055ced7e36" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 15:26:30 -0000 --001a1142e4ccc5c61b055ced7e36 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 1, 2017 at 8:15 AM, Brian Trammell (IETF) wrote: > > > On 26 Oct 2017, at 13:38, Philipp S. Tiesel wrote: > > > > Hi, > > > > I really like the listing of which information QUIC exposes. > > I have just one little question about it: Should Section 3 also state > which information is exposed my the integrated TLS handshake? > > Yes, it should. > > > AFAIK, the TLS handshake exposes the application protocol and host name > in clear. > > As I understand it, TLS1.3 should fix this. > Not at present, though we are working on it for the future. -Ekr > > I am not sure whether it also exposes the initial QUIC connection > parameters in clear. > > As I read it, the cleartext packets only contain the TLS1.3 handshake. > > Cheers, > > Brian > > > AVE! > > Philipp S. Tiesel / phils=E2=80=A6 > > > >> On 25. Oct 2017, at 10:11, internet-drafts@ietf.org wrote: > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts > directories. > >> This draft is a work item of the QUIC WG of the IETF. > >> > >> Title : Manageability of the QUIC Transport Protocol > >> Authors : Mirja Kuehlewind > >> Brian Trammell > >> Filename : draft-ietf-quic-manageability-01.txt > >> Pages : 13 > >> Date : 2017-10-25 > >> > >> Abstract: > >> This document discusses manageability of the QUIC transport protocol= , > >> focusing on caveats impacting network operations involving QUIC > >> traffic. Its intended audience is network operators, as well as > >> content providers that rely on the use of QUIC-aware middleboxes, > >> e.g. for load balancing. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/ > >> > >> There are also htmlized versions available at: > >> https://tools.ietf.org/html/draft-ietf-quic-manageability-01 > >> https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-01 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-quic-manageability-01 > >> > >> > >> Please note that it may take a couple of minutes from the time of > submission > >> until the htmlized version and diff are available at tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> > > > > > > --001a1142e4ccc5c61b055ced7e36 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 1, 2017 at 8:15 AM, Brian Trammell (IETF) <ietf@trammell.ch= > wrote:
<= br> > On 26 Oct 2017, at 13:38, Philipp S. Tiesel <phils@in-panik.de> wrote:
>
> Hi,
>
> I really like the listing of which information QUIC exposes.
> I have just one little question about it: Should Section 3 also state = which information is exposed my the integrated TLS handshake?

Yes, it should.

> AFAIK, the TLS handshake exposes the application protocol and host nam= e in clear.

As I understand it, TLS1.3 should fix this.
Not at present, though we are working on it for the future.

-Ekr


> I am not sure whether it also exposes the initial QUIC connection para= meters in clear.

As I read it, the cleartext packets only contain the TLS1.3 handshak= e.

Cheers,

Brian

> AVE!
>=C2=A0 =C2=A0Philipp S. Tiesel / phils=E2=80=A6
>
>> On 25. Oct 2017, at 10:11, internet-drafts@ietf.org wrote:
>>
>>
>> A New Internet-Draft is available from the on-line Internet-Drafts= directories.
>> This draft is a work item of the QUIC WG of the IETF.
>>
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0: Manageability of the QUIC Transport Protocol
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0: Mirja Kuehlewind
>>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Brian Trammell
>>=C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-ie= tf-quic-manageability-01.txt
>>=C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= : 13
>>=C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = : 2017-10-25
>>
>> Abstract:
>>=C2=A0 =C2=A0This document discusses manageability of the QUIC tran= sport protocol,
>>=C2=A0 =C2=A0focusing on caveats impacting network operations invol= ving QUIC
>>=C2=A0 =C2=A0traffic.=C2=A0 Its intended audience is network operat= ors, as well as
>>=C2=A0 =C2=A0content providers that rely on the use of QUIC-aware m= iddleboxes,
>>=C2=A0 =C2=A0e.g. for load balancing.
>>
>>
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org= /doc/draft-ietf-quic-manageability/
>>
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-quic-manageability-01
>> https://datatracker.i= etf.org/doc/html/draft-ietf-quic-manageability-01
>>
>> A diff from the previous version is available at:
>> https://www.ietf.org/rf= cdiff?url2=3Ddraft-ietf-quic-manageability-01
>>
>>
>> Please note that it may take a couple of minutes from the time of = submission
>> until the htmlized version and diff are available at tools.ietf.org.
>>
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>>
>>
>
>


--001a1142e4ccc5c61b055ced7e36-- From nobody Wed Nov 1 08:27: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 2078D13FDA2 for ; Wed, 1 Nov 2017 08:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1_hN_GWzF3sL for ; Wed, 1 Nov 2017 08:27:45 -0700 (PDT) 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 8C4C413FD88 for ; Wed, 1 Nov 2017 08:27:45 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 069913407BA; Wed, 1 Nov 2017 16:27:44 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.352); Wed, 1 Nov 2017 16:27:44 +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; Wed, 1 Nov 2017 16:27:43 +0100 (CET) Received: from [161.23.247.65] (account ietf@trammell.ch [161.23.247.65] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 34610886; Wed, 01 Nov 2017 16:27:43 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_DC9919C1-74D2-441C-A9F2-564C52B9B373"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I-D Action: draft-ietf-quic-manageability-01.txt Date: Wed, 1 Nov 2017 15:27:42 +0000 In-Reply-To: Cc: "Philipp S. Tiesel" , QUIC WG To: Eric Rescorla References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> <6D868BC1-8BE5-4CAA-BEFC-79046C887505@in-panik.de> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 15:27:48 -0000 --Apple-Mail=_DC9919C1-74D2-441C-A9F2-564C52B9B373 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Ekr, > On 1 Nov 2017, at 15:25, Eric Rescorla wrote: >=20 >=20 >=20 > On Wed, Nov 1, 2017 at 8:15 AM, Brian Trammell (IETF) = wrote: >=20 > > On 26 Oct 2017, at 13:38, Philipp S. Tiesel = wrote: > > > > Hi, > > > > I really like the listing of which information QUIC exposes. > > I have just one little question about it: Should Section 3 also = state which information is exposed my the integrated TLS handshake? >=20 > Yes, it should. >=20 > > AFAIK, the TLS handshake exposes the application protocol and host = name in clear. >=20 > As I understand it, TLS1.3 should fix this. >=20 > Not at present, though we are working on it for the future. Thanks for the correction. I'll add this to the set of exposed = information for QUIC at present in the working copy of the draft, then. Cheers, Brian >=20 >=20 > > I am not sure whether it also exposes the initial QUIC connection = parameters in clear. >=20 > As I read it, the cleartext packets only contain the TLS1.3 handshake. >=20 > Cheers, >=20 > Brian >=20 > > AVE! > > Philipp S. Tiesel / phils=E2=80=A6 > > > >> On 25. Oct 2017, at 10:11, internet-drafts@ietf.org wrote: > >> > >> > >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. > >> This draft is a work item of the QUIC WG of the IETF. > >> > >> Title : Manageability of the QUIC Transport = Protocol > >> Authors : Mirja Kuehlewind > >> Brian Trammell > >> Filename : draft-ietf-quic-manageability-01.txt > >> Pages : 13 > >> Date : 2017-10-25 > >> > >> Abstract: > >> This document discusses manageability of the QUIC transport = protocol, > >> focusing on caveats impacting network operations involving QUIC > >> traffic. Its intended audience is network operators, as well as > >> content providers that rely on the use of QUIC-aware middleboxes, > >> e.g. for load balancing. > >> > >> > >> The IETF datatracker status page for this draft is: > >> https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/ > >> > >> There are also htmlized versions available at: > >> https://tools.ietf.org/html/draft-ietf-quic-manageability-01 > >> = https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-01 > >> > >> A diff from the previous version is available at: > >> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-quic-manageability-01 > >> > >> > >> Please note that it may take a couple of minutes from the time of = submission > >> until the htmlized version and diff are available at = tools.ietf.org. > >> > >> Internet-Drafts are also available by anonymous FTP at: > >> ftp://ftp.ietf.org/internet-drafts/ > >> > >> > > > > >=20 >=20 --Apple-Mail=_DC9919C1-74D2-441C-A9F2-564C52B9B373 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAln55+4ACgkQihK3vwvq RqPHvxAAo/ObsUWBBnwKJqyx2UCDKDTL2vrO19ykMzN3FPwa+Fx0uSzuk75nPsHv A6rNprGqTy4elFATvGBlVv+BgjUwN3jctItYdyIgZsdyaCXawOkVQUtlVe3zj2GX YJSudUuzCw3MjWnjzxCXSvzIEw9RzHkYAgVpKKNQaozkKuobreQlAeS3NIBBCyGA QOyGElYUJWjERAhFuCc0NROWpZuytCEu5O7STuWrUb5OLEN3M+zHW+Sk5JKCpyvi 1S0ONVNJ4lIXNPKMMesFmxlH0W4t4WVgKJFMcmKwtjbBykLGsi+eHUG9Ssi0ugzq 5jx24UKKGl53rrkOHG2DyosX4QF2PVDO+/+Ki7/khGADDeRc3XVJjwk8qHHtG/sv v/cRsImrqr5ZOQX2QCjLud/k121wreQ0IMASzOpYIsqfM5Q8qBMZ6lxt8beznHcr /uPZyFmIU126TmIA1vxvhTnZeBxSxSrZ4JygGDLGq3h94efsw8Lwdm0M8splH1GM pbouDcihFQyVl0alP+ed576GltE9GSyTCnMnNYJxyp5cZ+kQk8njOVPYNWItfwOQ fFtxukOSE7ZuocFUE8TGuJpNv9tb/QgB37+LEGEmdjKpFESTOcmCL0zMqsEKEoJ/ KKegbu1ILESReUq/k/zmRpTilLjLze9LgBYkRnUaktmkrpKB/rA= =FBSN -----END PGP SIGNATURE----- --Apple-Mail=_DC9919C1-74D2-441C-A9F2-564C52B9B373-- From nobody Wed Nov 1 08:29: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 F3B0713F56F for ; Wed, 1 Nov 2017 08:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=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 EEkKGJzQgtcH for ; Wed, 1 Nov 2017 08:29:00 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 8A12313F5EC for ; Wed, 1 Nov 2017 08:29:00 -0700 (PDT) Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA1FLbaq019565; Wed, 1 Nov 2017 15:29:00 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=jan2016.eng; bh=m5MtbsfkQLzn3MhIpR3xxMN70YmZR8GcXTo5tDcGifM=; b=W+9k2NbIiAqwgATztjXfZESk6aOXv46ArN1rw0JFo51LoT0exNWWjBWxvysNs8PFEbW+ 8Wugas9OWCQWRU2lQDg5xqayUHRNNgG8tnveb01VfIT/ssZObMkqipdCjGbBL0HPjmeV qNZyM87teL/taale8ZVm5Ekb0e1NDwrPEeNhfKDnHsIj4IAehHd+lLtdcKe8xbGCSaUr hE1AgTZ9RQ2/CVC4QtM4WEJOfuFuw3F5ZhgvhYciqlUTwOGdsWuIgFDRTi6/EeNUUhpi aevV/EyRIaku/W+Kqgb838FIxYY5uDDoOSKryANmK/SJNbuF/XdhMCBmZ3HNwNnXKPWB Ow== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by mx0a-00190b01.pphosted.com with ESMTP id 2dvmw2pg9e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 01 Nov 2017 15:28:59 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA1FQCQL001186; Wed, 1 Nov 2017 11:28:57 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dvn7uurv3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 01 Nov 2017 11:28:57 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 1 Nov 2017 11:28:57 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1263.000; Wed, 1 Nov 2017 11:28:57 -0400 From: "Salz, Rich" To: "Brian Trammell (IETF)" , "Philipp S. Tiesel" CC: QUIC WG Subject: Re: I-D Action: draft-ietf-quic-manageability-01.txt Thread-Topic: I-D Action: draft-ietf-quic-manageability-01.txt Thread-Index: AQHTTWkHRvqh1tmueEKx20MUYdOlcqL2VsIAgAmZ4ICAAAPdAA== Date: Wed, 1 Nov 2017 15:28:56 +0000 Message-ID: <54EAB984-F4A2-4D94-841F-662055A7D118@akamai.com> References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> <6D868BC1-8BE5-4CAA-BEFC-79046C887505@in-panik.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.44] Content-Type: text/plain; charset="utf-8" Content-ID: <359731BB9226264B875707DA31A5B2E6@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-01_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711010212 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-01_03:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 lowpriorityscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711010211 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 15:29:05 -0000 4p6iID4gQUZBSUssIHRoZSBUTFMgaGFuZHNoYWtlIGV4cG9zZXMgdGhlIGFwcGxpY2F0aW9uIHBy b3RvY29sIGFuZCBob3N0IG5hbWUgaW4gY2xlYXIuDQogICAgDQrinqIgICAgIEFzIEkgdW5kZXJz dGFuZCBpdCwgVExTMS4zIHNob3VsZCBmaXggdGhpcy4NCiAgICANCkFMUE4gKGFwcGxpY2F0aW9u IHByb3RvY29sKSBpcyBpbiBjbGVhcnRleHQuIFRoZSBTTkkgKHNlcnZlciBuYW1lKSBleHRlbnNp b24gaXMgYWxzbyBpbiBjbGVhcnRleHQsIGJ1dCB0aGVyZSBpcyBzb21lIHdvcmsgc3RhcnRpbmcg KGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRscy1zbmktZW5jcnlwdGlv bi0wMCkgdG8gYWRkcmVzcyB0aGlzLg0KDQoNCg== From nobody Wed Nov 1 08:41: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 0DD7313F5A3 for ; Wed, 1 Nov 2017 08:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 i4C7nJqRDbv8 for ; Wed, 1 Nov 2017 08:41:47 -0700 (PDT) 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 ietfa.amsl.com (Postfix) with ESMTPS id 76AF213F4FF for ; Wed, 1 Nov 2017 08:41:47 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 39F36340E38 for ; Wed, 1 Nov 2017 16:41:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.2602); Wed, 1 Nov 2017 16:41:46 +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 for ; Wed, 1 Nov 2017 16:41:46 +0100 (CET) Received: from [161.23.247.65] (account ietf@trammell.ch [161.23.247.65] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 34612465 for quic@ietf.org; Wed, 01 Nov 2017 16:41:46 +0100 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_06F37BAD-6823-407E-9E4E-1DDB4C6FDF4B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I-D Action: draft-ietf-quic-manageability-01.txt Date: Wed, 1 Nov 2017 15:41:45 +0000 References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> <6D868BC1-8BE5-4CAA-BEFC-79046C887505@in-panik.de> To: QUIC WG In-Reply-To: Message-Id: <1C982947-DB92-4133-A5A7-8AA4757743ED@trammell.ch> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 15:41:50 -0000 --Apple-Mail=_06F37BAD-6823-407E-9E4E-1DDB4C6FDF4B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Proposed addition to the draft at = https://github.com/quicwg/ops-drafts/pull/21 > On 1 Nov 2017, at 15:27, Brian Trammell (IETF) = wrote: >=20 > hi Ekr, >=20 >> On 1 Nov 2017, at 15:25, Eric Rescorla wrote: >>=20 >>=20 >>=20 >> On Wed, Nov 1, 2017 at 8:15 AM, Brian Trammell (IETF) = wrote: >>=20 >>> On 26 Oct 2017, at 13:38, Philipp S. Tiesel = wrote: >>>=20 >>> Hi, >>>=20 >>> I really like the listing of which information QUIC exposes. >>> I have just one little question about it: Should Section 3 also = state which information is exposed my the integrated TLS handshake? >>=20 >> Yes, it should. >>=20 >>> AFAIK, the TLS handshake exposes the application protocol and host = name in clear. >>=20 >> As I understand it, TLS1.3 should fix this. >>=20 >> Not at present, though we are working on it for the future. >=20 > Thanks for the correction. I'll add this to the set of exposed = information for QUIC at present in the working copy of the draft, then. >=20 > Cheers, >=20 > Brian >=20 >>=20 >>=20 >>> I am not sure whether it also exposes the initial QUIC connection = parameters in clear. >>=20 >> As I read it, the cleartext packets only contain the TLS1.3 = handshake. >>=20 >> Cheers, >>=20 >> Brian >>=20 >>> AVE! >>> Philipp S. Tiesel / phils=E2=80=A6 >>>=20 >>>> On 25. Oct 2017, at 10:11, internet-drafts@ietf.org wrote: >>>>=20 >>>>=20 >>>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>>> This draft is a work item of the QUIC WG of the IETF. >>>>=20 >>>> Title : Manageability of the QUIC Transport = Protocol >>>> Authors : Mirja Kuehlewind >>>> Brian Trammell >>>> Filename : draft-ietf-quic-manageability-01.txt >>>> Pages : 13 >>>> Date : 2017-10-25 >>>>=20 >>>> Abstract: >>>> This document discusses manageability of the QUIC transport = protocol, >>>> focusing on caveats impacting network operations involving QUIC >>>> traffic. Its intended audience is network operators, as well as >>>> content providers that rely on the use of QUIC-aware middleboxes, >>>> e.g. for load balancing. >>>>=20 >>>>=20 >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-quic-manageability/ >>>>=20 >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-quic-manageability-01 >>>> = https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageability-01 >>>>=20 >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-quic-manageability-01 >>>>=20 >>>>=20 >>>> Please note that it may take a couple of minutes from the time of = submission >>>> until the htmlized version and diff are available at = tools.ietf.org. >>>>=20 >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ --Apple-Mail=_06F37BAD-6823-407E-9E4E-1DDB4C6FDF4B 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAln56zkACgkQihK3vwvq RqOdtg//aw7yKX+rIHJ+BfJ0BigbsmDmJMQGnUIeslGPTjbUwesOr3OivDs58Qm6 lPOggtdtycz83xNcC/WSwQxJvh+y2QqlrOAClXkYyBdwUQJKEJSaFyFCa3zzXSIv KKrigr+/6N5BdDeJ1P0ErXEATeiCo3pM/MTTs9kE7+6ZQ2AOcRON3oYkgg5j7vPb vzaYmtBzxZp7t5QuIs8WUWXFXGGyO5yN0FL4UPpCUlYJ5b6mRmgm5NOcFxC2x7ug ykjQAW1odcl0HmcyTt4BMsV5pbRDtEhhK2NwgfS8yFzqxkk9ghRO0rHroaEKnnah LnfLnqxGLGAMSDDsoyD9XaZZZqW8aBE+vgOEb6uM0uhdkc2MC5IwFzbbgH3LchSp dc2YVOBsKzRGhBBDNWhawDvPcnGxeloBv8doKr/byhCy6lQXQj6jheSut3aSDygW NE5CrGpPd/e8tGatGNZ/cLEkEVh9taIgVNWOkvSRE2fBptJHZoJyig4+5XIjeSxo 3HMRR6eUztBhYH7qJxfqHUYIdnusXwdtSs4Pmc5tOOxbnzMPULijHJeiH9AOdQMt P0elFcL/JBQDgO1Sg2Uty3IP4lWEbQSAIOpgz6PxaJR2VbpHtgnTM147tD8eoGaE 6caamCnYndQoeYrxwDtHddeA2nDKi1snTuybxhWXDwiGHm9Fl14= =T6yN -----END PGP SIGNATURE----- --Apple-Mail=_06F37BAD-6823-407E-9E4E-1DDB4C6FDF4B-- From nobody Thu Nov 2 13:50: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 74F1F13F95E for ; Thu, 2 Nov 2017 13:50:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ABM9aXead7UA for ; Thu, 2 Nov 2017 13:50:36 -0700 (PDT) Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (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 4755513F95F for ; Thu, 2 Nov 2017 13:50:35 -0700 (PDT) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vA2KnrDs022466 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 2 Nov 2017 21:49:53 +0100 Received: from [2001:bf0:c801:101:c821:9806:c083:513a] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eAMQX-0004Ge-DY; Thu, 02 Nov 2017 21:49:25 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments From: "Philipp S. Tiesel" In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> Date: Thu, 2 Nov 2017 21:49:50 +0100 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3445.4.7) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 20:50:38 -0000 Hi > On 1. Nov 2017, at 14:03, Roni Even wrote: >=20 > Hi, > =20 > I think support for unreliable streams is important for unidirectional = and bi-directional streams and even if it is V2 we still need to take = support for it into account. One use case is RTP over QUIC. > =20 > Small comments: > =20 > In section 4.2 =E2=80=9C The loss of such a frame does not introduce = state at the perceived receiver=E2=80=9D. If new streams are opened with = higher stream ID, it implicitly opens this one frame stream that was = lost in the receiver. I think it still requires the sender to send a = reliable FIN to close this stream. You=E2=80=99re right. I overlooked this. =E2=80=93 The draft says: Streams MUST be created in sequential order. Open streams can be used = in any order. Streams that are used out of order result in lower-numbered streams in the same direction being counted as open. I don=E2=80=99t know the rational behind this, but I think this is, = besides the complications for unreliable streams, unfortunate: - with unidirectional streams, this looks a little ambiguous. - it prevents the application in encode its own flags within the stream = ID. Can anyone tell me the reason for this MUST?=20 I Put it on the ToDo-List for -02 > In the security section =E2=80=9C An active, on path attacker can drop = selected frames =E2=80=9C . What does it mean selected frames, the whole = payload is encrypted. This is a little complicated: - Assume having =E2=80=9Cstream-as-a-message=E2=80=9D streams with two = different kins of messages sized A,B - Assume each message fits into one packet, but two messages will not = fit - Assume one doesn't want to split packets to fill packets to MTU due = to latency constrains =3D> If an attacker know the inside protocol, the attacker can = distinguish from the packet length wether it is an A or B kind message To avoid this, one has to pad all packets=E2=80=A6 I should clarify = this. AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' From nobody Sun Nov 5 00:32: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 9FD8C13FB5B for ; Sun, 5 Nov 2017 00:32:40 -0700 (PDT) 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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pWMeZ5qga0m for ; Sun, 5 Nov 2017 00:32:37 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71F1913FA6E for ; Sun, 5 Nov 2017 00:32:37 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML713-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRZ90124; Sun, 05 Nov 2017 07:32:34 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 5 Nov 2017 07:32:33 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Sun, 5 Nov 2017 15:32:28 +0800 From: Roni Even To: "Philipp S. Tiesel" CC: QUIC WG Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Topic: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Index: AQHTVBwwoDixcEmLIk67t+44J7ng4KMFZwIg Date: Sun, 5 Nov 2017 07:32:27 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD832288@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.65] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090201.59FEBE93.003E, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.14, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 455e522544b23ad160bdb3e6b2c410bd Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 05 Nov 2017 07:32:40 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUGhpbGlwcCBTLiBUaWVz ZWwgW21haWx0bzpwaGlsc0Bpbi1wYW5pay5kZV0NCj4gU2VudDog15nXldedwqDXlCAwMiDXoNeV 15HXnteR16ggMjAxNyAyMjo1MA0KPiBUbzogUm9uaSBFdmVuDQo+IENjOiBRVUlDIFdHDQo+IFN1 YmplY3Q6IFJlOiBkcmFmdC10aWVzZWwtcXVpYy11bnJlbGlhYmxlLXN0cmVhbXMtMDEgLSBjb21t ZW50cw0KPiANCj4gSGkNCj4gDQo+ID4gT24gMS4gTm92IDIwMTcsIGF0IDE0OjAzLCBSb25pIEV2 ZW4gPHJvbmkuZXZlbkBodWF3ZWkuY29tPiB3cm90ZToNCj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4g SSB0aGluayBzdXBwb3J0IGZvciB1bnJlbGlhYmxlIHN0cmVhbXMgaXMgaW1wb3J0YW50IGZvciB1 bmlkaXJlY3Rpb25hbCBhbmQgYmktDQo+IGRpcmVjdGlvbmFsIHN0cmVhbXMgYW5kIGV2ZW4gaWYg aXQgaXMgVjIgd2Ugc3RpbGwgbmVlZCB0byB0YWtlIHN1cHBvcnQgZm9yIGl0IGludG8NCj4gYWNj b3VudC4gT25lIHVzZSBjYXNlIGlzIFJUUCBvdmVyIFFVSUMuDQo+ID4NCj4gPiBTbWFsbCBjb21t ZW50czoNCj4gPg0KPiA+IEluIHNlY3Rpb24gNC4yIOKAnCBUaGUgbG9zcyBvZiBzdWNoIGEgZnJh bWUgZG9lcyBub3QgaW50cm9kdWNlIHN0YXRlIGF0IHRoZQ0KPiBwZXJjZWl2ZWQgcmVjZWl2ZXLi gJ0uIElmIG5ldyBzdHJlYW1zIGFyZSBvcGVuZWQgd2l0aCBoaWdoZXIgc3RyZWFtIElELCAgaXQN Cj4gaW1wbGljaXRseSBvcGVucyB0aGlzIG9uZSBmcmFtZSBzdHJlYW0gdGhhdCB3YXMgbG9zdCBp biB0aGUgcmVjZWl2ZXIuIEkgdGhpbmsgaXQNCj4gc3RpbGwgcmVxdWlyZXMgdGhlIHNlbmRlciB0 byBzZW5kIGEgcmVsaWFibGUgRklOIHRvIGNsb3NlIHRoaXMgc3RyZWFtLg0KPiANCj4gWW914oCZ cmUgcmlnaHQuIEkgb3Zlcmxvb2tlZCB0aGlzLiDigJMgVGhlIGRyYWZ0IHNheXM6DQo+ICAgU3Ry ZWFtcyBNVVNUIGJlIGNyZWF0ZWQgaW4gc2VxdWVudGlhbCBvcmRlci4gT3BlbiBzdHJlYW1zIGNh biBiZSB1c2VkIGluDQo+ICAgYW55IG9yZGVyLiBTdHJlYW1zIHRoYXQgYXJlIHVzZWQgb3V0IG9m IG9yZGVyIHJlc3VsdCBpbiBsb3dlci1udW1iZXJlZA0KPiAgIHN0cmVhbXMgaW4gdGhlIHNhbWUg ZGlyZWN0aW9uIGJlaW5nIGNvdW50ZWQgYXMgb3Blbi4NCj4gDQo+IEkgZG9u4oCZdCBrbm93IHRo ZSByYXRpb25hbCBiZWhpbmQgdGhpcywgYnV0IEkgdGhpbmsgdGhpcyBpcywgYmVzaWRlcyB0aGUN Cj4gY29tcGxpY2F0aW9ucyBmb3IgdW5yZWxpYWJsZSBzdHJlYW1zLCB1bmZvcnR1bmF0ZToNCj4g IC0gd2l0aCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zLCB0aGlzIGxvb2tzIGEgbGl0dGxlIGFtYmln dW91cy4NCj4gIC0gaXQgcHJldmVudHMgdGhlIGFwcGxpY2F0aW9uIGluIGVuY29kZSBpdHMgb3du IGZsYWdzIHdpdGhpbiB0aGUgc3RyZWFtIElELg0KPiANCj4gQ2FuIGFueW9uZSB0ZWxsIG1lIHRo ZSByZWFzb24gZm9yIHRoaXMgTVVTVD8NCj4gDQo+IEkgUHV0IGl0IG9uIHRoZSBUb0RvLUxpc3Qg Zm9yIC0wMg0KPiANCj4gPiBJbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiDigJwgQW4gYWN0aXZlLCBv biBwYXRoIGF0dGFja2VyIGNhbiBkcm9wIHNlbGVjdGVkDQo+IGZyYW1lcyDigJwgLiBXaGF0IGRv ZXMgaXQgbWVhbiBzZWxlY3RlZCBmcmFtZXMsIHRoZSB3aG9sZSBwYXlsb2FkIGlzDQo+IGVuY3J5 cHRlZC4NCj4gDQo+IFRoaXMgaXMgYSBsaXR0bGUgY29tcGxpY2F0ZWQ6DQo+ICAtIEFzc3VtZSBo YXZpbmcg4oCcc3RyZWFtLWFzLWEtbWVzc2FnZeKAnSBzdHJlYW1zIHdpdGggdHdvIGRpZmZlcmVu dCBraW5zIG9mDQo+IG1lc3NhZ2VzIHNpemVkIEEsQg0KPiAgLSBBc3N1bWUgZWFjaCBtZXNzYWdl IGZpdHMgaW50byBvbmUgcGFja2V0LCBidXQgdHdvIG1lc3NhZ2VzIHdpbGwgbm90IGZpdA0KPiAg LSBBc3N1bWUgb25lIGRvZXNuJ3Qgd2FudCB0byBzcGxpdCBwYWNrZXRzIHRvIGZpbGwgcGFja2V0 cyB0byBNVFUgZHVlIHRvDQo+IGxhdGVuY3kgY29uc3RyYWlucyAgPT4gSWYgYW4gYXR0YWNrZXIg a25vdyB0aGUgaW5zaWRlIHByb3RvY29sLCB0aGUgYXR0YWNrZXINCj4gY2FuIGRpc3Rpbmd1aXNo IGZyb20gdGhlIHBhY2tldCBsZW5ndGggd2V0aGVyIGl0IGlzIGFuIEEgb3IgQiBraW5kIG1lc3Nh Z2UNCj4gDQo+IFRvIGF2b2lkIHRoaXMsIG9uZSBoYXMgdG8gcGFkIGFsbCBwYWNrZXRz4oCmIEkg c2hvdWxkIGNsYXJpZnkgdGhpcy4NCltSb25pIEV2ZW5dIEkgdW5kZXJzdGFuZCB0aGlzIGNhc2Ug YnV0IHdoYXQgZG9lcyBzZWxlY3RlZCBmcmFtZXMgbWVhbiwgSSBhc3N1bWUgdGhhdCB0aGUgYXR0 YWNrZXIgZG9lcyBub3Qga25vdyB3aGF0IGlzIGluIGVhY2ggc3RyZWFtIGluIG9yZGVyIHRvIHNl bGVjdCBhIHNwZWNpZmljIG9uZSwgc28gd2h5IHdpbGwgaGUganVzdCBkcm9wIG9uZSBhbmQgbm90 IHRoZSBvdGhlciBvciB3aHkgbm90IGJvdGg/DQo+IA0KPiBBVkUhDQo+ICAgUGhpbGlwcCBTLiBU aWVzZWwgLyBwaGlsc+KApg0KPiAtLQ0KPiAgICB7cGhpbHN9LS0tPi0tLShwaGlsc0Bpbi1wYW5p ay5kZSktLS0+LS0tKGh0dHA6Ly9waGlscy5pbi1wYW5pay5kZSktLS0tLA0KPiAgICAgICB3ZW5u IHcgZWluZSAgIGF1YmUgaXN0IGRuICAgICAgbWFuIGF1IGRyYW4gZHJlIGVuICAgICAgICAgICAg ICAgICAgIHwNCj4gICAgICAgICAgICBvICAgICBTY2hyICAgICAgICBhbiBtdXNzICAgICBoYyAg ICAgICAgIGggICAoS3VydCBTY2h3aXR0ZXJzKSB8DQo+IDp3cSEgIDwtLS0tKHBob25lOiArNDkt MTc5LTY3Mzc0MzkpLS0tPC0tLShqYWJiZXI6IHBoaWxzQGluLXBhbmlrLmRlKS0tLS0nDQoNCg== From nobody Mon Nov 6 01:16: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 1CA9013FB57 for ; Mon, 6 Nov 2017 01:16:03 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fqxxs68VvGBL for ; Mon, 6 Nov 2017 01:16:01 -0800 (PST) Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (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 0D8B313F963 for ; Mon, 6 Nov 2017 01:15:59 -0800 (PST) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vA69EoLB021865 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 6 Nov 2017 10:14:50 +0100 Received: from [2001:638:809:ff1f::8295:dc66] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eBdU6-0001i8-GO; Mon, 06 Nov 2017 10:14:22 +0100 From: "Philipp S. Tiesel" Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_D48B2C7E-C5D6-4E0C-AEC5-D2EA43096AF7" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments Date: Mon, 6 Nov 2017 10:14:49 +0100 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD832288@DGGEMM506-MBX.china.huawei.com> Cc: QUIC WG To: Roni Even References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD832288@DGGEMM506-MBX.china.huawei.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:16:03 -0000 --Apple-Mail=_D48B2C7E-C5D6-4E0C-AEC5-D2EA43096AF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5. Nov 2017, at 08:32, Roni Even wrote: >> From: Philipp S. Tiesel [mailto:phils@in-panik.de] >>> On 1. Nov 2017, at 14:03, Roni Even wrote: >>>=20 >>> In the security section =E2=80=9C An active, on path attacker can = drop selected >>> frames =E2=80=9C . What does it mean selected frames, the whole = payload is >>> encrypted. >>>=20 >> This is a little complicated: >> - Assume having =E2=80=9Cstream-as-a-message=E2=80=9D streams with = two different kins of >> messages sized A,B >> - Assume each message fits into one packet, but two messages will not = fit >> - Assume one doesn't want to split packets to fill packets to MTU due = to >> latency constrains =3D> If an attacker know the inside protocol, the = attacker >> can distinguish from the packet length wether it is an A or B kind = message >>=20 >> To avoid this, one has to pad all packets=E2=80=A6 I should clarify = this. > [Roni Even] I understand this case but what does selected frames mean, = I assume that the attacker does not know what is in each stream in order = to select a specific one, so why will he just drop one and not the other = or why not both? Assuming the attacker _knows the protocol_, the attacker would also know = the sizes of all kinds of messages and may use this knowledge to recover = protocol state or selectively drop messages. For a protocol like HTTP, the attack vector is rather small. If one uses this against video conferencing applications, an attacker = could prevent rate adaption by dropping reception reports (larger than = a pure QUIC ACK, smaller than a video frame). If one uses this on IoT control stuff, an attacker might be able to = learn a lot about the system state by observing sizes and timings. This is nothing we can fix within QUIC without massive scarifies, but = application developers must keep in mind. AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' --Apple-Mail=_D48B2C7E-C5D6-4E0C-AEC5-D2EA43096AF7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 5. Nov 2017, at 08:32, Roni Even <roni.even@huawei.com> wrote:
From: Philipp S. Tiesel [mailto:phils@in-panik.de]
On 1. Nov 2017, at 14:03, Roni Even <roni.even@huawei.com> wrote:

In the = security section =E2=80=9C An active, on path attacker can drop = selected
frames =E2=80=9C . What does it mean selected frames, the = whole payload is
encrypted.

This is a little complicated:
- = Assume having =E2=80=9Cstream-as-a-message=E2=80=9D streams with two = different kins of
messages sized A,B
- = Assume each message fits into one packet, but two messages will not = fit
- Assume one doesn't want to split packets to fill = packets to MTU due to
latency constrains  =3D> If = an attacker know the inside protocol, the attacker
can = distinguish from the packet length wether it is an A or B kind = message

To avoid this, one has to pad all = packets=E2=80=A6 I should clarify this.
[Roni Even] I = understand this case but what does selected frames mean, I assume that = the attacker does not know what is in each stream in order to select a = specific one, so why will he just drop one and not the other or why not = both?

Assuming the attacker = _knows the protocol_, the attacker would also know the sizes of all = kinds of messages and may use this knowledge to recover protocol state = or selectively drop messages.

For a protocol like HTTP, the attack = vector is rather small.
If one uses this against = video conferencing applications, an attacker could prevent rate adaption =  by dropping reception reports (larger than a pure QUIC ACK, = smaller than a video frame).
If one uses this on = IoT control stuff, an attacker might be able to learn a lot about the = system state by observing sizes and timings.

This is nothing we can fix within QUIC = without massive scarifies, but application developers must keep in = mind.


AVE!
  Philipp S. Tiesel / phils=E2=80=A6-- 
   {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
  =     wenn w eine   aube ist dn      man au = dran dre en                 =   |
           o   =   Schr        an muss     hc   =       h   (Kurt Schwitters) |
:wq! =  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

= --Apple-Mail=_D48B2C7E-C5D6-4E0C-AEC5-D2EA43096AF7-- From nobody Mon Nov 6 23: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 DF19813FB8A for ; Mon, 6 Nov 2017 23:40:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 9aCdP_6sCark for ; Mon, 6 Nov 2017 23:40: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 A426013FB32 for ; Mon, 6 Nov 2017 23:40:48 -0800 (PST) X-AuditID: c1b4fb25-1b7d19c000000c94-55-5a01637e0e35 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 27.5D.03220.E73610A5; Tue, 7 Nov 2017 08:40:46 +0100 (CET) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 7 Nov 2017 08:40:45 +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=OLtWAnhl4CM1a4d3lGjKQgUM9trmhGNTpiG9d04XwkI=; b=WSWV6GMvCyesApGEzM0SJoUp9V+O5v09kyCYuG7OEv1uR4BzBiBK9i97YFMUPIi4BghcNrcCsLbfRJyCl1Funb7FjWY8kDaN1T1mgonCPapCPWY2u6pyHy7HT7kCacYsCHU4RNMi4bPaVOqnHbBzVBAgzu1ZEIfXzIn/wbpaf/8= 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_P256) id 15.20.218.6; Tue, 7 Nov 2017 07:40:44 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::d067:33bc:7c46:c8c9]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::d067:33bc:7c46:c8c9%13]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 07:40:43 +0000 From: Ingemar Johansson S To: "Philipp S. Tiesel" , Roni Even CC: QUIC WG Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Topic: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Index: AQHTVznzaxwXVQFObkG5Q8JOBDTpHqMIg0ww Date: Tue, 7 Nov 2017 07:40:43 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD832288@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 6:o71t1OkHNebuQvp/qWazAo4/nSDb5QHw9WYSlzxSsujqMRzVsyarQdYMb4HM2T6Tnq+n2vx3dIypIpCv0/B8urPUw0bHZ3YTRRyYp7ZivDVOi5CxnA27L/MEUuXwocJtRq/gpYaUYsRZ8F8RulCHiHVP+DeE11wltKxDC48l87T4ElDuxuOQ1YH2YwjPX1+Te2b/+AobUNS9OQaQLZxyw2aDb/+FKhOneF7aGCQ8tkBmM587xkP746zPa3eu1o3Fy/yxO3annFrmDXp4Zq2DhsBvukGlIP8HATVHQzPrMiTgqpxII2+p1M639Fn3fAUgWiu5Pl9FnFDZ5+z7TMYjFOzUh3sEZEMNHX7KXp8MFOs=; 5:EM/L8Yimas5dgHDgu7pF5DpbYxN5EsImRJiEPvoPS+WFVDM3J08B7o7gCD9v+rJc88vNYSdaqx1H5n80VyBNswbnZv2DizWyE/gZBojLtaSY4mmOfJPhCRKEhPfsNTKzUBwJ/RWeLETcZEkhrepLVge2JL8vBYCCNiGHPGg43rU=; 24:Fxh10DLYgLHnJ67cLPqEgkF7umafyZlnTBjDxh4HMjzB1Y0NKa+uE4Vd4WnGFF1v7YmMAUSUNdK0Xx9M8x73S+YdvkTjYEtxpD0i8pbIXQA=; 7:tjg56VrgXaHR7yYAF4NVo3VamdmgJwQKrOsxQ+2DxSgQG0BZBTJ0wtc4YCCahtU2GXvBidAzF1q76j4Zv7kdVS3Ng00NwSKietQOijYTUVGHZsDh2fXByt0JhtUIUSkXYzQoQXULMC7WeXoi+qiMQSV3TkP6EpN7DA0c8+pKLqiijfY2UmQbMLovj6tgHogYh5ydQGioQ5CpNJYW3QbN1ZcUfr8JsITo+ZreAYoF3TU//PehajfwkD4Pv7Dwt5dH x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 932d3c92-db76-4c16-c0b2-08d525b2da4a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:DB4PR07MB345; x-ms-traffictypediagnostic: DB4PR07MB345: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-exchange-antispam-report-test: UriScan:(20558992708506)(278428928389397)(192374486261705)(50582790962513)(21748063052155)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3231021)(3002001)(93006095)(93001095)(6041248)(20161123558100)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB345; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(189002)(24454002)(199003)(74316002)(106356001)(101416001)(14454004)(68736007)(5660300001)(478600001)(55016002)(6506006)(33656002)(6246003)(50986999)(54356999)(2950100002)(230783001)(25786009)(229853002)(6306002)(54896002)(236005)(76176999)(2900100001)(606006)(9686003)(53546010)(7696004)(105586002)(6436002)(8676002)(3660700001)(19609705001)(102836003)(6116002)(790700001)(3846002)(3280700002)(4326008)(81156014)(81166006)(53386004)(86362001)(97736004)(8936002)(99286004)(189998001)(2906002)(110136005)(53936002)(316002)(93886005)(66066001)(5250100002)(7736002); 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; 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_DB4PR07MB34899FCFC336AE2F0B72A6CC2510DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 932d3c92-db76-4c16-c0b2-08d525b2da4a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 07:40:43.7812 (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: H4sIAAAAAAAAA02Se0hTYRjG+3bOtqM5+JwT37yErsKS5mUFSohpUQghFfaHjEDnPOm8TNkx UYkS0wSnqKWgw2tIkoiWJqbWyHnXUlMpXKKpq2FplkmahbTtLPC/H+/zPN974aMIYTvXlVKq 0mm1Sp4s5tmTVVFdVyW3FUjmrzN6BxU0tXKCiuoPBm0OTZKhRHjewDo3vLHxNyc8b9bpCiGz D46jk5UZtNovJMY+YWtuEaUZ72TmvdFxc1DLrUJkRwE+DXcNu/xCZE8JcT+CHVMRzyII8TCC gQ+HLQKJiwlYbXiJWFcFB7TfJmyRjwgWJsr5lggPB8Nj/bbZRVEiHAGlrzMtZQK7QW7JvPVV J3wWKrWDXAuLcCi8z58hWZZCnbbb6iHxUWg2dXIsLMAyWJkd4rG9CjgwPjtoDdiZHxrZbSIs jLAHLG4vkGwzFzAY6zjsbhgaX0wSLDvD6soel2VP+Du9zGPZA6brNNbNAPfxoXBMZwv4QmfZ OmI5An7W9tpMlQi6e2ptwglYLt2xTaGAzbliLmsqQjBS9otkTUpYndSQrDDNhf4f72yCOzQM 6/mlSKLdNzrLqbCm3eZrrTdwhNEqI6k1n5UwN2zr8WMtXlCuWeKzfBzyq2v4++v1iN+MnBma iU2Jl57ypdVKBcOkqnxVdHo7Mv+kvmd/jj1HM2theoQpJHYQ6MKRTMiVZzBZKXoEFCEWCbq8 D8iEgjh5VjatTo1W30ymGT1yo0ixiyBMNxUlxPHydDqJptNo9X+VQ9m55qAbbz1U+VPlixek HQdow5OvXoovbVHrTz/7ux/5fp0p2YpJOpldcsm980xStEmUE6iQ3PfSw3mjY2zrfKJPbhfV 0uJ/+VCk5yY9kF0seVVNXTM8eLgReK9mrqM3MfuTy8WK0XVTrqdU4rY3vvRow3nMYSRSE5I2 E2DwkpLnorIixSSTIA/wIdSM/B/UHTuRRQMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:40:51 -0000 --_000_DB4PR07MB34899FCFC336AE2F0B72A6CC2510DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbGlwIGFuZCBSb25pDQoNCkkgYXNzdW1lIHRoYXQgYnkgcmVjZXB0aW9uIHJlcG9ydHMg aXMgbWVhbnQgdGhlIFJUQ1AgQ0NNIG1lc3NhZ2VzIHN1Y2ggYXMgVE1NQlIgb3IgPw0KDQpTby4u IHVubGVzcyBJIG1pc3VuZGVyc3Rvb2QgaXQgY29tcGxldGVseS4NCkkgYW0gbm90IGF0IGFsbCBj b252aW5jZWQgdGhhdCBtZWRpYSByYXRlL2Nvbmdlc3Rpb24gY29udHJvbCBpbiBRVUlDIHNob3Vs ZCByZWx5IG9uIFRNTUJSLg0KU0NSZUFNIGZvciBpbnN0YW5jZSwgc3BlY2lmaWVkIGluIHRoZSBS TUNBVCBXRyBmb3IgaW5zdGFuY2UgZG9lcyBub3QgZGVwZW5kIG9uIFRNTUJSIGFzIGl0IGlzIEFD SyBjbG9ja2VkLCB0aGUgbWVkaWEgdHJhbnNtaXNzaW9uIGlzIHJlZHVjZWQgdG8gYSB2ZXJ5IGxv dyByYXRlIGlmIHRoZSBBQ0tzIGFyZSBkaXNjYXJkZWQgYnkgYW4gYXR0YWNrZXIuDQoNCkkgd291 bGQgc2F5IHRoYXQgaXQgaXMgbW9yZSBzdHJhaWdodGZvcndhcmQgdG8gdXNlIGEgbXVsdGlwdXJw b3NlIGNvbmdlc3Rpb24gY29udHJvbCBpbiBRVUlDLCB0aGlzIGlzIHBlcmhhcHMgYmFzZWQgb24g QkJSLCBidXQgU0NSZUFNIHN0eWxlIGlzIG5vdCBleGNsdWRlZC4gSW4gYW55IGNhc2UgdGhpcyBt ZWFucyB0aGF0IGl0IGlzIG5vdCBwb3NzaWJsZSB0byBwcmV2ZW50IHJhdGUgYWRhcHRhdGlvbi4N Cg0KL0luZ2VtYXINCg0KDQpGcm9tOiBQaGlsaXBwIFMuIFRpZXNlbCBbbWFpbHRvOnBoaWxzQGlu LXBhbmlrLmRlXQ0KU2VudDogZGVuIDYgbm92ZW1iZXIgMjAxNyAxMDoxNQ0KVG86IFJvbmkgRXZl biA8cm9uaS5ldmVuQGh1YXdlaS5jb20+DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBkcmFmdC10aWVzZWwtcXVpYy11bnJlbGlhYmxlLXN0cmVhbXMtMDEgLSBjb21t ZW50cw0KDQoNCg0KDQpPbiA1LiBOb3YgMjAxNywgYXQgMDg6MzIsIFJvbmkgRXZlbiA8cm9uaS5l dmVuQGh1YXdlaS5jb208bWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpGcm9t OiBQaGlsaXBwIFMuIFRpZXNlbCBbbWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlXQ0KDQpPbiAxLiBO b3YgMjAxNywgYXQgMTQ6MDMsIFJvbmkgRXZlbiA8cm9uaS5ldmVuQGh1YXdlaS5jb208bWFpbHRv OnJvbmkuZXZlbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpJbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiDi gJwgQW4gYWN0aXZlLCBvbiBwYXRoIGF0dGFja2VyIGNhbiBkcm9wIHNlbGVjdGVkDQpmcmFtZXMg 4oCcIC4gV2hhdCBkb2VzIGl0IG1lYW4gc2VsZWN0ZWQgZnJhbWVzLCB0aGUgd2hvbGUgcGF5bG9h ZCBpcw0KZW5jcnlwdGVkLg0KVGhpcyBpcyBhIGxpdHRsZSBjb21wbGljYXRlZDoNCi0gQXNzdW1l IGhhdmluZyDigJxzdHJlYW0tYXMtYS1tZXNzYWdl4oCdIHN0cmVhbXMgd2l0aCB0d28gZGlmZmVy ZW50IGtpbnMgb2YNCm1lc3NhZ2VzIHNpemVkIEEsQg0KLSBBc3N1bWUgZWFjaCBtZXNzYWdlIGZp dHMgaW50byBvbmUgcGFja2V0LCBidXQgdHdvIG1lc3NhZ2VzIHdpbGwgbm90IGZpdA0KLSBBc3N1 bWUgb25lIGRvZXNuJ3Qgd2FudCB0byBzcGxpdCBwYWNrZXRzIHRvIGZpbGwgcGFja2V0cyB0byBN VFUgZHVlIHRvDQpsYXRlbmN5IGNvbnN0cmFpbnMgID0+IElmIGFuIGF0dGFja2VyIGtub3cgdGhl IGluc2lkZSBwcm90b2NvbCwgdGhlIGF0dGFja2VyDQpjYW4gZGlzdGluZ3Vpc2ggZnJvbSB0aGUg cGFja2V0IGxlbmd0aCB3ZXRoZXIgaXQgaXMgYW4gQSBvciBCIGtpbmQgbWVzc2FnZQ0KDQpUbyBh dm9pZCB0aGlzLCBvbmUgaGFzIHRvIHBhZCBhbGwgcGFja2V0c+KApiBJIHNob3VsZCBjbGFyaWZ5 IHRoaXMuDQpbUm9uaSBFdmVuXSBJIHVuZGVyc3RhbmQgdGhpcyBjYXNlIGJ1dCB3aGF0IGRvZXMg c2VsZWN0ZWQgZnJhbWVzIG1lYW4sIEkgYXNzdW1lIHRoYXQgdGhlIGF0dGFja2VyIGRvZXMgbm90 IGtub3cgd2hhdCBpcyBpbiBlYWNoIHN0cmVhbSBpbiBvcmRlciB0byBzZWxlY3QgYSBzcGVjaWZp YyBvbmUsIHNvIHdoeSB3aWxsIGhlIGp1c3QgZHJvcCBvbmUgYW5kIG5vdCB0aGUgb3RoZXIgb3Ig d2h5IG5vdCBib3RoPw0KDQpBc3N1bWluZyB0aGUgYXR0YWNrZXIgX2tub3dzIHRoZSBwcm90b2Nv bF8sIHRoZSBhdHRhY2tlciB3b3VsZCBhbHNvIGtub3cgdGhlIHNpemVzIG9mIGFsbCBraW5kcyBv ZiBtZXNzYWdlcyBhbmQgbWF5IHVzZSB0aGlzIGtub3dsZWRnZSB0byByZWNvdmVyIHByb3RvY29s IHN0YXRlIG9yIHNlbGVjdGl2ZWx5IGRyb3AgbWVzc2FnZXMuDQoNCkZvciBhIHByb3RvY29sIGxp a2UgSFRUUCwgdGhlIGF0dGFjayB2ZWN0b3IgaXMgcmF0aGVyIHNtYWxsLg0KSWYgb25lIHVzZXMg dGhpcyBhZ2FpbnN0IHZpZGVvIGNvbmZlcmVuY2luZyBhcHBsaWNhdGlvbnMsIGFuIGF0dGFja2Vy IGNvdWxkIHByZXZlbnQgcmF0ZSBhZGFwdGlvbiAgYnkgZHJvcHBpbmcgcmVjZXB0aW9uIHJlcG9y dHMgKGxhcmdlciB0aGFuIGEgcHVyZSBRVUlDIEFDSywgc21hbGxlciB0aGFuIGEgdmlkZW8gZnJh bWUpLg0KSWYgb25lIHVzZXMgdGhpcyBvbiBJb1QgY29udHJvbCBzdHVmZiwgYW4gYXR0YWNrZXIg bWlnaHQgYmUgYWJsZSB0byBsZWFybiBhIGxvdCBhYm91dCB0aGUgc3lzdGVtIHN0YXRlIGJ5IG9i c2VydmluZyBzaXplcyBhbmQgdGltaW5ncy4NCg0KVGhpcyBpcyBub3RoaW5nIHdlIGNhbiBmaXgg d2l0aGluIFFVSUMgd2l0aG91dCBtYXNzaXZlIHNjYXJpZmllcywgYnV0IGFwcGxpY2F0aW9uIGRl dmVsb3BlcnMgbXVzdCBrZWVwIGluIG1pbmQuDQoNCg0KQVZFIQ0KICBQaGlsaXBwIFMuIFRpZXNl bCAvIHBoaWxz4oCmDQotLQ0KICAge3BoaWxzfS0tLT4tLS0ocGhpbHNAaW4tcGFuaWsuZGU8bWFp bHRvOnBoaWxzQGluLXBhbmlrLmRlPiktLS0+LS0tKGh0dHA6Ly9waGlscy5pbi1wYW5pay5kZSkt LS0tLA0KICAgICAgd2VubiB3IGVpbmUgICBhdWJlIGlzdCBkbiAgICAgIG1hbiBhdSBkcmFuIGRy ZSBlbiAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgIG8gICAgIFNjaHIgICAgICAgIGFu IG11c3MgICAgIGhjICAgICAgICAgaCAgIChLdXJ0IFNjaHdpdHRlcnMpIHwNCjp3cSEgIDwtLS0t KHBob25lOiArNDktMTc5LTY3Mzc0MzkpLS0tPC0tLShqYWJiZXI6IHBoaWxzQGluLXBhbmlrLmRl PG1haWx0bzpwaGlsc0Bpbi1wYW5pay5kZT4pLS0tLScNCg0K --_000_DB4PR07MB34899FCFC336AE2F0B72A6CC2510DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyOw0KCXBhbm9zZS0x OjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9y bWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNt Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250 LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcw Ljg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SGkgUGhpbGlwIGFuZCBSb25pPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg YXNzdW1lIHRoYXQgYnkgPHU+cmVjZXB0aW9uPC91PiByZXBvcnRzIGlzIG1lYW50IHRoZSBSVENQ IENDTSBtZXNzYWdlcyBzdWNoIGFzIFRNTUJSIG9yID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U28uLiB1bmxlc3MgSSBtaXN1bmRlcnN0b29kIGl0IGNvbXBsZXRlbHkuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBhdCBhbGwgY29udmluY2VkIHRoYXQgbWVk aWEgcmF0ZS9jb25nZXN0aW9uIGNvbnRyb2wgaW4gUVVJQyBzaG91bGQgcmVseSBvbiBUTU1CUi4N CjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U0NSZUFNIGZvciBpbnN0YW5j ZSwgc3BlY2lmaWVkIGluIHRoZSBSTUNBVCBXRyBmb3IgaW5zdGFuY2UgZG9lcyBub3QgZGVwZW5k IG9uIFRNTUJSIGFzIGl0IGlzIEFDSyBjbG9ja2VkLCB0aGUgbWVkaWEgdHJhbnNtaXNzaW9uIGlz IHJlZHVjZWQgdG8gYSB2ZXJ5IGxvdyByYXRlIGlmIHRoZSBBQ0tzIGFyZSBkaXNjYXJkZWQgYnkg YW4gYXR0YWNrZXIuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBzYXkgdGhhdCBp dCBpcyBtb3JlIHN0cmFpZ2h0Zm9yd2FyZCB0byB1c2UgYSBtdWx0aXB1cnBvc2UgY29uZ2VzdGlv biBjb250cm9sIGluIFFVSUMsIHRoaXMgaXMgcGVyaGFwcyBiYXNlZCBvbiBCQlIsIGJ1dCBTQ1Jl QU0gc3R5bGUgaXMgbm90IGV4Y2x1ZGVkLiBJbiBhbnkgY2FzZSB0aGlzIG1lYW5zIHRoYXQgaXQg aXMgbm90IHBvc3NpYmxlIHRvIHByZXZlbnQgcmF0ZSBhZGFwdGF0aW9uLg0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1 ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUGhpbGlwcCBT LiBUaWVzZWwgW21haWx0bzpwaGlsc0Bpbi1wYW5pay5kZV0gPGJyPg0KPGI+U2VudDo8L2I+IGRl biA2IG5vdmVtYmVyIDIwMTcgMTA6MTU8YnI+DQo8Yj5Ubzo8L2I+IFJvbmkgRXZlbiAmbHQ7cm9u aS5ldmVuQGh1YXdlaS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBRVUlDIFdHICZsdDtxdWljQGll dGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogZHJhZnQtdGllc2VsLXF1aWMtdW5y ZWxpYWJsZS1zdHJlYW1zLTAxIC0gY29tbWVudHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gNS4gTm92IDIwMTcsIGF0IDA4OjMyLCBSb25pIEV2ZW4gJmx0OzxhIGhyZWY9 Im1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbSI+cm9uaS5ldmVuQGh1YXdlaS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWNhcHM6 IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 d29yZC1zcGFjaW5nOjBweCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYi PkZyb206IFBoaWxpcHAgUy4gVGllc2VsIFs8YSBocmVmPSJtYWlsdG86cGhpbHNAaW4tcGFuaWsu ZGUiPm1haWx0bzpwaGlsc0Bpbi1wYW5pay5kZTwvYT5dPGJyPg0KPGJyPg0KPG86cD48L286cD48 L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVu bG8tUmVndWxhciZxdW90OyxzZXJpZiI+T24gMS4gTm92IDIwMTcsIGF0IDE0OjAzLCBSb25pIEV2 ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbSI+cm9uaS5ldmVuQGh1 YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv dGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+SW4gdGhlIHNlY3Vy aXR5IHNlY3Rpb24g4oCcIEFuIGFjdGl2ZSwgb24gcGF0aCBhdHRhY2tlciBjYW4gZHJvcCBzZWxl Y3RlZDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9ja3F1b3RlIHN0 eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1z aXplOjguNXB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPmZy YW1lcyDigJwgLiBXaGF0IGRvZXMgaXQgbWVhbiBzZWxlY3RlZCBmcmFtZXMsIHRoZSB3aG9sZSBw YXlsb2FkIGlzPGJyPg0KZW5jcnlwdGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+VGhpcyBpcyBhIGxp dHRsZSBjb21wbGljYXRlZDo8YnI+DQotIEFzc3VtZSBoYXZpbmcg4oCcc3RyZWFtLWFzLWEtbWVz c2FnZeKAnSBzdHJlYW1zIHdpdGggdHdvIGRpZmZlcmVudCBraW5zIG9mPGJyPg0KbWVzc2FnZXMg c2l6ZWQgQSxCPGJyPg0KLSBBc3N1bWUgZWFjaCBtZXNzYWdlIGZpdHMgaW50byBvbmUgcGFja2V0 LCBidXQgdHdvIG1lc3NhZ2VzIHdpbGwgbm90IGZpdDxicj4NCi0gQXNzdW1lIG9uZSBkb2Vzbid0 IHdhbnQgdG8gc3BsaXQgcGFja2V0cyB0byBmaWxsIHBhY2tldHMgdG8gTVRVIGR1ZSB0bzxicj4N CmxhdGVuY3kgY29uc3RyYWlucyAmbmJzcDs9Jmd0OyBJZiBhbiBhdHRhY2tlciBrbm93IHRoZSBp bnNpZGUgcHJvdG9jb2wsIHRoZSBhdHRhY2tlcjxicj4NCmNhbiBkaXN0aW5ndWlzaCBmcm9tIHRo ZSBwYWNrZXQgbGVuZ3RoIHdldGhlciBpdCBpcyBhbiBBIG9yIEIga2luZCBtZXNzYWdlPGJyPg0K PGJyPg0KVG8gYXZvaWQgdGhpcywgb25lIGhhcyB0byBwYWQgYWxsIHBhY2tldHPigKYgSSBzaG91 bGQgY2xhcmlmeSB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+W1JvbmkgRXZlbl0gSSB1bmRlcnN0 YW5kIHRoaXMgY2FzZSBidXQgd2hhdCBkb2VzIHNlbGVjdGVkIGZyYW1lcyBtZWFuLCBJIGFzc3Vt ZSB0aGF0IHRoZSBhdHRhY2tlciBkb2VzIG5vdCBrbm93IHdoYXQgaXMgaW4gZWFjaCBzdHJlYW0g aW4gb3JkZXIgdG8gc2VsZWN0IGEgc3BlY2lmaWMgb25lLCBzbw0KIHdoeSB3aWxsIGhlIGp1c3Qg ZHJvcCBvbmUgYW5kIG5vdCB0aGUgb3RoZXIgb3Igd2h5IG5vdCBib3RoPzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Bc3N1bWluZyB0aGUgYXR0YWNrZXIgX2tub3dzIHRoZSBwcm90b2NvbF8s IHRoZSBhdHRhY2tlciB3b3VsZCBhbHNvIGtub3cgdGhlIHNpemVzIG9mIGFsbCBraW5kcyBvZiBt ZXNzYWdlcyBhbmQgbWF5IHVzZSB0aGlzIGtub3dsZWRnZSB0byByZWNvdmVyIHByb3RvY29sIHN0 YXRlIG9yIHNlbGVjdGl2ZWx5IGRyb3AgbWVzc2FnZXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBhIHByb3RvY29sIGxpa2UgSFRUUCwg dGhlIGF0dGFjayB2ZWN0b3IgaXMgcmF0aGVyIHNtYWxsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgb25lIHVzZXMgdGhpcyBhZ2FpbnN0IHZp ZGVvIGNvbmZlcmVuY2luZyBhcHBsaWNhdGlvbnMsIGFuIGF0dGFja2VyIGNvdWxkIHByZXZlbnQg cmF0ZSBhZGFwdGlvbiAmbmJzcDtieSBkcm9wcGluZyByZWNlcHRpb24gcmVwb3J0cyAobGFyZ2Vy IHRoYW4gYSBwdXJlIFFVSUMgQUNLLCBzbWFsbGVyIHRoYW4gYSB2aWRlbyBmcmFtZSkuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBvbmUgdXNl cyB0aGlzIG9uIElvVCBjb250cm9sIHN0dWZmLCBhbiBhdHRhY2tlciBtaWdodCBiZSBhYmxlIHRv IGxlYXJuIGEgbG90IGFib3V0IHRoZSBzeXN0ZW0gc3RhdGUgYnkgb2JzZXJ2aW5nIHNpemVzIGFu ZCB0aW1pbmdzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGlzIGlzIG5vdGhpbmcgd2UgY2FuIGZpeCB3aXRoaW4gUVVJQyB3aXRob3V0IG1h c3NpdmUgc2NhcmlmaWVzLCBidXQgYXBwbGljYXRpb24gZGV2ZWxvcGVycyBtdXN0IGtlZXAgaW4g bWluZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QVZFITxicj4NCiZu YnNwOyBQaGlsaXBwIFMuIFRpZXNlbCAvIHBoaWxz4oCmPGJyPg0KLS0mbmJzcDs8YnI+DQombmJz cDsgJm5ic3A7e3BoaWxzfS0tLSZndDstLS0oPGEgaHJlZj0ibWFpbHRvOnBoaWxzQGluLXBhbmlr LmRlIj5waGlsc0Bpbi1wYW5pay5kZTwvYT4pLS0tJmd0Oy0tLSg8YSBocmVmPSJodHRwOi8vcGhp bHMuaW4tcGFuaWsuZGUiPmh0dHA6Ly9waGlscy5pbi1wYW5pay5kZTwvYT4pLS0tLSw8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyB3ZW5uIHcgZWluZSAmbmJzcDsgYXViZSBpc3QgZG4gJm5ic3A7 ICZuYnNwOyAmbmJzcDttYW4gYXUgZHJhbiBkcmUgZW4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7byAmbmJzcDsgJm5ic3A7IFNjaHIgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW4gbXVzcyAmbmJzcDsgJm5ic3A7IGhjICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBoICZuYnNwOyAoS3VydCBTY2h3aXR0ZXJzKSB8PGJyPg0KOndxISAm bmJzcDsmbHQ7LS0tLShwaG9uZTogJiM0Mzs0OS0xNzktNjczNzQzOSktLS0mbHQ7LS0tKGphYmJl cjogPGEgaHJlZj0ibWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlIj4NCnBoaWxzQGluLXBhbmlrLmRl PC9hPiktLS0tJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB4PR07MB34899FCFC336AE2F0B72A6CC2510DB4PR07MB348eurprd_-- From nobody Tue Nov 7 01:08: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 ADF7813FD4A for ; Tue, 7 Nov 2017 01:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 A72XIZlLq44B for ; Tue, 7 Nov 2017 01:08:32 -0800 (PST) Received: from mail-out1.informatik.tu-muenchen.de (mail-out1.informatik.tu-muenchen.de [131.159.0.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 43FE713FCBC for ; Tue, 7 Nov 2017 01:06:33 -0800 (PST) Received: by mail.in.tum.de (Postfix, from userid 107) id 6B9B01C2A4B; Tue, 7 Nov 2017 10:06:30 +0100 (CET) Received: (Authenticated sender: ott) by mail.in.tum.de (Postfix) with ESMTPSA id 40BA11C2A49; Tue, 7 Nov 2017 10:06:28 +0100 (CET) (Extended-Queue-bit tech_mwhgq@fff.in.tum.de) Subject: Re: QUIC - Our schedule and scope To: Colin Perkins , Bernard Aboba Cc: "Brian Trammell (IETF)" , Mark Nottingham , QUIC WG , Lars Eggert , Spencer Dawkins at IETF References: From: Joerg Ott Message-ID: <5979f4c0-4b0f-2218-8507-74efa4888027@in.tum.de> Date: Tue, 7 Nov 2017 10:06:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:08:35 -0000 I agree with Colin. We had this discussion about the multiplexing very briefly in Paris (if my memory works properly) and this need was too quickly discounted. We don't want to maneuver outselves into a corner when applications like WebRTC are on the horizon. Like Colin said, the mechanism is secondary but we need to act here for v1. Jörg On 01.11.17 10:50, Colin Perkins wrote: > >> On 1 Nov 2017, at 07:16, Bernard Aboba > > wrote: >> >> Colin Perkins said: >> >> "I do think that peer-to-peer uses of QUIC need attention pre-V1, if >> they’re to be supported cleanly. At minimum, we need to arrange the >> QUIC headers to easily demultiplex with STUN on the same UDP port, >> otherwise we’ll end-up re-inventing STUN within QUIC. Focussing solely >> on HTTP is going to make this difficult. >> >> See draft-aboba-avtcore-quic-multiplexing-00 for more discussion." >> >> [BA]  Peer-to-peer uses of QUIC are under development, and are quite >> likely to be deployed in advance of a v2 specification. >> >>  As the multiplexing draft makes clear, there is an alternative (a >> single octet shim) that enables de-multiplexing of QUIC without >> modification (or even consideration) of QUIC headers.  So while native >> demultiplexing QUIC headers from STUN might be preferred, this >> probably can’t be characterized as a "must have". > > There are several options for the packet format, and a shim is only one. > > Whether we define a shim, or change the QUIC header format to allow > demuxing, we should do it early enough so middleboxes are aware. > Otherwise, we’ll see ossification around a format that prevents > peer-to-peer use. > >> Given that some of the most popular peer-to-peer uses involve >> unreliable data exchange (e.g. in games), support for that is a basic >> requirement.  A "quick and dirty" approach would be to utilize a QUIC >> stream for each message, while setting a timer so as to approximate a >> data channel's maxPacketLifetime parameter.  A more thorough solution >> would be to support unreliable QUIC streams natively, allowing >> maxPacketLifetime or maxRetransmits to be enforced on a per-packet >> basis, mimicing the behavior of an unreliable RTCDataChannel running >> over SCTP/DTLS/UDP. >> >> The problem with the "quick and dirty" approach is that many >> peer-to-peer data exchange developers are obsessed with latency and >> therefore may prefer no retransmissions at all.  This could lead to >> widespread deployment of draft-tiesel-quic-unreliable-streams prior to >> standardization. >> >> >> >> On Sun, Oct 29, 2017 at 11:08 AM, Colin Perkins > > wrote: >> >> >> > On 28 Oct 2017, at 09:04, Brian Trammell (IETF) > wrote: >> > >> > hi Mark, all, >> > >> > Broadly, I support Patrick's intepretation here. I'll point out that there seems to be some inconsistency between two points below: >> > >> >> On 27 Oct 2017, at 08:26, Mark Nottingham > wrote: >> >> >> >> 2) V1 of QUIC should *only* address the use case of HTTP. >> > >> > and >> > >> >> * V1 will need to document the "invariants" of QUIC -- i.e., the parts on the wire that will not change -- to allow other use cases to be addressed by V2 and beyond. >> > >> > That QUIC's handshake, pre-version-negotiation wire image, and ossification-prevention features will be "baked in" in V1 is clear, and I thought it already had been, though thanks for calling it out here. >> > >> > Focusing on *only* addressing HTTP in this wire image, though, seems like it might be dangerous in ways I can't fully articulate yet... HTTP is an explicitly asymmetric protocol, with different roles for client and server well beyond the initial handshake, and as it is presently most commonly deployed, wildly different architectures for client-side and server-side implementations. Many of the things that we suspect we'll want to bring on top of QUIC in the future are less so; even Web protocols like WebSockets fit here. Will this focus lead to invariants that will make less asymmetric applications harder to build and deploy? Should we be concerned about that at this point? >> >> >> I do think that peer-to-peer uses of QUIC need attention pre-V1, >> if they’re to be supported cleanly. At minimum, we need to arrange >> the QUIC headers to easily demultiplex with STUN on the same UDP >> port, otherwise we’ll end-up re-inventing STUN within QUIC. >> Focussing solely on HTTP is going to make this difficult. >> >> See draft-aboba-avtcore-quic-multiplexing-00 for more discussion. >> >> -- >> Colin Perkins >> https://csperkins.org/ >> >> >> >> >> > > > > -- > Colin Perkins > https://csperkins.org/ > > > > From nobody Tue Nov 7 03:50: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 7D8D513FE32 for ; Tue, 7 Nov 2017 03:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 DJx3ieyIHRsE for ; Tue, 7 Nov 2017 03:50:47 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCB6E13FE31 for ; Tue, 7 Nov 2017 03:50:45 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZI67776; Tue, 07 Nov 2017 11:50:42 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 7 Nov 2017 11:50:20 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Tue, 7 Nov 2017 19:50:13 +0800 From: Roni Even To: Ingemar Johansson S , "Philipp S. Tiesel" CC: QUIC WG Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Topic: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Index: AQHTVBwwoDixcEmLIk67t+44J7ng4KMIg0wwgABPrWA= Date: Tue, 7 Nov 2017 11:50:12 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8351F8@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD832288@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.65] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8351F8DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.5A019E13.0072, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.14, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9de01acb088ed5dccf12085c36a29c56 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 11:50:49 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8351F8DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSW5nZW1hciwNCkl0IGlzIG5vdCBDQ00gdGhlIGF0dGFja2VyIGp1c3QgZG9lcyBoZXVyaXN0 aWNzIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIG5vdCBtZWRpYSBidXQgcmVwb3J0IChSVENQ IG9yIEFDSyBmcmFtZXMpIGFuZCBkcm9wcyBpdCwgQlRXOiBhdWRpbyBwYWNrZXRzIG1heSBhbHNv IGJlIHNtYWxsLg0KVGhpcyBpcyBhbiBleGFtcGxlLiBUaGUgY2xhaW0gaXMgdGhhdCB5b3UgY2Fu IHVzZSBoZXVyaXN0aWNzIHRvIGRyb3Ag4oCcc2VsZWN0ZWTigJ0gZnJhbWVzIGV2ZW4gdGhvdWdo IHlvdSBkbyBub3Qga25vdyB3aGF0IGlzIGluIHRoZSBwYWNrZXQuDQpSb25pDQoNCg0KDQpGcm9t OiBJbmdlbWFyIEpvaGFuc3NvbiBTIFttYWlsdG86aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nv bi5jb21dDQpTZW50OiDXmdeV150g15IgMDcg16DXldeR157XkdeoIDIwMTcgMDk6NDENClRvOiBQ aGlsaXBwIFMuIFRpZXNlbDsgUm9uaSBFdmVuDQpDYzogUVVJQyBXRw0KU3ViamVjdDogUkU6IGRy YWZ0LXRpZXNlbC1xdWljLXVucmVsaWFibGUtc3RyZWFtcy0wMSAtIGNvbW1lbnRzDQoNCkhpIFBo aWxpcCBhbmQgUm9uaQ0KDQpJIGFzc3VtZSB0aGF0IGJ5IHJlY2VwdGlvbiByZXBvcnRzIGlzIG1l YW50IHRoZSBSVENQIENDTSBtZXNzYWdlcyBzdWNoIGFzIFRNTUJSIG9yID8NCg0KU28uLiB1bmxl c3MgSSBtaXN1bmRlcnN0b29kIGl0IGNvbXBsZXRlbHkuDQpJIGFtIG5vdCBhdCBhbGwgY29udmlu Y2VkIHRoYXQgbWVkaWEgcmF0ZS9jb25nZXN0aW9uIGNvbnRyb2wgaW4gUVVJQyBzaG91bGQgcmVs eSBvbiBUTU1CUi4NClNDUmVBTSBmb3IgaW5zdGFuY2UsIHNwZWNpZmllZCBpbiB0aGUgUk1DQVQg V0cgZm9yIGluc3RhbmNlIGRvZXMgbm90IGRlcGVuZCBvbiBUTU1CUiBhcyBpdCBpcyBBQ0sgY2xv Y2tlZCwgdGhlIG1lZGlhIHRyYW5zbWlzc2lvbiBpcyByZWR1Y2VkIHRvIGEgdmVyeSBsb3cgcmF0 ZSBpZiB0aGUgQUNLcyBhcmUgZGlzY2FyZGVkIGJ5IGFuIGF0dGFja2VyLg0KDQpJIHdvdWxkIHNh eSB0aGF0IGl0IGlzIG1vcmUgc3RyYWlnaHRmb3J3YXJkIHRvIHVzZSBhIG11bHRpcHVycG9zZSBj b25nZXN0aW9uIGNvbnRyb2wgaW4gUVVJQywgdGhpcyBpcyBwZXJoYXBzIGJhc2VkIG9uIEJCUiwg YnV0IFNDUmVBTSBzdHlsZSBpcyBub3QgZXhjbHVkZWQuIEluIGFueSBjYXNlIHRoaXMgbWVhbnMg dGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gcHJldmVudCByYXRlIGFkYXB0YXRpb24uDQoNCi9J bmdlbWFyDQoNCg0KRnJvbTogUGhpbGlwcCBTLiBUaWVzZWwgW21haWx0bzpwaGlsc0Bpbi1wYW5p ay5kZV0NClNlbnQ6IGRlbiA2IG5vdmVtYmVyIDIwMTcgMTA6MTUNClRvOiBSb25pIEV2ZW4gPHJv bmkuZXZlbkBodWF3ZWkuY29tPG1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbT4+DQpDYzogUVVJ QyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZTog ZHJhZnQtdGllc2VsLXF1aWMtdW5yZWxpYWJsZS1zdHJlYW1zLTAxIC0gY29tbWVudHMNCg0KDQoN Ck9uIDUuIE5vdiAyMDE3LCBhdCAwODozMiwgUm9uaSBFdmVuIDxyb25pLmV2ZW5AaHVhd2VpLmNv bTxtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20+PiB3cm90ZToNCkZyb206IFBoaWxpcHAgUy4g VGllc2VsIFttYWlsdG86cGhpbHNAaW4tcGFuaWsuZGVdDQpPbiAxLiBOb3YgMjAxNywgYXQgMTQ6 MDMsIFJvbmkgRXZlbiA8cm9uaS5ldmVuQGh1YXdlaS5jb208bWFpbHRvOnJvbmkuZXZlbkBodWF3 ZWkuY29tPj4gd3JvdGU6DQpJbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiDigJwgQW4gYWN0aXZlLCBv biBwYXRoIGF0dGFja2VyIGNhbiBkcm9wIHNlbGVjdGVkDQpmcmFtZXMg4oCcIC4gV2hhdCBkb2Vz IGl0IG1lYW4gc2VsZWN0ZWQgZnJhbWVzLCB0aGUgd2hvbGUgcGF5bG9hZCBpcw0KZW5jcnlwdGVk Lg0KVGhpcyBpcyBhIGxpdHRsZSBjb21wbGljYXRlZDoNCi0gQXNzdW1lIGhhdmluZyDigJxzdHJl YW0tYXMtYS1tZXNzYWdl4oCdIHN0cmVhbXMgd2l0aCB0d28gZGlmZmVyZW50IGtpbnMgb2YNCm1l c3NhZ2VzIHNpemVkIEEsQg0KLSBBc3N1bWUgZWFjaCBtZXNzYWdlIGZpdHMgaW50byBvbmUgcGFj a2V0LCBidXQgdHdvIG1lc3NhZ2VzIHdpbGwgbm90IGZpdA0KLSBBc3N1bWUgb25lIGRvZXNuJ3Qg d2FudCB0byBzcGxpdCBwYWNrZXRzIHRvIGZpbGwgcGFja2V0cyB0byBNVFUgZHVlIHRvDQpsYXRl bmN5IGNvbnN0cmFpbnMgID0+IElmIGFuIGF0dGFja2VyIGtub3cgdGhlIGluc2lkZSBwcm90b2Nv bCwgdGhlIGF0dGFja2VyDQpjYW4gZGlzdGluZ3Vpc2ggZnJvbSB0aGUgcGFja2V0IGxlbmd0aCB3 ZXRoZXIgaXQgaXMgYW4gQSBvciBCIGtpbmQgbWVzc2FnZQ0KDQpUbyBhdm9pZCB0aGlzLCBvbmUg aGFzIHRvIHBhZCBhbGwgcGFja2V0c+KApiBJIHNob3VsZCBjbGFyaWZ5IHRoaXMuDQpbUm9uaSBF dmVuXSBJIHVuZGVyc3RhbmQgdGhpcyBjYXNlIGJ1dCB3aGF0IGRvZXMgc2VsZWN0ZWQgZnJhbWVz IG1lYW4sIEkgYXNzdW1lIHRoYXQgdGhlIGF0dGFja2VyIGRvZXMgbm90IGtub3cgd2hhdCBpcyBp biBlYWNoIHN0cmVhbSBpbiBvcmRlciB0byBzZWxlY3QgYSBzcGVjaWZpYyBvbmUsIHNvIHdoeSB3 aWxsIGhlIGp1c3QgZHJvcCBvbmUgYW5kIG5vdCB0aGUgb3RoZXIgb3Igd2h5IG5vdCBib3RoPw0K DQpBc3N1bWluZyB0aGUgYXR0YWNrZXIgX2tub3dzIHRoZSBwcm90b2NvbF8sIHRoZSBhdHRhY2tl ciB3b3VsZCBhbHNvIGtub3cgdGhlIHNpemVzIG9mIGFsbCBraW5kcyBvZiBtZXNzYWdlcyBhbmQg bWF5IHVzZSB0aGlzIGtub3dsZWRnZSB0byByZWNvdmVyIHByb3RvY29sIHN0YXRlIG9yIHNlbGVj dGl2ZWx5IGRyb3AgbWVzc2FnZXMuDQoNCkZvciBhIHByb3RvY29sIGxpa2UgSFRUUCwgdGhlIGF0 dGFjayB2ZWN0b3IgaXMgcmF0aGVyIHNtYWxsLg0KSWYgb25lIHVzZXMgdGhpcyBhZ2FpbnN0IHZp ZGVvIGNvbmZlcmVuY2luZyBhcHBsaWNhdGlvbnMsIGFuIGF0dGFja2VyIGNvdWxkIHByZXZlbnQg cmF0ZSBhZGFwdGlvbiAgYnkgZHJvcHBpbmcgcmVjZXB0aW9uIHJlcG9ydHMgKGxhcmdlciB0aGFu IGEgcHVyZSBRVUlDIEFDSywgc21hbGxlciB0aGFuIGEgdmlkZW8gZnJhbWUpLg0KSWYgb25lIHVz ZXMgdGhpcyBvbiBJb1QgY29udHJvbCBzdHVmZiwgYW4gYXR0YWNrZXIgbWlnaHQgYmUgYWJsZSB0 byBsZWFybiBhIGxvdCBhYm91dCB0aGUgc3lzdGVtIHN0YXRlIGJ5IG9ic2VydmluZyBzaXplcyBh bmQgdGltaW5ncy4NCg0KVGhpcyBpcyBub3RoaW5nIHdlIGNhbiBmaXggd2l0aGluIFFVSUMgd2l0 aG91dCBtYXNzaXZlIHNjYXJpZmllcywgYnV0IGFwcGxpY2F0aW9uIGRldmVsb3BlcnMgbXVzdCBr ZWVwIGluIG1pbmQuDQoNCg0KQVZFIQ0KICBQaGlsaXBwIFMuIFRpZXNlbCAvIHBoaWxz4oCmDQot LQ0KICAge3BoaWxzfS0tLT4tLS0ocGhpbHNAaW4tcGFuaWsuZGU8bWFpbHRvOnBoaWxzQGluLXBh bmlrLmRlPiktLS0+LS0tKGh0dHA6Ly9waGlscy5pbi1wYW5pay5kZSktLS0tLA0KICAgICAgd2Vu biB3IGVpbmUgICBhdWJlIGlzdCBkbiAgICAgIG1hbiBhdSBkcmFuIGRyZSBlbiAgICAgICAgICAg ICAgICAgICB8DQogICAgICAgICAgIG8gICAgIFNjaHIgICAgICAgIGFuIG11c3MgICAgIGhjICAg ICAgICAgaCAgIChLdXJ0IFNjaHdpdHRlcnMpIHwNCjp3cSEgIDwtLS0tKHBob25lOiArNDktMTc5 LTY3Mzc0MzkpLS0tPC0tLShqYWJiZXI6IHBoaWxzQGluLXBhbmlrLmRlPG1haWx0bzpwaGlsc0Bp bi1wYW5pay5kZT4pLS0tLScNCg0K --_000_6E58094ECC8D8344914996DAD28F1CCD8351F8DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXI7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRh dGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1z aXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5F bWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uQmFsbG9vblRl eHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFt aWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPkhpIEluZ2VtYXIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IGlzIG5vdCBDQ00g dGhlIGF0dGFja2VyIGp1c3QgZG9lcyBoZXVyaXN0aWNzIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGlz IGlzIG5vdCBtZWRpYSBidXQgcmVwb3J0IChSVENQIG9yIEFDSyBmcmFtZXMpIGFuZCBkcm9wcyBp dCwgQlRXOiBhdWRpbyBwYWNrZXRzIG1heSBhbHNvIGJlIHNtYWxsLg0KPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PlRoaXMgaXMgYW4gZXhhbXBsZS4gVGhlIGNsYWltIGlzIHRoYXQgeW91IGNhbiB1c2UgaGV1cmlz dGljcyB0byBkcm9wIOKAnHNlbGVjdGVk4oCdIGZyYW1lcyBldmVuIHRob3VnaCB5b3UgZG8gbm90 IGtub3cgd2hhdCBpcyBpbiB0aGUgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Sb25pPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVw dDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNt IDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSW5nZW1hciBK b2hhbnNzb24gUyBbbWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IDxzcGFuIGxhbmc9IkhFIiBkaXI9IlJUTCI+15nXldedJm5ic3A715Ig MDcg16DXldeR157XkdeoIDIwMTcgMDk6NDE8L3NwYW4+PGJyPg0KPGI+VG86PC9iPiBQaGlsaXBw IFMuIFRpZXNlbDsgUm9uaSBFdmVuPGJyPg0KPGI+Q2M6PC9iPiBRVUlDIFdHPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBkcmFmdC10aWVzZWwtcXVpYy11bnJlbGlhYmxlLXN0cmVhbXMtMDEgLSBj b21tZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp IFBoaWxpcCBhbmQgUm9uaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFzc3VtZSB0aGF0IGJ5 IDx1PnJlY2VwdGlvbjwvdT4gcmVwb3J0cyBpcyBtZWFudCB0aGUgUlRDUCBDQ00gbWVzc2FnZXMg c3VjaCBhcyBUTU1CUiBvciA/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvLi4gdW5sZXNzIEkg bWlzdW5kZXJzdG9vZCBpdCBjb21wbGV0ZWx5LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBhbSBub3QgYXQgYWxsIGNvbnZpbmNlZCB0aGF0IG1lZGlhIHJhdGUvY29uZ2Vz dGlvbiBjb250cm9sIGluIFFVSUMgc2hvdWxkIHJlbHkgb24gVE1NQlIuDQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNDUmVBTSBmb3IgaW5zdGFuY2UsIHNwZWNpZmllZCBp biB0aGUgUk1DQVQgV0cgZm9yIGluc3RhbmNlIGRvZXMgbm90IGRlcGVuZCBvbiBUTU1CUiBhcyBp dCBpcyBBQ0sgY2xvY2tlZCwgdGhlIG1lZGlhIHRyYW5zbWlzc2lvbiBpcyByZWR1Y2VkIHRvIGEg dmVyeSBsb3cgcmF0ZSBpZiB0aGUgQUNLcyBhcmUgZGlzY2FyZGVkIGJ5IGFuIGF0dGFja2VyLg0K PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgc2F5IHRoYXQgaXQgaXMgbW9yZSBzdHJh aWdodGZvcndhcmQgdG8gdXNlIGEgbXVsdGlwdXJwb3NlIGNvbmdlc3Rpb24gY29udHJvbCBpbiBR VUlDLCB0aGlzIGlzIHBlcmhhcHMgYmFzZWQgb24gQkJSLCBidXQgU0NSZUFNIHN0eWxlIGlzIG5v dCBleGNsdWRlZC4gSW4gYW55IGNhc2UgdGhpcyBtZWFucyB0aGF0IGl0IGlzIG5vdCBwb3NzaWJs ZSB0byBwcmV2ZW50IHJhdGUgYWRhcHRhdGlvbi4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4v SW5nZW1hcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGlu ZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFBoaWxpcHAgUy4gVGllc2VsIFs8YSBo cmVmPSJtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGUiPm1haWx0bzpwaGlsc0Bpbi1wYW5pay5kZTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDYgbm92ZW1iZXIgMjAxNyAxMDoxNTxicj4NCjxi PlRvOjwvYj4gUm9uaSBFdmVuICZsdDs8YSBocmVmPSJtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5j b20iPnJvbmkuZXZlbkBodWF3ZWkuY29tPC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+IFFVSUMgV0cg Jmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPiZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGRyYWZ0LXRpZXNlbC1xdWljLXVucmVsaWFibGUtc3Ry ZWFtcy0wMSAtIGNvbW1lbnRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNS4gTm92IDIwMTcsIGF0IDA4OjMyLCBSb25pIEV2ZW4g Jmx0OzxhIGhyZWY9Im1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbSI+cm9uaS5ldmVuQGh1YXdl aS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQ7Zm9udC12 YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dz OiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzstd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9u dC1mYW1pbHk6TWVubG8tUmVndWxhciI+RnJvbTogUGhpbGlwcCBTLiBUaWVzZWwgWzxhIGhyZWY9 Im1haWx0bzpwaGlsc0Bpbi1wYW5pay5kZSI+bWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlPC9hPl08 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eTpNZW5sby1SZWd1bGFyIj5PbiAxLiBOb3YgMjAxNywgYXQgMTQ6MDMsIFJvbmkgRXZlbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tIj5yb25pLmV2ZW5AaHVhd2VpLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZh bWlseTpNZW5sby1SZWd1bGFyIj5JbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiDigJwgQW4gYWN0aXZl LCBvbiBwYXRoIGF0dGFja2VyIGNhbiBkcm9wIHNlbGVjdGVkPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJv dHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6TWVu bG8tUmVndWxhciI+ZnJhbWVzIOKAnCAuIFdoYXQgZG9lcyBpdCBtZWFuIHNlbGVjdGVkIGZyYW1l cywgdGhlIHdob2xlIHBheWxvYWQgaXM8YnI+DQplbmNyeXB0ZWQuPG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyIj5UaGlzIGlzIGEgbGl0dGxl IGNvbXBsaWNhdGVkOjxicj4NCi0gQXNzdW1lIGhhdmluZyDigJxzdHJlYW0tYXMtYS1tZXNzYWdl 4oCdIHN0cmVhbXMgd2l0aCB0d28gZGlmZmVyZW50IGtpbnMgb2Y8YnI+DQptZXNzYWdlcyBzaXpl ZCBBLEI8YnI+DQotIEFzc3VtZSBlYWNoIG1lc3NhZ2UgZml0cyBpbnRvIG9uZSBwYWNrZXQsIGJ1 dCB0d28gbWVzc2FnZXMgd2lsbCBub3QgZml0PGJyPg0KLSBBc3N1bWUgb25lIGRvZXNuJ3Qgd2Fu dCB0byBzcGxpdCBwYWNrZXRzIHRvIGZpbGwgcGFja2V0cyB0byBNVFUgZHVlIHRvPGJyPg0KbGF0 ZW5jeSBjb25zdHJhaW5zICZuYnNwOz0mZ3Q7IElmIGFuIGF0dGFja2VyIGtub3cgdGhlIGluc2lk ZSBwcm90b2NvbCwgdGhlIGF0dGFja2VyPGJyPg0KY2FuIGRpc3Rpbmd1aXNoIGZyb20gdGhlIHBh Y2tldCBsZW5ndGggd2V0aGVyIGl0IGlzIGFuIEEgb3IgQiBraW5kIG1lc3NhZ2U8YnI+DQo8YnI+ DQpUbyBhdm9pZCB0aGlzLCBvbmUgaGFzIHRvIHBhZCBhbGwgcGFja2V0c+KApiBJIHNob3VsZCBj bGFyaWZ5IHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTpN ZW5sby1SZWd1bGFyIj5bUm9uaSBFdmVuXSBJIHVuZGVyc3RhbmQgdGhpcyBjYXNlIGJ1dCB3aGF0 IGRvZXMgc2VsZWN0ZWQgZnJhbWVzIG1lYW4sIEkgYXNzdW1lIHRoYXQgdGhlIGF0dGFja2VyIGRv ZXMgbm90IGtub3cgd2hhdCBpcyBpbiBlYWNoIHN0cmVhbSBpbiBvcmRlciB0byBzZWxlY3QgYSBz cGVjaWZpYyBvbmUsIHNvIHdoeSB3aWxsDQogaGUganVzdCBkcm9wIG9uZSBhbmQgbm90IHRoZSBv dGhlciBvciB3aHkgbm90IGJvdGg/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzc3VtaW5n IHRoZSBhdHRhY2tlciBfa25vd3MgdGhlIHByb3RvY29sXywgdGhlIGF0dGFja2VyIHdvdWxkIGFs c28ga25vdyB0aGUgc2l6ZXMgb2YgYWxsIGtpbmRzIG9mIG1lc3NhZ2VzIGFuZCBtYXkgdXNlIHRo aXMga25vd2xlZGdlIHRvIHJlY292ZXIgcHJvdG9jb2wgc3RhdGUgb3Igc2VsZWN0aXZlbHkgZHJv cCBtZXNzYWdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Rm9yIGEgcHJvdG9jb2wgbGlrZSBIVFRQLCB0aGUgYXR0YWNrIHZlY3RvciBpcyBy YXRoZXIgc21hbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JZiBvbmUgdXNlcyB0aGlzIGFnYWluc3QgdmlkZW8gY29uZmVyZW5jaW5nIGFwcGxp Y2F0aW9ucywgYW4gYXR0YWNrZXIgY291bGQgcHJldmVudCByYXRlIGFkYXB0aW9uICZuYnNwO2J5 IGRyb3BwaW5nIHJlY2VwdGlvbiByZXBvcnRzIChsYXJnZXIgdGhhbiBhIHB1cmUgUVVJQyBBQ0ss IHNtYWxsZXIgdGhhbiBhIHZpZGVvIGZyYW1lKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIG9uZSB1c2VzIHRoaXMgb24gSW9UIGNvbnRyb2wg c3R1ZmYsIGFuIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gbGVhcm4gYSBsb3QgYWJvdXQgdGhl IHN5c3RlbSBzdGF0ZSBieSBvYnNlcnZpbmcgc2l6ZXMgYW5kIHRpbWluZ3MuPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgbm90aGlu ZyB3ZSBjYW4gZml4IHdpdGhpbiBRVUlDIHdpdGhvdXQgbWFzc2l2ZSBzY2FyaWZpZXMsIGJ1dCBh cHBsaWNhdGlvbiBkZXZlbG9wZXJzIG11c3Qga2VlcCBpbiBtaW5kLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BVkUhPGJyPg0KJm5ic3A7IFBoaWxpcHAgUy4gVGllc2Vs IC8gcGhpbHPigKY8YnI+DQotLSZuYnNwOzxicj4NCiZuYnNwOyAmbmJzcDt7cGhpbHN9LS0tJmd0 Oy0tLSg8YSBocmVmPSJtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGUiPnBoaWxzQGluLXBhbmlrLmRl PC9hPiktLS0mZ3Q7LS0tKDxhIGhyZWY9Imh0dHA6Ly9waGlscy5pbi1wYW5pay5kZSI+aHR0cDov L3BoaWxzLmluLXBhbmlrLmRlPC9hPiktLS0tLDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IHdl bm4gdyBlaW5lICZuYnNwOyBhdWJlIGlzdCBkbiAmbmJzcDsgJm5ic3A7ICZuYnNwO21hbiBhdSBk cmFuIGRyZSBlbiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDtvICZuYnNwOyAmbmJzcDsgU2NociAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDth biBtdXNzICZuYnNwOyAmbmJzcDsgaGMgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGggJm5i c3A7IChLdXJ0IFNjaHdpdHRlcnMpIHw8YnI+DQo6d3EhICZuYnNwOyZsdDstLS0tKHBob25lOiAm IzQzOzQ5LTE3OS02NzM3NDM5KS0tLSZsdDstLS0oamFiYmVyOiA8YSBocmVmPSJtYWlsdG86cGhp bHNAaW4tcGFuaWsuZGUiPg0KcGhpbHNAaW4tcGFuaWsuZGU8L2E+KS0tLS0nPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD8351F8DGGEMM506MBXchina_-- From nobody Tue Nov 7 06: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 367CC13FC24 for ; Tue, 7 Nov 2017 06:48:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 IXGk7y0APYJA for ; Tue, 7 Nov 2017 06:48:02 -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 621E313FEB4 for ; Tue, 7 Nov 2017 06:48:02 -0800 (PST) X-AuditID: c1b4fb25-1b7d19c000000c94-21-5a01c79fbc0d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 90.49.03220.F97C10A5; Tue, 7 Nov 2017 15:48:00 +0100 (CET) Received: from EUR01-HE1-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.352.0; Tue, 7 Nov 2017 15:47: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=QNSaFOp1d0AhmBreAkqBWUpOHytC9EHatzpeJEXIdes=; b=KfyZn13lKKhuRsGoww6ZAzOylJH/wj7nVh9u57RdY8x/ok4DAdMRX+6nyT2b50PfPgEMzdyUjIjp5U2ViCvso0BWUebUYj77CG5RVvUyJlaHdDuM/dGD0ImQ7AyaIEwlIkImE7t2+/LtS8GABCccabEdGeCa+AUZW2MLZLUxLxo= 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_P256) id 15.20.218.6; Tue, 7 Nov 2017 14:47:57 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::d067:33bc:7c46:c8c9]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::d067:33bc:7c46:c8c9%13]) with mapi id 15.20.0218.005; Tue, 7 Nov 2017 14:47:57 +0000 From: Ingemar Johansson S To: Roni Even , "Philipp S. Tiesel" CC: QUIC WG Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Topic: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Index: AQHTVznzaxwXVQFObkG5Q8JOBDTpHqMIg0wwgABLYwCAADCkgA== Date: Tue, 7 Nov 2017 14:47:57 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD832288@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8351F8@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8351F8@DGGEMM506-MBX.china.huawei.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 6:zKohgQG9xhcyRO1VeAGNM5vrF6BaqbRRg2/S8YmvJ2l5q8BELFPosl0Flxx4LJSWTWGecv/Bv8TzzgcR0Lqj52DmWT32UVkvQH3GsuyJOeD7Ct+qmoHudcnyM1B2r6kFVlCvseI1HzhOEq2JqwZUeVTaPScXY7CUYJtqHVl1fAEmCcAzwna017IX6ueQuDPcvaSmmGckgHiTWJi5XL26Dzbr9urcfRsmjfYCJlWH5v30tUt1ShP99Npat+tSxOU7YBM7w0E6s+2933coTkfIFq4l20Z4KKwfd9MUxMv815sK5/gC3J/VCBHxtfffqVDzF0xiBcpVJJ9OvJX6dsQFLXGYukOIYPtwWJ424MlVGC0=; 5:QhEZwgDUJhoB/jZy9DLat0KoJx7gvT4W1veeoxol2RciXdYZ14HD0v/IgbKZHfSf+4V1fVHuHg9FVT0t8VxZwgpkMwyUZx7GPg1bpk99bpLyF6Vo+HfD+DMAUdYWDmyXEmAvQTwWlEAymo2AO6e+zFtq4xj+E5bMOhZxvtfiSdY=; 24:hxT9P1MiUiNic8k952MWHgCPopXQVhvsXGbN9tK5ipFUc5uVSVzZbvbMKwOzmwwT3FdjkHG1KTsZAcT95l5OljFcSSd/x9FQcGOr0OEQSzI=; 7:/G9JKZ6TXNiX56Zzh5/dOHSCCAM7j12hOC8gyYZZ/0DiHlstU3DfsG+SDHz5OlGzJZKaUPHccz0MZvF9Rl6qjFZKRPFZFszslsNCf0ZZcV/3GtksIHRLB3BxVZ347cOIrn0gOItLJGWRiqKn5uowayV39sjLFLdZ3sKawoqEy2htgYYvednSW/mJOFTJId3rj7mycQ3c2uUfEk95QKolHq0NWLjmpgP1NVUdTsM6lzoHjj4jPd3MaT+Mh03ib9Sp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9df091ba-a6f7-477d-2afa-08d525ee88f8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:DB4PR07MB345; x-ms-traffictypediagnostic: DB4PR07MB345: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-exchange-antispam-report-test: UriScan:(37575265505322)(20558992708506)(278428928389397)(192374486261705)(50582790962513)(21748063052155)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3231021)(3002001)(10201501046)(6041248)(20161123560025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB345; x-forefront-prvs: 0484063412 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(189002)(24454002)(199003)(14454004)(74316002)(106356001)(101416001)(9326002)(5660300001)(68736007)(33656002)(55016002)(478600001)(6506006)(6246003)(50986999)(54356999)(2950100002)(230783001)(25786009)(229853002)(6306002)(54896002)(236005)(2900100001)(606006)(9686003)(53546010)(76176999)(7696004)(6436002)(105586002)(8676002)(3660700001)(19609705001)(3846002)(102836003)(6116002)(790700001)(3280700002)(53386004)(4326008)(81156014)(81166006)(86362001)(97736004)(8936002)(99286004)(189998001)(2906002)(110136005)(53936002)(316002)(93886005)(66066001)(5250100002)(7736002); 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; 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_DB4PR07MB348012BC630A37881C3852CC2510DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9df091ba-a6f7-477d-2afa-08d525ee88f8 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Nov 2017 14:47:57.1170 (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: H4sIAAAAAAAAA02Se0hTYRjG+845247W6nO6fNOMGl00UysL/MNSg2gFQmKIDCKnnlTyxplJ 2h9ZKMLMK2k6zVuWmZKpedky0XVZlqBpGWqUV0TLIi+4yqRtn4H//d73eV6eh4+PpSVNAgc2 KjaB42OV0TKhNVMU3Cp1KzcgxcHMdNorvfoR5XWzfKPX/KtexpeWp76YE8irqn5R8tT3tmdp hbV3OBcdlcjxHsdDrCPzavoE8fo2dGXU+FeUgvqakBqxLOAjkPX7vBpZsxL8HEG9JlNIBgOC wqFSxjwwOJMG9f0fFFHyKVidrWHIMIrg6XWtSI2sWCH2hhr9MjKzHfaH7LFOC9PYEW5kfxKa 2Rb7QKHmpYB4fOFj2gBD+AQsvLlt8TB4N5SuFtFmFmMF9M7kCUhYJQ2D6meWYyt8DvJ7ui3B CDvBl+XPDAmzh+HJMsrMgDFUtffShKUwM7EqILwTVvrHhYSdoL8sAxHuEkF2BSbsDs25c2t7 f6jNuIfMJQAXItDqStcEFxjPMdKkRBjMD2WuBZSYTEtOhKMgo7B57bhfAFmLSwwRtkOFQS/K QW6adcUJx4FGO8FoLC9gA91FkyZmTXsXqNd5EMsuuJUxJiLsDGkld0Tr9+VI9BBJVZwqNCbi sKc7x0eFqVRxse6xXEIjMn2lrid/9rShgW9+eoRZJNskDm5EColAmahKitEjYGmZnbh13waF RByuTErm+LgL/OVoTqVHjiwjsxf7dfQFS3CEMoG7xHHxHP9fpVgrhxR0OrC7Y3Da2SFn+K6P 68hUcNBe6WTHqR10S0xtw+L3cHwg4LX2Z0Pbg6Dor6Ohm7veRlYX+9ddpB4HLnY6a7emTo3D WPvKu25P45ZrtXeSdQvLZ3KbUupGPpwMWWnO1w0qDFfHZ4ud5OnHji7kb5MV2EzHr6TWG3lx gGtLZU9BEyVjVJHKQ/tpXqX8B59CRKlGAwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:48:10 -0000 --_000_DB4PR07MB348012BC630A37881C3852CC2510DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KT0ssIHRoZW4gSSB1bmRlcnN0YW5kLCBtYXliZS4uIFN0aWxsIGRvbuKAmXQgZ2V0IGl0 LCBzb3JyeS4gSWYgeW91IGFyZSBhYm91dCB0byBzZWxlY3RpdmVseSBkaXNjYXJkIEFDSyBwYWNr ZXRzLCB0aGVuIHRoZSBBQ0sgc3BhY2luZyB3aWxsIGJlY29tZSBsYXJnZXIgYW5kIHRoZSBBQ0sg Y2xvY2tpbmcgd2lsbCBiZSBkZWdyYWRlZC4gVGhlIGVuZCBlZmZlY3QgaXMgdGhhdCBhbHNvIHRo ZSBtZWRpYSAob3Igd2hhdGV2ZXIpIHRoYXQgY29uc3RpdHV0ZSB0aGUgbGFyZ2UgcGFja2V0cyB3 aWxsIGFsc28gZ2V0IGEgZGVncmFkZWQgcGVyZm9ybWFuY2UgPw0KDQpJIGFzc3VtZSB0aGF0IHdl IHdpbGwgc3RpbGwgYmUgcnVubmluZyBvbmUgY29uZ2VzdGlvbiBjb250cm9sIGZvciB0aGUgY29u bmVjdGlvbiA/DQoNCi9JbmdlbWFyDQoNCkZyb206IFJvbmkgRXZlbiBbbWFpbHRvOnJvbmkuZXZl bkBodWF3ZWkuY29tXQ0KU2VudDogZGVuIDcgbm92ZW1iZXIgMjAxNyAxMjo1MA0KVG86IEluZ2Vt YXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPjsgUGhpbGlw cCBTLiBUaWVzZWwgPHBoaWxzQGluLXBhbmlrLmRlPg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSRTogZHJhZnQtdGllc2VsLXF1aWMtdW5yZWxpYWJsZS1zdHJlYW1zLTAx IC0gY29tbWVudHMNCg0KSGkgSW5nZW1hciwNCkl0IGlzIG5vdCBDQ00gdGhlIGF0dGFja2VyIGp1 c3QgZG9lcyBoZXVyaXN0aWNzIHRvIHVuZGVyc3RhbmQgdGhhdCB0aGlzIGlzIG5vdCBtZWRpYSBi dXQgcmVwb3J0IChSVENQIG9yIEFDSyBmcmFtZXMpIGFuZCBkcm9wcyBpdCwgQlRXOiBhdWRpbyBw YWNrZXRzIG1heSBhbHNvIGJlIHNtYWxsLg0KVGhpcyBpcyBhbiBleGFtcGxlLiBUaGUgY2xhaW0g aXMgdGhhdCB5b3UgY2FuIHVzZSBoZXVyaXN0aWNzIHRvIGRyb3Ag4oCcc2VsZWN0ZWTigJ0gZnJh bWVzIGV2ZW4gdGhvdWdoIHlvdSBkbyBub3Qga25vdyB3aGF0IGlzIGluIHRoZSBwYWNrZXQuDQpS b25pDQoNCg0KDQpGcm9tOiBJbmdlbWFyIEpvaGFuc3NvbiBTIFttYWlsdG86aW5nZW1hci5zLmpv aGFuc3NvbkBlcmljc3Nvbi5jb21dDQpTZW50OiDXmdeV150g15IgMDcg16DXldeR157XkdeoIDIw MTcgMDk6NDENClRvOiBQaGlsaXBwIFMuIFRpZXNlbDsgUm9uaSBFdmVuDQpDYzogUVVJQyBXRw0K U3ViamVjdDogUkU6IGRyYWZ0LXRpZXNlbC1xdWljLXVucmVsaWFibGUtc3RyZWFtcy0wMSAtIGNv bW1lbnRzDQoNCkhpIFBoaWxpcCBhbmQgUm9uaQ0KDQpJIGFzc3VtZSB0aGF0IGJ5IHJlY2VwdGlv biByZXBvcnRzIGlzIG1lYW50IHRoZSBSVENQIENDTSBtZXNzYWdlcyBzdWNoIGFzIFRNTUJSIG9y ID8NCg0KU28uLiB1bmxlc3MgSSBtaXN1bmRlcnN0b29kIGl0IGNvbXBsZXRlbHkuDQpJIGFtIG5v dCBhdCBhbGwgY29udmluY2VkIHRoYXQgbWVkaWEgcmF0ZS9jb25nZXN0aW9uIGNvbnRyb2wgaW4g UVVJQyBzaG91bGQgcmVseSBvbiBUTU1CUi4NClNDUmVBTSBmb3IgaW5zdGFuY2UsIHNwZWNpZmll ZCBpbiB0aGUgUk1DQVQgV0cgZm9yIGluc3RhbmNlIGRvZXMgbm90IGRlcGVuZCBvbiBUTU1CUiBh cyBpdCBpcyBBQ0sgY2xvY2tlZCwgdGhlIG1lZGlhIHRyYW5zbWlzc2lvbiBpcyByZWR1Y2VkIHRv IGEgdmVyeSBsb3cgcmF0ZSBpZiB0aGUgQUNLcyBhcmUgZGlzY2FyZGVkIGJ5IGFuIGF0dGFja2Vy Lg0KDQpJIHdvdWxkIHNheSB0aGF0IGl0IGlzIG1vcmUgc3RyYWlnaHRmb3J3YXJkIHRvIHVzZSBh IG11bHRpcHVycG9zZSBjb25nZXN0aW9uIGNvbnRyb2wgaW4gUVVJQywgdGhpcyBpcyBwZXJoYXBz IGJhc2VkIG9uIEJCUiwgYnV0IFNDUmVBTSBzdHlsZSBpcyBub3QgZXhjbHVkZWQuIEluIGFueSBj YXNlIHRoaXMgbWVhbnMgdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gcHJldmVudCByYXRlIGFk YXB0YXRpb24uDQoNCi9JbmdlbWFyDQoNCg0KRnJvbTogUGhpbGlwcCBTLiBUaWVzZWwgW21haWx0 bzpwaGlsc0Bpbi1wYW5pay5kZV0NClNlbnQ6IGRlbiA2IG5vdmVtYmVyIDIwMTcgMTA6MTUNClRv OiBSb25pIEV2ZW4gPHJvbmkuZXZlbkBodWF3ZWkuY29tPG1haWx0bzpyb25pLmV2ZW5AaHVhd2Vp LmNvbT4+DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+ DQpTdWJqZWN0OiBSZTogZHJhZnQtdGllc2VsLXF1aWMtdW5yZWxpYWJsZS1zdHJlYW1zLTAxIC0g Y29tbWVudHMNCg0KDQoNCk9uIDUuIE5vdiAyMDE3LCBhdCAwODozMiwgUm9uaSBFdmVuIDxyb25p LmV2ZW5AaHVhd2VpLmNvbTxtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20+PiB3cm90ZToNCkZy b206IFBoaWxpcHAgUy4gVGllc2VsIFttYWlsdG86cGhpbHNAaW4tcGFuaWsuZGVdDQpPbiAxLiBO b3YgMjAxNywgYXQgMTQ6MDMsIFJvbmkgRXZlbiA8cm9uaS5ldmVuQGh1YXdlaS5jb208bWFpbHRv OnJvbmkuZXZlbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpJbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiDi gJwgQW4gYWN0aXZlLCBvbiBwYXRoIGF0dGFja2VyIGNhbiBkcm9wIHNlbGVjdGVkDQpmcmFtZXMg 4oCcIC4gV2hhdCBkb2VzIGl0IG1lYW4gc2VsZWN0ZWQgZnJhbWVzLCB0aGUgd2hvbGUgcGF5bG9h ZCBpcw0KZW5jcnlwdGVkLg0KVGhpcyBpcyBhIGxpdHRsZSBjb21wbGljYXRlZDoNCi0gQXNzdW1l IGhhdmluZyDigJxzdHJlYW0tYXMtYS1tZXNzYWdl4oCdIHN0cmVhbXMgd2l0aCB0d28gZGlmZmVy ZW50IGtpbnMgb2YNCm1lc3NhZ2VzIHNpemVkIEEsQg0KLSBBc3N1bWUgZWFjaCBtZXNzYWdlIGZp dHMgaW50byBvbmUgcGFja2V0LCBidXQgdHdvIG1lc3NhZ2VzIHdpbGwgbm90IGZpdA0KLSBBc3N1 bWUgb25lIGRvZXNuJ3Qgd2FudCB0byBzcGxpdCBwYWNrZXRzIHRvIGZpbGwgcGFja2V0cyB0byBN VFUgZHVlIHRvDQpsYXRlbmN5IGNvbnN0cmFpbnMgID0+IElmIGFuIGF0dGFja2VyIGtub3cgdGhl IGluc2lkZSBwcm90b2NvbCwgdGhlIGF0dGFja2VyDQpjYW4gZGlzdGluZ3Vpc2ggZnJvbSB0aGUg cGFja2V0IGxlbmd0aCB3ZXRoZXIgaXQgaXMgYW4gQSBvciBCIGtpbmQgbWVzc2FnZQ0KDQpUbyBh dm9pZCB0aGlzLCBvbmUgaGFzIHRvIHBhZCBhbGwgcGFja2V0c+KApiBJIHNob3VsZCBjbGFyaWZ5 IHRoaXMuDQpbUm9uaSBFdmVuXSBJIHVuZGVyc3RhbmQgdGhpcyBjYXNlIGJ1dCB3aGF0IGRvZXMg c2VsZWN0ZWQgZnJhbWVzIG1lYW4sIEkgYXNzdW1lIHRoYXQgdGhlIGF0dGFja2VyIGRvZXMgbm90 IGtub3cgd2hhdCBpcyBpbiBlYWNoIHN0cmVhbSBpbiBvcmRlciB0byBzZWxlY3QgYSBzcGVjaWZp YyBvbmUsIHNvIHdoeSB3aWxsIGhlIGp1c3QgZHJvcCBvbmUgYW5kIG5vdCB0aGUgb3RoZXIgb3Ig d2h5IG5vdCBib3RoPw0KDQpBc3N1bWluZyB0aGUgYXR0YWNrZXIgX2tub3dzIHRoZSBwcm90b2Nv bF8sIHRoZSBhdHRhY2tlciB3b3VsZCBhbHNvIGtub3cgdGhlIHNpemVzIG9mIGFsbCBraW5kcyBv ZiBtZXNzYWdlcyBhbmQgbWF5IHVzZSB0aGlzIGtub3dsZWRnZSB0byByZWNvdmVyIHByb3RvY29s IHN0YXRlIG9yIHNlbGVjdGl2ZWx5IGRyb3AgbWVzc2FnZXMuDQoNCkZvciBhIHByb3RvY29sIGxp a2UgSFRUUCwgdGhlIGF0dGFjayB2ZWN0b3IgaXMgcmF0aGVyIHNtYWxsLg0KSWYgb25lIHVzZXMg dGhpcyBhZ2FpbnN0IHZpZGVvIGNvbmZlcmVuY2luZyBhcHBsaWNhdGlvbnMsIGFuIGF0dGFja2Vy IGNvdWxkIHByZXZlbnQgcmF0ZSBhZGFwdGlvbiAgYnkgZHJvcHBpbmcgcmVjZXB0aW9uIHJlcG9y dHMgKGxhcmdlciB0aGFuIGEgcHVyZSBRVUlDIEFDSywgc21hbGxlciB0aGFuIGEgdmlkZW8gZnJh bWUpLg0KSWYgb25lIHVzZXMgdGhpcyBvbiBJb1QgY29udHJvbCBzdHVmZiwgYW4gYXR0YWNrZXIg bWlnaHQgYmUgYWJsZSB0byBsZWFybiBhIGxvdCBhYm91dCB0aGUgc3lzdGVtIHN0YXRlIGJ5IG9i c2VydmluZyBzaXplcyBhbmQgdGltaW5ncy4NCg0KVGhpcyBpcyBub3RoaW5nIHdlIGNhbiBmaXgg d2l0aGluIFFVSUMgd2l0aG91dCBtYXNzaXZlIHNjYXJpZmllcywgYnV0IGFwcGxpY2F0aW9uIGRl dmVsb3BlcnMgbXVzdCBrZWVwIGluIG1pbmQuDQoNCg0KQVZFIQ0KICBQaGlsaXBwIFMuIFRpZXNl bCAvIHBoaWxz4oCmDQotLQ0KICAge3BoaWxzfS0tLT4tLS0ocGhpbHNAaW4tcGFuaWsuZGU8bWFp bHRvOnBoaWxzQGluLXBhbmlrLmRlPiktLS0+LS0tKGh0dHA6Ly9waGlscy5pbi1wYW5pay5kZSkt LS0tLA0KICAgICAgd2VubiB3IGVpbmUgICBhdWJlIGlzdCBkbiAgICAgIG1hbiBhdSBkcmFuIGRy ZSBlbiAgICAgICAgICAgICAgICAgICB8DQogICAgICAgICAgIG8gICAgIFNjaHIgICAgICAgIGFu IG11c3MgICAgIGhjICAgICAgICAgaCAgIChLdXJ0IFNjaHdpdHRlcnMpIHwNCjp3cSEgIDwtLS0t KHBob25lOiArNDktMTc5LTY3Mzc0MzkpLS0tPC0tLShqYWJiZXI6IHBoaWxzQGluLXBhbmlrLmRl PG1haWx0bzpwaGlsc0Bpbi1wYW5pay5kZT4pLS0tLScNCg0K --_000_DB4PR07MB348012BC630A37881C3852CC2510DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sby1SZWd1bGFy Ow0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIi Ow0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBw dDsNCglmb250LWZhbWlseToiVGFob21hIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5CYWxsb29uVGV4dENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6 IlRhaG9tYSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+ PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4 dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxh eW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5r PSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PSywgdGhlbiBJIHVu ZGVyc3RhbmQsIG1heWJlLi4gU3RpbGwgZG9u4oCZdCBnZXQgaXQsIHNvcnJ5LiBJZiB5b3UgYXJl IGFib3V0IHRvIHNlbGVjdGl2ZWx5IGRpc2NhcmQgQUNLIHBhY2tldHMsIHRoZW4gdGhlIEFDSyBz cGFjaW5nIHdpbGwgYmVjb21lIGxhcmdlciBhbmQgdGhlIEFDSyBjbG9ja2luZyB3aWxsIGJlIGRl Z3JhZGVkLiBUaGUgZW5kIGVmZmVjdCBpcyB0aGF0IGFsc28gdGhlIG1lZGlhIChvciB3aGF0ZXZl cikNCiB0aGF0IGNvbnN0aXR1dGUgdGhlIGxhcmdlIHBhY2tldHMgd2lsbCBhbHNvIGdldCBhIGRl Z3JhZGVkIHBlcmZvcm1hbmNlID8gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYXNzdW1lIHRo YXQgd2Ugd2lsbCBzdGlsbCBiZSBydW5uaW5nIG9uZSBjb25nZXN0aW9uIGNvbnRyb2wgZm9yIHRo ZSBjb25uZWN0aW9uID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+L0luZ2VtYXI8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBj bSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUm9uaSBFdmVuIFttYWlsdG86cm9uaS5ldmVu QGh1YXdlaS5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gNyBub3ZlbWJlciAyMDE3IDEyOjUw PGJyPg0KPGI+VG86PC9iPiBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDtpbmdlbWFyLnMuam9oYW5z c29uQGVyaWNzc29uLmNvbSZndDs7IFBoaWxpcHAgUy4gVGllc2VsICZsdDtwaGlsc0Bpbi1wYW5p ay5kZSZndDs8YnI+DQo8Yj5DYzo8L2I+IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC10aWVzZWwtcXVpYy11bnJlbGlhYmxlLXN0cmVh bXMtMDEgLSBjb21tZW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIEluZ2VtYXIsPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0 IGlzIG5vdCBDQ00gdGhlIGF0dGFja2VyIGp1c3QgZG9lcyBoZXVyaXN0aWNzIHRvIHVuZGVyc3Rh bmQgdGhhdCB0aGlzIGlzIG5vdCBtZWRpYSBidXQgcmVwb3J0IChSVENQIG9yIEFDSyBmcmFtZXMp IGFuZCBkcm9wcyBpdCwgQlRXOiBhdWRpbyBwYWNrZXRzIG1heSBhbHNvIGJlIHNtYWxsLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlRoaXMgaXMgYW4gZXhhbXBsZS4gVGhlIGNsYWltIGlzIHRoYXQgeW91IGNh biB1c2UgaGV1cmlzdGljcyB0byBkcm9wIOKAnHNlbGVjdGVk4oCdIGZyYW1lcyBldmVuIHRob3Vn aCB5b3UgZG8gbm90IGtub3cgd2hhdCBpcyBpbiB0aGUgcGFja2V0LjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5S b25pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp ZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gSW5nZW1hciBKb2hhbnNzb24gUyBb PGEgaHJlZj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj5tYWlsdG86 aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+ IDwvc3Bhbj48c3BhbiBsYW5nPSJIRSIgZGlyPSJSVEwiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj7XmdeV150mbmJzcDvX kiAwNyDXoNeV15HXnteR16ggMjAxNyAwOTo0MTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0K PGI+VG86PC9iPiBQaGlsaXBwIFMuIFRpZXNlbDsgUm9uaSBFdmVuPGJyPg0KPGI+Q2M6PC9iPiBR VUlDIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBkcmFmdC10aWVzZWwtcXVpYy11bnJlbGlh YmxlLXN0cmVhbXMtMDEgLSBjb21tZW50czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkhpIFBoaWxpcCBhbmQgUm9uaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGFzc3VtZSB0aGF0IGJ5IDx1PnJlY2VwdGlvbjwvdT4gcmVwb3J0cyBpcyBtZWFudCB0aGUg UlRDUCBDQ00gbWVzc2FnZXMgc3VjaCBhcyBUTU1CUiBvciA/PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlNvLi4gdW5sZXNzIEkgbWlzdW5kZXJzdG9vZCBpdCBjb21wbGV0ZWx5LjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBub3QgYXQgYWxsIGNvbnZpbmNlZCB0aGF0 IG1lZGlhIHJhdGUvY29uZ2VzdGlvbiBjb250cm9sIGluIFFVSUMgc2hvdWxkIHJlbHkgb24gVE1N QlIuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNDUmVBTSBmb3IgaW5z dGFuY2UsIHNwZWNpZmllZCBpbiB0aGUgUk1DQVQgV0cgZm9yIGluc3RhbmNlIGRvZXMgbm90IGRl cGVuZCBvbiBUTU1CUiBhcyBpdCBpcyBBQ0sgY2xvY2tlZCwgdGhlIG1lZGlhIHRyYW5zbWlzc2lv biBpcyByZWR1Y2VkIHRvIGEgdmVyeSBsb3cgcmF0ZSBpZiB0aGUgQUNLcyBhcmUgZGlzY2FyZGVk IGJ5IGFuIGF0dGFja2VyLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgc2F5IHRo YXQgaXQgaXMgbW9yZSBzdHJhaWdodGZvcndhcmQgdG8gdXNlIGEgbXVsdGlwdXJwb3NlIGNvbmdl c3Rpb24gY29udHJvbCBpbiBRVUlDLCB0aGlzIGlzIHBlcmhhcHMgYmFzZWQgb24gQkJSLCBidXQg U0NSZUFNIHN0eWxlIGlzIG5vdCBleGNsdWRlZC4gSW4gYW55IGNhc2UgdGhpcyBtZWFucyB0aGF0 IGl0IGlzIG5vdCBwb3NzaWJsZSB0byBwcmV2ZW50IHJhdGUgYWRhcHRhdGlvbi4NCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4vSW5nZW1hcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFBoaWxp cHAgUy4gVGllc2VsIFs8YSBocmVmPSJtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGUiPm1haWx0bzpw aGlsc0Bpbi1wYW5pay5kZTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gZGVuIDYgbm92ZW1iZXIg MjAxNyAxMDoxNTxicj4NCjxiPlRvOjwvYj4gUm9uaSBFdmVuICZsdDs8YSBocmVmPSJtYWlsdG86 cm9uaS5ldmVuQGh1YXdlaS5jb20iPnJvbmkuZXZlbkBodWF3ZWkuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWlj QGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGRyYWZ0LXRpZXNlbC1x dWljLXVucmVsaWFibGUtc3RyZWFtcy0wMSAtIGNvbW1lbnRzPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gNS4gTm92IDIwMTcsIGF0 IDA4OjMyLCBSb25pIEV2ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNv bSI+cm9uaS5ldmVuQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i b3R0b206NS4wcHQ7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiBhdXRvO3RleHQt YWxpZ246c3RhcnQ7d2lkb3dzOiBhdXRvOy13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzst d2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJp ZiI+RnJvbTogUGhpbGlwcCBTLiBUaWVzZWwgWzxhIGhyZWY9Im1haWx0bzpwaGlsc0Bpbi1wYW5p ay5kZSI+bWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlPC9hPl08bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFy JnF1b3Q7LHNlcmlmIj5PbiAxLiBOb3YgMjAxNywgYXQgMTQ6MDMsIFJvbmkgRXZlbiAmbHQ7PGEg aHJlZj0ibWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tIj5yb25pLmV2ZW5AaHVhd2VpLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxibG9j a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5JbiB0aGUgc2VjdXJpdHkgc2VjdGlv biDigJwgQW4gYWN0aXZlLCBvbiBwYXRoIGF0dGFja2VyIGNhbiBkcm9wIHNlbGVjdGVkPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+ZnJhbWVzIOKAnCAu IFdoYXQgZG9lcyBpdCBtZWFuIHNlbGVjdGVkIGZyYW1lcywgdGhlIHdob2xlIHBheWxvYWQgaXM8 YnI+DQplbmNyeXB0ZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWls eTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5UaGlzIGlzIGEgbGl0dGxlIGNvbXBs aWNhdGVkOjxicj4NCi0gQXNzdW1lIGhhdmluZyDigJxzdHJlYW0tYXMtYS1tZXNzYWdl4oCdIHN0 cmVhbXMgd2l0aCB0d28gZGlmZmVyZW50IGtpbnMgb2Y8YnI+DQptZXNzYWdlcyBzaXplZCBBLEI8 YnI+DQotIEFzc3VtZSBlYWNoIG1lc3NhZ2UgZml0cyBpbnRvIG9uZSBwYWNrZXQsIGJ1dCB0d28g bWVzc2FnZXMgd2lsbCBub3QgZml0PGJyPg0KLSBBc3N1bWUgb25lIGRvZXNuJ3Qgd2FudCB0byBz cGxpdCBwYWNrZXRzIHRvIGZpbGwgcGFja2V0cyB0byBNVFUgZHVlIHRvPGJyPg0KbGF0ZW5jeSBj b25zdHJhaW5zICZuYnNwOz0mZ3Q7IElmIGFuIGF0dGFja2VyIGtub3cgdGhlIGluc2lkZSBwcm90 b2NvbCwgdGhlIGF0dGFja2VyPGJyPg0KY2FuIGRpc3Rpbmd1aXNoIGZyb20gdGhlIHBhY2tldCBs ZW5ndGggd2V0aGVyIGl0IGlzIGFuIEEgb3IgQiBraW5kIG1lc3NhZ2U8YnI+DQo8YnI+DQpUbyBh dm9pZCB0aGlzLCBvbmUgaGFzIHRvIHBhZCBhbGwgcGFja2V0c+KApiBJIHNob3VsZCBjbGFyaWZ5 IHRoaXMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtN ZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5bUm9uaSBFdmVuXSBJIHVuZGVyc3RhbmQgdGhpcyBj YXNlIGJ1dCB3aGF0IGRvZXMgc2VsZWN0ZWQgZnJhbWVzIG1lYW4sIEkgYXNzdW1lIHRoYXQgdGhl IGF0dGFja2VyIGRvZXMgbm90IGtub3cgd2hhdCBpcyBpbiBlYWNoIHN0cmVhbSBpbiBvcmRlciB0 byBzZWxlY3QgYSBzcGVjaWZpYyBvbmUsIHNvDQogd2h5IHdpbGwgaGUganVzdCBkcm9wIG9uZSBh bmQgbm90IHRoZSBvdGhlciBvciB3aHkgbm90IGJvdGg/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFzc3VtaW5nIHRoZSBhdHRhY2tlciBfa25vd3MgdGhlIHByb3RvY29sXywgdGhlIGF0dGFj a2VyIHdvdWxkIGFsc28ga25vdyB0aGUgc2l6ZXMgb2YgYWxsIGtpbmRzIG9mIG1lc3NhZ2VzIGFu ZCBtYXkgdXNlIHRoaXMga25vd2xlZGdlIHRvIHJlY292ZXIgcHJvdG9jb2wgc3RhdGUgb3Igc2Vs ZWN0aXZlbHkgZHJvcCBtZXNzYWdlcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGEgcHJvdG9jb2wgbGlrZSBIVFRQLCB0aGUgYXR0YWNr IHZlY3RvciBpcyByYXRoZXIgc21hbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBvbmUgdXNlcyB0aGlzIGFnYWluc3QgdmlkZW8gY29uZmVy ZW5jaW5nIGFwcGxpY2F0aW9ucywgYW4gYXR0YWNrZXIgY291bGQgcHJldmVudCByYXRlIGFkYXB0 aW9uICZuYnNwO2J5IGRyb3BwaW5nIHJlY2VwdGlvbiByZXBvcnRzIChsYXJnZXIgdGhhbiBhIHB1 cmUgUVVJQyBBQ0ssIHNtYWxsZXIgdGhhbiBhIHZpZGVvIGZyYW1lKS48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIG9uZSB1c2VzIHRoaXMgb24g SW9UIGNvbnRyb2wgc3R1ZmYsIGFuIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gbGVhcm4gYSBs b3QgYWJvdXQgdGhlIHN5c3RlbSBzdGF0ZSBieSBvYnNlcnZpbmcgc2l6ZXMgYW5kIHRpbWluZ3Mu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRo aXMgaXMgbm90aGluZyB3ZSBjYW4gZml4IHdpdGhpbiBRVUlDIHdpdGhvdXQgbWFzc2l2ZSBzY2Fy aWZpZXMsIGJ1dCBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIG11c3Qga2VlcCBpbiBtaW5kLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5BVkUhPGJyPg0KJm5ic3A7IFBoaWxp cHAgUy4gVGllc2VsIC8gcGhpbHPigKY8YnI+DQotLSZuYnNwOzxicj4NCiZuYnNwOyAmbmJzcDt7 cGhpbHN9LS0tJmd0Oy0tLSg8YSBocmVmPSJtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGUiPnBoaWxz QGluLXBhbmlrLmRlPC9hPiktLS0mZ3Q7LS0tKDxhIGhyZWY9Imh0dHA6Ly9waGlscy5pbi1wYW5p ay5kZSI+aHR0cDovL3BoaWxzLmluLXBhbmlrLmRlPC9hPiktLS0tLDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7IHdlbm4gdyBlaW5lICZuYnNwOyBhdWJlIGlzdCBkbiAmbmJzcDsgJm5ic3A7ICZu YnNwO21hbiBhdSBkcmFuIGRyZSBlbiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtvICZuYnNwOyAmbmJzcDsgU2NociAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDthbiBtdXNzICZuYnNwOyAmbmJzcDsgaGMgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IGggJm5ic3A7IChLdXJ0IFNjaHdpdHRlcnMpIHw8YnI+DQo6d3EhICZuYnNwOyZsdDst LS0tKHBob25lOiAmIzQzOzQ5LTE3OS02NzM3NDM5KS0tLSZsdDstLS0oamFiYmVyOiA8YSBocmVm PSJtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGUiPg0KcGhpbHNAaW4tcGFuaWsuZGU8L2E+KS0tLS0n PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DB4PR07MB348012BC630A37881C3852CC2510DB4PR07MB348eurprd_-- From nobody Tue Nov 7 08:09: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 07BE213342D for ; Tue, 7 Nov 2017 08:09:21 -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=litespeedtech-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 A0XIBzLwTpEm for ; Tue, 7 Nov 2017 08:09:19 -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 1A09F1346DD for ; Tue, 7 Nov 2017 07:59:26 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id q83so15855309qke.6 for ; Tue, 07 Nov 2017 07:59:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=236HyKkTMIGWigEtuDkoivQio7kU1klW3+vrQlrCuh8=; b=yfWrM0zPFGwCgdKdLyz9zrz2lE1krS57dkILAMVqxr2e1bcsZmwm76VibS8thlDFz9 nA1aFW8CxY2szB9hUPjSU1cnFbq3Xu4TmEOuiGQrGkYkK2SHhiu8n7tunnQBdgYI8G+9 BTKrO6ylwlCuBqmTHYq/7wz52pviI1tSEAVEZst5hgD50zSoHxxITCNV1tLJ7dnQy+4n w39LmV1/3ixHhlEDZO2gWY9qbV3I0iAHTX7CbRBiOK2ua98hgYvDUB7tc+H3Zj3MrODr hZthQtUO6PBi+4baBhNSNzPBqylBlUMCKJqZM5TgxextAr9VRfDMekAlrkXrEuW3TD8w URvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=236HyKkTMIGWigEtuDkoivQio7kU1klW3+vrQlrCuh8=; b=C7SQCEGVA2NoERXXNJcYCe+bxs8PCZ5TTlFYpPoWqj0DTunggvs13hqyimarslEWg7 heFw534Zv39XqhynVRrdzW1+KF51AJXRAUGF8uAeifvpOIIBKs1AU7Q4ozBrASwOD5nO /XV0CjHvArmBItUQpMdK7cAmuWlEFdQ7/0kGMmZEPr7JKgkj7pg6GmowVTDt4ascBFjl KGogzE3xYR6s7LEBDSdo0Z3PdXzyk6h+wiRrqISFO/0jWJkzS3ieTTnqrF0tSEiEfqKP bmWrY9FeiUN4g4HLFzp50TnnL/mf4/G0MFPtsFnFu/pNk4aMCjIkHv4mMYx85SIQB4N4 JlGg== X-Gm-Message-State: AJaThX5Utd9XvBp0Ug5CCEVI35o6YsET+ty6+JFtGh7jNWsj25biv/kh lfhXxyIAllYlQAPtKX5DPs9YrtAm X-Google-Smtp-Source: ABhQp+TAQvRS58JzQEKQ1GNa+dDkn7csW5T564sU2AtNbSylAs3AwBXvANAaxAglk1HDhkMyNkyJQw== X-Received: by 10.55.42.75 with SMTP id q72mr8356818qkh.57.1510070365089; Tue, 07 Nov 2017 07:59:25 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id s9sm1093144qts.42.2017.11.07.07.59.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 07 Nov 2017 07:59:24 -0800 (PST) Date: Tue, 7 Nov 2017 10:59:18 -0500 From: Dmitri Tikhonov To: IETF QUIC WG Subject: QMIN: Header Compression for QUIC Message-ID: <20171107155917.GA17613@ubuntu-dmitri> Mail-Followup-To: IETF QUIC WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 16:09:21 -0000 Hello, Here is yet another header compression proposal: https://github.com/litespeedtech/qmin/blob/master/id-qmin.txt QMIN is a compression format and protocol for HTTP/2 headers. QMIN is based on HPACK. The modifications to HPACK are meant to allow robust compression use in QUIC: That is, no head-of-line blocking and low overhead. QMIN is guided by HPACK design principles. It inherits all of HPACK's data structures and retains binary compatibility with it. While designed with QUIC in mind, QMIN can be used in other contexts. Because IETF draft submission is disabled until November 12th, my proposal is hosted on GitHub. I will make a formal submission when the submission tool is reopened. In the meantime, any feedback is welcome. Thank you, - Dmitri. From nobody Tue Nov 7 08:49: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 7D40213320D for ; Tue, 7 Nov 2017 08:49:01 -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, HTML_MESSAGE=0.001, 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 wNZhACgFAmnB for ; Tue, 7 Nov 2017 08:48:58 -0800 (PST) Received: from einhorn-mail.in-berlin.de (einhorn.in-berlin.de [192.109.42.8]) (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 15E8613316B for ; Tue, 7 Nov 2017 08:48:57 -0800 (PST) X-Envelope-From: phils@in-panik.de Received: from x-berg.in-berlin.de (x-change.in-berlin.de [217.197.86.40]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-8+deb8u2) with ESMTP id vA7GmQ3X021430 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 7 Nov 2017 17:48:26 +0100 Received: from [2001:638:809:ff1f::8295:dc66] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1eC72b-00051P-IM; Tue, 07 Nov 2017 17:47:57 +0100 From: "Philipp S. Tiesel" Message-Id: <7A7BC718-CA7C-4DF1-87DC-EB7C48B48C56@in-panik.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_CBE3E2C2-BEFA-4C3C-8390-67D1505DD093" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments Date: Tue, 7 Nov 2017 17:48:25 +0100 In-Reply-To: Cc: Roni Even , QUIC WG To: Ingemar Johansson S References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD832288@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8351F8@DGGEMM506-MBX.china.huawei.com> X-Mailer: Apple Mail (2.3445.4.7) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 16:49:01 -0000 --Apple-Mail=_CBE3E2C2-BEFA-4C3C-8390-67D1505DD093 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, the whole point came up in the security considerations of the draft: If one uses unreliable streams as-a-message to cut down delay, it is also necessary to send them out right away and don=E2=80=99t wait unit a MTU-sized packet is full. Despite encryption, this allows an attacker to learn about = message sizes and, assuming the protocol within the QUIC connection is = known, might allow guessing what messages were used. =20 One _example_ for such an attack was an hypothetical streaming = protocol which an attacker can drop delivery reports for and thus could = influence rate adaption. I came to the conclusion this was not the best example for the message = guessing attack. > On 7. Nov 2017, at 15:47, Ingemar Johansson S = wrote: >=20 > Hi > =20 > OK, then I understand, maybe.. Still don=E2=80=99t get it, sorry. If = you are about to selectively discard ACK packets, then the ACK spacing = will become larger and the ACK clocking will be degraded. The end effect = is that also the media (or whatever) that constitute the large packets = will also get a degraded performance ?=20 > =20 > I assume that we will still be running one congestion control for the = connection ? > =20 > /Ingemar > =20 > From: Roni Even [mailto:roni.even@huawei.com]=20 > Sent: den 7 november 2017 12:50 > To: Ingemar Johansson S ; Philipp S. = Tiesel > Cc: QUIC WG > Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments > =20 > Hi Ingemar, > It is not CCM the attacker just does heuristics to understand that = this is not media but report (RTCP or ACK frames) and drops it, BTW: = audio packets may also be small. > This is an example. The claim is that you can use heuristics to drop = =E2=80=9Cselected=E2=80=9D frames even though you do not know what is in = the packet. > Roni > =20 > =20 > =20 > From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com = ]=20 > Sent: =D7=99=D7=95=D7=9D =D7=92 07 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 = 2017 09:41 > To: Philipp S. Tiesel; Roni Even > Cc: QUIC WG > Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments > =20 > Hi Philip and Roni > =20 > I assume that by reception reports is meant the RTCP CCM messages such = as TMMBR or ? > =20 > So.. unless I misunderstood it completely. > I am not at all convinced that media rate/congestion control in QUIC = should rely on TMMBR. > SCReAM for instance, specified in the RMCAT WG for instance does not = depend on TMMBR as it is ACK clocked, the media transmission is reduced = to a very low rate if the ACKs are discarded by an attacker. > =20 > I would say that it is more straightforward to use a multipurpose = congestion control in QUIC, this is perhaps based on BBR, but SCReAM = style is not excluded. In any case this means that it is not possible to = prevent rate adaptation. > =20 > /Ingemar > =20 > =20 > From: Philipp S. Tiesel [mailto:phils@in-panik.de = ]=20 > Sent: den 6 november 2017 10:15 > To: Roni Even > > Cc: QUIC WG > > Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments > =20 > =20 > =20 >=20 > On 5. Nov 2017, at 08:32, Roni Even > wrote: > From: Philipp S. Tiesel [mailto:phils@in-panik.de = ] >=20 > On 1. Nov 2017, at 14:03, Roni Even > wrote: >=20 > In the security section =E2=80=9C An active, on path attacker can drop = selected > frames =E2=80=9C . What does it mean selected frames, the whole = payload is > encrypted. >=20 > This is a little complicated: > - Assume having =E2=80=9Cstream-as-a-message=E2=80=9D streams with two = different kins of > messages sized A,B > - Assume each message fits into one packet, but two messages will not = fit > - Assume one doesn't want to split packets to fill packets to MTU due = to > latency constrains =3D> If an attacker know the inside protocol, the = attacker > can distinguish from the packet length wether it is an A or B kind = message >=20 > To avoid this, one has to pad all packets=E2=80=A6 I should clarify = this. > [Roni Even] I understand this case but what does selected frames mean, = I assume that the attacker does not know what is in each stream in order = to select a specific one, so why will he just drop one and not the other = or why not both? > =20 > Assuming the attacker _knows the protocol_, the attacker would also = know the sizes of all kinds of messages and may use this knowledge to = recover protocol state or selectively drop messages. > =20 > For a protocol like HTTP, the attack vector is rather small. > If one uses this against video conferencing applications, an attacker = could prevent rate adaption by dropping reception reports (larger than = a pure QUIC ACK, smaller than a video frame). > If one uses this on IoT control stuff, an attacker might be able to = learn a lot about the system state by observing sizes and timings. > =20 > This is nothing we can fix within QUIC without massive scarifies, but = application developers must keep in mind. > =20 > =20 > AVE! > Philipp S. Tiesel / phils=E2=80=A6 > --=20 > {phils}--->---(phils@in-panik.de = )--->---(http://phils.in-panik.de = )----, > wenn w eine aube ist dn man au dran dre en = | > o Schr an muss hc h (Kurt = Schwitters) | > :wq! <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de = )----' AVE! Philipp S. Tiesel / phils=E2=80=A6 --=20 = {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----, wenn w eine aube ist dn man au dran dre en = | o Schr an muss hc h (Kurt = Schwitters) | :wq! <----(phone: +49-179-6737439)---<---(jabber: = phils@in-panik.de)----' --Apple-Mail=_CBE3E2C2-BEFA-4C3C-8390-67D1505DD093 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

the = whole point came up in the security considerations of the = draft:

If one = uses unreliable streams as-a-message to cut down
= delay, it is also necessary to send them out right away
= and don=E2=80=99t wait unit a MTU-sized packet is full.

Despite = encryption, this allows an attacker to learn about message
 = sizes and, assuming the protocol within the QUIC = connection is known,
might allow guessing what = messages were used.
 
One = _example_ for such an attack was an hypothetical streaming = protocol
which an attacker can drop = delivery reports for and thus could influence
rate = adaption.

I = came to the conclusion this was not the best example for the message = guessing attack.


On 7. Nov 2017, at 15:47, Ingemar Johansson S <ingemar.s.johansson@ericsson.com> wrote:

Hi
 
OK, then I understand, maybe.. Still don=E2=80=99t get it, = sorry. If you are about to selectively discard ACK packets, then the ACK = spacing will become larger and the ACK clocking will be degraded. The = end effect is that also the media (or whatever) that constitute the = large packets will also get a degraded performance ? 
 
I assume = that we will still be running one congestion control for the connection = ?
 
/Ingemar
 
From: Roni Even [mailto:roni.even@huawei.com] 
Sent: den= 7 november 2017 12:50
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; Philipp S. Tiesel = <phils@in-panik.de>
Cc: QUIC = WG <quic@ietf.org>
Subject: RE: = draft-tiesel-quic-unreliable-streams-01 - comments
 
Hi = Ingemar,
It is not = CCM the attacker just does heuristics to understand that this is not = media but report (RTCP or ACK frames) and drops it, BTW: audio packets = may also be small.
This is = an example. The claim is that you can use heuristics to drop = =E2=80=9Cselected=E2=80=9D frames even though you do not know what is in = the packet.
Roni
 
 
 
From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] 
Sent: =D7=99=D7=95=D7=9D =D7=92 07 =D7=A0=D7=95=D7=91=D7=9E=D7=91= =D7=A8 2017 09:41
To: Philipp S. Tiesel; Roni = Even
Cc: QUIC WG
Subject: RE: = draft-tiesel-quic-unreliable-streams-01 - comments
 
Hi Philip and Roni
 
I assume that by reception reports is meant the RTCP = CCM messages such as TMMBR or ?
 
So.. unless I misunderstood it = completely.
I= am not at all convinced that media rate/congestion control in QUIC = should rely on TMMBR.
SCReAM for instance, specified in the RMCAT WG for instance = does not depend on TMMBR as it is ACK clocked, the media transmission is = reduced to a very low rate if the ACKs are discarded by an attacker.
 
I would = say that it is more straightforward to use a multipurpose congestion = control in QUIC, this is perhaps based on BBR, but SCReAM style is not = excluded. In any case this means that it is not possible to prevent rate = adaptation.
 
/Ingemar
 
 
From: Philipp S. Tiesel [mailto:phils@in-panik.de] 
Sent: den= 6 november 2017 10:15
To: Roni Even <roni.even@huawei.com>
Cc: QUIC WG <quic@ietf.org>
Subject: Re: = draft-tiesel-quic-unreliable-streams-01 - comments
 
 

 

On 5. Nov 2017, at 08:32, Roni Even <roni.even@huawei.com> = wrote:

From: Philipp S. Tiesel [mailto:phils@in-panik.de]

On 1. Nov 2017, at 14:03, Roni Even <roni.even@huawei.com> = wrote:

In the security section = =E2=80=9C An active, on path attacker can drop selected

frames =E2=80=9C . What = does it mean selected frames, the whole payload is
encrypted.

This is a little = complicated:
- Assume having =E2=80=9Cstream-as-a-message=E2= =80=9D streams with two different kins of
messages sized = A,B
- Assume each message fits into one packet, but two = messages will not fit
- Assume one doesn't want to split = packets to fill packets to MTU due to
latency constrains =  =3D> If an attacker know the inside protocol, the attacker
can distinguish from the packet length wether it is an A or B = kind message

To avoid this, one has to pad = all packets=E2=80=A6 I should clarify this.
[Roni Even] I understand this case but what does = selected frames mean, I assume that the attacker does not know what is = in each stream in order to select a specific one, so why will he just = drop one and not the other or why not both?
 
Assuming the attacker _knows the protocol_, the attacker = would also know the sizes of all kinds of messages and may use this = knowledge to recover protocol state or selectively drop messages.
 
For a protocol like HTTP, the attack = vector is rather small.
If one uses this against = video conferencing applications, an attacker could prevent rate adaption =  by dropping reception reports (larger than a pure QUIC ACK, = smaller than a video frame).
If one uses this on IoT = control stuff, an attacker might be able to learn a lot about the system = state by observing sizes and timings.
 
This is nothing we can fix within QUIC = without massive scarifies, but application developers must keep in = mind.
 
 
AVE!
  Philipp S. Tiesel / = phils=E2=80=A6
-- 
  =  {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
  =     wenn w eine   aube ist dn      man au = dran dre en                 =   |
           o   =   Schr        an muss     hc   =       h   (Kurt Schwitters) |
:wq! =  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

AVE!
  Philipp S. Tiesel / phils=E2=80=A6-- 
   {phils}--->---(phils@in-panik.de)--->---(http://phils.in-panik.de)----,
  =     wenn w eine   aube ist dn      man au = dran dre en                 =   |
           o   =   Schr        an muss     hc   =       h   (Kurt Schwitters) |
:wq! =  <----(phone: +49-179-6737439)---<---(jabber: phils@in-panik.de)----'

= --Apple-Mail=_CBE3E2C2-BEFA-4C3C-8390-67D1505DD093-- From nobody Tue Nov 7 14: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 65916129483 for ; Tue, 7 Nov 2017 14:35:11 -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, HTML_MESSAGE=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 FqMXz9aYLXNt for ; Tue, 7 Nov 2017 14:35:09 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 A7243129467 for ; Tue, 7 Nov 2017 14:35:08 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx35.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eCCSY-00088A-00 for quic@ietf.org; Tue, 07 Nov 2017 23:35:06 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eCCSO-0005Tc-Mq for quic@ietf.org; Tue, 07 Nov 2017 17:34:58 -0500 Received: (qmail 17834 invoked from network); 7 Nov 2017 22:34:55 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.39]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 7 Nov 2017 22:34:54 -0000 To: Roni Even , QUIC WG References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> From: Christian Huitema Message-ID: Date: Tue, 7 Nov 2017 14:34:53 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> Content-Type: multipart/alternative; boundary="------------28E0F3DF01393F7CB0DA30EA" Content-Language: en-US Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments X-Originating-IP: 168.144.250.230 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.22) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5jiN6hKn+Ep8vXVO9TnkF2YXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fsWMztea8GPVgtfFt3pofEPB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+OlqTWdUBHTyoJG+mqGBYi8bWhnKPmUW/oWx9V3wTBfG4Y+ZnfomCI+rgOtA8u12EwuwjY+ quNh23liqqeOwMwwqy4lE5s79uoGaeHjfOqnzPcqs5RcLqZ0NIAm9sCHr2eyNIkhDia+jiI1x+25 WhJqOf3+cMSJJ9Vk8Y6lSpImWN1jfvpuHR0I1KvcafUUdDQXhA0UizXQaOxPdjju+1r1qq9IJIue NdZ12JJe7t4cD3McN6qoXPjenLhIOF1oeRaXCr/NWK7TH4FMv3Tfwi9pxNoOgCOIOkpJLDOwqTub LDxLWmcgYfVXjB7b2OHKO6BZ0VwEd+iNUj65ezw/iijHw95cPWLsHiU6tFs2fFlaJuRMyksc0Dx4 iQa9AzGuG3nTPpuFqUUQz+mM8JAD4ECWQ8DWpNApCszClmRRuSyy/Kf4b0gaZx7Nq9QqOn1O3qQW V1cPRjz9OCMMfLnR36inCRN4We5DhRWjgWs48EY3iSG7X+t1TW39Ja77LGPpOwDCYR4kEX6t994C WVS20AAhX18KdtpUm+hN/W/Os4vpuFAxXqQU4SUCmX1X8Fu4HDH1rYsclUPWfsYbR8/iz5oiQk2H BukllN/eBZD4GGbFsCT/dtMIs/LqOU9hZ/v31oRzg7QgpumQxgT4IcKeAlfy/bB/laLK9WZp+I7d gzC3lLdvK/cKOEqlCIPGIfYQDNKLLI6rY1d8Qdsix0hWyXbo X-Report-Abuse-To: spam@quarantine6.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 22:35:11 -0000 This is a multi-part message in MIME format. --------------28E0F3DF01393F7CB0DA30EA Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/1/2017 6:03 AM, Roni Even wrote: > Hi, > > =A0 > > I think support for unreliable streams is important for unidirectional > and bi-directional streams and even if it is V2 we still need to take > support for it into account. One use case is RTP over QUIC. > I used to think that too, but I wonder whether something like RTP in QUIC is best achieved by overloading the concept of streams, or by defining a completely independent system, maybe using RTP and RTCP frame types instead of regular streams types. My main reason to say that is that regular stream data is more or less treated as a byte stream, and RTP is not. The transport is free to send stream data segments containing some of the stream's bytes, depending on flow control, multiplexing conditions, packet size, etc. In contrast, RTP data is sent as series of well delimited packets, each packet corresponding to some well defined time slice of the media. Whatever framing we use in QUIC will have to respect these packet boundaries. Another reason has to do with forward error correction, which is commonly applied to large video frames sent over several packets. Many systems use packet-erasure-correction schemes, which rely on correctly identifying which packet was lost -- or, in QUIC, which of the video-carrying frames was lost. That would require some frame numbering scheme. Some of that is probably best left to the application, but at a minimum QUIC shall be able to respect frame boundaries. And that's probably easier if the data is sent in some specialized RTP framing, rather than as regular STREAM DATA frames. > =A0 > > Small comments: > > =A0 > > In section 4.2 =93 The loss of such a frame does not introduce state at= > the perceived receiver=94. If new streams are opened with higher stream= > ID, =A0it implicitly opens this one frame stream that was lost in the > receiver. I think it still requires the sender to send a reliable FIN > to close this stream. > > =A0 > > In the security section =93 An active, on path attacker can drop > selected frames=93 . What does it mean selected frames, the whole > payload is encrypted. > We probably need to assume that real time stream will be set up by the application, using something like SIP or RTSP in conjunction with SDP. The end of the real time stream could also be signaled by the application in pretty much the same way. Frankly, I don't think that we are ready to define RTP over QUIC right now, as the priority is to finish the base spec. But what we can do is experiment with extension mechanism. For example, define an experiment in which QUIC that can carry RTP, and verify that we can use the various extension mechanisms to field that. We might learn something about these extension tools: version numbers, transport parameter negotiation, maybe experimental frame types. -- Christian Huitema --------------28E0F3DF01393F7CB0DA30EA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

On 11/1/2017 6:03 AM, Roni Even wrote:

Hi,

 

I think support for unreliable streams is important for unidirectional and bi-directional streams and even if it is V2 we still need to take support for it into account. One use case is RTP over QUIC.


I used to think that too, but I wonder whether something like RTP in QUIC is best achieved by overloading the concept of streams, or by defining a completely independent system, maybe using RTP and RTCP frame types instead of regular streams types.

My main reason to say that is that regular stream data is more or less treated as a byte stream, and RTP is not. The transport is free to send stream data segments containing some of the stream's bytes, depending on flow control, multiplexing conditions, packet size, etc. In contrast, RTP data is sent as series of well delimited packets, each packet corresponding to some well defined time slice of the media. Whatever framing we use in QUIC will have to respect these packet boundaries.

Another reason has to do with forward error correction, which is commonly applied to large video frames sent over several packets. Many systems use packet-erasure-correction schemes, which rely on correctly identifying which packet was lost -- or, in QUIC, which of the video-carrying frames was lost. That would require some frame numbering scheme. Some of that is probably best left to the application, but at a minimum QUIC shall be able to respect frame boundaries. And that's probably easier if the data is sent in some specialized RTP framing, rather than as regular STREAM DATA frames.

 

Small comments:

 

In section 4.2 “ The loss of such a frame does not introduce state at the perceived receiver”. If new streams are opened with higher stream ID,  it implicitly opens this one frame stream that was lost in the receiver. I think it still requires the sender to send a reliable FIN to close this stream.

 

In the security section “ An active, on path attacker can drop selected frames “ . What does it mean selected frames, the whole payload is encrypted.


We probably need to assume that real time stream will be set up by the application, using something like SIP or RTSP in conjunction with SDP. The end of the real time stream could also be signaled by the application in pretty much the same way.

Frankly, I don't think that we are ready to define RTP over QUIC right now, as the priority is to finish the base spec. But what we can do is experiment with extension mechanism. For example, define an experiment in which QUIC that can carry RTP, and verify that we can use the various extension mechanisms to field that. We might learn something about these extension tools: version numbers, transport parameter negotiation, maybe experimental frame types.

-- Christian Huitema
--------------28E0F3DF01393F7CB0DA30EA-- From nobody Tue Nov 7 15:35: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 D57B2129B05 for ; Tue, 7 Nov 2017 15:35:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 q_rnIdhXiiQo for ; Tue, 7 Nov 2017 15:35:16 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 1AC63129B37 for ; Tue, 7 Nov 2017 15:35:14 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vA7NW8p3022575; Tue, 7 Nov 2017 23:35:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=/UpgrHuszGXulBuScQMPr/PTvmri6EYShZlykqb+Vwc=; b=EHiBcYr16hcAPAANTHvRaDGIpfpEeQe27FZgPldurt/dO04xzBtvqdVl56LaPeBNUaPa tO3y7hVJIytR0/q+1X2YVeSb84syXFMoIQvFKD7zJ28fTTRxJKJ2BBavEXXe91OfNcmP UfLOyd49RcJrDumQuvECd1jhmLx/vu6oWxhbMR5Ty0ApUMVpkBt8u+DwaC9Jfzkuh+yG nZPqJ+wbJVMjz6VFxuV7atSctZBSZDC3fOa3GnZZPVdZpg+M1hAH847J1OQc50HPkqDp Pq5kE81xNvKnFfyXdLF0sbAYLqkiZfWNn14c+b6Xdva9m1l79meifPkISSbBMm3ZLskt uw== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2e16uav0wu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 07 Nov 2017 23:35:01 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vA7NVL0U013191; Tue, 7 Nov 2017 18:35:01 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e18vubb0d-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 07 Nov 2017 18:35:00 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb2.msg.corp.akamai.com (172.27.123.59) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 7 Nov 2017 18:35:00 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 7 Nov 2017 18:34:59 -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.1263.000; Tue, 7 Nov 2017 18:34:59 -0500 From: "Lubashev, Igor" To: Christian Huitema , Roni Even , QUIC WG Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Topic: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Index: AdNTERoY+irKmTeUSwyYPYwl1z5CzAFMW/mAAAiujxA= Date: Tue, 7 Nov 2017 23:34:59 +0000 Message-ID: <266d61e546f64b549ceb87ef05945bc6@usma1ex-dag1mb5.msg.corp.akamai.com> References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.38.173] Content-Type: multipart/alternative; boundary="_000_266d61e546f64b549ceb87ef05945bc6usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070308 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711070308 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 23:35:19 -0000 --_000_266d61e546f64b549ceb87ef05945bc6usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think an alternative to supporting a new packet transport within QUIC cou= ld be a new "MIN_STREAM_DATA" frame. This frame indicates that nothing bel= ow this stream data offset will be retransmitted. The application can periodically call setMinStreamData(offset), respecting = any in-stream message boundaries that makes sense for the application. If = all data up to the offset has been acked, this is a noop. Otherwise, the tr= ansport drops any unacked bytes up to offset and sends MIN_STREAM_DATA. Th= is way, an application does not need to create a stream-per-message, paying= no penalty in the usual case of all data delivered in time. * Igor From: Christian Huitema [mailto:huitema@huitema.net] Sent: Tuesday, November 07, 2017 5:35 PM To: Roni Even ; QUIC WG Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments On 11/1/2017 6:03 AM, Roni Even wrote: Hi, I think support for unreliable streams is important for unidirectional and = bi-directional streams and even if it is V2 we still need to take support f= or it into account. One use case is RTP over QUIC. I used to think that too, but I wonder whether something like RTP in QUIC i= s best achieved by overloading the concept of streams, or by defining a com= pletely independent system, maybe using RTP and RTCP frame types instead of= regular streams types. My main reason to say that is that regular stream data is more or less trea= ted as a byte stream, and RTP is not. The transport is free to send stream = data segments containing some of the stream's bytes, depending on flow cont= rol, multiplexing conditions, packet size, etc. In contrast, RTP data is se= nt as series of well delimited packets, each packet corresponding to some w= ell defined time slice of the media. Whatever framing we use in QUIC will h= ave to respect these packet boundaries. Another reason has to do with forward error correction, which is commonly a= pplied to large video frames sent over several packets. Many systems use pa= cket-erasure-correction schemes, which rely on correctly identifying which = packet was lost -- or, in QUIC, which of the video-carrying frames was lost= . That would require some frame numbering scheme. Some of that is probably = best left to the application, but at a minimum QUIC shall be able to respec= t frame boundaries. And that's probably easier if the data is sent in some = specialized RTP framing, rather than as regular STREAM DATA frames. Small comments: In section 4.2 " The loss of such a frame does not introduce state at the p= erceived receiver". If new streams are opened with higher stream ID, it im= plicitly opens this one frame stream that was lost in the receiver. I think= it still requires the sender to send a reliable FIN to close this stream. In the security section " An active, on path attacker can drop selected fra= mes " . What does it mean selected frames, the whole payload is encrypted. We probably need to assume that real time stream will be set up by the appl= ication, using something like SIP or RTSP in conjunction with SDP. The end = of the real time stream could also be signaled by the application in pretty= much the same way. Frankly, I don't think that we are ready to define RTP over QUIC right now,= as the priority is to finish the base spec. But what we can do is experime= nt with extension mechanism. For example, define an experiment in which QUI= C that can carry RTP, and verify that we can use the various extension mech= anisms to field that. We might learn something about these extension tools:= version numbers, transport parameter negotiation, maybe experimental frame= types. -- Christian Huitema --_000_266d61e546f64b549ceb87ef05945bc6usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think an alternat= ive to supporting a new packet transport within QUIC could be a new “= MIN_STREAM_DATA” frame.  This frame indicates that nothing below= this stream data offset will be retransmitted.

 

The application can= periodically call setMinStreamData(offset), respecting any in-stream messa= ge boundaries that makes sense for the application.  If all data up to= the offset has been acked, this is a noop. Otherwise, the transport drops any unacked bytes up to offset and sends MI= N_STREAM_DATA.  This way, an application does not need to create a str= eam-per-message, paying no penalty in the usual case of all data delivered = in time.

 

  • Igor

 

 

 

From:= Christian Huitema [mailto:huitema@huitema= .net]
Sent: Tuesday, November 07, 2017 5:35 PM
To: Roni Even <roni.even@huawei.com>; QUIC WG <quic@ietf.or= g>
Subject: Re: draft-tiesel-quic-unreliable-streams-01 - comments=

 

On 11/1/2017 6:03 AM, Roni Even wrote:

Hi,

 

I think support for unreliable streams is important = for unidirectional and bi-directional streams and even if it is V2 we still= need to take support for it into account. One use case is RTP over QUIC.


I used to think that too, but I wonder whether something like RTP in QUIC i= s best achieved by overloading the concept of streams, or by defining a com= pletely independent system, maybe using RTP and RTCP frame types instead of= regular streams types.

My main reason to say that is that regular stream data is more or less trea= ted as a byte stream, and RTP is not. The transport is free to send stream = data segments containing some of the stream's bytes, depending on flow cont= rol, multiplexing conditions, packet size, etc. In contrast, RTP data is sent as series of well delimited packe= ts, each packet corresponding to some well defined time slice of the media.= Whatever framing we use in QUIC will have to respect these packet boundari= es.

Another reason has to do with forward error correction, which is commonly a= pplied to large video frames sent over several packets. Many systems use pa= cket-erasure-correction schemes, which rely on correctly identifying which = packet was lost -- or, in QUIC, which of the video-carrying frames was lost. That would require some frame= numbering scheme. Some of that is probably best left to the application, b= ut at a minimum QUIC shall be able to respect frame boundaries. And that's = probably easier if the data is sent in some specialized RTP framing, rather than as regular STREAM DATA frames= .


 

Small comments:

 

In section 4.2 “ The loss of such a frame does= not introduce state at the perceived receiver”. If new streams are o= pened with higher stream ID,  it implicitly opens this one frame strea= m that was lost in the receiver. I think it still requires the sender to send a reliable FIN to close this stream.

 

In the security section “ An active, on path a= ttacker can drop selected frames “ . What does it mean selected frames, the whole p= ayload is encrypted.


We probably need to assume that real time stream will be set up by the appl= ication, using something like SIP or RTSP in conjunction with SDP. The end = of the real time stream could also be signaled by the application in pretty= much the same way.

Frankly, I don't think that we are ready to define RTP over QUIC right now,= as the priority is to finish the base spec. But what we can do is experime= nt with extension mechanism. For example, define an experiment in which QUI= C that can carry RTP, and verify that we can use the various extension mechanisms to field that. We might l= earn something about these extension tools: version numbers, transport para= meter negotiation, maybe experimental frame types.

-- Christian Huitema

--_000_266d61e546f64b549ceb87ef05945bc6usma1exdag1mb5msgcorpak_-- From nobody Tue Nov 7 23:15: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 8656D1314D5 for ; Tue, 7 Nov 2017 23:15:14 -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 bc8ll_OXcecl for ; Tue, 7 Nov 2017 23:15:12 -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 EE1651314F0 for ; Tue, 7 Nov 2017 23:14:46 -0800 (PST) X-AuditID: c1b4fb30-759ff70000007d10-61-5a02aee46a73 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 1E.9F.32016.4EEA20A5; Wed, 8 Nov 2017 08:14:45 +0100 (CET) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 8 Nov 2017 08:14:44 +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=B3Rxf0Z8LTcGdo8BhnRvXzMQOJgu5gy+SeJEj/5+J58=; b=TThVJjlW7GqYOfW4WflparF5g3/ELyZD3hiTihyh5QPKWgIzmsMOS1Lc5VprpAu9+J3jzVYakFr2A89kSZQ97d/9Dst1eQr2h2p1J7D3spVcI/RuK1cvVo9cNh7hZH+XL93sxE/iNDtHlKvtoae3F6D1I/K0Hl0gu3Rve+Fyyh0= 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_P256) id 15.20.218.6; Wed, 8 Nov 2017 07:14:42 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::d067:33bc:7c46:c8c9]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::d067:33bc:7c46:c8c9%13]) with mapi id 15.20.0218.005; Wed, 8 Nov 2017 07:14:42 +0000 From: Ingemar Johansson S To: "Philipp S. Tiesel" CC: Roni Even , QUIC WG Subject: RE: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Topic: draft-tiesel-quic-unreliable-streams-01 - comments Thread-Index: AQHTVznzaxwXVQFObkG5Q8JOBDTpHqMIg0wwgABLYwCAADCkgIAAIq6AgADxZlA= Date: Wed, 8 Nov 2017 07:14:42 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD82A735@DGGEMM506-MBS.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD832288@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8351F8@DGGEMM506-MBX.china.huawei.com> <7A7BC718-CA7C-4DF1-87DC-EB7C48B48C56@in-panik.de> In-Reply-To: <7A7BC718-CA7C-4DF1-87DC-EB7C48B48C56@in-panik.de> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 6:r/4dOSg6MKXtJSNCfzGgD5gNvZB3owbEV0OtRBejpdsNZXXI4ZKS0K9vidR3I5HpT2jgOV8ZwJb/R+kYccIN67/Dk2/I++otSvNHiB18aYHdcxcGXBEAgxkiw11U0NAyaWS6+EXl+eH+n8/4sTq4ornEN44fRAYFsmGs532f2L2r4Wro1KdkxO0M7xq73FuhGemdBn6LMwBHnNdY1KMH5CAl6gKUQQOZSf6o4uIHienWCDJhN+lS6qxbYpJq+OvTnb/DTSsIQAP320DBytws6ZjFA5PQ7ChPmyWrN8GiKgmEPppABBuxmBUPJpCtwbFABlrwe+Mqh5m/FMqeWbaJKkynkMwisoEhfp409C/MjTY=; 5:4Mdjv3JXQCoXL7Ukd6d+sJmjGIZTJ8En1tdJnCqwtxzllYraIca8HVux8w5GJkVI0CD4IFLymqsQ/xpt0EWlYEisLXIc/XINMCIXVlKSzMHrfC7w7s1koqdrel1vEq5GReXiWhV/pb0PTlyN9JH8ugftrSA6j5RkieGTsi28hp4=; 24:6WUY3JMGmrI9/yEZVIhR9w2jyGYN7ATdXIWiaEKKBuA2oVktsP7KvsVzmGtAMLg41syRxE5IltEA0iT4svooxUG+csv3WdPgKWx3PC28b4Q=; 7:SElgtUiWNFlJzEVGhFUpka0hYwn4wlhYzBsEamqje6sGbaOTjU6AJyn2nQnBTiXQH6w7H7AXP7qAGzrHsseEvFfSJ65Oj7PlDEZ2MrL0DTW4JpivBFoN8JNTI/LIKL9P2324c/5a79Dcsadnla4jMnOjIYkTszl60l5cH2AM8kXqr7mYV7zkc2xHi4LDVrI31aE5dbHnJNIX4Dozz3QwTQJdVaz9iPdjFKdVHKzN6IH2eq34fh96vBxgNKBnOvmk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6a84fe8b-5e9a-45d0-a613-08d526786230 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603249); SRVR:DB4PR07MB345; x-ms-traffictypediagnostic: DB4PR07MB345: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-exchange-antispam-report-test: UriScan:(37575265505322)(20558992708506)(278428928389397)(192374486261705)(50582790962513)(21748063052155)(17755550239193); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(3231021)(6041248)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB345; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB345; x-forefront-prvs: 0485417665 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(189002)(24454002)(199003)(106356001)(189998001)(2906002)(14454004)(478600001)(6506006)(55016002)(33656002)(68736007)(5660300001)(6246003)(50986999)(54356999)(74316002)(101416001)(6916009)(2950100002)(230783001)(25786009)(6306002)(54896002)(53546010)(229853002)(606006)(2900100001)(9686003)(6436002)(7696004)(105586002)(76176999)(236005)(53386004)(3660700001)(8676002)(19609705001)(3280700002)(81156014)(81166006)(6116002)(790700001)(3846002)(102836003)(97736004)(86362001)(54906003)(8936002)(99286004)(53936002)(316002)(93886005)(66066001)(7736002)(5250100002)(4326008); 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; 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_DB4PR07MB348CA1B22253E29FFF40BB7C2560DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6a84fe8b-5e9a-45d0-a613-08d526786230 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Nov 2017 07:14:42.6204 (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: H4sIAAAAAAAAA02Sa0iTYRTHfd7L9m41epyKR0uq4Qe1vKQRQmb6obCgCESQFeR0Lzqam2xm KhgSmqUtzSnN5XKQYWooaV4zcyuNPojhklDSpSleSDS7qCnStneB337n/P/nORcehhS/oP0Z hSqb1ahkSglPSNUkdwWGzrUQ0oiqO8LokoYWIvqeeU/02tAIFUcmFL1bphPq6zeJhKJPXpdI qTBGzioVOawmPDZFmKEfm0BZA1VE7sJSA1GIzDqiFAkYwMdhovMnXYqEjBi/RWCZXuJxwXsE k539lDOgsI6E6ld6glOqCegdf+qqF+OvCEaa5U7m4RhotK4jJ3vjIzBgfOJghiHxKVidkjrT Xvg0GIyDNGeJg8/FNorji/BwbtBlp3AgdPVGOtMiLIXtsmaKa/uMgta/i65ageOd4XIT38kI B4B9fcr1Dol9YWK2zr0ahvq+EZJjH1j8tkNzfAi2R2d4HAfAaF0ZcjYAbOGDfXrHLYRBx4Nl xPEF2KiuIjmTAUFP72O3EAwzFRskN0UarI3r3B1qHabfARwrwHzXzuOKR2morflFO9cEfADK F1IrUKhx1+Acq2FOv0MaXRfwhA81s5TRdcdgaO0N5yyHoapsms9xEBTXmvi782bEb0I+Wlab mpkeGRnGahRpWq1aFaZis9uQ4yNZXm5FdKPF+XgrwgyS7BXlGgipmJblaPMyrQgYUuItUl52 pERyWV4+q1Ff1VxXslor2s9QEl9RfP/HZDFOl2Wz11g2i9X8VwlG4F+IKu0pOR5+BWNBvqYh wfmzBUNpz/PnozpSjzbObrLnKkvC55LwSb2HhfLrSWz3NHX02DyqI07EXek+mGi1hfT5B7+2 GZZWfsRF6aRfBodXZ+TStTPSWDv/fsa+7yusxHj71qPSzqn8GZN3TNOfwK22yST25kroDf0b hUHdbqQDJJQ2Q3YshNRoZf8ATXJqV0QDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 08 Nov 2017 07:15:14 -0000 --_000_DB4PR07MB348CA1B22253E29FFF40BB7C2560DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0ssIHRoZW4gSSB1bmRlcnN0YW5kLg0KQW5vdGhlciBleGFtcGxlIG9mIGEgcG9zc2libGUgYXR0 YWNrIHZlY3RvciBpcyBuZWVkZWQgdGhlbiwgaWYgdGhlcmUgaXMgYW55IGNyZWRpYmxlIGV4YW1w bGUuDQoNCi9JbmdlbWFyDQoNCkZyb206IFBoaWxpcHAgUy4gVGllc2VsIFttYWlsdG86cGhpbHNA aW4tcGFuaWsuZGVdDQpTZW50OiBkZW4gNyBub3ZlbWJlciAyMDE3IDE3OjQ4DQpUbzogSW5nZW1h ciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+DQpDYzogUm9u aSBFdmVuIDxyb25pLmV2ZW5AaHVhd2VpLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpT dWJqZWN0OiBSZTogZHJhZnQtdGllc2VsLXF1aWMtdW5yZWxpYWJsZS1zdHJlYW1zLTAxIC0gY29t bWVudHMNCg0KSGksDQoNCnRoZSB3aG9sZSBwb2ludCBjYW1lIHVwIGluIHRoZSBzZWN1cml0eSBj b25zaWRlcmF0aW9ucyBvZiB0aGUgZHJhZnQ6DQoNCiAgICAgICAgICAgICAgSWYgb25lIHVzZXMg dW5yZWxpYWJsZSBzdHJlYW1zIGFzLWEtbWVzc2FnZSB0byBjdXQgZG93bg0KICAgICAgICAgICAg ICBkZWxheSwgaXQgaXMgYWxzbyBuZWNlc3NhcnkgdG8gc2VuZCB0aGVtIG91dCByaWdodCBhd2F5 DQogICAgICAgICAgICAgIGFuZCBkb27igJl0IHdhaXQgdW5pdCBhIE1UVS1zaXplZCBwYWNrZXQg aXMgZnVsbC4NCg0KICAgICAgICAgICAgICBEZXNwaXRlIGVuY3J5cHRpb24sIHRoaXMgYWxsb3dz IGFuIGF0dGFja2VyIHRvIGxlYXJuIGFib3V0IG1lc3NhZ2UNCiAgICAgICAgICAgICAgc2l6ZXMg YW5kLCBhc3N1bWluZyB0aGUgcHJvdG9jb2wgd2l0aGluIHRoZSBRVUlDIGNvbm5lY3Rpb24gaXMg a25vd24sDQogICAgICAgICAgICAgIG1pZ2h0IGFsbG93IGd1ZXNzaW5nIHdoYXQgbWVzc2FnZXMg d2VyZSB1c2VkLg0KDQogICAgICAgICAgICAgIE9uZSBfZXhhbXBsZV8gZm9yIHN1Y2ggYW4gYXR0 YWNrIHdhcyBhbiBoeXBvdGhldGljYWwgc3RyZWFtaW5nIHByb3RvY29sDQogICAgICAgICAgICAg IHdoaWNoIGFuIGF0dGFja2VyIGNhbiBkcm9wIGRlbGl2ZXJ5IHJlcG9ydHMgZm9yIGFuZCB0aHVz IGNvdWxkIGluZmx1ZW5jZQ0KICAgICAgICAgICAgICByYXRlIGFkYXB0aW9uLg0KDQpJIGNhbWUg dG8gdGhlIGNvbmNsdXNpb24gdGhpcyB3YXMgbm90IHRoZSBiZXN0IGV4YW1wbGUgZm9yIHRoZSBt ZXNzYWdlIGd1ZXNzaW5nIGF0dGFjay4NCg0KDQpPbiA3LiBOb3YgMjAxNywgYXQgMTU6NDcsIElu Z2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPG1haWx0 bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpIaQ0KDQpPSywg dGhlbiBJIHVuZGVyc3RhbmQsIG1heWJlLi4gU3RpbGwgZG9u4oCZdCBnZXQgaXQsIHNvcnJ5LiBJ ZiB5b3UgYXJlIGFib3V0IHRvIHNlbGVjdGl2ZWx5IGRpc2NhcmQgQUNLIHBhY2tldHMsIHRoZW4g dGhlIEFDSyBzcGFjaW5nIHdpbGwgYmVjb21lIGxhcmdlciBhbmQgdGhlIEFDSyBjbG9ja2luZyB3 aWxsIGJlIGRlZ3JhZGVkLiBUaGUgZW5kIGVmZmVjdCBpcyB0aGF0IGFsc28gdGhlIG1lZGlhIChv ciB3aGF0ZXZlcikgdGhhdCBjb25zdGl0dXRlIHRoZSBsYXJnZSBwYWNrZXRzIHdpbGwgYWxzbyBn ZXQgYSBkZWdyYWRlZCBwZXJmb3JtYW5jZSA/DQoNCkkgYXNzdW1lIHRoYXQgd2Ugd2lsbCBzdGls bCBiZSBydW5uaW5nIG9uZSBjb25nZXN0aW9uIGNvbnRyb2wgZm9yIHRoZSBjb25uZWN0aW9uID8N Cg0KL0luZ2VtYXINCg0KRnJvbTogUm9uaSBFdmVuIFttYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5j b21dDQpTZW50OiBkZW4gNyBub3ZlbWJlciAyMDE3IDEyOjUwDQpUbzogSW5nZW1hciBKb2hhbnNz b24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb208bWFpbHRvOmluZ2VtYXIucy5q b2hhbnNzb25AZXJpY3Nzb24uY29tPj47IFBoaWxpcHAgUy4gVGllc2VsIDxwaGlsc0Bpbi1wYW5p ay5kZTxtYWlsdG86cGhpbHNAaW4tcGFuaWsuZGU+Pg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5v cmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IGRyYWZ0LXRpZXNlbC1xdWlj LXVucmVsaWFibGUtc3RyZWFtcy0wMSAtIGNvbW1lbnRzDQoNCkhpIEluZ2VtYXIsDQpJdCBpcyBu b3QgQ0NNIHRoZSBhdHRhY2tlciBqdXN0IGRvZXMgaGV1cmlzdGljcyB0byB1bmRlcnN0YW5kIHRo YXQgdGhpcyBpcyBub3QgbWVkaWEgYnV0IHJlcG9ydCAoUlRDUCBvciBBQ0sgZnJhbWVzKSBhbmQg ZHJvcHMgaXQsIEJUVzogYXVkaW8gcGFja2V0cyBtYXkgYWxzbyBiZSBzbWFsbC4NClRoaXMgaXMg YW4gZXhhbXBsZS4gVGhlIGNsYWltIGlzIHRoYXQgeW91IGNhbiB1c2UgaGV1cmlzdGljcyB0byBk cm9wIOKAnHNlbGVjdGVk4oCdIGZyYW1lcyBldmVuIHRob3VnaCB5b3UgZG8gbm90IGtub3cgd2hh dCBpcyBpbiB0aGUgcGFja2V0Lg0KUm9uaQ0KDQoNCg0KRnJvbTogSW5nZW1hciBKb2hhbnNzb24g UyBbbWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tXQ0KU2VudDog15nXlded INeSIDA3INeg15XXkdee15HXqCAyMDE3IDA5OjQxDQpUbzogUGhpbGlwcCBTLiBUaWVzZWw7IFJv bmkgRXZlbg0KQ2M6IFFVSUMgV0cNClN1YmplY3Q6IFJFOiBkcmFmdC10aWVzZWwtcXVpYy11bnJl bGlhYmxlLXN0cmVhbXMtMDEgLSBjb21tZW50cw0KDQpIaSBQaGlsaXAgYW5kIFJvbmkNCg0KSSBh c3N1bWUgdGhhdCBieSByZWNlcHRpb24gcmVwb3J0cyBpcyBtZWFudCB0aGUgUlRDUCBDQ00gbWVz c2FnZXMgc3VjaCBhcyBUTU1CUiBvciA/DQoNClNvLi4gdW5sZXNzIEkgbWlzdW5kZXJzdG9vZCBp dCBjb21wbGV0ZWx5Lg0KSSBhbSBub3QgYXQgYWxsIGNvbnZpbmNlZCB0aGF0IG1lZGlhIHJhdGUv Y29uZ2VzdGlvbiBjb250cm9sIGluIFFVSUMgc2hvdWxkIHJlbHkgb24gVE1NQlIuDQpTQ1JlQU0g Zm9yIGluc3RhbmNlLCBzcGVjaWZpZWQgaW4gdGhlIFJNQ0FUIFdHIGZvciBpbnN0YW5jZSBkb2Vz IG5vdCBkZXBlbmQgb24gVE1NQlIgYXMgaXQgaXMgQUNLIGNsb2NrZWQsIHRoZSBtZWRpYSB0cmFu c21pc3Npb24gaXMgcmVkdWNlZCB0byBhIHZlcnkgbG93IHJhdGUgaWYgdGhlIEFDS3MgYXJlIGRp c2NhcmRlZCBieSBhbiBhdHRhY2tlci4NCg0KSSB3b3VsZCBzYXkgdGhhdCBpdCBpcyBtb3JlIHN0 cmFpZ2h0Zm9yd2FyZCB0byB1c2UgYSBtdWx0aXB1cnBvc2UgY29uZ2VzdGlvbiBjb250cm9sIGlu IFFVSUMsIHRoaXMgaXMgcGVyaGFwcyBiYXNlZCBvbiBCQlIsIGJ1dCBTQ1JlQU0gc3R5bGUgaXMg bm90IGV4Y2x1ZGVkLiBJbiBhbnkgY2FzZSB0aGlzIG1lYW5zIHRoYXQgaXQgaXMgbm90IHBvc3Np YmxlIHRvIHByZXZlbnQgcmF0ZSBhZGFwdGF0aW9uLg0KDQovSW5nZW1hcg0KDQoNCkZyb206IFBo aWxpcHAgUy4gVGllc2VsIFttYWlsdG86cGhpbHNAaW4tcGFuaWsuZGVdDQpTZW50OiBkZW4gNiBu b3ZlbWJlciAyMDE3IDEwOjE1DQpUbzogUm9uaSBFdmVuIDxyb25pLmV2ZW5AaHVhd2VpLmNvbTxt YWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20+Pg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IGRyYWZ0LXRpZXNlbC1xdWljLXVu cmVsaWFibGUtc3RyZWFtcy0wMSAtIGNvbW1lbnRzDQoNCg0KDQpPbiA1LiBOb3YgMjAxNywgYXQg MDg6MzIsIFJvbmkgRXZlbiA8cm9uaS5ldmVuQGh1YXdlaS5jb208bWFpbHRvOnJvbmkuZXZlbkBo dWF3ZWkuY29tPj4gd3JvdGU6DQpGcm9tOiBQaGlsaXBwIFMuIFRpZXNlbCBbbWFpbHRvOnBoaWxz QGluLXBhbmlrLmRlXQ0KT24gMS4gTm92IDIwMTcsIGF0IDE0OjAzLCBSb25pIEV2ZW4gPHJvbmku ZXZlbkBodWF3ZWkuY29tPG1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KSW4g dGhlIHNlY3VyaXR5IHNlY3Rpb24g4oCcIEFuIGFjdGl2ZSwgb24gcGF0aCBhdHRhY2tlciBjYW4g ZHJvcCBzZWxlY3RlZA0KZnJhbWVzIOKAnCAuIFdoYXQgZG9lcyBpdCBtZWFuIHNlbGVjdGVkIGZy YW1lcywgdGhlIHdob2xlIHBheWxvYWQgaXMNCmVuY3J5cHRlZC4NClRoaXMgaXMgYSBsaXR0bGUg Y29tcGxpY2F0ZWQ6DQotIEFzc3VtZSBoYXZpbmcg4oCcc3RyZWFtLWFzLWEtbWVzc2FnZeKAnSBz dHJlYW1zIHdpdGggdHdvIGRpZmZlcmVudCBraW5zIG9mDQptZXNzYWdlcyBzaXplZCBBLEINCi0g QXNzdW1lIGVhY2ggbWVzc2FnZSBmaXRzIGludG8gb25lIHBhY2tldCwgYnV0IHR3byBtZXNzYWdl cyB3aWxsIG5vdCBmaXQNCi0gQXNzdW1lIG9uZSBkb2Vzbid0IHdhbnQgdG8gc3BsaXQgcGFja2V0 cyB0byBmaWxsIHBhY2tldHMgdG8gTVRVIGR1ZSB0bw0KbGF0ZW5jeSBjb25zdHJhaW5zICA9PiBJ ZiBhbiBhdHRhY2tlciBrbm93IHRoZSBpbnNpZGUgcHJvdG9jb2wsIHRoZSBhdHRhY2tlcg0KY2Fu IGRpc3Rpbmd1aXNoIGZyb20gdGhlIHBhY2tldCBsZW5ndGggd2V0aGVyIGl0IGlzIGFuIEEgb3Ig QiBraW5kIG1lc3NhZ2UNCg0KVG8gYXZvaWQgdGhpcywgb25lIGhhcyB0byBwYWQgYWxsIHBhY2tl dHPigKYgSSBzaG91bGQgY2xhcmlmeSB0aGlzLg0KW1JvbmkgRXZlbl0gSSB1bmRlcnN0YW5kIHRo aXMgY2FzZSBidXQgd2hhdCBkb2VzIHNlbGVjdGVkIGZyYW1lcyBtZWFuLCBJIGFzc3VtZSB0aGF0 IHRoZSBhdHRhY2tlciBkb2VzIG5vdCBrbm93IHdoYXQgaXMgaW4gZWFjaCBzdHJlYW0gaW4gb3Jk ZXIgdG8gc2VsZWN0IGEgc3BlY2lmaWMgb25lLCBzbyB3aHkgd2lsbCBoZSBqdXN0IGRyb3Agb25l IGFuZCBub3QgdGhlIG90aGVyIG9yIHdoeSBub3QgYm90aD8NCg0KQXNzdW1pbmcgdGhlIGF0dGFj a2VyIF9rbm93cyB0aGUgcHJvdG9jb2xfLCB0aGUgYXR0YWNrZXIgd291bGQgYWxzbyBrbm93IHRo ZSBzaXplcyBvZiBhbGwga2luZHMgb2YgbWVzc2FnZXMgYW5kIG1heSB1c2UgdGhpcyBrbm93bGVk Z2UgdG8gcmVjb3ZlciBwcm90b2NvbCBzdGF0ZSBvciBzZWxlY3RpdmVseSBkcm9wIG1lc3NhZ2Vz Lg0KDQpGb3IgYSBwcm90b2NvbCBsaWtlIEhUVFAsIHRoZSBhdHRhY2sgdmVjdG9yIGlzIHJhdGhl ciBzbWFsbC4NCklmIG9uZSB1c2VzIHRoaXMgYWdhaW5zdCB2aWRlbyBjb25mZXJlbmNpbmcgYXBw bGljYXRpb25zLCBhbiBhdHRhY2tlciBjb3VsZCBwcmV2ZW50IHJhdGUgYWRhcHRpb24gIGJ5IGRy b3BwaW5nIHJlY2VwdGlvbiByZXBvcnRzIChsYXJnZXIgdGhhbiBhIHB1cmUgUVVJQyBBQ0ssIHNt YWxsZXIgdGhhbiBhIHZpZGVvIGZyYW1lKS4NCklmIG9uZSB1c2VzIHRoaXMgb24gSW9UIGNvbnRy b2wgc3R1ZmYsIGFuIGF0dGFja2VyIG1pZ2h0IGJlIGFibGUgdG8gbGVhcm4gYSBsb3QgYWJvdXQg dGhlIHN5c3RlbSBzdGF0ZSBieSBvYnNlcnZpbmcgc2l6ZXMgYW5kIHRpbWluZ3MuDQoNClRoaXMg aXMgbm90aGluZyB3ZSBjYW4gZml4IHdpdGhpbiBRVUlDIHdpdGhvdXQgbWFzc2l2ZSBzY2FyaWZp ZXMsIGJ1dCBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIG11c3Qga2VlcCBpbiBtaW5kLg0KDQoNCkFW RSENCiAgUGhpbGlwcCBTLiBUaWVzZWwgLyBwaGlsc+KApg0KLS0NCiAgIHtwaGlsc30tLS0+LS0t KHBoaWxzQGluLXBhbmlrLmRlPG1haWx0bzpwaGlsc0Bpbi1wYW5pay5kZT4pLS0tPi0tLShodHRw Oi8vcGhpbHMuaW4tcGFuaWsuZGU8aHR0cDovL3BoaWxzLmluLXBhbmlrLmRlLz4pLS0tLSwNCiAg ICAgIHdlbm4gdyBlaW5lICAgYXViZSBpc3QgZG4gICAgICBtYW4gYXUgZHJhbiBkcmUgZW4gICAg ICAgICAgICAgICAgICAgfA0KICAgICAgICAgICBvICAgICBTY2hyICAgICAgICBhbiBtdXNzICAg ICBoYyAgICAgICAgIGggICAoS3VydCBTY2h3aXR0ZXJzKSB8DQo6d3EhICA8LS0tLShwaG9uZTog KzQ5LTE3OS02NzM3NDM5KS0tLTwtLS0oamFiYmVyOiBwaGlsc0Bpbi1wYW5pay5kZTxtYWlsdG86 cGhpbHNAaW4tcGFuaWsuZGU+KS0tLS0nDQoNCkFWRSENCiAgUGhpbGlwcCBTLiBUaWVzZWwgLyBw aGlsc+KApg0KLS0NCiAgIHtwaGlsc30tLS0+LS0tKHBoaWxzQGluLXBhbmlrLmRlPG1haWx0bzpw aGlsc0Bpbi1wYW5pay5kZT4pLS0tPi0tLShodHRwOi8vcGhpbHMuaW4tcGFuaWsuZGUpLS0tLSwN CiAgICAgIHdlbm4gdyBlaW5lICAgYXViZSBpc3QgZG4gICAgICBtYW4gYXUgZHJhbiBkcmUgZW4g ICAgICAgICAgICAgICAgICAgfA0KICAgICAgICAgICBvICAgICBTY2hyICAgICAgICBhbiBtdXNz ICAgICBoYyAgICAgICAgIGggICAoS3VydCBTY2h3aXR0ZXJzKSB8DQo6d3EhICA8LS0tLShwaG9u ZTogKzQ5LTE3OS02NzM3NDM5KS0tLTwtLS0oamFiYmVyOiBwaGlsc0Bpbi1wYW5pay5kZTxtYWls dG86cGhpbHNAaW4tcGFuaWsuZGU+KS0tLS0nDQoNCg== --_000_DB4PR07MB348CA1B22253E29FFF40BB7C2560DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sby1SZWd1bGFy Ow0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBj bTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1 bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNw YW47fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUt Y29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBl cnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJX b3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0ssIHRoZW4gSSB1bmRlcnN0YW5k LiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFub3RoZXIgZXhhbXBsZSBv ZiBhIHBvc3NpYmxlIGF0dGFjayB2ZWN0b3IgaXMgbmVlZGVkIHRoZW4sIGlmIHRoZXJlIGlzIGFu eSBjcmVkaWJsZSBleGFtcGxlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4vSW5nZW1hciA8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRk aW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUGhpbGlwcCBTLiBUaWVzZWwgW21h aWx0bzpwaGlsc0Bpbi1wYW5pay5kZV0gPGJyPg0KPGI+U2VudDo8L2I+IGRlbiA3IG5vdmVtYmVy IDIwMTcgMTc6NDg8YnI+DQo8Yj5Ubzo8L2I+IEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0O2luZ2Vt YXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gUm9uaSBFdmVu ICZsdDtyb25pLmV2ZW5AaHVhd2VpLmNvbSZndDs7IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBkcmFmdC10aWVzZWwtcXVpYy11bnJlbGlhYmxl LXN0cmVhbXMtMDEgLSBjb21tZW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50 aGUgd2hvbGUgcG9pbnQgY2FtZSB1cCBpbiB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgb2Yg dGhlIGRyYWZ0OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyA8L3NwYW4+SWYgb25lIHVzZXMgdW5yZWxpYWJsZSBzdHJlYW1zIGFzLWEtbWVzc2FnZSB0byBj dXQgZG93bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gY2xhc3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9z cGFuPmRlbGF5LCBpdCBpcyBhbHNvIG5lY2Vzc2FyeSB0byBzZW5kIHRoZW0gb3V0IHJpZ2h0IGF3 YXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5h bmQgZG9u4oCZdCB3YWl0IHVuaXQgYSBNVFUtc2l6ZWQgcGFja2V0IGlzIGZ1bGwuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNz PSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5EZXNwaXRlIGVu Y3J5cHRpb24sIHRoaXMgYWxsb3dzIGFuIGF0dGFja2VyIHRvIGxlYXJuIGFib3V0IG1lc3NhZ2U8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5zaXpl cyBhbmQsIGFzc3VtaW5nIHRoZSBwcm90b2NvbCB3aXRoaW4gdGhlIFFVSUMgY29ubmVjdGlvbiBp cyBrbm93biw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwv c3Bhbj5taWdodCBhbGxvdyBndWVzc2luZyB3aGF0IG1lc3NhZ2VzIHdlcmUgdXNlZC48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gY2xh c3M9ImFwcGxlLXRhYi1zcGFuIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPk9uZSBfZXhh bXBsZV8gZm9yIHN1Y2ggYW4gYXR0YWNrIHdhcyBhbiBoeXBvdGhldGljYWwgc3RyZWFtaW5nIHBy b3RvY29sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8L3Nw YW4+d2hpY2ggYW4gYXR0YWNrZXIgY2FuIGRyb3AgZGVsaXZlcnkgcmVwb3J0cyBmb3IgYW5kIHRo dXMgY291bGQgaW5mbHVlbmNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBjbGFzcz0iYXBwbGUtdGFiLXNwYW4iPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA8L3NwYW4+cmF0ZSBhZGFwdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjYW1lIHRvIHRoZSBjb25jbHVzaW9uIHRoaXMg d2FzIG5vdCB0aGUgYmVzdCBleGFtcGxlIGZvciB0aGUgbWVzc2FnZSBndWVzc2luZyBhdHRhY2su PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIDcuIE5vdiAyMDE3LCBhdCAxNTo0NywgSW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj5pbmdlbWFyLnMuam9o YW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T0ssIHRoZW4gSSB1bmRlcnN0YW5kLCBtYXliZS4uIFN0 aWxsIGRvbuKAmXQgZ2V0IGl0LCBzb3JyeS4gSWYgeW91IGFyZSBhYm91dCB0byBzZWxlY3RpdmVs eSBkaXNjYXJkIEFDSyBwYWNrZXRzLCB0aGVuIHRoZSBBQ0sgc3BhY2luZyB3aWxsIGJlY29tZSBs YXJnZXIgYW5kIHRoZSBBQ0sgY2xvY2tpbmcgd2lsbCBiZSBkZWdyYWRlZC4gVGhlIGVuZCBlZmZl Y3QgaXMgdGhhdCBhbHNvIHRoZSBtZWRpYSAob3Igd2hhdGV2ZXIpDQogdGhhdCBjb25zdGl0dXRl IHRoZSBsYXJnZSBwYWNrZXRzIHdpbGwgYWxzbyBnZXQgYSBkZWdyYWRlZCBwZXJmb3JtYW5jZSA/ PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGFzc3VtZSB0 aGF0IHdlIHdpbGwgc3RpbGwgYmUgcnVubmluZyBvbmUgY29uZ2VzdGlvbiBjb250cm9sIGZvciB0 aGUgY29ubmVjdGlvbiA/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJvbmkgRXZlbiBbPGEgaHJlZj0ibWFpbHRvOnJvbmku ZXZlbkBodWF3ZWkuY29tIj5tYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb208L2E+XTxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50Ojwv Yj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ZGVuIDcg bm92ZW1iZXIgMjAxNyAxMjo1MDxicj4NCjxiPlRvOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+SW5nZW1hciBKb2hhbnNzb24gUyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tIj5pbmdlbWFyLnMuam9o YW5zc29uQGVyaWNzc29uLmNvbTwvYT4mZ3Q7OyBQaGlsaXBwIFMuIFRpZXNlbCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlIj5waGlsc0Bpbi1wYW5pay5kZTwvYT4mZ3Q7PGJy Pg0KPGI+Q2M6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj5RVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlJFOiBkcmFmdC10aWVzZWwtcXVpYy11bnJlbGlhYmxl LXN0cmVhbXMtMDEgLSBjb21tZW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPkhpIEluZ2VtYXIsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkl0IGlzIG5v dCBDQ00gdGhlIGF0dGFja2VyIGp1c3QgZG9lcyBoZXVyaXN0aWNzIHRvIHVuZGVyc3RhbmQgdGhh dCB0aGlzIGlzIG5vdCBtZWRpYSBidXQgcmVwb3J0IChSVENQIG9yIEFDSyBmcmFtZXMpIGFuZCBk cm9wcyBpdCwgQlRXOiBhdWRpbyBwYWNrZXRzIG1heSBhbHNvIGJlIHNtYWxsLjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJjb2xvcjojMUY0OTdEIj5UaGlzIGlzIGFuIGV4YW1wbGUuIFRoZSBjbGFpbSBpcyB0aGF0 IHlvdSBjYW4gdXNlIGhldXJpc3RpY3MgdG8gZHJvcCDigJxzZWxlY3RlZOKAnSBmcmFtZXMgZXZl biB0aG91Z2ggeW91IGRvIG5vdCBrbm93IHdoYXQgaXMgaW4gdGhlIHBhY2tldC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Um9uaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxzcGFuIHN0eWxlPSJjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJp ZiI+SW5nZW1hcg0KIEpvaGFuc3NvbiBTIFs8YSBocmVmPSJtYWlsdG86aW5nZW1hci5zLmpvaGFu c3NvbkBlcmljc3Nvbi5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPm1haWx0bzppbmdl bWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbTwvc3Bhbj48L2E+XTxzcGFuIGNsYXNzPSJhcHBs ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8Yj5TZW50OjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIGxh bmc9IkhFIiBkaXI9IlJUTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPteZ15XXnSZuYnNwO9eSIDA3INeg15XXkdee15HX qCAyMDE3IDA5OjQxPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5Ubzo8L2I+PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlBoaWxpcHAgUy4gVGll c2VsOyBSb25pIEV2ZW48YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlFVSUMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UkU6IGRyYWZ0LXRpZXNl bC1xdWljLXVucmVsaWFibGUtc3RyZWFtcy0wMSAtIGNvbW1lbnRzPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGkgUGhpbGlwIGFuZCBSb25pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYXNzdW1lIHRoYXQgYnk8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHU+cmVjZXB0aW9uPC91PjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5yZXBvcnRzIGlzIG1lYW50IHRoZSBS VENQIENDTSBtZXNzYWdlcyBzdWNoIGFzIFRNTUJSIG9yID88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28uLiB1bmxlc3MgSSBtaXN1bmRlcnN0 b29kIGl0IGNvbXBsZXRlbHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGFtIG5vdCBhdCBhbGwgY29udmluY2VkIHRoYXQgbWVkaWEgcmF0ZS9j b25nZXN0aW9uIGNvbnRyb2wgaW4gUVVJQyBzaG91bGQgcmVseSBvbiBUTU1CUi48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNDUmVBTSBmb3IgaW5z dGFuY2UsIHNwZWNpZmllZCBpbiB0aGUgUk1DQVQgV0cgZm9yIGluc3RhbmNlIGRvZXMgbm90IGRl cGVuZCBvbiBUTU1CUiBhcyBpdCBpcyBBQ0sgY2xvY2tlZCwgdGhlIG1lZGlhIHRyYW5zbWlzc2lv biBpcyByZWR1Y2VkIHRvIGEgdmVyeSBsb3cgcmF0ZSBpZiB0aGUgQUNLcyBhcmUgZGlzY2FyZGVk IGJ5IGFuIGF0dGFja2VyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHdvdWxkIHNheSB0aGF0IGl0IGlzIG1vcmUgc3RyYWlnaHRmb3J3YXJk IHRvIHVzZSBhIG11bHRpcHVycG9zZSBjb25nZXN0aW9uIGNvbnRyb2wgaW4gUVVJQywgdGhpcyBp cyBwZXJoYXBzIGJhc2VkIG9uIEJCUiwgYnV0IFNDUmVBTSBzdHlsZSBpcyBub3QgZXhjbHVkZWQu IEluIGFueSBjYXNlIHRoaXMgbWVhbnMgdGhhdCBpdCBpcyBub3QgcG9zc2libGUgdG8gcHJldmVu dCByYXRlIGFkYXB0YXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6 MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj48c3BhbiBjbGFzcz0iYXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+UGhpbGlwcCBTLiBUaWVzZWwgWzxhIGhyZWY9 Im1haWx0bzpwaGlsc0Bpbi1wYW5pay5kZSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFp bHRvOnBoaWxzQGluLXBhbmlrLmRlPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJh cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5kZW4gNiBub3ZlbWJlciAyMDE3IDEw OjE1PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5Sb25pIEV2ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpyb25pLmV2ZW5AaHVhd2Vp LmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cm9uaS5ldmVuQGh1YXdlaS5jb208L3Nw YW4+PC9hPiZndDs8YnI+DQo8Yj5DYzo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1z cGFjZSI+Jm5ic3A7PC9zcGFuPlFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYu b3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5xdWljQGlldGYub3JnPC9zcGFuPjwvYT4m Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+Jm5ic3A7PC9zcGFuPlJlOiBkcmFmdC10aWVzZWwtcXVpYy11bnJlbGlhYmxlLXN0cmVhbXMt MDEgLSBjb21tZW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQi PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIDUuIE5vdiAyMDE3LCBhdCAwODozMiwgUm9uaSBFdmVuICZsdDs8YSBocmVmPSJtYWls dG86cm9uaS5ldmVuQGh1YXdlaS5jb20iPjxzcGFuIHN0eWxlPSJjb2xvcjpwdXJwbGUiPnJvbmku ZXZlbkBodWF3ZWkuY29tPC9zcGFuPjwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt YXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpz dGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90 OyxzZXJpZiI+RnJvbTogUGhpbGlwcCBTLiBUaWVzZWwgWzxhIGhyZWY9Im1haWx0bzpwaGlsc0Bp bi1wYW5pay5kZSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+bWFpbHRvOnBoaWxzQGluLXBh bmlrLmRlPC9zcGFuPjwvYT5dPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OyxzZXJpZiI+T24g MS4gTm92IDIwMTcsIGF0IDE0OjAzLCBSb25pIEV2ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpyb25p LmV2ZW5AaHVhd2VpLmNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cm9uaS5ldmVuQGh1 YXdlaS5jb208L3NwYW4+PC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9i bG9ja3F1b3RlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LHNlcmlm Ij5JbiB0aGUgc2VjdXJpdHkgc2VjdGlvbiDigJwgQW4gYWN0aXZlLCBvbiBwYXRoIGF0dGFja2Vy IGNhbiBkcm9wIHNlbGVjdGVkPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1S ZWd1bGFyJnF1b3Q7LHNlcmlmIj5mcmFtZXMg4oCcIC4gV2hhdCBkb2VzIGl0IG1lYW4gc2VsZWN0 ZWQgZnJhbWVzLCB0aGUgd2hvbGUgcGF5bG9hZCBpczxicj4NCmVuY3J5cHRlZC48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1 bGFyJnF1b3Q7LHNlcmlmIj5UaGlzIGlzIGEgbGl0dGxlIGNvbXBsaWNhdGVkOjxicj4NCi0gQXNz dW1lIGhhdmluZyDigJxzdHJlYW0tYXMtYS1tZXNzYWdl4oCdIHN0cmVhbXMgd2l0aCB0d28gZGlm ZmVyZW50IGtpbnMgb2Y8YnI+DQptZXNzYWdlcyBzaXplZCBBLEI8YnI+DQotIEFzc3VtZSBlYWNo IG1lc3NhZ2UgZml0cyBpbnRvIG9uZSBwYWNrZXQsIGJ1dCB0d28gbWVzc2FnZXMgd2lsbCBub3Qg Zml0PGJyPg0KLSBBc3N1bWUgb25lIGRvZXNuJ3Qgd2FudCB0byBzcGxpdCBwYWNrZXRzIHRvIGZp bGwgcGFja2V0cyB0byBNVFUgZHVlIHRvPGJyPg0KbGF0ZW5jeSBjb25zdHJhaW5zICZuYnNwOz0m Z3Q7IElmIGFuIGF0dGFja2VyIGtub3cgdGhlIGluc2lkZSBwcm90b2NvbCwgdGhlIGF0dGFja2Vy PGJyPg0KY2FuIGRpc3Rpbmd1aXNoIGZyb20gdGhlIHBhY2tldCBsZW5ndGggd2V0aGVyIGl0IGlz IGFuIEEgb3IgQiBraW5kIG1lc3NhZ2U8YnI+DQo8YnI+DQpUbyBhdm9pZCB0aGlzLCBvbmUgaGFz IHRvIHBhZCBhbGwgcGFja2V0c+KApiBJIHNob3VsZCBjbGFyaWZ5IHRoaXMuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo4LjVwdDtmb250LWZhbWlseTomcXVvdDtNZW5s by1SZWd1bGFyJnF1b3Q7LHNlcmlmIj5bUm9uaSBFdmVuXSBJIHVuZGVyc3RhbmQgdGhpcyBjYXNl IGJ1dCB3aGF0IGRvZXMgc2VsZWN0ZWQgZnJhbWVzIG1lYW4sIEkgYXNzdW1lIHRoYXQgdGhlIGF0 dGFja2VyIGRvZXMgbm90IGtub3cgd2hhdCBpcyBpbiBlYWNoIHN0cmVhbSBpbiBvcmRlciB0byBz ZWxlY3QgYSBzcGVjaWZpYyBvbmUsIHNvDQogd2h5IHdpbGwgaGUganVzdCBkcm9wIG9uZSBhbmQg bm90IHRoZSBvdGhlciBvciB3aHkgbm90IGJvdGg/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzc3VtaW5nIHRoZSBhdHRhY2tlciBfa25v d3MgdGhlIHByb3RvY29sXywgdGhlIGF0dGFja2VyIHdvdWxkIGFsc28ga25vdyB0aGUgc2l6ZXMg b2YgYWxsIGtpbmRzIG9mIG1lc3NhZ2VzIGFuZCBtYXkgdXNlIHRoaXMga25vd2xlZGdlIHRvIHJl Y292ZXIgcHJvdG9jb2wgc3RhdGUgb3Igc2VsZWN0aXZlbHkgZHJvcCBtZXNzYWdlcy48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIGEgcHJvdG9jb2wgbGlrZSBIVFRQLCB0aGUgYXR0YWNr IHZlY3RvciBpcyByYXRoZXIgc21hbGwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiBvbmUgdXNlcyB0aGlzIGFnYWlu c3QgdmlkZW8gY29uZmVyZW5jaW5nIGFwcGxpY2F0aW9ucywgYW4gYXR0YWNrZXIgY291bGQgcHJl dmVudCByYXRlIGFkYXB0aW9uICZuYnNwO2J5IGRyb3BwaW5nIHJlY2VwdGlvbiByZXBvcnRzIChs YXJnZXIgdGhhbiBhIHB1cmUgUVVJQyBBQ0ssIHNtYWxsZXIgdGhhbiBhIHZpZGVvIGZyYW1lKS48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPklmIG9uZSB1c2VzIHRoaXMgb24gSW9UIGNvbnRyb2wgc3R1ZmYsIGFuIGF0dGFj a2VyIG1pZ2h0IGJlIGFibGUgdG8gbGVhcm4gYSBsb3QgYWJvdXQgdGhlIHN5c3RlbSBzdGF0ZSBi eSBvYnNlcnZpbmcgc2l6ZXMgYW5kIHRpbWluZ3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlRoaXMgaXMgbm90aGluZyB3ZSBjYW4gZml4IHdpdGhpbiBRVUlDIHdpdGhvdXQgbWFzc2l2ZSBz Y2FyaWZpZXMsIGJ1dCBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIG11c3Qga2VlcCBpbiBtaW5kLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ QVZFITxicj4NCiZuYnNwOyBQaGlsaXBwIFMuIFRpZXNlbCAvIHBoaWxz4oCmPGJyPg0KLS0mbmJz cDs8YnI+DQombmJzcDsgJm5ic3A7e3BoaWxzfS0tLSZndDstLS0oPGEgaHJlZj0ibWFpbHRvOnBo aWxzQGluLXBhbmlrLmRlIj48c3BhbiBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsc0Bpbi1wYW5p ay5kZTwvc3Bhbj48L2E+KS0tLSZndDstLS0oPGEgaHJlZj0iaHR0cDovL3BoaWxzLmluLXBhbmlr LmRlLyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cDovL3BoaWxzLmluLXBhbmlrLmRl PC9zcGFuPjwvYT4pLS0tLSw8YnI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyB3ZW5uIHcgZWluZSAm bmJzcDsgYXViZSBpc3QgZG4gJm5ic3A7ICZuYnNwOyAmbmJzcDttYW4gYXUgZHJhbiBkcmUgZW4g Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgfDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7byAm bmJzcDsgJm5ic3A7IFNjaHIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW4gbXVzcyAmbmJz cDsgJm5ic3A7IGhjICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBoICZuYnNwOyAoS3VydCBT Y2h3aXR0ZXJzKSB8PGJyPg0KOndxISAmbmJzcDsmbHQ7LS0tLShwaG9uZTogJiM0Mzs0OS0xNzkt NjczNzQzOSktLS0mbHQ7LS0tKGphYmJlcjo8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNw YWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlIj48c3Bh biBzdHlsZT0iY29sb3I6cHVycGxlIj5waGlsc0Bpbi1wYW5pay5kZTwvc3Bhbj48L2E+KS0tLS0n PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+QVZFITxicj4NCiZu YnNwOyBQaGlsaXBwIFMuIFRpZXNlbCAvIHBoaWxz4oCmPGJyPg0KLS0mbmJzcDs8YnI+DQombmJz cDsgJm5ic3A7e3BoaWxzfS0tLSZndDstLS0oPGEgaHJlZj0ibWFpbHRvOnBoaWxzQGluLXBhbmlr LmRlIj5waGlsc0Bpbi1wYW5pay5kZTwvYT4pLS0tJmd0Oy0tLSg8YSBocmVmPSJodHRwOi8vcGhp bHMuaW4tcGFuaWsuZGUiPmh0dHA6Ly9waGlscy5pbi1wYW5pay5kZTwvYT4pLS0tLSw8YnI+DQom bmJzcDsgJm5ic3A7ICZuYnNwOyB3ZW5uIHcgZWluZSAmbmJzcDsgYXViZSBpc3QgZG4gJm5ic3A7 ICZuYnNwOyAmbmJzcDttYW4gYXUgZHJhbiBkcmUgZW4gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7byAmbmJzcDsgJm5ic3A7IFNjaHIgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7YW4gbXVzcyAmbmJzcDsgJm5ic3A7IGhjICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyBoICZuYnNwOyAoS3VydCBTY2h3aXR0ZXJzKSB8PGJyPg0KOndxISAm bmJzcDsmbHQ7LS0tLShwaG9uZTogJiM0Mzs0OS0xNzktNjczNzQzOSktLS0mbHQ7LS0tKGphYmJl cjogPGEgaHJlZj0ibWFpbHRvOnBoaWxzQGluLXBhbmlrLmRlIj4NCnBoaWxzQGluLXBhbmlrLmRl PC9hPiktLS0tJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_DB4PR07MB348CA1B22253E29FFF40BB7C2560DB4PR07MB348eurprd_-- From nobody Thu Nov 9 09:53: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 529C1127005 for ; Thu, 9 Nov 2017 09:53:32 -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 J0torLcLGB8z for ; Thu, 9 Nov 2017 09:53:30 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 8A534126D45 for ; Thu, 9 Nov 2017 09:53:30 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id s66so3638033wmf.2 for ; Thu, 09 Nov 2017 09:53: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=E7PY9Y4Q+ol2FY0h69Rpb2smpZir/zgaRFYhqrYrgNk=; b=tACHWV2LPdl/x1BCMOl/AeSaLShNs/4Bco1h94XsStU7v3O/sLPVmJYeCutfqA+ThP 3YfCFzHACVIw4ZL/LTpvcth2Oiztg6xQsmAJCwwTsAYty4QPxTih7AWqpARhnRtOvyGE rzq3GZ9AL/sGSYInvLuNZCxRb6ALSRNpPI4Bfu5Xu8nOWbzisTEo8gDCxsv2lCTPaeXT EXmYBx5/msFyRn7fYiBDUXMQqpssVQB3WqXitGNkPJ9NRRGY8XeCn4V22KYteeyJVNV7 2QXQoGDPxERuYGNGU0LhhIq0pXe1Ny4OkcL38okmA3/4D8hhR01614SKsTFyAsdDh0yQ vBpw== 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=E7PY9Y4Q+ol2FY0h69Rpb2smpZir/zgaRFYhqrYrgNk=; b=nRiEWXx5MPVnM7JK2TrD4/1DzqFrK0DipNZmw8gCLVlmh0+wTLHrcCcEywSLTZXsXI gmUw+GSG0MRx5hC6CtByAC8zl54hWbudirtvQxK4yCV4xjGhqy8quhW6ht42YUaCVd6X 3/HayK7MzdRUK2pEulKe3aXSBm4cFub/FAh75DUteKUZss9wrEeISaXXKOejCQwX1B7v vWdCklsBRkCCXn+p/zt4J9YqyZy3GmPVsHyvHEaYZqx/e4WNU0uzNIV53f40EUk/Im0c 3Jyd4ySHyUBq6zOfVsEpuw6aoSGMywUimd9REudk3ezqtMMQZ6gGxyGtwdhtiwdLFq3l f+bA== X-Gm-Message-State: AJaThX6DndRd6Wr3iV2aLScmQa8oA3lLj/k5RbflywRWJbk5xsA3vbIC Ro4WB0t/VLcCoZ+vWrDggiy0sH1O80Np+rMm2zXeVA== X-Google-Smtp-Source: ABhQp+TmWQNrXHFgiJnaL8d9oFDliZOf+9jyLCT8WtR1v74/IDD2CpbbhJueQzTaLiN5TqaU2YDTDmDz0auBMxwLn38= X-Received: by 10.28.231.10 with SMTP id e10mr520305wmh.1.1510250009066; Thu, 09 Nov 2017 09:53:29 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.135.82 with HTTP; Thu, 9 Nov 2017 09:53:28 -0800 (PST) From: Martin Duke Date: Thu, 9 Nov 2017 09:53:28 -0800 Message-ID: Subject: Issues to Punt To: "Eggert, Lars" , Mark Nottingham Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e082f84b45000b3055d907bff" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 17:53:32 -0000 --089e082f84b45000b3055d907bff Content-Type: text/plain; charset="UTF-8" Lars and Mark, I generated issues #269 , #279 , and #602 around explicit middlebox signaling. While I think measurement and management issues will arise without these improvements, I agree that we can have a functioning protocol without them.Therefore, I am content to give these issues a "v2" label and reopen them if the concerns materialize in the real world. Martin Duke --089e082f84b45000b3055d907bff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lars and Mark,

I generated issues #269, #279, and #602 around expli= cit middlebox signaling. While I think measurement and management issues wi= ll arise without these improvements, I agree that we can have a functioning= protocol without them.Therefore, I am content to give these issues a "= ;v2" label and reopen them if the concerns materialize in the real wor= ld.

Martin Duke
--089e082f84b45000b3055d907bff-- From nobody Fri Nov 10 11:27: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 6748C1293D8 for ; Fri, 10 Nov 2017 11:27:36 -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=litespeedtech-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 wU-kRkz0XYno for ; Fri, 10 Nov 2017 11:27:34 -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 11B8512008A for ; Fri, 10 Nov 2017 11:27:34 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id a142so13184782qkb.5 for ; Fri, 10 Nov 2017 11:27:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to:user-agent; bh=oYEMSL/IIRx4gWaxi6mDnuDHEbBdJVBu1+EODLqWyts=; b=1G7ECDuN38nz7fcClr3ZPC7/+XAk6WWUKmV2sVMs1VCSPgpXCpNYnw0bn1nFHSL8LN FFo0dSB4o2yYXw/IsdWfoLMLbNqkvWl+l6ij2OtNyNJNqQ0SA0VrcUXZRx2BQuj0YMFV pkCanKQ1BX1QR3pnAXE5glVGT4bwRwxaQpV4ZHcpzVKPBmqHAKSTuQMLmyZjdB5K3hp7 L7MMzTOpqy6gKzGk2mQcQabqrxv6Mr/voWy5Oig/X39sM8GMBAXVcXi9UVtj75xCUGPr NcdXhtjXdeByO/shPY5GVJ5NvB6P41s1xMxGh+hONp3g5UVjjfwOncMJroeaWDtaQONf M8Gw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to:user-agent; bh=oYEMSL/IIRx4gWaxi6mDnuDHEbBdJVBu1+EODLqWyts=; b=pGDRx+QPh9omwY/vbSoN3uAmOc9FCTjA+wIev7iq66jBwaFNBs7O0uvhlM6wvG+CGG 5yNzyOKvXRYZIg8FiFm4JZe35BBptknSL7Cwhyw1KnXUTKVW2v4QcnYBEACTbjPedFGM INBM3wfcJzStg1NklGfkcLGgOSaHUiMsfhtJhz8IrPN6Jsxjmvs6V1YB62phrNV5m/nc 98atv07MpGlmbsWH2h7g8m8EmlPe97JahX1y639x2LTqlVRBwC9ZVYMhi28MCdn8N9OQ 3pxWs9edagmCnv296Xo3ZGcvl3OtnGsy9iRCF0S4ka0M6XZWMbCp26u+K/NrnzbEuD5A ffnA== X-Gm-Message-State: AJaThX5fj4TTC8SVfLdCJnqyZoIXtcDxqSTA/Lzs+oc51AjG6be12URz VNRlXukH+FNotsHJCHdxGbG9IR5i X-Google-Smtp-Source: AGs4zMapvOR3NzSg4ok31wHYP2M1/Ns/f3MxfIDepYgs6rwvzKAMuJh2Z2g4O1Y4V9WTMm6ZuaIoxA== X-Received: by 10.55.88.2 with SMTP id m2mr2324874qkb.260.1510342052942; Fri, 10 Nov 2017 11:27:32 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id c16sm6877249qtd.57.2017.11.10.11.27.32 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 10 Nov 2017 11:27:32 -0800 (PST) Date: Fri, 10 Nov 2017 14:27:27 -0500 From: Dmitri Tikhonov To: IETF QUIC WG Subject: Re: QMIN: Header Compression for QUIC Message-ID: <20171110192726.GA11074@ubuntu-dmitri> Mail-Followup-To: IETF QUIC WG References: <20171107155917.GA17613@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171107155917.GA17613@ubuntu-dmitri> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 19:27:36 -0000 Hello, Here are proof-of-concept QMIN encoder and decoder along with the test program: https://github.com/litespeedtech/qmin/tree/master/src The code demonstrates viability of QMIN as header compression protocol for QUIC. In particular: - QMIN solves the HoL problem; - The compression logic is mostly contained in the encoder, keeping the decoder simple; - QMIN is transport-independent; and - Memory penalty over HPACK is manageable. QMIN encoder and decoder (qmin_enc.c and qmin_dec.c) are based on LSQUIC Client Library's HPACK implementation. The test program (test-enc.c) is a driver for a single encoder-decoder pair. It performs stream creation, encoding of header fields, decoding of header fields by the decoder (including their validation), and it emulates the control channel sending QMIN control messages back and forth. test-enc usage: -E Trace encoder execution -D Trace decoder execution -s Dump encoder and decoder states. The following information is printed: - Current compression level; - Memory used, both real and the QMIN table size; - List of all dynamic table entries and their reference counts; and - List of all checkpoints along with their stream and entry references. -c CAP Specify maximum table capacity. The default is 64K. -r SEED Finish random stream instead of always the last one. SEED specifies the seed for repeatable run The new code (not the HPACK core) is optimized for readability rather than performance. Encoder's flushing and eviction strategies are not the best, but they are OK as far as the proof-of-concept is concerned. The messages informing the encoder of streams being done are faked in test-enc.c (as it is really not the job of the decoder to know when a stream is done). Feel free to comment, open GitHub issues, and so on. - Dmitri. 1. https://github.com/litespeedtech/lsquic-client/tree/master/src/liblsquic On Tue, Nov 07, 2017 at 10:59:17AM -0500, Dmitri Tikhonov wrote: > Here is yet another header compression proposal: > > https://github.com/litespeedtech/qmin/blob/master/id-qmin.txt > > QMIN is a compression format and protocol for HTTP/2 > headers. QMIN is based on HPACK. The modifications to > HPACK are meant to allow robust compression use in QUIC: > That is, no head-of-line blocking and low overhead. QMIN > is guided by HPACK design principles. It inherits all of > HPACK's data structures and retains binary compatibility > with it. While designed with QUIC in mind, QMIN can be > used in other contexts. > > Because IETF draft submission is disabled until November 12th, > my proposal is hosted on GitHub. I will make a formal submission > when the submission tool is reopened. > > In the meantime, any feedback is welcome. > > Thank you, > > - Dmitri. From nobody Sun Nov 12 18:43: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 EEBAA126C83 for ; Sun, 12 Nov 2017 18:43:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 qWi_B02OJ7Cu for ; Sun, 12 Nov 2017 18:43:20 -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 1E70A128CD5 for ; Sun, 12 Nov 2017 18:42:34 -0800 (PST) X-AuditID: c1b4fb2d-2ec699c000001e3d-e3-5a0906990cbf Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.21.07741.996090A5; Mon, 13 Nov 2017 03:42:33 +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.352.0; Mon, 13 Nov 2017 03:41:39 +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=z9zWWyFFe8wCZVZghaKjqyD4eu4sfTTyl2iWEKej+W8=; b=iI8KwWbfVSf9YgVGnuPvd5gbPMITqIb3Nfwwt/1imj0jJWR/+ZoxGPX7xkPKuu3TPQ/WJ2UL7F+cPw1cNBtbz4qaGaKf69LIFCXQJQp9Cmy33mBoR2pUyubAVQ3ZYYq6xeF4icLOKHq6BZosSj57XZzj8cg7lxK/oViA1pqbweo= Received: from DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) by DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 02:41:37 +0000 Received: from DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::a11b:f467:276f:c8c0]) by DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::a11b:f467:276f:c8c0%15]) with mapi id 15.20.0239.004; Mon, 13 Nov 2017 02:41:37 +0000 From: Ingemar Johansson S To: QUIC WG CC: "emile.stephan@orange.com" , "subirdas21@gmail.com" , "Bob Briscoe (research@bobbriscoe.net)" , "Mirja Kuehlewind (IETF)" , Ian Swett , "'ietf@trammell.ch'" , "Jana Iyengar (jri@google.com)" , Christian Huitema , "De Schepper, Koen (Koen)" , Marcus Ihlar Subject: ECN in QUIC side meeting Thread-Topic: ECN in QUIC side meeting Thread-Index: AdNcJeSRBc3+lOqHQKK/vPXn1O/anQ== Date: Mon, 13 Nov 2017 02:41:37 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [2001:67c:1232:144:69dd:b3e9:f80c:63ec] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DBXPR07MB351; 6:9hd1ZIW/o2B8jVJSNCCd6FiUbIA+GJ4j97WgyZPVllztnOWREDhd8W/x92+qjX2rXrEjFVEEwL2F2CNgmDUvHH3zVrvVdhCpL9UZhGlwCEzC5sosJKSvEVgOJI6t1Ed7ia3f5b0AJq4KAAs8XlzKkJAcpDP1rqekUgvqdEQikl3J3LC4JFVyYVs41hCC7bJKQFws9Z35lKkXCgsBIjgkIs0EvE6unEw9Bef0WDGAjNGGCVMmEMus2bRY52Zu20un1ACDy3f+UPw+QWVsnQMSQ5oFvN75LeHg0o7dlIgv0t83GvcgytWxB1Fw8+bWR/9EagJhsiroznpe9TkaGiJj7t/TiX+rTEyJsF7x0o9xqTc=; 5:5Isk9gCMvoIuJwYAQYhxx1YYYT6t+a1MLuLKk/aZye/l0QXSxBjCDJhw5Niohvysryo5KbnZ75sUDszdQIIgh3UXFMZ+j8TGghWEY0XUqKKo/Bj0vi8Ir89m1N2nfYHh0LqlM5FW/wreZEN0fn8j7sKr+OkGH0sPZuumxn/wTXE=; 24:FjyZrsFhogEilDl5Tb+O6uEP94CGqvVPqRJR/8xB6mKYCGmgryFB34sD1C1N29js/1zWp/ygd3pBErO8uxXdxOnkE8oMM1/aCr+AHQ63M2w=; 7:KchHBGgD9kLtC8NWTc8jy6Rnp1MW5RnN2qVnfxaQRYhVDiOCL62DjviG6nV6UKjpaKGiu8B1tD9OKlg9kfUKga5cPNQwYz7wO1wiDHSWbKxbCaZFJYxhuJkgNRW74bot2ilQqDB8wVnX56KPmWAXq4hMEpJkjBBcz8VSUNb7DJXKZXOBfrpV16kF8eI7WnFMMZdhbCEAhHVWSVPZaP/WayQevsi5YHFT+4jqb5QzaZpN6pRhuLssQ+vCY8G3DYO1 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(376002)(346002)(199003)(189002)(9326002)(966005)(3660700001)(2900100001)(101416001)(25786009)(5250100002)(50986999)(4326008)(105586002)(7696004)(54356999)(8936002)(68736007)(7416002)(8656006)(561944003)(53936002)(33656002)(790700001)(106356001)(102836003)(6116002)(5660300001)(3280700002)(236005)(478600001)(99286004)(97736004)(6506006)(2906002)(81156014)(9686003)(55016002)(6436002)(8676002)(316002)(81166006)(54906003)(606006)(86362001)(7736002)(19609705001)(6916009)(74316002)(107886003)(54896002)(39060400002)(14454004)(189998001)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB351; H:DBXPR07MB351.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: aa5a5750-2204-47b4-0515-08d52a400fb8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DBXPR07MB351; x-ms-traffictypediagnostic: DBXPR07MB351: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(60409825278598)(202460600054446)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(3231022)(93006095)(93001095)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DBXPR07MB351; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DBXPR07MB351; x-forefront-prvs: 0490BBA1F0 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_DBXPR07MB351E2227BCA5ACF934CC5BEC22B0DBXPR07MB351eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: aa5a5750-2204-47b4-0515-08d52a400fb8 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 02:41:37.1847 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB351 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Se0hTURzHO7v37t6tBrc185cvaFCUspUpdS0te1jrjyiQIPZHNfJivqbs mmT2x8qkWgpaapsVag0jbVga5TKWLguT6WxkPvCBD7Ky1yS0qCS3Y+B/n/v9fM8593c4DCH/ QQUxKfps3qDXpSvFUtJy5EmCyiKWaDfWmFdxrc9/kty1czdo7tewneI+9HoJ7uGFr2Lu6stq khvp/ExxhVVLudHy84grbamh46WaTyPdlMZeMURrqhpOaQbMHaTGav0l0lzwVlOaoQHPPL1/ LdZMPLeQhyRaaWwSn56Swxs2bD8uPel29aCsJ7Gnay7PEEb0Z7MJSRhgo6HA4yFMSMrI2RcI xsqbCZ+Qs+0IbrpTfUyyRQQY65bjUqkI2i4/RvhjFEHHG5PI1xKzsXDPOYt8rGCDoeG+V+wr Eew0AQ8ba2mfWMGuhp7vHQQurYWXn8pIzGr49qqFxMetgUtNDv9GMlYLvzuN/hyxoTAyO+xn gg2EgYlKEZ6BBeszN4E5AD6Oz1G4fwKm+4sonMeAZ7ZwoRMKnsor/gmAbaXh41D+gogCU/Ez CotJCmyOOhqLA5DfbyexMCPomrmOsFgPlWWDJOYUcBR9Wfils/C4sY/GCzwUTLkcCwtCYPxd CY2vmIe7tgJUjCIqFo2EOROunWtGFf4rWA6vLRMkztXQV1YqxhwBNdVTBGYVmOec5OK8CtG1 KEDgBSEjeVOUmjeknBCETL1az2c3oPm32Prot6oJ1U3tdCKWQcplsrSvjFZO6XKE3AwnAoZQ KmRtI/ORLEmXe4Y3ZB4znErnBScKZkhloCze0X1Ezibrsvk0ns/iDf+tiJEEGVFSnDY3IvV2 IxtamJHws+focJzp/raIgPrRuqJdJWjrYIH8ZqJisnTJwK3NFnesOno3s8X2fjA6cvBixtDe 066ormCiPhC8u/SJYQdD8sLre9v7jtUW5qW5Wu6Y9+21O9V/H9gOP43br1oZH3Lc2la19W3M mGIuep3re8KeMFXiDiUpnNRFhhMGQfcPVPi3TIcDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 02:43:22 -0000 --_000_DBXPR07MB351E2227BCA5ACF934CC5BEC22B0DBXPR07MB351eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I would like to propose that we, that is anybody interested in getting ECN = support in QUIC, meet this week to discuss the details and a way forward to= wards the ultimate goal to get this to happen. Something of a proposal is already written up in https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC I created a doodle where you can add your preference https://doodle.com/poll/dupqc7bv6dmha6ra /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson Research Network Protocols & E2E Performance Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com The world is full of magical things patiently waiting for our wits to grow sharper Bertrand Russell =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DBXPR07MB351E2227BCA5ACF934CC5BEC22B0DBXPR07MB351eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

I would like to propose that we, that is anybody int= erested in getting ECN support in QUIC, meet this week to discuss the detai= ls and a way forward towards the ultimate goal to get this to happen.<= /o:p>

Something of a proposal is already written up in

https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC

 

I created a doodle where you can add your preference=

https://doodle.com/poll/dupqc7bv6dmha6ra

 

/Ingemar

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

Ingemar Joh= ansson  M.Sc.

Master Researcher<= /o:p>

 

Ericsson Research<= /o:p>

Network Protocols &= E2E Performance

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson= @ericsson.com

www.ericsson.com

 

The world is full of magical things patiently

    waiting for our wits to grow sharper

           &= nbsp;   Bertrand Russell
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

 

--_000_DBXPR07MB351E2227BCA5ACF934CC5BEC22B0DBXPR07MB351eurprd_-- From nobody Mon Nov 13 02: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 E09AD1294EF for ; Mon, 13 Nov 2017 02:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 mkh_2DvNyjfL for ; Mon, 13 Nov 2017 02:28:42 -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 1CE481273B1 for ; Mon, 13 Nov 2017 02:28:41 -0800 (PST) X-AuditID: c1b4fb2d-f0bff70000001e3d-20-5a0973d83e58 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AB.8F.07741.8D3790A5; Mon, 13 Nov 2017 11:28:40 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.48) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 13 Nov 2017 11:28:39 +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=GqHFjXbJ8rhAph1SI0WqQgaYigJq5YFo9vO9uS2svok=; b=nNEc0tTIUOUvbHpxENniS+d+kroqJdJfoS96W1Q9C86p9BZoNI4sRWZ80YoMdrVk3hquTglIkG0rvJmfX6mRWEyU6pxBNv7tDk3zJx4uA0knZxuKUciHuLhJ3KthhJahgVzoClL2Qzb3uaCVVnEf0cmPkutvMPhzj0r4YmZogic= Received: from DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) by DBXPR07MB349.eurprd07.prod.outlook.com (10.141.12.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 10:28:38 +0000 Received: from DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::a11b:f467:276f:c8c0]) by DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::a11b:f467:276f:c8c0%15]) with mapi id 15.20.0239.004; Mon, 13 Nov 2017 10:28:38 +0000 From: Ingemar Johansson S To: QUIC WG Subject: RE: ECN in QUIC side meeting Thread-Topic: ECN in QUIC side meeting Thread-Index: AdNcJeSRBc3+lOqHQKK/vPXn1O/anQAQnO/g Date: Mon, 13 Nov 2017 10:28:38 +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: [31.133.138.247] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DBXPR07MB349; 6:p0jBZwzcEeoOWd1AwruVu7uIr0QvMeX42ukKwZzED6QQQ+S9yntkFq9Fb5dhg7vVcUWbv3OFpAWENoCq0mvMmFwxdaX90pVYKIx535Sn/PcR71knBbDVYWjUK2nqG5ss8aMq7iYV+xD8rpLsolBMcY7g8GcP8YRDs9R0zt+y5PYiy5maz518QFFVDq1upaND0W3FYfbOJ/SdL9UU0iKdwoscJH2HS72AiBxLEXCh3sMZ+PW3b9Ejva6LqLmZsq5XIiRRd7oZdaeme7NaJqRUlcKNl7XjkFiOQGftOBvOClWn5ibS8J3vzXb2BJG+SIWsd5HDb6uzNlzUU8mCCrHm5QD5TKBT6ViLqq3rGHrYMaI=; 5:QBwn3+9IwjmwJZXB281I2/W1gZoBTIOZELn8GFFfWgDT02JDu3qq1JBsk9beuMhy6KqiaRtj5lCAoUKYXAp+r6tjeiRfNafeYmzD6F7ONXU6XRi9g/VEWY87ha1qaX8bxQmlk5husiC5cUt2nKtp3nYtOPpGUoNHgAMtlWX6Tl4=; 24:Q+OWa9C76xodvM4QG88pc89Zm1Pw0inMAc51VkO2makJ4jM/+c2sEF25SqR07sMdHxhxnYAmrcGdDJtE6RDzm3/JOj4BwrqvtSRseaad5/w=; 7:glBW058g2VvGU/Fbvivc7LtBLE21GjO8S962FtX7zOGLeqfPkNwdeBBxuu58uZ9melvg2y+SaizkylfeFVfMSpB/VcuEfhKZTXAx5JQQelJmAVi77Z2BPsYSRlXGpL+LrqZnXem7ZMzTN+jrY0jY/54OPnUlYWs3Gya9p/qHmsSYLUZQThTrviY9qLgsKCLmkw3lfGdJVk/awSmQXMQ7U4ZBsVoDm+6WfBF6Nxws1GOWeiQ8rfdP3rKvB8Dd7YHU x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: edf8e209-e3c1-4add-74ac-08d52a814ded x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DBXPR07MB349; x-ms-traffictypediagnostic: DBXPR07MB349: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(82608151540597)(60409825278598)(211936372134217)(202460600054446)(153496737603132)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(3231022)(920507027)(10201501046)(6041248)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DBXPR07MB349; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DBXPR07MB349; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(189002)(199003)(2900100001)(3660700001)(5250100002)(14454004)(229853002)(189998001)(6436002)(2906002)(99286004)(86362001)(6506006)(81166006)(81156014)(105586002)(9326002)(66066001)(3280700002)(53936002)(106356001)(2950100002)(6246003)(8936002)(6916009)(19609705001)(50986999)(236005)(68736007)(5660300001)(53546010)(966005)(76176999)(54356999)(790700001)(102836003)(6116002)(74316002)(97736004)(3846002)(8676002)(55016002)(34040400001)(6306002)(54896002)(9686003)(7696004)(316002)(101416001)(25786009)(33656002)(561944003)(7736002)(606006)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB349; H:DBXPR07MB351.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: multipart/alternative; boundary="_000_DBXPR07MB351A6042F15BEC85A46505CC22B0DBXPR07MB351eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: edf8e209-e3c1-4add-74ac-08d52a814ded X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 10:28:38.7629 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB349 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sb0hTURjGO7t3291scFqar5pFI/ujbakV9UHEpEApyYhAZ6DD3XQ1N9s1 a/nFtLCcmgOXc2hOEENTIfFPVExcSlqCzlCXZCJapuIHJbNhWNvuAr/9nud9znve93AoQlzL DaZUmjxap1GoJTwhWZPSEyl1MgJ5pKUCzpRZ/eJQQmOji5OM5MIYJa1W5dO647EZwmzH0CaZ +1J9d+mjjSxECxmlSEABPgmGZ4NEKRJSYvwOgeF+nU8MIvg5V831CBKXE/BtrNpXqeLAZJOZ z4pZBI6n8xxPMx6OgWb7BvKwPw6BjtZVXimiqN04DAa69Kx9CAaWTCTL0WCp6fbGSXdk0zlM eFiE5dD/qITwHBW7udh40WMLcBo0r0554wiHwszGV28bAgfC1Hw9h10HQ+PbEYLlAFic2+Ky +UxY+1zO9bQELIEvCwVsJBTG6g2I5T4+2I1hLMugy7ji85OgyVVLerYFbEYw0O7gsYWjMGtd 9d2lgr8jbRw2ZEPwftLMY8U0F9Zaq33T7YW5CSOf5T9c+GSOr0THLNuWsLgHJLAWvg/zLd6n 2AVDNfMkG5GB01TFYzkCmhqWCZalYN6yk9t9K+K3oACGZpicrOgTMlqnymQYrUamofM6kPvP 9HVuSl+hF8tn7QhTSLJTxLsskIu5inxGn2NHQBESf1HRBbclUir092idNl13W00zdhRCkZJA UZxtNEWMsxR59E2azqV1/6scShBciDSvzz1IvPKhtk427pd80BkrY049Tmmv7C9LFzRkJlYv 7ftVdCnqyHnZ+kOie0Yl+hGxnjthOny1RXl/XdMb1BvnCu5L0Ha+KTag8D0RTpS0ckCvtrWM tt24bh0POn3NYZC3/5beKUmdvBWlXJx+nhpfYNpRYnzi6lwJ6BFUpO2XkEy2Iiqc0DGKfyV+ dE0vAwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:28:45 -0000 --_000_DBXPR07MB351A6042F15BEC85A46505CC22B0DBXPR07MB351eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Seems like we already now have a winner. All of the doodlers so far have selected the time slot 16.00-17.00 on Thurs= day, which means that I hereby decide that we'll pick that slot. I will try to arrange with a meeting room. A wiki on the subject is already in place https://github.com/quicwg/base-dr= afts/wiki/ECN-in-QUIC For those of you who attend, a few short questions to consider 1. Do the proposed ECN fields look OK ? 2. ECN in dedicated ACK frame, is this OK ? * If yes, should the timestamps be baked in the same ACK frame 3. ECN capability exchange already at connection setup, for or against ? 4. Is it time to add this to the QUIC transport draft ? /Ingemar From: Ingemar Johansson S Sent: den 13 november 2017 10:42 To: QUIC WG Cc: 'emile.stephan@orange.com' ; 'subirdas21@gmai= l.com' ; Bob Briscoe (research@bobbriscoe.net) ; 'Mirja Kuehlewind (IETF)' ; Ian S= wett ; 'ietf@trammell.ch' ; Jana Iye= ngar (jri@google.com) ; Christian Huitema ; De Schepper, Koen (Koen) ; Marcus Ihlar <= marcus.ihlar@ericsson.com> Subject: ECN in QUIC side meeting Hi I would like to propose that we, that is anybody interested in getting ECN = support in QUIC, meet this week to discuss the details and a way forward to= wards the ultimate goal to get this to happen. Something of a proposal is already written up in https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC I created a doodle where you can add your preference https://doodle.com/poll/dupqc7bv6dmha6ra /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson Research Network Protocols & E2E Performance Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com The world is full of magical things patiently waiting for our wits to grow sharper Bertrand Russell =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DBXPR07MB351A6042F15BEC85A46505CC22B0DBXPR07MB351eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

Seems like we already now have a winner. =

All of the doodlers so far have selected the time sl= ot 16.00-17.00 on Thursday, which means that I hereby decide that we’= ll pick that slot.
I will try to arrange with a meeting room.

 

A wiki on the subject is already in place https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC

For those of you who attend, a few short questions t= o consider

  1. Do the proposed ECN fields look OK ?
  2. ECN in dedicated ACK frame, is this OK ?
    1. If yes, should the timestamps be baked in the same ACK frame
  3. ECN capability exchange already at connection setup, for or agai= nst ?
  4. Is it time to add this to the QUIC transport dra= ft ?

 

/Ingemar

 

From: Ingemar Johansson S
Sent: den 13 november 2017 10:42
To: QUIC WG <quic@ietf.org>
Cc: 'emile.stephan@orange.com' <emile.stephan@orange.com>; 'su= birdas21@gmail.com' <subirdas21@gmail.com>; Bob Briscoe (research@bob= briscoe.net) <research@bobbriscoe.net>; 'Mirja Kuehlewind (IETF)' <= ;ietf@kuehlewind.net>; Ian Swett <ianswett@google.com>; 'ietf@trammell.ch' <ietf@trammell.ch>; Jana Iyengar (jri@google.com)= <jri@google.com>; Christian Huitema <huitema@huitema.net>; De = Schepper, Koen (Koen) <koen.de_schepper@nokia.com>; Marcus Ihlar <= marcus.ihlar@ericsson.com>
Subject: ECN in QUIC side meeting

 

Hi

I would like to propose that we, that is anybody int= erested in getting ECN support in QUIC, meet this week to discuss the detai= ls and a way forward towards the ultimate goal to get this to happen.<= /o:p>

Something of a proposal is already written up in

https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC

 

I created a doodle where you can add your preference=

https://doodle.com/poll/dupqc7bv6dmha6ra

 

/Ingemar

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

Ingemar Joh= ansson  M.Sc.

Master Researcher<= /o:p>

 

Ericsson Research<= /o:p>

Network Protocols &= E2E Performance

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

The world is full of magical things patiently

    waiting for our wits to grow sharper

           &= nbsp;   Bertrand Russell
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

 

--_000_DBXPR07MB351A6042F15BEC85A46505CC22B0DBXPR07MB351eurprd_-- From nobody Mon Nov 13 02:53: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 653F2129485 for ; Mon, 13 Nov 2017 02:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 HAt8KYQRHnbD for ; Mon, 13 Nov 2017 02:53:46 -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 24F34128CF0 for ; Mon, 13 Nov 2017 02:53:45 -0800 (PST) X-AuditID: c1b4fb30-a25ff70000002554-14-5a0979b87c12 Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id CC.44.09556.8B9790A5; Mon, 13 Nov 2017 11:53:44 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.63) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 13 Nov 2017 11:53:43 +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=w9dCtdYVcG41u7E1bIjxIti+1JIES2QwnpYkXmPR834=; b=IP+rmg01nDSIf1d1ojQ+o6J+y7yFWc0275nsuA1FBUn1SHx9+RCAE0B4Qt3k3awMAY3P+WwiGitdE9qm7itNHFlolWItxnBFtTI0pBwiL3lXOL2n6kcn/URDv+Xq8Dxd4lW7T1Ew3MUd4usvIeNMv6Dgd+7+UYrOBCsaFQOhK8w= Received: from DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) by DBXPR07MB351.eurprd07.prod.outlook.com (10.141.12.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Mon, 13 Nov 2017 10:53:42 +0000 Received: from DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::a11b:f467:276f:c8c0]) by DBXPR07MB351.eurprd07.prod.outlook.com ([fe80::a11b:f467:276f:c8c0%15]) with mapi id 15.20.0239.004; Mon, 13 Nov 2017 10:53:42 +0000 From: Ingemar Johansson S To: Ingemar Johansson S , QUIC WG Subject: RE: ECN in QUIC side meeting Thread-Topic: ECN in QUIC side meeting Thread-Index: AdNcJeSRBc3+lOqHQKK/vPXn1O/anQAQnO/gAAFUiYA= Date: Mon, 13 Nov 2017 10:53:42 +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: [31.133.138.247] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DBXPR07MB351; 6:Ptw1z31LXlx+N8djSM6U3/RpEaf0udSoR9m2fh5rqTTG3dKfYOMfW2/w+jx7UHEyFH3TBu0ZvPAkfk+yeaD9E05ZejdnjwEFbvaIEX97KPQcBvAROvPNd174QL1Cm2tiTDV8oTsZVnYzmb7vR6lMFHckJFYql9f0bVCnLQHmJ0gZsVVfZbYA0rcCIw2w2TtSDDYcDYtUo6BHatw9b67st4aIg69yHGtsMblpIHYq97mc8l2HcPAdMOdhFY+PCFF0/fTj6SeSiUbI1uWmGqybBkTGTDZILxBoBQckq63MqDjsTe/O28LJ6Dgpw5TFlIAfMAo5Twg87yeaL+bFPf9V4pQ6Z4EEll/Va9ftW5TWNNk=; 5:nFfAK8HbMO7h6+CFfzwaMjCxBGR67ZOuza1zun1vfNWRxqp0uaKHPnG+38Ih8eIyyrECwIN7Rg9YrJpRXPdfaRZLLOqJb6HRJKD6y24zmOoqly1TwtVEN/cq4A7Pqmpor5jGEz0XzBSMk1qXmv5fI0Cmo0lC7aq5jgBDI3E9Y3o=; 24:U45+X3ZN7FNnHmQZJkG1rY1lpKMNjAmsE5QCFCY9i0AQwgmAoCir5AOG0hDofK5DvMEUHZNTLLP0bKOX3kYjn9N/Gusb7Wsam6mKPe8j3aA=; 7:m0kOUz+X13ndmyoO00SQBQgTumBheImTZfML6VzZ1Jpb6OVzdzVmlVRFtDPI5CXyxvLaEsRvpk1U/KHBqdBX59Mju+ipNnhTp7a8jijagyvZviKETFX+SDPsn26dTdGf9Xvti7DTvkS77y/0TbQSjHkJJB8K03lv8fvdEO5paS8+MYNyO3Tw/FxdvIogq7DsO6C4yE6E3mHdawFaty2LQw2euhlTMdsfuZukH9KrffPl8YjFIoAd3z59cMYsDD+D x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(346002)(39860400002)(376002)(189002)(199003)(9686003)(81156014)(66066001)(110136005)(6436002)(316002)(8676002)(55016002)(53546010)(478600001)(3280700002)(236005)(99286004)(2906002)(6506006)(97736004)(34040400001)(74316002)(2950100002)(19609705001)(14454004)(6306002)(6246003)(189998001)(86362001)(7736002)(606006)(54896002)(81166006)(7696004)(5250100002)(105586002)(8936002)(50986999)(68736007)(54356999)(966005)(229853002)(3660700001)(9326002)(25786009)(101416001)(2900100001)(790700001)(5660300001)(3846002)(33656002)(53936002)(106356001)(102836003)(6116002)(76176999)(561944003); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR07MB351; H:DBXPR07MB351.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 61def439-3d90-4a3c-deb0-08d52a84cdf8 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DBXPR07MB351; x-ms-traffictypediagnostic: DBXPR07MB351: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(82608151540597)(60409825278598)(211936372134217)(202460600054446)(153496737603132)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3231022)(920507027)(93006095)(93001095)(3002001)(10201501046)(100000703101)(100105400095)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DBXPR07MB351; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DBXPR07MB351; x-forefront-prvs: 0490BBA1F0 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_DBXPR07MB35149A11955E02FD1937A23C22B0DBXPR07MB351eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 61def439-3d90-4a3c-deb0-08d52a84cdf8 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 10:53:42.1075 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DBXPR07MB351 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sf0hTURTHuXtv29tqcTXNgyXCUKFSU4voh5UGWhCiEIlMKKe+dKZO33S1 JDAhpelMw+UPkBmK5SSQ0DKVmYulIcwsbc5mKhpiGZlIQxTJ5zXwv8/5fr/nHM7lMpRno9CX UeUWsFyuMlsuktL1Sa8vhHTrJIqw5VL/UxVNe6LQ5ZaWNUECUkgj09lslZbljp1PkWbWv2mi 80bv3en9Y0HFyJynRwwD+ASYKz30SMJ44ncIZk1ZeiTd4iEEjt82IV/Q2EDBcPkDIXFqBLCx skGRYhaBs2eJ4vtFOBLarG7Ej/XC12C1NZPH/TgQbF06PuGFg8D2w0gTPgMOI5+WbC0IhLf2 yu0pMqyAqmddYjK+HUHjq8HtBglOhk7LCyHPCPvBtPvbtk5hH5icNwl4BoyhpW+EIuwNi3Ob O/k0WHEahORiObgWikjEDz6ZyhG/C/CAGMZmDWJiHAd9VZ+QGAYRjLn6d4w4cH6vp4hRh8D+ txYR4zCYjC6asAqGq0tEJGRBMOioExFjSgjtmwGED8Hcl2pxFQpu2HUFYTUM1HaIG7afwwM+ 1M/TRA+FCWONiPBRaH36kyIcAnWbVnq33oTEZuStYTWpORkREaEsp0rTaNS5oblswUu09WkG OtfDutHiQrQVYQbJ98omtBKFp1Cp1ehyrAgYSu4lK7myJcnSlbq7LKe+wRVmsxorOsjQch9Z tOVjkifOUBawt1g2j+X+uwJG4luMwipWXY6rxWOBjkTVyXB3SrOiKOp9fPCloFRKoM379bD8 3My4OqA5vqzMMNRWmj8SoBAn2u6PM1Of+8/GorjkXnuOulumTHO2Fcny7ebE69Opj25aE2Jn OkzDU89jhlbsc5NL/k9O9xdyHvZ968spMaPpF7kDa4/dWZbbPV/b5bQmUxl+hOI0yn+FHA6H MAMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:53:49 -0000 --_000_DBXPR07MB35149A11955E02FD1937A23C22B0DBXPR07MB351eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi The Hullet room is now booked for this meeting. /Ingemar From: Ingemar Johansson S [mailto:ingemar.s.johansson@ericsson.com] Sent: den 13 november 2017 18:29 To: QUIC WG Subject: RE: ECN in QUIC side meeting Hi Seems like we already now have a winner. All of the doodlers so far have selected the time slot 16.00-17.00 on Thurs= day, which means that I hereby decide that we'll pick that slot. I will try to arrange with a meeting room. A wiki on the subject is already in place https://github.com/quicwg/base-dr= afts/wiki/ECN-in-QUIC For those of you who attend, a few short questions to consider 1. Do the proposed ECN fields look OK ? 2. ECN in dedicated ACK frame, is this OK ? * If yes, should the timestamps be baked in the same ACK frame 1. ECN capability exchange already at connection setup, for or against ? 2. Is it time to add this to the QUIC transport draft ? /Ingemar From: Ingemar Johansson S Sent: den 13 november 2017 10:42 To: QUIC WG > Cc: 'emile.stephan@orange.com' >; 'subirdas21@gmail.com' >; Bob Briscoe (research@bobbriscoe.net) >; 'Mi= rja Kuehlewind (IETF)' >; I= an Swett >; 'ietf@trammell.= ch' >; Jana Iyengar (jri@google.c= om) >; Christi= an Huitema >; De Schepper, = Koen (Koen) >= ; Marcus Ihlar = > Subject: ECN in QUIC side meeting Hi I would like to propose that we, that is anybody interested in getting ECN = support in QUIC, meet this week to discuss the details and a way forward to= wards the ultimate goal to get this to happen. Something of a proposal is already written up in https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC I created a doodle where you can add your preference https://doodle.com/poll/dupqc7bv6dmha6ra /Ingemar =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D Ingemar Johansson M.Sc. Master Researcher Ericsson Research Network Protocols & E2E Performance Labratoriegr=E4nd 11 971 28, Lule=E5, Sweden Phone +46-1071 43042 SMS/MMS +46-73 078 3289 ingemar.s.johansson@ericsson.com www.ericsson.com The world is full of magical things patiently waiting for our wits to grow sharper Bertrand Russell =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D --_000_DBXPR07MB35149A11955E02FD1937A23C22B0DBXPR07MB351eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

The Hullet room is now booked for this meeting.=

 

/Ingemar

 

From: Ingemar Johansson S [mailto:ingemar.s.j= ohansson@ericsson.com]
Sent: den 13 november 2017 18:29
To: QUIC WG <quic@ietf.org>
Subject: RE: ECN in QUIC side meeting

 

Hi

Seems like we already now have a winner. =

All of the doodlers so far have selected the time sl= ot 16.00-17.00 on Thursday, which means that I hereby decide that we’= ll pick that slot.
I will try to arrange with a meeting room.

 

A wiki on the subject is already in place https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC

For those of you who attend, a few short questions t= o consider

  1. D= o the proposed ECN fields look OK ?
  2. ECN in dedicated ACK frame, is this OK ?
    1. I= f yes, should the timestamps be baked in the same ACK frame
      2. =
  1. E= CN capability exchange already at connection setup, for or against ?
  2. Is it time to add this to the QUIC transport draft ?

 

/Ingemar

 

From: Ingemar Johansson S
Sent: den 13 november 2017 10:42
To: QUIC WG <quic@ietf.org&g= t;
Cc: 'emile.stephan@orange.com' <emile.stephan@orange.com>; 'subirdas21@gmail.com' <subirdas21@gmail.com>; Bob Bris= coe (research@bobbriscoe.net= ) <research@bobbriscoe.net= >; 'Mirja Kuehlewind (IETF)' <= ietf@kuehlewind.net>; Ian Swett <ianswett@google.com>; 'ietf@trammell.ch' <ietf@trammell.ch>; Jana Iyengar (jri@google.com) <jri@google.com>; Christian Huitema &= lt;huitema@huitema.net>; De S= chepper, Koen (Koen) <koen= .de_schepper@nokia.com>; Marcus Ihlar <marcus.ihlar= @ericsson.com>
Subject: ECN in QUIC side meeting

 

Hi

I would like to propose that we, that is anybody int= erested in getting ECN support in QUIC, meet this week to discuss the detai= ls and a way forward towards the ultimate goal to get this to happen.<= /o:p>

Something of a proposal is already written up in

https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC

 

I created a doodle where you can add your preference=

https://doodle.com/poll/dupqc7bv6dmha6ra

 

/Ingemar

=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

Ingemar Joh= ansson  M.Sc.

Master Researcher<= /o:p>

 

Ericsson Research<= /o:p>

Network Protocols &= E2E Performance

Labratoriegr=E4nd 11

971 28, Lule=E5, Sweden=

Phone +46-1071 4304= 2

SMS/MMS +46-73 078 = 3289

ingemar.s.johansson@ericsson.com

www.ericsson.com

 

The world is full of magical things patiently

    waiting for our wits to grow sharper

           &= nbsp;   Bertrand Russell
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

 

--_000_DBXPR07MB35149A11955E02FD1937A23C22B0DBXPR07MB351eurprd_-- From nobody Mon Nov 13 05:36: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 721951295A0 for ; Mon, 13 Nov 2017 05:36:08 -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=litespeedtech-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 GhODbw5_uo_e for ; Mon, 13 Nov 2017 05:36:06 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d: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 128DA129666 for ; Mon, 13 Nov 2017 05:35:58 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id n3so903830qkn.11 for ; Mon, 13 Nov 2017 05:35:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:subject:message-id:mail-followup-to:mime-version :content-disposition:user-agent; bh=W3tAoyXs7TEYBbhqy0lZUNolifLpebTdUnnBk4JvL8Y=; b=Ua95E6NeDhX0Umym9Touuo4CdR0BwOt2Iajm8l6kWAnycUbTCcq8z/7WVdwFqRJChq TpKNQEak26HO0UGYWChpGIy5BfUPUIPLmo4ddtw71C4Iy2nxZ+X6jElZ3kCg0mMvRxB8 9F8LUSJhFrbNJsu1apehjNmiobqNYWz8zeHcSsZmSFNexCAQ6Ajx26u7ba893cV9zHwr /z/rX/8Zm0cQAqggc99y6+/8kFUtbmwJv6J0GfGvGjdgflgvJNsFBX7blTCd7dL3VwH2 OH5w+d/3cjNMwMREqB2Tvby8Trrq5lil6AbHM4jC2Fx/ppxPTyEBBKkkX5BY1y7zxjpE rQZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :mime-version:content-disposition:user-agent; bh=W3tAoyXs7TEYBbhqy0lZUNolifLpebTdUnnBk4JvL8Y=; b=Q0saPv+O2AxlqAZNaGBiXOQNn8ONvW6m2s4Y20JhNbtLH5mzwabFNUbQUU6aREzDuw YYf0JkTTPbIyML2RTbJ56Ppj+RzPtGEYOdfs4gLUrK4dNUDrfxZF7XXix158u24zV3d0 ItPZz0zPxrYXLxEMVv0Tbxu6uvnD7YJMbtd5U/mp8BeG3/HNeR7Q6oRstnCQLfSOhDFv xDktbMlR1KRuPxeRhDecBzEzAS0h8yR1kSj2g61W/qqFxMfc9IUD4pJBQ7Flrrnr0bJF yHaDNy774ebUNbDuFZ9RrRWp4poew1+ixZ3xahfgKii3d1Px5m3vEdtwXxvt9f/G4GVr kk6A== X-Gm-Message-State: AJaThX7sGau+nhhXXg81WzWBO3ojtbzZiDZoJLyzhgy0LbBp0iqoaWc2 i1vvaJRwESrwFR7BNet0CVe8lkNB X-Google-Smtp-Source: AGs4zMbfbc35EfI2wDlw2L2Y2SrcYZ9eHBKm9W3nuXJZgcVZn+k3fyYuL9U94JqVGdRExjAvmIeLgg== X-Received: by 10.55.99.69 with SMTP id x66mr13762877qkb.87.1510580157066; Mon, 13 Nov 2017 05:35:57 -0800 (PST) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id y30sm10734458qtd.48.2017.11.13.05.35.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 13 Nov 2017 05:35:56 -0800 (PST) Date: Mon, 13 Nov 2017 08:35:52 -0500 From: Dmitri Tikhonov To: IETF QUIC WG Subject: Fwd: New Version Notification for draft-tikhonov-quic-qmin-00.txt Message-ID: <20171113133551.GA19640@ubuntu-dmitri> Mail-Followup-To: IETF QUIC WG MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 13:36:08 -0000 Hello all, I submitted the QMIN draft. There have been virtually no changes to the document since my original announcement on November 7th. - Dmitri. ----- Forwarded message from internet-drafts@ietf.org ----- Date: Mon, 13 Nov 2017 05:25:51 -0800 From: internet-drafts@ietf.org To: Dmitri Tikhonov Subject: New Version Notification for draft-tikhonov-quic-qmin-00.txt A new version of I-D, draft-tikhonov-quic-qmin-00.txt has been successfully submitted by Dmitri Tikhonov and posted to the IETF repository. Name: draft-tikhonov-quic-qmin Revision: 00 Title: QMIN: Header Compression for QUIC Document date: 2017-11-13 Group: Individual Submission Pages: 16 URL: https://www.ietf.org/internet-drafts/draft-tikhonov-quic-qmin-00.txt Status: https://datatracker.ietf.org/doc/draft-tikhonov-quic-qmin/ Htmlized: https://tools.ietf.org/html/draft-tikhonov-quic-qmin-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-tikhonov-quic-qmin-00 Abstract: This specification defines QMIN, a compression format and protocol for HTTP/2 ([RFC7540]) headers. QMIN is based on HPACK ([RFC7541]). The modifications to HPACK are meant to allow robust compression use in QUIC: That is, no head-of-line blocking and low overhead. QMIN is guided by HPACK design principles. It inherits all of HPACK's data structures and retains binary compatibility with it. While designed with QUIC in mind, QMIN can be used in other contexts. 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 ----- End forwarded message ----- From nobody Mon Nov 13 22:36:01 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 D0B57127342 for ; Mon, 13 Nov 2017 22:35: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, 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 zwfEIJoYHwKF for ; Mon, 13 Nov 2017 22:35:58 -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 53D98129417 for ; Mon, 13 Nov 2017 22:35:58 -0800 (PST) Received: by mail-ot0-x231.google.com with SMTP id s12so9419239otc.0 for ; Mon, 13 Nov 2017 22:35:58 -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=kCetXWTbqgprSmqF7/lCJC2KBsORNs5Nt55fuMgUwT8=; b=gduCd3IHIJC5VXK40dNK7jy/ieQg0ESj6HeY3pmbxp/3pBvHxf4RsC9G74YFmpPpOv OUv4MEU2AwH5hwhogxXKrqEpanCEpuaUEocAB3ueLJ6cbjcfl9LkGApmh6RcjnyyNDAn xFH+z91f17ZCaLV1fErmkbQdL6kHM4ZZ4lIrVb63V1tI3QfZnJQnaEkbQzj31iqEqn0L iMcrRFGe8k8GZrhq2ltj6rPQ2KLY4QqoESAZokOVixhncFGR1byynwofguFjX3GooNbA iKnBrG0cmIuUQ1WdwP2Bmc+KOttR/49FdUpjaho8m1PUGtGqWuKS3PfKiWqfh/LRFJ7H yL0g== 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=kCetXWTbqgprSmqF7/lCJC2KBsORNs5Nt55fuMgUwT8=; b=ShootXicGcBvVWnARkxKoTrurGJubIXx6/9yxaGjoi5Lt0stxp3egULXVzz2SbIYxj hGDSuwsul+KAF3DSDfZ3VgFw/5waWIC+xol+W266T7v+QVe2AYoK4OgAUH3vukHQJZ/g t0NpxAi3PwGtrADBHNr5bleyU0/S+Ju/KAjtCF2Qz4b4U/+jPcs2ujonQupO5hl2Jg8e 9R6wX5pDc+EugAb3xLoGbCPfenYLWn0LYkyu3/GNhNOOQbCq0SrXQtIGQgEcu+UqAjnu G/k0mv7Ht8a9gS3uiTcfJSyYstwad1Kk/GVcSVgzyrAJwRQrgLpbf9kG6CgOg4/R+OdM YZrA== X-Gm-Message-State: AJaThX4gLCZRVJyFVHSc14/IBHdxKLSs3LUn4DGigK2ofyL3eKjq8YGp xJCEV2sx/SvZtJTyFFEbNtl4rhoEXpxLAFFenCox1g== X-Google-Smtp-Source: AGs4zMYNWIG/sGZIlU8A++kWAsPq1jbYM7t+qSN5dHynQQZUbAfRKn9iIwFapNhcffl6rBhwP4R98fxe6gUOQlFYV3U= X-Received: by 10.157.53.8 with SMTP id o8mr7679743otc.35.1510641357633; Mon, 13 Nov 2017 22:35:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 13 Nov 2017 22:35:56 -0800 (PST) From: Martin Thomson Date: Tue, 14 Nov 2017 14:35:56 +0800 Message-ID: Subject: p2p tweak I was going to propose To: Colin Perkins , Bernard Aboba , QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:36:00 -0000 If we invert the connection ID bit, then if we assume that p2p cases will use ICE, then those use cases won't need the connection ID on short packets. Inverting that bit means that QUIC short packets would only use between 64 and 127. From nobody Mon Nov 13 22:39: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 D77C912717E for ; Mon, 13 Nov 2017 22:39:29 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNeuWo2Cs0Dw for ; Mon, 13 Nov 2017 22:39:26 -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 EB33812943C for ; Mon, 13 Nov 2017 22:39:25 -0800 (PST) X-AuditID: c1b4fb3a-c73ff70000004c48-45-5a0a8f9b9fb9 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id E5.A3.19528.B9F8A0A5; Tue, 14 Nov 2017 07:39:24 +0100 (CET) Received: from [100.94.60.141] (153.88.183.153) by smtps.internal.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 14 Nov 2017 07:39:22 +0100 To: IETF QUIC WG From: Magnus Westerlund Subject: Regarding Turn channel in first octet demultiplex Message-ID: Date: Tue, 14 Nov 2017 14:41:12 +0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms030006010307030504050004" X-Originating-IP: [153.88.183.153] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrNLMWRmVeSWpSXmKPExsUyM2J7oO6cfq4og+Nv2Sx6FnA7MHosWfKT KYAxissmJTUnsyy1SN8ugSvj5Mt77AVn7SsmLn7L0sC40bqLkZNDQsBE4v/+HpYuRi4OIYHD jBJ7OpugnE2MEl337wM5HBwiAgoSaxo4QRrYBCwkbv5oZAOxhQWsJNZvW8QCYvMK2Ets3XSe HcRmEVCVuLammxnEFhWIkZj44CIjRI2gxMmZT8DmMwt0M0o82P6WCSQhJKAt0dDUwQpxkZLE 9XnXWSYw8s5C0jMLWQ9IglnAVuLO3N3MELa2xLKFr6FscYmmLytZIWxriRm/DrJB2IoSU7of skPYphKvj35khLCNJN7taWRfwMi5ilG0OLW4ODfdyEgvtSgzubg4P08vL7VkEyMwmA9u+W21 g/Hgc8dDjAIcjEo8vJk1XFFCrIllxZW5hxhVgOY82rD6AqMUS15+XqqSCG9IMFCaNyWxsiq1 KD++qDQntfgQozQHi5I4r8O+CxFCAumJJanZqakFqUUwWSYOTqkGRqu51+q951vJGzZM2Xxw 0vJD2zfMWePT7X/uilVErWJI+In2xers/xN/X5PfVl3820lYUfTAf53vwV+Nzi7Smb5csPiY 6TyWfXOSrV6fujp78dq3l0Oy9wZzHNcr2HK8MDzjoLx4xtl0/9NuK1SlvnA3XoiRTjM53M1R xWz9TUnPb93v/+WrrimxFGckGmoxFxUnAgATIEUkbgIAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:39:30 -0000 --------------ms030006010307030504050004 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-GB Hi, I wanted to follow up my comment at the mic today. So the inclusion of the TURN channel space in the RFC 7983=20 demultiplexing table is really to make some implementation choices easier= =2E So, many ICE implementation uses a single source port per interface=20 (A:P1) . That source port is used both to send STUN connectivity checks=20 (A:P1 -> C:P3) as well as TURN packets to a TURN server (A:P1 -> B:P2).=20 The IP address of the TURN server is known. But, in context of ICE, it=20 is not uncommon to receive STUN packets from previously unknown peer IP=20 addresses (D:P4) that was sent to the client's NATed address (N:P9).=20 Thus it is common to filter first on protocol then figure out what the=20 information means for that address. C A:P1 -----N:P9 -------> B:P2 (TURN server) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \----> C:P3 (Peer ca= ndidate address) =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \--> D:P4 (Oth= er Peer candidate address) So, TURN channel demultiplexing is not needed if one restrict the=20 implementation so that it first look at the source address of incoming=20 IP/UDP packets and then use that to determine that it is STUN/TURN=20 packets from the TURN server. But, it is restricting the implementation=20 in a way that hasn't been common before. From my perspective, it is not important to maintain TURN channels in=20 the demultiplexing. Cheers Magnus Westerlund ---------------------------------------------------------------------- Media Technologies, Ericsson Research ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Torshamnsgatan 23 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- --------------ms030006010307030504050004 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME-kryptografisk signatur MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DLkwggX7MIID46ADAgECAhEA75oIXW3eBHJH2u7brn5gnDANBgkqhkiG9w0BAQUFADA6MREw DwYDVQQKDAhFcmljc3NvbjElMCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2 MjAeFw0xNTAxMjMwODUwNTdaFw0xODAxMjMwODUwNTdaMHAxETAPBgNVBAoMCEVyaWNzc29u MRowGAYDVQQDDBFNYWdudXMgV2VzdGVybHVuZDEtMCsGCSqGSIb3DQEJARYebWFnbnVzLndl c3Rlcmx1bmRAZXJpY3Nzb24uY29tMRAwDgYDVQQFEwdlcmFtc3dkMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAkULrp/ViIWFfDbY2Ycew0bXJc2In2WNQbPORLyFXNpRhjhmg ot5P/0w90T4HY0H6QayjIPK6qIGt1DBXwkq/QHoRsFZiDK9JDnk2WUDcqbJaHqMXvkhj4Jl4 KvonZ31T3NF/8OlcEjumVc8AUA6iccOeUva3TvL/EOqY3f4bsem4ER3KAcY/lTPWivSY+/Aw vS64JjaANOHVhZ0LUj10JTe9CpdXB+1nMpqLFYkjse/2ahQuKyaBKhKJs35pSYijh3Ln+vMv YUNEna2LjHvkCPVo5Oihylxjmd1OSDXND7125tgo/kB08RtaJ9u6PNw0CoUgA+d23UzVzlYg aSJbhwIDAQABo4IBxDCCAcAwSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50cnVzdC50 ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEEdjB0 MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFs Y2F2Mi5jZXIwKQYDVR0RBCIwIIEebWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tMFUG A1UdIAROMEwwSgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3Np dG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggr BgEFBQcDAjAdBgNVHQ4EFgQUwff+Y5pMEPJX7xortCv8deSKeQEwHwYDVR0jBBgwFoAUsQ3K 1Ea3r4YCwy9vBsoOdnF/SzcwDgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQBy rk0JhGgu9Fd/0Fg1cMhSa882HMQZWQLT1V4PFQpU6t2an8xaqT5JsxOpuxb+WxwpKG+UDbzQ cWgcb/DPW3Mc0AvhTFII1qAYf6Smkq6SOD/8TACjH+dy7JrbcNYJcTlVNBlC/V/C+waICkER wuMC/8QjXs0ExJekAD3i/3GUok9WnvEHsohIL04qk1lbvJN4WGHCHFercX11Ch+UjStHwtyw zyFWi64CqD48kKqPwEne3Lj7ozxzuwCCaJI9fmCQgLfSL+UcDgEb7cQucMAnB/Zxlz6U6ohd PRlQHaLevAYD2UK+BlhZKLAv/DNUz0nk6fx4CiJF5DIRteUdzGoeGcnWMWO9hv5PkEJC1WkZ gYXZ/91HMUjsYUuy5/EsmkqvkCalRudoqe6Pex3A34iFGNvDhI3fCrbvmRS4FARPse5D8BLu e/PIvAPNUC7xl8UcfnTNVgy5ITzWNiY9hIrbAzfPbTXyZSIdMD+HTNg33ziMbu2Iry/2eS1X /whXkApnQNpHplvzf1xMEeNPlDKtL8OOg+9y4ESdn27EKxeeaaFXsrhb3z1woIjQxXINft5W EPXWnks/YBCvrLTH8kRCLZgH17zDxb+MLqKj1XUQtBKgDhb+VswJM6GF+dDeBJoEYjvLR1Sx l5yfaRj0F7HYkjRUwyehwSHgTVqtgnT9QjCCBrYwggSeoAMCAQICEQCgDMvMm5mY7OI6cPR8 wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQDDBZU ZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg Q0EgdjIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4 Gnl17DJhklkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWX hPTdNzrB3zs5cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehB raHZabrGh9OxQHC4iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI 7LvMiZtVaqitBl0oAJiJyeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd 0D7TGJtkdldVJtMwDYXpyFMGAijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGj A/CxX9aC5Vi1EMRJiOGF6gV3T+V5yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2F GBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXd vo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNXYQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzx b3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0 Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUFBwEBBH4wfDAtBggrBgEFBQcwAYYh aHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsGCCsGAQUFBzAChj9odHRwOi8v cmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFzb25lcmFyb290Y2F2MS5j ZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQBgg8CAwEBAjA6MDgG CCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL0NQ UzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25lcmEuY29t L3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcD BDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3 PZBCsmGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n 65c5oN+l2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+x hsfysYiIl4ORzE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fv dcy04/RnoylxSenxADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdnes s3e1qAEueSRNASLfpFwyRmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZW Os38FQhGWHWXI0g6SgdDObU0GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9byw hEfXjxLIC3Qhtu5lJPTgIo5Bup+aBBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92w behSZD3mSSAemDVwGB2Yu0XHQYyyYfpWsGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEm Jqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62RwfM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/em OtwCGXQ6tZCByMNLxeDwU1TGbTGCAxcwggMTAgEBME8wOjERMA8GA1UECgwIRXJpY3Nzb24x JTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuu fmCcMA0GCWCGSAFlAwQCAQUAoIIBmTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xNzExMTQwNjQxMTJaMC8GCSqGSIb3DQEJBDEiBCAQ/EeSccuvqPU4fCsT yCnAh2SV6087UtsTS2jVrzhcpzBeBgkrBgEEAYI3EAQxUTBPMDoxETAPBgNVBAoMCEVyaWNz c29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYyAhEA75oIXW3eBHJH 2u7brn5gnDBgBgsqhkiG9w0BCRACCzFRoE8wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNV BAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEQDvmghdbd4Eckfa7tuufmCcMGwG CSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAO BggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw DQYJKoZIhvcNAQEBBQAEggEAF/7UcCsQJScjQcxoFPrJSO4EmSOfZbkyLOcTLhyebi5rm4e4 U4vUtGTG1grjSucXcB02Pe7pPvHFVFT9iZ9tWSGyUNHAzixEclPKDd6Mgj2qSFf+6K26vfRa dcn3PzB8gObJm3dTBXX29yXg61GR7ZzwVYv51PFCRq3EIt5bX9pdhtYCnUsRWsEYjfknP7/o jEmE8B5wrJLyVPCC8DgeV83WjthKlN5Y5zsAbBofNPkj1j24srqqIb4/St3KM1MAscfzqnKe Zd4/xRX4e7XKpFNrloDhqK8WIPtdfGmtMc3sq8ncv1WAR86i9Db4gJmsQX90LZSVFvrzYhuH kdZOJAAAAAAAAA== --------------ms030006010307030504050004-- From nobody Mon Nov 13 22:50: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 4EF62126C25 for ; Mon, 13 Nov 2017 22:50: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 xzXsw3J4ktiP for ; Mon, 13 Nov 2017 22:50:52 -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 896B5129439 for ; Mon, 13 Nov 2017 22:50:52 -0800 (PST) Received: by mail-oi0-x236.google.com with SMTP id h6so12981027oia.10 for ; Mon, 13 Nov 2017 22:50: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=GRPl3r0u5BXn3LJOZJZSvtyf/2UFAw7AjpD+dHtxcPQ=; b=Xg+2WOaVfFCoGWsYnb0HYkHzo5RwDQAqITK3L1HsiD9ixt3kxRSGtpBgm+gUXc5H99 69sjbteIKLi757IXB/cZVh5WjSAmjOP2C1SeQ9JtLUpNUL9vH52bhaondQ6SbC1lwxgW ztE9gSZAUnHALkcxhT6ms5Crg6ONuVMr5jEYi3NqIzYp10vp4v1YmPGB+MpuBWfquRWO hGXm/rXS5lETU9YpclW8BsEvBFgb48bdQCQfr/mgBNVe1ExbJyEAF8wma0BghzUA35bk ACKnCFxQ33KE+gdBrw9QegKxhca3KESryiRIMDOSArvvn67uV1y9mIogB0c7oCaKLwfC QwbQ== 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=GRPl3r0u5BXn3LJOZJZSvtyf/2UFAw7AjpD+dHtxcPQ=; b=LQJ/S6h1HuPK1qKvhyVTnsEGnidRcLoVit9ERBH3jBa+SsXxAPHyMgb/PqLpcl7FS8 T6+csAt9lJxvo+3XB50VgNrJ4im8GDVAV50HgiGicDzp4D9zhP9TcJj680R6aUjvTCps 2Te1mpdE8fO0vtheIT5nL/2r0zaF8jGBHIi2kAH0Q9dMhyFEMlD7Ox8r+Helc2T2wQFZ 0GPl8OEb4M40Kps7H1sOUeonIpmp5nCt0mhBgq6t2al4o9+th3zLSQ72fjv/D+P6LHGO g4S3wvi+i3e8nLweokFi0DDEsaRAblvcN3MEu2d90QJKZvgqnJWjM2LTcYlTr9DCil23 0bIg== X-Gm-Message-State: AJaThX4UAC7fiu7TXgCEbxANWi7JU0o0K2CuoFT4o3mSCbQGMOU0xS8E pyVWCh6ckFm6Q5hFR1WpxWBFjZCz4wa7z1ObHEk= X-Google-Smtp-Source: AGs4zMaSwr/bj0MlH7pPhhJ0OL9OxdDUzEbdOEtRzTQ1hj0X/RDv0qSme4Df7Ji1JpfY9Y9AhcXfsgX4bkAWaH2uHAM= X-Received: by 10.202.225.130 with SMTP id y124mr6358365oig.88.1510642251688; Mon, 13 Nov 2017 22:50:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Mon, 13 Nov 2017 22:50:51 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 14 Nov 2017 14:50:51 +0800 Message-ID: Subject: Re: Regarding Turn channel in first octet demultiplex To: Magnus Westerlund Cc: IETF QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:50:54 -0000 Thanks for the explanation Magnus. I now understand the problem and can see how this design could be advantageous. On Tue, Nov 14, 2017 at 2:41 PM, Magnus Westerlund wrote: > Hi, > > I wanted to follow up my comment at the mic today. > > So the inclusion of the TURN channel space in the RFC 7983 demultiplexing > table is really to make some implementation choices easier. > > So, many ICE implementation uses a single source port per interface (A:P1) . > That source port is used both to send STUN connectivity checks (A:P1 -> > C:P3) as well as TURN packets to a TURN server (A:P1 -> B:P2). The IP > address of the TURN server is known. But, in context of ICE, it is not > uncommon to receive STUN packets from previously unknown peer IP addresses > (D:P4) that was sent to the client's NATed address (N:P9). Thus it is common > to filter first on protocol then figure out what the information means for > that address. > > C A:P1 -----N:P9 -------> B:P2 (TURN server) > \ > \----> C:P3 (Peer candidate address) > \ > \--> D:P4 (Other Peer candidate address) > > > So, TURN channel demultiplexing is not needed if one restrict the > implementation so that it first look at the source address of incoming > IP/UDP packets and then use that to determine that it is STUN/TURN packets > from the TURN server. But, it is restricting the implementation in a way > that hasn't been common before. > > From my perspective, it is not important to maintain TURN channels in the > demultiplexing. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Media Technologies, Ericsson Research > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Torshamnsgatan 23 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden | mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > From nobody Tue Nov 14 00:38: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 5EE251200E5 for ; Tue, 14 Nov 2017 00:38:26 -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 vjow1DIcx0Nt for ; Tue, 14 Nov 2017 00:38:24 -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 3BAF912008A for ; Tue, 14 Nov 2017 00:38:24 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-1c-5a0aab7ef304 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id ED.88.08439.E7BAA0A5; Tue, 14 Nov 2017 09:38:22 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 14 Nov 2017 09:38:21 +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=4uyNu9jiskm+N64Ttx5KpQH/y+Lf79c9cTZejx9SvsA=; b=OtntuG3SOM2s4tOglBCg2qLmglG90A4SU5bU58QmfsC7WZ/cJ1dWv/w/YawlUJX+cz9e4izAAZbgTaW8K8Qo0AmMJZEgW9RU9+y6b4Yed46Bgm+ouWrFbzkPPZb2v52ghc0Ln49asE8+bYjHFpHpCs2gULC4u2zMMSN/wH2ksfI= Received: from HE1PR07MB3242.eurprd07.prod.outlook.com (10.170.246.21) by HE1PR07MB3244.eurprd07.prod.outlook.com (10.170.246.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.4; Tue, 14 Nov 2017 08:38:20 +0000 Received: from HE1PR07MB3242.eurprd07.prod.outlook.com ([fe80::6de1:acc:af2d:b555]) by HE1PR07MB3242.eurprd07.prod.outlook.com ([fe80::6de1:acc:af2d:b555%13]) with mapi id 15.20.0239.005; Tue, 14 Nov 2017 08:38:20 +0000 From: Marcus Ihlar To: "quic@ietf.org" CC: "Eggert, Lars" , Mark Nottingham Subject: Latency measurement in version 1 Thread-Topic: Latency measurement in version 1 Thread-Index: AdNdHs0dmWSuyqJzTQKXHeIOa1OXHw== Date: Tue, 14 Nov 2017 08:38:20 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcus.ihlar@ericsson.com; x-originating-ip: [2001:67c:370:128:9855:63d4:2be7:f240] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3244; 6:MOst3u6Votk3uQCokB70/QbwYS+srsuLWN/vXrvATdG9I28M4riEWCklnauBdJkenoj2aaJgdlWUr3BNIDApXxlIvNcBy3Jma0SkkX2dbwj2HvPkrt/fbB6kOSGE+X8Nbjs2l+bsvrHTys9/HyX46G1EgV3Ks9lPOBcp8RSws2AbJzvL6GTEmcdcKO6D+iJbUXL9aKyZgrGDW5Sn7YTrlErpXGhIvJpGmBAeZrkqMYu7Dg/DseRvphQm/gnWMt9WMyqAdxWkF0sJq0JHiR/JfrThD2iPOGov7IeJ9vttuD5HlFOXtEzs3s94gqV7Pc/JGEaKEwBupIag9GM+6tJnKjAv1LF1tCB8quAxl4+vkbc=; 5:gsjB+z5uAhbuOwP1NsaQ9DuOz46lJMOu8ywGH4eMxNkAdlhPm3/w9SqMHjNpw5paj3JK2LJBmcBbevkeBvr3rw+xVC2iWvbb8/q83TX4Ss57Xff8oEsWmGOI8QZhhdEhZJHn5F6EMwX6YN+e+Oc2rH86/349dS5AmMv1RXtWyQs=; 24:McntO9zDe3uwI4xRtCcF1p4q5XLs2pX1KMfSPV0we3sZMUUJoYIndqkTC19OGYDqnBhkXbersSVLBN8RIUpcd/NsfXz/XufgVjmqIYe63y8=; 7:XXADFtXVjSAZJQsMBMLAh6rZysuHgPrHA/5KDdgX7xeOLTMxFzoIiQKfNiTwS3OMMuWTlfbmaeOK9Ayc7xjjmtn3ql3eROtw0x40ZvAqOtXiWerd40gw7YdIO26B2HPbnu2lU5SA00t9XVIauQwbRoN4d9IBna3ZFiPAC+ASXZ+rv4FMH0urndPROMoHRetD3mc4Q2HVl0Jh04dszjfdSHNR7clJfouZOs9+zT+Oqh3l2pn2XHqTTaPuov+jhW3E x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 263d74d5-c969-4bb3-ccaf-08d52b3b0f73 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:HE1PR07MB3244; x-ms-traffictypediagnostic: HE1PR07MB3244: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155)(227612066756510); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3231022)(3002001)(6041248)(20161123562025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3244; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3244; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(39860400002)(346002)(199003)(189002)(81166006)(5640700003)(9686003)(8676002)(2906002)(53936002)(1730700003)(81156014)(478600001)(99286004)(25786009)(7696004)(5660300001)(189998001)(97736004)(8936002)(3660700001)(6506006)(54906003)(3280700002)(86362001)(6436002)(68736007)(101416001)(105586002)(7736002)(106356001)(74316002)(33656002)(54896002)(2900100001)(790700001)(2351001)(14454004)(102836003)(55016002)(2501003)(5250100002)(6916009)(4326008)(6116002)(316002)(50986999)(5630700001)(54356999)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3244; H:HE1PR07MB3242.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: multipart/alternative; boundary="_000_HE1PR07MB3242609D91D432DDD4CF25B5E2280HE1PR07MB3242eurp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 263d74d5-c969-4bb3-ccaf-08d52b3b0f73 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 08:38:20.3542 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3244 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SfUhTURjGObt387oc3Jbii7aslYGKK9NqYKssClGj/ggyNXTlTU2dsmtm QmHGKKY10xVzmJquTw0/MivU4bbEpC8tBWt+olDm8g+zRENr25ngf7/zPM95Oc/LoQhhM9eH SlPkMEqFPEPM45PlsS+2BF+u48dtr7Fskn6fLialDbMTSFpcvWY/EWkwLHAim2rnuZG62Tne MSKOvyeZyUjLZZTb9ibxUwv1ldzsZyF5S+peogDNBqiROwV0GPya1HHViE8JaQsCY+sPAh/e ILANaZHjQNI3CNB8u8txXBHSdzhgrJfi1DiCxqIxwmHwaAm8Gy7iOdiT3gwV92vdHEzQh2Co z0w6eB0dAFZrK4EzEvg9UMVd4WKdCTmYpP2hclTjzAvoBGi4MuVkRItgdH6ExDO94etkFQd3 oMHQ/pHA7AVTE8v2mZQ9nwCL1mwsS2FkbgxhFsGnqiJnMaDNbqBbrudhQwLPb/10hY7AxOtO Hg6VI9CMl7iMQLhZ1UZiTgf9o0LXI6Jhslvl0vu5YPqyD/N66KxQuQZZuFBSMIPwGhl4+FSF SlCQflUhzFlgrJvh6Z0LWAs95ZMk1iUweFvLwxwED+5NE5iD7SXM5Gq9Grk9QV4sw57OTNkR KmGUaWdYNkshUTA5zcj+k0wtf/1fos+2CDOiKST2EKjK+HFCrjyXvZhpRkARYk/BK71dEiTL L+YzyqxE5fkMhjUjX4oUewsijL2xQjpFnsOkM0w2o1xxOZS7TwHK9zu823+kLCzGPL9LFmvo 6tgYXnFVd0C44UL1TNRxTZP8T6LvqQXF46UPtvZSS2yiNj0LiaR91h5Dy+xAjV9SKHVtqL6h ozrl+om2Oo/3mfFvZaZg1cGtWkr8T08OH22MGjzna+uvjFsMF+2MP9ndlZuXpB8wqWWyiUsx pWejxSSbKg8JJJSs/D/P1f+IRQMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:38:26 -0000 --_000_HE1PR07MB3242609D91D432DDD4CF25B5E2280HE1PR07MB3242eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, The chairs requested feedback to the list wrt to the spin bit, here are som= e of my thoughts. # The ability to perform latency measurements is more crucial than packet l= oss (not saying it is unimportant though). In mobile networks "random" pack= et loss is effectively zero, congestion related loss is preceded by spikes = in latency which will be measurable with the spin bit. Hence, I would sugge= st we focus on spin bit and leave the packet loss for later versions. # As version one gets deployed we will see a significant shift of traffic o= ver to QUIC from TCP. In order for the operators to manage the traffic and = make sure the desired QoE for the customers is achieved use-cases such as i= nterdomain trouble shooting and certain types of AQM functions, we need a w= ay to do latency measurements from day one. This requires that we have supp= ort for latency measurements in version 1. # Version 1 will be a base line and will be widely deployed, hence if the s= pin bit is not included from the beginning we will not be able to perform m= easurement for a large amount of early adopters. Furthermore, since V1 is f= ocusing on HTTP, we will likely see lots of V1 deployments long after V2 is= available. # On the point of whether the bit should be invariant I don=B4t have a stro= ng opinion. # If we focus on HTTP2 for QUIC version 1, most of the described corner cas= es as pointed out in the DT slides go away. Hence, spin bit becomes useful = for all cases I can think about. /Marcus Ihlar --_000_HE1PR07MB3242609D91D432DDD4CF25B5E2280HE1PR07MB3242eurp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

The chairs requested feedback t= o the list wrt to the spin bit, here are some of my thoughts.

 

# The ability to perform latenc= y measurements is more crucial than packet loss (not saying it is unimporta= nt though). In mobile networks “random” packet loss is effectiv= ely zero, congestion related loss is preceded by spikes in latency which will be measurable with the spin bit. Hence, I wou= ld suggest we focus on spin bit and leave the packet loss for later version= s.

 

# As version one gets deployed = we will see a significant shift of traffic over to QUIC from TCP. In order = for the operators to manage the traffic and make sure the desired QoE for t= he customers is achieved use-cases such as interdomain trouble shooting and certain types of AQM functions, we nee= d a way to do latency measurements from day one. This requires that we have= support for latency measurements in version 1.

 

# Version 1 will be a base line= and will be widely deployed, hence if the spin bit is not included from th= e beginning we will not be able to perform measurement for a large amount o= f early adopters. Furthermore, since V1 is focusing on HTTP, we will likely see lots of V1 deployments long aft= er V2 is available.

 

# On the point of whether the b= it should be invariant I don=B4t have a strong opinion.

 

# If we focus on HTTP2 for QUIC= version 1, most of the described corner cases as pointed out in the DT sli= des go away. Hence, spin bit becomes useful for all cases I can think about= .

 

/Marcus Ihlar=

--_000_HE1PR07MB3242609D91D432DDD4CF25B5E2280HE1PR07MB3242eurp_-- From nobody Tue Nov 14 00:42: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 8E7BC124D6C for ; Tue, 14 Nov 2017 00:42:06 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z1-oh0Fj8rqZ for ; Tue, 14 Nov 2017 00:42:05 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 295581200E5 for ; Tue, 14 Nov 2017 00:42:05 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5B63D9CCE0FCE for ; Tue, 14 Nov 2017 08:42:02 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 14 Nov 2017 08:41:26 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 16:41:07 +0800 From: Roni Even To: QUIC WG Subject: spin bit in QUIC Thread-Topic: spin bit in QUIC Thread-Index: AdNdInWu9OoodX6pTBa2nSIjjM2p0w== Date: Tue, 14 Nov 2017 08:41:06 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD836BC1@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.35.96] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD836BC1DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:42:06 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD836BC1DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, It is good that the conclusion about the geo location security issue is tha= t the spin bit does not add privacy risk on top of what can be done without= it. As for the spin bit. RTT calculation are used for trouble shooting in TCP s= ee in draft-even-quic-troubleshooting-video-delivery-00. The spin bit will provide similar functionality even though it is less reli= able as was mentioned since it is not part of the QUIC state machine. We envision that we will see a lot of QUIC traffic in the network and havin= g the spin bit can help with identifying bottle necks in the network and re= ducing QUIC latency. It will be important to have the spin bit in V1 and t= he main text is already in the github Thanks Roni Even --_000_6E58094ECC8D8344914996DAD28F1CCD836BC1DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

It is good that the conclusion about the geo locatio= n security issue is that the spin bit does not add privacy risk on top of w= hat can be done without it.

 

As for the spin bit. RTT calculation are used for tr= ouble shooting in TCP see in draft-even-quic-troubleshooting-video-delivery= -00.

The spin bit will provide similar functionality even= though it is less reliable as was mentioned since it is not part of the QU= IC state machine.

We envision that we will see a lot of QUIC traffic i= n the network and having the spin bit can help with identifying bottle neck= s in the network and reducing QUIC latency.  It will be important to h= ave the spin bit in V1 and the main text is already in the github

 

Thanks

Roni Even

 

 

--_000_6E58094ECC8D8344914996DAD28F1CCD836BC1DGGEMM506MBXchina_-- From nobody Tue Nov 14 01:05: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 C95B312008A for ; Tue, 14 Nov 2017 01:05:01 -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 F3w8m1PtcjDn for ; Tue, 14 Nov 2017 01:05:00 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id 141A61292FD for ; Tue, 14 Nov 2017 01:04:58 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 51F18340D5A; Tue, 14 Nov 2017 10:04:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.21117); Tue, 14 Nov 2017 10:04:56 +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; Tue, 14 Nov 2017 10:04:56 +0100 (CET) Received: from dhcp-808c.meeting.ietf.org (account ietf@trammell.ch [31.133.128.140] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 35906331; Tue, 14 Nov 2017 10:04:55 +0100 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_A3F783C0-1D1E-491E-B55E-BBB915A07984"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: spin bit implementation experience Message-Id: <3A09ADC3-2FEC-47BF-91A3-D437CCEEA81F@trammell.ch> Date: Tue, 14 Nov 2017 17:04:51 +0800 Cc: De Vaere Piet To: QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:05:02 -0000 --Apple-Mail=_A3F783C0-1D1E-491E-B55E-BBB915A07984 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, At the mic during today's session, I mentioned some implementation = experience we had with the spin bit, done by our student Piet De Vaere = at ETH. You can see his report at = https://devae.re/f/eth/quic/spinbit_report.pdf. Cheers, Brian --Apple-Mail=_A3F783C0-1D1E-491E-B55E-BBB915A07984 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloKsbMACgkQihK3vwvq RqN20xAAw2TrQAZXOpS/8f0O3+sm21p7qrlYovco7GJC7MUd7XPbSU4vOBGTJTs6 YLbprSA0pgc9hy+py6ElBGc2jMQUHFAGfBkElTpZjY4fuS+JTWX8DdmlsyOyIFiG aedkwxpTOWV/Jg6ceme2FzPjHcdUTy8Q1ic0RVdBS+CK7TRbLE90HD90f0yJGi1T TwwMuv6HAnct0DOwcRxrXHWMfAOun1Q2WlNuI8+4qhPJMWV7GMuBz8i+LFwXYFL1 fiGhR/OQ5SRuPEWi01Lv6bb8YL6szXq4WFuVTXN0p4spWJ4vjkWUc/KAnQU/QOXL Iqpi32izadM4NQFt+ZoZ69wMekDoQZwi4bafpmJvQR8jl+Kb0McRlX1IH+/OWEW4 aYcWFwc/MIcUm4YTnecSRr09xvLnmynAJM2Mxeoa2PzjkdqKmVwgnYYE4HqIUYAG s/mYkClVqWgVGqJzSfkwLooh+x5vkHrKQ+E42vZPmJlutARVXgmZC61+YRc61cta llPURc1P0dIixzIxxepc+ldnYsRzhRFhsJpUAClt81i31aTz5zhAPfYa65oIOCGv eIJzcndhsup7l8eOMQ0tuz1VO8HYOzMNnoCDQnbdPIfalRe/5aHFMJDXk5HJyUEW dmRwFGchm2YcMtHq0yYstZ+WklAytyd0LGRvF2RS70FdvDZBonY= =a6Wi -----END PGP SIGNATURE----- --Apple-Mail=_A3F783C0-1D1E-491E-B55E-BBB915A07984-- From nobody Tue Nov 14 01:30: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 1E5461286C7 for ; Tue, 14 Nov 2017 01:30:30 -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, UNPARSEABLE_RELAY=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 yzlPBSK6hV5c for ; Tue, 14 Nov 2017 01:30:24 -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 DB71B127078 for ; Tue, 14 Nov 2017 01:30:23 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id p33so9780971uag.9 for ; Tue, 14 Nov 2017 01:30:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=ZxjEMKWB83eRQ6HvMSkQS5mUUrf+PFKFT2b4r3PnSpA=; b=tNORdFcdrJOI0qh1o6lBP2kJR1cohNNpaE2G+rIw0Pf2Aser6ajr9vvj+rI81DA0OT 8gwzLfTJeq9uxDwjyf69aL3K9WHWE3CDG0z6EsP5wozdJIPWajYTSxL8mBeK1awyB1X/ tcB8+guqhAnboqqHJpo7mI24drp8fEVThTmVShtlUJ/kha67cyNr+JAXctxGMYxBZmp0 IZF3NBq4Peti5TbsVwdOnEGefQAqGtpTT3Uy/1xBQgrCfi/eqoI/nDmr8KBc37fht5gR n9rNtpfjPV7toNtq5dfOPAzulmNOGTkyl+z+U4SDZnTRfSbVVKHQLhdx4bM3nUuMysnM qdpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=ZxjEMKWB83eRQ6HvMSkQS5mUUrf+PFKFT2b4r3PnSpA=; b=dbBNciFuSpY6Li3CgDrOhT3eupaVZEhgfvjgilULiMOsYDH364Okmcrj7I5dv62LIh Si11ZQesWXOtTNzREgaHgD3Z+Xvtr1HIh+gh/udmCx514USfc/6+GeP8QnQvD05MhvF4 9N9EBBJ0iiYct/Cym4C52D8LwYJeRhHsKhAXkr1QtsWkt9Pz5QNCcmor81sJF4qPGH3J oZUpzYCIzLaYioaV/DShGliM7htDdvuCeSYxYLVnYh+Rz6EsMXJ899GDxIUjhJ8GX4vW esZA52+e72lTFzttUi5dtVMbkLl0QzzKVyc5hixcJz/TFYlp3rfKsiERkSneXFUafTmM THDA== X-Gm-Message-State: AJaThX5j385h2iuM63gT0hmOWyx3fYh4Z9XgjoIujkywp+EmpQaUfxjC o1TXPLfj/aHXcMmbBq9NnZkoCJ3dL/lAr2Mm+Cc= X-Google-Smtp-Source: AGs4zMZjFjDjMH6TralMRhnxVMLPBRp7YdnJaMjxwIafEIycSVsHRY72Vc3queiqgkO7JTJUZPqP0NKKyrvueLa6AHk= X-Received: by 10.176.92.28 with SMTP id q28mr10488510uaf.48.1510651822731; Tue, 14 Nov 2017 01:30:22 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 14 Nov 2017 01:30:22 -0800 From: Marten Seemann In-Reply-To: <3A09ADC3-2FEC-47BF-91A3-D437CCEEA81F@trammell.ch> References: <3A09ADC3-2FEC-47BF-91A3-D437CCEEA81F@trammell.ch> X-Mailer: Airmail (461) MIME-Version: 1.0 Date: Tue, 14 Nov 2017 01:30:22 -0800 Message-ID: Subject: Re: spin bit implementation experience To: "Brian Trammell (IETF)" , QUIC WG Cc: De Vaere Piet Content-Type: multipart/alternative; boundary="f403043615324603b4055dee09d3" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:30:30 -0000 --f403043615324603b4055dee09d3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Did you perform any measurements on networks that have loss and / or reordering? These are the conditions where I would expect problems with the spin bit, and I=E2=80=99d be interested to see how it performs there. On 14. November 2017 at 17:05:06, Brian Trammell (IETF) (ietf@trammell.ch) wrote: Greetings, all, At the mic during today's session, I mentioned some implementation experience we had with the spin bit, done by our student Piet De Vaere at ETH. You can see his report at https://devae.re/f/eth/quic/spinbit_report.pdf. Cheers, Brian --f403043615324603b4055dee09d3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Did you perform any measurements on networks that have lo= ss and / or reordering? These are the conditions where I would expect probl= ems with the spin bit, and I=E2=80=99d be interested to see how it performs= there.


On 14. November 2017 at = 17:05:06, Brian Trammell (IETF) (ietf@t= rammell.ch) wrote:

Greetings, all,

At the mic during today's session, I mentioned some implementation = experience we had with the spin bit, done by our student Piet De Vaere at E= TH. You can see his report at https://devae.re/f/eth/quic/spinbit_report.pdf.

Cheers,

Brian
--f403043615324603b4055dee09d3-- From nobody Tue Nov 14 01: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 A6FFD129409 for ; Tue, 14 Nov 2017 01:32:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Ry04EaiZn2CO for ; Tue, 14 Nov 2017 01:32:50 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A39E1286C7 for ; Tue, 14 Nov 2017 01:32:47 -0800 (PST) Received: from CAS22.d.ethz.ch (172.31.51.112) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 14 Nov 2017 10:32:41 +0100 Received: from [82.130.103.210] (82.130.103.210) by mail.ethz.ch (172.31.51.112) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 14 Nov 2017 10:32:44 +0100 Subject: Re: spin bit implementation experience To: Marten Seemann , "Brian Trammell (IETF)" , QUIC WG References: <3A09ADC3-2FEC-47BF-91A3-D437CCEEA81F@trammell.ch> From: Piet De Vaere | ETH Message-ID: Date: Tue, 14 Nov 2017 10:32:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [82.130.103.210] Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:32:54 -0000 Heyho On 2017-11-14 10:30, Marten Seemann wrote: > Did you perform any measurements on networks that have loss and / or > reordering? These are the conditions where I would expect problems with > the spin bit, and I’d be interested to see how it performs there. Not yet, but I will. The results in the report Brian send are really just a very first impression. A more in depth analysis will follow. Cheers Piet > > On 14. November 2017 at 17:05:06, Brian Trammell (IETF) > (ietf@trammell.ch ) wrote: > >> Greetings, all, >> >> At the mic during today's session, I mentioned some implementation >> experience we had with the spin bit, done by our student Piet De Vaere >> at ETH. You can see his report at >> https://devae.re/f/eth/quic/spinbit_report.pdf. >> >> Cheers, >> >> Brian From nobody Tue Nov 14 01:39: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 B75DF126CC7 for ; Tue, 14 Nov 2017 01:38:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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=verizon.com header.b=aPEvoiXd; dkim=pass (1024-bit key) header.d=verizon.com header.b=pnKM9Sil; dkim=pass (1024-bit key) header.d=verizon.com header.b=lSDJHR8I Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ea2MtHn0KiR for ; Tue, 14 Nov 2017 01:38:57 -0800 (PST) Received: from omzsmtpe01.verizonbusiness.com (omzsmtpe01.verizonbusiness.com [199.249.25.210]) (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 0273A124B09 for ; Tue, 14 Nov 2017 01:38:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1510652337; x=1542188337; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=37mR7Mcmk1IrMb/TLWqjP+keG1DalvnXGVi2hszc5dI=; b=aPEvoiXd7YpaQ3E76yZUG4GzuuUdK/D7rXWU6nMXnKakL0itQzi0lc4A u6o89DCR/1g/CJRKaDUBNQLVTvMV9toQySEiCvQipOUP35UhjmeRPxcyB n4eoWDsCJBNmpjzdRy6XFeuHIdcBnQly+mV7SIQQbrMD7hFsTPc6pmryA Y=; Received: from unknown (HELO fldsmtpi03.verizon.com) ([166.68.71.145]) by omzsmtpe01.verizonbusiness.com with ESMTP; 14 Nov 2017 09:38:55 +0000 Received: from rogue-10-255-192-101.rogue.vzwcorp.com (HELO atlantis.verizonwireless.com) ([10.255.192.101]) by fldsmtpi03.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2017 09:38:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1510652307; x=1542188307; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=37mR7Mcmk1IrMb/TLWqjP+keG1DalvnXGVi2hszc5dI=; b=pnKM9SilUS2BrUqRWHE9lhbfDv2ldqj1CGDbEkxntSEaraysaw3hc9Tb RDNj9bHKQa7qIbSQkWWxlUyNLBRynR//H7fjb7p6BRMvkbQdDSkfCxw73 rng9ud+/JAYzAQO9tcNNnODNasVdzznwl5oW/zWsZV5op6Qi+N2vUknC1 8=; Received: from pioneer.tdc.vzwcorp.com (HELO eris.verizonwireless.com) ([10.254.88.34]) by atlantis.verizonwireless.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Nov 2017 04:38:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizon.com; i=@verizon.com; q=dns/txt; s=corp; t=1510652307; x=1542188307; h=to:cc:subject:date:message-id:references:in-reply-to: mime-version:from; bh=37mR7Mcmk1IrMb/TLWqjP+keG1DalvnXGVi2hszc5dI=; b=lSDJHR8INJE1640TcnA0XG4W5yguhxfA8JCo868g62gXIqHb70fakpA1 a+A7X9WVQPl1l43KxYCj80q6kEuaX0i3ctXn350VOZUFnY6sdMEc/iuBn cPzxHy7U3VbUJ7sumtqpoQqMjD/qOXeeJ6GqUo1K6C7l7nFevXwHvosvk Y=; From: sanjay.mishra@verizon.com X-Host: pioneer.tdc.vzwcorp.com Received: from ohtwi1exh001.uswin.ad.vzwcorp.com ([10.144.218.43]) by eris.verizonwireless.com with ESMTP/TLS/AES128-SHA256; 14 Nov 2017 09:38:26 +0000 Received: from tbwexch08apd.uswin.ad.vzwcorp.com (153.114.162.32) by OHTWI1EXH001.uswin.ad.vzwcorp.com (10.144.218.43) with Microsoft SMTP Server (TLS) id 14.3.248.2; Tue, 14 Nov 2017 04:38:26 -0500 Received: from OMZP1LUMXCA07.uswin.ad.vzwcorp.com (144.8.22.180) by tbwexch08apd.uswin.ad.vzwcorp.com (153.114.162.32) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 14 Nov 2017 04:38:26 -0500 Received: from OMZP1LUMXCA08.uswin.ad.vzwcorp.com (144.8.22.181) by OMZP1LUMXCA07.uswin.ad.vzwcorp.com (144.8.22.180) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 14 Nov 2017 03:38:25 -0600 Received: from OMZP1LUMXCA08.uswin.ad.vzwcorp.com ([144.8.22.181]) by OMZP1LUMXCA08.uswin.ad.vzwcorp.com ([144.8.22.181]) with mapi id 15.00.1263.000; Tue, 14 Nov 2017 03:38:25 -0600 To: QUIC WG CC: Roni Even Subject: RE: spin bit in QUIC Thread-Topic: spin bit in QUIC Thread-Index: AdNdInWu9OoodX6pTBa2nSIjjM2p0wABTQNQ Date: Tue, 14 Nov 2017 09:38:25 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD836BC1@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD836BC1@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.144.60.250] Content-Type: multipart/alternative; boundary="_000_b2e177651f94481b899362904c16b84dOMZP1LUMXCA08uswinadvzw_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:38:59 -0000 --_000_b2e177651f94481b899362904c16b84dOMZP1LUMXCA08uswinadvzw_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Adding to what Roni has below, first, I applaud to the spin bit design for = their time since the Prague meeting and many thanks to Ted for presenting t= hose findings. >From Ted's presentation, it appears that the design team accomplished what = they were asked to do, that is, look at geolocation threat and Min RTT. Sli= de 7 from Ted's presentation lays out negligible threat and at least not an= y additional adversarial information. Given this, I would have thought des= ign team to be less tentative and come to a clear consensus. Also, agree with Marcus on his enumeration on the need for spin bit and as = Roni pointed out inclusion of spin but in v1 gives us some real -world depl= oyment experience on performance and bottlenecks. I ask the chairs to add spin bit for v1. -Sanjay From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, November 14, 2017 4:41 PM To: QUIC WG Subject: [E] spin bit in QUIC Hi, It is good that the conclusion about the geo location security issue is tha= t the spin bit does not add privacy risk on top of what can be done without= it. As for the spin bit. RTT calculation are used for trouble shooting in TCP s= ee in draft-even-quic-troubleshooting-video-delivery-00. The spin bit will provide similar functionality even though it is less reli= able as was mentioned since it is not part of the QUIC state machine. We envision that we will see a lot of QUIC traffic in the network and havin= g the spin bit can help with identifying bottle necks in the network and re= ducing QUIC latency. It will be important to have the spin bit in V1 and t= he main text is already in the github Thanks Roni Even --_000_b2e177651f94481b899362904c16b84dOMZP1LUMXCA08uswinadvzw_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Adding to what Roni ha= s below, first, I applaud to the spin bit design for their time since the P= rague meeting and many thanks to Ted for presenting those findings.

 

From Ted’s prese= ntation, it appears that the design team accomplished what they were asked = to do, that is, look at geolocation threat and Min RTT. Slide 7 from Ted= 217;s presentation lays out negligible threat and at least not any additional adversarial information.  Given this, I w= ould have thought design team to be less tentative and come to a clear cons= ensus.

 

Also, agree with Marcu= s on his enumeration on the need for spin bit and as Roni pointed out inclu= sion of spin but in v1 gives us some real –world deployment experienc= e on performance and bottlenecks.

 

I ask the chairs to ad= d spin bit for v1.

 

-Sanjay

 

 

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of Roni Even
Sent: Tuesday, November 14, 2017 4:41 PM
To: QUIC WG <quic@ietf.org>
Subject: [E] spin bit in QUIC

 

Hi,

It is good that the conclusion about the geo locatio= n security issue is that the spin bit does not add privacy risk on top of w= hat can be done without it.

 

As for the spin bit. RTT calculation are used for tr= ouble shooting in TCP see in draft-even-quic-troubleshooting-video-delivery= -00.

The spin bit will provide similar functionality even= though it is less reliable as was mentioned since it is not part of the QU= IC state machine.

We envision that we will see a lot of QUIC traffic i= n the network and having the spin bit can help with identifying bottle neck= s in the network and reducing QUIC latency.  It will be important to h= ave the spin bit in V1 and the main text is already in the github

 

Thanks

Roni Even

 

 

 

--_000_b2e177651f94481b899362904c16b84dOMZP1LUMXCA08uswinadvzw_-- From nobody Tue Nov 14 01:41: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 4C04A1288B8 for ; Tue, 14 Nov 2017 01:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PAXy8FSsWk9u for ; Tue, 14 Nov 2017 01:41:46 -0800 (PST) Received: from gorgon.tele.no (gorgon.tele.no [IPv6:2001:700:800::70]) (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 1FDE712426E for ; Tue, 14 Nov 2017 01:41:46 -0800 (PST) Received: from localhost ([127.0.0.1]) by gorgon.tele.no with esmtp (Exim 4.89) (envelope-from ) id 1eEXis-0006cq-JK; Tue, 14 Nov 2017 10:41:39 +0100 Subject: Re: Latency measurement in version 1 To: Marcus Ihlar , "quic@ietf.org" Cc: "Eggert, Lars" References: From: Frode Kileng Message-ID: <02c85638-c06f-e73c-240e-21c4d654dbeb@tele.no> Date: Tue, 14 Nov 2017 10:41:35 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:41:57 -0000 On 14/11/17 09:38, Marcus Ihlar wrote: > > Hi, > > The chairs requested feedback to the list wrt to the spin bit, here > are some of my thoughts. > > # The ability to perform latency measurements is more crucial than > packet loss (not saying it is unimportant though). In mobile networks > “random” packet loss is effectively zero, congestion related loss is > preceded by spikes in latency which will be measurable with the spin > bit. Hence, I would suggest we focus on spin bit and leave the packet > loss for later versions. > This may be true that for  simple cases where "random" packet loss is close to zero and that latency spikes is a signal of loss. But there are other causes for loss that is hard to troubleshoot and where the spin bit is not enough. At least based on my own experience when called in to solve more complex mobile network performance issues. Frode Kileng Telenor Research From nobody Tue Nov 14 01:48: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 7D03A126CC7 for ; Tue, 14 Nov 2017 01:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.4 X-Spam-Level: X-Spam-Status: No, score=-5.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 IuP2BIEKGU5y for ; Tue, 14 Nov 2017 01:48:07 -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 E308A12426E for ; Tue, 14 Nov 2017 01:48:06 -0800 (PST) Received: from [172.16.139.137] ([101.100.166.3]) by mail.gmx.com (mrgmx102 [212.227.17.174]) with ESMTPSA (Nemesis) id 0LlXnX-1eoQjr28EJ-00bMQH for ; Tue, 14 Nov 2017 10:48:05 +0100 To: quic@ietf.org From: Georg Mayer Subject: spin-bit Message-ID: <638485db-f344-3685-3719-6f2dcddaa7e0@gmx.com> Date: Tue, 14 Nov 2017 17:48:01 +0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Provags-ID: V03:K0:R1PlOt7dpKo+sGhaI4kKcqTyO8PL2rAfRgubLTfx3YPtnSNkH3E LRVvfALel8TLgBj9DMu9PBnhyJ4VIaAQffvJ4cQPNn4Yrjfwb3udx9v6/tI21lsVNZT5FUD JwZKCYEnVa7vC3dqnNVA6RUeHntsL0zfwhc+Dp4SHyq7UQtrgF3BCAz9ieDC7Un8itd2C3r m6LoE1+I46BtYE6JHv5HQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:lSFuke4fBoY=:YYPTdkr9JhksS6+/YVlfWr hqstgjGfJQktL0gakJYES6TaLYMldhcLsU1YWc7prb/8oROZNu9yXD0X7a6wQPBGdcL56Sj+l h6laYR6Ve2gEhl/ug5qyjrF7wpKgD+y92oToSxumNinvfVw3vpUXU71bJ2242moW1P0DTv4k6 SjXH+9OTP24SPl13igNbrOWxl3loo/mCqEG0qtMvW3rgceN23Yb8iAFjRbMc/xGIgyjzXwOxU LUFGEWDwJgLr+VR6RDzuLZizvV1FUSXTkFIaaUPIxhiIiBD+PDMNHOuDHhyDbU8/ggWckFN0u u3ivjbIv/iKudp+N1KjFTXcyIthgOX5RPquYAWe5ZFJVGS2nhgO4qm6wYhDY/ym3hmxMo+/cf iMLlhcxYRuwUQjH4XPY6j8e2+N8AhvCSHD/X0heraWMFe5aflvkrr8KwxSwhAke9yAV0MM6Og oQFigZcFuYYyYZe7eGI30AVXuM1cUpPAt17EVy72MwJI2H1kqY1J+mA3J+DBn9B9ojU00Y2Ji P8hbh4o30JG6OkOoXFESyqh1+s9g+jjKbEOAPKjMn471LDN5qVL+tzgbSTN2/MuZBhM8speI7 5O5eYJVbBQU2Xz2rPafXThPgTO9hr5D359jHbwfS4lWkz1y8suAO7Tj4c3+7/3BNr7kBRsEzn tmtLgggQZpe4lQmn8XcxUM4Yjid3CKlu/gXMDOy/0tlZIA3S9qh5E/GIqMIIIAs0PJwFYKY8t 4MdP1cMm9VZ/M1F9IHjAdHkPFV1NKhZQh/l4Zb2XmAANcNVjh6tEFZflYQcctrPvW5ueXsrAe YukL9nPFlHkzCD5hJBBGD1e15a8Yx4oTIfz3brDNHENFbUaF+4= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:48:08 -0000 Hello, talking from a 5G/3GPP perspective. In 3GPP we are evaluating currently to use QUIC as transport for practically all our Core internal functionalities (known as "Service Based Architecture" (SBA)). In 5G all this communication will be API based and we'll use HTTP/2, this was already decided. In the upcoming release (Rel-15, deadline: June/Sept 2018) we will not make use of QUIC, as we don't foresee that it will be completed until then. But we are evaluating it to become part of Rel-16. Now looking on the discussion today - just as a personal note with my 3GPP/IETF Liaison glasses on - I see it as problematic if e.g. RTT and losses cannot be determined by the network operator (putting it simply). Looking at the specific deployment of QUIC we are looking at (i.e. network-internal communication) I guess that not having the spin-bit could for some operators and vendors be a real blocking point when looking at QUIC. This was not discussed in detail within 3GPP yet, but as the decision is coming up now in QUIC I'd like to give this as a warning, that if the spin-bit is missing from QUIC then it's adoption for transport of network-internal communications (at least in the 5G area) might turn out to be a problem which in the end might leave 3GPP only with the option to use TCP/TLS for these purposes. Cheers, Georg -- Georg Mayer 3GPP CT Chairman Mobile: +43 699 1900 5758 From nobody Tue Nov 14 01:50: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 D1E40126CC7 for ; Tue, 14 Nov 2017 01:50:08 -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 hdNMpAcV7cv8 for ; Tue, 14 Nov 2017 01:50:06 -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 9C480126DED for ; Tue, 14 Nov 2017 01:50:06 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id e19so19006495qte.8 for ; Tue, 14 Nov 2017 01:50: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; bh=LGGorKeDvUZCe4gh5avym3+nUuurK1JKlzqhUsZhRzk=; b=ZJ6f9I73LXjbQ2DsYEKnIc6WsX/xO7JwmuYOScqAUExOPGwNXnkq6nmnKQS+tWZwGt yksHPy0vSQd9Tw9buHH+TndkudgM7RM6jWteYXW8axmKeYBGh3qwRFinycIJQhnU1qGB S4tKksImLHrpbK3sUpfphW4hmq4RI/cUGWHFw4d+qXXhuYVFrqKgc/Z8PTStmXvAJqyT iRaq28k8yZj7sJ/XUTKDNXH3VUxjH8biOqmYKgqGIIckPPDik+kUu0j40NkKlt9I4OH1 i6aUVq8mDttXFeiWQO+ixvAhVYl5Uveaa/NEAckbP8tqUMoDBiNbsEfPyjLrqU0j2oG9 tmBA== 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; bh=LGGorKeDvUZCe4gh5avym3+nUuurK1JKlzqhUsZhRzk=; b=WxurLPr6NfW2kwVNy8ePAU726ZZBRbfNnSlcG07jZ+V35losK95ym/9bml8GgvhAeY FpKxp2t29+79e+E8rt6iGNqeu+MwmMqpzpvvVNhsmkWouVp9xX3pe2wMZg6iBcMllZRS FmO5hY/ozricgdaYunLgPIMh545zane3hFZcRWujS1KesEk9mXiEUGgV2dzKY+rdDBnR iXeKZxIu0lHfZKDb85vIBZgzpqGBtCa5iqISVD8IEnfu9C0IbT89s5EO7fyitLORNGpD 19jOhNInMQp9mdgNdyQJKnRRpZg688Ri6jiEeXQmz05MslO40UiMoxcd0DpnK4JkWwTG YOoA== X-Gm-Message-State: AJaThX41IKZGM7/2BaXaRODSkhhRwccsUq7x/95/Zl128GTR1+ALPfVM LtxHNfZ8WOSPNrpaDiHwW9NZTKs27gQIzxx7lpFQLg== X-Google-Smtp-Source: AGs4zMYdjKWUwM53vIAt07sy9Ge03wR88e6sMynaaaAhxQZ33xo0QbEcjBr2mctiysog769Y1TiqcY6q6vOmVq+uXgs= X-Received: by 10.37.208.74 with SMTP id h71mr7547050ybg.480.1510653005672; Tue, 14 Nov 2017 01:50:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.132.7 with HTTP; Tue, 14 Nov 2017 01:50:04 -0800 (PST) Received: by 10.129.132.7 with HTTP; Tue, 14 Nov 2017 01:50:04 -0800 (PST) In-Reply-To: References: From: fish fish Date: Tue, 14 Nov 2017 17:50:04 +0800 Message-ID: Subject: Fwd: Questions about QUIC server reset issues To: quic@ietf.org Content-Type: multipart/alternative; boundary="94eb2c056358c838ed055dee4ffa" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:50:09 -0000 --94eb2c056358c838ed055dee4ffa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Respected quic-ads, I am Siyu Yang from Tsinghua University in Beijing, China. I am a master candidate student interested in the transportation layer of satellite networks ( LEO/MEO/GEO ) using QUIC. Previously I have done an experiment building QUIC server and clients in a simulated satellite network environment. It turns out that QUIC/UDP performs much better than TCP/IP structure because of the reduced handshake RTTs and congestion control strategies. After reading Google=E2=80=99s paper on QUIC in sigcomm 2017, *would you pl= ease tell me more about updates of quic=E2=80=99s server stateless reset strateg= ies? Any solution if possible to solve?* *And I am also interested in QUIC cooperation with CDN in such a working case*: mobile clients may apply for another CDN server when they are browsing using QUIC, if it is possible that a connection between CDN server A and the next CDN server B, *the server A would send the related users=E2= =80=99 authentication info** in service* (users=E2=80=99 public key and A=E2=80= =99s public key so that B would not reject the clients=E2=80=99 requests though it is proba= bly the first time that these clients seek for connection to B so that one-RTT saved in this =E2=80=9Cnew=E2=80=9D connection) *to the server B if A knows= that B would take over A to serve the clients ?* I might not be a very common phenomenon in terrestrial networks =E2=80=A6 I= could think out one that: a CDN incremental deployment that the newly established CDN server might =E2=80=9Cinherit=E2=80=9D users=E2=80=99 authe= ntication from its neighbor servers. But it could be a common phenomenon happening every few hours/days in satellite networks if we deploy a set of CDN servers for example in a MEO satellite networks which could cover the whole world with a couple of satellites. Some MEO-constellations has a good properties that the relative locations within these satellites does not change, just like constellations we observe in sky. In this time, the CDN servers serve one client in order and the next server coming to serve could be calculated easily.* If QUIC could SUPPORT servers' authentication transport, it would help a lot in enhancement of the network flow in satellite networks!* And I am also interested that will authentication transport work in QUIC using TLS 1.3. Maybe it would also help a lot in terrestrial networks if mobile users feel good to use their geolocation information =E2=80=A6 Thanks in advance and looking forward to your reply. --94eb2c056358c838ed055dee4ffa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


Respected quic-ads,=C2=A0
I am Siyu Yang from Tsinghua University i= n Beijing, China. I am a master candidate student interested in the transpo= rtation layer of satellite networks ( LEO/MEO/GEO ) using QUIC.
Previously I have done an experimen= t building QUIC server and clients in a simulated satellite network environ= ment. It turns out that QUIC/UDP performs much better than TCP/IP structure= because of the reduced handshake RTTs and congestion control strategies.

After reading Google=E2=80=99s paper on QUIC in sigcomm 2017,= would you please tell me more about updates of quic=E2=80=99s server st= ateless reset strategies? Any solution if possible to solve?

<= /span>And I am also interested in QUIC cooperation with CDN in such a wo= rking case: mobile clients may apply for another CDN server when they a= re browsing using QUIC, if it is possible that a connection between CDN ser= ver A and the next CDN server B, =C2=A0the server A would send the relat= ed users=E2=80=99 authentication info=C2=A0in service =C2=A0= =C2=A0(users=E2=80=99 public key and A=E2=80=99s public key so that B would= not reject the clients=E2=80=99 requests though it is probably the first t= ime that these clients seek for connection to B so that one-RTT saved in th= is=C2=A0=E2=80=9Cnew=E2=80=9D connection) to the server B if A knows tha= t B would take over A to serve the clients ?

I might not b= e a very common phenomenon in terrestrial networks=C2=A0=E2=80=A6 I could t= hink out one that: =C2=A0a CDN incremental deployment that the newly establ= ished CDN server might=C2=A0=E2=80=9Cinherit=E2=80=9D users=E2=80=99 authen= tication from its neighbor servers.=C2=A0

But it could be a common phenomenon= happening every few hours/days in satellite networks if we deploy a set of= CDN servers for example in a MEO satellite networks which could cover the = whole world with a couple of satellites. Some MEO-constellations has a good= properties that the relative locations within these satellites does not ch= ange, just like constellations=C2=A0we observe in sky. In this time, the CD= N servers serve one client in order and the next server coming to serve cou= ld be calculated easily. If QUIC could SUPPORT s= ervers' authentication transport, it would help a lot in enhancement of= the network flow in satellite networks!

And I am also interested = that will authentication transport work in QUIC using TLS 1.3.
=

Maybe i= t would also help a lot in terrestrial networks if mobile users feel good t= o use their geolocation information=C2=A0=E2=80=A6

Thanks in advance and look= ing forward to your reply.

<= /div> --94eb2c056358c838ed055dee4ffa-- From nobody Tue Nov 14 01:58: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 95682124B09 for ; Tue, 14 Nov 2017 01:39:22 -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 xqa2rw_q30aK for ; Tue, 14 Nov 2017 01:39:18 -0800 (PST) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EE39128BA2 for ; Tue, 14 Nov 2017 01:39:13 -0800 (PST) Received: by mail-io0-x22d.google.com with SMTP id v21so2887693ioi.4 for ; Tue, 14 Nov 2017 01:39:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=wlwYPbLbot1p+xlwoZ0NTvTJfasZuBY2+k7ieTktwVU=; b=dzSLVK9K/zdCXtEckBEthXNa4hjhGNSc8laaNQyh/9iz1/41UUWqNP8Z3xQnyybRT3 veQ33IZFLkCIrhGPisaxQKfdiL0E7j6IAXRaKHat8/lLoE929R+CFl8fi5oaiyc9zyBh vFzVWIeGZ8dFCB1PcpQWrX8pGt/PM8gqAzt8QKR8mD45MtfNIdpQJjOEK2lld64qhmil VgFIMKHlFWie6C+xgPDjf7TLY+Osp8dnoCFM4FV3m1Rr1zPFAWxAVMSW2sTQts3xbXit d7DTLnx/Tjir7LOMOkIaZwucvFSkJr/zr83+t0XXza3TvdVNxGIxnrnCpthkEQV6VfUY ekBA== 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 :content-language; bh=wlwYPbLbot1p+xlwoZ0NTvTJfasZuBY2+k7ieTktwVU=; b=mfGH4f41YmSTKmUXMVtyWdi4D6iwXfoY8ZnxQrqJgWPp3YvHfZKmy2Sc0GYn5RGBtl 9uHp5Lqdsw5DcbvreMkyvWytreeNj8RFPbfOAIJ1SpJfgTE6fB2HLJZQhdpAM/Go03lS gnBubQmunJyBpb47jo0U5vGyoqdroHhPQryvV4wfu8mMykDG2N5wP0mHxHmtDMSP3QW3 H7ZgfX4PYAbjlHJASEQEB21WMN+D1zTLJQwHyIky+GEJFuAd5ttvZrf3DptNskyF8z6x hNArw/prWMw/URIENYfpYtTYL/rhvcrMkUk9H2UaGjo7u0XzHC/3mC+u1o/w9pi/s5ns NXKg== X-Gm-Message-State: AJaThX6Czok79G7Ceg4gpuRHqLVX2muQX6+e8tYo/wINWCENrnTY19I3 Flv9KSOjzI8y1MX0oW1uWwiF5Q== X-Google-Smtp-Source: AGs4zMYGlcCmLpNqiyumqVotxe2EiFGWXxNYb06xPJaDmlJabhdn0pGJpW0SPCIDhEkjQopH2VceVw== X-Received: by 10.107.7.33 with SMTP id 33mr6584536ioh.124.1510652352372; Tue, 14 Nov 2017 01:39:12 -0800 (PST) Received: from ?IPv6:2001:67c:1232:144:282b:b03c:ac87:bd15? ([2001:67c:1232:144:282b:b03c:ac87:bd15]) by smtp.googlemail.com with ESMTPSA id v125sm2481580itv.42.2017.11.14.01.39.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 01:39:11 -0800 (PST) Subject: Re: Latency measurement in version 1 To: Marcus Ihlar , "quic@ietf.org" References: From: Frode Kileng Message-ID: Date: Tue, 14 Nov 2017 10:39:08 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: X-Mailman-Approved-At: Tue, 14 Nov 2017 01:58:20 -0800 X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:39:23 -0000 On 14/11/17 09:38, Marcus Ihlar wrote: > > Hi, > > The chairs requested feedback to the list wrt to the spin bit, here > are some of my thoughts. > > # The ability to perform latency measurements is more crucial than > packet loss (not saying it is unimportant though). In mobile networks > “random” packet loss is effectively zero, congestion related loss is > preceded by spikes in latency which will be measurable with the spin > bit. Hence, I would suggest we focus on spin bit and leave the packet > loss for later versions. > This may be true that for the simple cases that "random" packet loss is close to zero and that latency spikes is a signal of loss. But there are other causes for loss that is hard to troubleshoot and where the spin bit is not enough. At least based on my own experience when called in to solve more complex mobile network performance issues. Frode Kileng Telenor Research From nobody Tue Nov 14 02:14: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 B753F126B6E for ; Tue, 14 Nov 2017 02:14:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id esmYebIPf5RT for ; Tue, 14 Nov 2017 02:14:13 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA35A124B09 for ; Tue, 14 Nov 2017 02:14:12 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 296D7403B9 for ; Tue, 14 Nov 2017 11:14:11 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.13]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id 0D2CD1A0079 for ; Tue, 14 Nov 2017 11:14:11 +0100 (CET) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM6D.corporate.adroot.infra.ftgroup ([fe80::54f9:a6c3:c013:cbc7%19]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 11:14:10 +0100 From: To: QUIC WG Subject: RE: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFw== Date: Tue, 14 Nov 2017 10:14:10 +0000 Message-ID: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] Content-Type: multipart/alternative; boundary="_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5OPEXCLILM44corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:14:19 -0000 --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5OPEXCLILM44corp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Last week Orange experienced a fallback of QUIC to TCP on one of its networ= ks. The issues were not visible in QUIC traffic. The troubleshooting was ma= de using TCP packets information. This is not sustainable on the long term = when numerous applications using different versions of QUIC will stop to fa= llback to TCP. Based on the exchange we had in the RTT design team and in today meeting , = it sounds reasonable to reserve at least 2 bits (ideally 3 bits as discusse= d in the design team) for manageability in the QUIC invariants and to start= experimenting the spin bit in QUIC V1. Regards Emile ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5OPEXCLILM44corp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi

 

Last week Oran= ge experienced a fallback of QUIC to TCP on one of its networks. The issues= were not visible in QUIC traffic. The troubleshooting was made using TCP packets information. This is not sustainable on the long te= rm when numerous applications using different versions of QUIC will stop to= fallback to TCP.

 

Based on the e= xchange we had in the RTT design team and in today meeting , it sounds reas= onable to reserve at least 2 bits (ideally 3 bits as discussed in the design team) for manageability in the QUIC invariants and to start = experimenting the spin bit in QUIC V1.

 

Regards

Emile

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5OPEXCLILM44corp_-- From nobody Tue Nov 14 06:51: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 F0EAF124D6C for ; Tue, 14 Nov 2017 06:51: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, 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=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 awjt9KQDEZxn for ; Tue, 14 Nov 2017 06:51:18 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 45A98124C27 for ; Tue, 14 Nov 2017 06:51:18 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id i38so10094795iod.2 for ; Tue, 14 Nov 2017 06:51: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=NIM+EQMfjqavnNTvjQsWTCCzOI5YJCGEcp3tR1RAqtQ=; b=ZwfsjUJiqTWUOAKoPb7RLQZ+kp67AFSE3rTm3yWYcuJlsA72tkm5sHlXJzI2PAch7Y EErHjrArF4e8Vbpq8gfVQSS3JFfqOoTYG94D/Y0pWG/VEmQF1/qMGctcS7H8pZFdhBe6 0qdSj+ntwh6nH/akNDW5xnL3qklscjJ/aTwqSG/d3fbr6PM/gFKevqiO1cJMSiObf1tT YbuueEAeCmhwpFuy02acKb4dA8vMKGQEBdosJOfmOdHaRp9MlWWyKDyHbFdbJIevyZPv Y9j3H3qv8A5AzPKNCkyMhCUYeVhAR7Gpbsu3D2OCUxRbXGYJPDmTwKCsQky/FJSG2I57 PMiA== 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=NIM+EQMfjqavnNTvjQsWTCCzOI5YJCGEcp3tR1RAqtQ=; b=Jr8E478Qz2TaN1eJcDcZB4hKDdTLhiSbNpbuxNYV/FnWRfMB+QEw4JTNR7UW1V+VUx Ax6O+hy3043RRZ+cF8B3Quox4/EOD07eluZEdxXGvkKHngkue90UyFR0AAOx3q3n7LhG 53S3mQ8gL3pUYCgOgGmy0qz9fg1GLw5/b0t/RNwWePS6s1fW8EQK5fo9M94zByFVPwJP 6BZGANwbHPX832JOoQTP+OKIZw6IT47Ux+dcK9rA7PAkOSWyV/4PYH1KWgRWD5R0mhpD jrOV32AAOVtyiFSw+12iOn+jclXBxHza0NTixfK+bied/1bqIr13ZN4a66Yt8amBrSZI SbZg== X-Gm-Message-State: AJaThX4ht8DGsbGAmAxo3fFPGeXu1XQzpwKBi31TbWBvQf8RndBXJWIU Ai99EbVe08C6e3GYmlvDN97nA/RKmOVALm5la7Ighw== X-Google-Smtp-Source: AGs4zMaSYR+RzGXsI2hdSN//Jq+CIhH7sp21J0XQ53RwyKaWzikzJ9YEQ8YTLPe3TxG9NIpEtWchqwLlaxzzbts8xYI= X-Received: by 10.107.163.15 with SMTP id m15mr14516740ioe.61.1510671077477; Tue, 14 Nov 2017 06:51:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.130.35 with HTTP; Tue, 14 Nov 2017 06:50:56 -0800 (PST) In-Reply-To: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> From: Ian Swett Date: Tue, 14 Nov 2017 09:50:56 -0500 Message-ID: Subject: Re: spin bit in QUIC: troubleshooting To: emile.stephan@orange.com Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a11402f14f2b742055df28427" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:51:20 -0000 --001a11402f14f2b742055df28427 Content-Type: text/plain; charset="UTF-8" What would the other bit or two be used for? If there is no standardized use of those bits in v1, then I believe we should wait to reserve them when their usage is defined, given we'd need a version bump to specify how they were being used. At the moment, the management use case is not competing with anyone else for bits in the short header. On Tue, Nov 14, 2017 at 5:14 AM, wrote: > Hi > > > > Last week Orange experienced a fallback of QUIC to TCP on one of its > networks. The issues were not visible in QUIC traffic. The troubleshooting > was made using TCP packets information. This is not sustainable on the long > term when numerous applications using different versions of QUIC will stop > to fallback to TCP. > > > > Based on the exchange we had in the RTT design team and in today meeting , > it sounds reasonable to reserve at least 2 bits (ideally 3 bits as > discussed in the design team) for manageability in the QUIC invariants and > to start experimenting the spin bit in QUIC V1. > > > > Regards > > Emile > > > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > --001a11402f14f2b742055df28427 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What would the other bit or two be used for?=C2=A0 If ther= e is no standardized use of those bits in v1, then I believe we should wait= to reserve them when their usage is defined, given we'd need a version= bump to specify how they were being used.=C2=A0 At the moment, the managem= ent use case is not competing with anyone else for bits in the short header= .

On Tue, No= v 14, 2017 at 5:14 AM, <emile.stephan@orange.com> wr= ote:

Hi

=C2=A0

Last week Oran= ge experienced a fallback of QUIC to TCP on one of its networks. The issues= were not visible in QUIC traffic. The troubleshooting was made using TCP packets information. This is not sustainable on the long te= rm when numerous applications using different versions of QUIC will stop to= fallback to TCP.

=C2=A0<= u>

Based on the e= xchange we had in the RTT design team and in today meeting , it sounds reas= onable to reserve at least 2 bits (ideally 3 bits as discussed in the design team) for manageability in the QUIC invariants and to start = experimenting the spin bit in QUIC V1.

=C2=A0<= u>

Regards=

Emile

=C2=A0

____________________________________________________________=
_____________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--001a11402f14f2b742055df28427-- From nobody Tue Nov 14 07:26: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 9CD67124D37 for ; Tue, 14 Nov 2017 07:26:44 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVaQpQUL3nl2 for ; Tue, 14 Nov 2017 07:26:43 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CF587126C89 for ; Tue, 14 Nov 2017 07:26:42 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 5A684B4271594 for ; Tue, 14 Nov 2017 15:26:39 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 14 Nov 2017 15:26:40 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 23:26:35 +0800 From: Roni Even To: Ian Swett , "emile.stephan@orange.com" CC: QUIC WG Subject: RE: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdF///x3sA//9w/SA= Date: Tue, 14 Nov 2017 15:26:35 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD836D79@DGGEMM506-MBX.china.huawei.com> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.42.211] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD836D79DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 15:26:44 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD836D79DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IGxhdGVuY3kgaXMgd2hhdCB3ZSBuZWVkIHJpZ2h0IG5vdy4NCk9uY2Ugd2Ug dW5kZXJzdGFuZCBtb3JlIGFib3V0IHF1aWMgYW5kIHBhY2tldCBsb3NzICh3aWxsIEVDTiBiZSB1 c2VkIHJlZHVjaW5nIHBhY2tldCBsb3NzKSBhbmQgb3RoZXIgZnVuY3Rpb25hbGl0eSB3ZSBjYW4g c2VlIHdoYXQgZWxzZSBpcyBuZWVkZWQuIFRoaXMgbWF5IGJlIGRvbmUgaW4gbmV4dCB2ZXJzaW9u IHVzaW5nIHZhcmlhbnRzLg0KUm9uaQ0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSWFuIFN3ZXR0DQpTZW50OiDXmdeV150g15IgMTQg16DX ldeR157XkdeoIDIwMTcgMTY6NTENClRvOiBlbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20NCkNjOiBR VUlDIFdHDQpTdWJqZWN0OiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJsZXNob290aW5nDQoN CldoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBmb3I/ICBJZiB0aGVyZSBp cyBubyBzdGFuZGFyZGl6ZWQgdXNlIG9mIHRob3NlIGJpdHMgaW4gdjEsIHRoZW4gSSBiZWxpZXZl IHdlIHNob3VsZCB3YWl0IHRvIHJlc2VydmUgdGhlbSB3aGVuIHRoZWlyIHVzYWdlIGlzIGRlZmlu ZWQsIGdpdmVuIHdlJ2QgbmVlZCBhIHZlcnNpb24gYnVtcCB0byBzcGVjaWZ5IGhvdyB0aGV5IHdl cmUgYmVpbmcgdXNlZC4gIEF0IHRoZSBtb21lbnQsIHRoZSBtYW5hZ2VtZW50IHVzZSBjYXNlIGlz IG5vdCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBmb3IgYml0cyBpbiB0aGUgc2hvcnQgaGVh ZGVyLg0KDQpPbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCA1OjE0IEFNLCA8ZW1pbGUuc3RlcGhhbkBv cmFuZ2UuY29tPG1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpDQoN Ckxhc3Qgd2VlayBPcmFuZ2UgZXhwZXJpZW5jZWQgYSBmYWxsYmFjayBvZiBRVUlDIHRvIFRDUCBv biBvbmUgb2YgaXRzIG5ldHdvcmtzLiBUaGUgaXNzdWVzIHdlcmUgbm90IHZpc2libGUgaW4gUVVJ QyB0cmFmZmljLiBUaGUgdHJvdWJsZXNob290aW5nIHdhcyBtYWRlIHVzaW5nIFRDUCBwYWNrZXRz IGluZm9ybWF0aW9uLiBUaGlzIGlzIG5vdCBzdXN0YWluYWJsZSBvbiB0aGUgbG9uZyB0ZXJtIHdo ZW4gbnVtZXJvdXMgYXBwbGljYXRpb25zIHVzaW5nIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlD IHdpbGwgc3RvcCB0byBmYWxsYmFjayB0byBUQ1AuDQoNCkJhc2VkIG9uIHRoZSBleGNoYW5nZSB3 ZSBoYWQgaW4gdGhlIFJUVCBkZXNpZ24gdGVhbSBhbmQgaW4gdG9kYXkgbWVldGluZyAsIGl0IHNv dW5kcyByZWFzb25hYmxlIHRvIHJlc2VydmUgYXQgbGVhc3QgMiBiaXRzIChpZGVhbGx5IDMgYml0 cyBhcyBkaXNjdXNzZWQgaW4gdGhlIGRlc2lnbiB0ZWFtKSBmb3IgbWFuYWdlYWJpbGl0eSBpbiB0 aGUgUVVJQyBpbnZhcmlhbnRzIGFuZCB0byBzdGFydCBleHBlcmltZW50aW5nIHRoZSBzcGluIGJp dCBpbiBRVUlDIFYxLg0KDQpSZWdhcmRzDQpFbWlsZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1l c3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0 aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0K DQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlv bi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBz aSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoN Cg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRl bnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkg bGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdp dGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3Jhbmdl IGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFu Z2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQo= --_000_6E58094ECC8D8344914996DAD28F1CCD836D79DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0 dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7 DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxl LXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIu MHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9u MTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0 cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRt YXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5k aWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1 cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhhdCBs YXRlbmN5IGlzIHdoYXQgd2UgbmVlZCByaWdodCBub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPk9uY2Ugd2UgdW5kZXJzdGFuZCBtb3JlIGFib3V0IHF1aWMgYW5kIHBhY2tldCBsb3Nz ICh3aWxsIEVDTiBiZSB1c2VkIHJlZHVjaW5nIHBhY2tldCBsb3NzKSBhbmQgb3RoZXIgZnVuY3Rp b25hbGl0eSB3ZSBjYW4gc2VlIHdoYXQgZWxzZSBpcyBuZWVkZWQuIFRoaXMgbWF5DQogYmUgZG9u ZSBpbiBuZXh0IHZlcnNpb24gdXNpbmcgdmFyaWFudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPlJvbmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg Ymx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4g UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ SWFuIFN3ZXR0PGJyPg0KPGI+U2VudDo8L2I+IDxzcGFuIGxhbmc9IkhFIiBkaXI9IlJUTCI+15nX ldedJm5ic3A715IgMTQg16DXldeR157XkdeoIDIwMTcgMTY6NTE8L3NwYW4+PGJyPg0KPGI+VG86 PC9iPiBlbWlsZS5zdGVwaGFuQG9yYW5nZS5jb208YnI+DQo8Yj5DYzo8L2I+IFFVSUMgV0c8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVzaG9vdGluZzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0 IHdvdWxkIHRoZSBvdGhlciBiaXQgb3IgdHdvIGJlIHVzZWQgZm9yPyZuYnNwOyBJZiB0aGVyZSBp cyBubyBzdGFuZGFyZGl6ZWQgdXNlIG9mIHRob3NlIGJpdHMgaW4gdjEsIHRoZW4gSSBiZWxpZXZl IHdlIHNob3VsZCB3YWl0IHRvIHJlc2VydmUgdGhlbSB3aGVuIHRoZWlyIHVzYWdlIGlzIGRlZmlu ZWQsIGdpdmVuIHdlJ2QgbmVlZCBhIHZlcnNpb24gYnVtcCB0byBzcGVjaWZ5IGhvdyB0aGV5IHdl cmUgYmVpbmcNCiB1c2VkLiZuYnNwOyBBdCB0aGUgbW9tZW50LCB0aGUgbWFuYWdlbWVudCB1c2Ug Y2FzZSBpcyBub3QgY29tcGV0aW5nIHdpdGggYW55b25lIGVsc2UgZm9yIGJpdHMgaW4gdGhlIHNo b3J0IGhlYWRlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pk9uIFR1ZSwgTm92IDE0LCAyMDE3IGF0IDU6MTQgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86ZW1p bGUuc3RlcGhhbkBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZW1pbGUuc3RlcGhhbkBvcmFu Z2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPkhpPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+TGFzdCB3ZWVrIE9yYW5nZSBleHBlcmllbmNlZCBhIGZhbGxiYWNr IG9mIFFVSUMgdG8gVENQIG9uIG9uZSBvZiBpdHMgbmV0d29ya3MuIFRoZSBpc3N1ZXMgd2VyZSBu b3QgdmlzaWJsZQ0KIGluIFFVSUMgdHJhZmZpYy4gVGhlIHRyb3VibGVzaG9vdGluZyB3YXMgbWFk ZSB1c2luZyBUQ1AgcGFja2V0cyBpbmZvcm1hdGlvbi4gVGhpcyBpcyBub3Qgc3VzdGFpbmFibGUg b24gdGhlIGxvbmcgdGVybSB3aGVuIG51bWVyb3VzIGFwcGxpY2F0aW9ucyB1c2luZyBkaWZmZXJl bnQgdmVyc2lvbnMgb2YgUVVJQyB3aWxsIHN0b3AgdG8gZmFsbGJhY2sgdG8gVENQLjwvc3Bhbj48 c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+ PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+QmFzZWQgb24gdGhl IGV4Y2hhbmdlIHdlIGhhZCBpbiB0aGUgUlRUIGRlc2lnbiB0ZWFtIGFuZCBpbiB0b2RheSBtZWV0 aW5nICwgaXQgc291bmRzIHJlYXNvbmFibGUgdG8gcmVzZXJ2ZQ0KIGF0IGxlYXN0IDIgYml0cyAo aWRlYWxseSAzIGJpdHMgYXMgZGlzY3Vzc2VkIGluIHRoZSBkZXNpZ24gdGVhbSkgZm9yIG1hbmFn ZWFiaWxpdHkgaW4gdGhlIFFVSUMgaW52YXJpYW50cyBhbmQgdG8gc3RhcnQgZXhwZXJpbWVudGlu ZyB0aGUgc3BpbiBiaXQgaW4gUVVJQyBWMS48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPlJlZ2FyZHM8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+RW1pbGU8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PHNwYW4gbGFu Zz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJG UiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5hIGwnZXhwZWRpdGV1ciBl dCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMg ZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+T3JhbmdlIGRlY2xpbmUgdG91dGUg cmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFs c2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG UiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5U aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ozxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+dGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2 ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJl ZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlm aWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+ PHNwYW4gbGFuZz0iRlIiPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6E58094ECC8D8344914996DAD28F1CCD836D79DGGEMM506MBXchina_-- From nobody Tue Nov 14 08:17: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 68E661271FD for ; Tue, 14 Nov 2017 08:17:06 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 nFWpP7LtZYe4 for ; Tue, 14 Nov 2017 08:17:03 -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 D18951275F4 for ; Tue, 14 Nov 2017 08:17:02 -0800 (PST) X-AuditID: c1b4fb3a-c73ff70000004c48-0b-5a0b16fc6ad6 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BE.D3.19528.CF61B0A5; Tue, 14 Nov 2017 17:17:00 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 14 Nov 2017 17:17:00 +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=MxFbuXZTz2FDsvyWNMK+wVrovU4sONk0g2tQwLxW+0w=; b=ezD9dNffmEG6nWqIWUROts+dGhCu/iuKocR/sfZP8kwlZve+Zkq4OUks89l+EX153DQ+LGCFK7GQM2C9LWzmfXzok+oHlVpKAHXCJEdaJoNNlCInJJz91tuBD4yk9IoZp6Q6fiEq14u+iTc+LysW9hMFlLCFhutoKM0vsmDRea8= Received: from HE1PR07MB3242.eurprd07.prod.outlook.com (10.170.246.21) by HE1PR07MB3243.eurprd07.prod.outlook.com (10.170.246.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Tue, 14 Nov 2017 16:16:58 +0000 Received: from HE1PR07MB3242.eurprd07.prod.outlook.com ([fe80::6de1:acc:af2d:b555]) by HE1PR07MB3242.eurprd07.prod.outlook.com ([fe80::6de1:acc:af2d:b555%13]) with mapi id 15.20.0239.005; Tue, 14 Nov 2017 16:16:58 +0000 From: Marcus Ihlar To: Frode Kileng CC: "quic@ietf.org" Subject: Re: Latency measurement in version 1 Thread-Topic: Latency measurement in version 1 Thread-Index: AdNdHs0dmWSuyqJzTQKXHeIOa1OXHwADZ3wAAA3knAA= Date: Tue, 14 Nov 2017 16:16:58 +0000 Message-ID: <5CDA60EC-0B99-4203-8855-7AC1F72106F6@ericsson.com> References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcus.ihlar@ericsson.com; x-originating-ip: [111.223.96.146] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3243; 6:wcMkhXHFSQeTm7SJ3LedK8bpiKD5ippn7dN06RLK8CEbD+tJquKrMGC5uMM0j84/sIofMH1eT4o92DyKgEtGbL1f2XEt2gtmgywi41YykmnTDZ62R6l1rtFYS1wdbORJoiKRzVL2R3VdACxj6nL6x+bN51GPEV8P0GjGLiYK6FeeoQ6N36d+qJgVhy06IS4WX/rJNofdwvynHQxGPJYyTxzNdlpC9ToAQqnF3Xge3L4RfI4tXuMEnfNtgj7jaqWmi/jhBcqMA4R62MCdqEqWI7zlh94czrPcLH1Xm28FPcjGARTaPTUwHUbhvArRkOIsNcYsV+9vh+UhaiT0oDrg9GRqAy8d1DvhAp2XVfNxTsQ=; 5:TxGjKb8Dr04CmcqoplaQ5XHnzZAMpRLD41WcRfXpuDmqD+j67xSb0ERGcwsggKru7RoPJYc0PA84YwVrSCJ3n+ulMjKaxiOajb4O6NESAADD2aEra8MBDqziP5pNpQRj1UjkS0jzxUn6+fRn//2GPfbt3zcuZMTPHvesP5u9TaY=; 24:Piy72o8wEImP7T15FsM3JD6QIXyxQK+780XRLNSkVoTQROHnN7aMc2jZ1CilClhL94X+DEfSxCWBNpezZYp52iSGAgVzxQF/DK0hiTTyjJw=; 7:11FA/bWUEZ2I00uYnrPYTmGROtIQoJHHyNuHz5KCWmW3JCtQ3UETqY0jnMcj9+dhzICSQ9OZn0BDiTsovsbWShadZ06meRMXDHrW4+RVssntf9G9B6ZORIhO1pxgTWzBViGboKHelFbVLU6F48ruRGoQTa6Lj2S1VLXqLRgxLqxo6k5XPUYWJdZZkx5KNvQZE//XMyJU+CJDhYv/AcHmY2w9oGVVqsf4YZcGBn64Afa1bEtJYDL1rBzu2efTi3t6 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cd1dbd2d-b6cd-429d-b26b-08d52b7b21b5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:HE1PR07MB3243; x-ms-traffictypediagnostic: HE1PR07MB3243: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(10201501046)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3243; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3243; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(24454002)(189002)(199003)(14454004)(68736007)(53936002)(3280700002)(189998001)(86362001)(3660700001)(36756003)(5660300001)(229853002)(66066001)(6246003)(7736002)(83716003)(316002)(478600001)(97736004)(8676002)(3846002)(6116002)(76176999)(54356999)(102836003)(50986999)(99936001)(81156014)(82746002)(2900100001)(81166006)(39060400002)(2906002)(25786009)(99286004)(105586002)(106356001)(1411001)(5250100002)(4326008)(53546010)(54896002)(6436002)(8936002)(6512007)(6506006)(101416001)(33656002)(6486002)(6916009)(2950100002)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3243; H:HE1PR07MB3242.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: multipart/signed; boundary="Apple-Mail-027E5230-F296-4FEF-8814-4C4E60F2C3E9"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cd1dbd2d-b6cd-429d-b26b-08d52b7b21b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 16:16:58.7289 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3243 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0iTURjHO+9lztnitDQfLammRU42TYrM7hk0giIoqKywZW9lrSnva5LR h6EV6fJW0+ylcqAwKAkvy7Uo0nUh3cquEHZZS5eZSBloZZJtOwuCvv2e5/md8z/ncKS0YpiN leYY8jneoNMrJTLmwjb7HPX49IjMFJcxMW3YPiXtjCViFaV1iG/DtA0NP6lNVKZs2V5On1PA 8ckrdssOWK50M3nurUcd5UbaiMa3lKJwKeCFcPtTDVuKZFIFvotgpOg8RYqHCHwTjcGCwWU0 eAfaQloNBR2lzxlSeBG0VXShwGYSrAH3W5MkwJE4AQYHKtkA0zgezC5jkKdhNXQWv6GIo4GR l3Us4XQo6zWHBZjBc6H+41c6wHK8EiaKTKGwCgTe6lPBsHC8HBwT1qCEcBx4vr9jSFg09PTV UeR2keB96pIQjoKB3t/+MKnf3wljr/NIWwn9Zb9ownHwrM6EAlmAnWHw6FlraKCB61VDiPAG sHiKGCLVIxj91sCQgQpqhq4HAwAfgh+3dv5tn74nUsT3sDDc7GDJYCa0XzwpqURq8Z9zi36P xucQXPrdhcTgC0yFzgt9DJGyoN5dG0Z4FtiHLtKEE+GOyRpy5oDZ5A0586FktIr9v78Uasc6 JIQXweD9YfSvY0GTr6AogROEw/tTUzUcn5MtCLkGjYHLb0H+z9dh+5V+A3X0r3YiLEXKyfIl VESmgtUVCIWHnSjBv8+HpqtPUCxjyDVwyki5Q5RlKuR7dYXHOD43iz+i5wQnmiFllNFybaR/ Jd6vy+cOcVwex/+dUtLwWCNaN699bdLGyw8qcLZzxyS1p7Fxc+8aVbLo60mJ903sib5pmxuj irWf1bnjSorXt51wv782Mtgt9zxWvffaLiXZxn0rM7Jb91lj5vOK4y3lzUf0u7bHNN2Y/WL0 qas642si8+rL4i6tM/VzSdOaFNFn1m603p5CHYwQ0x4XeGuby5WMcEC3QEXzgu4PejERkIQD AAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 16:17:06 -0000 --Apple-Mail-027E5230-F296-4FEF-8814-4C4E60F2C3E9 Content-Type: multipart/alternative; boundary=Apple-Mail-7896B929-044B-4519-A263-5695D071EE32 Content-Transfer-Encoding: 7bit --Apple-Mail-7896B929-044B-4519-A263-5695D071EE32 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksIA0KDQoNCj4gT24gMTQgTm92IDIwMTcsIGF0IDE3OjM5LCBGcm9kZSBLaWxlbmcgPGZyb2Rl a2lAZ21haWwuY29tPiB3cm90ZToNCj4gDQo+IA0KPj4gT24gMTQvMTEvMTcgMDk6MzgsIE1hcmN1 cyBJaGxhciB3cm90ZToNCj4+IA0KPj4gSGksDQo+PiANCj4+IFRoZSBjaGFpcnMgcmVxdWVzdGVk IGZlZWRiYWNrIHRvIHRoZSBsaXN0IHdydCB0byB0aGUgc3BpbiBiaXQsIGhlcmUgYXJlIHNvbWUg b2YgbXkgdGhvdWdodHMuDQo+PiANCj4+ICMgVGhlIGFiaWxpdHkgdG8gcGVyZm9ybSBsYXRlbmN5 IG1lYXN1cmVtZW50cyBpcyBtb3JlIGNydWNpYWwgdGhhbiBwYWNrZXQgbG9zcyAobm90IHNheWlu ZyBpdCBpcyB1bmltcG9ydGFudCB0aG91Z2gpLiBJbiBtb2JpbGUgbmV0d29ya3Mg4oCccmFuZG9t 4oCdIHBhY2tldCBsb3NzIGlzIGVmZmVjdGl2ZWx5IHplcm8sIGNvbmdlc3Rpb24gcmVsYXRlZCBs b3NzIGlzIHByZWNlZGVkIGJ5IHNwaWtlcyBpbiBsYXRlbmN5IHdoaWNoIHdpbGwgYmUgbWVhc3Vy YWJsZSB3aXRoIHRoZSBzcGluIGJpdC4gSGVuY2UsIEkgd291bGQgc3VnZ2VzdCB3ZSBmb2N1cyBv biBzcGluIGJpdCBhbmQgbGVhdmUgdGhlIHBhY2tldCBsb3NzIGZvciBsYXRlciB2ZXJzaW9ucy4N Cj4+IA0KPiANCj4gVGhpcyBtYXkgYmUgdHJ1ZSB0aGF0IGZvciB0aGUgc2ltcGxlIGNhc2VzIHRo YXQgInJhbmRvbSIgcGFja2V0IGxvc3MgaXMgY2xvc2UgdG8gemVybyBhbmQgdGhhdCBsYXRlbmN5 IHNwaWtlcyBpcyBhIHNpZ25hbCBvZiBsb3NzLiBCdXQgdGhlcmUgYXJlIG90aGVyIGNhdXNlcyBm b3IgbG9zcyB0aGF0IGlzIGhhcmQgdG8gdHJvdWJsZXNob290IGFuZCB3aGVyZSB0aGUgc3BpbiBi aXQgaXMgbm90IGVub3VnaC4gQXQgbGVhc3QgYmFzZWQgb24gbXkgb3duIGV4cGVyaWVuY2Ugd2hl biBjYWxsZWQgaW4gdG8gc29sdmUgbW9yZSBjb21wbGV4IG1vYmlsZSBuZXR3b3JrIHBlcmZvcm1h bmNlIGlzc3Vlcy4NCj4gDQpZZXMsIHRoaXMgaXMgZGVmaW5pdGVseSB0cnVlLCBzcGluIGJpdCB3 b27igJl0IGhlbHAgdXMgc29sdmUgYWxsIHByb2JsZW1zLCBhbmQgdGhlcmUgYXJlIGNhc2VzIHdo ZXJlIHBhY2tldCBsb3NzIGlzIGltcG9ydGFudCB0byBkZXRlY3QuIEhvd2V2ZXIsIEkgdGhpbmsg dGhlcmUgaXMgYSB0cmFkZW9mZiB3ZSBuZWVkIHRvIG1ha2Ugd2hlbiBpdCBjb21lcyB0byB3aGF0 IGlzIHJlYXNvbmFibGUgdG8gaGF2ZSBpbiBwbGFjZSBmb3IgdmVyc2lvbiAxLiANCkhvcGVmdWxs eSB3ZeKAmWxsIHNlZSBhbiBpbmNyZWFzZWQgYWRvcHRpb24gb2YgRUNOIGFzIHdlbGwsIHdoaWNo IHdpbGwgcmVkdWNlIHNvbWUgb2YgdGhlIGNhc2VzIHdoZXJlIGxvc3MgaXMgYSBzZXJpb3VzIGlz c3VlIHRvZGF5IChlLmcgc2hhbGxvdyB1cGxpbmsgYnVmZmVycykuIA0KDQo+IEZyb2RlIEtpbGVu Zw0KPiBUZWxlbm9yIFJlc2VhcmNoDQo+IA0K --Apple-Mail-7896B929-044B-4519-A263-5695D071EE32 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkhpLCZuYnNwOzxk aXY+PGJyPjxkaXY+PGJyPk9uIDE0IE5vdiAyMDE3LCBhdCAxNzozOSwgRnJvZGUgS2lsZW5nICZs dDs8YSBocmVmPSJtYWlsdG86ZnJvZGVraUBnbWFpbC5jb20iPmZyb2Rla2lAZ21haWwuY29tPC9h PiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pjxz cGFuPjwvc3Bhbj48YnI+PHNwYW4+T24gMTQvMTEvMTcgMDk6MzgsIE1hcmN1cyBJaGxhciB3cm90 ZTo8L3NwYW4+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9i bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPkhpLDwvc3Bhbj48YnI+PC9i bG9ja3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPlRoZSBjaGFpcnMgcmVxdWVzdGVk IGZlZWRiYWNrIHRvIHRoZSBsaXN0IHdydCB0byB0aGUgc3BpbiBiaXQsIGhlcmUgYXJlIHNvbWUg b2YgbXkgdGhvdWdodHMuPC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0i Y2l0ZSI+PHNwYW4+PC9zcGFuPjxicj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0 ZSI+PHNwYW4+IyBUaGUgYWJpbGl0eSB0byBwZXJmb3JtIGxhdGVuY3kgbWVhc3VyZW1lbnRzIGlz IG1vcmUgY3J1Y2lhbCB0aGFuIHBhY2tldCBsb3NzIChub3Qgc2F5aW5nIGl0IGlzIHVuaW1wb3J0 YW50IHRob3VnaCkuIEluIG1vYmlsZSBuZXR3b3JrcyDigJxyYW5kb23igJ0gcGFja2V0IGxvc3Mg aXMgZWZmZWN0aXZlbHkgemVybywgY29uZ2VzdGlvbiByZWxhdGVkIGxvc3MgaXMgcHJlY2VkZWQg Ynkgc3Bpa2VzIGluIGxhdGVuY3kgd2hpY2ggd2lsbCBiZSBtZWFzdXJhYmxlIHdpdGggdGhlIHNw aW4gYml0LiBIZW5jZSwgSSB3b3VsZCBzdWdnZXN0IHdlIGZvY3VzIG9uIHNwaW4gYml0IGFuZCBs ZWF2ZSB0aGUgcGFja2V0IGxvc3MgZm9yIGxhdGVyIHZlcnNpb25zLjwvc3Bhbj48YnI+PC9ibG9j a3F1b3RlPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuPjwvc3Bhbj48YnI+PC9ibG9ja3F1 b3RlPjxzcGFuPjwvc3Bhbj48YnI+PHNwYW4+VGhpcyBtYXkgYmUgdHJ1ZSB0aGF0IGZvciB0aGUg c2ltcGxlIGNhc2VzIHRoYXQgInJhbmRvbSIgcGFja2V0IGxvc3MgaXMgY2xvc2UgdG8gemVybyBh bmQgdGhhdCBsYXRlbmN5IHNwaWtlcyBpcyBhIHNpZ25hbCBvZiBsb3NzLiBCdXQgdGhlcmUgYXJl IG90aGVyIGNhdXNlcyBmb3IgbG9zcyB0aGF0IGlzIGhhcmQgdG8gdHJvdWJsZXNob290IGFuZCB3 aGVyZSB0aGUgc3BpbiBiaXQgaXMgbm90IGVub3VnaC4gQXQgbGVhc3QgYmFzZWQgb24gbXkgb3du IGV4cGVyaWVuY2Ugd2hlbiBjYWxsZWQgaW4gdG8gc29sdmUgbW9yZSBjb21wbGV4IG1vYmlsZSBu ZXR3b3JrIHBlcmZvcm1hbmNlIGlzc3Vlcy48L3NwYW4+PGJyPjxzcGFuPjwvc3Bhbj48YnI+PC9k aXY+PC9ibG9ja3F1b3RlPjxkaXY+WWVzLCB0aGlzIGlzIGRlZmluaXRlbHkgdHJ1ZSwgc3BpbiBi aXQgd29u4oCZdCBoZWxwIHVzIHNvbHZlIGFsbCBwcm9ibGVtcywgYW5kIHRoZXJlIGFyZSBjYXNl cyB3aGVyZSBwYWNrZXQgbG9zcyBpcyBpbXBvcnRhbnQgdG8gZGV0ZWN0LiBIb3dldmVyLCBJIHRo aW5rIHRoZXJlIGlzIGEgdHJhZGVvZmYgd2UgbmVlZCB0byBtYWtlIHdoZW4gaXQgY29tZXMgdG8g d2hhdCBpcyByZWFzb25hYmxlIHRvIGhhdmUgaW4gcGxhY2UgZm9yIHZlcnNpb24gMS4mbmJzcDs8 L2Rpdj48ZGl2PkhvcGVmdWxseSB3ZeKAmWxsIHNlZSBhbiBpbmNyZWFzZWQgYWRvcHRpb24gb2Yg RUNOIGFzIHdlbGwsIHdoaWNoIHdpbGwgcmVkdWNlIHNvbWUgb2YgdGhlIGNhc2VzIHdoZXJlIGxv c3MgaXMgYSBzZXJpb3VzIGlzc3VlIHRvZGF5IChlLmcgc2hhbGxvdyB1cGxpbmsgYnVmZmVycyku Jm5ic3A7PC9kaXY+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxkaXY+PHNwYW4+RnJvZGUg S2lsZW5nPC9zcGFuPjxicj48c3Bhbj5UZWxlbm9yIFJlc2VhcmNoPC9zcGFuPjxicj48c3Bhbj48 L3NwYW4+PGJyPjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48L2JvZHk+PC9odG1sPg== --Apple-Mail-7896B929-044B-4519-A263-5695D071EE32-- --Apple-Mail-027E5230-F296-4FEF-8814-4C4E60F2C3E9 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMqTCCBesw ggPToAMCAQICEBZmcKQRRjNw1PdSU5JDz7kwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjAzMTEx NzUxWhcNMTcxMjAzMTExNzUwWjBmMREwDwYDVQQKDAhFcmljc3NvbjEVMBMGA1UEAwwMTWFyY3Vz IElobGFyMSgwJgYJKoZIhvcNAQkBFhltYXJjdXMuaWhsYXJAZXJpY3Nzb24uY29tMRAwDgYDVQQF EwdlbWFyaWhsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloIS4tGTL4vDh7SUI5AL S+lqDSGdmu4x44OOJWxtLD0+WraSlbXlfcdmNBs7jHhvlp2H8QI1mnU16hu4zVlQylS3jdAY74xF mta6U1ZUsw0AprA2ihvRaHqafkLI69Wizv7XDcU67zoD+TTgtgaBI9agmUcex9Qv9WFmhuRub0Jv HZezw+EXRVrznKodEB2UeM+LSkefuxjiIEp3gRSJ5EgLnLjlNPUShPosCffWzOmNALwfq8W4GJdx ZarKLlNrsVQnD1RNGlWwJeSNvqOopCE80suFv3Blac5NPcr3JEQEfgVtbjR0ijLspTbj6j6UGj8J uXIabnI1/alLaNgFrwIDAQABo4IBvzCCAbswSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50 cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEE djB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2 Mi5jZXIwJAYDVR0RBB0wG4EZbWFyY3VzLmlobGFyQGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoG DCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVs aWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYE FDM4jO3rLCqOTlXf4FyV++FOTOOKMB8GA1UdIwQYMBaAFLENytRGt6+GAsMvbwbKDnZxf0s3MA4G A1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAgEAGAUhHcBBEaN68sqhHRJQ0iDUGK2NxQIu uvMxc0bnoPaoC8rJcjmokdpqLuujoroTfNwmBvnT4mSVtHWUbj/+B72pD4Vs3LgP5SS2B5kd6O3K VoFpmiJMyVXQwhK6M8N8vLzMweCk2I/fcYxn1sq2M2fotUpZk+a9nzTUuahH9LADow7V8MgqedXz mUjkHDLRCSUKswd2TKB8phT5v6lP87OnraFchXCIwGzf1ykF3CYrLH6yce03jQ8+xN/1Xg+cxpR4 /xcJLFzyWrNFCS4Y4tWUcYjkTCeRNz3MQ3br8OeDtCFGGkivlsPRYbrgqrUQM24hrdHcEAlThFDk jmNuT4xvCOXPtWtjCK6CgmelnLEC/RkcxvHG96lufYw+CYJnGcTgRG9Mhk9b79oEkpeiYRv9oU0E Z6jO2HxsIk1ZP58/n7EWE7bHgnn7l6sDbWqCl8mfAd9qQKyrbewFwXM1lxGR8LpmfLDMaVndFdn2 PEVkSCd+lwCTP12ZLtVgEGTqiiL2xbCB8IyvaKcckjWNj+VUH6rjvapL9Tj8Agi1hRvossxV0Fky t/lK7wPsbpBarR9g+EUEMhHWdy304zdvyGgit0KEEwGyTAJ/N3VvufrjdxTFKehfs53epXaA7hh8 ott5jefG1NYl3ruRX2hk3EacS7bWZjDZda4R38QzgW8wgga2MIIEnqADAgECAhEAoAzLzJuZmOzi OnD0fMHAWTANBgkqhkiG9w0BAQUFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwW VGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1MjcwNzQ2MjFaMDox ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2rpT619IllOfiTjqo3XceBp5dewyYZJZ KFzoDkgTIVuhcxlbeUUeyj7/q47dmKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1ll4T03Tc6wd87OXCT u7CiMnfi0cuJf/JCiuIj5vkNfF8hhdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h2Wm6xofTsUBwuIgR 5Mw9GBdyf7wagU6+25Uc2H9Yd4+Wu6lSBwj38/nghNe+ZkXrFw0ESOy7zImbVWqorQZdKACYicng ZrxLowTbCBIFEOiXEBRuZ8tBGsy8sL+3JcG+4s7y4KF3Okha3dA+0xibZHZXVSbTMA2F6chTBgIo 0+rn/IdpLjyMKw4EBTRMiEGeKudmaURsLoAurDMYBxAxowPwsV/WguVYtRDESYjhheoFd0/lechw x0gQXkG1QF5vMEkwwX10MHa6PwF6hE9JhukaXuKthRgWmrhPKhxDuqkd1gBIL41XxVNpOsWcdapr 8IZF2ncYemSDF84G+lqY4ry50dBhCja4Ddg13b6PungLeOQYb5npGtk6yQ8TC1ogcvEGIDXjV2EL LkRJw7I1qOsBdC6mwOe+vaJvZ5/7ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh73CM2cADoyp5pNL0d yE+0G86tqH9xNbNfMaPAzPQ/dQmpNDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcB AQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29u ZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIP AgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSxDcrURrevhgLDL28Gyg52cX9LNzAfBgNVHSME GDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQUFAAOCAgEAbgcgbK+sdz2QQrJh m3Emf1y/tLZ1TG5SJ6CYC9QYdz4kYnIHaPJfunL1qfwKwcDGDcEjcq72PSHsMmlfJ+uXOaDfpdiQ 1Ls63QDVSp2MYWu2cghIj5mPfLAdm52YMXyS10GKEcCO6TjsH8qD9nwmFQnfsYbH8rGIiJeDkcxN 06XqaUNslpMgQZqB1FyYfe7nuvmydn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XMtOP0Z6MpcUnp8QA4 tbWPYiMnRzIMjrt3X87MVPAIrzBhuGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagBLnkkTQEi36RcMkZs 5orjYfaJ87oREdsmISv+iHgrOB0B6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1lyNIOkoHQzm1NBhB 47tDJA84joZvgVcD2Sjewe8A+zj4+r5S1aOnfLyxivW8sIRH148SyAt0IbbuZST04CKOQbqfmgQY 4if7vQX6q8qmabnZ1nxvsMQt9u66TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgdmLtFx0GMsmH6VrBs hhMkUhyhYUcCXSDT81iyPPcMuFnPj4KsnpJBJianuoOF0kBY+JqrcL6oT+HYNkAnCjP24etkcHzO xnkkvyxRnvOCpiY0w370/HNqyvJxMmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0xggKWMIICkgIBATBO MDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB IHYyAhAWZnCkEUYzcNT3UlOSQ8+5MAkGBSsOAwIaBQCgggEdMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTExNDE2MTY1NlowIwYJKoZIhvcNAQkEMRYEFASiPAJa uvYsQejR08b/Wk1VVRJMMF0GCSsGAQQBgjcQBDFQME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEBZmcKQRRjNw1PdSU5JDz7kwXwYL KoZIhvcNAQkQAgsxUKBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBO TCBJbmRpdmlkdWFsIENBIHYyAhAWZnCkEUYzcNT3UlOSQ8+5MA0GCSqGSIb3DQEBAQUABIIBAF8+ wT2E35B4AMjP+cPgK+heU3QprbjGJL+DWPUj7b8T/P+5p35sVbMPbf++gwYaiwYQ7DssQQ1WJW9z w5FSgILUVPCmJSKx5EieIjSHEH0EOoinw+Tj9EMUDxNYylT8rRocOBD8aHiC+yybH/PRVm6AYdCZ uyzhEOTpgaQODfUE+M3RRcEawzXV1nQ1VuXZ1SLD25PtjOZyz3l9iCidbsdWknLvnWzqrNUQ6YJX fA2cG4fTbbKjMEXH8sd+008thbFPOSAmd/RD/7dXe17bpazFC31tCf+wjIXPDlibdcU/qwIvwnr4 fDs/YykVIGKJjapGEs+OiNJt/4KOi1LG0/IAAAAAAAA= --Apple-Mail-027E5230-F296-4FEF-8814-4C4E60F2C3E9-- From nobody Tue Nov 14 08:20: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 325151275F4 for ; Tue, 14 Nov 2017 08:20:46 -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 pb42Efpa_eLA for ; Tue, 14 Nov 2017 08:20:44 -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 9B78C1271FD for ; Tue, 14 Nov 2017 08:20:42 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-02-5a0b17d87d38 Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 8B.CF.08439.8D71B0A5; Tue, 14 Nov 2017 17:20:40 +0100 (CET) Received: from EUR01-HE1-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.352.0; Tue, 14 Nov 2017 17:20:40 +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=7OY2f6hHXjOKKC6bEU8X0P8+Q3CAjtTG1CzCb3mz7Fk=; b=U9tiu4fmrWtBU95oCIwJ2JfSW9B7sSCchjGQbm66RfMfUF7zfKnDv53UG0ZoXam/iZGFUsYpHh3uhbDIDxVp6brsPE76hbIIwRHVFUjZB+PrRkMiJO2OqjjFOEHq2+XpE2M8NUSh55e6K0sze0b8RIPKpKw1wubMbjxLcOqkyFY= Received: from HE1PR07MB3242.eurprd07.prod.outlook.com (10.170.246.21) by HE1PR07MB3243.eurprd07.prod.outlook.com (10.170.246.22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Tue, 14 Nov 2017 16:20:39 +0000 Received: from HE1PR07MB3242.eurprd07.prod.outlook.com ([fe80::6de1:acc:af2d:b555]) by HE1PR07MB3242.eurprd07.prod.outlook.com ([fe80::6de1:acc:af2d:b555%13]) with mapi id 15.20.0239.005; Tue, 14 Nov 2017 16:20:39 +0000 From: Marcus Ihlar To: Roni Even CC: Ian Swett , "emile.stephan@orange.com" , QUIC WG Subject: Re: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFwAJsv0AAAE+vIAAAeM/AA== Date: Tue, 14 Nov 2017 16:20:39 +0000 Message-ID: <37B26B29-2193-443B-8B27-0CF68A8619CA@ericsson.com> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <6E58094ECC8D8344914996DAD28F1CCD836D79@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD836D79@DGGEMM506-MBX.china.huawei.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcus.ihlar@ericsson.com; x-originating-ip: [111.223.96.146] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB3243; 6:7fdAcKjVIXE9J3LUBtfAQHhxG2BYN4661MKzeAFLJJmLAXXDSUnFpD0110bpcFhJ7LqPaMjXwXboN20ZdbPvQgZmtRIfdPnL/mLj5Sn5wUfBSLp1wXhB1Ff1aUofhJI7aeHvYxK2PAUODs5X5xl9c3Ml9hQi70TYnDaTua/gcLt8CRiHKSNTAvHtm33dGATEJHa3eHS3VMNyVUzyPOriJWb6IxlaiiDop9CFXJRUBmc/8TdnBlbF+X/EjhZZHa0FV2HWn7Rb9JFFeihOUhY09p0w0tlinMBqbflqdwvndBBf9tZC9JQEhP27BHNj1XYw0oSUjZ85NzRatXygPtVTlZWgh80Pxj2L97Oq2+X7gH8=; 5:pau/guVgfKlFUHdcGW6fxEGaCf/lE+WPRPuG45gWZTQWTgFkTxOKSCpjm9fLHoewV/ymnntycbiEVFrxorvUy3mnwZcYWBtRv2AAvbIQbxWba47idxuZGcHc5lc2GHMqeNuLIBc/68e5TBu7XY9yK3XcLvojSheRXZ/m2R5QqiE=; 24:W+RPHXs1ZQ+6RIlzYc4CRNctJuE4gcRMkoUY6KKHHltIalXatwSvkLelvL1uu/VONpRIHMQ8BGDUoGQB6XMjo4JTt5Oe043H2ISgUB2LAo4=; 7:6HekExlo9rEm9NuJ2oTNDAotVQKawyK41iajZghniVVnnK9bfR5NQO25iTPzKLBBbEOws4FDJvKJn03DHOlF1CPnOYDMrQhQLf122WnLLN04vDTc/RhOXjX/FF32p7IaU6X5Kwq36ruAOmu3unTG7MAh6i0AHcw1c/ocSRoJrEmjfYXpL0fr3uozpV8woqxspMJd3JBvsNqJ1iXCzFJmEQO6SC6DOgEqyPF0X5X/Fwq7EWb6yeQ4Z3gJACJMGQQk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 6edaf682-299a-4db7-b5b0-08d52b7ba4fc x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:HE1PR07MB3243; x-ms-traffictypediagnostic: HE1PR07MB3243: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(50582790962513)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(10201501046)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB3243; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB3243; x-forefront-prvs: 04916EA04C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(346002)(24454002)(189002)(199003)(51444003)(14454004)(68736007)(53936002)(54906003)(5890100001)(3280700002)(189998001)(86362001)(3660700001)(36756003)(5660300001)(229853002)(66066001)(6246003)(7736002)(83716003)(316002)(478600001)(97736004)(8676002)(3846002)(6116002)(76176999)(54356999)(102836003)(790700001)(50986999)(99936001)(81156014)(82746002)(2900100001)(81166006)(2906002)(25786009)(99286004)(105586002)(106356001)(5250100002)(4326008)(53546010)(54896002)(6436002)(8936002)(6512007)(6506006)(101416001)(33656002)(6486002)(6916009)(2950100002)(236005); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3243; H:HE1PR07MB3242.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: multipart/signed; boundary="Apple-Mail-AD273F84-95CD-40AE-BA9B-6659B91C02E2"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6edaf682-299a-4db7-b5b0-08d52b7ba4fc X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 16:20:39.0540 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3243 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSa0hTYRjHeXfes83NwWlpPpkmDU2bOdMujAq1PsS+RH0IzCnY0pMOddqO WnYBKytyVpaVujQNBcW0VLpZljoztQuaBZlSMRMrL5lG3snOfBcIffud5/97nvd5X46YkmcI XcV6QzJrNOjiFUIJzt/7YJNft4tUu662Va1uapjC6ulPdbQ6q1iqHn/egUOwprg2RZPxbITW lJZOCzQZA+3C3Vgr2RrNxutTWaN/0D5J7CnrBToprxId/tB2E6ej6jKUiRzEwGyAwR9PhDaW M80I/ox6ZCIJz20IBuYGadsHZs5TYP31WESSawKYn/9KkRYrgumsZBsLGRW8+mhaGOXEeIKl o3LBoZgUqG89LbLxUt4xzd9GxPEHc06PnbfDi5k+gY0x4wW5s40Lc2RMMNxvOYnJwXkC6Jy7 iG2BA7MHcusmaRsjxh0+T37C5DAX6OkvEpC7OYH1zUshYWf4/uUP74t5PwJmepNIWQFfz89S hN2hq8hkfxaLCM5WHiesgnuXRuz1ndDaMEXZ9gGmBMHEeCkmgRKujdyjCcdBV8l1O4fDqexe e8NnGsZq6uyBGzQWnBZmIz/zor3NvEcxOQjGqiZE5oUXWALt+f3YzC9OMZHQ/FtFfA94MFJA EV4DDaYyTHgVXDFZRYR94NzEJfr/+hbIm2kSEt4IQy1jaLFTjBwrkDPHcvsTYgLXq1ijPorj Eg0qA5tci/j/senurNdD9HZ4mwUxYqRwlHUjqVZO61K5tAQL8uTn9FXf6kSu2JBoYBVOsjqz RCuXRevSjrDGxEhjSjzLWdAKMVa4yDROfCcTo0tm41g2iTX+SwViB9d0FBKw0lc5V9jvHrE+ z7qs+phyFJ9L7H/HxZWfCL/vva5rX9HBzB5Ue1SL5sIKK8ZCb+jOyGuGNqeXLVd6DT3aEfzz aZR3aP3V9xV3mAOjipLL+iA378lhafWV1WvBp2U8oNvUEvbxxK9gUfi3Q7tCyqG1SufWQGe+ 1s9mDwX2+Q4rMBerC1BSRk73FyJ46EeXAwAA Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 16:20:46 -0000 --Apple-Mail-AD273F84-95CD-40AE-BA9B-6659B91C02E2 Content-Type: multipart/alternative; boundary=Apple-Mail-7F1DC1BB-4186-42AB-AD2E-5F405F849C9E Content-Transfer-Encoding: 7bit --Apple-Mail-7F1DC1BB-4186-42AB-AD2E-5F405F849C9E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 KzEgb24gUm9uaXMgc3RhdGVtZW50IGJlbG93LiANCkxldCB1cyBiZWdpbiB3aXRoIGxhdGVuY3ks IHdoaWNoIGlzIHRoZSBtb3N0IGNydWNpYWwgY29tcG9uZW50IHRvIGhhdmUgaW4gcGxhY2UuIA0K QXMgVjEgZ2V0cyBkZXBsb3llZCB3ZSB3aWxsIGdldCBhIGJldHRlciB1bmRlcnN0YW5kaW5nIG9m IHdoYXQgZWxzZSBtaWdodCBiZSBuZWVkZWQuIA0KDQo+IE9uIDE0IE5vdiAyMDE3LCBhdCAyMzoy NywgUm9uaSBFdmVuIDxyb25pLmV2ZW5AaHVhd2VpLmNvbT4gd3JvdGU6DQo+IA0KPiBJIHRoaW5r IHRoYXQgbGF0ZW5jeSBpcyB3aGF0IHdlIG5lZWQgcmlnaHQgbm93Lg0KPiBPbmNlIHdlIHVuZGVy c3RhbmQgbW9yZSBhYm91dCBxdWljIGFuZCBwYWNrZXQgbG9zcyAod2lsbCBFQ04gYmUgdXNlZCBy ZWR1Y2luZyBwYWNrZXQgbG9zcykgYW5kIG90aGVyIGZ1bmN0aW9uYWxpdHkgd2UgY2FuIHNlZSB3 aGF0IGVsc2UgaXMgbmVlZGVkLiBUaGlzIG1heSBiZSBkb25lIGluIG5leHQgdmVyc2lvbiB1c2lu ZyB2YXJpYW50cy4NCj4gUm9uaQ0KPiAgDQo+IEZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNCj4gU2VudDog15nXldedINeSIDE0 INeg15XXkdee15HXqCAyMDE3IDE2OjUxDQo+IFRvOiBlbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20N Cj4gQ2M6IFFVSUMgV0cNCj4gU3ViamVjdDogUmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVz aG9vdGluZw0KPiAgDQo+IFdoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBm b3I/ICBJZiB0aGVyZSBpcyBubyBzdGFuZGFyZGl6ZWQgdXNlIG9mIHRob3NlIGJpdHMgaW4gdjEs IHRoZW4gSSBiZWxpZXZlIHdlIHNob3VsZCB3YWl0IHRvIHJlc2VydmUgdGhlbSB3aGVuIHRoZWly IHVzYWdlIGlzIGRlZmluZWQsIGdpdmVuIHdlJ2QgbmVlZCBhIHZlcnNpb24gYnVtcCB0byBzcGVj aWZ5IGhvdyB0aGV5IHdlcmUgYmVpbmcgdXNlZC4gIEF0IHRoZSBtb21lbnQsIHRoZSBtYW5hZ2Vt ZW50IHVzZSBjYXNlIGlzIG5vdCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBmb3IgYml0cyBp biB0aGUgc2hvcnQgaGVhZGVyLg0KPiAgDQo+IE9uIFR1ZSwgTm92IDE0LCAyMDE3IGF0IDU6MTQg QU0sIDxlbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+IHdyb3RlOg0KPiBIaQ0KPiAgDQo+IExhc3Qg d2VlayBPcmFuZ2UgZXhwZXJpZW5jZWQgYSBmYWxsYmFjayBvZiBRVUlDIHRvIFRDUCBvbiBvbmUg b2YgaXRzIG5ldHdvcmtzLiBUaGUgaXNzdWVzIHdlcmUgbm90IHZpc2libGUgaW4gUVVJQyB0cmFm ZmljLiBUaGUgdHJvdWJsZXNob290aW5nIHdhcyBtYWRlIHVzaW5nIFRDUCBwYWNrZXRzIGluZm9y bWF0aW9uLiBUaGlzIGlzIG5vdCBzdXN0YWluYWJsZSBvbiB0aGUgbG9uZyB0ZXJtIHdoZW4gbnVt ZXJvdXMgYXBwbGljYXRpb25zIHVzaW5nIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdpbGwg c3RvcCB0byBmYWxsYmFjayB0byBUQ1AuDQo+ICANCj4gQmFzZWQgb24gdGhlIGV4Y2hhbmdlIHdl IGhhZCBpbiB0aGUgUlRUIGRlc2lnbiB0ZWFtIGFuZCBpbiB0b2RheSBtZWV0aW5nICwgaXQgc291 bmRzIHJlYXNvbmFibGUgdG8gcmVzZXJ2ZSBhdCBsZWFzdCAyIGJpdHMgKGlkZWFsbHkgMyBiaXRz IGFzIGRpc2N1c3NlZCBpbiB0aGUgZGVzaWduIHRlYW0pIGZvciBtYW5hZ2VhYmlsaXR5IGluIHRo ZSBRVUlDIGludmFyaWFudHMgYW5kIHRvIHN0YXJ0IGV4cGVyaW1lbnRpbmcgdGhlIHNwaW4gYml0 IGluIFFVSUMgVjEuDQo+ICANCj4gUmVnYXJkcw0KPiBFbWlsZQ0KPiAgDQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g IA0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRl cyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMNCj4gcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXINCj4gYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kg cXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQg c3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCj4gT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9u c2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLg0KPiAgDQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHBy b3RlY3RlZCBieSBsYXc7DQo+IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBv ciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+ICANCg== --Apple-Mail-7F1DC1BB-4186-42AB-AD2E-5F405F849C9E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPisxIG9uIFJvbmlz IHN0YXRlbWVudCBiZWxvdy4mbmJzcDs8ZGl2PkxldCB1cyBiZWdpbiB3aXRoIGxhdGVuY3ksIHdo aWNoIGlzIHRoZSBtb3N0IGNydWNpYWwgY29tcG9uZW50IHRvIGhhdmUgaW4gcGxhY2UuJm5ic3A7 PC9kaXY+PGRpdj5BcyBWMSBnZXRzIGRlcGxveWVkIHdlIHdpbGwgZ2V0IGEgYmV0dGVyIHVuZGVy c3RhbmRpbmcgb2Ygd2hhdCBlbHNlIG1pZ2h0IGJlIG5lZWRlZC4mbmJzcDs8L2Rpdj48ZGl2Pjxk aXY+PGJyPk9uIDE0IE5vdiAyMDE3LCBhdCAyMzoyNywgUm9uaSBFdmVuICZsdDs8YSBocmVmPSJt YWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20iPnJvbmkuZXZlbkBodWF3ZWkuY29tPC9hPiZndDsg d3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2Pg0KPG1ldGEg aHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRm LTgiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNCAo ZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIg MiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBhbm9zZS0x OjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29s YXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlv bnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2lu OjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBl cmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1M IFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAv Pg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxh eW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwv bzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCg0KDQo8ZGl2IGNsYXNzPSJXb3JkU2Vj dGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgdGhhdCBsYXRlbmN5IGlzIHdoYXQgd2UgbmVlZCByaWdo dCBub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPk9uY2Ugd2UgdW5kZXJzdGFuZCBt b3JlIGFib3V0IHF1aWMgYW5kIHBhY2tldCBsb3NzICh3aWxsIEVDTiBiZSB1c2VkIHJlZHVjaW5n IHBhY2tldCBsb3NzKSBhbmQgb3RoZXIgZnVuY3Rpb25hbGl0eSB3ZSBjYW4gc2VlIHdoYXQgZWxz ZSBpcyBuZWVkZWQuIFRoaXMgbWF5DQogYmUgZG9uZSBpbiBuZXh0IHZlcnNpb24gdXNpbmcgdmFy aWFudHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbmk8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20g MGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPklhbiBTd2V0dDxicj4NCjxiPlNlbnQ6PC9iPiA8c3BhbiBsYW5nPSJI RSIgZGlyPSJSVEwiPteZ15XXnSZuYnNwO9eSIDE0INeg15XXkdee15HXqCAyMDE3IDE2OjUxPC9z cGFuPjxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOmVtaWxlLnN0ZXBoYW5Ab3Jhbmdl LmNvbSI+ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPC9hPjxicj4NCjxiPkNjOjwvYj4gUVVJQyBX Rzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJsZXNob290 aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBmb3I/Jm5ic3A7IElmIHRo ZXJlIGlzIG5vIHN0YW5kYXJkaXplZCB1c2Ugb2YgdGhvc2UgYml0cyBpbiB2MSwgdGhlbiBJIGJl bGlldmUgd2Ugc2hvdWxkIHdhaXQgdG8gcmVzZXJ2ZSB0aGVtIHdoZW4gdGhlaXIgdXNhZ2UgaXMg ZGVmaW5lZCwgZ2l2ZW4gd2UnZCBuZWVkIGEgdmVyc2lvbiBidW1wIHRvIHNwZWNpZnkgaG93IHRo ZXkgd2VyZSBiZWluZw0KIHVzZWQuJm5ic3A7IEF0IHRoZSBtb21lbnQsIHRoZSBtYW5hZ2VtZW50 IHVzZSBjYXNlIGlzIG5vdCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBmb3IgYml0cyBpbiB0 aGUgc2hvcnQgaGVhZGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgNToxNCBBTSwgJmx0OzxhIGhyZWY9Im1haWx0 bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5lbWlsZS5zdGVwaGFu QG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+SGk8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5MYXN0IHdlZWsgT3JhbmdlIGV4cGVyaWVuY2VkIGEgZmFs bGJhY2sgb2YgUVVJQyB0byBUQ1Agb24gb25lIG9mIGl0cyBuZXR3b3Jrcy4gVGhlIGlzc3VlcyB3 ZXJlIG5vdCB2aXNpYmxlDQogaW4gUVVJQyB0cmFmZmljLiBUaGUgdHJvdWJsZXNob290aW5nIHdh cyBtYWRlIHVzaW5nIFRDUCBwYWNrZXRzIGluZm9ybWF0aW9uLiBUaGlzIGlzIG5vdCBzdXN0YWlu YWJsZSBvbiB0aGUgbG9uZyB0ZXJtIHdoZW4gbnVtZXJvdXMgYXBwbGljYXRpb25zIHVzaW5nIGRp ZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdpbGwgc3RvcCB0byBmYWxsYmFjayB0byBUQ1AuPC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CYXNlZCBv biB0aGUgZXhjaGFuZ2Ugd2UgaGFkIGluIHRoZSBSVFQgZGVzaWduIHRlYW0gYW5kIGluIHRvZGF5 IG1lZXRpbmcgLCBpdCBzb3VuZHMgcmVhc29uYWJsZSB0byByZXNlcnZlDQogYXQgbGVhc3QgMiBi aXRzIChpZGVhbGx5IDMgYml0cyBhcyBkaXNjdXNzZWQgaW4gdGhlIGRlc2lnbiB0ZWFtKSBmb3Ig bWFuYWdlYWJpbGl0eSBpbiB0aGUgUVVJQyBpbnZhcmlhbnRzIGFuZCB0byBzdGFydCBleHBlcmlt ZW50aW5nIHRoZSBzcGluIGJpdCBpbiBRVUlDIFYxLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJkczwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FbWlsZTwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3Bh biBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi PkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+cGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj50aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KDQoNCjwvZGl2PjwvYmxvY2txdW90ZT48L2Rpdj48 L2JvZHk+PC9odG1sPg== --Apple-Mail-7F1DC1BB-4186-42AB-AD2E-5F405F849C9E-- --Apple-Mail-AD273F84-95CD-40AE-BA9B-6659B91C02E2 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMqTCCBesw ggPToAMCAQICEBZmcKQRRjNw1PdSU5JDz7kwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjAzMTEx NzUxWhcNMTcxMjAzMTExNzUwWjBmMREwDwYDVQQKDAhFcmljc3NvbjEVMBMGA1UEAwwMTWFyY3Vz IElobGFyMSgwJgYJKoZIhvcNAQkBFhltYXJjdXMuaWhsYXJAZXJpY3Nzb24uY29tMRAwDgYDVQQF EwdlbWFyaWhsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloIS4tGTL4vDh7SUI5AL S+lqDSGdmu4x44OOJWxtLD0+WraSlbXlfcdmNBs7jHhvlp2H8QI1mnU16hu4zVlQylS3jdAY74xF mta6U1ZUsw0AprA2ihvRaHqafkLI69Wizv7XDcU67zoD+TTgtgaBI9agmUcex9Qv9WFmhuRub0Jv HZezw+EXRVrznKodEB2UeM+LSkefuxjiIEp3gRSJ5EgLnLjlNPUShPosCffWzOmNALwfq8W4GJdx ZarKLlNrsVQnD1RNGlWwJeSNvqOopCE80suFv3Blac5NPcr3JEQEfgVtbjR0ijLspTbj6j6UGj8J uXIabnI1/alLaNgFrwIDAQABo4IBvzCCAbswSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50 cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEE djB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2 Mi5jZXIwJAYDVR0RBB0wG4EZbWFyY3VzLmlobGFyQGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoG DCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVs aWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYE FDM4jO3rLCqOTlXf4FyV++FOTOOKMB8GA1UdIwQYMBaAFLENytRGt6+GAsMvbwbKDnZxf0s3MA4G A1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAgEAGAUhHcBBEaN68sqhHRJQ0iDUGK2NxQIu uvMxc0bnoPaoC8rJcjmokdpqLuujoroTfNwmBvnT4mSVtHWUbj/+B72pD4Vs3LgP5SS2B5kd6O3K VoFpmiJMyVXQwhK6M8N8vLzMweCk2I/fcYxn1sq2M2fotUpZk+a9nzTUuahH9LADow7V8MgqedXz mUjkHDLRCSUKswd2TKB8phT5v6lP87OnraFchXCIwGzf1ykF3CYrLH6yce03jQ8+xN/1Xg+cxpR4 /xcJLFzyWrNFCS4Y4tWUcYjkTCeRNz3MQ3br8OeDtCFGGkivlsPRYbrgqrUQM24hrdHcEAlThFDk jmNuT4xvCOXPtWtjCK6CgmelnLEC/RkcxvHG96lufYw+CYJnGcTgRG9Mhk9b79oEkpeiYRv9oU0E Z6jO2HxsIk1ZP58/n7EWE7bHgnn7l6sDbWqCl8mfAd9qQKyrbewFwXM1lxGR8LpmfLDMaVndFdn2 PEVkSCd+lwCTP12ZLtVgEGTqiiL2xbCB8IyvaKcckjWNj+VUH6rjvapL9Tj8Agi1hRvossxV0Fky t/lK7wPsbpBarR9g+EUEMhHWdy304zdvyGgit0KEEwGyTAJ/N3VvufrjdxTFKehfs53epXaA7hh8 ott5jefG1NYl3ruRX2hk3EacS7bWZjDZda4R38QzgW8wgga2MIIEnqADAgECAhEAoAzLzJuZmOzi OnD0fMHAWTANBgkqhkiG9w0BAQUFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwW VGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1MjcwNzQ2MjFaMDox ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2rpT619IllOfiTjqo3XceBp5dewyYZJZ KFzoDkgTIVuhcxlbeUUeyj7/q47dmKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1ll4T03Tc6wd87OXCT u7CiMnfi0cuJf/JCiuIj5vkNfF8hhdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h2Wm6xofTsUBwuIgR 5Mw9GBdyf7wagU6+25Uc2H9Yd4+Wu6lSBwj38/nghNe+ZkXrFw0ESOy7zImbVWqorQZdKACYicng ZrxLowTbCBIFEOiXEBRuZ8tBGsy8sL+3JcG+4s7y4KF3Okha3dA+0xibZHZXVSbTMA2F6chTBgIo 0+rn/IdpLjyMKw4EBTRMiEGeKudmaURsLoAurDMYBxAxowPwsV/WguVYtRDESYjhheoFd0/lechw x0gQXkG1QF5vMEkwwX10MHa6PwF6hE9JhukaXuKthRgWmrhPKhxDuqkd1gBIL41XxVNpOsWcdapr 8IZF2ncYemSDF84G+lqY4ry50dBhCja4Ddg13b6PungLeOQYb5npGtk6yQ8TC1ogcvEGIDXjV2EL LkRJw7I1qOsBdC6mwOe+vaJvZ5/7ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh73CM2cADoyp5pNL0d yE+0G86tqH9xNbNfMaPAzPQ/dQmpNDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcB AQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29u ZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIP AgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSxDcrURrevhgLDL28Gyg52cX9LNzAfBgNVHSME GDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQUFAAOCAgEAbgcgbK+sdz2QQrJh m3Emf1y/tLZ1TG5SJ6CYC9QYdz4kYnIHaPJfunL1qfwKwcDGDcEjcq72PSHsMmlfJ+uXOaDfpdiQ 1Ls63QDVSp2MYWu2cghIj5mPfLAdm52YMXyS10GKEcCO6TjsH8qD9nwmFQnfsYbH8rGIiJeDkcxN 06XqaUNslpMgQZqB1FyYfe7nuvmydn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XMtOP0Z6MpcUnp8QA4 tbWPYiMnRzIMjrt3X87MVPAIrzBhuGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagBLnkkTQEi36RcMkZs 5orjYfaJ87oREdsmISv+iHgrOB0B6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1lyNIOkoHQzm1NBhB 47tDJA84joZvgVcD2Sjewe8A+zj4+r5S1aOnfLyxivW8sIRH148SyAt0IbbuZST04CKOQbqfmgQY 4if7vQX6q8qmabnZ1nxvsMQt9u66TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgdmLtFx0GMsmH6VrBs hhMkUhyhYUcCXSDT81iyPPcMuFnPj4KsnpJBJianuoOF0kBY+JqrcL6oT+HYNkAnCjP24etkcHzO xnkkvyxRnvOCpiY0w370/HNqyvJxMmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0xggKWMIICkgIBATBO MDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB IHYyAhAWZnCkEUYzcNT3UlOSQ8+5MAkGBSsOAwIaBQCgggEdMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTExNDE2MjAzOFowIwYJKoZIhvcNAQkEMRYEFOp1TLvp 8hMlPuRcNFVaL6wQ69FQMF0GCSsGAQQBgjcQBDFQME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEBZmcKQRRjNw1PdSU5JDz7kwXwYL KoZIhvcNAQkQAgsxUKBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBO TCBJbmRpdmlkdWFsIENBIHYyAhAWZnCkEUYzcNT3UlOSQ8+5MA0GCSqGSIb3DQEBAQUABIIBAEL+ clV+vUQLvT9+GSJ4cuMaKs8gxPUahhJTTvX14K1d5EtJbuMQjJG/Siqjqw/VIWYsT0AZeAor7elQ dLgSZq1cRaKA2fcamJ2iA/En3K2wXRLhEAzrdu6LLjclfH0uApWfeYe/qUc+W7991Fl2EebT1gnY CADrjtQg4qIKaMdCjXvLkDhZceymN0hw+TjhqY86hsNgKyYTZwTLhVOq0hQ6phyPMgbQskk/nmFa WA4Es0IbdZZh52dlqlh9bmCxfh0u3UIX1X6I91ybQkp8MCllhpkpFQsHFnqs/saQEd36hBMGSVaM RVOqsUZ2+5d3eei0eg+3ZpN1xvHqBchjkioAAAAAAAA= --Apple-Mail-AD273F84-95CD-40AE-BA9B-6659B91C02E2-- From nobody Tue Nov 14 08:54: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 EDB9D127843 for ; Tue, 14 Nov 2017 08:54:15 -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_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 MucAkrAHBEWX for ; Tue, 14 Nov 2017 08:54:13 -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 25EF2128CF0 for ; Tue, 14 Nov 2017 08:54:12 -0800 (PST) X-AuditID: c1b4fb3a-c5bff70000004c48-e1-5a0b1fb33f0c Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 6D.69.19528.3BF1B0A5; Tue, 14 Nov 2017 17:54:11 +0100 (CET) Received: from EUR01-DB5-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.352.0; Tue, 14 Nov 2017 17:54:11 +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=YcfFMPyOYwbrvoxoLnVFDL34oa8YQCNu7pES/TiXOEY=; b=W3p6/BF/t3EtXVR6A1s+24hmscK4mZ0vlML7LMRwZ9Ng5B1m5Xx/BoJUTJIsHB1fHB1W4ovYnE1MeD0zViP0T806b+F03Opm5omVrVSmO6Es/n5iKP9VRIAWF/THeeS1GjU7tISN6nPPfd+a0/j5A0iiqhmd2fYRdBLPX3XMkQ4= Received: from AM2PR07MB0563.eurprd07.prod.outlook.com (10.160.32.21) by VI1PR07MB3247.eurprd07.prod.outlook.com (10.175.243.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Tue, 14 Nov 2017 16:54:09 +0000 Received: from AM2PR07MB0563.eurprd07.prod.outlook.com ([fe80::51b:b1d2:5312:ddb6]) by AM2PR07MB0563.eurprd07.prod.outlook.com ([fe80::51b:b1d2:5312:ddb6%15]) with mapi id 15.20.0239.004; Tue, 14 Nov 2017 16:54:07 +0000 From: Salvatore Loreto To: Marcus Ihlar , Roni Even CC: Ian Swett , QUIC WG , "emile.stephan@orange.com" Subject: RE: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFwAJsv0AAAE+vIAAAeM/AAABBYeg Date: Tue, 14 Nov 2017 16:54:07 +0000 Message-ID: References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <6E58094ECC8D8344914996DAD28F1CCD836D79@DGGEMM506-MBX.china.huawei.com> <37B26B29-2193-443B-8B27-0CF68A8619CA@ericsson.com> In-Reply-To: <37B26B29-2193-443B-8B27-0CF68A8619CA@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [31.133.152.63] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB3247; 6:lfAoAPd8vqcIStujYQjfMVNjwxkLD8pMRucXdvtvpomwGu6VpchmnBS+Kmnq8uOkyifMYP4nlYxC0gVZN3jBRFLUBCCiEtVkEp8e57OIrQYyETCwOe5b9K0WBet7QrVJjn5JBVMoxyx4exBpYZuoN8KFZl3Bf+WG//CKa6q+fIe9ZditJA41uaE48cE3JmQHPDWlYy54DGlz0UtpGdGrtmIwT6P0L9jeTZE5EOfKa4lE8fQS0u8yQCvbU5M7e0+PoKEBomknAeGn30mWaUOqt+Jdq8+nNB0B3hSEHSzJhhGuPPVC30e+VzldbW9ladq664D0O43sEw7PXcb2r9uGIdV/4VXh7hQqf7opasfK3EQ=; 5:ApHd/PBhb/rBz4uYsHgnFbC3JYvizUaPdHVNjRDDX9uzpoZpzmNhrHqDJ89FWyMOwFflFb/WQISCkyQ/gRJxfyFvYufvpPjRMaGkntJ+MmlQt4bntxnhnvG9lsI/NajfTHzjVDkK3FEpffoHoHUtf7hCziLVhoCf45BlzWqfNo8=; 24:YR4e1R05N0GcqnZFcYBaea2p9G7k70NIUc6iArO8caXc2/LvEtYFMvI8i7i+NYnBrOXGEqczQ3Wthi0MsEAmcZNYSAFrvEAfgwXy/Oh0JY0=; 7:PqW4r3eKHPTzk8dTTO2/stdf2+lNFBaSOUfQq+XudB6CmPLnbBL6vZK1PCMsJejT2ti6y3wv/oz3IAtS5h5vMv9YtfUu7Tk9l3qFEBxOJFc6DLceeNZsRR7Olgri9HjfvDUxRNDFQ2rltyCBgdiNe7/lmK0YGIEDZaU6l4yb9SeSS/w849kX1m1lPAi27Az49BTdwiLtGLGpY1UubYDKoFYZ9JU9kUDMNt2BCUNrncL19bXHDILm4gc+qqOHrEN3 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(346002)(376002)(39860400002)(24454002)(51444003)(199003)(189002)(76176999)(54356999)(33656002)(53546010)(50986999)(189998001)(53936002)(99936001)(101416001)(68736007)(229853002)(4326008)(478600001)(6116002)(3846002)(790700001)(102836003)(14454004)(55016002)(316002)(66066001)(54906003)(110136005)(6246003)(97736004)(81156014)(93886005)(6436002)(106356001)(6506006)(105586002)(81166006)(7736002)(2950100002)(74316002)(7696004)(5660300001)(99286004)(6306002)(236005)(8936002)(5250100002)(2906002)(86362001)(2900100001)(34040400001)(3660700001)(54896002)(3280700002)(9686003)(8676002)(5890100001)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:VI1PR07MB3247; H:AM2PR07MB0563.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 8c970317-bb44-497d-9fc7-08d52b805245 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258)(49563074); SRVR:VI1PR07MB3247; x-ms-traffictypediagnostic: VI1PR07MB3247: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(50582790962513)(211936372134217)(227612066756510)(153496737603132)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231022)(920507027)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR07MB3247; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR07MB3247; x-forefront-prvs: 04916EA04C received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=salvatore.loreto@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01D35D71.8F62C9A0" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8c970317-bb44-497d-9fc7-08d52b805245 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2017 16:54:07.7333 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB3247 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA1WSa0hTYRjHec9tc2txnK4ezCinfZnkvRgaohAyocJvlQk56qSiTjlnShco PyjIzFx5KWempY0ywUuWl4TcUlPLtDBFLcPSJO2CJmiWrm3vhPr2e27///O8vGJSvkZ7iVN0 eo7XadOUjIQqP9aq2PtwlzQ+6M6Yt9rydJVS/5pqp9WXq6Xqpd4hKorSVDdnaXK7v9Ga2tpf hCb3cz8TR8VLDpzm0lKyOT4wMlGS3G/rpDNLnqGz85M9ZA4abUIG5CYGNgy61lfsLBHL2WcI xgrqXUEfgqI1C+0IKLaQhAHDAI0rZQQsr46QOJhGYHvcxjjEGHY/zE23kA72ZI/AbJ/BaUKy WTBXe8/JHmwAfKjsQrgnEEzFEy6OgT/1G4QBie12e6D9uo8jLWMTwJzzWYS9XhFga2yiHAU3 NgqMDV1OX8Rug5WBegJ7bYeJmSoCH+cJ069fMJgV8OXTBu3QB9YHRs2xOL0T3lQVOE8G1iqC t42PXLOhYDB20rhwl4HWwW8EHj4MGz8v4XwNgvWvV1yiKng+cgbPpsLS+0KX6C0EZT0VIhzM 02B70kbhLm/oupnHGNFe0z+Lm+x9JFuIoONqO2NyPoE79JfPULjpBFg/GUWY/WF2fJbaZPPt BdJkX4S0L1Jjiv0/7eAIuLFmYTD7QEnBtEtmHyz0LKJqJK1DCoEThPSkkJAAjk85JQgZugAd p29G9l9oafkd3oYsc9FWxIqRcotsi7c0Xk5rs4Vz6VbkZ9f52PhgGHlRugwdp/SUtZsk8XLZ ae258xyfcZLPSuMEK9ohppTbZRpP+ySbpNVzqRyXyfGbVULs5pWDIvWLk/nzp1SqhF71wHDK TJvtd6lC+iMyLu6QmaywLSz5NhwPiXG/X/muv3q91KPjWrHane8Y8o/u5qdawgsk43nE5aMT P5Z7siJ8Ms/uTgwNKr7wfXVx7WJC2KKoaGhrX5PRb0Qfpwg2K9xmdL5JSfkjBxMH6/KDhiNe 5tc2flRSQrI2WEXygvYvDJAQ4I0DAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 16:54:16 -0000 ------=_NextPart_000_000D_01D35D71.8F62C9A0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_000E_01D35D71.8F62C9A0" ------=_NextPart_001_000E_01D35D71.8F62C9A0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable +1 Latency is the most crucial component needed in Quic version 1 =20 Also considering the fact that QUIC will be either most likely adopted = in 3GPP for 5G SBA and the majority of the traffic in 5G networks QUIC (per Georg Mayer = mail on those points) Operators will have to make sure to keep the latency really low in 5G = networks and they will be measured on latency. =20 /Sal =20 From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Marcus Ihlar Sent: den 14 november 2017 17:21 To: Roni Even Cc: Ian Swett ; QUIC WG ; = emile.stephan@orange.com Subject: Re: spin bit in QUIC: troubleshooting =20 +1 on Ronis statement below.=20 Let us begin with latency, which is the most crucial component to have = in place.=20 As V1 gets deployed we will get a better understanding of what else = might be needed.=20 On 14 Nov 2017, at 23:27, Roni Even > wrote: I think that latency is what we need right now. Once we understand more about quic and packet loss (will ECN be used = reducing packet loss) and other functionality we can see what else is = needed. This may be done in next version using variants. Roni =20 From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett Sent: =D7=99=D7=95=D7=9D =D7=92 14 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 = 2017 16:51 To: emile.stephan@orange.com =20 Cc: QUIC WG Subject: Re: spin bit in QUIC: troubleshooting =20 What would the other bit or two be used for? If there is no = standardized use of those bits in v1, then I believe we should wait to = reserve them when their usage is defined, given we'd need a version bump = to specify how they were being used. At the moment, the management use = case is not competing with anyone else for bits in the short header. =20 On Tue, Nov 14, 2017 at 5:14 AM, > wrote: Hi =20 Last week Orange experienced a fallback of QUIC to TCP on one of its = networks. The issues were not visible in QUIC traffic. The = troubleshooting was made using TCP packets information. This is not = sustainable on the long term when numerous applications using different = versions of QUIC will stop to fallback to TCP. =20 Based on the exchange we had in the RTT design team and in today meeting = , it sounds reasonable to reserve at least 2 bits (ideally 3 bits as = discussed in the design team) for manageability in the QUIC invariants = and to start experimenting the spin bit in QUIC V1. =20 Regards Emile =20 _________________________________________________________________________= ________________________________________________ =20 Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme = ou falsifie. Merci. =20 This message and its attachments may contain confidential or privileged = information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and = delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. Thank you. =20 ------=_NextPart_001_000E_01D35D71.8F62C9A0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

+1=

Latency is = the most crucial component needed in Quic version = 1

 

Also = considering the fact that QUIC will be either most likely adopted in = 3GPP for 5G SBA

and the = majority of the traffic in 5G networks QUIC (per Georg Mayer mail on = those points)

Operators = will have to make sure to keep the latency really low in 5G networks and = they

will be = measured on latency.

 

/Sal

 

From:<= /b> = QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Marcus = Ihlar
Sent: den 14 november 2017 17:21
To: Roni Even = <roni.even@huawei.com>
Cc: Ian Swett = <ianswett@google.com>; QUIC WG <quic@ietf.org>; = emile.stephan@orange.com
Subject: Re: spin bit in QUIC: = troubleshooting

 

+1 on Ronis = statement below. 

Let us begin with latency, which is the most crucial = component to have in place. 

As V1 gets deployed we will get a better understanding = of what else might be needed. 


On 14 Nov 2017, at = 23:27, Roni Even <roni.even@huawei.com> = wrote:

I think that latency is what we need right now.

Once we understand more about quic and packet loss (will ECN be used = reducing packet loss) and other functionality we can see what else is = needed. This may be done in next version using = variants.

Roni

 

From: QUIC = [mailto:quic-bounces@ietf.org] = On Behalf Of Ian Swett
Sent: =D7=99=D7=95=D7= =9D =D7=92 14 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 = 16:51
To:= emile.stephan@orange.com
= Cc: QUIC WG
Subject: Re: spin bit in QUIC: = troubleshooting

 

What = would the other bit or two be used for?  If there is no = standardized use of those bits in v1, then I believe we should wait to = reserve them when their usage is defined, given we'd need a version bump = to specify how they were being used.  At the moment, the management = use case is not competing with anyone else for bits in the short = header.

 

On Tue, = Nov 14, 2017 at 5:14 AM, <emile.stephan@orange.com> = wrote:

Hi<= /span>

&nb= sp;

Las= t week Orange experienced a fallback of QUIC to TCP on one of its = networks. The issues were not visible in QUIC traffic. The = troubleshooting was made using TCP packets information. This is not = sustainable on the long term when numerous applications using different = versions of QUIC will stop to fallback to TCP.

&nb= sp;

Bas= ed on the exchange we had in the RTT design team and in today meeting , = it sounds reasonable to reserve at least 2 bits (ideally 3 bits as = discussed in the design team) for manageability in the QUIC invariants = and to start experimenting the spin bit in QUIC = V1.

&nb= sp;

Reg= ards

Emi= le

 <= /o:p>

_______________________________________________________________=
__________________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des =
informations confidentielles ou privilegiees et ne doivent =
donc
pas etre diffuses, =
exploites ou copies sans autorisation. Si vous avez recu ce message par =
erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. =
Les messages electroniques etant susceptibles =
d'alteration,
Orange decline =
toute responsabilite si ce message a ete altere, deforme ou falsifie. =
Merci.
 
This =
message and its attachments may contain confidential or privileged =
information that may be protected by =
law;
they should not be =
distributed, used or copied without =
authorisation.
If you have =
received this email in error, please notify the sender and delete this =
message and its attachments.
As emails may be altered, Orange is not liable for messages =
that have been modified, changed or =
falsified.
Thank =
you.

 

------=_NextPart_001_000E_01D35D71.8F62C9A0-- ------=_NextPart_000_000D_01D35D71.8F62C9A0 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIVWjCCAyAw ggIIoAMCAQICAR0wDQYJKoZIhvcNAQEFBQAwOTELMAkGA1UEBhMCRkkxDzANBgNVBAoTBlNvbmVy YTEZMBcGA1UEAxMQU29uZXJhIENsYXNzMiBDQTAeFw0wMTA0MDYwNzI5NDBaFw0yMTA0MDYwNzI5 NDBaMDkxCzAJBgNVBAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFz czIgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCQF0o1ncrwDZbHRPoWN/xIvb1/ gC01O+FvqGepvwMcTYxvMkfVQWikEwTBNQyahEP8XB3/ibPoFxjNkV/7iePqv05dfBsm03V57eaE 41flrSnE9Doo56V7hDZps/1edr2jLZnTkE4jKH0YY/FUOyaddluXQrL/rvBO7N05lU6DBn/nSUDI xQGyVFpmHT38+ek8Cp6BuHDwAYvkI1R8yK74kB4AlnLUVM9hI7zq+50CldG2uXE6aQg/D7ThQseI 9T+YqKe6HOBxce9YV4FQelxrdEYOgwOYw46obvJ2Mm4ng8Jz89wY6LST6nVEawRgIHFXh53zvqCQ Iz2KJOHaIdvDAgMBAAGjMzAxMA8GA1UdEwEB/wQFMAMBAf8wEQYDVR0OBAoECEqgqliE0148MAsG A1UdDwQEAwIBBjANBgkqhkiG9w0BAQUFAAOCAQEAWs6H+RZyFVdLHdmb56ImMOyTZ9/WLdI0r/c4 pc6rFrmrL3w1y6zQD7RMK/yA72uMkV82dvfbsxsZ6vSyEf1hcUS/KLM6Hb+zQ+ifv9wxCHGwnY3W NEcykMZlJPegSnwEc485bxeMcrW9S8h6+HuDwyhOnAnqZz+yZwQbwxTa+OdJJJHQHWr6YTnva+ch dQYH2BK0ISBwQnGB2jyaNr6mWw1qbJofkXv5+e9Cuk5OnswMjZTc2UWcXuxCUGOu9F3EsRLcyjuo Lp0UWgV1t+zXY+K6NbYECJHo2p2c9ma1GKwKplQmNDPSG8HUfxo6jguqMm7b/E8ln9kyx5ZacKzf TDCCBX0wggRloAMCAQICEQDR4D5bSO3Hngk/QN7hYcOLMA0GCSqGSIb3DQEBBQUAMDkxCzAJBgNV BAYTAkZJMQ8wDQYDVQQKEwZTb25lcmExGTAXBgNVBAMTEFNvbmVyYSBDbGFzczIgQ0EwHhcNMDcx MDE4MTI1MjAxWhcNMTkxMDE3MDUwNDExWjA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UE AwwWVGVsaWFTb25lcmEgUm9vdCBDQSB2MTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIB AMK+6yfwIaPzaSZVfp3FVRaRXP3vIb9TgHot0pGMYzHw7CTww6XScnwQbfQ3t+XmfHnqjLWCi65I tqwA3GV17CpNX8GH9SBlK4GoRz6JI5UwFpB/6FcHSOcZrr9FZ7E3GwYq/t75rH2D+1665I+XZ75L jo1kB1c4VWk0Nj0TSO9P4tNmHqTPGrdeNjPUtAa9GAH9d4RQAEX1jF3oI7x+/jXh7VB7qTCNGdMJ jmhnXb88lxhTuylixcpecsHHltTbLaC0H2kD7OriUPEMPPCs81Mt8Bz17Ww5OXOAFshSsCPN4D7c 3TxHoLs1iuKYaIu+5b9y7tL6pe0S7fyYGKkmdtwoSxAgHNN/Fnct7W+A90m7UwW7XWjH1Mh1Fj+J Wov3F0fUTPHSiXk+TT2YqGHeOh7S+F4D4MHJHIzTjU3TlTazN19jY5szFPAtJmtTfImMMsJu7D0h ADnJoWjiUIMusDor8zagrC/kb2HCUQk5PotTubtn2txTuXZZNp1D5SDgPTJghSJRt8czu90VL6R4 pgd7gUY2BIbdeTXHlSw7sKMXNeVzH7RcWe/a6hBle3rQf5+ztCo3O3CLm1u5K7fsslESl1MpWtTw EhDcTwK7EpIvYtQ/aUN8Ddb8WHUBiJ1YFkveupD/RwGJBmr2X7KQarMCpgKIv7NHfirZ1fpoeDVN AgMBAAGjggGAMIIBfDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMmh0dHA6Ly9jYS50cnVz dC50ZWxpYXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY2VyMA8GA1UdEwEB/wQFMAMBAf8wGQYD VR0gBBIwEDAOBgwrBgEEAYIPAgMBAQIwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBTwj1k4ALP1 j5qWDNXr+nuqF+gTEjCBuQYDVR0fBIGxMIGuMG+gbaBrhmlsZGFwOi8vY3JsLTEudHJ1c3QudGVs aWFzb25lcmEuY29tL2NuPVNvbmVyYSUyMENsYXNzMiUyMENBLG89U29uZXJhLGM9Rkk/Y2VydGlm aWNhdGVyZXZvY2F0aW9ubGlzdDtiaW5hcnkwO6A5oDeGNWh0dHA6Ly9jcmwtMi50cnVzdC50ZWxp YXNvbmVyYS5jb20vc29uZXJhY2xhc3MyY2EuY3JsMBMGA1UdIwQMMAqACEqgqliE0148MA0GCSqG SIb3DQEBBQUAA4IBAQB7L2bVGhb4q6FZUtsGVNbneHh+Q5OmrXeyTfAHxWAg90PVlDgAY0+cBk4o PxOL9ZVGnhec070CdiGWHwrqqKER1uDC2H97BTr3jBzGl9mf/43MxbY7NJB9LHMONfDeF+V+8bMK ziBdedr0HocKuKtBbzbvChOkDOaAKZkqCVXEC4+x1AUwqx4++t6D3aSnC3+1CWt2+AXfXrIzjE6p AKqZcnJfrI2mqIatmAtaXvW12I8TyZR+ERIMcOVGIa4MYfxxSpz0TSSz94DWfLK3DlKiXaxT+Tqo k3yH1wZhC+6q/11vPLL52cPWk2HciFDaylK2u3watcxmk8kaxNEt6K5zMIIF9zCCA9+gAwIBAgIQ J0lp3dorWxgq9FlRgcZjZzANBgkqhkiG9w0BAQUFADA6MREwDwYDVQQKDAhFcmljc3NvbjElMCMG A1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MjAeFw0xNDEyMDMwOTA1MjVaFw0xNzEy MDMwOTA1MjRaMG4xETAPBgNVBAoMCEVyaWNzc29uMRkwFwYDVQQDDBBTYWx2YXRvcmUgTG9yZXRv MSwwKgYJKoZIhvcNAQkBFh1zYWx2YXRvcmUubG9yZXRvQGVyaWNzc29uLmNvbTEQMA4GA1UEBRMH dGVpbG9zYTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAI2TwjL8WyfvKabcljazgAlA rhNFKMxWqRNRfz8X6A3pEa3mc14U7coF5hFYwCSjgkK3P+7jcbkdibjNxefyF0GS73ghXWtE8hSQ /rrK2gjXO758ebrD7X4hUHAqwEOL0/BoTCpNO6SxNBidmhMyRf60nHPLubS+M2IMZgMsLdFP/KaP nYQgAf5CaQ2q//UjDVFonyAySt5bF7vGCqu+on6b+noYWmxBJsRUVjHPm+GHrE0Go8PSQEXQCE/K hbDtwgoVn9IeTJI2ysLa9saZO3FfUYejgzegOXcq07cAcb+wWe31lKSNRp0yMRoj78KvJlVSN8Q4 lWSGFZ+0P+tbW+cCAwEAAaOCAcMwggG/MEgGA1UdHwRBMD8wPaA7oDmGN2h0dHA6Ly9jcmwudHJ1 c3QudGVsaWEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2Mi5jcmwwgYIGCCsGAQUFBwEBBHYw dDAoBggrBgEFBQcwAYYcaHR0cDovL29jc3AyLnRydXN0LnRlbGlhLmNvbTBIBggrBgEFBQcwAoY8 aHR0cDovL2NhLnRydXN0LnRlbGlhc29uZXJhLmNvbS9lcmljc3Nvbm5saW5kaXZpZHVhbGNhdjIu Y2VyMCgGA1UdEQQhMB+BHXNhbHZhdG9yZS5sb3JldG9AZXJpY3Nzb24uY29tMFUGA1UdIAROMEww SgYMKwYBBAGCDwIDAQESMDowOAYIKwYBBQUHAgEWLGh0dHBzOi8vcmVwb3NpdG9yeS50cnVzdC50 ZWxpYXNvbmVyYS5jb20vQ1BTMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNVHQ4E FgQUx1yDCWQOOg82wL87joacNfMxn3wwHwYDVR0jBBgwFoAUsQ3K1Ea3r4YCwy9vBsoOdnF/Szcw DgYDVR0PAQH/BAQDAgWgMA0GCSqGSIb3DQEBBQUAA4ICAQADoVxptsgW22Er7BM6ASs4CtFQla/A 5ZMLloZKszE2OgRuiOqJvqPZCHy/eDmCVw/3bctu7WAv823JmcdQlXcLiK9K37BdFSE4Iuzh/ANM 6Icx+Q2nHHUUURexot9IH0d4VZj4WuUMyHXFkdNwGzH3jS7U8GF+9aD+iBJn/hjuAhvRFmQns/4k 3e8dKlvS5tIBxB4cLdLbMV2sUxv4Z9XYsb4D3k1awv9/E6OwyJVhdtrwNVaJ/2Vp2zU/0EWhoraA dyZoFWJBXOF/xYyVl84aK6Tx+NW7f537y5vRsq6+XaM+j91wKajxwWicJv3hx6ZfNtLpKbRuy/jn qIJIdQApSLt/4b4ZHHgilkVLjm3AJJDsE13RjpYYO6ssoWOo7kj73XsWtHiwnyhFCf+4oFjgLTlo uzm6rtBunH5Xgt4EIyKKZsh5hd/GGzHWuv2JzLyrAxLNiPGXZ4e5tyhvBujRNw6husYYtDFUdSqf VhH9/a4WJVmLLgEXw5Q8BSxxM487Hu7csCVX9BPXr+9DDdfHUr67rtzGBE0oGHKouA3lmxn/rngK Q/8CfDgk71+v1xasa6XhMmh2oaYgZU2OmYyUzUc7NH5RANOMbxivU/UPT3WEsQeH39cllwK12a// BwAC1gntYtP0d0GVE7Q9hvOoO872TCQqzzdDfF6Z1csHWjCCBrYwggSeoAMCAQICEQCgDMvMm5mY 7OI6cPR8wcBZMA0GCSqGSIb3DQEBBQUAMDcxFDASBgNVBAoMC1RlbGlhU29uZXJhMR8wHQYDVQQD DBZUZWxpYVNvbmVyYSBSb290IENBIHYxMB4XDTE0MDUyNzA3NDYyMVoXDTI0MDUyNzA3NDYyMVow OjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0Eg djIwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQDaulPrX0iWU5+JOOqjddx4Gnl17DJh klkoXOgOSBMhW6FzGVt5RR7KPv+rjt2YpbwdoqWSYa4VPkS/72vuQoWsvz2avWWXhPTdNzrB3zs5 cJO7sKIyd+LRy4l/8kKK4iPm+Q18XyGF0xTuc5WS3WiMScJSxEKdIOP8xehBraHZabrGh9OxQHC4 iBHkzD0YF3J/vBqBTr7blRzYf1h3j5a7qVIHCPfz+eCE175mResXDQRI7LvMiZtVaqitBl0oAJiJ yeBmvEujBNsIEgUQ6JcQFG5ny0EazLywv7clwb7izvLgoXc6SFrd0D7TGJtkdldVJtMwDYXpyFMG AijT6uf8h2kuPIwrDgQFNEyIQZ4q52ZpRGwugC6sMxgHEDGjA/CxX9aC5Vi1EMRJiOGF6gV3T+V5 yHDHSBBeQbVAXm8wSTDBfXQwdro/AXqET0mG6Rpe4q2FGBaauE8qHEO6qR3WAEgvjVfFU2k6xZx1 qmvwhkXadxh6ZIMXzgb6WpjivLnR0GEKNrgN2DXdvo+6eAt45Bhvmeka2TrJDxMLWiBy8QYgNeNX YQsuREnDsjWo6wF0LqbA5769om9nn/uJzmzxb3nT1iHue5co9J93ta06kxiASHvcIzZwAOjKnmk0 vR3IT7Qbzq2of3E1s18xo8DM9D91Cak0Nq+RALtdv1uZKQIDAQABo4IBuDCCAbQwgYoGCCsGAQUF BwEBBH4wfDAtBggrBgEFBQcwAYYhaHR0cDovL29jc3AudHJ1c3QudGVsaWFzb25lcmEuY29tMEsG CCsGAQUFBzAChj9odHRwOi8vcmVwb3NpdG9yeS50cnVzdC50ZWxpYXNvbmVyYS5jb20vdGVsaWFz b25lcmFyb290Y2F2MS5jZXIwEgYDVR0TAQH/BAgwBgEB/wIBADBVBgNVHSAETjBMMEoGDCsGAQQB gg8CAwEBAjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25l cmEuY29tL0NQUzBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsLTMudHJ1c3QudGVsaWFzb25l cmEuY29tL3RlbGlhc29uZXJhcm9vdGNhdjEuY3JsMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEF BQcDBDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0OBBYEFLENytRGt6+GAsMvbwbKDnZxf0s3MB8GA1Ud IwQYMBaAFPCPWTgAs/WPmpYM1ev6e6oX6BMSMA0GCSqGSIb3DQEBBQUAA4ICAQBuByBsr6x3PZBC smGbcSZ/XL+0tnVMblInoJgL1Bh3PiRicgdo8l+6cvWp/ArBwMYNwSNyrvY9IewyaV8n65c5oN+l 2JDUuzrdANVKnYxha7ZyCEiPmY98sB2bnZgxfJLXQYoRwI7pOOwfyoP2fCYVCd+xhsfysYiIl4OR zE3TpeppQ2yWkyBBmoHUXJh97ue6+bJ2fqnVUoOVMVnYYEtvsz67v7w2z3fvdcy04/RnoylxSenx ADi1tY9iIydHMgyOu3dfzsxU8AivMGG4aKStsCfUEyg0LlkbhqMrdness3e1qAEueSRNASLfpFwy RmzmiuNh9onzuhER2yYhK/6IeCs4HQHrPhkY8JUmhtmdL2uErOZWOs38FQhGWHWXI0g6SgdDObU0 GEHju0MkDziOhm+BVwPZKN7B7wD7OPj6vlLVo6d8vLGK9bywhEfXjxLIC3Qhtu5lJPTgIo5Bup+a BBjiJ/u9BfqryqZpudnWfG+wxC327rpNAq2OKdFsR92wbehSZD3mSSAemDVwGB2Yu0XHQYyyYfpW sGyGEyRSHKFhRwJdINPzWLI89wy4Wc+PgqyekkEmJqe6g4XSQFj4mqtwvqhP4dg2QCcKM/bh62Rw fM7GeSS/LFGe84KmJjTDfvT8c2rK8nEyZ/emOtwCGXQ6tZCByMNLxeDwU1TGbTGCA0QwggNAAgEB ME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwg Q0EgdjICECdJad3aK1sYKvRZUYHGY2cwCQYFKw4DAhoFAKCCAcswGAYJKoZIhvcNAQkDMQsGCSqG SIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTcxMTE0MTY1NDA0WjAjBgkqhkiG9w0BCQQxFgQU0+H0 1L8tR5gfGp3Mv5dZaqipAiYwXQYJKwYBBAGCNxAEMVAwTjA6MREwDwYDVQQKDAhFcmljc3NvbjEl MCMGA1UEAwwcRXJpY3Nzb24gTkwgSW5kaXZpZHVhbCBDQSB2MgIQJ0lp3dorWxgq9FlRgcZjZzBf BgsqhkiG9w0BCRACCzFQoE4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAjBgNVBAMMHEVyaWNzc29u IE5MIEluZGl2aWR1YWwgQ0EgdjICECdJad3aK1sYKvRZUYHGY2cwgasGCSqGSIb3DQEJDzGBnTCB mjALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggq hkiG9w0DAgICAIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4D AhowCwYJYIZIAWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwDQYJKoZIhvcNAQEBBQAE ggEAg72f/GeBgj3n7fArbhOomp5602zzMZWKp9dx/Ih2IOIJu5F0JNSc4BapIH7oGaF6Cb2psEmS r/ll8KLquNmmkBuxpKQZrjQcisiU7aFoU1jgUmmO7zVaZqqAKx7cQTlFjvY5rP1tGFOhsO6K8H5H tDF/HWtYZm2/ERnALY2ktdq2kwwtPUL8a7f+kU21MVT9V1/NgMdoP4u5eOZFxSe2YD0d+kwxNePL er6gbJkJrzIPxhcsq6MEYf84jAf5N+9G1wbt2BezB+MyirjbA72rn7W+LGOlPwSWEzIV2y1CWwek NrGZbEUKzokmzUfE2z+kqa5V0kRtWEefd8mat1+KSwAAAAAAAA== ------=_NextPart_000_000D_01D35D71.8F62C9A0-- From nobody Tue Nov 14 10:06: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 AD1A3127517 for ; Tue, 14 Nov 2017 10:06:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kMuFafcu87UE for ; Tue, 14 Nov 2017 10:06:22 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 966B6127005 for ; Tue, 14 Nov 2017 10:06:22 -0800 (PST) Received: from opfednr02.francetelecom.fr (unknown [xx.xx.xx.66]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id E214C180C9B; Tue, 14 Nov 2017 19:06:20 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr02.francetelecom.fr (ESMTP service) with ESMTP id C14F5120065; Tue, 14 Nov 2017 19:06:20 +0100 (CET) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 19:06:20 +0100 From: To: Ian Swett CC: QUIC WG Subject: RE: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFwAHmowAAAeL0sA= Date: Tue, 14 Nov 2017 18:06:20 +0000 Message-ID: <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67BOPEXCLILM44corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 18:06:25 -0000 --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67BOPEXCLILM44corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgSWFuLA0KDQpJdCB3YXMgc3VnZ2VzdGVkIGluIHRoZSBsYXRlc3QgZGlzY3Vzc2lvbiBvbiB0 aGUgUlRUIGRlc2lnbiB0ZWFtIG1haWxpbmcgbGlzdCB0byBoYXZlIG9uZSBiaXQgZm9yIHBhY2tl dCBsb3N0LCBvbmUgZm9yIGxhdGVuY3kgKHNwaW4gYml0IG9yIGVxLikgYW5kIG9uZSBmb3IgY29u Z2VzdGlvbi4NCkl0IHNlZW1zIGEgc2ltcGxpc3RpYyBhcHByb2FjaCBvbiBvbmUgaGFuZCBidXQg YW4gaW52YXJpYW50IG9uIHRoZSBsb25nIHRlcm0uDQoNClJlZ2FyZHMNCkVtaWxlDQoNCg0KRGUg OiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXQ0KRW52b3nDqSA6IG1hcmRp IDE0IG5vdmVtYnJlIDIwMTcgMjI6NTENCsOAIDogU1RFUEhBTiBFbWlsZSBJTVQvT0xODQpDYyA6 IFFVSUMgV0cNCk9iamV0IDogUmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVzaG9vdGluZw0K DQpXaGF0IHdvdWxkIHRoZSBvdGhlciBiaXQgb3IgdHdvIGJlIHVzZWQgZm9yPyAgSWYgdGhlcmUg aXMgbm8gc3RhbmRhcmRpemVkIHVzZSBvZiB0aG9zZSBiaXRzIGluIHYxLCB0aGVuIEkgYmVsaWV2 ZSB3ZSBzaG91bGQgd2FpdCB0byByZXNlcnZlIHRoZW0gd2hlbiB0aGVpciB1c2FnZSBpcyBkZWZp bmVkLCBnaXZlbiB3ZSdkIG5lZWQgYSB2ZXJzaW9uIGJ1bXAgdG8gc3BlY2lmeSBob3cgdGhleSB3 ZXJlIGJlaW5nIHVzZWQuICBBdCB0aGUgbW9tZW50LCB0aGUgbWFuYWdlbWVudCB1c2UgY2FzZSBp cyBub3QgY29tcGV0aW5nIHdpdGggYW55b25lIGVsc2UgZm9yIGJpdHMgaW4gdGhlIHNob3J0IGhl YWRlci4NCg0KT24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgNToxNCBBTSwgPGVtaWxlLnN0ZXBoYW5A b3JhbmdlLmNvbTxtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPj4gd3JvdGU6DQpIaQ0K DQpMYXN0IHdlZWsgT3JhbmdlIGV4cGVyaWVuY2VkIGEgZmFsbGJhY2sgb2YgUVVJQyB0byBUQ1Ag b24gb25lIG9mIGl0cyBuZXR3b3Jrcy4gVGhlIGlzc3VlcyB3ZXJlIG5vdCB2aXNpYmxlIGluIFFV SUMgdHJhZmZpYy4gVGhlIHRyb3VibGVzaG9vdGluZyB3YXMgbWFkZSB1c2luZyBUQ1AgcGFja2V0 cyBpbmZvcm1hdGlvbi4gVGhpcyBpcyBub3Qgc3VzdGFpbmFibGUgb24gdGhlIGxvbmcgdGVybSB3 aGVuIG51bWVyb3VzIGFwcGxpY2F0aW9ucyB1c2luZyBkaWZmZXJlbnQgdmVyc2lvbnMgb2YgUVVJ QyB3aWxsIHN0b3AgdG8gZmFsbGJhY2sgdG8gVENQLg0KDQpCYXNlZCBvbiB0aGUgZXhjaGFuZ2Ug d2UgaGFkIGluIHRoZSBSVFQgZGVzaWduIHRlYW0gYW5kIGluIHRvZGF5IG1lZXRpbmcgLCBpdCBz b3VuZHMgcmVhc29uYWJsZSB0byByZXNlcnZlIGF0IGxlYXN0IDIgYml0cyAoaWRlYWxseSAzIGJp dHMgYXMgZGlzY3Vzc2VkIGluIHRoZSBkZXNpZ24gdGVhbSkgZm9yIG1hbmFnZWFiaWxpdHkgaW4g dGhlIFFVSUMgaW52YXJpYW50cyBhbmQgdG8gc3RhcnQgZXhwZXJpbWVudGluZyB0aGUgc3BpbiBi aXQgaW4gUVVJQyBWMS4NCg0KUmVnYXJkcw0KRW1pbGUNCg0KDQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMN Cg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRp b24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUg c2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGli bGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0K DQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlk ZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5 IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5n ZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hh bmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgph IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67BOPEXCLILM44corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBD YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLlByZm9ybWF0SFRNTENh cg0KCXttc28tc3R5bGUtbmFtZToiUHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250 LWZhbWlseTpDb25zb2xhczsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpGUjt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibGFjazsNCglmb250LXdlaWdodDpub3JtYWw7 DQoJZm9udC1zdHlsZTpub3JtYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgltc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIu MHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0K ZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1b aWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1h eD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9 IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9k eSBsYW5nPSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3Jk U2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkhpIElhbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 YmxhY2siPkl0IHdhcyBzdWdnZXN0ZWQgaW4gdGhlIGxhdGVzdCBkaXNjdXNzaW9uIG9uIHRoZSBS VFQgZGVzaWduIHRlYW0gbWFpbGluZyBsaXN0IHRvIGhhdmUgb25lIGJpdCBmb3IgcGFja2V0IGxv c3QsIG9uZSBmb3IgbGF0ZW5jeSAoc3BpbiBiaXQgb3IgZXEuKSBhbmQNCiBvbmUgZm9yIGNvbmdl c3Rpb24uIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5JdCBzZWVtcyBh IHNpbXBsaXN0aWMgYXBwcm9hY2ggb24gb25lIGhhbmQgYnV0IGFuIGludmFyaWFudCBvbiB0aGUg bG9uZyB0ZXJtLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJkczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FbWlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPiBJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUu Y29tXQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1hcmRpIDE0IG5vdmVtYnJlIDIwMTcg MjI6NTE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IFNURVBIQU4gRW1pbGUgSU1UL09MTjxicj4NCjxi PkNjJm5ic3A7OjwvYj4gUVVJQyBXRzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IHNwaW4g Yml0IGluIFFVSUM6IHRyb3VibGVzaG9vdGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPldoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBmb3I/Jm5i c3A7IElmIHRoZXJlIGlzIG5vIHN0YW5kYXJkaXplZCB1c2Ugb2YgdGhvc2UgYml0cyBpbiB2MSwg dGhlbiBJIGJlbGlldmUgd2Ugc2hvdWxkIHdhaXQgdG8gcmVzZXJ2ZSB0aGVtIHdoZW4gdGhlaXIg dXNhZ2UgaXMgZGVmaW5lZCwgZ2l2ZW4gd2UnZCBuZWVkIGEgdmVyc2lvbiBidW1wIHRvIHNwZWNp ZnkgaG93IHRoZXkgd2VyZSBiZWluZw0KIHVzZWQuJm5ic3A7IEF0IHRoZSBtb21lbnQsIHRoZSBt YW5hZ2VtZW50IHVzZSBjYXNlIGlzIG5vdCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBmb3Ig Yml0cyBpbiB0aGUgc2hvcnQgaGVhZGVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgNToxNCBBTSwgJmx0OzxhIGhy ZWY9Im1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5lbWls ZS5zdGVwaGFuQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOmJsYWNrIj5IaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TGFzdCB3ZWVrIE9yYW5nZSBleHBl cmllbmNlZCBhIGZhbGxiYWNrIG9mIFFVSUMgdG8gVENQIG9uIG9uZSBvZiBpdHMgbmV0d29ya3Mu IFRoZSBpc3N1ZXMNCiB3ZXJlIG5vdCB2aXNpYmxlIGluIFFVSUMgdHJhZmZpYy4gVGhlIHRyb3Vi bGVzaG9vdGluZyB3YXMgbWFkZSB1c2luZyBUQ1AgcGFja2V0cyBpbmZvcm1hdGlvbi4gVGhpcyBp cyBub3Qgc3VzdGFpbmFibGUgb24gdGhlIGxvbmcgdGVybSB3aGVuIG51bWVyb3VzIGFwcGxpY2F0 aW9ucyB1c2luZyBkaWZmZXJlbnQgdmVyc2lvbnMgb2YgUVVJQyB3aWxsIHN0b3AgdG8gZmFsbGJh Y2sgdG8gVENQLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkJhc2VkIG9uIHRoZSBl eGNoYW5nZSB3ZSBoYWQgaW4gdGhlIFJUVCBkZXNpZ24gdGVhbSBhbmQgaW4gdG9kYXkgbWVldGlu ZyAsIGl0IHNvdW5kcyByZWFzb25hYmxlDQogdG8gcmVzZXJ2ZSBhdCBsZWFzdCAyIGJpdHMgKGlk ZWFsbHkgMyBiaXRzIGFzIGRpc2N1c3NlZCBpbiB0aGUgZGVzaWduIHRlYW0pIGZvciBtYW5hZ2Vh YmlsaXR5IGluIHRoZSBRVUlDIGludmFyaWFudHMgYW5kIHRvIHN0YXJ0IGV4cGVyaW1lbnRpbmcg dGhlIHNwaW4gYml0IGluIFFVSUMgVjEuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ UmVnYXJkczwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkVtaWxlPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cHJlPl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5DZSBt ZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1h dGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8 bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIg ZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s PG86cD48L286cD48L3ByZT4NCjxwcmU+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBv ciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86 cD48L286cD48L3ByZT4NCjxwcmU+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3ByZT4NCjxwcmU+ SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86 cD48L286cD48L3ByZT4NCjxwcmU+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMg bm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRoYW5rIHlvdS48bzpwPjwvbzpw PjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBz ZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRp ZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2 ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdl eHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExl cyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24s Ck9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUg YWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9y bWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxz IG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBo YXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJF PjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67BOPEXCLILM44corp_-- From nobody Tue Nov 14 13:21: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 A9E46128799 for ; Tue, 14 Nov 2017 13:21:15 -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 (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 r3ykhqi0FJXg for ; Tue, 14 Nov 2017 13:21:12 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::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 7B35A1293DF for ; Tue, 14 Nov 2017 13:21:12 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id r127so15281603itb.5 for ; Tue, 14 Nov 2017 13:21: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=QstPUSA7Tb+q4R7ShqhZUvgCFzFIjSGxtHlyEW47kug=; b=vNtRd+ACaZtMQ5BmWyz/fGO9OHgkQFCajDlDkPe79lzqTZg7x53DIG+fTHUDjxjzL4 /yBelqLZrlZNlkgiY0zwfvXDSXK5+UtRoCP0oPscAq2D7tzWjZ+oaHvjsAi0PViXKr6J 1QkffKHnjswmhG5sLBoru8Ne/gKP+Xw6czw9iO4xwCDQHnZ/5wEneeoPaspIlhbQliIa IHwZV9oFxdClKgPpNYLUvwVX111blv1KWLAAEeroTxhKd1b/GnLM217wXWQVIIQ5oZ4Y h9HDg3rE9TkZGGbNDailaqxZfOi3O3oQ23OaSWcQyxAp0sNcFAoMrz9sKy2R6OpoVOrt 1dGg== 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=QstPUSA7Tb+q4R7ShqhZUvgCFzFIjSGxtHlyEW47kug=; b=QmSO5BTIBTSigfY4c7DQKDSDznxVXa1ffx1FUINC3qwmBPC7YX/D21sBXrEH+yC3oj tDI2BzYy5+X5G3efl1TBL+8oimWQ/kHwP2dLi69MVPmMwk93Ud68D9dW27F0gryd4E7d ExfcQxl7K+ZtgfaEESmBNQyFWPYUEEa05J8hKnGSXylzMMPD8uOvRunLC8afvWPop55a R18za9VmoTRyHWgPISglcX6Ne1ZW2Q2WuQcMqNJvph4R/w2q2lembPtpO2A4mErO+FBt wc/xZ6IYROQbN+Xxv0u//1lgj6q9MXcI0/oX6dlULQjKyyXNKRpFtqDtaRI8FfMnZOQ+ sKXw== X-Gm-Message-State: AJaThX6WgC5Am1KKgh8Jm1rfgPWomr/MlyVIktSaQTbUAwi5he9e/fK0 AWCpUkrG1Z1jQ3UWc21KwPMKgpxb4b8jcQQL8d7hDg== X-Google-Smtp-Source: AGs4zMYSalUDBW+xPYZ7qNM2vJEyCgSvFrhVcFEoxhfSCYJo0JXYWqW67jD0Y5pbEq67Yr/YHYUMAVQPTTDSGuZ0x8s= X-Received: by 10.36.39.8 with SMTP id g8mr10022408ita.42.1510694471596; Tue, 14 Nov 2017 13:21:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.3.193 with HTTP; Tue, 14 Nov 2017 13:20:50 -0800 (PST) In-Reply-To: <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> From: Ian Swett Date: Tue, 14 Nov 2017 16:20:50 -0500 Message-ID: Subject: Re: spin bit in QUIC: troubleshooting To: emile.stephan@orange.com Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a1147c5ac589462055df7f7dd" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 21:21:16 -0000 --001a1147c5ac589462055df7f7dd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for clarifying Emile. On Tue, Nov 14, 2017 at 1:06 PM, wrote: > Hi Ian, > > > > It was suggested in the latest discussion on the RTT design team mailing > list to have one bit for packet lost, one for latency (spin bit or eq.) a= nd > one for congestion. > > It seems a simplistic approach on one hand but an invariant on the long > term. > > > > Regards > > Emile > > > > > > *De :* Ian Swett [mailto:ianswett@google.com] > *Envoy=C3=A9 :* mardi 14 novembre 2017 22:51 > *=C3=80 :* STEPHAN Emile IMT/OLN > *Cc :* QUIC WG > *Objet :* Re: spin bit in QUIC: troubleshooting > > > > What would the other bit or two be used for? If there is no standardized > use of those bits in v1, then I believe we should wait to reserve them wh= en > their usage is defined, given we'd need a version bump to specify how the= y > were being used. At the moment, the management use case is not competing > with anyone else for bits in the short header. > > > > On Tue, Nov 14, 2017 at 5:14 AM, wrote: > > Hi > > > > Last week Orange experienced a fallback of QUIC to TCP on one of its > networks. The issues were not visible in QUIC traffic. The troubleshootin= g > was made using TCP packets information. This is not sustainable on the lo= ng > term when numerous applications using different versions of QUIC will sto= p > to fallback to TCP. > > > > Based on the exchange we had in the RTT design team and in today meeting = , > it sounds reasonable to reserve at least 2 bits (ideally 3 bits as > discussed in the design team) for manageability in the QUIC invariants an= d > to start experimenting the spin bit in QUIC V1. > > > > Regards > > Emile > > > > _________________________________________________________________________= ________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > > they should not be distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > > Thank you. > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confid= entielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez re= cu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u falsifie. Merci. > > This message and its attachments may contain confidential or privileged i= nformation that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and de= lete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n modified, changed or falsified. > Thank you. > > --001a1147c5ac589462055df7f7dd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for clarifying Emile.

On Tue, Nov 14, 2017 at 1:06 PM, <emile.stephan@orange.com> wrote:

Hi Ian,=

=C2=A0<= u>

It was suggest= ed in the latest discussion on the RTT design team mailing list to have one= bit for packet lost, one for latency (spin bit or eq.) and one for congestion.

It seems a sim= plistic approach on one hand but an invariant on the long term.

=C2=A0<= u>

Regards=

Emile

=C2=A0<= u>

=C2=A0<= u>

De=C2=A0: Ian = Swett [mailto:ians= wett@google.com]
Envoy=C3=A9=C2=A0: mardi 14 novembre 2017 22:51
=C3=80=C2=A0: STEPHAN Emile IMT/OLN
Cc=C2=A0: QUIC WG
Objet=C2=A0: Re: spin bit in QUIC: troubleshooting

=C2=A0

What would the other bit or two be used for?=C2=A0 I= f there is no standardized use of those bits in v1, then I believe we shoul= d wait to reserve them when their usage is defined, given we'd need a v= ersion bump to specify how they were being used.=C2=A0 At the moment, the management use case is not competing with a= nyone else for bits in the short header.

=C2=A0

On Tue, Nov 14, 2017 at 5:14 AM, <emile.stephan@orange.com= > wrote:

Hi

=C2=A0

Last week Oran= ge experienced a fallback of QUIC to TCP on one of its networks. The issues were not visible in QUIC traffic. The troubleshooting was made using TCP p= ackets information. This is not sustainable on the long term when numerous = applications using different versions of QUIC will stop to fallback to TCP.=

=C2=A0<= u>

Based on the e= xchange we had in the RTT design team and in today meeting , it sounds reas= onable to reserve at least 2 bits (ideally 3 bits as discussed in the design team= ) for manageability in the QUIC invariants and to start experimenting the s= pin bit in QUIC V1.

=C2=A0<= u>

Regards=

Emile

=C2=A0

____________________________________________________________=
_____________________________________________________________<=
/u>
=C2=A0
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les me=
ssages electroniques etant susceptibles d'alteration,

Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.


=C2=A0


This message and its attachments may contain confidential or privilege=
d information that may be protected by law;


they should not be distributed, used or copied without authorisation.<=
u>


If you have received this email in error, please notify the sender and=
 delete this message and its attachments.


As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.


Thank you.

=C2=A0

____________________________________________________________=
_____________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message=
s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--001a1147c5ac589462055df7f7dd-- From nobody Tue Nov 14 17:11: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 2BBB0129451 for ; Tue, 14 Nov 2017 17:11:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 KZA_IHeFUEol for ; Tue, 14 Nov 2017 17:11:14 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E699129423 for ; Tue, 14 Nov 2017 17:11:14 -0800 (PST) Received: from pps.filterd (m0048589.ppops.net [127.0.0.1]) by m0048589.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id vAF18BPR047015; Tue, 14 Nov 2017 20:11:11 -0500 Received: from flpd657.enaf.ffdc.sbc.com (sbcsmtp9.sbc.com [144.160.128.153]) by m0048589.ppops.net-00191d01. with ESMTP id 2e89p0jcnj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Nov 2017 20:11:11 -0500 Received: from enaf.ffdc.sbc.com (localhost [127.0.0.1]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id vAF1BAIA060770; Tue, 14 Nov 2017 17:11:10 -0800 Received: from zlp25947.vci.att.com (zlp25947.vci.att.com [135.213.92.137]) by flpd657.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id vAF1B6B8060736; Tue, 14 Nov 2017 17:11:07 -0800 Received: from zlp25947.vci.att.com (zlp25947.vci.att.com [127.0.0.1]) by zlp25947.vci.att.com (Service) with ESMTP id D8347400050E; Wed, 15 Nov 2017 01:11:06 +0000 (GMT) Received: from flpi487.ffdc.sbc.com (unknown [130.4.162.181]) by zlp25947.vci.att.com (Service) with ESMTPS id BBECD4000515; Wed, 15 Nov 2017 01:11:06 +0000 (GMT) Received: from CAFRFD1MSGHUBAG.ITServices.sbc.com (CAFRFD1MSGHUBAG.itservices.sbc.com [130.4.169.164]) by flpi487.ffdc.sbc.com (RSA Interceptor); Wed, 15 Nov 2017 01:10:47 GMT Received: from CAFRFD1MSGUSRJI.ITServices.sbc.com ([169.254.8.228]) by CAFRFD1MSGHUBAG.ITServices.sbc.com ([130.4.169.164]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 17:10:47 -0800 From: "DRUTA, DAN" To: Ian Swett CC: "emile.stephan@orange.com" , QUIC WG Subject: Re: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFwAadoYAAAbTAwAABsr3AP//uiLU Date: Wed, 15 Nov 2017 01:10:46 +0000 Message-ID: <822FABC6-2BF5-47E1-91D7-AF25F77BC5BE@att.com> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_822FABC62BF547E191D7AF25F77BC5BEattcom_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150014 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 01:11:16 -0000 --_000_822FABC62BF547E191D7AF25F77BC5BEattcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I will add my support for the inclusion of the spin bit into V1 and make a = few more points. Considering that the design team analysis concluded that the spin bit does = not add any additional privacy risk and the very specific need addressing l= atency has been documented and validated by a large number of WG members, I= believe the QUIC working group has a unique opportunity to show that we ca= n design protocols that are efficient, privacy sensitive and network manage= ment friendly. This particular design, while not perfect does have the biggest benefit rel= ative to the risks and it should be adopted from the beginning. Best Regards, Dan On Nov 15, 2017, at 5:21 AM, Ian Swett > wrote: Thanks for clarifying Emile. On Tue, Nov 14, 2017 at 1:06 PM, > wrote: Hi Ian, It was suggested in the latest discussion on the RTT design team mailing li= st to have one bit for packet lost, one for latency (spin bit or eq.) and o= ne for congestion. It seems a simplistic approach on one hand but an invariant on the long ter= m. Regards Emile De : Ian Swett [mailto:ianswett@google.com] Envoy=E9 : mardi 14 novembre 2017 22:51 =C0 : STEPHAN Emile IMT/OLN Cc : QUIC WG Objet : Re: spin bit in QUIC: troubleshooting What would the other bit or two be used for? If there is no standardized u= se of those bits in v1, then I believe we should wait to reserve them when = their usage is defined, given we'd need a version bump to specify how they = were being used. At the moment, the management use case is not competing w= ith anyone else for bits in the short header. On Tue, Nov 14, 2017 at 5:14 AM, > wrote: Hi Last week Orange experienced a fallback of QUIC to TCP on one of its networ= ks. The issues were not visible in QUIC traffic. The troubleshooting was ma= de using TCP packets information. This is not sustainable on the long term = when numerous applications using different versions of QUIC will stop to fa= llback to TCP. Based on the exchange we had in the RTT design team and in today meeting , = it sounds reasonable to reserve at least 2 bits (ideally 3 bits as discusse= d in the design team) for manageability in the QUIC invariants and to start= experimenting the spin bit in QUIC V1. Regards Emile ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_822FABC62BF547E191D7AF25F77BC5BEattcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I will add my support for the inclusion of the spin bit into V1 and make a = few more points.
Considering that the design team analysis concluded that the spin bit = does not add any additional privacy risk and the very specific need address= ing latency has been documented and validated by a large number of WG membe= rs, I believe the QUIC working group has a unique opportunity to show that we can design protocols that are eff= icient, privacy sensitive and network management friendly.
This particular design, while not perfect does have the biggest benefi= t relative to the risks and it should be adopted from the beginning.

Best Regards,
Dan


On Nov 15, 2017, at 5:21 AM, Ian Swett <ianswett@google.com> wrote:

Thanks for clarifying Emile.

On Tue, Nov 14, 2017 at 1:06 PM, <emile.= stephan@orange.com> wrote:

Hi Ian,=

 <= u>

It was suggest= ed in the latest discussion on the RTT design team mailing list to have one= bit for packet lost, one for latency (spin bit or eq.) and one for congestion.

It seems a sim= plistic approach on one hand but an invariant on the long term.

 <= u>

Regards=

Emile

 <= u>

 <= u>

De : Ian = Swett [mailto:ians= wett@google.com]
Envoy=E9 : mardi 14 novembre 2017 22:51
=C0 : STEPHAN Emile IMT/OLN
Cc : QUIC WG
Objet : Re: spin bit in QUIC: troubleshooting

 

What would the other bit or two be used for?  I= f there is no standardized use of those bits in v1, then I believe we shoul= d wait to reserve them when their usage is defined, given we'd need a versi= on bump to specify how they were being used.  At the moment, the management use case is not competing with a= nyone else for bits in the short header.

 

On Tue, Nov 14, 2017 at 5:14 AM, <emile.stephan@orange.com= > wrote:

Hi

 

Last week Oran= ge experienced a fallback of QUIC to TCP on one of its networks. The issues= were not visible in QUIC traffic. The troubleshooting was made using TCP packets information. This is not sustainable on the long te= rm when numerous applications using different versions of QUIC will stop to= fallback to TCP.

 <= u>

Based on the e= xchange we had in the RTT design team and in today meeting , it sounds reas= onable to reserve at least 2 bits (ideally 3 bits as discussed in the design team) for manageability in the QUIC invariants and to start = experimenting the spin bit in QUIC V1.

 <= u>

Regards=

Emile

 

____________________________________________________________=
_____________________________________________________________<=
/u>
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
u>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.

 

____________________________________________________________=
_____________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.

--_000_822FABC62BF547E191D7AF25F77BC5BEattcom_-- From nobody Tue Nov 14 17:24: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 9735412940B for ; Tue, 14 Nov 2017 17:24:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 gtKacWubSscC for ; Tue, 14 Nov 2017 17:24:30 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0099.outbound.protection.outlook.com [104.47.1.99]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 464E8126CD6 for ; Tue, 14 Nov 2017 17:24:30 -0800 (PST) Received: from VI1PR0601MB2431.eurprd06.prod.outlook.com (10.173.84.135) by VI1PR0601MB2430.eurprd06.prod.outlook.com (10.173.83.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Wed, 15 Nov 2017 01:24:27 +0000 Received: from VI1PR0601MB2431.eurprd06.prod.outlook.com ([fe80::c062:bf8:cc99:33eb]) by VI1PR0601MB2431.eurprd06.prod.outlook.com ([fe80::c062:bf8:cc99:33eb%17]) with mapi id 15.20.0218.015; Wed, 15 Nov 2017 01:24:27 +0000 From: JESUS MARIA MARTIN GARCIA To: "sanjay.mishra@verizon.com" , QUIC WG Subject: RE: spin bit in QUIC Thread-Topic: spin bit in QUIC Thread-Index: AdNdInWu9OoodX6pTBa2nSIjjM2p0wABTQNQACIWFrA= Date: Wed, 15 Nov 2017 01:24:27 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD836BC1@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: es-ES, en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jesusmaria.martingarcia@telefonica.com; x-originating-ip: [2001:67c:370:128:85d9:8d79:7054:cf26] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR0601MB2430; 6:frtDfRhg6LApJxQf79M8sioKNPLClZEDcy9IzDDN/topSNQyHryHG8/bEGJ8zw7K/3Q678ri5F1iXi/bFuGXyV8dy1B6E4f9AYu+lYJXwZ+lC9KsU3Y65cEN056yYKh+FflysBKmTB6yUcG0gC5PGnCR+ImUSvV6ORUqNhNvWZxu8OFs2n7idiySnhVAkaye7rNqXQHXUK3o/hkwoinLNulZCWRe71V0sICwK5WqYUtnAOklF08H+fT2zpmqdyj91qfGYBVtdRLOYYcBdYNW5CiMBYZGt2eTuNE2EL/vi0qjrgiDurdeZZLIUkEc5a+QPTyIx+IZrvGRJ7ncC24rlH9WxYCtrkdxOS1OarAcL0k=; 5:3yg5N9mk8oZcr/N4RO1UWj8pEl1/04JWAuHRCXda4VMA5mG95uuj8xlnudWTDpY3NRmDwOK/q9vbjI/VXVnXjj696aPT/HozecXzrH2AouJJ5ha+OXFgq0hoAowVX0MCnsPmrdET77NyrUbIueoYceh5U7o3YXM8YtJlFe56obg=; 24:+vrImQw0Aq898wTw0WOoxEkcCTTm1m+azZfMDst5uixztMS/76GvpbMSPTXU26tfekqozCjwSv3MkbJ6BYfttifBGobp0jtuoDiR+kuonZI=; 7:y8HcJ5U2DCLiGqY3hob6v9aQs4x7/VrykZn8EYjvBZ2zKw9/3ftZJ4qeWvxcIucazF2SvvFFKaZEhORuO2M/PzbE+voRDHj8Gp7YOm+zvc7Rx7McAs1JkfyJXNEwGawT9oIyDXhsXaqyENpgdaoPo+SW736bFWOG0dGar7GNqvBalDurlO8OiWwL/GnpQRS0fzF2opvnghVNulHG9clCeDGdCCgeFIFaFQM8od8EPJ6oe/alc4SD+FOrk6wPbXqF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2a36ecf2-f335-4c34-4f03-08d52bc79d16 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:VI1PR0601MB2430; x-ms-traffictypediagnostic: VI1PR0601MB2430: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(50582790962513)(227612066756510)(21748063052155)(154440410675630); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3002001)(3231022)(6055026)(6041248)(20161123560025)(20161123564025)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:VI1PR0601MB2430; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:VI1PR0601MB2430; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(189002)(40134004)(25724002)(199003)(8676002)(2950100002)(81166006)(81156014)(86362001)(99286004)(5660300001)(7696004)(6306002)(54896002)(5250100002)(55016002)(53936002)(97736004)(3280700002)(2900100001)(110136005)(14454004)(68736007)(8936002)(316002)(2501003)(6506006)(2906002)(229853002)(6436002)(786003)(7736002)(74316002)(76176999)(54356999)(25786009)(50986999)(101416001)(3480700004)(53346004)(3660700001)(53546010)(105586002)(6116002)(102836003)(6246003)(478600001)(790700001)(33656002)(189998001)(236005)(106356001)(9686003)(9010500006)(19627235001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0601MB2430; H:VI1PR0601MB2431.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR0601MB24316996BD50FEF4FBDF53D591290VI1PR0601MB2431_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2a36ecf2-f335-4c34-4f03-08d52bc79d16 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 01:24:27.5983 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0601MB2430 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 01:24:35 -0000 --_000_VI1PR0601MB24316996BD50FEF4FBDF53D591290VI1PR0601MB2431_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 Even with the limitations known, the spin bit will allow service providers = to measure latency in the network for troubleshooting. That's why I want to add my support for the inclusion of the spin bit into = V1 BR Jesus Make a small change everyday Jes=FAs Mart=EDn | Telef=F3nica S.A. De: QUIC [mailto:quic-bounces@ietf.org] En nombre de sanjay.mishra@verizon.= com Enviado el: martes, 14 de noviembre de 2017 10:38 Para: QUIC WG CC: Roni Even Asunto: RE: spin bit in QUIC Adding to what Roni has below, first, I applaud to the spin bit design for = their time since the Prague meeting and many thanks to Ted for presenting t= hose findings. >From Ted's presentation, it appears that the design team accomplished what = they were asked to do, that is, look at geolocation threat and Min RTT. Sli= de 7 from Ted's presentation lays out negligible threat and at least not an= y additional adversarial information. Given this, I would have thought des= ign team to be less tentative and come to a clear consensus. Also, agree with Marcus on his enumeration on the need for spin bit and as = Roni pointed out inclusion of spin but in v1 gives us some real -world depl= oyment experience on performance and bottlenecks. I ask the chairs to add spin bit for v1. -Sanjay From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, November 14, 2017 4:41 PM To: QUIC WG > Subject: [E] spin bit in QUIC Hi, It is good that the conclusion about the geo location security issue is tha= t the spin bit does not add privacy risk on top of what can be done without= it. As for the spin bit. RTT calculation are used for trouble shooting in TCP s= ee in draft-even-quic-troubleshooting-video-delivery-00. The spin bit will provide similar functionality even though it is less reli= able as was mentioned since it is not part of the QUIC state machine. We envision that we will see a lot of QUIC traffic in the network and havin= g the spin bit can help with identifying bottle necks in the network and re= ducing QUIC latency. It will be important to have the spin bit in V1 and t= he main text is already in the github Thanks Roni Even ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_VI1PR0601MB24316996BD50FEF4FBDF53D591290VI1PR0601MB2431_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1

 

Even with the limitations known, the spin bit will allow service providers to = measure latency in the network for troubleshooting.

 

That’s why I want to add my support for the inclusion of the spin bit in= to V1

 

BR

Jesus

Make a = small change everyday

 

Jes=FAs= Mart=EDn = | Telef=F3nica S.A.

 

De: QUIC [mailto:quic-bounces@ietf.org] En= nombre de sanjay.mishra@verizon.com
Enviado el: martes, 14 de noviembre de 2017 10:38
Para: QUIC WG <quic@ietf.org>
CC: Roni Even <roni.even@huawei.com>
Asunto: RE: spin bit in QUIC

 

Adding = to what Roni has below, first, I applaud to the spin bit design for their t= ime since the Prague meeting and many thanks to Ted for presenting those fi= ndings.

&n= bsp;

From Te= d’s presentation, it appears that the design team accomplished what t= hey were asked to do, that is, look at geolocation threat and Min RTT. Slid= e 7 from Ted’s presentation lays out negligible threat and at least not any additional adversarial information.  Give= n this, I would have thought design team to be less tentative and come to a= clear consensus.

&n= bsp;

Also, a= gree with Marcus on his enumeration on the need for spin bit and as Roni po= inted out inclusion of spin but in v1 gives us some real –world deplo= yment experience on performance and bottlenecks.

&n= bsp;

I ask t= he chairs to add spin bit for v1.

&n= bsp;

-Sanjay=

&n= bsp;

&n= bsp;

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Tuesday, November 14, 2017 4:41 PM
To: QUIC WG <quic@ietf.org>
Subject: [E] spin bit in QUIC

 

Hi,

It is good that the conclusion = about the geo location security issue is that the spin bit does not add pri= vacy risk on top of what can be done without it.

 

As for the spin bit. RTT calcul= ation are used for trouble shooting in TCP see in draft-even-quic-troublesh= ooting-video-delivery-00.

The spin bit will provide simil= ar functionality even though it is less reliable as was mentioned since it = is not part of the QUIC state machine.

We envision that we will see a = lot of QUIC traffic in the network and having the spin bit can help with id= entifying bottle necks in the network and reducing QUIC latency.  It w= ill be important to have the spin bit in V1 and the main text is already in the github

 

Thanks

Roni Even

 

 

 



Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o
 --_000_VI1PR0601MB24316996BD50FEF4FBDF53D591290VI1PR0601MB2431_-- From nobody Tue Nov 14 17:35: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 D79F9126DFB for ; Tue, 14 Nov 2017 17:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 0ym_zGCjL7Fx for ; Tue, 14 Nov 2017 17:35:29 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 02CB4128AFE for ; Tue, 14 Nov 2017 17:35:29 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id ACB5457B8B054 for ; Wed, 15 Nov 2017 01:35:25 +0000 (GMT) Received: from NKGEML411-HUB.china.huawei.com (10.98.56.70) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 01:35:26 +0000 Received: from NKGEML513-MBS.china.huawei.com ([169.254.2.198]) by nkgeml411-hub.china.huawei.com ([10.98.56.70]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 09:35:20 +0800 From: "Huangyihong (Rachel)" To: "DRUTA, DAN" , Ian Swett CC: QUIC WG , "emile.stephan@orange.com" Subject: Re: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdsWjQPILy0zGdSpeKMlxWVn7JTQ== Date: Wed, 15 Nov 2017 01:35:19 +0000 Message-ID: <51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1@nkgeml513-mbs.china.huawei.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.45.77] Content-Type: multipart/alternative; boundary="_000_51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1nkgeml513mbschi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 01:35:32 -0000 --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1nkgeml513mbschi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdOKAmXMgYSBnb29kIHBvaW50LiBJIHJlYWxseSB0aGluayB0aGUgYmFsYW5jZSBzaG91bGQg YmUgYWNoaWV2ZWQgYmV0d2VlbiBwcml2YWN5IGFuZCBvcGVyYXRpb24uIFNwaW4gYml0IGlzIGEg Z29vZCBleGFtcGxlLiBJIHN1cHBvcnQgaXQuDQoNCkJSLA0KUmFjaGVsDQoNCuWPkeS7tuS6ujog UVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIERSVVRBLCBEQU4NCuWP kemAgeaXtumXtDogMjAxN+W5tDEx5pyIMTXml6UgOToxMQ0K5pS25Lu25Lq6OiBJYW4gU3dldHQg PGlhbnN3ZXR0QGdvb2dsZS5jb20+DQrmioTpgIE6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBl bWlsZS5zdGVwaGFuQG9yYW5nZS5jb20NCuS4u+mimDogUmU6IHNwaW4gYml0IGluIFFVSUM6IHRy b3VibGVzaG9vdGluZw0KDQpJIHdpbGwgYWRkIG15IHN1cHBvcnQgZm9yIHRoZSBpbmNsdXNpb24g b2YgdGhlIHNwaW4gYml0IGludG8gVjEgYW5kIG1ha2UgYSBmZXcgbW9yZSBwb2ludHMuDQpDb25z aWRlcmluZyB0aGF0IHRoZSBkZXNpZ24gdGVhbSBhbmFseXNpcyBjb25jbHVkZWQgdGhhdCB0aGUg c3BpbiBiaXQgZG9lcyBub3QgYWRkIGFueSBhZGRpdGlvbmFsIHByaXZhY3kgcmlzayBhbmQgdGhl IHZlcnkgc3BlY2lmaWMgbmVlZCBhZGRyZXNzaW5nIGxhdGVuY3kgaGFzIGJlZW4gZG9jdW1lbnRl ZCBhbmQgdmFsaWRhdGVkIGJ5IGEgbGFyZ2UgbnVtYmVyIG9mIFdHIG1lbWJlcnMsIEkgYmVsaWV2 ZSB0aGUgUVVJQyB3b3JraW5nIGdyb3VwIGhhcyBhIHVuaXF1ZSBvcHBvcnR1bml0eSB0byBzaG93 IHRoYXQgd2UgY2FuIGRlc2lnbiBwcm90b2NvbHMgdGhhdCBhcmUgZWZmaWNpZW50LCBwcml2YWN5 IHNlbnNpdGl2ZSBhbmQgbmV0d29yayBtYW5hZ2VtZW50IGZyaWVuZGx5Lg0KVGhpcyBwYXJ0aWN1 bGFyIGRlc2lnbiwgd2hpbGUgbm90IHBlcmZlY3QgZG9lcyBoYXZlIHRoZSBiaWdnZXN0IGJlbmVm aXQgcmVsYXRpdmUgdG8gdGhlIHJpc2tzIGFuZCBpdCBzaG91bGQgYmUgYWRvcHRlZCBmcm9tIHRo ZSBiZWdpbm5pbmcuDQpCZXN0IFJlZ2FyZHMsDQpEYW4NCg0KDQpPbiBOb3YgMTUsIDIwMTcsIGF0 IDU6MjEgQU0sIElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRA Z29vZ2xlLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5nIEVtaWxlLg0KDQpPbiBU dWUsIE5vdiAxNCwgMjAxNyBhdCAxOjA2IFBNLCA8ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPG1h aWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIElhbiwNCg0KSXQgd2Fz IHN1Z2dlc3RlZCBpbiB0aGUgbGF0ZXN0IGRpc2N1c3Npb24gb24gdGhlIFJUVCBkZXNpZ24gdGVh bSBtYWlsaW5nIGxpc3QgdG8gaGF2ZSBvbmUgYml0IGZvciBwYWNrZXQgbG9zdCwgb25lIGZvciBs YXRlbmN5IChzcGluIGJpdCBvciBlcS4pIGFuZCBvbmUgZm9yIGNvbmdlc3Rpb24uDQpJdCBzZWVt cyBhIHNpbXBsaXN0aWMgYXBwcm9hY2ggb24gb25lIGhhbmQgYnV0IGFuIGludmFyaWFudCBvbiB0 aGUgbG9uZyB0ZXJtLg0KDQpSZWdhcmRzDQpFbWlsZQ0KDQoNCkRlIDogSWFuIFN3ZXR0IFttYWls dG86aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT5dDQpFbnZv ecOpIDogbWFyZGkgMTQgbm92ZW1icmUgMjAxNyAyMjo1MQ0Kw4AgOiBTVEVQSEFOIEVtaWxlIElN VC9PTE4NCkNjIDogUVVJQyBXRw0KT2JqZXQgOiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJs ZXNob290aW5nDQoNCldoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBmb3I/ ICBJZiB0aGVyZSBpcyBubyBzdGFuZGFyZGl6ZWQgdXNlIG9mIHRob3NlIGJpdHMgaW4gdjEsIHRo ZW4gSSBiZWxpZXZlIHdlIHNob3VsZCB3YWl0IHRvIHJlc2VydmUgdGhlbSB3aGVuIHRoZWlyIHVz YWdlIGlzIGRlZmluZWQsIGdpdmVuIHdlJ2QgbmVlZCBhIHZlcnNpb24gYnVtcCB0byBzcGVjaWZ5 IGhvdyB0aGV5IHdlcmUgYmVpbmcgdXNlZC4gIEF0IHRoZSBtb21lbnQsIHRoZSBtYW5hZ2VtZW50 IHVzZSBjYXNlIGlzIG5vdCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBmb3IgYml0cyBpbiB0 aGUgc2hvcnQgaGVhZGVyLg0KDQpPbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCA1OjE0IEFNLCA8ZW1p bGUuc3RlcGhhbkBvcmFuZ2UuY29tPG1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+PiB3 cm90ZToNCkhpDQoNCkxhc3Qgd2VlayBPcmFuZ2UgZXhwZXJpZW5jZWQgYSBmYWxsYmFjayBvZiBR VUlDIHRvIFRDUCBvbiBvbmUgb2YgaXRzIG5ldHdvcmtzLiBUaGUgaXNzdWVzIHdlcmUgbm90IHZp c2libGUgaW4gUVVJQyB0cmFmZmljLiBUaGUgdHJvdWJsZXNob290aW5nIHdhcyBtYWRlIHVzaW5n IFRDUCBwYWNrZXRzIGluZm9ybWF0aW9uLiBUaGlzIGlzIG5vdCBzdXN0YWluYWJsZSBvbiB0aGUg bG9uZyB0ZXJtIHdoZW4gbnVtZXJvdXMgYXBwbGljYXRpb25zIHVzaW5nIGRpZmZlcmVudCB2ZXJz aW9ucyBvZiBRVUlDIHdpbGwgc3RvcCB0byBmYWxsYmFjayB0byBUQ1AuDQoNCkJhc2VkIG9uIHRo ZSBleGNoYW5nZSB3ZSBoYWQgaW4gdGhlIFJUVCBkZXNpZ24gdGVhbSBhbmQgaW4gdG9kYXkgbWVl dGluZyAsIGl0IHNvdW5kcyByZWFzb25hYmxlIHRvIHJlc2VydmUgYXQgbGVhc3QgMiBiaXRzIChp ZGVhbGx5IDMgYml0cyBhcyBkaXNjdXNzZWQgaW4gdGhlIGRlc2lnbiB0ZWFtKSBmb3IgbWFuYWdl YWJpbGl0eSBpbiB0aGUgUVVJQyBpbnZhcmlhbnRzIGFuZCB0byBzdGFydCBleHBlcmltZW50aW5n IHRoZSBzcGluIGJpdCBpbiBRVUlDIFYxLg0KDQpSZWdhcmRzDQpFbWlsZQ0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIg ZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRv aXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5z IGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2 ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNw b25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZp ZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQo= --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1nkgeml513mbschi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOWui+S9kyI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OuW+rui9r+mbhem7kTsNCglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3Nl LTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNv Tm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmi hOiuvuagvOW8jyBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5I VE1MQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28t c3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgOTAuMHB0IDcyLjBwdCA5MC4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGF04oCZcyBhIGdvb2QgcG9pbnQuIEkgcmVh bGx5IHRoaW5rIHRoZSBiYWxhbmNlIHNob3VsZCBiZSBhY2hpZXZlZCBiZXR3ZWVuIHByaXZhY3kg YW5kIG9wZXJhdGlvbi4gU3BpbiBiaXQgaXMgYSBnb29kIGV4YW1wbGUuIEkgc3VwcG9ydCBpdC4N CjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5CUiw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJhY2hlbDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFF MSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9 r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwv c3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IFFVSUMg W21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddDQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMt c2VyaWYiPuS7o+ihqCA8L3NwYW4+DQo8L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNl cmlmIj5EUlVUQSwgREFOPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+rui9r+mbhem7kSZxdW90OyxzYW5zLXNlcmlmIj7lj5Hp gIHml7bpl7Q8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/p m4Xpu5EmcXVvdDssc2Fucy1zZXJpZiI+IDIwMTc8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LHNhbnMtc2VyaWYi PuW5tDxzcGFuIGxhbmc9IkVOLVVTIj4xMTwvc3Bhbj7mnIg8c3BhbiBsYW5nPSJFTi1VUyI+MTU8 L3NwYW4+5pelPHNwYW4gbGFuZz0iRU4tVVMiPg0KIDk6MTE8YnI+DQo8L3NwYW4+PGI+5pS25Lu2 5Lq6PHNwYW4gbGFuZz0iRU4tVVMiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIj4gSWFu IFN3ZXR0ICZsdDtpYW5zd2V0dEBnb29nbGUuY29tJmd0Ozxicj4NCjwvc3Bhbj48Yj7mioTpgIE8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBRVUlDIFdH ICZsdDtxdWljQGlldGYub3JnJmd0OzsgZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPGJyPg0KPC9z cGFuPjxiPuS4u+mimDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJF Ti1VUyI+IFJlOiBzcGluIGJpdCBpbiBRVUlDOiB0cm91Ymxlc2hvb3Rpbmc8bzpwPjwvbzpwPjwv c3Bhbj48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSB3aWxsIGFkZCBteSBzdXBwb3J0IGZvciB0 aGUgaW5jbHVzaW9uIG9mIHRoZSBzcGluIGJpdCBpbnRvIFYxIGFuZCBtYWtlIGEgZmV3IG1vcmUg cG9pbnRzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5Db25zaWRlcmluZyB0aGF0IHRoZSBkZXNpZ24gdGVhbSBh bmFseXNpcyBjb25jbHVkZWQgdGhhdCB0aGUgc3BpbiBiaXQgZG9lcyBub3QgYWRkIGFueSBhZGRp dGlvbmFsIHByaXZhY3kgcmlzayBhbmQgdGhlIHZlcnkgc3BlY2lmaWMgbmVlZCBhZGRyZXNzaW5n IGxhdGVuY3kgaGFzIGJlZW4gZG9jdW1lbnRlZCBhbmQgdmFsaWRhdGVkIGJ5IGEgbGFyZ2UgbnVt YmVyIG9mIFdHIG1lbWJlcnMsDQogSSBiZWxpZXZlIHRoZSBRVUlDIHdvcmtpbmcgZ3JvdXAgaGFz IGEgdW5pcXVlIG9wcG9ydHVuaXR5IHRvIHNob3cgdGhhdCB3ZSBjYW4gZGVzaWduIHByb3RvY29s cyB0aGF0IGFyZSBlZmZpY2llbnQsIHByaXZhY3kgc2Vuc2l0aXZlIGFuZCBuZXR3b3JrIG1hbmFn ZW1lbnQgZnJpZW5kbHkuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+VGhpcyBwYXJ0aWN1bGFyIGRlc2lnbiwgd2hpbGUgbm90IHBlcmZlY3QgZG9lcyBo YXZlIHRoZSBiaWdnZXN0IGJlbmVmaXQgcmVsYXRpdmUgdG8gdGhlIHJpc2tzIGFuZCBpdCBzaG91 bGQgYmUgYWRvcHRlZCBmcm9tIHRoZSBiZWdpbm5pbmcuPG86cD48L286cD48L3NwYW4+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMy4wcHQiPkJlc3QgUmVnYXJkcyw8L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5EYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij48YnI+DQpPbiBOb3YgMTUsIDIwMTcsIGF0IDU6MjEgQU0sIElhbiBTd2V0dCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhhbmtzIGZvciBjbGFyaWZ5 aW5nIEVtaWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIFR1 ZSwgTm92IDE0LCAyMDE3IGF0IDE6MDYgUE0sICZsdDs8YSBocmVmPSJtYWlsdG86ZW1pbGUuc3Rl cGhhbkBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20g MGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+SGkgSWFuLDwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOmJsYWNrIj5JdCB3YXMgc3VnZ2VzdGVkIGluIHRoZSBsYXRlc3QgZGlzY3Vz c2lvbiBvbiB0aGUgUlRUIGRlc2lnbiB0ZWFtIG1haWxpbmcgbGlzdCB0byBoYXZlIG9uZQ0KIGJp dCBmb3IgcGFja2V0IGxvc3QsIG9uZSBmb3IgbGF0ZW5jeSAoc3BpbiBiaXQgb3IgZXEuKSBhbmQg b25lIGZvciBjb25nZXN0aW9uLiA8L3NwYW4+DQo8c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjpibGFjayI+SXQgc2VlbXMgYSBzaW1wbGlzdGljIGFwcHJvYWNoIG9uIG9uZSBo YW5kIGJ1dCBhbiBpbnZhcmlhbnQgb24gdGhlIGxvbmcgdGVybS48L3NwYW4+PHNwYW4gbGFuZz0i RlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5n PSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+UmVnYXJkczwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+RW1pbGU8L3NwYW4+PHNwYW4g bGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3Bh biBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBJYW4gU3dldHQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86 aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208 L2E+XQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1hcmRpIDE0IG5vdmVtYnJlIDIwMTcg MjI6NTE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IFNURVBIQU4gRW1pbGUgSU1UL09MTjxicj4NCjxi PkNjJm5ic3A7OjwvYj4gUVVJQyBXRzxicj4NCjxiPk9iamV0Jm5ic3A7OjwvYj4gUmU6IHNwaW4g Yml0IGluIFFVSUM6IHRyb3VibGVzaG9vdGluZzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+V2hhdCB3b3VsZCB0aGUgb3RoZXIgYml0 IG9yIHR3byBiZSB1c2VkIGZvcj8mbmJzcDsgSWYgdGhlcmUgaXMgbm8gc3RhbmRhcmRpemVkIHVz ZSBvZiB0aG9zZSBiaXRzIGluIHYxLCB0aGVuIEkgYmVsaWV2ZSB3ZSBzaG91bGQgd2FpdCB0byBy ZXNlcnZlIHRoZW0gd2hlbiB0aGVpciB1c2FnZQ0KIGlzIGRlZmluZWQsIGdpdmVuIHdlJ2QgbmVl ZCBhIHZlcnNpb24gYnVtcCB0byBzcGVjaWZ5IGhvdyB0aGV5IHdlcmUgYmVpbmcgdXNlZC4mbmJz cDsgQXQgdGhlIG1vbWVudCwgdGhlIG1hbmFnZW1lbnQgdXNlIGNhc2UgaXMgbm90IGNvbXBldGlu ZyB3aXRoIGFueW9uZSBlbHNlIGZvciBiaXRzIGluIHRoZSBzaG9ydCBoZWFkZXIuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPk9uIFR1ZSwgTm92IDE0LCAyMDE3IGF0IDU6 MTQgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tIiB0YXJn ZXQ9Il9ibGFuayI+ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5IaTwvc3Bhbj48c3BhbiBsYW5nPSJG UiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZS Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj5MYXN0IHdlZWsgT3JhbmdlIGV4cGVyaWVu Y2VkIGEgZmFsbGJhY2sgb2YgUVVJQyB0byBUQ1Agb24gb25lIG9mIGl0cyBuZXR3b3Jrcy4gVGhl IGlzc3Vlcw0KIHdlcmUgbm90IHZpc2libGUgaW4gUVVJQyB0cmFmZmljLiBUaGUgdHJvdWJsZXNo b290aW5nIHdhcyBtYWRlIHVzaW5nIFRDUCBwYWNrZXRzIGluZm9ybWF0aW9uLiBUaGlzIGlzIG5v dCBzdXN0YWluYWJsZSBvbiB0aGUgbG9uZyB0ZXJtIHdoZW4gbnVtZXJvdXMgYXBwbGljYXRpb25z IHVzaW5nIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdpbGwgc3RvcCB0byBmYWxsYmFjayB0 byBUQ1AuPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNr Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6Ymxh Y2siPkJhc2VkIG9uIHRoZSBleGNoYW5nZSB3ZSBoYWQgaW4gdGhlIFJUVCBkZXNpZ24gdGVhbSBh bmQgaW4gdG9kYXkgbWVldGluZyAsIGl0IHNvdW5kcyByZWFzb25hYmxlDQogdG8gcmVzZXJ2ZSBh dCBsZWFzdCAyIGJpdHMgKGlkZWFsbHkgMyBiaXRzIGFzIGRpc2N1c3NlZCBpbiB0aGUgZGVzaWdu IHRlYW0pIGZvciBtYW5hZ2VhYmlsaXR5IGluIHRoZSBRVUlDIGludmFyaWFudHMgYW5kIHRvIHN0 YXJ0IGV4cGVyaW1lbnRpbmcgdGhlIHNwaW4gYml0IGluIFFVSUMgVjEuPC9zcGFuPjxzcGFuIGxh bmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4g bGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPlJlZ2FyZHM8L3NwYW4+PHNw YW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkVtaWxlPC9zcGFuPjxz cGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5DZSBtZXNzYWdlIGV0IHNl cyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBs b2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBt ZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWly ZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVl cyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+T3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5UaGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdl ZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+dGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0K PHByZT48c3BhbiBsYW5nPSJGUiI+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIj5DZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBl dCBuZSBkb2l2ZW50IGRvbmM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFu Zz0iRlIiPnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jp c2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS Ij5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+T3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRl cmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wcmU+DQo8cHJl PjxzcGFuIGxhbmc9IkZSIj5UaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29u dGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBw cm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJGUiI+dGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRo b3V0IGF1dGhvcmlzYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj5JZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoYW5rIHlvdS48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1nkgeml513mbschi_-- From nobody Tue Nov 14 17:46: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 83D03129418 for ; Tue, 14 Nov 2017 17:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Aaz8mhDXS7I for ; Tue, 14 Nov 2017 17:46:31 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50128.outbound.protection.outlook.com [40.107.5.128]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61E21129464 for ; Tue, 14 Nov 2017 17:46:29 -0800 (PST) Received: from AM5PR0602MB3251.eurprd06.prod.outlook.com (10.167.170.156) by AM5PR0602MB3250.eurprd06.prod.outlook.com (10.167.170.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Wed, 15 Nov 2017 01:46:26 +0000 Received: from AM5PR0602MB3251.eurprd06.prod.outlook.com ([fe80::a898:7fb6:a67c:be6d]) by AM5PR0602MB3251.eurprd06.prod.outlook.com ([fe80::a898:7fb6:a67c:be6d%13]) with mapi id 15.20.0218.015; Wed, 15 Nov 2017 01:46:26 +0000 From: "Diego R. Lopez" To: "Huangyihong (Rachel)" , "DRUTA, DAN" , Ian Swett CC: QUIC WG , "emile.stephan@orange.com" Subject: Re: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdsWjQiXFl+idYSdWDiJw89tZdFwAAiTIA Date: Wed, 15 Nov 2017 01:46:26 +0000 Message-ID: <9CF29477-00B0-4E70-9E9F-07F628AFFBBF@telefonica.com> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1@nkgeml513-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1@nkgeml513-mbs.china.huawei.com> Accept-Language: en-US Content-Language: es-ES X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 authentication-results: spf=none (sender IP is ) smtp.mailfrom=diego.r.lopez@telefonica.com; x-originating-ip: [2001:67c:370:128:242f:9116:c7b3:74b7] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM5PR0602MB3250; 6:x3g59gQij3kbBmCyN/Wc4sf7JBhBDUihqg0y6KIW/JG9yDLOqXkPnokVqujOyIKMvcrI99YXCQZvWG4KYQaOp5pp4RDsdFLLHrUoNBG9jlyFVZn18dqHMGbjmPI9oW4j57tmDKozuz6jPaeNgLD9UVptiIa15236m4YNdl/slIc8I3wQ1rpKzVLI8KWTjaZlm2nUyZPxTIr5YwodH0BWJzhmLEqnCOiq7Wcx8S2N5sU0vVhzDJU8rLFe/DsqmfT/m6/5CmBfbZkJt4hkGAVcQ1qgtzL/lqIUvwywxwpYdtRNuqiVpigiEx30Cd2iwx3FuQYj7GOJJyVxEmUO24KWk9Td3oyf5uL1JMwpljCriiY=; 5:p6pdanTWpQtX6mSOxnahlsnp+7sTbYh/kVs8YQcVESO4NSqrcJw9trLvsMpSfayHpy8mmPCAU/0btnAmQ8BwLMe7uXfgyYZn3bXvWfYr8P8P+kBU5rHxPxJSD8AIQjtLczRpQgIWut09v0Fdh5jtTA9T05z2CurTy5s2c1d64Tg=; 24:gFOHrtb4XOWqjfNBwqPFo6wvYRm01MiJYpkxQz0I3FFFQkiPkBljNgYhzTtyYlJFrz8x04YZ0WaoeK+NK/hV2mDdILohXiioPmB+EVPAK+0=; 7:SaUSt9m88rPiT8ruX6DpCuIuPljLUdE9z0W9HdODuEk0n+w7THDPUreBouV3wsrFry4iSpKtHY9UCw+UwJFqYy0DuaBsu22SlF+m3AbctTAIUskj/uRHfxo4c3n6ddc8s3bckTtG7D0iASgrftehGJVm2HDeFqZWYg5pSjRf7ZhH5QQU4USDadNJqDSIlkrH5QPWB5ySC8v0oU7oQIsZPQDmbYsicp1zK+7KMwAUVfSZU62b6XYHZ425P/+1gpzp x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 7bef9eef-0d3b-41f6-b98b-08d52bcaaf60 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:AM5PR0602MB3250; x-ms-traffictypediagnostic: AM5PR0602MB3250: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(40392960112811)(278428928389397)(50582790962513)(211936372134217)(227612066756510)(153496737603132)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3231022)(920507027)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(3002001)(6055026)(6041248)(201703131423075)(201702281529075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123564025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM5PR0602MB3250; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM5PR0602MB3250; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(189002)(199003)(25724002)(40134004)(24454002)(252514010)(101416001)(8936002)(102836003)(53936002)(83506002)(14454004)(6436002)(2906002)(4326008)(6506006)(5250100002)(81166006)(54896002)(6306002)(34040400001)(58126008)(81156014)(86362001)(33656002)(2900100001)(6512007)(54906003)(68736007)(3660700001)(3280700002)(6486002)(6116002)(6246003)(229853002)(8676002)(25786009)(236005)(99286004)(110136005)(53546010)(966005)(5660300001)(7736002)(50986999)(478600001)(606006)(2950100002)(786003)(76176999)(54356999)(5890100001)(36756003)(82746002)(106356001)(97736004)(83716003)(189998001)(105586002)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM5PR0602MB3250; H:AM5PR0602MB3251.eurprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: telefonica.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_9CF2947700B04E709E9F07F628AFFBBFtelefonicacom_" MIME-Version: 1.0 X-OriginatorOrg: telefonica.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7bef9eef-0d3b-41f6-b98b-08d52bcaaf60 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 01:46:26.7751 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 9744600e-3e04-492e-baa1-25ec245c6f10 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0602MB3250 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 01:46:35 -0000 --_000_9CF2947700B04E709E9F07F628AFFBBFtelefonicacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm90IHRvIGZvcmdldCB0aGUgcG9zc2liaWxpdHkgb2Ygb3BlbiwgaW5kZXBlbmRlbnQgbWVhc3Vy ZW1lbnRzLCBzdXBwb3J0aW5nIHJlc2VhcmNoIGRhdGEgY29sbGVjdGlvbuKApg0KDQpTbyB5ZXMs IHN1cHBvcnQuDQoNCi0tDQoiRXN0YSB2ZXogbm8gZmFsbGFyZW1vcywgRG9jdG9yIEluZmllcm5v Ig0KDQpEciBEaWVnbyBSLiBMb3Bleg0KVGVsZWZvbmljYSBJK0QNCmh0dHA6Ly9wZW9wbGUudGlk LmVzL2RpZWdvLmxvcGV6Lw0KDQplLW1haWw6IGRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb208 bWFpbHRvOmRpZWdvLnIubG9wZXpAdGVsZWZvbmljYS5jb20+DQpUZWw6ICAgICAgICArMzQgOTEz IDEyOSAwNDENCk1vYmlsZTogKzM0IDY4MiAwNTEgMDkxDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KDQoNCg0KT24gMTUvMTEvMTcgOTozNiwgIlFVSUMgZW4gbm9tYnJlIGRl IEh1YW5neWlob25nIChSYWNoZWwpIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmc+IGVuIG5vbWJyZSBkZSByYWNoZWwuaHVhbmdAaHVhd2VpLmNvbTxt YWlsdG86cmFjaGVsLmh1YW5nQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KVGhhdOKAmXMgYSBnb29k IHBvaW50LiBJIHJlYWxseSB0aGluayB0aGUgYmFsYW5jZSBzaG91bGQgYmUgYWNoaWV2ZWQgYmV0 d2VlbiBwcml2YWN5IGFuZCBvcGVyYXRpb24uIFNwaW4gYml0IGlzIGEgZ29vZCBleGFtcGxlLiBJ IHN1cHBvcnQgaXQuDQoNCkJSLA0KUmFjaGVsDQoNCuWPkeS7tuS6ujogUVVJQyBbbWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIERSVVRBLCBEQU4NCuWPkemAgeaXtumXtDogMjAx N+W5tDEx5pyIMTXml6UgOToxMQ0K5pS25Lu25Lq6OiBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2ds ZS5jb20+DQrmioTpgIE6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBlbWlsZS5zdGVwaGFuQG9y YW5nZS5jb20NCuS4u+mimDogUmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVzaG9vdGluZw0K DQpJIHdpbGwgYWRkIG15IHN1cHBvcnQgZm9yIHRoZSBpbmNsdXNpb24gb2YgdGhlIHNwaW4gYml0 IGludG8gVjEgYW5kIG1ha2UgYSBmZXcgbW9yZSBwb2ludHMuDQpDb25zaWRlcmluZyB0aGF0IHRo ZSBkZXNpZ24gdGVhbSBhbmFseXNpcyBjb25jbHVkZWQgdGhhdCB0aGUgc3BpbiBiaXQgZG9lcyBu b3QgYWRkIGFueSBhZGRpdGlvbmFsIHByaXZhY3kgcmlzayBhbmQgdGhlIHZlcnkgc3BlY2lmaWMg bmVlZCBhZGRyZXNzaW5nIGxhdGVuY3kgaGFzIGJlZW4gZG9jdW1lbnRlZCBhbmQgdmFsaWRhdGVk IGJ5IGEgbGFyZ2UgbnVtYmVyIG9mIFdHIG1lbWJlcnMsIEkgYmVsaWV2ZSB0aGUgUVVJQyB3b3Jr aW5nIGdyb3VwIGhhcyBhIHVuaXF1ZSBvcHBvcnR1bml0eSB0byBzaG93IHRoYXQgd2UgY2FuIGRl c2lnbiBwcm90b2NvbHMgdGhhdCBhcmUgZWZmaWNpZW50LCBwcml2YWN5IHNlbnNpdGl2ZSBhbmQg bmV0d29yayBtYW5hZ2VtZW50IGZyaWVuZGx5Lg0KVGhpcyBwYXJ0aWN1bGFyIGRlc2lnbiwgd2hp bGUgbm90IHBlcmZlY3QgZG9lcyBoYXZlIHRoZSBiaWdnZXN0IGJlbmVmaXQgcmVsYXRpdmUgdG8g dGhlIHJpc2tzIGFuZCBpdCBzaG91bGQgYmUgYWRvcHRlZCBmcm9tIHRoZSBiZWdpbm5pbmcuDQpC ZXN0IFJlZ2FyZHMsDQpEYW4NCg0KDQpPbiBOb3YgMTUsIDIwMTcsIGF0IDU6MjEgQU0sIElhbiBT d2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+IHdy b3RlOg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5nIEVtaWxlLg0KDQpPbiBUdWUsIE5vdiAxNCwgMjAx NyBhdCAxOjA2IFBNLCA8ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPG1haWx0bzplbWlsZS5zdGVw aGFuQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIElhbiwNCg0KSXQgd2FzIHN1Z2dlc3RlZCBpbiB0 aGUgbGF0ZXN0IGRpc2N1c3Npb24gb24gdGhlIFJUVCBkZXNpZ24gdGVhbSBtYWlsaW5nIGxpc3Qg dG8gaGF2ZSBvbmUgYml0IGZvciBwYWNrZXQgbG9zdCwgb25lIGZvciBsYXRlbmN5IChzcGluIGJp dCBvciBlcS4pIGFuZCBvbmUgZm9yIGNvbmdlc3Rpb24uDQpJdCBzZWVtcyBhIHNpbXBsaXN0aWMg YXBwcm9hY2ggb24gb25lIGhhbmQgYnV0IGFuIGludmFyaWFudCBvbiB0aGUgbG9uZyB0ZXJtLg0K DQpSZWdhcmRzDQpFbWlsZQ0KDQoNCkRlIDogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29v Z2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT5dDQpFbnZvecOpIDogbWFyZGkgMTQg bm92ZW1icmUgMjAxNyAyMjo1MQ0Kw4AgOiBTVEVQSEFOIEVtaWxlIElNVC9PTE4NCkNjIDogUVVJ QyBXRw0KT2JqZXQgOiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJsZXNob290aW5nDQoNCldo YXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBmb3I/ICBJZiB0aGVyZSBpcyBu byBzdGFuZGFyZGl6ZWQgdXNlIG9mIHRob3NlIGJpdHMgaW4gdjEsIHRoZW4gSSBiZWxpZXZlIHdl IHNob3VsZCB3YWl0IHRvIHJlc2VydmUgdGhlbSB3aGVuIHRoZWlyIHVzYWdlIGlzIGRlZmluZWQs IGdpdmVuIHdlJ2QgbmVlZCBhIHZlcnNpb24gYnVtcCB0byBzcGVjaWZ5IGhvdyB0aGV5IHdlcmUg YmVpbmcgdXNlZC4gIEF0IHRoZSBtb21lbnQsIHRoZSBtYW5hZ2VtZW50IHVzZSBjYXNlIGlzIG5v dCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBmb3IgYml0cyBpbiB0aGUgc2hvcnQgaGVhZGVy Lg0KDQpPbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCA1OjE0IEFNLCA8ZW1pbGUuc3RlcGhhbkBvcmFu Z2UuY29tPG1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpDQoNCkxh c3Qgd2VlayBPcmFuZ2UgZXhwZXJpZW5jZWQgYSBmYWxsYmFjayBvZiBRVUlDIHRvIFRDUCBvbiBv bmUgb2YgaXRzIG5ldHdvcmtzLiBUaGUgaXNzdWVzIHdlcmUgbm90IHZpc2libGUgaW4gUVVJQyB0 cmFmZmljLiBUaGUgdHJvdWJsZXNob290aW5nIHdhcyBtYWRlIHVzaW5nIFRDUCBwYWNrZXRzIGlu Zm9ybWF0aW9uLiBUaGlzIGlzIG5vdCBzdXN0YWluYWJsZSBvbiB0aGUgbG9uZyB0ZXJtIHdoZW4g bnVtZXJvdXMgYXBwbGljYXRpb25zIHVzaW5nIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdp bGwgc3RvcCB0byBmYWxsYmFjayB0byBUQ1AuDQoNCkJhc2VkIG9uIHRoZSBleGNoYW5nZSB3ZSBo YWQgaW4gdGhlIFJUVCBkZXNpZ24gdGVhbSBhbmQgaW4gdG9kYXkgbWVldGluZyAsIGl0IHNvdW5k cyByZWFzb25hYmxlIHRvIHJlc2VydmUgYXQgbGVhc3QgMiBiaXRzIChpZGVhbGx5IDMgYml0cyBh cyBkaXNjdXNzZWQgaW4gdGhlIGRlc2lnbiB0ZWFtKSBmb3IgbWFuYWdlYWJpbGl0eSBpbiB0aGUg UVVJQyBpbnZhcmlhbnRzIGFuZCB0byBzdGFydCBleHBlcmltZW50aW5nIHRoZSBzcGluIGJpdCBp biBRVUlDIFYxLg0KDQpSZWdhcmRzDQpFbWlsZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0K DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3Nh Z2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9u cyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpw YXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0K DQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3 Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhv dXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlz IG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2Vk IG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCkVzdGUgbWVuc2FqZSB5IHN1cyBhZGp1bnRvcyBzZSBkaXJpZ2VuIGV4Y2x1 c2l2YW1lbnRlIGEgc3UgZGVzdGluYXRhcmlvLCBwdWVkZSBjb250ZW5lciBpbmZvcm1hY2nDs24g cHJpdmlsZWdpYWRhIG8gY29uZmlkZW5jaWFsIHkgZXMgcGFyYSB1c28gZXhjbHVzaXZvIGRlIGxh IHBlcnNvbmEgbyBlbnRpZGFkIGRlIGRlc3Rpbm8uIFNpIG5vIGVzIHVzdGVkLiBlbCBkZXN0aW5h dGFyaW8gaW5kaWNhZG8sIHF1ZWRhIG5vdGlmaWNhZG8gZGUgcXVlIGxhIGxlY3R1cmEsIHV0aWxp emFjacOzbiwgZGl2dWxnYWNpw7NuIHkvbyBjb3BpYSBzaW4gYXV0b3JpemFjacOzbiBwdWVkZSBl c3RhciBwcm9oaWJpZGEgZW4gdmlydHVkIGRlIGxhIGxlZ2lzbGFjacOzbiB2aWdlbnRlLiBTaSBo YSByZWNpYmlkbyBlc3RlIG1lbnNhamUgcG9yIGVycm9yLCBsZSByb2dhbW9zIHF1ZSBub3MgbG8g Y29tdW5pcXVlIGlubWVkaWF0YW1lbnRlIHBvciBlc3RhIG1pc21hIHbDrWEgeSBwcm9jZWRhIGEg c3UgZGVzdHJ1Y2Npw7NuLg0KDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgdHJh bnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBpbnRl bmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSBuYW1lZCBh Ym92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2UgaXMgbm90IHRoZSBpbnRlbmRlZCBy ZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRoYXQgYW55IGRpc3NlbWluYXRpb24s IGRpc3RyaWJ1dGlvbiBvciBjb3B5aW5nIG9mIHRoaXMgY29tbXVuaWNhdGlvbiBpcyBzdHJpY3Rs eSBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBl cnJvciwgZG8gbm90IHJlYWQgaXQuIFBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2Vu ZGVyIHRoYXQgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBjb21tdW5pY2F0aW9uIGluIGVycm9yIGFu ZCB0aGVuIGRlbGV0ZSBpdC4NCg0KRXN0YSBtZW5zYWdlbSBlIHNldXMgYW5leG9zIHNlIGRpcmln ZW0gZXhjbHVzaXZhbWVudGUgYW8gc2V1IGRlc3RpbmF0w6FyaW8sIHBvZGUgY29udGVyIGluZm9y bWHDp8OjbyBwcml2aWxlZ2lhZGEgb3UgY29uZmlkZW5jaWFsIGUgw6kgcGFyYSB1c28gZXhjbHVz aXZvIGRhIHBlc3NvYSBvdSBlbnRpZGFkZSBkZSBkZXN0aW5vLiBTZSBuw6NvIMOpIHZvc3NhIHNl bmhvcmlhIG8gZGVzdGluYXTDoXJpbyBpbmRpY2FkbywgZmljYSBub3RpZmljYWRvIGRlIHF1ZSBh IGxlaXR1cmEsIHV0aWxpemHDp8OjbywgZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRv cml6YcOnw6NvIHBvZGUgZXN0YXIgcHJvaWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28g dmlnZW50ZS4gU2UgcmVjZWJldSBlc3RhIG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBx dWUgbm9zIG8gY29tdW5pcXVlIGltZWRpYXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJv Y2VkYSBhIHN1YSBkZXN0cnVpw6fDo28NCg== --_000_9CF2947700B04E709E9F07F628AFFBBFtelefonicacom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVMOtdHVsbyIgY29udGVudD0iIj4NCjxtZXRhIG5hbWU9IktleXdvcmRzIiBjb250 ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAx NSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAq Lw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpBcmlhbDsNCglwYW5vc2UtMToyIDExIDYgNCAy IDIgMiAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ cGFub3NlLTE6MiA3IDMgOSAyIDIgNSAyIDQgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2 IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTrl vq7ova/pm4Xpu5E7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu IixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIGNvbiBmb3JtYXRvIHBy ZXZpbyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpzcGFuLkhU TUxjb25mb3JtYXRvcHJldmlvQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIGNvbiBmb3JtYXRv IHByZXZpbyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBjb24gZm9ybWF0byBwcmV2aW8iOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIixzZXJpZjt9 DQpwLkhUTUwsIGxpLkhUTUwsIGRpdi5IVE1MDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIOmihOiu vuagvOW8jyI7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJ Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MQ2hhcg0KCXtt c28tc3R5bGUtbmFtZToiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIOmihOiuvuagvOW8jyI7DQoJZm9udC1mYW1p bHk6IkNvdXJpZXIgTmV3IixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWZvbnQtdmFyaWFu dDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3Jt Om5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNl bGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28t c3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7 fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1z aXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7 DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQgNzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24x DQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2Nv bG9yPSJ3aGl0ZSIgbGFuZz0iRVMtVFJBRCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8 ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Tm90IHRvIGZv cmdldCB0aGUgcG9zc2liaWxpdHkgb2Ygb3BlbiwgaW5kZXBlbmRlbnQgbWVhc3VyZW1lbnRzLCBz dXBwb3J0aW5nIHJlc2VhcmNoIGRhdGEgY29sbGVjdGlvbuKApjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPlNvIHllcywgc3VwcG9ydC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+LS08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij4mcXVvdDtFc3RhIHZleiBubyBmYWxsYXJlbW9zLCBEb2N0b3IgSW5maWVybm8mcXVvdDs8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDs8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj5EciBEaWVnbyBSLiBMb3Blejwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPlRlbGVmb25pY2EgSSYjNDM7RDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxhIGhyZWY9Imh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxvcGV6LyI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQiPmh0dHA6Ly9wZW9wbGUudGlkLmVzL2RpZWdvLmxv cGV6Lzwvc3Bhbj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFn ZTpFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7 PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO21z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5lLW1haWw6Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLUdCIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxhIGhyZWY9Im1h aWx0bzpkaWVnby5yLmxvcGV6QHRlbGVmb25pY2EuY29tIj48c3BhbiBsYW5nPSJFUy1UUkFEIiBz dHlsZT0iY29sb3I6d2luZG93dGV4dCI+ZGllZ28uci5sb3BlekB0ZWxlZm9uaWNhLmNvbTwvc3Bh bj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tR0IiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+VGVsOiZuYnNwOyZu YnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmIzQzOzM0IDkxMyAxMjkgMDQxPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+TW9iaWxlOiAmIzQzOzM0IDY4MiAw NTEgMDkxPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjttc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij5PbiAxNS8xMS8x NyA5OjM2LCAmcXVvdDtRVUlDIGVuIG5vbWJyZSBkZSBIdWFuZ3lpaG9uZyAoUmFjaGVsKSZxdW90 OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3VuY2Vz QGlldGYub3JnPC9hPiBlbiBub21icmUgZGUNCjxhIGhyZWY9Im1haWx0bzpyYWNoZWwuaHVhbmdA aHVhd2VpLmNvbSI+cmFjaGVsLmh1YW5nQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUu NHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj5UaGF04oCZcyBhIGdvb2QgcG9pbnQuIEkgcmVhbGx5IHRoaW5rIHRoZSBi YWxhbmNlIHNob3VsZCBiZSBhY2hpZXZlZCBiZXR3ZWVuIHByaXZhY3kgYW5kIG9wZXJhdGlvbi4g U3BpbiBiaXQgaXMgYSBnb29kIGV4YW1wbGUuDQogSSBzdXBwb3J0IGl0LiA8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm dDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QlIs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5SYWNoZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzUuNHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTaW1T dW4iPuWPkTwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7ku7bkuro8L3NwYW4+PC9iPjxi PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrl vq7ova/pm4Xpu5EiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5EiPg0KIFFVSUMgW21haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmddIDwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuS7o+ihqDwvc3Bh bj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65b6u6L2v 6ZuF6buRIj4NCjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kSI+RFJVVEEsIERBTjxicj4NCjwvc3Bhbj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTaW1TdW4iPuWPkTwv c3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7pgIE8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1biI+5pe26Ze0PC9zcGFuPjwvYj48 Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 5b6u6L2v6ZuF6buRIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRIj4NCiAyMDE3PC9zcGFuPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+5bm0PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5EiPjExPC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTrlvq7ova/pm4Xpu5EiPjE1PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+5pelPC9z cGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTrlvq7ova/pm4Xpu5EiPg0KIDk6MTE8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj7m lLbku7bkuro8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5EiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5Ei PiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+5oqE6YCBPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRIj46PC9zcGFuPjwv Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 5b6u6L2v6ZuF6buRIj4gUVVJQyBXRyAmbHQ7cXVpY0BpZXRmLm9yZyZndDs7IGVtaWxlLnN0ZXBo YW5Ab3JhbmdlLmNvbTxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPuS4uzwvc3Bhbj48 L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6U2ltU3VuIj7p opg8L3NwYW4+PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5EiPjo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5EiPg0KIFJl OiBzcGluIGJpdCBpbiBRVUlDOiB0cm91Ymxlc2hvb3Rpbmc8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0 OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxh bmc9IkVOLVVTIj5JIHdpbGwgYWRkIG15IHN1cHBvcnQgZm9yIHRoZSBpbmNsdXNpb24gb2YgdGhl IHNwaW4gYml0IGludG8gVjEgYW5kIG1ha2UgYSBmZXcgbW9yZSBwb2ludHMuDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNvbnNpZGVyaW5nIHRoYXQgdGhlIGRlc2ln biB0ZWFtIGFuYWx5c2lzIGNvbmNsdWRlZCB0aGF0IHRoZSBzcGluIGJpdCBkb2VzIG5vdCBhZGQg YW55IGFkZGl0aW9uYWwgcHJpdmFjeSByaXNrIGFuZCB0aGUgdmVyeSBzcGVjaWZpYyBuZWVkIGFk ZHJlc3NpbmcgbGF0ZW5jeSBoYXMgYmVlbiBkb2N1bWVudGVkIGFuZCB2YWxpZGF0ZWQNCiBieSBh IGxhcmdlIG51bWJlciBvZiBXRyBtZW1iZXJzLCBJIGJlbGlldmUgdGhlIFFVSUMgd29ya2luZyBn cm91cCBoYXMgYSB1bmlxdWUgb3Bwb3J0dW5pdHkgdG8gc2hvdyB0aGF0IHdlIGNhbiBkZXNpZ24g cHJvdG9jb2xzIHRoYXQgYXJlIGVmZmljaWVudCwgcHJpdmFjeSBzZW5zaXRpdmUgYW5kIG5ldHdv cmsgbWFuYWdlbWVudCBmcmllbmRseS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBjbTtt YXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjM1LjRwdCI+ DQo8c3BhbiBsYW5nPSJFTi1VUyI+VGhpcyBwYXJ0aWN1bGFyIGRlc2lnbiwgd2hpbGUgbm90IHBl cmZlY3QgZG9lcyBoYXZlIHRoZSBiaWdnZXN0IGJlbmVmaXQgcmVsYXRpdmUgdG8gdGhlIHJpc2tz IGFuZCBpdCBzaG91bGQgYmUgYWRvcHRlZCBmcm9tIHRoZSBiZWdpbm5pbmcuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMy4w cHQiPkJlc3QgUmVnYXJkcyw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5n PSJFTi1VUyI+RGFuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4t VVMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2lu LXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNw YW4gbGFuZz0iRU4tVVMiPjxicj4NCk9uIE5vdiAxNSwgMjAxNywgYXQgNToyMSBBTSwgSWFuIFN3 ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSI+aWFuc3dldHRAZ29v Z2xlLmNvbTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJs b2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40 cHQiPjxzcGFuIGxhbmc9IkVOLVVTIj5UaGFua3MgZm9yIGNsYXJpZnlpbmcgRW1pbGUuPC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPiZuYnNwOzwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gVHVlLCBOb3YgMTQsIDIwMTcgYXQg MTowNiBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20iIHRh cmdldD0iX2JsYW5rIj5lbWlsZS5zdGVwaGFuQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8L3Nw YW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM1LjRwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGkg SWFuLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDozNS40cHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4t bGVmdDozNS40cHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2siPkl0 IHdhcyBzdWdnZXN0ZWQgaW4gdGhlIGxhdGVzdCBkaXNjdXNzaW9uIG9uIHRoZSBSVFQgZGVzaWdu IHRlYW0gbWFpbGluZyBsaXN0IHRvIGhhdmUgb25lIGJpdCBmb3IgcGFja2V0IGxvc3QsIG9uZSBm b3IgbGF0ZW5jeSAoc3BpbiBiaXQgb3IgZXEuKSBhbmQgb25lIGZvciBjb25nZXN0aW9uLg0KPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1 LjRwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SXQgc2VlbXMg YSBzaW1wbGlzdGljIGFwcHJvYWNoIG9uIG9uZSBoYW5kIGJ1dCBhbiBpbnZhcmlhbnQgb24gdGhl IGxvbmcgdGVybS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj5SZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpi bGFjayI+RW1pbGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJs YWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RGUmbmJz cDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBJYW4gU3dldHQgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmlh bnN3ZXR0QGdvb2dsZS5jb208L2E+XQ0KPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IG1hcmRp IDE0IG5vdmVtYnJlIDIwMTcgMjI6NTE8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IFNURVBIQU4gRW1p bGUgSU1UL09MTjxicj4NCjxiPkNjJm5ic3A7OjwvYj4gUVVJQyBXRzxicj4NCjxiPk9iamV0Jm5i c3A7OjwvYj4gUmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVzaG9vdGluZzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1s ZWZ0OjM1LjRwdCI+DQo8c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNw YW4gbGFuZz0iRlIiPldoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBmb3I/ Jm5ic3A7IElmIHRoZXJlIGlzIG5vIHN0YW5kYXJkaXplZCB1c2Ugb2YgdGhvc2UgYml0cyBpbiB2 MSwgdGhlbiBJIGJlbGlldmUgd2Ugc2hvdWxkIHdhaXQgdG8gcmVzZXJ2ZSB0aGVtIHdoZW4gdGhl aXIgdXNhZ2UgaXMgZGVmaW5lZCwgZ2l2ZW4gd2UnZCBuZWVkIGEgdmVyc2lvbiBidW1wIHRvIHNw ZWNpZnkgaG93IHRoZXkgd2VyZSBiZWluZyB1c2VkLiZuYnNwOw0KIEF0IHRoZSBtb21lbnQsIHRo ZSBtYW5hZ2VtZW50IHVzZSBjYXNlIGlzIG5vdCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBm b3IgYml0cyBpbiB0aGUgc2hvcnQgaGVhZGVyLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNS40cHQiPg0KPHNw YW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkZSIj5PbiBU dWUsIE5vdiAxNCwgMjAxNyBhdCA1OjE0IEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVtaWxlLnN0 ZXBoYW5Ab3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNv bTwvYT4mZ3Q7IHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBsYW5nPSJGUiIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjpibGFjayI+SGk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5MYXN0IHdlZWsgT3JhbmdlIGV4cGVyaWVuY2VkIGEgZmFsbGJhY2sgb2Yg UVVJQyB0byBUQ1Agb24gb25lIG9mIGl0cyBuZXR3b3Jrcy4gVGhlIGlzc3VlcyB3ZXJlIG5vdCB2 aXNpYmxlIGluIFFVSUMgdHJhZmZpYy4gVGhlIHRyb3VibGVzaG9vdGluZyB3YXMgbWFkZSB1c2lu ZyBUQ1AgcGFja2V0cw0KIGluZm9ybWF0aW9uLiBUaGlzIGlzIG5vdCBzdXN0YWluYWJsZSBvbiB0 aGUgbG9uZyB0ZXJtIHdoZW4gbnVtZXJvdXMgYXBwbGljYXRpb25zIHVzaW5nIGRpZmZlcmVudCB2 ZXJzaW9ucyBvZiBRVUlDIHdpbGwgc3RvcCB0byBmYWxsYmFjayB0byBUQ1AuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QmFzZWQgb24gdGhlIGV4Y2hh bmdlIHdlIGhhZCBpbiB0aGUgUlRUIGRlc2lnbiB0ZWFtIGFuZCBpbiB0b2RheSBtZWV0aW5nICwg aXQgc291bmRzIHJlYXNvbmFibGUgdG8gcmVzZXJ2ZSBhdCBsZWFzdCAyIGJpdHMgKGlkZWFsbHkg MyBiaXRzIGFzIGRpc2N1c3NlZCBpbiB0aGUgZGVzaWduIHRlYW0pDQogZm9yIG1hbmFnZWFiaWxp dHkgaW4gdGhlIFFVSUMgaW52YXJpYW50cyBhbmQgdG8gc3RhcnQgZXhwZXJpbWVudGluZyB0aGUg c3BpbiBiaXQgaW4gUVVJQyBWMS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrIj5SZWdhcmRzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjpibGFjayI+RW1pbGU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87bWFyZ2luLWxlZnQ6MzUuNHB0Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1 LjRwdCI+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3Bh biBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjwvc3Bhbj48bzpwPjwvbzpwPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiI+YSBs J2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4g TGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlv biw8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRw dCI+PHNwYW4gbGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNp IGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3Nw YW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNw YW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0i bWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMg YXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiPnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBp biBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl PSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFs dGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBt b2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3Uu PC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM1LjRwdCI+DQo8c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiPl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1 LjRwdCI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNv bmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPC9zcGFuPjxv OnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxh bmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9y aXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxl eiBsZSBzaWduYWxlcjwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2lu LWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8L3NwYW4+PG86cD48L286cD48L3By ZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiPk9yYW5n ZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJl LCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxw cmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3Bh biBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzs8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM1LjRwdCI+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjwvc3Bhbj48bzpwPjwvbzpw PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzUuNHB0Ij48c3BhbiBsYW5nPSJGUiI+ SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0 aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPC9z cGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxz cGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDoz NS40cHQiPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNS40cHQiPjxzcGFuIGxhbmc9IkVOLVVT Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1 b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxicj4NCjxocj4NCjxmb250IGZhY2U9IkFyaWFsIiBjb2xv cj0iR3JheSIgc2l6ZT0iMSI+PGJyPg0KRXN0ZSBtZW5zYWplIHkgc3VzIGFkanVudG9zIHNlIGRp cmlnZW4gZXhjbHVzaXZhbWVudGUgYSBzdSBkZXN0aW5hdGFyaW8sIHB1ZWRlIGNvbnRlbmVyIGlu Zm9ybWFjacOzbiBwcml2aWxlZ2lhZGEgbyBjb25maWRlbmNpYWwgeSBlcyBwYXJhIHVzbyBleGNs dXNpdm8gZGUgbGEgcGVyc29uYSBvIGVudGlkYWQgZGUgZGVzdGluby4gU2kgbm8gZXMgdXN0ZWQu IGVsIGRlc3RpbmF0YXJpbyBpbmRpY2FkbywgcXVlZGEgbm90aWZpY2FkbyBkZSBxdWUgbGENCiBs ZWN0dXJhLCB1dGlsaXphY2nDs24sIGRpdnVsZ2FjacOzbiB5L28gY29waWEgc2luIGF1dG9yaXph Y2nDs24gcHVlZGUgZXN0YXIgcHJvaGliaWRhIGVuIHZpcnR1ZCBkZSBsYSBsZWdpc2xhY2nDs24g dmlnZW50ZS4gU2kgaGEgcmVjaWJpZG8gZXN0ZSBtZW5zYWplIHBvciBlcnJvciwgbGUgcm9nYW1v cyBxdWUgbm9zIGxvIGNvbXVuaXF1ZSBpbm1lZGlhdGFtZW50ZSBwb3IgZXN0YSBtaXNtYSB2w61h IHkgcHJvY2VkYSBhIHN1IGRlc3RydWNjacOzbi48YnI+DQo8YnI+DQpUaGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGluIHRoaXMgdHJhbnNtaXNzaW9uIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBvbmx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSBuYW1lZCBhYm92ZS4gSWYgdGhlIHJlYWRlciBvZiB0aGlzIG1lc3NhZ2Ug aXMgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHlvdSBhcmUgaGVyZWJ5IG5vdGlmaWVkIHRo YXQgYW55IGRpc3NlbWluYXRpb24sDQogZGlzdHJpYnV0aW9uIG9yIGNvcHlpbmcgb2YgdGhpcyBj b21tdW5pY2F0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBkbyBub3QgcmVhZCBpdC4gUGxlYXNlIGltbWVk aWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgdGhhdCB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGNv bW11bmljYXRpb24gaW4gZXJyb3IgYW5kIHRoZW4gZGVsZXRlIGl0Ljxicj4NCjxicj4NCkVzdGEg bWVuc2FnZW0gZSBzZXVzIGFuZXhvcyBzZSBkaXJpZ2VtIGV4Y2x1c2l2YW1lbnRlIGFvIHNldSBk ZXN0aW5hdMOhcmlvLCBwb2RlIGNvbnRlciBpbmZvcm1hw6fDo28gcHJpdmlsZWdpYWRhIG91IGNv bmZpZGVuY2lhbCBlIMOpIHBhcmEgdXNvIGV4Y2x1c2l2byBkYSBwZXNzb2Egb3UgZW50aWRhZGUg ZGUgZGVzdGluby4gU2UgbsOjbyDDqSB2b3NzYSBzZW5ob3JpYSBvIGRlc3RpbmF0w6FyaW8gaW5k aWNhZG8sIGZpY2Egbm90aWZpY2FkbyBkZSBxdWUgYQ0KIGxlaXR1cmEsIHV0aWxpemHDp8Ojbywg ZGl2dWxnYcOnw6NvIGUvb3UgY8OzcGlhIHNlbSBhdXRvcml6YcOnw6NvIHBvZGUgZXN0YXIgcHJv aWJpZGEgZW0gdmlydHVkZSBkYSBsZWdpc2xhw6fDo28gdmlnZW50ZS4gU2UgcmVjZWJldSBlc3Rh IG1lbnNhZ2VtIHBvciBlcnJvLCByb2dhbW9zLWxoZSBxdWUgbm9zIG8gY29tdW5pcXVlIGltZWRp YXRhbWVudGUgcG9yIGVzdGEgbWVzbWEgdmlhIGUgcHJvY2VkYSBhIHN1YSBkZXN0cnVpw6fDo288 YnI+DQo8L2ZvbnQ+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9CF2947700B04E709E9F07F628AFFBBFtelefonicacom_-- From nobody Tue Nov 14 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 F3333129477 for ; Tue, 14 Nov 2017 17:55:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.699 X-Spam-Level: X-Spam-Status: No, score=-4.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBm2_kLBHhEx for ; Tue, 14 Nov 2017 17:55:09 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0139.outbound.protection.outlook.com [104.47.0.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B061F12947B for ; Tue, 14 Nov 2017 17:55:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=uT6tCHAKuCH4ybsYGcrcS1qvD9Q6ubOzybaQqm6LYJ0=; b=SP3CTVbZzXahPxmvee6ouMtJkevQD/YOsdtSpaMQbHpLfywnyVmfkEE5C2kDOQbmINGLfx9Phf0EyQmw0HBI4bf/oYQRsfh4yZyZQbpbQHZnGDJjz5I015JA7wAAh/V4QfMqmgZ9N7P8ogCTyspxG59uNVUZkdxIriDaDUI6IQ0= Received: from HE1PR07MB1100.eurprd07.prod.outlook.com (10.163.177.150) by HE1PR07MB1100.eurprd07.prod.outlook.com (10.163.177.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.239.4; Wed, 15 Nov 2017 01:55:06 +0000 Received: from HE1PR07MB1100.eurprd07.prod.outlook.com ([fe80::9932:facd:c0bc:17cc]) by HE1PR07MB1100.eurprd07.prod.outlook.com ([fe80::9932:facd:c0bc:17cc%13]) with mapi id 15.20.0239.005; Wed, 15 Nov 2017 01:55:05 +0000 From: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" To: "DRUTA, DAN" , Ian Swett CC: QUIC WG , "emile.stephan@orange.com" , "Fossati, Thomas (Nokia - GB/Cambridge, UK)" Subject: Re: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFwAJsv0AAAbTAwAABsr3AAAIB8QAABJPmwA= Date: Wed, 15 Nov 2017 01:55:05 +0000 Message-ID: References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <822FABC6-2BF5-47E1-91D7-AF25F77BC5BE@att.com> In-Reply-To: <822FABC6-2BF5-47E1-91D7-AF25F77BC5BE@att.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 authentication-results: spf=none (sender IP is ) smtp.mailfrom=thomas.fossati@nokia.com; x-originating-ip: [31.133.136.127] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HE1PR07MB1100; 6:StDnArpSL3xYcO1ipxrD4UNQDpRKr0uHbZXxT14bmtDt68V6cYLyRyQo1oxhdGmt0h63WS6Kfn4ZvbUX57he81h0GHL0dYtlrC5OU6c3xywAV4GBWv+IwhPyXnHz5z0GA5g6gHYApGoL7gs7jmsFc43N2oh52F4yCG3xMF+I9jrTpZPnyKde/PmUM9xIT9je4cuwv4JcUvtber4R2YrGP9PctcOzKrbi1MUZ7/N9F4Jd0uN7duoqldoWjv2SthceTVCSI0efxlU14n5uGK1vx1ukYWizar9nrqEyydDjJw4xf/onLpXOwR5byszjOsb71RFoB9j+hEx7AceZ+hK5GN8OzunvlOj/T5A+BON85iI=; 5:kNbhp0/yVYdzH5h2LQXIW65DM5dxnC+RCBdVLVrQ42ILIkeNOeShaenmtv8eHQqeYi+kOowZC07f6VEe96HzjU/kr8gcbjrcNF3oqxT2EGDXcdR/9IXLtqtU3Xymodpbin3LjpJFIukehZW8vIwsoRwaZFXTY/QT0T3qlnkTTRo=; 24:/6FCVhQ7fc8OZkc0vgsCn6FGoDkZzyzDwXq790bkiW67pr8PTdX9OKrPkINkXzej9ZdNl4+zUi5OzFkGEFlJRBeAQKzYOWMTCPqnyZvSDqw=; 7:jhIit4im2olnm2KKJbWQZh+RiG7PsYf+Fxg7x/XfUV878TsDfn4XSvywJb1N/rU4eV5WjMiJDUEtzwSISFIoJRGKmmTph4ESywPwZmlxJsa8JMTwrR17oeJD2qTSkWjjij3Tm0iA4J2wvzIRE0rkpigEZAlHQXTOAcEDjtlina79KBv4tcxkTVFh1cp2qHvJ2dzhRXCpva/YD1shKaMlko3l4LdB9YvazF9qUK3MYitX/PLSQ8kVS+yMiGQQn5xo x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(189002)(199003)(24454002)(8936002)(34040400001)(478600001)(5660300001)(58126008)(93886005)(33656002)(6512007)(54906003)(189998001)(99286004)(83716003)(36756003)(110136005)(97736004)(82746002)(53546010)(5890100001)(7736002)(2950100002)(86362001)(6246003)(6506006)(81156014)(50986999)(81166006)(8676002)(76176999)(4326008)(66066001)(53936002)(102836003)(236005)(83506002)(3846002)(14454004)(3280700002)(25786009)(229853002)(68736007)(106356001)(105586002)(316002)(101416001)(5250100002)(2900100001)(6436002)(6486002)(6116002)(54896002)(3660700001)(107886003)(6306002)(54356999)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR07MB1100; H:HE1PR07MB1100.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; x-ms-office365-filtering-correlation-id: 0c42d120-7982-4795-335c-08d52bcbe478 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:HE1PR07MB1100; x-ms-traffictypediagnostic: HE1PR07MB1100: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(97927398514766)(211936372134217)(227612066756510)(153496737603132)(18271650672692)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(10201501046)(3231022)(920507027)(3002001)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:HE1PR07MB1100; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HE1PR07MB1100; x-forefront-prvs: 0492FD61DD received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_B610969AA9F84DA4AB702C13C6A5FAC9nokiacom_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0c42d120-7982-4795-335c-08d52bcbe478 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 01:55:05.2356 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB1100 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 01:55:28 -0000 --_000_B610969AA9F84DA4AB702C13C6A5FAC9nokiacom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzEgZm9yIHRoZSByZWFzb25zIHN0YXRlZCB1cC10aHJlYWQgYXMgd2VsbCBhcyB5ZXN0ZXJkYXkg YXQgdGhlIG1pYy4NCg0KKEFuZCB0aGFua3MgQnJpYW4gZm9yIHRoZSBncmVhdCBhbmFseXNpcyBv biB0aGUgcHJpdmFjeSBpbXBsaWNhdGlvbnMuKQ0KDQpPbiAxNS8xMS8yMDE3LCAwOToxMCwgIlFV SUMgb24gYmVoYWxmIG9mIERSVVRBLCBEQU4iIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGRkNTgyNkBhdHQuY29tPG1haWx0 bzpkZDU4MjZAYXR0LmNvbT4+IHdyb3RlOg0KDQpJIHdpbGwgYWRkIG15IHN1cHBvcnQgZm9yIHRo ZSBpbmNsdXNpb24gb2YgdGhlIHNwaW4gYml0IGludG8gVjEgYW5kIG1ha2UgYSBmZXcgbW9yZSBw b2ludHMuDQpDb25zaWRlcmluZyB0aGF0IHRoZSBkZXNpZ24gdGVhbSBhbmFseXNpcyBjb25jbHVk ZWQgdGhhdCB0aGUgc3BpbiBiaXQgZG9lcyBub3QgYWRkIGFueSBhZGRpdGlvbmFsIHByaXZhY3kg cmlzayBhbmQgdGhlIHZlcnkgc3BlY2lmaWMgbmVlZCBhZGRyZXNzaW5nIGxhdGVuY3kgaGFzIGJl ZW4gZG9jdW1lbnRlZCBhbmQgdmFsaWRhdGVkIGJ5IGEgbGFyZ2UgbnVtYmVyIG9mIFdHIG1lbWJl cnMsIEkgYmVsaWV2ZSB0aGUgUVVJQyB3b3JraW5nIGdyb3VwIGhhcyBhIHVuaXF1ZSBvcHBvcnR1 bml0eSB0byBzaG93IHRoYXQgd2UgY2FuIGRlc2lnbiBwcm90b2NvbHMgdGhhdCBhcmUgZWZmaWNp ZW50LCBwcml2YWN5IHNlbnNpdGl2ZSBhbmQgbmV0d29yayBtYW5hZ2VtZW50IGZyaWVuZGx5Lg0K VGhpcyBwYXJ0aWN1bGFyIGRlc2lnbiwgd2hpbGUgbm90IHBlcmZlY3QgZG9lcyBoYXZlIHRoZSBi aWdnZXN0IGJlbmVmaXQgcmVsYXRpdmUgdG8gdGhlIHJpc2tzIGFuZCBpdCBzaG91bGQgYmUgYWRv cHRlZCBmcm9tIHRoZSBiZWdpbm5pbmcuDQpCZXN0IFJlZ2FyZHMsDQpEYW4NCg0KDQpPbiBOb3Yg MTUsIDIwMTcsIGF0IDU6MjEgQU0sIElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWls dG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+IHdyb3RlOg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5nIEVt aWxlLg0KDQpPbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCAxOjA2IFBNLCA8ZW1pbGUuc3RlcGhhbkBv cmFuZ2UuY29tPG1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIElh biwNCg0KSXQgd2FzIHN1Z2dlc3RlZCBpbiB0aGUgbGF0ZXN0IGRpc2N1c3Npb24gb24gdGhlIFJU VCBkZXNpZ24gdGVhbSBtYWlsaW5nIGxpc3QgdG8gaGF2ZSBvbmUgYml0IGZvciBwYWNrZXQgbG9z dCwgb25lIGZvciBsYXRlbmN5IChzcGluIGJpdCBvciBlcS4pIGFuZCBvbmUgZm9yIGNvbmdlc3Rp b24uDQpJdCBzZWVtcyBhIHNpbXBsaXN0aWMgYXBwcm9hY2ggb24gb25lIGhhbmQgYnV0IGFuIGlu dmFyaWFudCBvbiB0aGUgbG9uZyB0ZXJtLg0KDQpSZWdhcmRzDQpFbWlsZQ0KDQoNCkRlIDogSWFu IFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xl LmNvbT5dDQpFbnZvecOpIDogbWFyZGkgMTQgbm92ZW1icmUgMjAxNyAyMjo1MQ0Kw4AgOiBTVEVQ SEFOIEVtaWxlIElNVC9PTE4NCkNjIDogUVVJQyBXRw0KT2JqZXQgOiBSZTogc3BpbiBiaXQgaW4g UVVJQzogdHJvdWJsZXNob290aW5nDQoNCldoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0d28g YmUgdXNlZCBmb3I/ICBJZiB0aGVyZSBpcyBubyBzdGFuZGFyZGl6ZWQgdXNlIG9mIHRob3NlIGJp dHMgaW4gdjEsIHRoZW4gSSBiZWxpZXZlIHdlIHNob3VsZCB3YWl0IHRvIHJlc2VydmUgdGhlbSB3 aGVuIHRoZWlyIHVzYWdlIGlzIGRlZmluZWQsIGdpdmVuIHdlJ2QgbmVlZCBhIHZlcnNpb24gYnVt cCB0byBzcGVjaWZ5IGhvdyB0aGV5IHdlcmUgYmVpbmcgdXNlZC4gIEF0IHRoZSBtb21lbnQsIHRo ZSBtYW5hZ2VtZW50IHVzZSBjYXNlIGlzIG5vdCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBm b3IgYml0cyBpbiB0aGUgc2hvcnQgaGVhZGVyLg0KDQpPbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCA1 OjE0IEFNLCA8ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPG1haWx0bzplbWlsZS5zdGVwaGFuQG9y YW5nZS5jb20+PiB3cm90ZToNCkhpDQoNCkxhc3Qgd2VlayBPcmFuZ2UgZXhwZXJpZW5jZWQgYSBm YWxsYmFjayBvZiBRVUlDIHRvIFRDUCBvbiBvbmUgb2YgaXRzIG5ldHdvcmtzLiBUaGUgaXNzdWVz IHdlcmUgbm90IHZpc2libGUgaW4gUVVJQyB0cmFmZmljLiBUaGUgdHJvdWJsZXNob290aW5nIHdh cyBtYWRlIHVzaW5nIFRDUCBwYWNrZXRzIGluZm9ybWF0aW9uLiBUaGlzIGlzIG5vdCBzdXN0YWlu YWJsZSBvbiB0aGUgbG9uZyB0ZXJtIHdoZW4gbnVtZXJvdXMgYXBwbGljYXRpb25zIHVzaW5nIGRp ZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdpbGwgc3RvcCB0byBmYWxsYmFjayB0byBUQ1AuDQoN CkJhc2VkIG9uIHRoZSBleGNoYW5nZSB3ZSBoYWQgaW4gdGhlIFJUVCBkZXNpZ24gdGVhbSBhbmQg aW4gdG9kYXkgbWVldGluZyAsIGl0IHNvdW5kcyByZWFzb25hYmxlIHRvIHJlc2VydmUgYXQgbGVh c3QgMiBiaXRzIChpZGVhbGx5IDMgYml0cyBhcyBkaXNjdXNzZWQgaW4gdGhlIGRlc2lnbiB0ZWFt KSBmb3IgbWFuYWdlYWJpbGl0eSBpbiB0aGUgUVVJQyBpbnZhcmlhbnRzIGFuZCB0byBzdGFydCBl eHBlcmltZW50aW5nIHRoZSBzcGluIGJpdCBpbiBRVUlDIFYxLg0KDQpSZWdhcmRzDQpFbWlsZQ0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdp ZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBk ZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ry b25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGlu ZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3Jt ZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0KDQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJp YnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWls cyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQg aGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0K DQo= --_000_B610969AA9F84DA4AB702C13C6A5FAC9nokiacom_ Content-Type: text/html; charset="utf-8" Content-ID: <4A23D8FBB0D628448241E37A2A017887@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6QXJpYWw7DQoJcGFub3NlLTE6MiAxMSA2IDQgMiAy IDIgMiAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCXBh bm9zZS0xOjIgNyAzIDkgMiAyIDUgMiA0IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpX aW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6VGFob21hOw0KCXBh bm9zZS0xOjIgMTEgNiA0IDMgNSA0IDQgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpw Lk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJ bWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6 IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5l O30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uSFRN TFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENo YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVm b3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvdXJpZXI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJ Y29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5NS4w cHQgODQyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAq Lw0KQGxpc3QgbDANCgl7bXNvLWxpc3QtaWQ6MjQ0MjcwMjgxOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczo4OTYxNzMwNDI7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2 LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjcyLjBwdDsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGkt Zm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEwOC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjE0NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjE4MC4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIxNi4wcHQ7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjI1Mi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjI4OC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMy NC4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0x OC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6NDgyNDMzMzg0Ow0KCW1zby1saXN0LXRlbXBs YXRlLWlkczotMTk1MTM3MDIyNDt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MzYuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MTA4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MTQ0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MTgwLjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjE2LjBwdDsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTps ZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MjUyLjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mjg4LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6MzI0LjBwdDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDo2ODEzMjU0ODI7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOi0xOTQ0MjkzMzQ0O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDozNi4wcHQ7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDo3Mi4wcHQ7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0K CW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVs Mw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDox ODAuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwyOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozMjQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1i b3R0b206MGNtO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIg bGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiYj NDM7MSBmb3IgdGhlIHJlYXNvbnMgc3RhdGVkIHVwLXRocmVhZCBhcyB3ZWxsIGFzIHllc3RlcmRh eSBhdCB0aGUgbWljLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmk7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OkNhbGlicmk7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPihBbmQgdGhhbmtzIEJyaWFuIGZv ciB0aGUgZ3JlYXQgYW5hbHlzaXMgb24gdGhlIHByaXZhY3kgaW1wbGljYXRpb25zLik8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPk9uIDE1LzExLzIwMTcsIDA5OjEw LCAmcXVvdDtRVUlDIG9uIGJlaGFsZiBvZiBEUlVUQSwgREFOJnF1b3Q7ICZsdDs8YSBocmVmPSJt YWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9u IGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFpbHRvOmRkNTgyNkBhdHQuY29tIj5kZDU4MjZAYXR0LmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjM2LjBwdCI+SSB3aWxsIGFkZCBteSBzdXBwb3J0IGZvciB0aGUgaW5jbHVzaW9uIG9mIHRo ZSBzcGluIGJpdCBpbnRvIFYxIGFuZCBtYWtlIGEgZmV3IG1vcmUgcG9pbnRzLg0KPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2 LjBwdCI+Q29uc2lkZXJpbmcgdGhhdCB0aGUgZGVzaWduIHRlYW0gYW5hbHlzaXMgY29uY2x1ZGVk IHRoYXQgdGhlIHNwaW4gYml0IGRvZXMgbm90IGFkZCBhbnkgYWRkaXRpb25hbCBwcml2YWN5IHJp c2sgYW5kIHRoZSB2ZXJ5IHNwZWNpZmljIG5lZWQgYWRkcmVzc2luZyBsYXRlbmN5IGhhcyBiZWVu IGRvY3VtZW50ZWQgYW5kIHZhbGlkYXRlZCBieSBhIGxhcmdlIG51bWJlcg0KIG9mIFdHIG1lbWJl cnMsIEkgYmVsaWV2ZSB0aGUgUVVJQyB3b3JraW5nIGdyb3VwIGhhcyBhIHVuaXF1ZSBvcHBvcnR1 bml0eSB0byBzaG93IHRoYXQgd2UgY2FuIGRlc2lnbiBwcm90b2NvbHMgdGhhdCBhcmUgZWZmaWNp ZW50LCBwcml2YWN5IHNlbnNpdGl2ZSBhbmQgbmV0d29yayBtYW5hZ2VtZW50IGZyaWVuZGx5Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjEy LjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0KVGhpcyBwYXJ0aWN1bGFyIGRlc2lnbiwgd2hpbGUg bm90IHBlcmZlY3QgZG9lcyBoYXZlIHRoZSBiaWdnZXN0IGJlbmVmaXQgcmVsYXRpdmUgdG8gdGhl IHJpc2tzIGFuZCBpdCBzaG91bGQgYmUgYWRvcHRlZCBmcm9tIHRoZSBiZWdpbm5pbmcuPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTMuMHB0Ij5CZXN0IFJlZ2Fy ZHMsPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+RGFuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowY207bWFyZ2luLXJpZ2h0OjBj bTttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDozNi4wcHQiPg0KPGJyPg0KT24gTm92 IDE1LCAyMDE3LCBhdCA1OjIxIEFNLCBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5z d2V0dEBnb29nbGUuY29tIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5UaGFua3MgZm9yIGNsYXJpZnlpbmcgRW1pbGUuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWxlZnQ6MzYuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij5PbiBUdWUsIE5vdiAxNCwg MjAxNyBhdCAxOjA2IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVtaWxlLnN0ZXBoYW5Ab3Jhbmdl LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2siPkhpIElh biw8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsYWNrIj4mbmJz cDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsYWNrIj5JdCB3 YXMgc3VnZ2VzdGVkIGluIHRoZSBsYXRlc3QgZGlzY3Vzc2lvbiBvbiB0aGUgUlRUIGRlc2lnbiB0 ZWFtIG1haWxpbmcgbGlzdCB0byBoYXZlIG9uZSBiaXQgZm9yIHBhY2tldCBsb3N0LCBvbmUgZm9y IGxhdGVuY3kgKHNwaW4gYml0IG9yIGVxLikgYW5kIG9uZSBmb3IgY29uZ2VzdGlvbi4NCjwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2siPkl0IHNlZW1zIGEg c2ltcGxpc3RpYyBhcHByb2FjaCBvbiBvbmUgaGFuZCBidXQgYW4gaW52YXJpYW50IG9uIHRoZSBs b25nIHRlcm0uPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFj ayI+UmVnYXJkczwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6Ymxh Y2siPkVtaWxlPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpibGFj ayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxiPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpUYWhvbWEiPkRlJm5ic3A7 Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OlRhaG9tYSI+IElhbiBTd2V0dCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppYW5zd2V0 dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT5dDQo8 YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWFyZGkgMTQgbm92ZW1icmUgMjAxNyAyMjo1MTxi cj4NCjxiPsOAJm5ic3A7OjwvYj4gU1RFUEhBTiBFbWlsZSBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJz cDs6PC9iPiBRVUlDIFdHPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogc3BpbiBiaXQgaW4g UVVJQzogdHJvdWJsZXNob290aW5nPC9zcGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVm dDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFu IGxhbmc9IkZSIj5XaGF0IHdvdWxkIHRoZSBvdGhlciBiaXQgb3IgdHdvIGJlIHVzZWQgZm9yPyZu YnNwOyBJZiB0aGVyZSBpcyBubyBzdGFuZGFyZGl6ZWQgdXNlIG9mIHRob3NlIGJpdHMgaW4gdjEs IHRoZW4gSSBiZWxpZXZlIHdlIHNob3VsZCB3YWl0IHRvIHJlc2VydmUgdGhlbSB3aGVuIHRoZWly IHVzYWdlIGlzIGRlZmluZWQsIGdpdmVuIHdlJ2QgbmVlZCBhIHZlcnNpb24gYnVtcCB0byBzcGVj aWZ5IGhvdyB0aGV5IHdlcmUgYmVpbmcgdXNlZC4mbmJzcDsNCiBBdCB0aGUgbW9tZW50LCB0aGUg bWFuYWdlbWVudCB1c2UgY2FzZSBpcyBub3QgY29tcGV0aW5nIHdpdGggYW55b25lIGVsc2UgZm9y IGJpdHMgaW4gdGhlIHNob3J0IGhlYWRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bWFyZ2luLWxlZnQ6MzYuMHB0Ij4NCjxzcGFu IGxhbmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJGUiI+T24gVHVl LCBOb3YgMTQsIDIwMTcgYXQgNToxNCBBTSwgJmx0OzxhIGhyZWY9Im1haWx0bzplbWlsZS5zdGVw aGFuQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5lbWlsZS5zdGVwaGFuQG9yYW5nZS5jb208 L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsYWNrIj5IaTwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2siPkxhc3Qgd2VlayBP cmFuZ2UgZXhwZXJpZW5jZWQgYSBmYWxsYmFjayBvZiBRVUlDIHRvIFRDUCBvbiBvbmUgb2YgaXRz IG5ldHdvcmtzLiBUaGUgaXNzdWVzIHdlcmUgbm90IHZpc2libGUgaW4gUVVJQyB0cmFmZmljLiBU aGUgdHJvdWJsZXNob290aW5nIHdhcyBtYWRlIHVzaW5nIFRDUCBwYWNrZXRzIGluZm9ybWF0aW9u Lg0KIFRoaXMgaXMgbm90IHN1c3RhaW5hYmxlIG9uIHRoZSBsb25nIHRlcm0gd2hlbiBudW1lcm91 cyBhcHBsaWNhdGlvbnMgdXNpbmcgZGlmZmVyZW50IHZlcnNpb25zIG9mIFFVSUMgd2lsbCBzdG9w IHRvIGZhbGxiYWNrIHRvIFRDUC48L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs O2NvbG9yOmJsYWNrIj5CYXNlZCBvbiB0aGUgZXhjaGFuZ2Ugd2UgaGFkIGluIHRoZSBSVFQgZGVz aWduIHRlYW0gYW5kIGluIHRvZGF5IG1lZXRpbmcgLCBpdCBzb3VuZHMgcmVhc29uYWJsZSB0byBy ZXNlcnZlIGF0IGxlYXN0IDIgYml0cyAoaWRlYWxseSAzIGJpdHMgYXMgZGlzY3Vzc2VkIGluIHRo ZSBkZXNpZ24gdGVhbSkgZm9yIG1hbmFnZWFiaWxpdHkNCiBpbiB0aGUgUVVJQyBpbnZhcmlhbnRz IGFuZCB0byBzdGFydCBleHBlcmltZW50aW5nIHRoZSBzcGluIGJpdCBpbiBRVUlDIFYxLjwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6YmxhY2siPlJlZ2FyZHM8L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttYXJnaW4tbGVmdDozNi4wcHQiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOmJsYWNrIj5FbWlsZTwvc3Bh bj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9w cmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkZSIj5wYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0 Ij48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRv dXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1h cmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJGUiI+ VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFs IG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBj b3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUg cmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFu ZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkZS Ij5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNz YWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFu IGxhbmc9IkZSIj5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8c3BhbiBs YW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBw dCI+PHNwYW4gbGFuZz0iRlIiPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBs YW5nPSJGUiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5p ciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUg ZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW4t bGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkZSIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVz IG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJGUiI+YSBsJ2V4 cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVz IG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+ PHNwYW4gbGFuZz0iRlIiPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4g bGFuZz0iRlIiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFy Z2luLWxlZnQ6MzYuMHB0Ij48c3BhbiBsYW5nPSJGUiI+VGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0 YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PHNwYW4gbGFuZz0iRlIiPnRoZXkgc2hv dWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0 aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6MzYu MHB0Ij48c3BhbiBsYW5nPSJGUiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJt YXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkZSIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVy ZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2Rp ZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIGxhbmc9IkZSIj5UaGFuayB5b3UuPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv dGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_B610969AA9F84DA4AB702C13C6A5FAC9nokiacom_-- From nobody Tue Nov 14 18:24:26 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 5005E126BF7; Tue, 14 Nov 2017 18:24:25 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: quic@ietf.org Subject: I-D Action: draft-ietf-quic-recovery-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.65.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151071266524.25968.9565229044620176016@ietfa.amsl.com> Date: Tue, 14 Nov 2017 18:24:25 -0800 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 02:24:25 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the QUIC WG of the IETF. Title : QUIC Loss Detection and Congestion Control Authors : Jana Iyengar Ian Swett Filename : draft-ietf-quic-recovery-07.txt Pages : 26 Date : 2017-11-14 Abstract: This document describes loss detection and congestion control mechanisms for QUIC. Note to Readers Discussion of this draft takes place on the QUIC working group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/search/?email_list=quic [1]. Working Group information can be found at https://github.com/quicwg [2]; source code and issues list for this draft can be found at https://github.com/quicwg/base-drafts/labels/recovery [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-recovery/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-recovery-07 https://datatracker.ietf.org/doc/html/draft-ietf-quic-recovery-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-recovery-07 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 14 18:54: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 46574127863 for ; Tue, 14 Nov 2017 18:54:51 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 0wwyg_Bsp4dC for ; Tue, 14 Nov 2017 18:54:47 -0800 (PST) Received: from mx03.telecomitalia.it (mx03.telecomitalia.it [217.169.121.23]) (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 F1BFE12948F for ; Tue, 14 Nov 2017 18:54:46 -0800 (PST) X-AuditID: d9a97917-5d3ff70000004801-c1-5a0bac7484cf Received: from TELMBXA06RM001.telecomitalia.local ( [10.14.252.34]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx03.telecomitalia.it () with SMTP id 15.90.18433.47CAB0A5; Wed, 15 Nov 2017 03:54:44 +0100 (CET) From: Fioccola Giuseppe To: "Huangyihong (Rachel)" , "DRUTA, DAN" , Ian Swett , QUIC WG CC: "emile.stephan@orange.com" Subject: R: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdsWjQiXFl+idYSdWDiJw89tZdFwAC2LYQ Date: Wed, 15 Nov 2017 02:54:44 +0000 Message-ID: <6d41835fd0a448e583a8f845ec5f5508@TELMBXB02RM001.telecomitalia.local> References: <51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1@nkgeml513-mbs.china.huawei.com> In-Reply-To: <51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1@nkgeml513-mbs.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.236] x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_6d41835fd0a448e583a8f845ec5f5508TELMBXB02RM001telecomit_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCKsWRmVeSWpSXmKPExsXCxfdHSbdkDXeUwa6fuhaT2i+xWhzc/4PF 4ue9nawWPQu4LZZ2nmJ3YPV42T+H0WPBplKPliNvWT2WLPnJ5NHy7CRbAGtUA6NNYl5efkli SapCSmpxsq2SS2Zxck5iZm5qkUJIak5qcn6ukkJmiq2SsZJCQU5icmpual6JrVJiQUFqXoqS HZcCBrABKsvMU0jNS85PycxLt1XyDPbXtbAwtdQ1VLILLE0tLslXyE0tLk5MT8/MV0hNWC+Y sWnRe/aCruNMFddnSzUwHtnH1MXIySEhYCLx5+oOdhBbSGAKk8S+TZ4gNpuAjcTBVyfYQGwR gX5GiXPdFiA2s4ClxKf/51hBbGEBXYlfj38zQtToS8yafAvKNpI4NXMj2EwWAVWJ18cWg83h FQiUOL/6JQvErlCJFRe+gNVzCoRJPP44lRnEZhSQlZiwexEjxC5xiRfTT7BD3CkgsWTPeWYI W1Ti5eN/rBC2gcTWpftYIGxFie1fj0PFZSQWHpnMCjEnX2JS5xpGiBsEJU7OfMIygVF0FpIV s5CUzUJSNouRAyiuKbF+lz5EiaLElO6HUOUaEq1z5rIjiy9gZF/FKJpbYWCsVwKJ1sySxJzM RL3Mkk2MwKR0c2Wl+A7G9pXOhxgFOBiVeHj3T+COEmJNLCuuzD3EKMHBrCTCm9wPFOJNSays Si3Kjy8qzUktPsToAwzIicxSosn5wISZVxJvaGJhaWhsYWFkaGFmikNYSZw38QVXlJBAOjDd ZaemFqQWwYxj4uAEJgEtAxv/BhHfL7Fvtjy0/9LcFPZwQYSJyIQOm/+LTst+ivgQr5XUt+Hw 6cMn7DL/805/fnyCAufb04rPt4hHlkcYhrlJF8zPWnRso7lp8UbZ/Lp1n9dGblH3X69nu10n hv3BORfvyULK9/7+83m3cckKl6N5nFMbTz2aW/cocd7SEwoPBU5db1yrxFKckWioxVxUnAgA zc9+7ncDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 02:54:51 -0000 --_000_6d41835fd0a448e583a8f845ec5f5508TELMBXB02RM001telecomit_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 SGkgQWxsLA0KSSBzdXBwb3J0IHRoZSBpbmNsdXNpb24gb2YgdGhlIHNwaW4gYml0IGludG8g VjEuIE15IHN1Z2dlc3Rpb24gaXMgdG8gaGF2ZSBvbmUgYml0IGZvciBwYWNrZXQgbG9zcywg b25lIGZvciBsYXRlbmN5IGFuZCBvbmUgZm9yIGNvbmdlc3Rpb24uIEkgd291bGQgYWxzbyBt ZW50aW9uIGRyYWZ0LWlldGYtaXBwbS1hbHQtbWFyayB0aGF0IGRldGFpbHMgaG93IHRvIHVz ZSBvbmUgYml0IG9yIHR3byBiaXRzIGZvciBwYWNrZXQgbG9zcyBhbmQgbGF0ZW5jeSBjYWxj dWxhdGlvbi4NCg0KQmVzdCBSZWdhcmRzLA0KDQpHaXVzZXBwZQ0KDQpEYTogUVVJQyBbbWFp bHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEh1YW5neWlob25nIChS YWNoZWwpDQpJbnZpYXRvOiBtZXJjb2xlZMOsIDE1IG5vdmVtYnJlIDIwMTcgMDI6MzUNCkE6 IERSVVRBLCBEQU47IElhbiBTd2V0dA0KQ2M6IFFVSUMgV0c7IGVtaWxlLnN0ZXBoYW5Ab3Jh bmdlLmNvbQ0KT2dnZXR0bzogUmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVzaG9vdGlu Zw0KDQpUaGF04oCZcyBhIGdvb2QgcG9pbnQuIEkgcmVhbGx5IHRoaW5rIHRoZSBiYWxhbmNl IHNob3VsZCBiZSBhY2hpZXZlZCBiZXR3ZWVuIHByaXZhY3kgYW5kIG9wZXJhdGlvbi4gU3Bp biBiaXQgaXMgYSBnb29kIGV4YW1wbGUuIEkgc3VwcG9ydCBpdC4NCg0KQlIsDQpSYWNoZWwN Cg0K5Y+R5Lu25Lq6OiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSDku6Po oaggRFJVVEEsIERBTg0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0MTHmnIgxNeaXpSA5OjExDQrm lLbku7bkuro6IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbTxtYWlsdG86aWFuc3dl dHRAZ29vZ2xlLmNvbT4+DQrmioTpgIE6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRv OnF1aWNAaWV0Zi5vcmc+PjsgZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPG1haWx0bzplbWls ZS5zdGVwaGFuQG9yYW5nZS5jb20+DQrkuLvpopg6IFJlOiBzcGluIGJpdCBpbiBRVUlDOiB0 cm91Ymxlc2hvb3RpbmcNCg0KSSB3aWxsIGFkZCBteSBzdXBwb3J0IGZvciB0aGUgaW5jbHVz aW9uIG9mIHRoZSBzcGluIGJpdCBpbnRvIFYxIGFuZCBtYWtlIGEgZmV3IG1vcmUgcG9pbnRz Lg0KQ29uc2lkZXJpbmcgdGhhdCB0aGUgZGVzaWduIHRlYW0gYW5hbHlzaXMgY29uY2x1ZGVk IHRoYXQgdGhlIHNwaW4gYml0IGRvZXMgbm90IGFkZCBhbnkgYWRkaXRpb25hbCBwcml2YWN5 IHJpc2sgYW5kIHRoZSB2ZXJ5IHNwZWNpZmljIG5lZWQgYWRkcmVzc2luZyBsYXRlbmN5IGhh cyBiZWVuIGRvY3VtZW50ZWQgYW5kIHZhbGlkYXRlZCBieSBhIGxhcmdlIG51bWJlciBvZiBX RyBtZW1iZXJzLCBJIGJlbGlldmUgdGhlIFFVSUMgd29ya2luZyBncm91cCBoYXMgYSB1bmlx dWUgb3Bwb3J0dW5pdHkgdG8gc2hvdyB0aGF0IHdlIGNhbiBkZXNpZ24gcHJvdG9jb2xzIHRo YXQgYXJlIGVmZmljaWVudCwgcHJpdmFjeSBzZW5zaXRpdmUgYW5kIG5ldHdvcmsgbWFuYWdl bWVudCBmcmllbmRseS4NClRoaXMgcGFydGljdWxhciBkZXNpZ24sIHdoaWxlIG5vdCBwZXJm ZWN0IGRvZXMgaGF2ZSB0aGUgYmlnZ2VzdCBiZW5lZml0IHJlbGF0aXZlIHRvIHRoZSByaXNr cyBhbmQgaXQgc2hvdWxkIGJlIGFkb3B0ZWQgZnJvbSB0aGUgYmVnaW5uaW5nLg0KQmVzdCBS ZWdhcmRzLA0KRGFuDQoNCg0KT24gTm92IDE1LCAyMDE3LCBhdCA1OjIxIEFNLCBJYW4gU3dl dHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PiB3 cm90ZToNClRoYW5rcyBmb3IgY2xhcmlmeWluZyBFbWlsZS4NCg0KT24gVHVlLCBOb3YgMTQs IDIwMTcgYXQgMTowNiBQTSwgPGVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbTxtYWlsdG86ZW1p bGUuc3RlcGhhbkBvcmFuZ2UuY29tPj4gd3JvdGU6DQpIaSBJYW4sDQoNCkl0IHdhcyBzdWdn ZXN0ZWQgaW4gdGhlIGxhdGVzdCBkaXNjdXNzaW9uIG9uIHRoZSBSVFQgZGVzaWduIHRlYW0g bWFpbGluZyBsaXN0IHRvIGhhdmUgb25lIGJpdCBmb3IgcGFja2V0IGxvc3QsIG9uZSBmb3Ig bGF0ZW5jeSAoc3BpbiBiaXQgb3IgZXEuKSBhbmQgb25lIGZvciBjb25nZXN0aW9uLg0KSXQg c2VlbXMgYSBzaW1wbGlzdGljIGFwcHJvYWNoIG9uIG9uZSBoYW5kIGJ1dCBhbiBpbnZhcmlh bnQgb24gdGhlIGxvbmcgdGVybS4NCg0KUmVnYXJkcw0KRW1pbGUNCg0KDQpEZSA6IElhbiBT d2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2ds ZS5jb20+XQ0KRW52b3nDqSA6IG1hcmRpIDE0IG5vdmVtYnJlIDIwMTcgMjI6NTENCsOAIDog U1RFUEhBTiBFbWlsZSBJTVQvT0xODQpDYyA6IFFVSUMgV0cNCk9iamV0IDogUmU6IHNwaW4g Yml0IGluIFFVSUM6IHRyb3VibGVzaG9vdGluZw0KDQpXaGF0IHdvdWxkIHRoZSBvdGhlciBi aXQgb3IgdHdvIGJlIHVzZWQgZm9yPyAgSWYgdGhlcmUgaXMgbm8gc3RhbmRhcmRpemVkIHVz ZSBvZiB0aG9zZSBiaXRzIGluIHYxLCB0aGVuIEkgYmVsaWV2ZSB3ZSBzaG91bGQgd2FpdCB0 byByZXNlcnZlIHRoZW0gd2hlbiB0aGVpciB1c2FnZSBpcyBkZWZpbmVkLCBnaXZlbiB3ZSdk IG5lZWQgYSB2ZXJzaW9uIGJ1bXAgdG8gc3BlY2lmeSBob3cgdGhleSB3ZXJlIGJlaW5nIHVz ZWQuICBBdCB0aGUgbW9tZW50LCB0aGUgbWFuYWdlbWVudCB1c2UgY2FzZSBpcyBub3QgY29t cGV0aW5nIHdpdGggYW55b25lIGVsc2UgZm9yIGJpdHMgaW4gdGhlIHNob3J0IGhlYWRlci4N Cg0KT24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgNToxNCBBTSwgPGVtaWxlLnN0ZXBoYW5Ab3Jh bmdlLmNvbTxtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPj4gd3JvdGU6DQpIaQ0K DQpMYXN0IHdlZWsgT3JhbmdlIGV4cGVyaWVuY2VkIGEgZmFsbGJhY2sgb2YgUVVJQyB0byBU Q1Agb24gb25lIG9mIGl0cyBuZXR3b3Jrcy4gVGhlIGlzc3VlcyB3ZXJlIG5vdCB2aXNpYmxl IGluIFFVSUMgdHJhZmZpYy4gVGhlIHRyb3VibGVzaG9vdGluZyB3YXMgbWFkZSB1c2luZyBU Q1AgcGFja2V0cyBpbmZvcm1hdGlvbi4gVGhpcyBpcyBub3Qgc3VzdGFpbmFibGUgb24gdGhl IGxvbmcgdGVybSB3aGVuIG51bWVyb3VzIGFwcGxpY2F0aW9ucyB1c2luZyBkaWZmZXJlbnQg dmVyc2lvbnMgb2YgUVVJQyB3aWxsIHN0b3AgdG8gZmFsbGJhY2sgdG8gVENQLg0KDQpCYXNl ZCBvbiB0aGUgZXhjaGFuZ2Ugd2UgaGFkIGluIHRoZSBSVFQgZGVzaWduIHRlYW0gYW5kIGlu IHRvZGF5IG1lZXRpbmcgLCBpdCBzb3VuZHMgcmVhc29uYWJsZSB0byByZXNlcnZlIGF0IGxl YXN0IDIgYml0cyAoaWRlYWxseSAzIGJpdHMgYXMgZGlzY3Vzc2VkIGluIHRoZSBkZXNpZ24g dGVhbSkgZm9yIG1hbmFnZWFiaWxpdHkgaW4gdGhlIFFVSUMgaW52YXJpYW50cyBhbmQgdG8g c3RhcnQgZXhwZXJpbWVudGluZyB0aGUgc3BpbiBiaXQgaW4gUVVJQyBWMS4NCg0KUmVnYXJk cw0KRW1pbGUNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRo YW5rIHlvdS4NCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBw aWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlk ZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2ln bmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBw aWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2Fi aWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUu IE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNv bnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVk LCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBl bWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRo YW5rIHlvdS4NCg0KDQpRdWVzdG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8g aW5kaXJpenphdGkgZXNjbHVzaXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBk aWZmdXNpb25lLCBjb3BpYSBvIHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRh bGxhIGNvbm9zY2VuemEgZGkgcXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVu dGUgdmlldGF0ZS4gUXVhbG9yYSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8g cGVyIGVycm9yZSBzaWV0ZSBjb3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlh dGEgY29tdW5pY2F6aW9uZSBhbCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEg ZGlzdHJ1emlvbmUsIEdyYXppZS4gDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVu dHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24s IGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jp c2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVs ZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNl bmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuIA0KDQpSaXNwZXR0YSBsJ2FtYmllbnRl LiBOb24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQo= --_000_6d41835fd0a448e583a8f845ec5f5508TELMBXB02RM001telecomit_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAx IDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiTVMgR290aGljIjsNCglw YW5vc2UtMToyIDExIDYgOSA3IDIgNSA4IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJNUyBHb3RoaWMiOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDcgMiA1IDggMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCkBmb250LWZh Y2UNCgl7Zm9udC1mYW1pbHk6IlNlZ29lIFVJIjsNCglwYW5vc2UtMToyIDExIDUgMiA0IDIg NCAyIDIgMzt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQE1TIEdvdGhpYyI7DQoJ cGFub3NlLTE6MiAxMSA2IDkgNyAyIDUgOCAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiXEBTaW1TdW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZv bnQtZmFjZQ0KCXtmb250LWZhbWlseTrlvq7ova/pm4Xpu5E7fQ0KLyogU3R5bGUgRGVmaW5p dGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7 bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCmE6bGluaywg c3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJs dWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNv SHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlByZWZvcm1hdHRhdG8gSFRNTCBDYXJh dHRlcmUiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRh dGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGVzdG8gZnVtZXR0byBDYXJhdHRlcmUiOw0KCW1h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsN Cglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5QcmVmb3JtYXR0 YXRvSFRNTENhcmF0dGVyZQ0KCXttc28tc3R5bGUtbmFtZToiUHJlZm9ybWF0dGF0byBIVE1M IENhcmF0dGVyZSI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5r OiJQcmVmb3JtYXR0YXRvIEhUTUwiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFzO30NCnAuSFRN TCwgbGkuSFRNTCwgZGl2LkhUTUwNCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC8 5byPIjsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8gQ2hhciI7DQoJbWFy Z2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnNwYW4uSFRNTENo YXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg6aKE6K6+5qC85byPIENoYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCDpooTorr7moLzlvI8i Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5TdGlsZU1lc3NhZ2dpb0Rp UG9zdGFFbGV0dHJvbmljYTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFu LlN0aWxlTWVzc2FnZ2lvRGlQb3N0YUVsZXR0cm9uaWNhMjINCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCnNwYW4uVGVzdG9mdW1ldHRvQ2FyYXR0ZXJlDQoJe21zby1z dHlsZS1uYW1lOiJUZXN0byBmdW1ldHRvIENhcmF0dGVyZSI7DQoJbXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXN0byBmdW1ldHRvIjsNCglmb250LWZhbWls eToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA5MC4wcHQg NzIuMHB0IDkwLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+ DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48 L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IklUIiBsaW5rPSJibHVl IiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEFsbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgc3VwcG9ydCB0aGUgaW5jbHVzaW9uIG9mIHRoZSBz cGluIGJpdCBpbnRvIFYxLiBNeSBzdWdnZXN0aW9uIGlzIHRvIGhhdmUgb25lIGJpdCBmb3Ig cGFja2V0IGxvc3MsIG9uZSBmb3IgbGF0ZW5jeSBhbmQgb25lIGZvciBjb25nZXN0aW9uLiBJ IHdvdWxkDQogYWxzbyBtZW50aW9uIDx1PmRyYWZ0LWlldGYtaXBwbS1hbHQtbWFyazwvdT4g dGhhdCBkZXRhaWxzIGhvdyB0byB1c2Ugb25lIGJpdCBvciB0d28gYml0cyBmb3IgcGFja2V0 IGxvc3MgYW5kIGxhdGVuY3kgY2FsY3VsYXRpb24uPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+QmVzdCBSZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+ R2l1c2VwcGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPkRhOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5QZXIgY29udG8gZGkg PC9iPkh1YW5neWlob25nIChSYWNoZWwpPGJyPg0KPGI+SW52aWF0bzo8L2I+IG1lcmNvbGVk w6wgMTUgbm92ZW1icmUgMjAxNyAwMjozNTxicj4NCjxiPkE6PC9iPiBEUlVUQSwgREFOOyBJ YW4gU3dldHQ8YnI+DQo8Yj5DYzo8L2I+IFFVSUMgV0c7IGVtaWxlLnN0ZXBoYW5Ab3Jhbmdl LmNvbTxicj4NCjxiPk9nZ2V0dG86PC9iPiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJs ZXNob290aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGF04oCZcyBhIGdvb2Qg cG9pbnQuIEkgcmVhbGx5IHRoaW5rIHRoZSBiYWxhbmNlIHNob3VsZCBiZSBhY2hpZXZlZCBi ZXR3ZWVuIHByaXZhY3kgYW5kIG9wZXJhdGlvbi4gU3BpbiBiaXQgaXMgYSBnb29kDQogZXhh bXBsZS4gSSBzdXBwb3J0IGl0LiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+QlIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5SYWNoZWw8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6U2ltU3VuO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7lj5Hku7bkuro8L3NwYW4+ PC9iPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTrlvq7ova/pm4Xpu5E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTrlvq7ova/pm4Xpu5E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KIFFV SUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPm1haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSA8L3NwYW4+DQo8Yj48c3BhbiBsYW5nPSJaSC1DTiIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1 b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7ku6Pooag8L3NwYW4+PC9iPjxiPjxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrl vq7ova/pm4Xpu5E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KPC9zcGFuPjwvYj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 5b6u6L2v6ZuF6buRO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5EUlVUQSwgREFOPGJy Pg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTpTaW1TdW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuWPkemA geaXtumXtDwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+DQogMjAxNzwvc3Bhbj48c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TVMgR290aGljJnF1b3Q7O21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj7lubQ8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+MTE8L3NwYW4+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdvdGhpYyZxdW90Ozttc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5pyIPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrlvq7ova/pm4Xpu5E7bXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjE1PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuaXpTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO21z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiA5OjExPGJyPg0KPC9zcGFuPjxiPjxzcGFu IGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtNUyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuaUtuS7tuS6 ujwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+DQogSWFuIFN3ZXR0ICZsdDs8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNv bSI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxh bmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtN UyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuaKhOmAgTwvc3Bh bj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OuW+rui9r+mbhem7kTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Ojwv c3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OuW+rui9r+mbhem7kTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQog UVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5v cmc8L2E+Jmd0OzsgPGEgaHJlZj0ibWFpbHRvOmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbSI+ DQplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb208L2E+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxh bmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtN UyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuS4uzwvc3Bhbj48 L2I+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+6aKYPC9zcGFuPjwv Yj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk65b6u6L2v6ZuF6buRO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj46PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk65b6u6L2v6ZuF6buRO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiBSZTog c3BpbiBiaXQgaW4gUVVJQzogdHJvdWJsZXNob290aW5nPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkkgd2lsbCBhZGQgbXkgc3Vw cG9ydCBmb3IgdGhlIGluY2x1c2lvbiBvZiB0aGUgc3BpbiBiaXQgaW50byBWMSBhbmQgbWFr ZSBhIGZldyBtb3JlIHBvaW50cy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5Db25zaWRlcmluZyB0aGF0IHRoZSBkZXNpZ24gdGVhbSBh bmFseXNpcyBjb25jbHVkZWQgdGhhdCB0aGUgc3BpbiBiaXQgZG9lcyBub3QgYWRkIGFueSBh ZGRpdGlvbmFsIHByaXZhY3kgcmlzayBhbmQgdGhlIHZlcnkgc3BlY2lmaWMgbmVlZCBhZGRy ZXNzaW5nIGxhdGVuY3kgaGFzIGJlZW4gZG9jdW1lbnRlZCBhbmQgdmFsaWRhdGVkDQogYnkg YSBsYXJnZSBudW1iZXIgb2YgV0cgbWVtYmVycywgSSBiZWxpZXZlIHRoZSBRVUlDIHdvcmtp bmcgZ3JvdXAgaGFzIGEgdW5pcXVlIG9wcG9ydHVuaXR5IHRvIHNob3cgdGhhdCB3ZSBjYW4g ZGVzaWduIHByb3RvY29scyB0aGF0IGFyZSBlZmZpY2llbnQsIHByaXZhY3kgc2Vuc2l0aXZl IGFuZCBuZXR3b3JrIG1hbmFnZW1lbnQgZnJpZW5kbHkuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5UaGlzIHBhcnRpY3VsYXIgZGVzaWduLCB3aGlsZSBub3QgcGVyZmVj dCBkb2VzIGhhdmUgdGhlIGJpZ2dlc3QgYmVuZWZpdCByZWxhdGl2ZSB0byB0aGUgcmlza3Mg YW5kIGl0IHNob3VsZCBiZSBhZG9wdGVkIGZyb20gdGhlIGJlZ2lubmluZy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEzLjBwdDttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+QmVzdCBSZWdhcmRzLDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5EYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KT24gTm92 IDE1LCAyMDE3LCBhdCA1OjIxIEFNLCBJYW4gU3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzpp YW5zd2V0dEBnb29nbGUuY29tIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDsgd3JvdGU6 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+VGhhbmtzIGZvciBjbGFyaWZ5aW5nIEVtaWxlLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5PbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCAxOjA2IFBNLCAmbHQ7PGEgaHJlZj0ibWFpbHRv OmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVtaWxlLnN0ZXBo YW5Ab3JhbmdlLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGNtO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj5IaSBJYW4sPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNw Ozwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JdCB3YXMgc3VnZ2VzdGVkIGluIHRoZSBs YXRlc3QgZGlzY3Vzc2lvbiBvbiB0aGUgUlRUIGRlc2lnbiB0ZWFtDQogbWFpbGluZyBsaXN0 IHRvIGhhdmUgb25lIGJpdCBmb3IgcGFja2V0IGxvc3QsIG9uZSBmb3IgbGF0ZW5jeSAoc3Bp biBiaXQgb3IgZXEuKSBhbmQgb25lIGZvciBjb25nZXN0aW9uLg0KPC9zcGFuPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPkl0IHNlZW1zIGEgc2ltcGxpc3RpYyBhcHByb2FjaCBvbiBvbmUgaGFu ZCBidXQgYW4gaW52YXJpYW50IG9uDQogdGhlIGxvbmcgdGVybS48L3NwYW4+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1V UyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlJlZ2FyZHM8 L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjaztt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RW1pbGU8L3NwYW4+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KIElhbiBTd2V0 dCBbbWFpbHRvOjxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9 Il9ibGFuayI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT5dDQo8YnI+DQo8Yj5FbnZvecOpJm5i c3A7OjwvYj4gbWFyZGkgMTQgbm92ZW1icmUgMjAxNyAyMjo1MTxicj4NCjxiPsOAJm5ic3A7 OjwvYj4gU1RFUEhBTiBFbWlsZSBJTVQvT0xOPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBRVUlD IFdHPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJv dWJsZXNob290aW5nPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5XaGF0IHdvdWxkIHRoZSBvdGhlciBiaXQg b3IgdHdvIGJlIHVzZWQgZm9yPyZuYnNwOyBJZiB0aGVyZSBpcyBubyBzdGFuZGFyZGl6ZWQg dXNlIG9mIHRob3NlIGJpdHMgaW4gdjEsIHRoZW4gSSBiZWxpZXZlIHdlIHNob3VsZCB3YWl0 DQogdG8gcmVzZXJ2ZSB0aGVtIHdoZW4gdGhlaXIgdXNhZ2UgaXMgZGVmaW5lZCwgZ2l2ZW4g d2UnZCBuZWVkIGEgdmVyc2lvbiBidW1wIHRvIHNwZWNpZnkgaG93IHRoZXkgd2VyZSBiZWlu ZyB1c2VkLiZuYnNwOyBBdCB0aGUgbW9tZW50LCB0aGUgbWFuYWdlbWVudCB1c2UgY2FzZSBp cyBub3QgY29tcGV0aW5nIHdpdGggYW55b25lIGVsc2UgZm9yIGJpdHMgaW4gdGhlIHNob3J0 IGhlYWRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk9uIFR1ZSwgTm92IDE0LCAyMDE3IGF0IDU6MTQgQU0s ICZsdDs8YSBocmVmPSJtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tIiB0YXJnZXQ9 Il9ibGFuayI+ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5IaTwvc3Bhbj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+TGFzdCB3ZWVrIE9yYW5nZSBl eHBlcmllbmNlZCBhIGZhbGxiYWNrIG9mIFFVSUMgdG8gVENQIG9uIG9uZQ0KIG9mIGl0cyBu ZXR3b3Jrcy4gVGhlIGlzc3VlcyB3ZXJlIG5vdCB2aXNpYmxlIGluIFFVSUMgdHJhZmZpYy4g VGhlIHRyb3VibGVzaG9vdGluZyB3YXMgbWFkZSB1c2luZyBUQ1AgcGFja2V0cyBpbmZvcm1h dGlvbi4gVGhpcyBpcyBub3Qgc3VzdGFpbmFibGUgb24gdGhlIGxvbmcgdGVybSB3aGVuIG51 bWVyb3VzIGFwcGxpY2F0aW9ucyB1c2luZyBkaWZmZXJlbnQgdmVyc2lvbnMgb2YgUVVJQyB3 aWxsIHN0b3AgdG8gZmFsbGJhY2sgdG8gVENQLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QmFzZWQgb24gdGhlIGV4Y2hh bmdlIHdlIGhhZCBpbiB0aGUgUlRUIGRlc2lnbiB0ZWFtIGFuZCBpbiB0b2RheQ0KIG1lZXRp bmcgLCBpdCBzb3VuZHMgcmVhc29uYWJsZSB0byByZXNlcnZlIGF0IGxlYXN0IDIgYml0cyAo aWRlYWxseSAzIGJpdHMgYXMgZGlzY3Vzc2VkIGluIHRoZSBkZXNpZ24gdGVhbSkgZm9yIG1h bmFnZWFiaWxpdHkgaW4gdGhlIFFVSUMgaW52YXJpYW50cyBhbmQgdG8gc3RhcnQgZXhwZXJp bWVudGluZyB0aGUgc3BpbiBiaXQgaW4gUVVJQyBWMS48L3NwYW4+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlJlZ2FyZHM8L3NwYW4+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpaSC1DTiI+RW1pbGU8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNv cGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBw YXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj5hIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBs YW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5PcmFuZ2UgZGVj bGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwg ZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGlzIG1lc3NhZ2UgYW5kIGl0 cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OzxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOlpILUNOIj50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3Ig Y29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5v dGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBz dHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVu IG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwcmU+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG UiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+Q2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1 dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0 aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6 IGxlIHNpZ25hbGVyPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmll LiBNZXJjaS48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6WkgtQ04iPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5 IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPnRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJG UiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy48bzpwPjwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQg b3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5n PSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGFuayB5b3UuPG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPGh0bWw+DQoJPGJvZHk+DQoJCTx0YWJsZSBzdHlsZT0id2lkdGg6NjAwcHg7Ij4N CgkJCTx0ZCBzdHlsZT0id2lkdGg6NTg1cHg7IGZvbnQtZmFtaWx5OiBWZXJkYW5hOyBmb250 LXNpemU6Ny41cHQ7IGNvbG9yOiMwMDA7IHRleHQtYWxpZ246IGp1c3RpZnkiIHdpZHRoPSIz OTUiPg0KCQkJCVF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRp cml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1 c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEg Y29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2 aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIg ZXJyb3JlIHNpZXRlIGNvcnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBj b211bmljYXppb25lIGFsIG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0 cnV6aW9uZSwgR3JhemllLg0KCQkJCTxicj48YnI+DQoJCQkJPGk+DQoJCQkJCVRoaXMgZS1t YWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgIGNvbnRh aW4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShz KSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55 Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVk IHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2ht ZW50cyBhbmQgYWR2aXNlIHRoZSBzZW5kZXIgYnkgcmV0dXJuICBlLW1haWwsIFRoYW5rcy4N CgkJCQk8L2k+DQoJCQkJPGJyPjxicj4NCgkJCQk8Yj5SaXNwZXR0YSBsJ2FtYmllbnRlLiBO b24gc3RhbXBhcmUgcXVlc3RhIG1haWwgc2Ugbm9uICZlZ3JhdmU7IG5lY2Vzc2FyaW8uPC9i Pg0KCQkJPC90ZD4NCgkJPC90YWJsZT4NCgk8L2JvZHk+DQo8L2h0bWw+DQo8L2JvZHk+DQo8 L2h0bWw+DQo= --_000_6d41835fd0a448e583a8f845ec5f5508TELMBXB02RM001telecomit_-- From nobody Tue Nov 14 18:55: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 254891294B7 for ; Tue, 14 Nov 2017 18:55:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 QPtGMWSk60fV for ; Tue, 14 Nov 2017 18:55:41 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0a-00191d01.pphosted.com [67.231.149.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E9BA1294C4 for ; Tue, 14 Nov 2017 18:55:35 -0800 (PST) Received: from pps.filterd (m0053301.ppops.net [127.0.0.1]) by mx0a-00191d01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAF1js9n025090; Tue, 14 Nov 2017 20:52:22 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by mx0a-00191d01.pphosted.com with ESMTP id 2e88vjcbgw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 14 Nov 2017 20:52:22 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id vAF1qKWf031511; Tue, 14 Nov 2017 19:52:21 -0600 Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id vAF1qGBs031502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Nov 2017 19:52:16 -0600 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint02.pst.cso.att.com (RSA Interceptor); Wed, 15 Nov 2017 01:52:00 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id vAF1q0xm007816; Tue, 14 Nov 2017 19:52:00 -0600 Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.178.11]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id vAF1ptfm007559; Tue, 14 Nov 2017 19:51:55 -0600 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-blue.research.att.com (Postfix) with ESMTP id C6FF0F0EEC; Tue, 14 Nov 2017 20:51:54 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0361.001; Tue, 14 Nov 2017 20:51:54 -0500 From: "MORTON, ALFRED C (AL)" To: Ian Swett , "emile.stephan@orange.com" CC: QUIC WG Subject: RE: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFwAULTIAAAbTAwAABsr3AAABszfg Date: Wed, 15 Nov 2017 01:51:54 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [31.133.131.38] Content-Type: multipart/alternative; boundary="_000_4D7F4AD313D3FC43A053B309F97543CF490457FAnjmtexg5researc_" MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150023 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 02:55:43 -0000 --_000_4D7F4AD313D3FC43A053B309F97543CF490457FAnjmtexg5researc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SeKAmWQgbGlrZSB0byBvZmZlciBzdXBwb3J0IGZvciBTcGluIEJpdCAoYW5kIG9uZSBvciB0d28N CmJpdHMgZm9yIG1hbmFnZW1lbnQgaWYgdGhleSBjYW4gYmUganVzdGlmaWVkIHF1aWNrbHkpIGlu IHYxLg0KT24gdGhpcyB0b3BpYyBvZiBtb3JlIGJpdHMsDQphc2tpbmcgZnVydGhlciBjbGFyaWZp Y2F0aW9uIGZyb20gRW1pbGUsIGJlbG93IFtBQ01dLg0KQWwNCg0KRnJvbTogUVVJQyBbbWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElhbiBTd2V0dA0KU2VudDogVHVl c2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgNDoyMSBQTQ0KVG86IGVtaWxlLnN0ZXBoYW5Ab3Jhbmdl LmNvbQ0KQ2M6IFFVSUMgV0cNClN1YmplY3Q6IFJlOiBzcGluIGJpdCBpbiBRVUlDOiB0cm91Ymxl c2hvb3RpbmcNCg0KVGhhbmtzIGZvciBjbGFyaWZ5aW5nIEVtaWxlLg0KDQpPbiBUdWUsIE5vdiAx NCwgMjAxNyBhdCAxOjA2IFBNLCA8ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPG1haWx0bzplbWls ZS5zdGVwaGFuQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpIElhbiwNCkl0IHdhcyBzdWdnZXN0ZWQg aW4gdGhlIGxhdGVzdCBkaXNjdXNzaW9uIG9uIHRoZSBSVFQgZGVzaWduIHRlYW0gbWFpbGluZyBs aXN0IHRvIGhhdmUgb25lIGJpdCBmb3IgcGFja2V0IGxvc3QsIG9uZSBmb3IgbGF0ZW5jeSAoc3Bp biBiaXQgb3IgZXEuKSBhbmQgb25lIGZvciBjb25nZXN0aW9uLg0KW0FDTV0gIFRoZXJlIG1heSBi ZSBzb21lIG92ZXJsYXAgd2l0aCBFQ04gYW5kIMKrIG9uZSBiaXQgZm9yIGNvbmdlc3Rpb24gwrsu DQpEaWQgeW91IGFsc28gY29uc2lkZXIgdGhpcyBkZXBlbmRlbmN5LCBFbWlsZSA/IChJ4oCZbSBl Y2hvaW5nIGEgaGFsbHdheSBkaXNjdXNzaW9uKQ0KDQpJdCBzZWVtcyBhIHNpbXBsaXN0aWMgYXBw cm9hY2ggb24gb25lIGhhbmQgYnV0IGFuIGludmFyaWFudCBvbiB0aGUgbG9uZyB0ZXJtLg0KDQpS ZWdhcmRzDQpFbWlsZQ0KDQoNCkRlIDogSWFuIFN3ZXR0IFttYWlsdG86aWFuc3dldHRAZ29vZ2xl LmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT5dDQpFbnZvecOpIDogbWFyZGkgMTQgbm92 ZW1icmUgMjAxNyAyMjo1MQ0Kw4AgOiBTVEVQSEFOIEVtaWxlIElNVC9PTE4NCkNjIDogUVVJQyBX Rw0KT2JqZXQgOiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJsZXNob290aW5nDQoNCldoYXQg d291bGQgdGhlIG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBmb3I/ICBJZiB0aGVyZSBpcyBubyBz dGFuZGFyZGl6ZWQgdXNlIG9mIHRob3NlIGJpdHMgaW4gdjEsIHRoZW4gSSBiZWxpZXZlIHdlIHNo b3VsZCB3YWl0IHRvIHJlc2VydmUgdGhlbSB3aGVuIHRoZWlyIHVzYWdlIGlzIGRlZmluZWQsIGdp dmVuIHdlJ2QgbmVlZCBhIHZlcnNpb24gYnVtcCB0byBzcGVjaWZ5IGhvdyB0aGV5IHdlcmUgYmVp bmcgdXNlZC4gIEF0IHRoZSBtb21lbnQsIHRoZSBtYW5hZ2VtZW50IHVzZSBjYXNlIGlzIG5vdCBj b21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBmb3IgYml0cyBpbiB0aGUgc2hvcnQgaGVhZGVyLg0K DQpPbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCA1OjE0IEFNLCA8ZW1pbGUuc3RlcGhhbkBvcmFuZ2Uu Y29tPG1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+PiB3cm90ZToNCkhpDQoNCkxhc3Qg d2VlayBPcmFuZ2UgZXhwZXJpZW5jZWQgYSBmYWxsYmFjayBvZiBRVUlDIHRvIFRDUCBvbiBvbmUg b2YgaXRzIG5ldHdvcmtzLiBUaGUgaXNzdWVzIHdlcmUgbm90IHZpc2libGUgaW4gUVVJQyB0cmFm ZmljLiBUaGUgdHJvdWJsZXNob290aW5nIHdhcyBtYWRlIHVzaW5nIFRDUCBwYWNrZXRzIGluZm9y bWF0aW9uLiBUaGlzIGlzIG5vdCBzdXN0YWluYWJsZSBvbiB0aGUgbG9uZyB0ZXJtIHdoZW4gbnVt ZXJvdXMgYXBwbGljYXRpb25zIHVzaW5nIGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdpbGwg c3RvcCB0byBmYWxsYmFjayB0byBUQ1AuDQoNCkJhc2VkIG9uIHRoZSBleGNoYW5nZSB3ZSBoYWQg aW4gdGhlIFJUVCBkZXNpZ24gdGVhbSBhbmQgaW4gdG9kYXkgbWVldGluZyAsIGl0IHNvdW5kcyBy ZWFzb25hYmxlIHRvIHJlc2VydmUgYXQgbGVhc3QgMiBiaXRzIChpZGVhbGx5IDMgYml0cyBhcyBk aXNjdXNzZWQgaW4gdGhlIGRlc2lnbiB0ZWFtKSBmb3IgbWFuYWdlYWJpbGl0eSBpbiB0aGUgUVVJ QyBpbnZhcmlhbnRzIGFuZCB0byBzdGFydCBleHBlcmltZW50aW5nIHRoZSBzcGluIGJpdCBpbiBR VUlDIFYxLg0KDQpSZWdhcmRzDQpFbWlsZQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0K DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KDQoNCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYw0KDQpwYXMg ZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl cg0KDQphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLA0KDQpPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQoNCg0KDQpU aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwg b3IgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Ow0K DQp0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4NCg0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBp dHMgYXR0YWNobWVudHMuDQoNCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5v dCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9y IGZhbHNpZmllZC4NCg0KVGhhbmsgeW91Lg0KDQo= --_000_4D7F4AD313D3FC43A053B309F97543CF490457FAnjmtexg5researc_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5Nc29BY2V0YXRlLCBsaS5N c29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIs InNhbnMtc2VyaWYiO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5h bWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OkNvbnNvbGFz O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJY29sb3I6YmxhY2s7fQ0Kc3Bhbi5CYWxsb29u VGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5 bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1m YW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90Oztjb2xvcjpibGFjayI+SeKAmWQgbGlrZSB0byBvZmZlciBzdXBwb3J0IGZvciBT cGluIEJpdCAoYW5kIG9uZSBvciB0d288bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Yml0cyBmb3IgbWFuYWdlbWVudCBpZiB0 aGV5IGNhbiBiZSBqdXN0aWZpZWQgcXVpY2tseSkgaW4gdjEuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPk9uIHRoaXMgdG9w aWMgb2YgbW9yZSBiaXRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5hc2tpbmcgZnVydGhlciBjbGFyaWZpY2F0aW9uIGZy b20gRW1pbGUsIGJlbG93IFtBQ01dLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5BbDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwv Yj5JYW4gU3dldHQ8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcg NDoyMSBQTTxicj4NCjxiPlRvOjwvYj4gZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPGJyPg0KPGI+ Q2M6PC9iPiBRVUlDIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBzcGluIGJpdCBpbiBRVUlD OiB0cm91Ymxlc2hvb3Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+VGhhbmtzIGZvciBjbGFyaWZ5aW5nIEVtaWxlLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gVHVlLCBOb3YgMTQsIDIwMTcgYXQg MTowNiBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20iIHRh cmdldD0iX2JsYW5rIj5lbWlsZS5zdGVwaGFuQG9yYW5nZS5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5IaSBJYW4sPC9zcGFuPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SXQg d2FzIHN1Z2dlc3RlZCBpbiB0aGUgbGF0ZXN0IGRpc2N1c3Npb24gb24gdGhlIFJUVCBkZXNpZ24g dGVhbSBtYWlsaW5nIGxpc3QgdG8gaGF2ZSBvbmUgYml0IGZvciBwYWNrZXQNCiBsb3N0LCBvbmUg Zm9yIGxhdGVuY3kgKHNwaW4gYml0IG9yIGVxLikgYW5kIG9uZSBmb3IgY29uZ2VzdGlvbi4gPC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij5bQUNNXQ0KPC9zcGFuPjwvaT48L2I+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4m bmJzcDtUaGVyZSBtYXkgYmUgc29tZSBvdmVybGFwIHdpdGggRUNOIGFuZCDCqyZuYnNwO29uZSBi aXQgZm9yIGNvbmdlc3Rpb24mbmJzcDvCuy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+RGlkIHlvdSBh bHNvIGNvbnNpZGVyIHRoaXMgZGVwZW5kZW5jeSwgRW1pbGUmbmJzcDs/IChJ4oCZbSBlY2hvaW5n IGEgaGFsbHdheSBkaXNjdXNzaW9uKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkl0IHNlZW1zIGEgc2ltcGxpc3RpYyBhcHByb2FjaCBvbiBv bmUgaGFuZCBidXQgYW4gaW52YXJpYW50IG9uIHRoZSBsb25nIHRlcm0uPC9zcGFuPjxzcGFuIGxh bmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBs YW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZWdhcmRzPC9zcGFuPjxzcGFu IGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPkVtaWxlPC9zcGFuPjxzcGFu IGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNw YW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PGI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IElhbiBTd2V0dA0K IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20iIHRhcmdldD0iX2Js YW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9i PiBtYXJkaSAxNCBub3ZlbWJyZSAyMDE3IDIyOjUxPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBTVEVQ SEFOIEVtaWxlIElNVC9PTE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IFFVSUMgV0c8YnI+DQo8Yj5P YmpldCZuYnNwOzo8L2I+IFJlOiBzcGluIGJpdCBpbiBRVUlDOiB0cm91Ymxlc2hvb3Rpbmc8L3Nw YW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiI+Jm5ic3A7PG86cD48L286cD48 L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIi PldoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBmb3I/Jm5ic3A7IElmIHRo ZXJlIGlzIG5vIHN0YW5kYXJkaXplZCB1c2Ugb2YgdGhvc2UgYml0cyBpbiB2MSwgdGhlbiBJIGJl bGlldmUgd2Ugc2hvdWxkIHdhaXQgdG8gcmVzZXJ2ZSB0aGVtIHdoZW4gdGhlaXIgdXNhZ2UNCiBp cyBkZWZpbmVkLCBnaXZlbiB3ZSdkIG5lZWQgYSB2ZXJzaW9uIGJ1bXAgdG8gc3BlY2lmeSBob3cg dGhleSB3ZXJlIGJlaW5nIHVzZWQuJm5ic3A7IEF0IHRoZSBtb21lbnQsIHRoZSBtYW5hZ2VtZW50 IHVzZSBjYXNlIGlzIG5vdCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBmb3IgYml0cyBpbiB0 aGUgc2hvcnQgaGVhZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZuYnNwOzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkZSIj5P biBUdWUsIE5vdiAxNCwgMjAxNyBhdCA1OjE0IEFNLCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmVtaWxl LnN0ZXBoYW5Ab3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVtaWxlLnN0ZXBoYW5Ab3Jhbmdl LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+SGk8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5MYXN0IHdlZWsgT3JhbmdlIGV4cGVyaWVuY2VkIGEgZmFs bGJhY2sgb2YgUVVJQyB0byBUQ1Agb24gb25lIG9mIGl0cyBuZXR3b3Jrcy4gVGhlIGlzc3VlcyB3 ZXJlIG5vdCB2aXNpYmxlDQogaW4gUVVJQyB0cmFmZmljLiBUaGUgdHJvdWJsZXNob290aW5nIHdh cyBtYWRlIHVzaW5nIFRDUCBwYWNrZXRzIGluZm9ybWF0aW9uLiBUaGlzIGlzIG5vdCBzdXN0YWlu YWJsZSBvbiB0aGUgbG9uZyB0ZXJtIHdoZW4gbnVtZXJvdXMgYXBwbGljYXRpb25zIHVzaW5nIGRp ZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdpbGwgc3RvcCB0byBmYWxsYmFjayB0byBUQ1AuPC9z cGFuPjxzcGFuIGxhbmc9IkZSIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwv c3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CYXNlZCBv biB0aGUgZXhjaGFuZ2Ugd2UgaGFkIGluIHRoZSBSVFQgZGVzaWduIHRlYW0gYW5kIGluIHRvZGF5 IG1lZXRpbmcgLCBpdCBzb3VuZHMgcmVhc29uYWJsZSB0byByZXNlcnZlDQogYXQgbGVhc3QgMiBi aXRzIChpZGVhbGx5IDMgYml0cyBhcyBkaXNjdXNzZWQgaW4gdGhlIGRlc2lnbiB0ZWFtKSBmb3Ig bWFuYWdlYWJpbGl0eSBpbiB0aGUgUVVJQyBpbnZhcmlhbnRzIGFuZCB0byBzdGFydCBleHBlcmlt ZW50aW5nIHRoZSBzcGluIGJpdCBpbiBRVUlDIFYxLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJkczwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FbWlsZTwvc3Bhbj48c3BhbiBsYW5nPSJGUiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8c3Bh biBsYW5nPSJGUiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9 IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIi PkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+cGFzIGV0 cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZv dXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBlZGl0 ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNz YWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5PcmFuZ2UgZGVjbGluZSB0 b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBv dSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxh bmc9IkZSIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0i RlIiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBs YXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj50aGV5IHNo b3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNh dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPklmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+QXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZT48c3BhbiBsYW5nPSJGUiI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRlIiPiZu YnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj5fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBq b2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMg b3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZT48c3BhbiBsYW5nPSJGUiI+cGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmU+PHNwYW4gbGFuZz0iRlIiPmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1 ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1 c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxz cGFuIGxhbmc9IkZSIj5PcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlPjxzcGFuIGxhbmc9IkZSIj50aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVz ZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxwcmU+PHNwYW4gbGFuZz0iRlIiPklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3Bh biBsYW5nPSJGUiI+QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT48c3BhbiBsYW5nPSJGUiI+VGhhbmsg eW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_4D7F4AD313D3FC43A053B309F97543CF490457FAnjmtexg5researc_-- From nobody Tue Nov 14 19:25: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 54D881286CA for ; Tue, 14 Nov 2017 19:25:07 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CarflwMyhFWC for ; Tue, 14 Nov 2017 19:25:06 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 071111275AB for ; Tue, 14 Nov 2017 19:25:06 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 981B6CE7A8B8F for ; Wed, 15 Nov 2017 03:25:02 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 03:25:03 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 11:24:59 +0800 From: Roni Even To: QUIC WG Subject: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQ== Date: Wed, 15 Nov 2017 03:24:59 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.42.100] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD836EFADGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:25:07 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD836EFADGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, When moving from cell to wifi the reason may be due to cost (money or quota= ). In this case the user (client) may want to move to wifi even if it will= mean dropping to TCP. Roni --_000_6E58094ECC8D8344914996DAD28F1CCD836EFADGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the  user (client) may want to = move to wifi even if it will mean dropping to TCP.

 

Roni

--_000_6E58094ECC8D8344914996DAD28F1CCD836EFADGGEMM506MBXchina_-- From nobody Tue Nov 14 19: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 A5B9D1275FD for ; Tue, 14 Nov 2017 19:26:34 -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, MIME_QP_LONG_LINE=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 obrK9qjW5-UJ for ; Tue, 14 Nov 2017 19:26:33 -0800 (PST) Received: from mail-oi0-x244.google.com (mail-oi0-x244.google.com [IPv6:2607:f8b0:4003:c06::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 3F1481275AB for ; Tue, 14 Nov 2017 19:26:33 -0800 (PST) Received: by mail-oi0-x244.google.com with SMTP id r190so6128873oie.6 for ; Tue, 14 Nov 2017 19:26:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:date:subject:message-id :to; bh=OKFRgHF7S/43/DbF7W7MS0UvFLY990KlnSDjMNKaegU=; b=QBHeoLnYa5lrr1lbEx7nZCUBGGV9NXfVjA1V5Llw3Sf8P3uUUT/HVfyW+FvD337rOv 8W2By+J31rva50i53a6wDioGDboJZ4qvPgdLirSVWceygPdBK1REuZqmxYjiTdI+4Mxo VisIHb7axUVRwxOb6Uahn5iXNzjx7JSdQNtEILtyQbEOSZtZRMo9vTbWoQQXc38k+gtO ue5wSjy8kE1z7T91t6N0riR9UeiTISOOkJU4PFXpL2CVpDSrnmmjnaj3W0LSwIcSROEq yTk/CfKFcM+xxYKMVSAedg6LdPEKOEf7xFuOjj1Vl4yxsXYszPVxtipcLJziQTjMXQDj ZNOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version:date :subject:message-id:to; bh=OKFRgHF7S/43/DbF7W7MS0UvFLY990KlnSDjMNKaegU=; b=PZfE3kBVQ4rQwd7MyfVKWXcMmh7AEDRd3S3CSTxVhjykMOtqhJXDyEVyYJSJ/+Y1yH T591+jizdVC29SrOM1v2Ak2xC/HGuSvxW7um0LIRxAJYoqEUTdSdlP7sunWT55U7Q40f WR5Q+MktWE8PXaE9DytiLQNgM1RjUFBpZ2RVUxWVMeEM9mB7SVCY8NiXzmeivFIenNWp Aw8DwIQfuT6gfdTTpkE4Adsve9Rcqzspz5PRw2vAd5RJULNmSwl2Vdmsn+3bXPBDP24A HSSH3DFPTo25Eh00ODzt/9iAgRBM22t3CqXxRQl8tFuX1bWIeuUH9TJfmxCkob5QEBBb WRqA== X-Gm-Message-State: AJaThX4OxiuIKpuAje9tKQ/T42cUARZo+Zi3xrYiT0q4I4iaQeHeIgIA S67rqopSslZ6Ny2jw4lXSGH172HH X-Google-Smtp-Source: AGs4zMYl9aH7+bwNDL76EblMEPiPJmt6JRJVPtspriiYw7qVvhfSWcWU8FrzZsiPcSmGyQGDI7EPBg== X-Received: by 10.202.171.20 with SMTP id u20mr5847429oie.173.1510716392264; Tue, 14 Nov 2017 19:26:32 -0800 (PST) Received: from [100.92.192.14] (54.sub-70-196-14.myvzw.com. [70.196.14.54]) by smtp.gmail.com with ESMTPSA id s101sm3530467ota.17.2017.11.14.19.26.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 19:26:31 -0800 (PST) From: Bret Jordan Content-Type: multipart/alternative; boundary=Apple-Mail-12215302-50E0-4DB0-8451-E19EFB971A3F Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (1.0) Date: Wed, 15 Nov 2017 11:26:27 +0800 Subject: ACKs in encrypted tunnel Message-Id: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> To: quic@ietf.org X-Mailer: iPhone Mail (15A432) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:26:34 -0000 --Apple-Mail-12215302-50E0-4DB0-8451-E19EFB971A3F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable So my understanding is that all ACKs and notices about lost packets, frames,= etc will be communicated inside the encrypted tunnel with QUIC. What is our plan to enable network operators to help troubleshoot network pr= oblems with QUIC?=20 When running a large network the network team / network operators are often a= sked to help identify problems when an application is not working or is slug= gish. If all information is inside the encrypted tunnel, are we just saying =E2= =80=9Cend user and application support person, you figure it out?=E2=80=9D=20= This seems like a huge problem. I mean the network does not always work fla= wlessly and it seems like we are removing all the abilities for network oper= ators to ensure any level of SLA or OLA. =20 Bret=20 Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050= --Apple-Mail-12215302-50E0-4DB0-8451-E19EFB971A3F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable So my understanding is that all ACKs and notices about lost pa= ckets, frames, etc will be communicated inside the encrypted tunnel with QUI= C.

=
= What is our plan to enable network operators to help troubleshoot network pr= oblems with QUIC? 

When running a large network the network team / n= etwork operators are often asked to help identify problems when an applicati= on is not working or is sluggish. If all information is inside the encrypted= tunnel, are we just saying =E2=80=9Cend user and application support person= , you figure it out?=E2=80=9D 

This seems like a huge problem.  = ;I mean the network does not always work flawlessly and it seems like we are= removing all the abilities for network operators to ensure any level of SLA= or OLA.  

Bret 

= Sent from my Commo= dore 128D

PGP Fingerprin= t: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050
= --Apple-Mail-12215302-50E0-4DB0-8451-E19EFB971A3F-- From nobody Tue Nov 14 19:31: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 1E3EC126C22 for ; Tue, 14 Nov 2017 19:31:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 SJ4BDX9QG8xg for ; Tue, 14 Nov 2017 19:31:21 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6BD3E126B72 for ; Tue, 14 Nov 2017 19:31:21 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D0DA7F86D2D7E for ; Wed, 15 Nov 2017 03:31:18 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 03:31:20 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 11:31:13 +0800 From: Roni Even To: Bret Jordan , "quic@ietf.org" Subject: RE: ACKs in encrypted tunnel Thread-Topic: ACKs in encrypted tunnel Thread-Index: AQHTXcGSIYXZuC/d5EakK+LMHgg9a6MUyKgw Date: Wed, 15 Nov 2017 03:31:12 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> References: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> In-Reply-To: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.42.100] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD836F41DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:31:23 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD836F41DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpUaGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUgc3BpbiBiaXQgdGhhdCB3YXMgcHJlc2VudGVk IHllc3RlcmRheQ0KUm9uaQ0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgQnJldCBKb3JkYW4NClNlbnQ6INeZ15XXnSDXkyAxNSDXoNeV15HX nteR16ggMjAxNyAwNToyNg0KVG86IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IEFDS3MgaW4gZW5j cnlwdGVkIHR1bm5lbA0KDQpTbyBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYWxsIEFDS3MgYW5k IG5vdGljZXMgYWJvdXQgbG9zdCBwYWNrZXRzLCBmcmFtZXMsIGV0YyB3aWxsIGJlIGNvbW11bmlj YXRlZCBpbnNpZGUgdGhlIGVuY3J5cHRlZCB0dW5uZWwgd2l0aCBRVUlDLg0KDQoNCldoYXQgaXMg b3VyIHBsYW4gdG8gZW5hYmxlIG5ldHdvcmsgb3BlcmF0b3JzIHRvIGhlbHAgdHJvdWJsZXNob290 IG5ldHdvcmsgcHJvYmxlbXMgd2l0aCBRVUlDPw0KDQoNCldoZW4gcnVubmluZyBhIGxhcmdlIG5l dHdvcmsgdGhlIG5ldHdvcmsgdGVhbSAvIG5ldHdvcmsgb3BlcmF0b3JzIGFyZSBvZnRlbiBhc2tl ZCB0byBoZWxwIGlkZW50aWZ5IHByb2JsZW1zIHdoZW4gYW4gYXBwbGljYXRpb24gaXMgbm90IHdv cmtpbmcgb3IgaXMgc2x1Z2dpc2guIElmIGFsbCBpbmZvcm1hdGlvbiBpcyBpbnNpZGUgdGhlIGVu Y3J5cHRlZCB0dW5uZWwsIGFyZSB3ZSBqdXN0IHNheWluZyDigJxlbmQgdXNlciBhbmQgYXBwbGlj YXRpb24gc3VwcG9ydCBwZXJzb24sIHlvdSBmaWd1cmUgaXQgb3V0P+KAnQ0KDQoNClRoaXMgc2Vl bXMgbGlrZSBhIGh1Z2UgcHJvYmxlbS4gIEkgbWVhbiB0aGUgbmV0d29yayBkb2VzIG5vdCBhbHdh eXMgd29yayBmbGF3bGVzc2x5IGFuZCBpdCBzZWVtcyBsaWtlIHdlIGFyZSByZW1vdmluZyBhbGwg dGhlIGFiaWxpdGllcyBmb3IgbmV0d29yayBvcGVyYXRvcnMgdG8gZW5zdXJlIGFueSBsZXZlbCBv ZiBTTEEgb3IgT0xBLg0KDQoNCkJyZXQNCg0KU2VudCBmcm9tIG15IENvbW1vZG9yZSAxMjhEDQoN Cg0KUEdQIEZpbmdlcnByaW50OiA2M0I0IEZDNTMgNjgwQSA2QjdEIDE0NDcgIEYyQzAgNzRGOCBB Q0FFIDc0MTUgMDA1MDx0ZWw6NzQxNSUyMDAwNTA+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD836F41DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3 Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5UaGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUgc3BpbiBiaXQgdGhhdCB3YXMgcHJlc2Vu dGVkIHllc3RlcmRheTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb25pPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzow Y20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtU YWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFFVSUMgW21haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkJyZXQgSm9yZGFuPGJyPg0KPGI+ U2VudDo8L2I+IDxzcGFuIGxhbmc9IkhFIiBkaXI9IlJUTCI+15nXldedJm5ic3A715MgMTUg16DX ldeR157XkdeoIDIwMTcgMDU6MjY8L3NwYW4+PGJyPg0KPGI+VG86PC9iPiBxdWljQGlldGYub3Jn PGJyPg0KPGI+U3ViamVjdDo8L2I+IEFDS3MgaW4gZW5jcnlwdGVkIHR1bm5lbDxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIG15IHVuZGVyc3RhbmRpbmcg aXMgdGhhdCBhbGwgQUNLcyBhbmQgbm90aWNlcyBhYm91dCBsb3N0IHBhY2tldHMsIGZyYW1lcywg ZXRjIHdpbGwgYmUgY29tbXVuaWNhdGVkIGluc2lkZSB0aGUgZW5jcnlwdGVkIHR1bm5lbCB3aXRo IFFVSUMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K PGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5XaGF0IGlzIG91ciBwbGFuIHRvIGVuYWJsZSBuZXR3b3JrIG9wZXJhdG9ycyB0byBoZWxwIHRy b3VibGVzaG9vdCBuZXR3b3JrIHByb2JsZW1zIHdpdGggUVVJQz8mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hlbiBydW5u aW5nIGEgbGFyZ2UgbmV0d29yayB0aGUgbmV0d29yayB0ZWFtIC8gbmV0d29yayBvcGVyYXRvcnMg YXJlIG9mdGVuIGFza2VkIHRvIGhlbHAgaWRlbnRpZnkgcHJvYmxlbXMgd2hlbiBhbiBhcHBsaWNh dGlvbiBpcyBub3Qgd29ya2luZyBvciBpcyBzbHVnZ2lzaC4gSWYgYWxsIGluZm9ybWF0aW9uIGlz IGluc2lkZSB0aGUgZW5jcnlwdGVkIHR1bm5lbCwgYXJlIHdlIGp1c3Qgc2F5aW5nIOKAnGVuZCB1 c2VyDQogYW5kIGFwcGxpY2F0aW9uIHN1cHBvcnQgcGVyc29uLCB5b3UgZmlndXJlIGl0IG91dD/i gJ0mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+VGhpcyBzZWVtcyBsaWtlIGEgaHVnZSBwcm9ibGVtLiAmbmJzcDtJIG1lYW4g dGhlIG5ldHdvcmsgZG9lcyBub3QgYWx3YXlzIHdvcmsgZmxhd2xlc3NseSBhbmQgaXQgc2VlbXMg bGlrZSB3ZSBhcmUgcmVtb3ZpbmcgYWxsIHRoZSBhYmlsaXRpZXMgZm9yIG5ldHdvcmsgb3BlcmF0 b3JzIHRvIGVuc3VyZSBhbnkgbGV2ZWwgb2YgU0xBIG9yIE9MQS4gJm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJyZXQmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2VudCBmcm9tIG15IENvbW1vZG9yZSAxMjhEPG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QR1AgRmluZ2VycHJpbnQ6Jm5ic3A7NjNC NCBGQzUzIDY4MEEgNkI3RCAxNDQ3ICZuYnNwO0YyQzAgNzRGOCBBQ0FFJm5ic3A7PGEgaHJlZj0i dGVsOjc0MTUlMjAwMDUwIj43NDE1IDAwNTA8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6E58094ECC8D8344914996DAD28F1CCD836F41DGGEMM506MBXchina_-- From nobody Tue Nov 14 19:35: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 4FBAB1286CA for ; Tue, 14 Nov 2017 19:35:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=evequefou.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 5MgnF9FObb84 for ; Tue, 14 Nov 2017 19:35:30 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0101.outbound.protection.outlook.com [104.47.33.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9B70126CE8 for ; Tue, 14 Nov 2017 19:35:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DgpMMRyEk2vQlxtSC3gQI2oycpVi3bbJnRdZDLBhbhs=; b=KaD4iSnHbP4YiFDPc83KU/Izg6XoZcsLiJMBGBcDI5U1P5z8Ov+SxKNyyKGFENJxHraffKAuiqwJHoH2GUwP9PzcEtXh6AVFOyqWUTyGAcw1Lk6d+WHu5uEgbSHxdh6nqH639072pqWVpu1yfn9xq9/I9qHeqjj+75vEX8qe+2s= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2431.namprd08.prod.outlook.com (10.169.203.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Wed, 15 Nov 2017 03:35:27 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0239.005; Wed, 15 Nov 2017 03:35:27 +0000 From: Mike Bishop To: Roni Even , QUIC WG Subject: RE: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQ Date: Wed, 15 Nov 2017 03:35:27 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2001:67c:370:1998:d598:cf33:ce08:619a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2431; 6:Z1rqPwcKytrilMejnhMQTzOFYv5gs13c8+9jUJE8++Qxfbbqd6McBX4eH4sdHfh7q93P7lCAusfuQASeklQZCLm6h9G1hWheqykY6OL94RLmPIr1ItVeY46C7RRg78PD+V9ZnlZbvjup0Btm7xgHA8gVH+1uHp8mPpqD8w25KLAlaszga9j1eFf5AS6L1d7ScSGtTkVZzdBNkg5y5KP9DyzHX2SK3DOpBFV+9F5TtmejZ94x6aLB7lw24NhY5ruE07/FcXpGWuIsXROVZlBJH1EyC+df+yNEgNO6r8WberbJaa4bD6CxqgtNfjCMTRJIqPuvP6pklfhUBrEXlZnN/cnyQz0dAjHOdrgCw6jZkN8=; 5:uK7ZQkOQB8iiejGqSj3k09LmxL9p1EaLZyD76kq64wjnxwqySOh1uBe8khvmUzedRBiaZMXgGohUZnHSh8AE6vLgsQHPgI1s+9XPC0uQRTxCbn+8+pd376sp+VVRRT/mL3we3YgNy5xUgcHQZzSM6+PPtP6rk62NK1aulvffdAY=; 24:3nwHFy3FniDbMWSDez08UZy2eUpEb2Et6446VaxpqUGP2pF8+OZa4CsbOq8VTJZ7eke8+ODpJK6Oyr1x/u2aj+nP2Ck0S1bSD2Nbzdg8lHY=; 7:+dyRHlslkAp+4gd403a9vFWJqq7fr1h1QhNQMqv4Mio+kiOit3b0YN89yhTeRzV8miUZsImj9EhiPqESUYPDySxBn8TS4PDMyn1HRY1xvKJN1l068YYvQ7aC23Kk3yo1wXqXd9vkCuKi6ANDsM9yrA1dm6CEg6Ws0mp9Aclo8Cm5aCYf+5UXMivqjqjHaZAOjRuBK8V4sRfp+tUTW4ibRpxcjtnaehFBMvCtqpkSF+KF87qy3SnphoIPtiDJulJk x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 30520d58-0a26-4450-be1b-08d52bd9ea0c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603199); SRVR:MWHPR08MB2431; x-ms-traffictypediagnostic: MWHPR08MB2431: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3231022)(6041248)(2016111802025)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2431; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2431; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39830400002)(346002)(376002)(199003)(189002)(6116002)(68736007)(19609705001)(3480700004)(33656002)(5660300001)(55016002)(6506006)(7116003)(189998001)(6246003)(478600001)(77096006)(53936002)(6436002)(6306002)(54896002)(2900100001)(9686003)(14454004)(86362001)(102836003)(74316002)(81156014)(8936002)(81166006)(790700001)(99286004)(8676002)(2906002)(110136005)(76176999)(54356999)(2950100002)(50986999)(53546010)(25786009)(3660700001)(229853002)(316002)(221733001)(74482002)(106356001)(97736004)(105586002)(7696004)(101416001)(3280700002)(7736002)(111123002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2431; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB243212D50C3C7A8CB1585F21DA290MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 30520d58-0a26-4450-be1b-08d52bd9ea0c X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 03:35:27.5050 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2431 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:35:32 -0000 --_000_MWHPR08MB243212D50C3C7A8CB1585F21DA290MWHPR08MB2432namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That may well be the case, but it's not the QUIC stack's choice to make. T= he application could choose to open a new connection, but that remains outs= ide the scope of the transport and the mapping to it which we're defining. For HTTP, this is fairly straightforward - it could stop issuing new flow c= ontrol credit, let currently-in-transit data arrive and any losses recovere= d, and open a TCP connection to issue a range request starting at whatever = data offset it hasn't seen. But that's still a property of an HTTP managem= ent above the HTTP/QUIC mapping. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, November 15, 2017 11:25 AM To: QUIC WG Subject: connection migration Hi, When moving from cell to wifi the reason may be due to cost (money or quota= ). In this case the user (client) may want to move to wifi even if it will= mean dropping to TCP. Roni --_000_MWHPR08MB243212D50C3C7A8CB1585F21DA290MWHPR08MB2432namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That may well be the case, but it’s not the QU= IC stack’s choice to make.  The application could choose to open= a new connection, but that remains outside the scope of the transport and = the mapping to it which we’re defining.

 

For HTTP, this is fairly straightforward – it = could stop issuing new flow control credit, let currently-in-transit data a= rrive and any losses recovered, and open a TCP connection to issue a range = request starting at whatever data offset it hasn’t seen.  But that’s still a property of an HTTP m= anagement above the HTTP/QUIC mapping.

 

From: QUIC [mailto:quic-bounces@ietf.org] = On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <quic@ietf.org>
Subject: connection migration

 

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the  user (client) may want to = move to wifi even if it will mean dropping to TCP.

 

Roni

--_000_MWHPR08MB243212D50C3C7A8CB1585F21DA290MWHPR08MB2432namp_-- From nobody Tue Nov 14 19:37: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 38172128CFF for ; Tue, 14 Nov 2017 19:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 4tZ8iDnvpyTJ for ; Tue, 14 Nov 2017 19:37:39 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0129.outbound.protection.outlook.com [104.47.41.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB264126B72 for ; Tue, 14 Nov 2017 19:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=R7KbaKEi+DvhZCnPmB0S+HCYlanviSm7gitChEmCGvA=; b=T06eMi7doMCQIInwqptqljZm/H0pxHMcwKzAkmKmUhccpw6BQ/DZtwhCeqPK6yLcB6HkK4ylIfmigTXK88O8AtAdqFy4D0vsVqRkSjZy03uHpA+Snlgm/UEXLHxjc7dXdG5Di5KTP6Gg+WYSbu/jjUGbPK+12wgwfeenwwPEMOw= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2431.namprd08.prod.outlook.com (10.169.203.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Wed, 15 Nov 2017 03:37:37 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0239.005; Wed, 15 Nov 2017 03:37:37 +0000 From: Mike Bishop To: Roni Even , Bret Jordan , "quic@ietf.org" Subject: RE: ACKs in encrypted tunnel Thread-Topic: ACKs in encrypted tunnel Thread-Index: AQHTXcGN/P1o2Nv99U6OtVBH7RML2qMUyNsAgAABT+A= Date: Wed, 15 Nov 2017 03:37:37 +0000 Message-ID: References: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2001:67c:370:1998:d598:cf33:ce08:619a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2431; 6:KxqCChmq95KpVdj0Epv7iwpr7ZuRi3Mq2GHZ3BpiqMWWxnXB7YBxuu6C1JH/f9zz7z3nm53d1aCpFRI5oT7A9NNUNgk5R7cMRn4sLWe5FiffQMH/lexXrO7b/HZGmIoWuYV3oE6pQ5ZZ2uykIwqZdqV9WCQIFAO7K3voJUii+u+Vx0kD1ghEeKsJY37F1d1yzjTE/J49GfErKCj3EYKWrIXnnSl9uLbrz7hY5xSs6YyGB46Go1O0fSRToBLeF8DfEtdK9lGvAwet7l0nHGvPKtI/ZJ73yDNvt4ZOYD0fYB9tBgX0zeChh9eZOpIwd2tLiYaQqjQMdhD7o35gl9S5JjsFidvHBjBXa1GKc5Qtp8Y=; 5:wNRpnS34Q9G7BniVdKDckv9J2sUQ1hzqYeapIlQLE1ajoTA2xmP1s8Xykq+aB6EFDLOlDnr4nQH+1Qp2QHCiAdHaxVN8H3D+8OFpkP/g1N50pDfCuuHM3bktKFo1Nm8CcDptgCHSz7ScVN0mQYWDwLeJfgCmqvvHJAtYHy8nGoc=; 24:/egzaNAXjI00glHRpwTu0e0qQ74MLnDkNbP6W+NzQOCBR5fYgjI8bYIxXk+B3dYH34CHdsV3Fqwur4DUidKTr+S62/fDmaxuJCoDcLRn7Bg=; 7:GFCW3DBYZwdBgXmnTgsxRSa7zIKBuPSIQJ6ndFibSmryKSSZeybM3nckwlxLxPN8PkcM3Fidw4SNW2ePui4J7aJv8Ycl1rRbkI/ARqNbEh/eA5r8t/O0SRj9SaXQ+H8WSYM4EfpKN/HV25cCODvsMjG41ihPLpiaZxu2LH2xTUWEKlJL0xEQXALKDn7lohhFgze+wBMhaRP49mV8nG0LvHVhdDZQbiNmNUvlp85705QtkFwuAnphuXMpJ52RhOet x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b55c2616-dc36-4a8f-fa50-08d52bda376b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603199); SRVR:MWHPR08MB2431; x-ms-traffictypediagnostic: MWHPR08MB2431: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(227612066756510)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3231022)(6041248)(2016111802025)(20161123562025)(20161123560025)(20161123564025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2431; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2431; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400002)(346002)(376002)(199003)(189002)(6116002)(68736007)(19609705001)(3480700004)(33656002)(5660300001)(55016002)(6506006)(236005)(189998001)(6246003)(478600001)(77096006)(53936002)(39060400002)(6436002)(6306002)(54896002)(2900100001)(9686003)(14454004)(86362001)(102836003)(74316002)(81156014)(8936002)(81166006)(790700001)(99286004)(8676002)(2906002)(110136005)(76176999)(54356999)(2950100002)(50986999)(53546010)(25786009)(2501003)(3660700001)(229853002)(316002)(74482002)(106356001)(97736004)(105586002)(7696004)(101416001)(3280700002)(7736002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2431; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432A5A86D93610F9EC96894DA290MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: b55c2616-dc36-4a8f-fa50-08d52bda376b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 03:37:37.3450 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2431 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:37:41 -0000 --_000_MWHPR08MB2432A5A86D93610F9EC96894DA290MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWxzbywgaWYgdGhlIGVuZCBwb2ludChzKSBjb25zZW50IHRvIGdpdmUgeW91IHRoZSBrZXlzLCBu b3RoaW5nIHN0b3BzIHlvdSBmcm9tIGluc3BlY3RpbmcgYSBwYXJ0aWN1bGFyIGZsb3cuICBJdCBy ZXF1aXJlcyB0aGUgYWN0aXZlIGNvb3BlcmF0aW9uIG9mIGF0IGxlYXN0IG9uZSBwYXJ0eSB0byB0 aGUgY29ubmVjdGlvbiwgYnV0IGlmIHNvbWVvbmXigJlzIGNhbGxpbmcgeW91IGZvciBoZWxwLCB0 aGF04oCZcyBwcmVzdW1hYmx5IHRoZSBjYXNlLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgUm9uaSBFdmVuDQpTZW50OiBXZWRuZXNkYXks IE5vdmVtYmVyIDE1LCAyMDE3IDExOjMxIEFNDQpUbzogQnJldCBKb3JkYW4gPGpvcmRhbi5pZXRm QGdtYWlsLmNvbT47IHF1aWNAaWV0Zi5vcmcNClN1YmplY3Q6IFJFOiBBQ0tzIGluIGVuY3J5cHRl ZCB0dW5uZWwNCg0KSGksDQpUaGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUgc3BpbiBiaXQgdGhhdCB3 YXMgcHJlc2VudGVkIHllc3RlcmRheQ0KUm9uaQ0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQnJldCBKb3JkYW4NClNlbnQ6INeZ15XXnSDX kyAxNSDXoNeV15HXnteR16ggMjAxNyAwNToyNg0KVG86IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1 aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBBQ0tzIGluIGVuY3J5cHRlZCB0dW5uZWwNCg0KU28gbXkg dW5kZXJzdGFuZGluZyBpcyB0aGF0IGFsbCBBQ0tzIGFuZCBub3RpY2VzIGFib3V0IGxvc3QgcGFj a2V0cywgZnJhbWVzLCBldGMgd2lsbCBiZSBjb21tdW5pY2F0ZWQgaW5zaWRlIHRoZSBlbmNyeXB0 ZWQgdHVubmVsIHdpdGggUVVJQy4NCg0KV2hhdCBpcyBvdXIgcGxhbiB0byBlbmFibGUgbmV0d29y ayBvcGVyYXRvcnMgdG8gaGVscCB0cm91Ymxlc2hvb3QgbmV0d29yayBwcm9ibGVtcyB3aXRoIFFV SUM/DQoNCldoZW4gcnVubmluZyBhIGxhcmdlIG5ldHdvcmsgdGhlIG5ldHdvcmsgdGVhbSAvIG5l dHdvcmsgb3BlcmF0b3JzIGFyZSBvZnRlbiBhc2tlZCB0byBoZWxwIGlkZW50aWZ5IHByb2JsZW1z IHdoZW4gYW4gYXBwbGljYXRpb24gaXMgbm90IHdvcmtpbmcgb3IgaXMgc2x1Z2dpc2guIElmIGFs bCBpbmZvcm1hdGlvbiBpcyBpbnNpZGUgdGhlIGVuY3J5cHRlZCB0dW5uZWwsIGFyZSB3ZSBqdXN0 IHNheWluZyDigJxlbmQgdXNlciBhbmQgYXBwbGljYXRpb24gc3VwcG9ydCBwZXJzb24sIHlvdSBm aWd1cmUgaXQgb3V0P+KAnQ0KDQpUaGlzIHNlZW1zIGxpa2UgYSBodWdlIHByb2JsZW0uICBJIG1l YW4gdGhlIG5ldHdvcmsgZG9lcyBub3QgYWx3YXlzIHdvcmsgZmxhd2xlc3NseSBhbmQgaXQgc2Vl bXMgbGlrZSB3ZSBhcmUgcmVtb3ZpbmcgYWxsIHRoZSBhYmlsaXRpZXMgZm9yIG5ldHdvcmsgb3Bl cmF0b3JzIHRvIGVuc3VyZSBhbnkgbGV2ZWwgb2YgU0xBIG9yIE9MQS4NCg0KQnJldA0KDQpTZW50 IGZyb20gbXkgQ29tbW9kb3JlIDEyOEQNCg0KUEdQIEZpbmdlcnByaW50OiA2M0I0IEZDNTMgNjgw QSA2QjdEIDE0NDcgIEYyQzAgNzRGOCBBQ0FFIDc0MTUgMDA1MDx0ZWw6NzQxNSUyMDAwNTA+DQo= --_000_MWHPR08MB2432A5A86D93610F9EC96894DA290MWHPR08MB2432namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5BbHNvLCBpZiB0aGUgZW5kIHBvaW50KHMpIGNvbnNlbnQgdG8gZ2l2ZSB5b3UgdGhlIGtleXMs IG5vdGhpbmcgc3RvcHMgeW91IGZyb20gaW5zcGVjdGluZyBhIHBhcnRpY3VsYXIgZmxvdy4mbmJz cDsgSXQgcmVxdWlyZXMgdGhlIGFjdGl2ZSBjb29wZXJhdGlvbiBvZiBhdCBsZWFzdCBvbmUgcGFy dHkgdG8gdGhlDQogY29ubmVjdGlvbiwgYnV0IGlmIHNvbWVvbmXigJlzIGNhbGxpbmcgeW91IGZv ciBoZWxwLCB0aGF04oCZcyBwcmVzdW1hYmx5IHRoZSBjYXNlLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIG5hbWU9Il9NYWlsRW5kQ29tcG9zZSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPHNwYW4gc3R5bGU9 Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxkaXY+DQo8ZGl2IHN0eWxl PSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBw dCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBRVUlDIFttYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5Sb25pIEV2ZW48YnI+DQo8Yj5TZW50 OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyAxMTozMSBBTTxicj4NCjxiPlRvOjwv Yj4gQnJldCBKb3JkYW4gJmx0O2pvcmRhbi5pZXRmQGdtYWlsLmNvbSZndDs7IHF1aWNAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEFDS3MgaW4gZW5jcnlwdGVkIHR1bm5lbDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBkaXNjdXNzZWQg aW4gdGhlIHNwaW4gYml0IHRoYXQgd2FzIHByZXNlbnRlZCB5ZXN0ZXJkYXk8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+Um9uaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LHNhbnMtc2VyaWYiPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+QnJldCBKb3JkYW48YnI+DQo8Yj5TZW50OjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9IkhF IiBkaXI9IlJUTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPteZ15XXnSZuYnNwO9eTIDE1INeg15XXkdee15HXqCAyMDE3 IDA1OjI2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6PC9i PiBBQ0tzIGluIGVuY3J5cHRlZCB0dW5uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5TbyBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYWxsIEFDS3MgYW5k IG5vdGljZXMgYWJvdXQgbG9zdCBwYWNrZXRzLCBmcmFtZXMsIGV0YyB3aWxsIGJlIGNvbW11bmlj YXRlZCBpbnNpZGUgdGhlIGVuY3J5cHRlZCB0dW5uZWwgd2l0aCBRVUlDLjxvOnA+PC9vOnA+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5XaGF0IGlzIG91ciBwbGFuIHRvIGVuYWJsZSBuZXR3b3JrIG9wZXJhdG9ycyB0byBoZWxw IHRyb3VibGVzaG9vdCBuZXR3b3JrIHByb2JsZW1zIHdpdGggUVVJQz8mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5XaGVuIHJ1bm5pbmcgYSBsYXJnZSBuZXR3b3JrIHRoZSBuZXR3b3Jr IHRlYW0gLyBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgb2Z0ZW4gYXNrZWQgdG8gaGVscCBpZGVudGlm eSBwcm9ibGVtcyB3aGVuIGFuIGFwcGxpY2F0aW9uIGlzIG5vdCB3b3JraW5nIG9yIGlzIHNsdWdn aXNoLiBJZiBhbGwgaW5mb3JtYXRpb24gaXMgaW5zaWRlIHRoZSBlbmNyeXB0ZWQgdHVubmVsLCBh cmUgd2UganVzdCBzYXlpbmcg4oCcZW5kIHVzZXINCiBhbmQgYXBwbGljYXRpb24gc3VwcG9ydCBw ZXJzb24sIHlvdSBmaWd1cmUgaXQgb3V0P+KAnSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlRoaXMgc2VlbXMgbGlrZSBhIGh1Z2UgcHJvYmxlbS4gJm5ic3A7SSBtZWFuIHRoZSBuZXR3 b3JrIGRvZXMgbm90IGFsd2F5cyB3b3JrIGZsYXdsZXNzbHkgYW5kIGl0IHNlZW1zIGxpa2Ugd2Ug YXJlIHJlbW92aW5nIGFsbCB0aGUgYWJpbGl0aWVzIGZvciBuZXR3b3JrIG9wZXJhdG9ycyB0byBl bnN1cmUgYW55IGxldmVsIG9mIFNMQSBvciBPTEEuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkJyZXQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIG15IENvbW1vZG9yZSAxMjhEPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0 b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlBHUCBGaW5nZXJwcmludDombmJzcDs2M0I0IEZDNTMgNjgwQSA2QjdEIDE0 NDcgJm5ic3A7RjJDMCA3NEY4IEFDQUUmbmJzcDs8YSBocmVmPSJ0ZWw6NzQxNSUyMDAwNTAiPjc0 MTUgMDA1MDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR08MB2432A5A86D93610F9EC96894DA290MWHPR08MB2432namp_-- From nobody Tue Nov 14 19:41: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 B0AF512878D for ; Tue, 14 Nov 2017 19:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=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 5SX99YaDpOkb for ; Tue, 14 Nov 2017 19:41:03 -0800 (PST) Received: from mail-ot0-x241.google.com (mail-ot0-x241.google.com [IPv6:2607:f8b0:4003:c0f::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06459126B72 for ; Tue, 14 Nov 2017 19:41:03 -0800 (PST) Received: by mail-ot0-x241.google.com with SMTP id u10so11192972otc.12 for ; Tue, 14 Nov 2017 19:41:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PBgigoQUFMvE/u8qgvmWHw4sPvLTnuNKaW1TvsnPHJk=; b=cLt0cBOEshOktX0zPe15aiha1uHy+njfY1VC5+HYupD/zx930DuFThlWJA3fl8zcrE 8f+hglxaYG4O2AMn27E4Xy5rfFJpY5+XO4lBYQwR/fi5iA9nPzDIThUf2rFlTI24xZFF 7NIpLTH5d06tT4vGGoZ8rNAtkBJkqwxMMXj8pI3msM0zAbRpVVTgbR+AMENjLNrjQ5Yv JaElel+TlolZFOJ/hzm+C0152AJbejHwujMOqDA/zuO2H5NrVylKk+DNFSEApYwjl7xD 9roKJ7Bzau0ESSiI2G0vp56o5CbytBPIhF+u2HH68cEY75mTDRCHtPpQB1qNApzBUmmQ Qc+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:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=PBgigoQUFMvE/u8qgvmWHw4sPvLTnuNKaW1TvsnPHJk=; b=eEWEgQ8kXPH8TsaML0Yl0s0ypvlAPFX6GYDpUEPc9QaCymMLJ4d+nNl9HfVSSxgK+8 yvhhVIwVE4uXaJqNYN5O1JpdyJy56F4AOZ0+wor2ZashFYul0iYwSaHSgt0E/ufOhrhO ayCG7AauiuEHcL96sdtU0eFhzGFUgUtHaEFXopYJxqroPxvoQDMsdpPIkiCyVE3catYI wW2KFESRxQzrOt2HCzQWKcV9a6RwyV2ocRQpldcf/lsJ87LhkYxWp4XhPCzCMLN4A8IN obs7RvqII8BKR5o1w3QlSYRsXtmcf6cOKkppSTBIfEVDmHUCseLpUTBpSh1gfSoudJ6u ToBw== X-Gm-Message-State: AJaThX61P7e3KvnuPITtxC7ZjQMMu5mb72I3tKHmdBvVw2+nu+a45KHR ZgzgSfxdnqi2R2UDzNOrV1qmH4Vr X-Google-Smtp-Source: AGs4zMasFxCtVYDS+yp+kHVm84Hb9qPx2pK3B2/bifg9EcIQXxFy0ppalMUJeOAGiUoqthIBm9+I/Q== X-Received: by 10.157.27.2 with SMTP id l2mr8593407otl.300.1510717262499; Tue, 14 Nov 2017 19:41:02 -0800 (PST) Received: from [100.92.192.14] (54.sub-70-196-14.myvzw.com. [70.196.14.54]) by smtp.gmail.com with ESMTPSA id c135sm877266oih.33.2017.11.14.19.41.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 19:41:01 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-67C68EC9-4CED-4534-8F09-58F437CB85C9 Mime-Version: 1.0 (1.0) Subject: Re: ACKs in encrypted tunnel From: Bret Jordan X-Mailer: iPhone Mail (15A432) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> Date: Wed, 15 Nov 2017 11:40:56 +0800 Cc: "quic@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <34291EB8-82B1-47E5-A9AE-449969298927@gmail.com> References: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> To: Roni Even Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:41:05 -0000 --Apple-Mail-67C68EC9-4CED-4534-8F09-58F437CB85C9 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is the spin bit going to be enough? I am not sure it is.=20 Bret=20 Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > On Nov 15, 2017, at 11:31 AM, Roni Even wrote: >=20 > Hi, > This is discussed in the spin bit that was presented yesterday > Roni > =20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Bret Jordan > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 20= 17 05:26 > To: quic@ietf.org > Subject: ACKs in encrypted tunnel > =20 > So my understanding is that all ACKs and notices about lost packets, frame= s, etc will be communicated inside the encrypted tunnel with QUIC. >=20 >=20 > What is our plan to enable network operators to help troubleshoot network p= roblems with QUIC?=20 >=20 >=20 > When running a large network the network team / network operators are ofte= n asked to help identify problems when an application is not working or is s= luggish. If all information is inside the encrypted tunnel, are we just sayi= ng =E2=80=9Cend user and application support person, you figure it out?=E2=80= =9D=20 >=20 >=20 > This seems like a huge problem. I mean the network does not always work f= lawlessly and it seems like we are removing all the abilities for network op= erators to ensure any level of SLA or OLA. =20 >=20 >=20 > Bret=20 > =20 > Sent from my Commodore 128D >=20 >=20 > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 --Apple-Mail-67C68EC9-4CED-4534-8F09-58F437CB85C9 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Is the spin bit going to be enough? I am no= t sure it is. 

Bret 

Sent f= rom my Commodore 128D

PGP = Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Nov 15, 2017, at 11:31 AM, Roni E= ven <roni.even@huawei.com>= wrote:

Hi,

This is discussed in the sp= in bit that was presented yesterday

Roni

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Bret Jordan
Sent: =D7=99=D7=95=D7=9D =D7=93 15= =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 05:26
To: quic@ietf.org
Subject: ACKs in encrypted tunnel

 

So my understanding is that all ACKs and notices abou= t lost packets, frames, etc will be communicated inside the encrypted tunnel= with QUIC.



What is our plan to enable network operators to help t= roubleshoot network problems with QUIC? 



When running a large network the network team / netwo= rk operators are often asked to help identify problems when an application i= s not working or is sluggish. If all information is inside the encrypted tun= nel, are we just saying =E2=80=9Cend user and application support person, you figure it out?=E2=80=9D 



This seems like a huge problem.  I mean the netw= ork does not always work flawlessly and it seems like we are removing all th= e abilities for network operators to ensure any level of SLA or OLA.  <= o:p>



Bret 

 

Sent from my Commodore 128D



PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  = F2C0 74F8 ACAE 7415 0050

=
= --Apple-Mail-67C68EC9-4CED-4534-8F09-58F437CB85C9-- From nobody Tue Nov 14 19:41: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 C7191126CBF for ; Tue, 14 Nov 2017 19:41:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 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, MIME_QP_LONG_LINE=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 8hSBUiAlf0FB for ; Tue, 14 Nov 2017 19:41:48 -0800 (PST) Received: from mail-oi0-x241.google.com (mail-oi0-x241.google.com [IPv6:2607:f8b0:4003:c06::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 085CC126B72 for ; Tue, 14 Nov 2017 19:41:48 -0800 (PST) Received: by mail-oi0-x241.google.com with SMTP id n16so6132667oig.3 for ; Tue, 14 Nov 2017 19:41:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0sD9NvaWylVfpvIQsRUqNsDzSjD+y838+rBlOloH6Co=; b=tGpg45SupcBceP32AFAcv9hXlHf0jqTXOAEz61Z9UdmtdxsO9gpaB14bPUVJ29SPMK u+xf+3Dl4ap3WJ42QMfCUcoFVL8cWmenJdi42fpMQOnFp1DJSzQnr1yJe+Ycwi1VS5tA DMJDtws24skWh6nYS/ssHyTw8PAAF521H4V/Ic7eF32VBe983grJ4J7jCx3oanoXMyQy R8hl3lB/1YJMWVu6AgQTmbLCXo5lJ6p/9bYCp4waBKIFEZ+LMdrCQIUW4qKhzHiifOPG uB1/nGUie9rAzvlU0Ab9BcMI9nRjj+Sh1mUBV0wBmhybD2BK2e3HQ3I8SAQI0b3qzpvI FIww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0sD9NvaWylVfpvIQsRUqNsDzSjD+y838+rBlOloH6Co=; b=l+B559R5/f7p9Ewy0wJR8/UuE2hLsEToWGZLnp8fE3GwvG25hI54SE3em7wJMoUcGv czp41XmuuNnO0XOIGkIJyB5j8vnNj+Q91dbvirgutyGtwrQXmdZSHrJLy3wvGUXCUzPZ mxuc1RFDti5x3TtNMGYEHUo5XQgUloa5Vbda8kIB00SRV6ryzDTBnKK58Y4eTRrUXgIO CGHfJHr1b3LLF/6/dqkO+pdBSMz48fEF8OGo8o2c41ZN5q7yv2sQe/c8E5T7nGHntjUV JhA78UXKyyebu0G3kxRShGDcNHzWc6mIFg87U1Vd7OVDEDqnS1Wovvq2wSeEfYg5KYSn PaeA== X-Gm-Message-State: AJaThX7Wa0GPTOsZ+AmkipZUrccqUfidkGvYlEMxP9yflH21dAfk5CDK lKNyMO5FvlCWLYYCBPQ1V8cOYkK9 X-Google-Smtp-Source: AGs4zMbUEqZh4PemY6IUSxqH777UVmt7myofycMUX7O3zFS5JPTh+sNtMarfJTPu/8B95Zj1ha2WAw== X-Received: by 10.202.114.141 with SMTP id p135mr5009535oic.408.1510717307462; Tue, 14 Nov 2017 19:41:47 -0800 (PST) Received: from [100.92.192.14] (54.sub-70-196-14.myvzw.com. [70.196.14.54]) by smtp.gmail.com with ESMTPSA id f2sm9712998ote.52.2017.11.14.19.41.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 14 Nov 2017 19:41:46 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-5BE89292-65D2-4149-A21F-7ABFC64DCC04 Mime-Version: 1.0 (1.0) Subject: Re: ACKs in encrypted tunnel From: Bret Jordan X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Wed, 15 Nov 2017 11:41:40 +0800 Cc: Roni Even , "quic@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <0F543241-F5B6-4A55-B773-2DEFDDC8860C@gmail.com> References: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> To: Mike Bishop Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:41:50 -0000 --Apple-Mail-5BE89292-65D2-4149-A21F-7ABFC64DCC04 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am not sure that is really realistic. Bret=20 Sent from my Commodore 128D PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > On Nov 15, 2017, at 11:37 AM, Mike Bishop wrote: >=20 > Also, if the end point(s) consent to give you the keys, nothing stops you f= rom inspecting a particular flow. It requires the active cooperation of at l= east one party to the connection, but if someone=E2=80=99s calling you for h= elp, that=E2=80=99s presumably the case. > =20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even > Sent: Wednesday, November 15, 2017 11:31 AM > To: Bret Jordan ; quic@ietf.org > Subject: RE: ACKs in encrypted tunnel > =20 > Hi, > This is discussed in the spin bit that was presented yesterday > Roni > =20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Bret Jordan > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 20= 17 05:26 > To: quic@ietf.org > Subject: ACKs in encrypted tunnel > =20 > So my understanding is that all ACKs and notices about lost packets, frame= s, etc will be communicated inside the encrypted tunnel with QUIC. > =20 >=20 > What is our plan to enable network operators to help troubleshoot network p= roblems with QUIC?=20 > =20 >=20 > When running a large network the network team / network operators are ofte= n asked to help identify problems when an application is not working or is s= luggish. If all information is inside the encrypted tunnel, are we just sayi= ng =E2=80=9Cend user and application support person, you figure it out?=E2=80= =9D=20 > =20 >=20 > This seems like a huge problem. I mean the network does not always work f= lawlessly and it seems like we are removing all the abilities for network op= erators to ensure any level of SLA or OLA. =20 > =20 >=20 > Bret=20 > =20 > Sent from my Commodore 128D > =20 >=20 > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 --Apple-Mail-5BE89292-65D2-4149-A21F-7ABFC64DCC04 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable I am not sure that is really realistic.
Bret 

Sent from my Commodore 128D

PGP Fingerprint: 63= B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050

On Nov 15, 2017, at 11:37 AM, Mike Bishop <mbishop@evequefou.be> wrote:

Also, if the end point(s) consent to give you the key= s, nothing stops you from inspecting a particular flow.  It requires th= e active cooperation of at least one party to the connection, but if someone=E2=80=99s calling you for help, that=E2=80=99s p= resumably the case.

 <= /a>

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:31 AM
To: Bret Jordan <jordan.i= etf@gmail.com>; quic@ietf.org Subject: RE: ACKs in encrypted tunnel

 

Hi,

This is discussed in the spin bit that w= as presented yesterday

Roni

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Bret Jordan
Sent: =D7=99=D7=95=D7=9D =D7=93 15= =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 05:26
To: quic@ietf.org
Subject: ACKs in encrypted tunnel

 

So my understanding is that all ACKs and notices abou= t lost packets, frames, etc will be communicated inside the encrypted tunnel= with QUIC.

 

What is our plan to enable network operators to help t= roubleshoot network problems with QUIC? 

 

When running a large network the network team / netwo= rk operators are often asked to help identify problems when an application i= s not working or is sluggish. If all information is inside the encrypted tun= nel, are we just saying =E2=80=9Cend user and application support person, you figure it out?=E2=80=9D 

 

This seems like a huge problem.  I mean the netw= ork does not always work flawlessly and it seems like we are removing all th= e abilities for network operators to ensure any level of SLA or OLA.  <= o:p>

 

Bret 

 

Sent from my Commodore 128D

 

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  = F2C0 74F8 ACAE 7415 0050

=
= --Apple-Mail-5BE89292-65D2-4149-A21F-7ABFC64DCC04-- From nobody Tue Nov 14 19:46: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 68910126CBF for ; Tue, 14 Nov 2017 19:46: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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 FBNr1p5ZcrYh for ; Tue, 14 Nov 2017 19:46:05 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6088C126C22 for ; Tue, 14 Nov 2017 19:46:05 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id e19so26658963qte.8 for ; Tue, 14 Nov 2017 19:46:05 -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:content-transfer-encoding; bh=TIfwSB6ZvX8Tw6IGgnWEzcEsKSgtKaE+Cph3u+kfalg=; b=HcxUUV5+l9C48/ym25fPwR/Rypvgrk0ujVGx/ONS3Fe60okC5B3nno9MzPVaGuAb1a l2WrTpnlUG7T/khZeoRk8p7OUlgkhy9w2x5Gca3zkeQMhNyPHVWcJihyNIE8bccYoaKI vUKfvHMVAaPl2e3/rbnwnkWf4Dndt2YL7MS6U= 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=TIfwSB6ZvX8Tw6IGgnWEzcEsKSgtKaE+Cph3u+kfalg=; b=kGoPqXcNXpwfYRLfFcAIiXTsSXs+Jj9fkyxmbkhlMwqWM4n+wiAfMCJidREyEPP1xc xDr3HYUinOXIS9yHFpbVtq+AVxb1ufNHiX2KIt3GXUbHx0o0iURq8Y8KOuWgkJeO17Ep CX4HY9TcvNUBYNkP/jifA/ghyoW4Nc0p6N3XdbZ7HvZ0XO768lez33LeoPpic7ZqmGc/ oTeoGBEGDFvni4XWoIsPx7NGBR7aSrHBsdp+1jDAYCt9I/9O9Xcdv6xctOW9C2BPjbv5 N2StQGmbhbVUq7lO7CqHeqjxvhQxF8b9CsOuOtDbXdAvD7ckUZv2NvypK+SWKikDtjc+ mzbA== X-Gm-Message-State: AJaThX7P/+lQc7B1qI6H/U8Etoo4+ARcYSYTlcSQNz7v4nw6ZDS7NYnK FFT6tSRRs3gY8Fr9f5jo6dTc7Kbw0RD6pJWVRmAdhA== X-Google-Smtp-Source: AGs4zMaQZl1nF5UG9ahRdIDp+o5Es5zL4Gd2Gm6c3JThyhfHs+av7c7pk3AFfSzu0jPoY54xdzb8K1rf2dYfBRRr03U= X-Received: by 10.200.22.234 with SMTP id y39mr22605756qtk.59.1510717564339; Tue, 14 Nov 2017 19:46:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.204.17 with HTTP; Tue, 14 Nov 2017 19:46:03 -0800 (PST) X-Originating-IP: [2001:67c:370:128:9071:bb4e:1555:ddaa] In-Reply-To: <0F543241-F5B6-4A55-B773-2DEFDDC8860C@gmail.com> References: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> <0F543241-F5B6-4A55-B773-2DEFDDC8860C@gmail.com> From: Kyle Rose Date: Wed, 15 Nov 2017 11:46:03 +0800 Message-ID: Subject: Re: ACKs in encrypted tunnel To: Bret Jordan Cc: Mike Bishop , Roni Even , "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:46:07 -0000 Can you describe an example problem and debugging workflow in which publicly-visible ACKs were indispensable in helping to locate a network problem? Kyle On Wed, Nov 15, 2017 at 11:41 AM, Bret Jordan wrote= : > I am not sure that is really realistic. > > Bret > > Sent from my Commodore 128D > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > > On Nov 15, 2017, at 11:37 AM, Mike Bishop wrote: > > Also, if the end point(s) consent to give you the keys, nothing stops you > from inspecting a particular flow. It requires the active cooperation of= at > least one party to the connection, but if someone=E2=80=99s calling you f= or help, > that=E2=80=99s presumably the case. > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even > Sent: Wednesday, November 15, 2017 11:31 AM > To: Bret Jordan ; quic@ietf.org > Subject: RE: ACKs in encrypted tunnel > > > > Hi, > > This is discussed in the spin bit that was presented yesterday > > Roni > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Bret Jordan > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2= 017 05:26 > To: quic@ietf.org > Subject: ACKs in encrypted tunnel > > > > So my understanding is that all ACKs and notices about lost packets, fram= es, > etc will be communicated inside the encrypted tunnel with QUIC. > > > > What is our plan to enable network operators to help troubleshoot network > problems with QUIC? > > > > When running a large network the network team / network operators are oft= en > asked to help identify problems when an application is not working or is > sluggish. If all information is inside the encrypted tunnel, are we just > saying =E2=80=9Cend user and application support person, you figure it ou= t?=E2=80=9D > > > > This seems like a huge problem. I mean the network does not always work > flawlessly and it seems like we are removing all the abilities for networ= k > operators to ensure any level of SLA or OLA. > > > > Bret > > > > Sent from my Commodore 128D > > > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 From nobody Tue Nov 14 19: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 6A3391294C9 for ; Tue, 14 Nov 2017 19:47:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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=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 cd0XHj_Wzgtb for ; Tue, 14 Nov 2017 19:47:01 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 B2D67126C22 for ; Tue, 14 Nov 2017 19:47:01 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAF3kxnd023780; Wed, 15 Nov 2017 03:46:59 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=9BVtFphDXtk//IxTu2S2m1eUx7ZB+sANnxr5vAyv5O0=; b=NGsoNn0yGBO3B9j4cxu9aoWqECli279rJbTZYokAlcB2n+psOeoYj96JUem0K8XK1wAQ jSO5qBHEZehpQeTkDFrD4STFqCLuaxNa/NJUt8sDXtqTqK8DumVnqYAvBFklBsdIeGFr 9nEGVEA6dKZA9TvpxcSGe6NJbYbHR7X7CldIRXO/lXhHTvSXJ08oqSdZ2+v2ScpMgd/i Tfv1JDJumeKeDCyPhHFPBAxdajGWHtjnKaeWg4vYmFOwCmnSPumaXxCUpCdWFxOLFee7 qYY1PmEfb2mM5C/mBtHOS8Vpod/hqhoTNmvYkRVUhUwrI3uBEAGLjdj8pUuYZzopEifG qQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050096.ppops.net-00190b01. with ESMTP id 2e8d5vg3ah-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Nov 2017 03:46:59 +0000 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAF3jvxs014569; Tue, 14 Nov 2017 22:46:58 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2e7p3wkv4b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 14 Nov 2017 22:46:58 -0500 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.1263.5; Tue, 14 Nov 2017 22:46: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.1263.000; Tue, 14 Nov 2017 22:46:57 -0500 From: "Lubashev, Igor" To: JESUS MARIA MARTIN GARCIA , "sanjay.mishra@verizon.com" , QUIC WG Subject: RE: spin bit in QUIC Thread-Topic: spin bit in QUIC Thread-Index: AdNdInWu9OoodX6pTBa2nSIjjM2p0wABTQNQACIWFrAABPszcA== Date: Wed, 15 Nov 2017 03:46:57 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD836BC1@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.76] Content-Type: multipart/alternative; boundary="_000_c2d3578e2b804c9488c325068d623f43usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150051 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-14_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150051 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:47:05 -0000 --_000_c2d3578e2b804c9488c325068d623f43usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the operators believe that this bit will improve their networks and will= help end user experience for QUIC, I am all for it (since the privacy risk= s of this bit is practically negligible). * Igor From: JESUS MARIA MARTIN GARCIA [mailto:jesusmaria.martingarcia@telefonica.= com] Sent: Wednesday, November 15, 2017 9:24 AM To: sanjay.mishra@verizon.com; QUIC WG Subject: RE: spin bit in QUIC +1 Even with the limitations known, the spin bit will allow service providers = to measure latency in the network for troubleshooting. That's why I want to add my support for the inclusion of the spin bit into = V1 BR Jesus Make a small change everyday Jes=FAs Mart=EDn | Telef=F3nica S.A. De: QUIC [mailto:quic-bounces@ietf.org] En nombre de sanjay.mishra@verizon.= com Enviado el: martes, 14 de noviembre de 2017 10:38 Para: QUIC WG > CC: Roni Even > Asunto: RE: spin bit in QUIC Adding to what Roni has below, first, I applaud to the spin bit design for = their time since the Prague meeting and many thanks to Ted for presenting t= hose findings. >From Ted's presentation, it appears that the design team accomplished what = they were asked to do, that is, look at geolocation threat and Min RTT. Sli= de 7 from Ted's presentation lays out negligible threat and at least not an= y additional adversarial information. Given this, I would have thought des= ign team to be less tentative and come to a clear consensus. Also, agree with Marcus on his enumeration on the need for spin bit and as = Roni pointed out inclusion of spin but in v1 gives us some real -world depl= oyment experience on performance and bottlenecks. I ask the chairs to add spin bit for v1. -Sanjay From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even Sent: Tuesday, November 14, 2017 4:41 PM To: QUIC WG > Subject: [E] spin bit in QUIC Hi, It is good that the conclusion about the geo location security issue is tha= t the spin bit does not add privacy risk on top of what can be done without= it. As for the spin bit. RTT calculation are used for trouble shooting in TCP s= ee in draft-even-quic-troubleshooting-video-delivery-00. The spin bit will provide similar functionality even though it is less reli= able as was mentioned since it is not part of the QUIC state machine. We envision that we will see a lot of QUIC traffic in the network and havin= g the spin bit can help with identifying bottle necks in the network and re= ducing QUIC latency. It will be important to have the spin bit in V1 and t= he main text is already in the github Thanks Roni Even ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o= copia sin autorizaci=F3n puede estar prohibida en virtud de la legislaci= =F3n vigente. Si ha recibido este mensaje por error, le rogamos que nos lo = comunique inmediatamente por esta misma v=EDa y proceda a su destrucci=F3n. The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this co= mmunication is strictly prohibited. If you have received this transmission = in error, do not read it. Please immediately reply to the sender that you h= ave received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, div= ulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o pode estar proibida em virtude= da legisla=E7=E3o vigente. Se recebeu esta mensagem por erro, rogamos-lhe = que nos o comunique imediatamente por esta mesma via e proceda a sua destru= i=E7=E3o --_000_c2d3578e2b804c9488c325068d623f43usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

If the operators believe that this bit will improve = their networks and will help end user experience for QUIC, I am all for it = (since the privacy risks of this bit is practically negligible).=

 

  • Igor

 

From: JESUS MARIA MARTIN GARCIA [mailto:jesus= maria.martingarcia@telefonica.com]
Sent: Wednesday, November 15, 2017 9:24 AM
To: sanjay.mishra@verizon.com; QUIC WG <quic@ietf.org>
Subject: RE: spin bit in QUIC

 

+1

 

Even with the limitati= ons known, the spin bit will allow service providers to measure latency in = the network for troubleshooting.

 

That’s why I wan= t to add my support for the inclusion of the spin bit into V1

 

BR

Jesus

Make a small change ev= eryday

&n= bsp;

Jes=FAs Mart=EDn | Telef=F3nica S.A.

 = ;

De: QUIC [mailto:quic-bounces@ietf.o= rg] En nombre de sanjay.mis= hra@verizon.com
Enviado el: martes, 14 de noviembre de 2017 10:38
Para: QUIC WG <quic@ietf.org= >
CC: Roni Even <roni.even@= huawei.com>
Asunto: RE: spin bit in QUIC

 

Adding to what Roni ha= s below, first, I applaud to the spin bit design for their time since the P= rague meeting and many thanks to Ted for presenting those findings.

 

From Ted’s prese= ntation, it appears that the design team accomplished what they were asked = to do, that is, look at geolocation threat and Min RTT. Slide 7 from Ted= 217;s presentation lays out negligible threat and at least not any additional adversarial information.  Given this, I w= ould have thought design team to be less tentative and come to a clear cons= ensus.

 

Also, agree with Marcu= s on his enumeration on the need for spin bit and as Roni pointed out inclu= sion of spin but in v1 gives us some real –world deployment experienc= e on performance and bottlenecks.

 

I ask the chairs to ad= d spin bit for v1.

 

-Sanjay

 

 

From: QUIC [mailto:quic-bounces@ietf.org= ] On Behalf Of Roni Even
Sent: Tuesday, November 14, 2017 4:41 PM
To: QUIC WG <<= span lang=3D"EN-US">quic@ietf.org>
Subject: [E] spin bit in QUIC

 

Hi,

It is good that the conclusion about the geo locatio= n security issue is that the spin bit does not add privacy risk on top of w= hat can be done without it.

 

As for the spin bit. RTT calculation are used for tr= ouble shooting in TCP see in draft-even-quic-troubleshooting-video-delivery= -00.

The spin bit will provide similar functionality even= though it is less reliable as was mentioned since it is not part of the QU= IC state machine.

We envision that we will see a lot of QUIC traffic i= n the network and having the spin bit can help with identifying bottle neck= s in the network and reducing QUIC latency.  It will be important to h= ave the spin bit in V1 and the main text is already in the github

 

Thanks

Roni Even

 

 

 

 


Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, pu= ede contener informaci=F3n privilegiada o confidencial y es para uso exclus= ivo de la persona o entidad de destino. Si no es usted. el destinatario ind= icado, queda notificado de que la lectura, utilizaci=F3n, divulgaci=F3n y/o copia sin autorizaci=F3n puede e= star prohibida en virtud de la legislaci=F3n vigente. Si ha recibido este m= ensaje por error, le rogamos que nos lo comunique inmediatamente por esta m= isma v=EDa y proceda a su destrucci=F3n.

The information contained in this transmission is privileged and confidenti= al information intended only for the use of the individual or entity named = above. If the reader of this message is not the intended recipient, you are= hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If y= ou have received this transmission in error, do not read it. Please immedia= tely reply to the sender that you have received this communication in error= and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinat=E1rio= , pode conter informa=E7=E3o privilegiada ou confidencial e =E9 para uso ex= clusivo da pessoa ou entidade de destino. Se n=E3o =E9 vossa senhoria o des= tinat=E1rio indicado, fica notificado de que a leitura, utiliza=E7=E3o, divulga=E7=E3o e/ou c=F3pia sem autoriza=E7=E3o p= ode estar proibida em virtude da legisla=E7=E3o vigente. Se recebeu esta me= nsagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mes= ma via e proceda a sua destrui=E7=E3o

--_000_c2d3578e2b804c9488c325068d623f43usma1exdag1mb5msgcorpak_-- From nobody Tue Nov 14 21:25: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 E1372128DF2 for ; Tue, 14 Nov 2017 21:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 Zw3Vjr1yR0Yq for ; Tue, 14 Nov 2017 21:25:28 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 75925127058 for ; Tue, 14 Nov 2017 21:25:28 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 357CAEB84D14A for ; Wed, 15 Nov 2017 05:25:25 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 05:25:27 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 13:25:04 +0800 From: Roni Even To: Mike Bishop , QUIC WG Subject: RE: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQAAPS1iA= Date: Wed, 15 Nov 2017 05:25:03 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.46.95] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD83701DDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 05:25:30 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD83701DDGGEMM506MBXchina_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable So what is the connection migration flow here. The quic stack in the cell n= etwork will try to migrate to wifi without application request and fail but= will not fall back to TCP. There may be multiple application running over quic? HTTP and peer to peer = at the same time, so who will handle this case? Roni From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 05:35 To: Roni Even; QUIC WG Subject: RE: connection migration That may well be the case, but it=92s not the QUIC stack=92s choice to make= . The application could choose to open a new connection, but that remains = outside the scope of the transport and the mapping to it which we=92re defi= ning. For HTTP, this is fairly straightforward =96 it could stop issuing new flow= control credit, let currently-in-transit data arrive and any losses recove= red, and open a TCP connection to issue a range request starting at whateve= r data offset it hasn=92t seen. But that=92s still a property of an HTTP m= anagement above the HTTP/QUIC mapping. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, November 15, 2017 11:25 AM To: QUIC WG > Subject: connection migration Hi, When moving from cell to wifi the reason may be due to cost (money or quota= ). In this case the user (client) may want to move to wifi even if it will= mean dropping to TCP. Roni --_000_6E58094ECC8D8344914996DAD28F1CCD83701DDGGEMM506MBXchina_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

So what is the connect= ion migration flow here. The quic stack in the cell network will try to mig= rate to wifi without application request and fail but will not fall back to= TCP.

There may be multiple = application running over quic? HTTP and peer to peer at the same time, so w= ho will handle this case?

 

Roni=

 

From: Mike Bis= hop [mailto:mbishop@evequefou.be]
Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 05:35
To: Roni Even; QUIC WG
Subject: RE: connection migration

 

That may well be the case, but it=92s not the QUIC s= tack=92s choice to make.  The application could choose to open a new c= onnection, but that remains outside the scope of the transport and the mapp= ing to it which we=92re defining.

 

For HTTP, this is fairly straightforward =96 it coul= d stop issuing new flow control credit, let currently-in-transit data arriv= e and any losses recovered, and open a TCP connection to issue a range requ= est starting at whatever data offset it hasn=92t seen.  But that=92s still a property of an HTTP managemen= t above the HTTP/QUIC mapping.

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <quic@ietf.org&g= t;
Subject: connection migration

 

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the  user (client) may want to = move to wifi even if it will mean dropping to TCP.

 

Roni

--_000_6E58094ECC8D8344914996DAD28F1CCD83701DDGGEMM506MBXchina_-- From nobody Tue Nov 14 21:49: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 585211294F7 for ; Tue, 14 Nov 2017 21:49:44 -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, 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 35FU_djfI0Hs for ; Tue, 14 Nov 2017 21:49:42 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 9C3401294F4 for ; Tue, 14 Nov 2017 21:48:48 -0800 (PST) Received: from dhcp-8a57.meeting.ietf.org (unknown [IPv6:2001:67c:370:128:2094:13f3:30e5:c12d]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 5A06F1B00247; Wed, 15 Nov 2017 05:48:27 +0000 (GMT) Message-ID: <5A0BD528.3040106@erg.abdn.ac.uk> Date: Wed, 15 Nov 2017 13:48:24 +0800 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: "MORTON, ALFRED C (AL)" CC: Ian Swett , "emile.stephan@orange.com" , QUIC WG Subject: Re: spin bit in QUIC: troubleshooting References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> 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.22 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 Nov 2017 05:49:44 -0000 As I said at the mic: I think the spin-bit analysis was helpful, thanks. I can see how spin-bit is really useful to get basic diagnostics of RTT if it can be relied to be present in every packet. (It is important to measure latency within the network). There are places where 1-bit gives restricted value, and using more would help: My additional comment at the Mic related to how much extra would be the gain from an additional one or two bits? In particular, I'd like to see a method that can let me detect some loss patterns and measure reordering, at least I think it is important to know and measure when there is small-scale reordering <3. A suggestion:is to use a 2-bit counter for the spin ( 00->01->10->11->00), that would help detect these path anomlies. Gorry On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote: > > I’d like to offer support for Spin Bit (and one or two > > bits for management if they can be justified quickly) in v1. > > On this topic of more bits, > > asking further clarification from Emile, below [ACM]. > > Al > > *From:*QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* Tuesday, November 14, 2017 4:21 PM > *To:* emile.stephan@orange.com > *Cc:* QUIC WG > *Subject:* Re: spin bit in QUIC: troubleshooting > > Thanks for clarifying Emile. > > On Tue, Nov 14, 2017 at 1:06 PM, > wrote: > > Hi Ian, > > It was suggested in the latest discussion on the RTT design team > mailing list to have one bit for packet lost, one for latency (spin > bit or eq.) and one for congestion. > > */[ACM] /* There may be some overlap with ECN and « one bit for > congestion ». > > Did you also consider this dependency, Emile ? (I’m echoing a hallway > discussion) > > It seems a simplistic approach on one hand but an invariant on the > long term. > > Regards > > Emile > > *De :*Ian Swett [mailto:ianswett@google.com ] > *Envoyé :* mardi 14 novembre 2017 22:51 > *À :* STEPHAN Emile IMT/OLN > *Cc :* QUIC WG > *Objet :* Re: spin bit in QUIC: troubleshooting > > What would the other bit or two be used for? If there is no > standardized use of those bits in v1, then I believe we should wait to > reserve them when their usage is defined, given we'd need a version > bump to specify how they were being used. At the moment, the > management use case is not competing with anyone else for bits in the > short header. > > On Tue, Nov 14, 2017 at 5:14 AM, > wrote: > > Hi > > Last week Orange experienced a fallback of QUIC to TCP on one of its > networks. The issues were not visible in QUIC traffic. The > troubleshooting was made using TCP packets information. This is not > sustainable on the long term when numerous applications using > different versions of QUIC will stop to fallback to TCP. > > Based on the exchange we had in the RTT design team and in today > meeting , it sounds reasonable to reserve at least 2 bits (ideally 3 > bits as discussed in the design team) for manageability in the QUIC > invariants and to start experimenting the spin bit in QUIC V1. > > Regards > > Emile > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > From nobody Tue Nov 14 21:59: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 536961294B3 for ; Tue, 14 Nov 2017 21:59:55 -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, 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 EzWxdaa8prDI for ; Tue, 14 Nov 2017 21:59:53 -0800 (PST) Received: from hub021-ca-6.exch021.serverdata.net (hub021-ca-6.exch021.serverdata.net [64.78.56.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4580D1243F6 for ; Tue, 14 Nov 2017 21:59:53 -0800 (PST) Received: from MBX021-W3-CA-2.exch021.domain.local ([10.254.4.78]) by HUB021-CA-6.exch021.domain.local ([10.254.4.92]) with mapi id 14.03.0319.002; Tue, 14 Nov 2017 21:59:52 -0800 From: Piotr Galecki To: "gorry@erg.abdn.ac.uk" , "MORTON, ALFRED C (AL)" CC: Ian Swett , QUIC WG , "emile.stephan@orange.com" Subject: RE: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFwAadoYAAAbTAwAABsr3AAAJd4YAAAhCegAAEKR6AA== Date: Wed, 15 Nov 2017 05:59:51 +0000 Message-ID: <2C515BE8694C6F4B9B6A578BCAC32E2F83AC9673@MBX021-W3-CA-2.exch021.domain.local> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> <5A0BD528.3040106@erg.abdn.ac.uk> In-Reply-To: <5A0BD528.3040106@erg.abdn.ac.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.203.66.100] 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.22 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 Nov 2017 05:59:55 -0000 SG93IHdvdWxkIGEgbmV0d29yayBwcm9iZSBiZSBhYmxlIHRvIG1lYXN1cmUgdGhlIGxldmVsIG9m IHBhY2tldCByZW9yZGVyaW5nIGluIFFVSUMgc3RyZWFtIHdpdGggb25seSBhIHNwaW4gYml0Pw0K DQpJJ20gYXNraW5nIGJlY2F1c2Ugb25lIG9mIHRoZSBjb21tb24gdGVjaG5pcXVlcyB0byBkaWFn bm9zZSBuZXR3b3JrIGlzc3Vlcw0KaXMgdG8gaW5zZXJ0IGEgcHJvYmUgaW4gZGlmZmVyZW50IHBv aW50cyBpbiB0aGUgbmV0d29yayBhbmQgbWVhc3VyZToNCiogUlRUDQoqIFRDUCBzZWdtZW50IGxv c3MNCiogVENQIHNlZ21lbnQgcmV0cmFuc21pc3Npb25zDQoqIFRDUCBzZWdtZW50IG91dC1vZi1v cmRlcg0KYXMgYSBmZXcgYmFzaWMgZGF0YSBwb2ludHMuDQpXaXRoIG1lYXN1cmVtZW50cyBpbiBw b2ludCBBIGFuZCBwb2ludCBCIG9uZSBjYW4gZGV0ZXJtaW5lIGZvciBleGFtcGxlIGlmIGEgbmV0 d29yayBkZXZpY2UgaXMgbWlzb3JkZXJpbmcgcGFja2V0cy4NCg0KLVBpb3RyDQoNCi0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnXSBPbiBCZWhhbGYgT2YgR29ycnkgRmFpcmh1cnN0DQpTZW50OiBXZWRuZXNkYXksIE5vdmVt YmVyIDE1LCAyMDE3IDEyOjQ4IEFNDQpUbzogTU9SVE9OLCBBTEZSRUQgQyAoQUwpIDxhY21vcnRv bkBhdHQuY29tPg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xlLmNvbT47IFFVSUMgV0cg PHF1aWNAaWV0Zi5vcmc+OyBlbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20NClN1YmplY3Q6IFJlOiBz cGluIGJpdCBpbiBRVUlDOiB0cm91Ymxlc2hvb3RpbmcNCg0KQXMgSSBzYWlkIGF0IHRoZSBtaWM6 IEkgdGhpbmsgdGhlIHNwaW4tYml0IGFuYWx5c2lzIHdhcyBoZWxwZnVsLCB0aGFua3MuDQoNCkkg Y2FuIHNlZSBob3cgc3Bpbi1iaXQgaXMgcmVhbGx5IHVzZWZ1bCB0byBnZXQgYmFzaWMgZGlhZ25v c3RpY3Mgb2YgUlRUIGlmIGl0IGNhbiBiZSByZWxpZWQgdG8gYmUgcHJlc2VudCBpbiBldmVyeSBw YWNrZXQuIChJdCBpcyBpbXBvcnRhbnQgdG8gbWVhc3VyZSBsYXRlbmN5IHdpdGhpbiB0aGUgbmV0 d29yaykuDQoNClRoZXJlIGFyZSBwbGFjZXMgd2hlcmUgMS1iaXQgZ2l2ZXMgcmVzdHJpY3RlZCB2 YWx1ZSwgYW5kIHVzaW5nIG1vcmUgd291bGQgaGVscDogTXkgYWRkaXRpb25hbCBjb21tZW50IGF0 IHRoZSBNaWMgcmVsYXRlZCB0byBob3cgbXVjaCBleHRyYSB3b3VsZCBiZSB0aGUgZ2FpbiBmcm9t IGFuIGFkZGl0aW9uYWwgb25lIG9yIHR3byBiaXRzPw0KDQpJbiBwYXJ0aWN1bGFyLCBJJ2QgbGlr ZSB0byBzZWUgYSBtZXRob2QgdGhhdCBjYW4gbGV0IG1lIGRldGVjdCBzb21lIGxvc3MgcGF0dGVy bnMgYW5kIG1lYXN1cmUgcmVvcmRlcmluZywgYXQgbGVhc3QgSSB0aGluayBpdCBpcyBpbXBvcnRh bnQgdG8ga25vdyBhbmQgbWVhc3VyZSB3aGVuIHRoZXJlIGlzIHNtYWxsLXNjYWxlIHJlb3JkZXJp bmcgPDMuDQoNCkEgc3VnZ2VzdGlvbjppcyB0byB1c2UgYSAyLWJpdCBjb3VudGVyIGZvciB0aGUg c3BpbiAoIA0KMDAtPjAxLT4xMC0+MTEtPjAwKSwgdGhhdCB3b3VsZCBoZWxwIGRldGVjdCB0aGVz ZSBwYXRoIGFub21saWVzLg0KDQpHb3JyeQ0KDQpPbiAxNS8xMS8yMDE3LCAwOTo1MSwgTU9SVE9O LCBBTEZSRUQgQyAoQUwpIHdyb3RlOg0KPg0KPiBJ4oCZZCBsaWtlIHRvIG9mZmVyIHN1cHBvcnQg Zm9yIFNwaW4gQml0IChhbmQgb25lIG9yIHR3bw0KPg0KPiBiaXRzIGZvciBtYW5hZ2VtZW50IGlm IHRoZXkgY2FuIGJlIGp1c3RpZmllZCBxdWlja2x5KSBpbiB2MS4NCj4NCj4gT24gdGhpcyB0b3Bp YyBvZiBtb3JlIGJpdHMsDQo+DQo+IGFza2luZyBmdXJ0aGVyIGNsYXJpZmljYXRpb24gZnJvbSBF bWlsZSwgYmVsb3cgW0FDTV0uDQo+DQo+IEFsDQo+DQo+ICpGcm9tOipRVUlDIFttYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnXSAqT24gQmVoYWxmIE9mICpJYW4gU3dldHQNCj4gKlNlbnQ6KiBU dWVzZGF5LCBOb3ZlbWJlciAxNCwgMjAxNyA0OjIxIFBNDQo+ICpUbzoqIGVtaWxlLnN0ZXBoYW5A b3JhbmdlLmNvbQ0KPiAqQ2M6KiBRVUlDIFdHDQo+ICpTdWJqZWN0OiogUmU6IHNwaW4gYml0IGlu IFFVSUM6IHRyb3VibGVzaG9vdGluZw0KPg0KPiBUaGFua3MgZm9yIGNsYXJpZnlpbmcgRW1pbGUu DQo+DQo+IE9uIFR1ZSwgTm92IDE0LCAyMDE3IGF0IDE6MDYgUE0sIDxlbWlsZS5zdGVwaGFuQG9y YW5nZS5jb20gDQo+IDxtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+ DQo+IEhpIElhbiwNCj4NCj4gSXQgd2FzIHN1Z2dlc3RlZCBpbiB0aGUgbGF0ZXN0IGRpc2N1c3Np b24gb24gdGhlIFJUVCBkZXNpZ24gdGVhbSANCj4gbWFpbGluZyBsaXN0IHRvIGhhdmUgb25lIGJp dCBmb3IgcGFja2V0IGxvc3QsIG9uZSBmb3IgbGF0ZW5jeSAoc3BpbiANCj4gYml0IG9yIGVxLikg YW5kIG9uZSBmb3IgY29uZ2VzdGlvbi4NCj4NCj4gKi9bQUNNXSAvKiBUaGVyZSBtYXkgYmUgc29t ZSBvdmVybGFwIHdpdGggRUNOIGFuZCDCqyBvbmUgYml0IGZvciANCj4gY29uZ2VzdGlvbiDCuy4N Cj4NCj4gRGlkIHlvdSBhbHNvIGNvbnNpZGVyIHRoaXMgZGVwZW5kZW5jeSwgRW1pbGUgPyAoSeKA mW0gZWNob2luZyBhIGhhbGx3YXkNCj4gZGlzY3Vzc2lvbikNCj4NCj4gSXQgc2VlbXMgYSBzaW1w bGlzdGljIGFwcHJvYWNoIG9uIG9uZSBoYW5kIGJ1dCBhbiBpbnZhcmlhbnQgb24gdGhlIA0KPiBs b25nIHRlcm0uDQo+DQo+IFJlZ2FyZHMNCj4NCj4gRW1pbGUNCj4NCj4gKkRlIDoqSWFuIFN3ZXR0 IFttYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSANCj4gPG1haWx0bzppYW5zd2V0dEBnb29nbGUu Y29tPl0gKkVudm95w6kgOiogbWFyZGkgMTQgbm92ZW1icmUgMjAxNyAyMjo1MSANCj4gKsOAIDoq IFNURVBIQU4gRW1pbGUgSU1UL09MTiAqQ2MgOiogUVVJQyBXRyAqT2JqZXQgOiogUmU6IHNwaW4g Yml0IGluIA0KPiBRVUlDOiB0cm91Ymxlc2hvb3RpbmcNCj4NCj4gV2hhdCB3b3VsZCB0aGUgb3Ro ZXIgYml0IG9yIHR3byBiZSB1c2VkIGZvcj8gIElmIHRoZXJlIGlzIG5vIA0KPiBzdGFuZGFyZGl6 ZWQgdXNlIG9mIHRob3NlIGJpdHMgaW4gdjEsIHRoZW4gSSBiZWxpZXZlIHdlIHNob3VsZCB3YWl0 IHRvIA0KPiByZXNlcnZlIHRoZW0gd2hlbiB0aGVpciB1c2FnZSBpcyBkZWZpbmVkLCBnaXZlbiB3 ZSdkIG5lZWQgYSB2ZXJzaW9uIA0KPiBidW1wIHRvIHNwZWNpZnkgaG93IHRoZXkgd2VyZSBiZWlu ZyB1c2VkLiAgQXQgdGhlIG1vbWVudCwgdGhlIA0KPiBtYW5hZ2VtZW50IHVzZSBjYXNlIGlzIG5v dCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBmb3IgYml0cyBpbiB0aGUgDQo+IHNob3J0IGhl YWRlci4NCj4NCj4gT24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgNToxNCBBTSwgPGVtaWxlLnN0ZXBo YW5Ab3JhbmdlLmNvbSANCj4gPG1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+PiB3cm90 ZToNCj4NCj4gSGkNCj4NCj4gTGFzdCB3ZWVrIE9yYW5nZSBleHBlcmllbmNlZCBhIGZhbGxiYWNr IG9mIFFVSUMgdG8gVENQIG9uIG9uZSBvZiBpdHMgDQo+IG5ldHdvcmtzLiBUaGUgaXNzdWVzIHdl cmUgbm90IHZpc2libGUgaW4gUVVJQyB0cmFmZmljLiBUaGUgDQo+IHRyb3VibGVzaG9vdGluZyB3 YXMgbWFkZSB1c2luZyBUQ1AgcGFja2V0cyBpbmZvcm1hdGlvbi4gVGhpcyBpcyBub3QgDQo+IHN1 c3RhaW5hYmxlIG9uIHRoZSBsb25nIHRlcm0gd2hlbiBudW1lcm91cyBhcHBsaWNhdGlvbnMgdXNp bmcgDQo+IGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdpbGwgc3RvcCB0byBmYWxsYmFjayB0 byBUQ1AuDQo+DQo+IEJhc2VkIG9uIHRoZSBleGNoYW5nZSB3ZSBoYWQgaW4gdGhlIFJUVCBkZXNp Z24gdGVhbSBhbmQgaW4gdG9kYXkgDQo+IG1lZXRpbmcgLCBpdCBzb3VuZHMgcmVhc29uYWJsZSB0 byByZXNlcnZlIGF0IGxlYXN0IDIgYml0cyAoaWRlYWxseSAzIA0KPiBiaXRzIGFzIGRpc2N1c3Nl ZCBpbiB0aGUgZGVzaWduIHRlYW0pIGZvciBtYW5hZ2VhYmlsaXR5IGluIHRoZSBRVUlDIA0KPiBp bnZhcmlhbnRzIGFuZCB0byBzdGFydCBleHBlcmltZW50aW5nIHRoZSBzcGluIGJpdCBpbiBRVUlD IFYxLg0KPg0KPiBSZWdhcmRzDQo+DQo+IEVtaWxlDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgDQo+ IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyANCj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIA0KPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIA0KPiBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuDQo+ICAgDQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciANCj4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPg0KPiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiAgIA0KPiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNv bnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgDQo+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2ll ZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLCANCj4gZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSAN Cj4gcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLg0KPiAgIA0KPiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgDQo+IHByaXZpbGVnZWQgaW5mb3JtYXRp b24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3Ry aWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+IElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPiBBcyBlbWFp bHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0 IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQo+IFRoYW5rIHlvdS4N Cj4NCg== From nobody Tue Nov 14 22:02: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 6F7E41294F7 for ; Tue, 14 Nov 2017 22:02:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.397 X-Spam-Level: X-Spam-Status: No, score=-4.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 pEBOEfu4HLtV for ; Tue, 14 Nov 2017 22:02:54 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8C0D1243F6 for ; Tue, 14 Nov 2017 22:02:53 -0800 (PST) Received: from opfednr03.francetelecom.fr (unknown [xx.xx.xx.67]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 51ACFC0B30; Wed, 15 Nov 2017 06:54:21 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.72]) by opfednr03.francetelecom.fr (ESMTP service) with ESMTP id 269F61A005C; Wed, 15 Nov 2017 06:54:21 +0100 (CET) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541%19]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 06:54:20 +0100 From: To: Bret Jordan , Mike Bishop CC: Roni Even , "quic@ietf.org" Subject: RE: ACKs in encrypted tunnel Thread-Topic: ACKs in encrypted tunnel Thread-Index: AQHTXcGMe50qXjZTt0OJtxUCWFKTIqMUuBcAgAABy4CAAAEiAIAAEZXA Date: Wed, 15 Nov 2017 05:54:19 +0000 Message-ID: <10753_1510725261_5A0BD68D_10753_79_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E9B0@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> <0F543241-F5B6-4A55-B773-2DEFDDC8860C@gmail.com> In-Reply-To: <0F543241-F5B6-4A55-B773-2DEFDDC8860C@gmail.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.6] Content-Type: multipart/alternative; boundary="_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E9B0OPEXCLILM44corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:02:56 -0000 --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E9B0OPEXCLILM44corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTWlrZSwNCg0KV2Ugd291bGQgbm90IGhhdmUgdGhpcyBkaXNjdXNzaW9uIGlmIHRoaXMgd2Fz IHRoZSBjYXNlLg0KDQpSZWdhcmRzDQpFbWlsZQ0KDQpEZSA6IFFVSUMgW21haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmddIERlIGxhIHBhcnQgZGUgQnJldCBKb3JkYW4NCkVudm95w6kgOiBtZXJj cmVkaSAxNSBub3ZlbWJyZSAyMDE3IDExOjQyDQrDgCA6IE1pa2UgQmlzaG9wDQpDYyA6IFJvbmkg RXZlbjsgcXVpY0BpZXRmLm9yZw0KT2JqZXQgOiBSZTogQUNLcyBpbiBlbmNyeXB0ZWQgdHVubmVs DQoNCkkgYW0gbm90IHN1cmUgdGhhdCBpcyByZWFsbHkgcmVhbGlzdGljLg0KDQpCcmV0DQpTZW50 IGZyb20gbXkgQ29tbW9kb3JlIDEyOEQNCg0KDQpQR1AgRmluZ2VycHJpbnQ6IDYzQjQgRkM1MyA2 ODBBIDZCN0QgMTQ0NyAgRjJDMCA3NEY4IEFDQUUgNzQxNSAwMDUwDQoNCk9uIE5vdiAxNSwgMjAx NywgYXQgMTE6MzcgQU0sIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86 bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3cm90ZToNCkFsc28sIGlmIHRoZSBlbmQgcG9pbnQocykg Y29uc2VudCB0byBnaXZlIHlvdSB0aGUga2V5cywgbm90aGluZyBzdG9wcyB5b3UgZnJvbSBpbnNw ZWN0aW5nIGEgcGFydGljdWxhciBmbG93LiAgSXQgcmVxdWlyZXMgdGhlIGFjdGl2ZSBjb29wZXJh dGlvbiBvZiBhdCBsZWFzdCBvbmUgcGFydHkgdG8gdGhlIGNvbm5lY3Rpb24sIGJ1dCBpZiBzb21l b25l4oCZcyBjYWxsaW5nIHlvdSBmb3IgaGVscCwgdGhhdOKAmXMgcHJlc3VtYWJseSB0aGUgY2Fz ZS4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIFJvbmkgRXZlbg0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyAxMTozMSBB TQ0KVG86IEJyZXQgSm9yZGFuIDxqb3JkYW4uaWV0ZkBnbWFpbC5jb208bWFpbHRvOmpvcmRhbi5p ZXRmQGdtYWlsLmNvbT4+OyBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KU3Vi amVjdDogUkU6IEFDS3MgaW4gZW5jcnlwdGVkIHR1bm5lbA0KDQpIaSwNClRoaXMgaXMgZGlzY3Vz c2VkIGluIHRoZSBzcGluIGJpdCB0aGF0IHdhcyBwcmVzZW50ZWQgeWVzdGVyZGF5DQpSb25pDQoN CkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBC cmV0IEpvcmRhbg0KU2VudDog15nXldedINeTIDE1INeg15XXkdee15HXqCAyMDE3IDA1OjI2DQpU bzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IEFDS3MgaW4g ZW5jcnlwdGVkIHR1bm5lbA0KDQpTbyBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYWxsIEFDS3Mg YW5kIG5vdGljZXMgYWJvdXQgbG9zdCBwYWNrZXRzLCBmcmFtZXMsIGV0YyB3aWxsIGJlIGNvbW11 bmljYXRlZCBpbnNpZGUgdGhlIGVuY3J5cHRlZCB0dW5uZWwgd2l0aCBRVUlDLg0KDQpXaGF0IGlz IG91ciBwbGFuIHRvIGVuYWJsZSBuZXR3b3JrIG9wZXJhdG9ycyB0byBoZWxwIHRyb3VibGVzaG9v dCBuZXR3b3JrIHByb2JsZW1zIHdpdGggUVVJQz8NCg0KV2hlbiBydW5uaW5nIGEgbGFyZ2UgbmV0 d29yayB0aGUgbmV0d29yayB0ZWFtIC8gbmV0d29yayBvcGVyYXRvcnMgYXJlIG9mdGVuIGFza2Vk IHRvIGhlbHAgaWRlbnRpZnkgcHJvYmxlbXMgd2hlbiBhbiBhcHBsaWNhdGlvbiBpcyBub3Qgd29y a2luZyBvciBpcyBzbHVnZ2lzaC4gSWYgYWxsIGluZm9ybWF0aW9uIGlzIGluc2lkZSB0aGUgZW5j cnlwdGVkIHR1bm5lbCwgYXJlIHdlIGp1c3Qgc2F5aW5nIOKAnGVuZCB1c2VyIGFuZCBhcHBsaWNh dGlvbiBzdXBwb3J0IHBlcnNvbiwgeW91IGZpZ3VyZSBpdCBvdXQ/4oCdDQoNClRoaXMgc2VlbXMg bGlrZSBhIGh1Z2UgcHJvYmxlbS4gIEkgbWVhbiB0aGUgbmV0d29yayBkb2VzIG5vdCBhbHdheXMg d29yayBmbGF3bGVzc2x5IGFuZCBpdCBzZWVtcyBsaWtlIHdlIGFyZSByZW1vdmluZyBhbGwgdGhl IGFiaWxpdGllcyBmb3IgbmV0d29yayBvcGVyYXRvcnMgdG8gZW5zdXJlIGFueSBsZXZlbCBvZiBT TEEgb3IgT0xBLg0KDQpCcmV0DQoNClNlbnQgZnJvbSBteSBDb21tb2RvcmUgMTI4RA0KDQpQR1Ag RmluZ2VycHJpbnQ6IDYzQjQgRkM1MyA2ODBBIDZCN0QgMTQ0NyAgRjJDMCA3NEY4IEFDQUUgNzQx NSAwMDUwPHRlbDo3NDE1JTIwMDA1MD4NCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVj ZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVs bGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMs IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1 IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRl dXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3Jhbmdl IGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUs IGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24g dGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQg ZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E9B0OPEXCLILM44corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRv bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0K CXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJ bWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4t bGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5U ZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsN Cgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxl cyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4uRW1haWxTdHls ZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlh bCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglm b250LXN0eWxlOm5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30N CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRt YXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRh PSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJv ZHkgbGFuZz0iRlIiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2siPkhpIE1pa2UsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPldlIHdvdWxkIG5vdCBoYXZl IHRoaXMgZGlzY3Vzc2lvbiBpZiB0aGlzIHdhcyB0aGUgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2siPlJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ RW1pbGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EZSZuYnNwOzo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10NCjxiPkRlIGxhIHBhcnQgZGU8L2I+IEJyZXQgSm9yZGFuPGJyPg0K PGI+RW52b3nDqSZuYnNwOzo8L2I+IG1lcmNyZWRpIDE1IG5vdmVtYnJlIDIwMTcgMTE6NDI8YnI+ DQo8Yj7DgCZuYnNwOzo8L2I+IE1pa2UgQmlzaG9wPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBSb25p IEV2ZW47IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+IFJlOiBBQ0tzIGlu IGVuY3J5cHRlZCB0dW5uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGFtIG5vdCBzdXJlIHRoYXQgaXMgcmVhbGx5IHJlYWxpc3RpYy48bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+QnJldCZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBpZD0iQXBwbGVNYWlsU2ln bmF0dXJlIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbnQgZnJvbSBteSBDb21tb2RvcmUgMTI4 RDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4N CjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UEdQ IEZpbmdlcnByaW50OiZuYnNwOzYzQjQgRkM1MyA2ODBBIDZCN0QgMTQ0NyAmbmJzcDtGMkMwIDc0 RjggQUNBRSA3NDE1IDAwNTA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpP biBOb3YgMTUsIDIwMTcsIGF0IDExOjM3IEFNLCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIj5tYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkFsc28sIGlmIHRoZSBlbmQgcG9pbnQocykg Y29uc2VudCB0byBnaXZlIHlvdSB0aGUga2V5cywgbm90aGluZyBzdG9wcyB5b3UgZnJvbSBpbnNw ZWN0aW5nIGEgcGFydGljdWxhciBmbG93LiZuYnNwOyBJdCByZXF1aXJlcyB0aGUgYWN0aXZlIGNv b3BlcmF0aW9uIG9mIGF0IGxlYXN0IG9uZSBwYXJ0eSB0bw0KIHRoZSBjb25uZWN0aW9uLCBidXQg aWYgc29tZW9uZeKAmXMgY2FsbGluZyB5b3UgZm9yIGhlbHAsIHRoYXTigJlzIHByZXN1bWFibHkg dGhlIGNhc2UuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEg bmFtZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvYT48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAw Y20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUVVJQyBbPGEg aHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnF1aWMtYm91bmNlc0Bp ZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvbmkgRXZlbjxicj4NCjxiPlNlbnQ6 PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDE1LCAyMDE3IDExOjMxIEFNPGJyPg0KPGI+VG86PC9i PiBCcmV0IEpvcmRhbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmpvcmRhbi5pZXRmQGdtYWlsLmNvbSI+ am9yZGFuLmlldGZAZ21haWwuY29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRm Lm9yZyI+cXVpY0BpZXRmLm9yZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEFDS3MgaW4g ZW5jcnlwdGVkIHR1bm5lbDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBkaXNjdXNzZWQgaW4gdGhlIHNwaW4g Yml0IHRoYXQgd2FzIHByZXNlbnRlZCB5ZXN0ZXJkYXk8L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+Um9uaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBR VUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj5tYWlsdG86cXVpYy1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+QnJldCBKb3JkYW48YnI+ DQo8Yj5TZW50OjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9IkhFIiBkaXI9IlJUTCIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPteZ15XXnSZuYnNwO9eTIDE1INeg15XXkdee15HXqCAyMDE3IDA1OjI2PC9z cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9t YSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBBQ0tzIGluIGVuY3J5cHRlZCB0dW5uZWw8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYWxsIEFDS3Mg YW5kIG5vdGljZXMgYWJvdXQgbG9zdCBwYWNrZXRzLCBmcmFtZXMsIGV0YyB3aWxsIGJlIGNvbW11 bmljYXRlZCBpbnNpZGUgdGhlIGVuY3J5cHRlZCB0dW5uZWwgd2l0aCBRVUlDLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XaGF0IGlzIG91ciBwbGFuIHRvIGVuYWJsZSBuZXR3b3JrIG9wZXJhdG9ycyB0byBo ZWxwIHRyb3VibGVzaG9vdCBuZXR3b3JrIHByb2JsZW1zIHdpdGggUVVJQz8mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVuIHJ1bm5pbmcgYSBsYXJnZSBuZXR3b3JrIHRoZSBuZXR3 b3JrIHRlYW0gLyBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgb2Z0ZW4gYXNrZWQgdG8gaGVscCBpZGVu dGlmeSBwcm9ibGVtcyB3aGVuIGFuIGFwcGxpY2F0aW9uIGlzIG5vdCB3b3JraW5nIG9yIGlzIHNs dWdnaXNoLiBJZiBhbGwgaW5mb3JtYXRpb24gaXMgaW5zaWRlIHRoZSBlbmNyeXB0ZWQgdHVubmVs LCBhcmUgd2UganVzdCBzYXlpbmcg4oCcZW5kIHVzZXINCiBhbmQgYXBwbGljYXRpb24gc3VwcG9y dCBwZXJzb24sIHlvdSBmaWd1cmUgaXQgb3V0P+KAnSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoaXMgc2VlbXMgbGlrZSBhIGh1Z2UgcHJvYmxlbS4gJm5ic3A7SSBtZWFuIHRoZSBu ZXR3b3JrIGRvZXMgbm90IGFsd2F5cyB3b3JrIGZsYXdsZXNzbHkgYW5kIGl0IHNlZW1zIGxpa2Ug d2UgYXJlIHJlbW92aW5nIGFsbCB0aGUgYWJpbGl0aWVzIGZvciBuZXR3b3JrIG9wZXJhdG9ycyB0 byBlbnN1cmUgYW55IGxldmVsIG9mIFNMQSBvciBPTEEuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJyZXQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1 cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIG15IENvbW1vZG9yZSAxMjhEPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBHUCBGaW5nZXJwcmludDombmJzcDs2M0I0IEZDNTMgNjgwQSA2QjdE IDE0NDcgJm5ic3A7RjJDMCA3NEY4IEFDQUUmbmJzcDs8YSBocmVmPSJ0ZWw6NzQxNSUyMDAwNTAi Pjc0MTUgMDA1MDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjxQUkU+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVz c2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRp b25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBh cyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBT aSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25h bGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpv aW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2Fs dGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3Nh Z2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxl Z2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u LgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4K QXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2Fn ZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5 b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E9B0OPEXCLILM44corp_-- From nobody Tue Nov 14 22:22: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 DB0C212702E for ; Tue, 14 Nov 2017 22:22:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 ME5w2FqEubdO for ; Tue, 14 Nov 2017 22:22:53 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0102.outbound.protection.outlook.com [104.47.41.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADA621243F6 for ; Tue, 14 Nov 2017 22:22:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nX8QciqPxqHMS+5AhX0WYJvW7+fZHP1bU+Hy8cERiwY=; b=KWy9vZyjMOEpSMZeA0lDuLqPNeTOyMwid8K/4QhHr5efiOYgW7+NCCUHsnGHBned1p/UZu9CFRGBwfYBlJMzXP9Ld65dArY85jJvldDQ9dJxpdG4Wph/UNLwFYpsQQOtVpMqMGCj9lIje3Q/aiM3U3esfMyybpSy+CcBqMDkbk4= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 15 Nov 2017 06:22:51 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0239.005; Wed, 15 Nov 2017 06:22:51 +0000 From: Mike Bishop To: Roni Even , QUIC WG Subject: RE: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQAAPS1iAAAgH6gA== Date: Wed, 15 Nov 2017 06:22:50 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2001:67c:1232:144:dfa:b055:a7a4:3c40] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2432; 6:bPY7OPqH7olwBX6lt/PvYZ6RSio1LuhxRbjTKtjO2z9ayRaFTMjTC3MVBjPLWzQLaBUocQCSlctkmOO/kLBH65FSETcUxhXSo6LmZp0GoaPQZ6jvYEJxjCkqeyyBna4C03csvgph8bdtFEWfA4rhATInhQxYqdkFvjPIXHYfwMcMRcUIYF5CH2XLJ67bAljz8ZxvdUk0pU6rN57O2VkVMM89Qu7nCOwWD1dKvFHXehGtiVxQVQY/B5D4rEOixX7SHK5UVG03IL3J9/HcRVFYYC6seYnyUez0o1ApVcHvVPtIopICYqqO0VtwGTGKkvDbuvRm/uVb4VIeU3CoUePmOqRvvgJhyxHBSoYcuNze61w=; 5:h6VZq4ytE4JkqMgiTjMVqQtu04qRYsh+VO1AqzkHb/+CC32uSL0UOZ4ke/IdSNFBD1lb8Ib7vSuxFltRsSzYe76JWD5Cj+ye2TeBkxkZBbx04UwAdTMr7uAfzDLco0Otg3LI/quOQEkntbttKn2XC6BscCni0vAPZlmiunlgxJY=; 24:IoYmqF6awUc09Qusf/ntzAPE32N+3r0N6SFN0Xajhk6C0vcRCggDephlf7NHlbMnrRgytbwPIqjK56zLJHOcPeeqkfRc8hX282CgLkOb87Y=; 7:Qyn2TFG5Ep9SiFZEoPJpjfQwGoufXYfFvqxblS3UyBt8LZ/Fn+cRtd3k/Gpq8vl4wgqahZRVz1Jpo4ZQRiTKlECPkvGS+1SJwnciVBNm4P5wxg63TkuZ1CEtCjMyqPJAL9/8EvVM3dMi3OQRfbEFR2aBYiXJ8VOMNVsEK73ckGBT3kQZO6zMIhJ3eP1IbGgdt5wg4Hq+8u5qjj6Gn0pqzdGWEiXMu4Nmq1zwFA/fzGI1GY66rvB3HuCv7sqIJOQX x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: baf2da7d-87a7-4e2a-1738-08d52bf14c5b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603199); SRVR:MWHPR08MB2432; x-ms-traffictypediagnostic: MWHPR08MB2432: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(50582790962513)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(93006095)(93001095)(3231022)(3002001)(10201501046)(6041248)(20161123558100)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(2016111802025)(20161123564025)(20161123555025)(20161123560025)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2432; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2432; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39830400002)(189002)(199003)(86362001)(77096006)(25786009)(33656002)(74316002)(229853002)(105586002)(106356001)(6436002)(6506006)(54896002)(6306002)(236005)(9686003)(102836003)(478600001)(53936002)(2900100001)(790700001)(6116002)(8676002)(81156014)(81166006)(6246003)(8936002)(55016002)(7736002)(97736004)(74482002)(3480700004)(7116003)(19609705001)(5660300001)(221733001)(53546010)(99286004)(14454004)(3660700001)(316002)(110136005)(3280700002)(68736007)(2906002)(50986999)(189998001)(7696004)(54356999)(76176999)(101416001)(2950100002)(111123002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2432; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB24329EDF1A8C660D2F715A7CDA290MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: baf2da7d-87a7-4e2a-1738-08d52bf14c5b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 06:22:50.8444 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2432 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:22:56 -0000 --_000_MWHPR08MB24329EDF1A8C660D2F715A7CDA290MWHPR08MB2432namp_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Exactly the same way that TCP-to-TCP handoff between these interfaces works= today, because (non-MP) TCP isn=92t capable of changing to a different int= erface. We=92re trying to build a better answer, but you=92re positing fro= m the start that connection migration fails, so we=92re now in =93no worse= =94 land. The QUIC stack in the client device will see a new interface is available. = It attempts to switch to it, because of some local policy. The transition= fails for whatever reason, but the cellular connection is still active. I= t is the application=92s choice whether it wants to wind down and close tha= t connection and start a new one using TCP, or keep using the old one if th= e interface remains available. If there are multiple applications, each ap= plication makes that choice independently. And if the first interface becomes unavailable for whatever reason, the cho= ice is made for it, and the application will have to recover. From: Roni Even [mailto:roni.even@huawei.com] Sent: Wednesday, November 15, 2017 1:25 PM To: Mike Bishop ; QUIC WG Subject: RE: connection migration So what is the connection migration flow here. The quic stack in the cell n= etwork will try to migrate to wifi without application request and fail but= will not fall back to TCP. There may be multiple application running over quic? HTTP and peer to peer = at the same time, so who will handle this case? Roni From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 05:35 To: Roni Even; QUIC WG Subject: RE: connection migration That may well be the case, but it=92s not the QUIC stack=92s choice to make= . The application could choose to open a new connection, but that remains = outside the scope of the transport and the mapping to it which we=92re defi= ning. For HTTP, this is fairly straightforward =96 it could stop issuing new flow= control credit, let currently-in-transit data arrive and any losses recove= red, and open a TCP connection to issue a range request starting at whateve= r data offset it hasn=92t seen. But that=92s still a property of an HTTP m= anagement above the HTTP/QUIC mapping. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, November 15, 2017 11:25 AM To: QUIC WG > Subject: connection migration Hi, When moving from cell to wifi the reason may be due to cost (money or quota= ). In this case the user (client) may want to move to wifi even if it will= mean dropping to TCP. Roni --_000_MWHPR08MB24329EDF1A8C660D2F715A7CDA290MWHPR08MB2432namp_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Exactly the same way that TCP-to-TCP handoff between= these interfaces works today, because (non-MP) TCP isn=92t capable of chan= ging to a different interface.  We=92re trying to build a better answe= r, but you=92re positing from the start that connection migration fails, so we=92re now in =93no worse=94 land.

 

The QUIC stack in the client device will see a new i= nterface is available.  It attempts to switch to it, because of some l= ocal policy.  The transition fails for whatever reason, but the cellul= ar connection is still active.  It is the application=92s choice whether it wants to wind down and close that connection and start a= new one using TCP, or keep using the old one if the interface remains avai= lable.  If there are multiple applications, each application makes tha= t choice independently.

 

And if the first interface becomes unavailable for w= hatever reason, the choice is made for it, and the application will have to= recover.

 

From: Roni Even [mailto:roni.even@huawei.com]=
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.= org>
Subject: RE: connection migration

 

So what is the connect= ion migration flow here. The quic stack in the cell network will try to mig= rate to wifi without application request and fail but will not fall back to= TCP.

There may be multiple = application running over quic? HTTP and peer to peer at the same time, so w= ho will handle this case?

 

Roni=

 

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 05:35
To: Roni Even; QUIC WG
Subject: RE: connection migration

 

That may well be the case, but it=92s not the QUIC s= tack=92s choice to make.  The application could choose to open a new c= onnection, but that remains outside the scope of the transport and the mapp= ing to it which we=92re defining.

 

For HTTP, this is fairly straightforward =96 it coul= d stop issuing new flow control credit, let currently-in-transit data arriv= e and any losses recovered, and open a TCP connection to issue a range requ= est starting at whatever data offset it hasn=92t seen.  But that=92s still a property of an HTTP managemen= t above the HTTP/QUIC mapping.

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <quic@ietf.org&g= t;
Subject: connection migration

 

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the  user (client) may want to = move to wifi even if it will mean dropping to TCP.

 

Roni

--_000_MWHPR08MB24329EDF1A8C660D2F715A7CDA290MWHPR08MB2432namp_-- From nobody Tue Nov 14 22:40: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 99FE4129510 for ; Tue, 14 Nov 2017 22:40:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 yf90MVwiCqYf for ; Tue, 14 Nov 2017 22:40:33 -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 1E5F61294CF for ; Tue, 14 Nov 2017 22:40:33 -0800 (PST) Received: from dhcp-8a57.meeting.ietf.org (unknown [IPv6:2001:67c:370:128:2094:13f3:30e5:c12d]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 3CB511B003A0; Wed, 15 Nov 2017 06:40:09 +0000 (GMT) Message-ID: <5A0BE148.4020308@erg.abdn.ac.uk> Date: Wed, 15 Nov 2017 14:40:08 +0800 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Piotr Galecki CC: "MORTON, ALFRED C (AL)" , Ian Swett , QUIC WG , "emile.stephan@orange.com" Subject: Re: spin bit in QUIC: troubleshooting References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> <5A0BD528.3040106@erg.abdn.ac.uk> <2C515BE8694C6F4B9B6A578BCAC32E2F83AC9673@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: <2C515BE8694C6F4B9B6A578BCAC32E2F83AC9673@MBX021-W3-CA-2.exch021.domain.local> 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.22 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 Nov 2017 06:40:36 -0000 I think (even pathological) reordering would be largely undetected with 1-bit. Since in thsi case, the bit simply flips 1->0 and 0->1, With 2 bits the first flip is 0->1 and then the next RTT , the flip is 1->2, then re-ordering of the spin may become detectable. It's not perfect, but you may see some pathologies for low additional cost. ACK visibility is needed for some of the things below. Gorry On 15/11/2017, 13:59, Piotr Galecki wrote: > How would a network probe be able to measure the level of packet reordering in QUIC stream with only a spin bit? > > I'm asking because one of the common techniques to diagnose network issues > is to insert a probe in different points in the network and measure: > * RTT > * TCP segment loss > * TCP segment retransmissions > * TCP segment out-of-order > as a few basic data points. > With measurements in point A and point B one can determine for example if a network device is misordering packets. > > -Piotr > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: Wednesday, November 15, 2017 12:48 AM > To: MORTON, ALFRED C (AL) > Cc: Ian Swett; QUIC WG; emile.stephan@orange.com > Subject: Re: spin bit in QUIC: troubleshooting > > As I said at the mic: I think the spin-bit analysis was helpful, thanks. > > I can see how spin-bit is really useful to get basic diagnostics of RTT if it can be relied to be present in every packet. (It is important to measure latency within the network). > > There are places where 1-bit gives restricted value, and using more would help: My additional comment at the Mic related to how much extra would be the gain from an additional one or two bits? > > In particular, I'd like to see a method that can let me detect some loss patterns and measure reordering, at least I think it is important to know and measure when there is small-scale reordering<3. > > A suggestion:is to use a 2-bit counter for the spin ( > 00->01->10->11->00), that would help detect these path anomlies. > > Gorry > > On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote: >> I’d like to offer support for Spin Bit (and one or two >> >> bits for management if they can be justified quickly) in v1. >> >> On this topic of more bits, >> >> asking further clarification from Emile, below [ACM]. >> >> Al >> >> *From:*QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett >> *Sent:* Tuesday, November 14, 2017 4:21 PM >> *To:* emile.stephan@orange.com >> *Cc:* QUIC WG >> *Subject:* Re: spin bit in QUIC: troubleshooting >> >> Thanks for clarifying Emile. >> >> On Tue, Nov 14, 2017 at 1:06 PM,> > wrote: >> >> Hi Ian, >> >> It was suggested in the latest discussion on the RTT design team >> mailing list to have one bit for packet lost, one for latency (spin >> bit or eq.) and one for congestion. >> >> */[ACM] /* There may be some overlap with ECN and « one bit for >> congestion ». >> >> Did you also consider this dependency, Emile ? (I’m echoing a hallway >> discussion) >> >> It seems a simplistic approach on one hand but an invariant on the >> long term. >> >> Regards >> >> Emile >> >> *De :*Ian Swett [mailto:ianswett@google.com >> ] *Envoyé :* mardi 14 novembre 2017 22:51 >> *À :* STEPHAN Emile IMT/OLN *Cc :* QUIC WG *Objet :* Re: spin bit in >> QUIC: troubleshooting >> >> What would the other bit or two be used for? If there is no >> standardized use of those bits in v1, then I believe we should wait to >> reserve them when their usage is defined, given we'd need a version >> bump to specify how they were being used. At the moment, the >> management use case is not competing with anyone else for bits in the >> short header. >> >> On Tue, Nov 14, 2017 at 5:14 AM,> > wrote: >> >> Hi >> >> Last week Orange experienced a fallback of QUIC to TCP on one of its >> networks. The issues were not visible in QUIC traffic. The >> troubleshooting was made using TCP packets information. This is not >> sustainable on the long term when numerous applications using >> different versions of QUIC will stop to fallback to TCP. >> >> Based on the exchange we had in the RTT design team and in today >> meeting , it sounds reasonable to reserve at least 2 bits (ideally 3 >> bits as discussed in the design team) for manageability in the QUIC >> invariants and to start experimenting the spin bit in QUIC V1. >> >> Regards >> >> Emile >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> >> ______________________________________________________________________ >> ___________________________________________________ >> >> Ce message et ses pieces jointes peuvent contenir des informations >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> exploites ou copies sans autorisation. Si vous avez recu ce message >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. >> >> This message and its attachments may contain confidential or >> privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. >> Thank you. >> From nobody Tue Nov 14 23:03: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 DA9C8127B60 for ; Tue, 14 Nov 2017 23:03:27 -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, 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 FEmyKGBPBT34 for ; Tue, 14 Nov 2017 23:03:25 -0800 (PST) Received: from mx01.telecomitalia.it (mx01.telecomitalia.it [217.169.121.10]) (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 9FF2E12952D for ; Tue, 14 Nov 2017 23:03:24 -0800 (PST) X-AuditID: d9a9790a-badff70000005327-59-5a0be6ba59a5 Received: from TELMBXA06RM001.telecomitalia.local ( [10.14.252.34]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx01.telecomitalia.it () with SMTP id E7.CD.21287.AB6EB0A5; Wed, 15 Nov 2017 08:03:22 +0100 (CET) From: Fioccola Giuseppe To: "gorry@erg.abdn.ac.uk" , Piotr Galecki CC: Ian Swett , QUIC WG , "MORTON, ALFRED C (AL)" , "emile.stephan@orange.com" Subject: R: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFwAHmowAAAeL0sAABhIoAAAJd4YAAAhCegAAAGZfgAABaCkAAAKzrDA= Date: Wed, 15 Nov 2017 07:03:21 +0000 Message-ID: References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> <5A0BD528.3040106@erg.abdn.ac.uk> <2C515BE8694C6F4B9B6A578BCAC32E2F83AC9673@MBX021-W3-CA-2.exch021.domain.local> <5A0BE148.4020308@erg.abdn.ac.uk> In-Reply-To: <5A0BE148.4020308@erg.abdn.ac.uk> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.248] x-ti-disclaimer: Disclaimer1 Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrCKsWRmVeSWpSXmKPExsXCxfdHSXfXM+4og1ftShZbj01ktDi4/weL xeu22YwWP+/tZLX4cO0+o0XPAm4HNo8XV54xe7zsn8Po0fP5BZPHgk2lHkuW/GTyaHl2ki2A LaqB0SYxLy+/JLEkVSEltTjZVsklszg5JzEzN7VIISQ1JzU5P1dJITPFVslYSaEgJzE5NTc1 r8RWKbGgIDUvRcmOSwED2ACVZeYppOYl56dk5qXbKnkG++taWJha6hoq2QWWphaX5CvkphYX J6anZ+YrpCasF8xY0fuIqeCDb0XDw/mMDYwfvLsYOTkkBEwkTs59xwpiCwlMYZI42ykCYrMJ 2EgcfHWCrYuRg0NEIF3i52vGLkYuDmaBxYwSx3dOZwGpERbQlfj1+DcjiC0ioC8xa/ItKDtJ YsaSqWA2i4CqxO7e8ywgc3gFAiXOtDiCzBES+MwicXP+GbC9nAJ6Eg8vbGEDsRkFZCUm7F4E 1sssIC7xYvoJdog7BSSW7DnPDGGLSrx8/I8VwjaQ2Lp0HwuErSgxacVvqHoZiYVHJrOC7GUW 0JRYv0sfYqSixJTuh2AlvAKCEidnPmGZwCg2C8m2WQgds5B0zELSsYCRZRWjaG6FgaFeCSTy MksSczIT9TJLNjECk87NlZVcOxhfr3I+xCjAwajEw/vgPHeUEGtiWXFl7iFGCQ5mJRHe5H6g EG9KYmVValF+fFFpTmrxIUYfYHhNZJYSTc4HJsS8knhDEwtLQ2MLCyNDCzNTHMJK4ryJL7ii hATSgakrOzW1ILUIZhwTB6dUA+O5q3NSGCKmlvsvPtqsv0aj/Xr1HVk2jqhVjTJ7r/J/mfqD wYOnbLdAbbb5o0LG5zpLM9jrzfjvdd+s/ua4qny26e6EvzvmK56b+vsHT+vNVrm+6OUr3xkY deev3ZDpNWcl7x3eoLhvQZu+3A53X9K56VTIksy28Mg4n1frljGtl2qd8qbHUECJpTgj0VCL uag4EQDmaxSTZwMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:03:28 -0000 Z29vZCB3YXkgdG8gbWVhc3VyZSB0aGUgcmVvcmRlcmluZyB3aXRoIDEgb3IgMiBiaXRzLg0K SW4gYWRkaXRpb24sIHRvIGFuc3dlciB0aGUgcHJldmlvdXMgcXVlc3Rpb24sIGRyYWZ0LWll dGYtaXBwbS1hbHQtbWFyayBzdWdnZXN0cyBob3cgdG8gdXNlIDEgb3IgMiBiaXRzIGZvciBw YWNrZXQgbG9zcyBhbmQgIFJUVCBjYWxjdWxhdGlvbi4NCg0KR2l1c2VwcGUNCg0KLS0tLS1N ZXNzYWdnaW8gb3JpZ2luYWxlLS0tLS0NCkRhOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnXSBQZXIgY29udG8gZGkgR29ycnkgRmFpcmh1cnN0DQpJbnZpYXRvOiBtZXJj b2xlZMOsIDE1IG5vdmVtYnJlIDIwMTcgMDc6NDANCkE6IFBpb3RyIEdhbGVja2kNCkNjOiBJ YW4gU3dldHQ7IFFVSUMgV0c7IE1PUlRPTiwgQUxGUkVEIEMgKEFMKTsgZW1pbGUuc3RlcGhh bkBvcmFuZ2UuY29tDQpPZ2dldHRvOiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJsZXNo b290aW5nDQoNCkkgdGhpbmsgKGV2ZW4gcGF0aG9sb2dpY2FsKSByZW9yZGVyaW5nIHdvdWxk IGJlIGxhcmdlbHkgdW5kZXRlY3RlZCB3aXRoIDEtYml0LiBTaW5jZSBpbiB0aHNpIGNhc2Us IHRoZSBiaXQgc2ltcGx5IGZsaXBzIDEtPjAgYW5kIDAtPjEsDQoNCldpdGggMiBiaXRzIHRo ZSBmaXJzdCBmbGlwIGlzIDAtPjEgYW5kIHRoZW4gdGhlIG5leHQgUlRUICwgdGhlIGZsaXAg aXMgDQoxLT4yLCB0aGVuIHJlLW9yZGVyaW5nIG9mIHRoZSBzcGluIG1heSBiZWNvbWUgZGV0 ZWN0YWJsZS4gSXQncyBub3QNCnBlcmZlY3QsIGJ1dCB5b3UgbWF5IHNlZSBzb21lIHBhdGhv bG9naWVzIGZvciBsb3cgYWRkaXRpb25hbCBjb3N0Lg0KDQpBQ0sgdmlzaWJpbGl0eSBpcyBu ZWVkZWQgZm9yIHNvbWUgb2YgdGhlIHRoaW5ncyBiZWxvdy4NCg0KR29ycnkNCg0KT24gMTUv MTEvMjAxNywgMTM6NTksIFBpb3RyIEdhbGVja2kgd3JvdGU6DQo+IEhvdyB3b3VsZCBhIG5l dHdvcmsgcHJvYmUgYmUgYWJsZSB0byBtZWFzdXJlIHRoZSBsZXZlbCBvZiBwYWNrZXQgcmVv cmRlcmluZyBpbiBRVUlDIHN0cmVhbSB3aXRoIG9ubHkgYSBzcGluIGJpdD8NCj4NCj4gSSdt IGFza2luZyBiZWNhdXNlIG9uZSBvZiB0aGUgY29tbW9uIHRlY2huaXF1ZXMgdG8gZGlhZ25v c2UgbmV0d29yayBpc3N1ZXMNCj4gaXMgdG8gaW5zZXJ0IGEgcHJvYmUgaW4gZGlmZmVyZW50 IHBvaW50cyBpbiB0aGUgbmV0d29yayBhbmQgbWVhc3VyZToNCj4gKiBSVFQNCj4gKiBUQ1Ag c2VnbWVudCBsb3NzDQo+ICogVENQIHNlZ21lbnQgcmV0cmFuc21pc3Npb25zDQo+ICogVENQ IHNlZ21lbnQgb3V0LW9mLW9yZGVyDQo+IGFzIGEgZmV3IGJhc2ljIGRhdGEgcG9pbnRzLg0K PiBXaXRoIG1lYXN1cmVtZW50cyBpbiBwb2ludCBBIGFuZCBwb2ludCBCIG9uZSBjYW4gZGV0 ZXJtaW5lIGZvciBleGFtcGxlIGlmIGEgbmV0d29yayBkZXZpY2UgaXMgbWlzb3JkZXJpbmcg cGFja2V0cy4NCj4NCj4gLVBpb3RyDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+IEZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBHb3JyeSBGYWlyaHVyc3QNCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwg MjAxNyAxMjo0OCBBTQ0KPiBUbzogTU9SVE9OLCBBTEZSRUQgQyAoQUwpPGFjbW9ydG9uQGF0 dC5jb20+DQo+IENjOiBJYW4gU3dldHQ8aWFuc3dldHRAZ29vZ2xlLmNvbT47IFFVSUMgV0c8 cXVpY0BpZXRmLm9yZz47IGVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbQ0KPiBTdWJqZWN0OiBS ZTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJsZXNob290aW5nDQo+DQo+IEFzIEkgc2FpZCBh dCB0aGUgbWljOiBJIHRoaW5rIHRoZSBzcGluLWJpdCBhbmFseXNpcyB3YXMgaGVscGZ1bCwg dGhhbmtzLg0KPg0KPiBJIGNhbiBzZWUgaG93IHNwaW4tYml0IGlzIHJlYWxseSB1c2VmdWwg dG8gZ2V0IGJhc2ljIGRpYWdub3N0aWNzIG9mIFJUVCBpZiBpdCBjYW4gYmUgcmVsaWVkIHRv IGJlIHByZXNlbnQgaW4gZXZlcnkgcGFja2V0LiAoSXQgaXMgaW1wb3J0YW50IHRvIG1lYXN1 cmUgbGF0ZW5jeSB3aXRoaW4gdGhlIG5ldHdvcmspLg0KPg0KPiBUaGVyZSBhcmUgcGxhY2Vz IHdoZXJlIDEtYml0IGdpdmVzIHJlc3RyaWN0ZWQgdmFsdWUsIGFuZCB1c2luZyBtb3JlIHdv dWxkIGhlbHA6IE15IGFkZGl0aW9uYWwgY29tbWVudCBhdCB0aGUgTWljIHJlbGF0ZWQgdG8g aG93IG11Y2ggZXh0cmEgd291bGQgYmUgdGhlIGdhaW4gZnJvbSBhbiBhZGRpdGlvbmFsIG9u ZSBvciB0d28gYml0cz8NCj4NCj4gSW4gcGFydGljdWxhciwgSSdkIGxpa2UgdG8gc2VlIGEg bWV0aG9kIHRoYXQgY2FuIGxldCBtZSBkZXRlY3Qgc29tZSBsb3NzIHBhdHRlcm5zIGFuZCBt ZWFzdXJlIHJlb3JkZXJpbmcsIGF0IGxlYXN0IEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRv IGtub3cgYW5kIG1lYXN1cmUgd2hlbiB0aGVyZSBpcyBzbWFsbC1zY2FsZSByZW9yZGVyaW5n PDMuDQo+DQo+IEEgc3VnZ2VzdGlvbjppcyB0byB1c2UgYSAyLWJpdCBjb3VudGVyIGZvciB0 aGUgc3BpbiAoDQo+IDAwLT4wMS0+MTAtPjExLT4wMCksIHRoYXQgd291bGQgaGVscCBkZXRl Y3QgdGhlc2UgcGF0aCBhbm9tbGllcy4NCj4NCj4gR29ycnkNCj4NCj4gT24gMTUvMTEvMjAx NywgMDk6NTEsIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSB3cm90ZToNCj4+IEnigJlkIGxpa2Ug dG8gb2ZmZXIgc3VwcG9ydCBmb3IgU3BpbiBCaXQgKGFuZCBvbmUgb3IgdHdvDQo+Pg0KPj4g Yml0cyBmb3IgbWFuYWdlbWVudCBpZiB0aGV5IGNhbiBiZSBqdXN0aWZpZWQgcXVpY2tseSkg aW4gdjEuDQo+Pg0KPj4gT24gdGhpcyB0b3BpYyBvZiBtb3JlIGJpdHMsDQo+Pg0KPj4gYXNr aW5nIGZ1cnRoZXIgY2xhcmlmaWNhdGlvbiBmcm9tIEVtaWxlLCBiZWxvdyBbQUNNXS4NCj4+ DQo+PiBBbA0KPj4NCj4+ICpGcm9tOipRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnXSAqT24gQmVoYWxmIE9mICpJYW4gU3dldHQNCj4+ICpTZW50OiogVHVlc2RheSwgTm92 ZW1iZXIgMTQsIDIwMTcgNDoyMSBQTQ0KPj4gKlRvOiogZW1pbGUuc3RlcGhhbkBvcmFuZ2Uu Y29tDQo+PiAqQ2M6KiBRVUlDIFdHDQo+PiAqU3ViamVjdDoqIFJlOiBzcGluIGJpdCBpbiBR VUlDOiB0cm91Ymxlc2hvb3RpbmcNCj4+DQo+PiBUaGFua3MgZm9yIGNsYXJpZnlpbmcgRW1p bGUuDQo+Pg0KPj4gT24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgMTowNiBQTSw8ZW1pbGUuc3Rl cGhhbkBvcmFuZ2UuY29tDQo+PiA8bWFpbHRvOmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbT4+ ICB3cm90ZToNCj4+DQo+PiBIaSBJYW4sDQo+Pg0KPj4gSXQgd2FzIHN1Z2dlc3RlZCBpbiB0 aGUgbGF0ZXN0IGRpc2N1c3Npb24gb24gdGhlIFJUVCBkZXNpZ24gdGVhbQ0KPj4gbWFpbGlu ZyBsaXN0IHRvIGhhdmUgb25lIGJpdCBmb3IgcGFja2V0IGxvc3QsIG9uZSBmb3IgbGF0ZW5j eSAoc3Bpbg0KPj4gYml0IG9yIGVxLikgYW5kIG9uZSBmb3IgY29uZ2VzdGlvbi4NCj4+DQo+ PiAqL1tBQ01dIC8qIFRoZXJlIG1heSBiZSBzb21lIG92ZXJsYXAgd2l0aCBFQ04gYW5kIMKr IG9uZSBiaXQgZm9yDQo+PiBjb25nZXN0aW9uIMK7Lg0KPj4NCj4+IERpZCB5b3UgYWxzbyBj b25zaWRlciB0aGlzIGRlcGVuZGVuY3ksIEVtaWxlID8gKEnigJltIGVjaG9pbmcgYSBoYWxs d2F5DQo+PiBkaXNjdXNzaW9uKQ0KPj4NCj4+IEl0IHNlZW1zIGEgc2ltcGxpc3RpYyBhcHBy b2FjaCBvbiBvbmUgaGFuZCBidXQgYW4gaW52YXJpYW50IG9uIHRoZQ0KPj4gbG9uZyB0ZXJt Lg0KPj4NCj4+IFJlZ2FyZHMNCj4+DQo+PiBFbWlsZQ0KPj4NCj4+ICpEZSA6KklhbiBTd2V0 dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20NCj4+IDxtYWlsdG86aWFuc3dldHRAZ29v Z2xlLmNvbT5dICpFbnZvecOpIDoqIG1hcmRpIDE0IG5vdmVtYnJlIDIwMTcgMjI6NTENCj4+ ICrDgCA6KiBTVEVQSEFOIEVtaWxlIElNVC9PTE4gKkNjIDoqIFFVSUMgV0cgKk9iamV0IDoq IFJlOiBzcGluIGJpdCBpbg0KPj4gUVVJQzogdHJvdWJsZXNob290aW5nDQo+Pg0KPj4gV2hh dCB3b3VsZCB0aGUgb3RoZXIgYml0IG9yIHR3byBiZSB1c2VkIGZvcj8gIElmIHRoZXJlIGlz IG5vDQo+PiBzdGFuZGFyZGl6ZWQgdXNlIG9mIHRob3NlIGJpdHMgaW4gdjEsIHRoZW4gSSBi ZWxpZXZlIHdlIHNob3VsZCB3YWl0IHRvDQo+PiByZXNlcnZlIHRoZW0gd2hlbiB0aGVpciB1 c2FnZSBpcyBkZWZpbmVkLCBnaXZlbiB3ZSdkIG5lZWQgYSB2ZXJzaW9uDQo+PiBidW1wIHRv IHNwZWNpZnkgaG93IHRoZXkgd2VyZSBiZWluZyB1c2VkLiAgQXQgdGhlIG1vbWVudCwgdGhl DQo+PiBtYW5hZ2VtZW50IHVzZSBjYXNlIGlzIG5vdCBjb21wZXRpbmcgd2l0aCBhbnlvbmUg ZWxzZSBmb3IgYml0cyBpbiB0aGUNCj4+IHNob3J0IGhlYWRlci4NCj4+DQo+PiBPbiBUdWUs IE5vdiAxNCwgMjAxNyBhdCA1OjE0IEFNLDxlbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20NCj4+ IDxtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPj4gIHdyb3RlOg0KPj4NCj4+IEhp DQo+Pg0KPj4gTGFzdCB3ZWVrIE9yYW5nZSBleHBlcmllbmNlZCBhIGZhbGxiYWNrIG9mIFFV SUMgdG8gVENQIG9uIG9uZSBvZiBpdHMNCj4+IG5ldHdvcmtzLiBUaGUgaXNzdWVzIHdlcmUg bm90IHZpc2libGUgaW4gUVVJQyB0cmFmZmljLiBUaGUNCj4+IHRyb3VibGVzaG9vdGluZyB3 YXMgbWFkZSB1c2luZyBUQ1AgcGFja2V0cyBpbmZvcm1hdGlvbi4gVGhpcyBpcyBub3QNCj4+ IHN1c3RhaW5hYmxlIG9uIHRoZSBsb25nIHRlcm0gd2hlbiBudW1lcm91cyBhcHBsaWNhdGlv bnMgdXNpbmcNCj4+IGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdpbGwgc3RvcCB0byBm YWxsYmFjayB0byBUQ1AuDQo+Pg0KPj4gQmFzZWQgb24gdGhlIGV4Y2hhbmdlIHdlIGhhZCBp biB0aGUgUlRUIGRlc2lnbiB0ZWFtIGFuZCBpbiB0b2RheQ0KPj4gbWVldGluZyAsIGl0IHNv dW5kcyByZWFzb25hYmxlIHRvIHJlc2VydmUgYXQgbGVhc3QgMiBiaXRzIChpZGVhbGx5IDMN Cj4+IGJpdHMgYXMgZGlzY3Vzc2VkIGluIHRoZSBkZXNpZ24gdGVhbSkgZm9yIG1hbmFnZWFi aWxpdHkgaW4gdGhlIFFVSUMNCj4+IGludmFyaWFudHMgYW5kIHRvIHN0YXJ0IGV4cGVyaW1l bnRpbmcgdGhlIHNwaW4gYml0IGluIFFVSUMgVjEuDQo+Pg0KPj4gUmVnYXJkcw0KPj4NCj4+ IEVtaWxlDQo+Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+Pg0KPj4gQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25z DQo+PiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YyBwYXMgZXRyZSBkaWZmdXNlcywNCj4+IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRv cmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UNCj4+IHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFp bnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRl IHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91 IGZhbHNpZmllLiBNZXJjaS4NCj4+DQo+PiBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3INCj4+IHByaXZpbGVnZWQgaW5mb3Jt YXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJl IGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+ PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90 aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy4NCj4+IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFi bGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC4NCj4+IFRoYW5rIHlvdS4NCj4+DQo+PiBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+PiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ DQo+PiBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMNCj4+IGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMg ZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRpZmZ1c2VzLA0KPj4gZXhwbG9pdGVzIG91 IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2Fn ZQ0KPj4gcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIg ZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3Nh Z2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwgT3Jh bmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBh bHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLg0KPj4NCj4+IFRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPj4g cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0 aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQg YXV0aG9yaXNhdGlvbi4NCj4+IElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4g ZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KPj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZp ZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4gVGhhbmsgeW91Lg0KPj4NCg0KDQpRdWVz dG8gbWVzc2FnZ2lvIGUgaSBzdW9pIGFsbGVnYXRpIHNvbm8gaW5kaXJpenphdGkgZXNjbHVz aXZhbWVudGUgYWxsZSBwZXJzb25lIGluZGljYXRlLiBMYSBkaWZmdXNpb25lLCBjb3BpYSBv IHF1YWxzaWFzaSBhbHRyYSBhemlvbmUgZGVyaXZhbnRlIGRhbGxhIGNvbm9zY2VuemEgZGkg cXVlc3RlIGluZm9ybWF6aW9uaSBzb25vIHJpZ29yb3NhbWVudGUgdmlldGF0ZS4gUXVhbG9y YSBhYmJpYXRlIHJpY2V2dXRvIHF1ZXN0byBkb2N1bWVudG8gcGVyIGVycm9yZSBzaWV0ZSBj b3J0ZXNlbWVudGUgcHJlZ2F0aSBkaSBkYXJuZSBpbW1lZGlhdGEgY29tdW5pY2F6aW9uZSBh bCBtaXR0ZW50ZSBlIGRpIHByb3Z2ZWRlcmUgYWxsYSBzdWEgZGlzdHJ1emlvbmUsIEdyYXpp ZS4gDQoNClRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFs IGFuZCBtYXkgY29udGFpbiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0 aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERpc3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5n IG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMgdW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5v dCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBh bmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSByZXR1cm4gZS1t YWlsLCBUaGFua3MuIA0KDQpSaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVl c3RhIG1haWwgc2Ugbm9uIMOoIG5lY2Vzc2FyaW8uDQo= From nobody Tue Nov 14 23:12: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 3C27812947C for ; Tue, 14 Nov 2017 23:12:56 -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 JjjJcjFGgx3e for ; Tue, 14 Nov 2017 23:12:53 -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 12A4C127B60 for ; Tue, 14 Nov 2017 23:12:53 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 2BDA4340EA2; Wed, 15 Nov 2017 08:12:51 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.28997); Wed, 15 Nov 2017 08:12:49 +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; Wed, 15 Nov 2017 08:12:48 +0100 (CET) Received: from [111.223.75.82] (account ietf@trammell.ch HELO [192.168.26.129]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 36026796; Wed, 15 Nov 2017 08:12:48 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_5D37D940-7CEB-4D36-BECC-23112AA1EF2D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: spin bit in QUIC: troubleshooting Date: Wed, 15 Nov 2017 15:12:43 +0800 In-Reply-To: <5A0BE148.4020308@erg.abdn.ac.uk> Cc: Piotr Galecki , Ian Swett , QUIC WG , Al Morton , "emile.stephan@orange.com" To: Gorry Fairhurst References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> <5A0BD528.3040106@erg.abdn.ac.uk> <2C515BE8694C6F4B9B6A578BCAC32E2F83AC9673@MBX021-W3-CA-2.exch021.domain.local> <5A0BE148.4020308@erg.abdn.ac.uk> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:12:56 -0000 --Apple-Mail=_5D37D940-7CEB-4D36-BECC-23112AA1EF2D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Gorry, Piotr, all, > On 15 Nov 2017, at 14:40, Gorry Fairhurst = wrote: >=20 > I think (even pathological) reordering would be largely undetected = with 1-bit. Since in thsi case, the bit simply flips 1->0 and 0->1, >=20 > With 2 bits the first flip is 0->1 and then the next RTT , the flip is = 1->2, then re-ordering of the spin may become detectable. It's not = perfect, but you may see some pathologies for low additional cost. >=20 > ACK visibility is needed for some of the things below. Only for RTX as far as I can tell, and RTX works fundamentally = differently in QUIC, so I'm not sure it's useful; see below. >=20 > Gorry >=20 > On 15/11/2017, 13:59, Piotr Galecki wrote: >> How would a network probe be able to measure the level of packet = reordering in QUIC stream with only a spin bit? >>=20 >> I'm asking because one of the common techniques to diagnose network = issues >> is to insert a probe in different points in the network and measure: >> * RTT This is the spin bit (whether one bit, or two bits as gorry suggests) >> * TCP segment loss >> * TCP segment retransmissions RTX is only really interesting for detecting loss, so I'll treat these = as the same. For upstream loss (loss occurring before the observation point), you can = do one-point measurement and just look at the packet numbers, which = (absent rebinding) go up by one per packet. (Note that this is a current = feature of v1, not an invariant, so if we decide we really want = one-point passive upstream loss measurement we should state that packet = number increment-by-one behavior is invariant, either now or later. For two-point loss, you can compare the packet number sequence, as you = can sequence numbers in TCP. >> * TCP segment out-of-order A two-bit spin does this. Network reordering can also be detected by = looking at the packet numbers; indeed, this is *easier* than doing = reordering detection than with TCP sequence numbers since a QUIC RTX = uses a new packet number. Same caveats apply to packet number = increment-by-one behavior as above. If we want reordering detection without adding increment-by-one to the = packet number invariants, then the two-bit spin is a good way to do that = IMO. Cheers, Brian >> as a few basic data points. >> With measurements in point A and point B one can determine for = example if a network device is misordering packets. >>=20 >> -Piotr >>=20 >> -----Original Message----- >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Gorry = Fairhurst >> Sent: Wednesday, November 15, 2017 12:48 AM >> To: MORTON, ALFRED C (AL) >> Cc: Ian Swett; QUIC WG; = emile.stephan@orange.com >> Subject: Re: spin bit in QUIC: troubleshooting >>=20 >> As I said at the mic: I think the spin-bit analysis was helpful, = thanks. >>=20 >> I can see how spin-bit is really useful to get basic diagnostics of = RTT if it can be relied to be present in every packet. (It is important = to measure latency within the network). >>=20 >> There are places where 1-bit gives restricted value, and using more = would help: My additional comment at the Mic related to how much extra = would be the gain from an additional one or two bits? >>=20 >> In particular, I'd like to see a method that can let me detect some = loss patterns and measure reordering, at least I think it is important = to know and measure when there is small-scale reordering<3. >>=20 >> A suggestion:is to use a 2-bit counter for the spin ( >> 00->01->10->11->00), that would help detect these path anomlies. >>=20 >> Gorry >>=20 >> On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote: >>> I=E2=80=99d like to offer support for Spin Bit (and one or two >>>=20 >>> bits for management if they can be justified quickly) in v1. >>>=20 >>> On this topic of more bits, >>>=20 >>> asking further clarification from Emile, below [ACM]. >>>=20 >>> Al >>>=20 >>> *From:*QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett >>> *Sent:* Tuesday, November 14, 2017 4:21 PM >>> *To:* emile.stephan@orange.com >>> *Cc:* QUIC WG >>> *Subject:* Re: spin bit in QUIC: troubleshooting >>>=20 >>> Thanks for clarifying Emile. >>>=20 >>> On Tue, Nov 14, 2017 at 1:06 PM,>> > wrote: >>>=20 >>> Hi Ian, >>>=20 >>> It was suggested in the latest discussion on the RTT design team >>> mailing list to have one bit for packet lost, one for latency (spin >>> bit or eq.) and one for congestion. >>>=20 >>> */[ACM] /* There may be some overlap with ECN and =C2=AB one bit for >>> congestion =C2=BB. >>>=20 >>> Did you also consider this dependency, Emile ? (I=E2=80=99m echoing = a hallway >>> discussion) >>>=20 >>> It seems a simplistic approach on one hand but an invariant on the >>> long term. >>>=20 >>> Regards >>>=20 >>> Emile >>>=20 >>> *De :*Ian Swett [mailto:ianswett@google.com >>> ] *Envoy=C3=A9 :* mardi 14 novembre 2017 = 22:51 >>> *=C3=80 :* STEPHAN Emile IMT/OLN *Cc :* QUIC WG *Objet :* Re: spin = bit in >>> QUIC: troubleshooting >>>=20 >>> What would the other bit or two be used for? If there is no >>> standardized use of those bits in v1, then I believe we should wait = to >>> reserve them when their usage is defined, given we'd need a version >>> bump to specify how they were being used. At the moment, the >>> management use case is not competing with anyone else for bits in = the >>> short header. >>>=20 >>> On Tue, Nov 14, 2017 at 5:14 AM,>> > wrote: >>>=20 >>> Hi >>>=20 >>> Last week Orange experienced a fallback of QUIC to TCP on one of its >>> networks. The issues were not visible in QUIC traffic. The >>> troubleshooting was made using TCP packets information. This is not >>> sustainable on the long term when numerous applications using >>> different versions of QUIC will stop to fallback to TCP. >>>=20 >>> Based on the exchange we had in the RTT design team and in today >>> meeting , it sounds reasonable to reserve at least 2 bits (ideally 3 >>> bits as discussed in the design team) for manageability in the QUIC >>> invariants and to start experimenting the spin bit in QUIC V1. >>>=20 >>> Regards >>>=20 >>> Emile >>>=20 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >>> = ______________________________________________________________________ >>> ___________________________________________________ >>>=20 >>> Ce message et ses pieces jointes peuvent contenir des informations >>> confidentielles ou privilegiees et ne doivent donc pas etre = diffuses, >>> exploites ou copies sans autorisation. Si vous avez recu ce message >>> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>>=20 >>> This message and its attachments may contain confidential or >>> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >>> If you have received this email in error, please notify the sender = and delete this message and its attachments. >>> As emails may be altered, Orange is not liable for messages that = have been modified, changed or falsified. >>> Thank you. >>>=20 >=20 --Apple-Mail=_5D37D940-7CEB-4D36-BECC-23112AA1EF2D 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloL6OsACgkQihK3vwvq RqMLVBAAkSaC3GesEl5uVBG7/xBm+2TgZx6YH0seAooBQkNJE1rcKTmK5cxYh06E yNCqlU9JQZS1FdaOJ88r0ZUMGYRDBw/sQWhXG3U2WyVAZNc7UxCSqgK5tNt+buZL /Q2sOIRawcxdAHRZN4rs0Bi3BJwl59aKwEX2KxLiM5P/E7mQUNs8lW8KCDiiEtNu hNef1kf8vNHsmACWCIIytwj5pMae4Nxpxyf7fLFlBo+BxHrrT9c/V9SOTz00LV18 NXq/HSwOEpYRUsBk6JwzF4H38FH5NbwGaqfANVnHzIFpFN75R3It+anGcXKF1Oak /9PBezNo55mqpxVh4Zf4GahZQUuXwMuYZEOw+gi6W+26o2GnhDeM11EUsKdI/1Z4 yKpGxjc3n9S/zPBsPyei5pHQ/FHtWkcxJYQplZsgge9XsPDgJNrNOix582OpnQTZ LeZzZqE4SreNwZU4CvGpd9CQ6p3/x3WVDsR2qpe+RwzkfybUhf3npy8ff2xfKtPt 50t2NXoecd9Vf/T8SMDGz380UuTc4eh8GnJi5JXP9pGBvV8ferZLCxJrASmLuy+5 XcCQ913HqTJqSb1MPotRUbp7+UmN3O/pYNhwH/lFRGCqKqVXUXRevCuW56pbfvRN DNGZS2e8U/lx2aLalnM6IrJRWgymyEoCQM4UzbwcTldK6SQFbVs= =Dfzx -----END PGP SIGNATURE----- --Apple-Mail=_5D37D940-7CEB-4D36-BECC-23112AA1EF2D-- From nobody Tue Nov 14 23:34: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 0E5F9127444 for ; Tue, 14 Nov 2017 23:34:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 bGiNHpsoPcl0 for ; Tue, 14 Nov 2017 23:34:37 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0129.outbound.protection.outlook.com [104.47.38.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D172F1270A0 for ; Tue, 14 Nov 2017 23:34:36 -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=vvZD1TGVGTcLsWL1ueJVPJfTFXHGLjmHbc1YyEo2MR4=; b=RRXdv7VqtB5S6w/RR1RXB/wKHDxsLq4QeBd/ws17F8oa7qXUmhBn8YZKQjL00MTlAqqpctWaVHIE3dU3d1X20n34LR80IhpJgFwJUnTSZIxr5YaX4njWbU9/7W83bwrqOSxGvvL7CRUFx7E72hk/Fw76xwbfrsaDla5LYjK3FAA= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0789.namprd21.prod.outlook.com (10.175.121.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.0; Wed, 15 Nov 2017 07:34:34 +0000 Received: from CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) by CY4PR21MB0277.namprd21.prod.outlook.com ([10.173.193.143]) with mapi id 15.20.0260.001; Wed, 15 Nov 2017 07:34:34 +0000 From: Praveen Balasubramanian To: "Brian Trammell (IETF)" , Gorry Fairhurst CC: Piotr Galecki , Ian Swett , QUIC WG , Al Morton , "emile.stephan@orange.com" Subject: RE: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFwAJsv0AAAbTAwAABsr3AAAJd4YAAAhCegAAAGZfgAABaCkAAAEjUYAAAJHQwA== Date: Wed, 15 Nov 2017 07:34:34 +0000 Message-ID: References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> <5A0BD528.3040106@erg.abdn.ac.uk> <2C515BE8694C6F4B9B6A578BCAC32E2F83AC9673@MBX021-W3-CA-2.exch021.domain.local> <5A0BE148.4020308@erg.abdn.ac.uk> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [101.100.166.67] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0789; 6:5PS+XYh3oc38cZ8Jqba4fnd+679b2IB6v7ChrcuDZBiKtOZZYbPW5bpioFumODUX16SMcSb+DwH0Sf0OmmxnE1mixOXEVoNCPcbIjjic/kKUHzJDwUftPpc4DnTFfGk0vfgxG2+XcvIYQbOFBJlliRmp8DKd/IUVq+2qm81WQla3LLTTO+uayuGH7umvmX6uE1sCUljg6BtFmp7P3AGqwAkJ+b1G8M/8BlB+LQliY2I0rSvHOEzf+NhFZHg9D/X2h5kc8iMfSeik+1/ReqxSqFHb/RS2R9Q8ZDSA57OVAlZRs8OsUz9V0vc2fRJyeFOfX7sDuERjW2BZfajvJrIJ8NjgEjonQqo6ulaFTh1YVQw=; 5:6J6LxLfBc8g/b+aq9DcF4AOF1GTMcaBTNiEC+3ZEwh8a0jPntex6gE94oF9g+DM0HYdeuvFd6dgWwTfGJJ+JfGBqIwscphMNZ73BQ3AXsMGIzCUwult032E3jeFi4nYsMePB83alwD1WDfKGzHoziTjCYBoVjQLSnWXcO+5IEDs=; 24:4Ba6p0amRQRNcMmYpt4bS/1oXgKPrtu8HPQUEQOisZ0bv0mAZwcwHru3g5MyM1Ga9cgux4bvuQM03c9Rx4tti/mb4xA9YY2NgP2IUTAfHzg=; 7:mAbTH6GGELr6jk1nYJ468naZ5n0OlNOmuQcbysIRmH/hGs58Q3fnA1KcI0oFFhAuiDH5anUVO12YW2WcW2f50oVmLl9f1RufyQmpQI9tleAHy439T7s4tMnlP/8g85vTAqcd1C2twT9xLx+i9ABklaLcwD+g5sIJ6W4cxQPX8lGx/DlxdaWbxVaVxo7CY2ie0EqDLASzAEMWa1ZamWl74BVd9sRokuRqeqbi/bMqc1iawnEOj/GMnXi33sruTEmF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 11a7e07e-ddb4-4905-dfce-08d52bfb5140 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:CY4PR21MB0789; x-ms-traffictypediagnostic: CY4PR21MB0789: authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(72170088055959)(97927398514766)(211936372134217)(153496737603132)(18271650672692); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231022)(920507027)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0789; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0789; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39860400002)(47760400005)(189002)(24454002)(199003)(13464003)(5890100001)(93886005)(8990500004)(189998001)(25786009)(102836003)(6116002)(81166006)(3846002)(8676002)(81156014)(53546010)(7696004)(2950100002)(5660300001)(7736002)(316002)(77096006)(305945005)(74316002)(34040400001)(97736004)(6436002)(6506006)(54906003)(86612001)(99286004)(229853002)(86362001)(110136005)(22452003)(8936002)(53936002)(2900100001)(33656002)(9686003)(4326008)(6246003)(66066001)(68736007)(55016002)(106356001)(105586002)(2906002)(101416001)(478600001)(10290500003)(14454004)(50986999)(76176999)(54356999)(3660700001)(10090500001)(3280700002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0789; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 11a7e07e-ddb4-4905-dfce-08d52bfb5140 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 07:34:34.1378 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0789 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:34:39 -0000 KzEgZm9yIGFkZGluZyBzdXBwb3J0IGZvciBzcGluLWJpdChzKSBpbiBWMS4gRm9yIG1vbml0b3Jp bmcgYW5kIGRpYWdub3N0aWNzIGluIElhYVMgc2NlbmFyaW8gaXQgaXMgcXVpdGUgdXNlZnVsIHRv IGJlIGFibGUgdG8gbWVhc3VyZSBsYXRlbmN5IGZsdWN0dWF0aW9ucyBhbmQgcmVvcmRlci9sb3Nz Lg0KDQpUaGFua3MNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmlhbiBUcmFtbWVsbCAo SUVURikNClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIwMTcgMzoxMyBQTQ0KVG86IEdv cnJ5IEZhaXJodXJzdCA8Z29ycnlAZXJnLmFiZG4uYWMudWs+DQpDYzogUGlvdHIgR2FsZWNraSA8 cGlvdHJfZ2FsZWNraUBhZmZpcm1lZG5ldHdvcmtzLmNvbT47IElhbiBTd2V0dCA8aWFuc3dldHRA Z29vZ2xlLmNvbT47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+OyBBbCBNb3J0b24gPGFjbW9ydG9u QGF0dC5jb20+OyBlbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20NClN1YmplY3Q6IFJlOiBzcGluIGJp dCBpbiBRVUlDOiB0cm91Ymxlc2hvb3RpbmcNCg0KaGkgR29ycnksIFBpb3RyLCBhbGwsDQoNCj4g T24gMTUgTm92IDIwMTcsIGF0IDE0OjQwLCBHb3JyeSBGYWlyaHVyc3QgPGdvcnJ5QGVyZy5hYmRu LmFjLnVrPiB3cm90ZToNCj4gDQo+IEkgdGhpbmsgKGV2ZW4gcGF0aG9sb2dpY2FsKSByZW9yZGVy aW5nIHdvdWxkIGJlIGxhcmdlbHkgdW5kZXRlY3RlZCANCj4gd2l0aCAxLWJpdC4gU2luY2UgaW4g dGhzaSBjYXNlLCB0aGUgYml0IHNpbXBseSBmbGlwcyAxLT4wIGFuZCAwLT4xLA0KPiANCj4gV2l0 aCAyIGJpdHMgdGhlIGZpcnN0IGZsaXAgaXMgMC0+MSBhbmQgdGhlbiB0aGUgbmV4dCBSVFQgLCB0 aGUgZmxpcCBpcyAxLT4yLCB0aGVuIHJlLW9yZGVyaW5nIG9mIHRoZSBzcGluIG1heSBiZWNvbWUg ZGV0ZWN0YWJsZS4gSXQncyBub3QgcGVyZmVjdCwgYnV0IHlvdSBtYXkgc2VlIHNvbWUgcGF0aG9s b2dpZXMgZm9yIGxvdyBhZGRpdGlvbmFsIGNvc3QuDQo+IA0KPiBBQ0sgdmlzaWJpbGl0eSBpcyBu ZWVkZWQgZm9yIHNvbWUgb2YgdGhlIHRoaW5ncyBiZWxvdy4NCg0KT25seSBmb3IgUlRYIGFzIGZh ciBhcyBJIGNhbiB0ZWxsLCBhbmQgUlRYIHdvcmtzIGZ1bmRhbWVudGFsbHkgZGlmZmVyZW50bHkg aW4gUVVJQywgc28gSSdtIG5vdCBzdXJlIGl0J3MgdXNlZnVsOyBzZWUgYmVsb3cuDQoNCj4gDQo+ IEdvcnJ5DQo+IA0KPiBPbiAxNS8xMS8yMDE3LCAxMzo1OSwgUGlvdHIgR2FsZWNraSB3cm90ZToN Cj4+IEhvdyB3b3VsZCBhIG5ldHdvcmsgcHJvYmUgYmUgYWJsZSB0byBtZWFzdXJlIHRoZSBsZXZl bCBvZiBwYWNrZXQgcmVvcmRlcmluZyBpbiBRVUlDIHN0cmVhbSB3aXRoIG9ubHkgYSBzcGluIGJp dD8NCj4+IA0KPj4gSSdtIGFza2luZyBiZWNhdXNlIG9uZSBvZiB0aGUgY29tbW9uIHRlY2huaXF1 ZXMgdG8gZGlhZ25vc2UgbmV0d29yayANCj4+IGlzc3VlcyBpcyB0byBpbnNlcnQgYSBwcm9iZSBp biBkaWZmZXJlbnQgcG9pbnRzIGluIHRoZSBuZXR3b3JrIGFuZCBtZWFzdXJlOg0KPj4gKiBSVFQN Cg0KVGhpcyBpcyB0aGUgc3BpbiBiaXQgKHdoZXRoZXIgb25lIGJpdCwgb3IgdHdvIGJpdHMgYXMg Z29ycnkgc3VnZ2VzdHMpDQoNCj4+ICogVENQIHNlZ21lbnQgbG9zcw0KPj4gKiBUQ1Agc2VnbWVu dCByZXRyYW5zbWlzc2lvbnMNCg0KUlRYIGlzIG9ubHkgcmVhbGx5IGludGVyZXN0aW5nIGZvciBk ZXRlY3RpbmcgbG9zcywgc28gSSdsbCB0cmVhdCB0aGVzZSBhcyB0aGUgc2FtZS4NCg0KRm9yIHVw c3RyZWFtIGxvc3MgKGxvc3Mgb2NjdXJyaW5nIGJlZm9yZSB0aGUgb2JzZXJ2YXRpb24gcG9pbnQp LCB5b3UgY2FuIGRvIG9uZS1wb2ludCBtZWFzdXJlbWVudCBhbmQganVzdCBsb29rIGF0IHRoZSBw YWNrZXQgbnVtYmVycywgd2hpY2ggKGFic2VudCByZWJpbmRpbmcpIGdvIHVwIGJ5IG9uZSBwZXIg cGFja2V0LiAoTm90ZSB0aGF0IHRoaXMgaXMgYSBjdXJyZW50IGZlYXR1cmUgb2YgdjEsIG5vdCBh biBpbnZhcmlhbnQsIHNvIGlmIHdlIGRlY2lkZSB3ZSByZWFsbHkgd2FudCBvbmUtcG9pbnQgcGFz c2l2ZSB1cHN0cmVhbSBsb3NzIG1lYXN1cmVtZW50IHdlIHNob3VsZCBzdGF0ZSB0aGF0IHBhY2tl dCBudW1iZXIgaW5jcmVtZW50LWJ5LW9uZSBiZWhhdmlvciBpcyBpbnZhcmlhbnQsIGVpdGhlciBu b3cgb3IgbGF0ZXIuDQoNCkZvciB0d28tcG9pbnQgbG9zcywgeW91IGNhbiBjb21wYXJlIHRoZSBw YWNrZXQgbnVtYmVyIHNlcXVlbmNlLCBhcyB5b3UgY2FuIHNlcXVlbmNlIG51bWJlcnMgaW4gVENQ Lg0KDQo+PiAqIFRDUCBzZWdtZW50IG91dC1vZi1vcmRlcg0KDQpBIHR3by1iaXQgc3BpbiBkb2Vz IHRoaXMuIE5ldHdvcmsgcmVvcmRlcmluZyBjYW4gYWxzbyBiZSBkZXRlY3RlZCBieSBsb29raW5n IGF0IHRoZSBwYWNrZXQgbnVtYmVyczsgaW5kZWVkLCB0aGlzIGlzICplYXNpZXIqIHRoYW4gZG9p bmcgcmVvcmRlcmluZyBkZXRlY3Rpb24gdGhhbiB3aXRoIFRDUCBzZXF1ZW5jZSBudW1iZXJzIHNp bmNlIGEgUVVJQyBSVFggdXNlcyBhIG5ldyBwYWNrZXQgbnVtYmVyLiBTYW1lIGNhdmVhdHMgYXBw bHkgdG8gcGFja2V0IG51bWJlciBpbmNyZW1lbnQtYnktb25lIGJlaGF2aW9yIGFzIGFib3ZlLg0K DQpJZiB3ZSB3YW50IHJlb3JkZXJpbmcgZGV0ZWN0aW9uIHdpdGhvdXQgYWRkaW5nIGluY3JlbWVu dC1ieS1vbmUgdG8gdGhlIHBhY2tldCBudW1iZXIgaW52YXJpYW50cywgdGhlbiB0aGUgdHdvLWJp dCBzcGluIGlzIGEgZ29vZCB3YXkgdG8gZG8gdGhhdCBJTU8uDQoNCkNoZWVycywNCg0KQnJpYW4N Cg0KDQo+PiBhcyBhIGZldyBiYXNpYyBkYXRhIHBvaW50cy4NCj4+IFdpdGggbWVhc3VyZW1lbnRz IGluIHBvaW50IEEgYW5kIHBvaW50IEIgb25lIGNhbiBkZXRlcm1pbmUgZm9yIGV4YW1wbGUgaWYg YSBuZXR3b3JrIGRldmljZSBpcyBtaXNvcmRlcmluZyBwYWNrZXRzLg0KPj4gDQo+PiAtUGlvdHIN Cj4+IA0KPj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4+IEZyb206IFFVSUMgW21haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBHb3JyeSANCj4+IEZhaXJodXJz dA0KPj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyAxMjo0OCBBTQ0KPj4gVG86 IE1PUlRPTiwgQUxGUkVEIEMgKEFMKTxhY21vcnRvbkBhdHQuY29tPg0KPj4gQ2M6IElhbiBTd2V0 dDxpYW5zd2V0dEBnb29nbGUuY29tPjsgUVVJQyBXRzxxdWljQGlldGYub3JnPjsgDQo+PiBlbWls ZS5zdGVwaGFuQG9yYW5nZS5jb20NCj4+IFN1YmplY3Q6IFJlOiBzcGluIGJpdCBpbiBRVUlDOiB0 cm91Ymxlc2hvb3RpbmcNCj4+IA0KPj4gQXMgSSBzYWlkIGF0IHRoZSBtaWM6IEkgdGhpbmsgdGhl IHNwaW4tYml0IGFuYWx5c2lzIHdhcyBoZWxwZnVsLCB0aGFua3MuDQo+PiANCj4+IEkgY2FuIHNl ZSBob3cgc3Bpbi1iaXQgaXMgcmVhbGx5IHVzZWZ1bCB0byBnZXQgYmFzaWMgZGlhZ25vc3RpY3Mg b2YgUlRUIGlmIGl0IGNhbiBiZSByZWxpZWQgdG8gYmUgcHJlc2VudCBpbiBldmVyeSBwYWNrZXQu IChJdCBpcyBpbXBvcnRhbnQgdG8gbWVhc3VyZSBsYXRlbmN5IHdpdGhpbiB0aGUgbmV0d29yayku DQo+PiANCj4+IFRoZXJlIGFyZSBwbGFjZXMgd2hlcmUgMS1iaXQgZ2l2ZXMgcmVzdHJpY3RlZCB2 YWx1ZSwgYW5kIHVzaW5nIG1vcmUgd291bGQgaGVscDogTXkgYWRkaXRpb25hbCBjb21tZW50IGF0 IHRoZSBNaWMgcmVsYXRlZCB0byBob3cgbXVjaCBleHRyYSB3b3VsZCBiZSB0aGUgZ2FpbiBmcm9t IGFuIGFkZGl0aW9uYWwgb25lIG9yIHR3byBiaXRzPw0KPj4gDQo+PiBJbiBwYXJ0aWN1bGFyLCBJ J2QgbGlrZSB0byBzZWUgYSBtZXRob2QgdGhhdCBjYW4gbGV0IG1lIGRldGVjdCBzb21lIGxvc3Mg cGF0dGVybnMgYW5kIG1lYXN1cmUgcmVvcmRlcmluZywgYXQgbGVhc3QgSSB0aGluayBpdCBpcyBp bXBvcnRhbnQgdG8ga25vdyBhbmQgbWVhc3VyZSB3aGVuIHRoZXJlIGlzIHNtYWxsLXNjYWxlIHJl b3JkZXJpbmc8My4NCj4+IA0KPj4gQSBzdWdnZXN0aW9uOmlzIHRvIHVzZSBhIDItYml0IGNvdW50 ZXIgZm9yIHRoZSBzcGluICgNCj4+IDAwLT4wMS0+MTAtPjExLT4wMCksIHRoYXQgd291bGQgaGVs cCBkZXRlY3QgdGhlc2UgcGF0aCBhbm9tbGllcy4NCj4+IA0KPj4gR29ycnkNCj4+IA0KPj4gT24g MTUvMTEvMjAxNywgMDk6NTEsIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSB3cm90ZToNCj4+PiBJ4oCZ ZCBsaWtlIHRvIG9mZmVyIHN1cHBvcnQgZm9yIFNwaW4gQml0IChhbmQgb25lIG9yIHR3bw0KPj4+ IA0KPj4+IGJpdHMgZm9yIG1hbmFnZW1lbnQgaWYgdGhleSBjYW4gYmUganVzdGlmaWVkIHF1aWNr bHkpIGluIHYxLg0KPj4+IA0KPj4+IE9uIHRoaXMgdG9waWMgb2YgbW9yZSBiaXRzLA0KPj4+IA0K Pj4+IGFza2luZyBmdXJ0aGVyIGNsYXJpZmljYXRpb24gZnJvbSBFbWlsZSwgYmVsb3cgW0FDTV0u DQo+Pj4gDQo+Pj4gQWwNCj4+PiANCj4+PiAqRnJvbToqUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZ10gKk9uIEJlaGFsZiBPZiAqSWFuIFN3ZXR0DQo+Pj4gKlNlbnQ6KiBUdWVzZGF5 LCBOb3ZlbWJlciAxNCwgMjAxNyA0OjIxIFBNDQo+Pj4gKlRvOiogZW1pbGUuc3RlcGhhbkBvcmFu Z2UuY29tDQo+Pj4gKkNjOiogUVVJQyBXRw0KPj4+ICpTdWJqZWN0OiogUmU6IHNwaW4gYml0IGlu IFFVSUM6IHRyb3VibGVzaG9vdGluZw0KPj4+IA0KPj4+IFRoYW5rcyBmb3IgY2xhcmlmeWluZyBF bWlsZS4NCj4+PiANCj4+PiBPbiBUdWUsIE5vdiAxNCwgMjAxNyBhdCAxOjA2IFBNLDxlbWlsZS5z dGVwaGFuQG9yYW5nZS5jb20gDQo+Pj4gPG1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+ PiAgd3JvdGU6DQo+Pj4gDQo+Pj4gSGkgSWFuLA0KPj4+IA0KPj4+IEl0IHdhcyBzdWdnZXN0ZWQg aW4gdGhlIGxhdGVzdCBkaXNjdXNzaW9uIG9uIHRoZSBSVFQgZGVzaWduIHRlYW0gDQo+Pj4gbWFp bGluZyBsaXN0IHRvIGhhdmUgb25lIGJpdCBmb3IgcGFja2V0IGxvc3QsIG9uZSBmb3IgbGF0ZW5j eSAoc3BpbiANCj4+PiBiaXQgb3IgZXEuKSBhbmQgb25lIGZvciBjb25nZXN0aW9uLg0KPj4+IA0K Pj4+ICovW0FDTV0gLyogVGhlcmUgbWF5IGJlIHNvbWUgb3ZlcmxhcCB3aXRoIEVDTiBhbmQgwqsg b25lIGJpdCBmb3IgDQo+Pj4gY29uZ2VzdGlvbiDCuy4NCj4+PiANCj4+PiBEaWQgeW91IGFsc28g Y29uc2lkZXIgdGhpcyBkZXBlbmRlbmN5LCBFbWlsZSA/IChJ4oCZbSBlY2hvaW5nIGEgDQo+Pj4g aGFsbHdheQ0KPj4+IGRpc2N1c3Npb24pDQo+Pj4gDQo+Pj4gSXQgc2VlbXMgYSBzaW1wbGlzdGlj IGFwcHJvYWNoIG9uIG9uZSBoYW5kIGJ1dCBhbiBpbnZhcmlhbnQgb24gdGhlIA0KPj4+IGxvbmcg dGVybS4NCj4+PiANCj4+PiBSZWdhcmRzDQo+Pj4gDQo+Pj4gRW1pbGUNCj4+PiANCj4+PiAqRGUg OipJYW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIA0KPj4+IDxtYWlsdG86aWFu c3dldHRAZ29vZ2xlLmNvbT5dICpFbnZvecOpIDoqIG1hcmRpIDE0IG5vdmVtYnJlIDIwMTcgDQo+ Pj4gMjI6NTEgKsOAIDoqIFNURVBIQU4gRW1pbGUgSU1UL09MTiAqQ2MgOiogUVVJQyBXRyAqT2Jq ZXQgOiogUmU6IHNwaW4gDQo+Pj4gYml0IGluDQo+Pj4gUVVJQzogdHJvdWJsZXNob290aW5nDQo+ Pj4gDQo+Pj4gV2hhdCB3b3VsZCB0aGUgb3RoZXIgYml0IG9yIHR3byBiZSB1c2VkIGZvcj8gIElm IHRoZXJlIGlzIG5vIA0KPj4+IHN0YW5kYXJkaXplZCB1c2Ugb2YgdGhvc2UgYml0cyBpbiB2MSwg dGhlbiBJIGJlbGlldmUgd2Ugc2hvdWxkIHdhaXQgDQo+Pj4gdG8gcmVzZXJ2ZSB0aGVtIHdoZW4g dGhlaXIgdXNhZ2UgaXMgZGVmaW5lZCwgZ2l2ZW4gd2UnZCBuZWVkIGEgDQo+Pj4gdmVyc2lvbiBi dW1wIHRvIHNwZWNpZnkgaG93IHRoZXkgd2VyZSBiZWluZyB1c2VkLiAgQXQgdGhlIG1vbWVudCwg DQo+Pj4gdGhlIG1hbmFnZW1lbnQgdXNlIGNhc2UgaXMgbm90IGNvbXBldGluZyB3aXRoIGFueW9u ZSBlbHNlIGZvciBiaXRzIA0KPj4+IGluIHRoZSBzaG9ydCBoZWFkZXIuDQo+Pj4gDQo+Pj4gT24g VHVlLCBOb3YgMTQsIDIwMTcgYXQgNToxNCBBTSw8ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tIA0K Pj4+IDxtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPj4gIHdyb3RlOg0KPj4+IA0KPj4+ IEhpDQo+Pj4gDQo+Pj4gTGFzdCB3ZWVrIE9yYW5nZSBleHBlcmllbmNlZCBhIGZhbGxiYWNrIG9m IFFVSUMgdG8gVENQIG9uIG9uZSBvZiBpdHMgDQo+Pj4gbmV0d29ya3MuIFRoZSBpc3N1ZXMgd2Vy ZSBub3QgdmlzaWJsZSBpbiBRVUlDIHRyYWZmaWMuIFRoZSANCj4+PiB0cm91Ymxlc2hvb3Rpbmcg d2FzIG1hZGUgdXNpbmcgVENQIHBhY2tldHMgaW5mb3JtYXRpb24uIFRoaXMgaXMgbm90IA0KPj4+ IHN1c3RhaW5hYmxlIG9uIHRoZSBsb25nIHRlcm0gd2hlbiBudW1lcm91cyBhcHBsaWNhdGlvbnMg dXNpbmcgDQo+Pj4gZGlmZmVyZW50IHZlcnNpb25zIG9mIFFVSUMgd2lsbCBzdG9wIHRvIGZhbGxi YWNrIHRvIFRDUC4NCj4+PiANCj4+PiBCYXNlZCBvbiB0aGUgZXhjaGFuZ2Ugd2UgaGFkIGluIHRo ZSBSVFQgZGVzaWduIHRlYW0gYW5kIGluIHRvZGF5IA0KPj4+IG1lZXRpbmcgLCBpdCBzb3VuZHMg cmVhc29uYWJsZSB0byByZXNlcnZlIGF0IGxlYXN0IDIgYml0cyAoaWRlYWxseSAzIA0KPj4+IGJp dHMgYXMgZGlzY3Vzc2VkIGluIHRoZSBkZXNpZ24gdGVhbSkgZm9yIG1hbmFnZWFiaWxpdHkgaW4g dGhlIFFVSUMgDQo+Pj4gaW52YXJpYW50cyBhbmQgdG8gc3RhcnQgZXhwZXJpbWVudGluZyB0aGUg c3BpbiBiaXQgaW4gUVVJQyBWMS4NCj4+PiANCj4+PiBSZWdhcmRzDQo+Pj4gDQo+Pj4gRW1pbGUN Cj4+PiANCj4+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fXw0KPj4+IF9fIF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4+IA0KPj4+IENlIG1lc3NhZ2UgZXQgc2VzIHBp ZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyANCj4+PiBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSAN Cj4+PiBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgDQo+Pj4gY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBz aWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNl cyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMg ZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBt ZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+Pj4gDQo+ Pj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIA0KPj4+IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVk IGJ5IGxhdzsgdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3 aXRob3V0IGF1dGhvcmlzYXRpb24uDQo+Pj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNz YWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+Pj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBP cmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQs IGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KPj4+IFRoYW5rIHlvdS4NCj4+PiANCj4+PiBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPj4+IF9fIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPj4+IA0KPj4+IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZl bnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyANCj4+PiBjb25maWRlbnRpZWxsZXMgb3UgcHJp dmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSANCj4+PiBkaWZmdXNlcywgZXhw bG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgDQo+ Pj4gY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRp dGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVz c2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFu Z2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVy ZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+Pj4gDQo+Pj4gVGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIA0KPj4+IHByaXZp bGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91 bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRp b24uDQo+Pj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuDQo+Pj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLg0KPj4+IFRoYW5rIHlvdS4NCj4+PiANCj4gDQoNCg== From nobody Tue Nov 14 23:39: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 DC37B129541 for ; Tue, 14 Nov 2017 23:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 GRf1r33m9TJp for ; Tue, 14 Nov 2017 23:39:24 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 099AE12951F for ; Tue, 14 Nov 2017 23:39:24 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 91C0BEC183A9F for ; Wed, 15 Nov 2017 07:39:20 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 07:39:22 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 15:39:15 +0800 From: Roni Even To: Mike Bishop , Bret Jordan , "quic@ietf.org" Subject: RE: ACKs in encrypted tunnel Thread-Topic: ACKs in encrypted tunnel Thread-Index: AQHTXcGSIYXZuC/d5EakK+LMHgg9a6MUyKgw//974YCAAMlXAA== Date: Wed, 15 Nov 2017 07:39:15 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8370EC@DGGEMM506-MBX.china.huawei.com> References: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.43.147] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8370ECDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:39:26 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8370ECDGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyB3aWxsIGFsbG93IHRoZSBTZXJ2aWNlIHByb3ZpZGVyIHRvIHJldmlldyB0aGUgY29udGVu dCAoYWxzbyBjaGFuZ2UpLiBUaGlzIGlzIG5vdCB3aGF0IHdlIHdhbnQgYW5kIEkgYXNzdW1lIHRo YXQgdGhpcyBpcyBub3Qgd2hhdCB5b3Ugd2FudA0KUm9uaQ0KDQpGcm9tOiBNaWtlIEJpc2hvcCBb bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlXQ0KU2VudDog15nXldedINeTIDE1INeg15XXkdee 15HXqCAyMDE3IDA1OjM4DQpUbzogUm9uaSBFdmVuOyBCcmV0IEpvcmRhbjsgcXVpY0BpZXRmLm9y Zw0KU3ViamVjdDogUkU6IEFDS3MgaW4gZW5jcnlwdGVkIHR1bm5lbA0KDQpBbHNvLCBpZiB0aGUg ZW5kIHBvaW50KHMpIGNvbnNlbnQgdG8gZ2l2ZSB5b3UgdGhlIGtleXMsIG5vdGhpbmcgc3RvcHMg eW91IGZyb20gaW5zcGVjdGluZyBhIHBhcnRpY3VsYXIgZmxvdy4gIEl0IHJlcXVpcmVzIHRoZSBh Y3RpdmUgY29vcGVyYXRpb24gb2YgYXQgbGVhc3Qgb25lIHBhcnR5IHRvIHRoZSBjb25uZWN0aW9u LCBidXQgaWYgc29tZW9uZeKAmXMgY2FsbGluZyB5b3UgZm9yIGhlbHAsIHRoYXTigJlzIHByZXN1 bWFibHkgdGhlIGNhc2UuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBSb25pIEV2ZW4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUs IDIwMTcgMTE6MzEgQU0NClRvOiBCcmV0IEpvcmRhbiA8am9yZGFuLmlldGZAZ21haWwuY29tPG1h aWx0bzpqb3JkYW4uaWV0ZkBnbWFpbC5jb20+PjsgcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJFOiBBQ0tzIGluIGVuY3J5cHRlZCB0dW5uZWwNCg0KSGksDQpU aGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUgc3BpbiBiaXQgdGhhdCB3YXMgcHJlc2VudGVkIHllc3Rl cmRheQ0KUm9uaQ0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBP biBCZWhhbGYgT2YgQnJldCBKb3JkYW4NClNlbnQ6INeZ15XXnSDXkyAxNSDXoNeV15HXnteR16gg MjAxNyAwNToyNg0KVG86IHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJq ZWN0OiBBQ0tzIGluIGVuY3J5cHRlZCB0dW5uZWwNCg0KU28gbXkgdW5kZXJzdGFuZGluZyBpcyB0 aGF0IGFsbCBBQ0tzIGFuZCBub3RpY2VzIGFib3V0IGxvc3QgcGFja2V0cywgZnJhbWVzLCBldGMg d2lsbCBiZSBjb21tdW5pY2F0ZWQgaW5zaWRlIHRoZSBlbmNyeXB0ZWQgdHVubmVsIHdpdGggUVVJ Qy4NCg0KV2hhdCBpcyBvdXIgcGxhbiB0byBlbmFibGUgbmV0d29yayBvcGVyYXRvcnMgdG8gaGVs cCB0cm91Ymxlc2hvb3QgbmV0d29yayBwcm9ibGVtcyB3aXRoIFFVSUM/DQoNCldoZW4gcnVubmlu ZyBhIGxhcmdlIG5ldHdvcmsgdGhlIG5ldHdvcmsgdGVhbSAvIG5ldHdvcmsgb3BlcmF0b3JzIGFy ZSBvZnRlbiBhc2tlZCB0byBoZWxwIGlkZW50aWZ5IHByb2JsZW1zIHdoZW4gYW4gYXBwbGljYXRp b24gaXMgbm90IHdvcmtpbmcgb3IgaXMgc2x1Z2dpc2guIElmIGFsbCBpbmZvcm1hdGlvbiBpcyBp bnNpZGUgdGhlIGVuY3J5cHRlZCB0dW5uZWwsIGFyZSB3ZSBqdXN0IHNheWluZyDigJxlbmQgdXNl ciBhbmQgYXBwbGljYXRpb24gc3VwcG9ydCBwZXJzb24sIHlvdSBmaWd1cmUgaXQgb3V0P+KAnQ0K DQpUaGlzIHNlZW1zIGxpa2UgYSBodWdlIHByb2JsZW0uICBJIG1lYW4gdGhlIG5ldHdvcmsgZG9l cyBub3QgYWx3YXlzIHdvcmsgZmxhd2xlc3NseSBhbmQgaXQgc2VlbXMgbGlrZSB3ZSBhcmUgcmVt b3ZpbmcgYWxsIHRoZSBhYmlsaXRpZXMgZm9yIG5ldHdvcmsgb3BlcmF0b3JzIHRvIGVuc3VyZSBh bnkgbGV2ZWwgb2YgU0xBIG9yIE9MQS4NCg0KQnJldA0KDQpTZW50IGZyb20gbXkgQ29tbW9kb3Jl IDEyOEQNCg0KUEdQIEZpbmdlcnByaW50OiA2M0I0IEZDNTMgNjgwQSA2QjdEIDE0NDcgIEYyQzAg NzRGOCBBQ0FFIDc0MTUgMDA1MDx0ZWw6NzQxNSUyMDAwNTA+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD8370ECDGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowY207DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K c3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uQmFs bG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZv bnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXtt c28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlv bjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0 IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxk aXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+VGhpcyB3aWxsIGFsbG93IHRoZSBTZXJ2 aWNlIHByb3ZpZGVyIHRvIHJldmlldyB0aGUgY29udGVudCAoYWxzbyBjaGFuZ2UpLiBUaGlzIGlz IG5vdCB3aGF0IHdlIHdhbnQgYW5kIEkgYXNzdW1lIHRoYXQgdGhpcyBpcyBub3Qgd2hhdCB5b3Ug d2FudDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb25pPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IE1pa2UgQmlzaG9wIFttYWlsdG86bWJpc2hvcEBl dmVxdWVmb3UuYmVdDQo8YnI+DQo8Yj5TZW50OjwvYj4gPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRM Ij7XmdeV150mbmJzcDvXkyAxNSDXoNeV15HXnteR16ggMjAxNyAwNTozODwvc3Bhbj48YnI+DQo8 Yj5Ubzo8L2I+IFJvbmkgRXZlbjsgQnJldCBKb3JkYW47IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IEFDS3MgaW4gZW5jcnlwdGVkIHR1bm5lbDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+QWxzbywgaWYgdGhlIGVuZCBwb2ludChzKSBjb25zZW50IHRvIGdpdmUgeW91IHRoZSBrZXlz LCBub3RoaW5nIHN0b3BzIHlvdSBmcm9tIGluc3BlY3RpbmcgYSBwYXJ0aWN1bGFyIGZsb3cuJm5i c3A7IEl0IHJlcXVpcmVzIHRoZSBhY3RpdmUgY29vcGVyYXRpb24gb2YgYXQgbGVhc3Qgb25lIHBh cnR5IHRvDQogdGhlIGNvbm5lY3Rpb24sIGJ1dCBpZiBzb21lb25l4oCZcyBjYWxsaW5nIHlvdSBm b3IgaGVscCwgdGhhdOKAmXMgcHJlc3VtYWJseSB0aGUgY2FzZS48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9hPjwvcD4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBP ZiA8L2I+Um9uaSBFdmVuPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUs IDIwMTcgMTE6MzEgQU08YnI+DQo8Yj5Ubzo8L2I+IEJyZXQgSm9yZGFuICZsdDs8YSBocmVmPSJt YWlsdG86am9yZGFuLmlldGZAZ21haWwuY29tIj5qb3JkYW4uaWV0ZkBnbWFpbC5jb208L2E+Jmd0 OzsNCjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPjxicj4N CjxiPlN1YmplY3Q6PC9iPiBSRTogQUNLcyBpbiBlbmNyeXB0ZWQgdHVubmVsPG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5U aGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUgc3BpbiBiaXQgdGhhdCB3YXMgcHJlc2VudGVkIHllc3Rl cmRheTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb25pPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBj bSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFFVSUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5CcmV0IEpvcmRhbjxicj4NCjxiPlNlbnQ6PC9iPiA8c3BhbiBsYW5nPSJI RSIgZGlyPSJSVEwiPteZ15XXnSZuYnNwO9eTIDE1INeg15XXkdee15HXqCAyMDE3IDA1OjI2PC9z cGFuPjxicj4NCjxiPlRvOjwvYj4gPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNA aWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IEFDS3MgaW4gZW5jcnlwdGVkIHR1bm5l bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNvIG15IHVu ZGVyc3RhbmRpbmcgaXMgdGhhdCBhbGwgQUNLcyBhbmQgbm90aWNlcyBhYm91dCBsb3N0IHBhY2tl dHMsIGZyYW1lcywgZXRjIHdpbGwgYmUgY29tbXVuaWNhdGVkIGluc2lkZSB0aGUgZW5jcnlwdGVk IHR1bm5lbCB3aXRoIFFVSUMuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgaXMgb3VyIHBsYW4gdG8g ZW5hYmxlIG5ldHdvcmsgb3BlcmF0b3JzIHRvIGhlbHAgdHJvdWJsZXNob290IG5ldHdvcmsgcHJv YmxlbXMgd2l0aCBRVUlDPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoZW4gcnVu bmluZyBhIGxhcmdlIG5ldHdvcmsgdGhlIG5ldHdvcmsgdGVhbSAvIG5ldHdvcmsgb3BlcmF0b3Jz IGFyZSBvZnRlbiBhc2tlZCB0byBoZWxwIGlkZW50aWZ5IHByb2JsZW1zIHdoZW4gYW4gYXBwbGlj YXRpb24gaXMgbm90IHdvcmtpbmcgb3IgaXMgc2x1Z2dpc2guIElmIGFsbCBpbmZvcm1hdGlvbiBp cyBpbnNpZGUgdGhlIGVuY3J5cHRlZCB0dW5uZWwsIGFyZSB3ZSBqdXN0IHNheWluZyDigJxlbmQg dXNlcg0KIGFuZCBhcHBsaWNhdGlvbiBzdXBwb3J0IHBlcnNvbiwgeW91IGZpZ3VyZSBpdCBvdXQ/ 4oCdJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBzZWVtcyBsaWtlIGEgaHVn ZSBwcm9ibGVtLiAmbmJzcDtJIG1lYW4gdGhlIG5ldHdvcmsgZG9lcyBub3QgYWx3YXlzIHdvcmsg Zmxhd2xlc3NseSBhbmQgaXQgc2VlbXMgbGlrZSB3ZSBhcmUgcmVtb3ZpbmcgYWxsIHRoZSBhYmls aXRpZXMgZm9yIG5ldHdvcmsgb3BlcmF0b3JzIHRvIGVuc3VyZSBhbnkgbGV2ZWwgb2YgU0xBIG9y IE9MQS4gJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnJldCZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXYgaWQ9IkFwcGxlTWFpbFNpZ25hdHVyZSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5T ZW50IGZyb20gbXkgQ29tbW9kb3JlIDEyOEQ8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UEdQIEZpbmdlcnBy aW50OiZuYnNwOzYzQjQgRkM1MyA2ODBBIDZCN0QgMTQ0NyAmbmJzcDtGMkMwIDc0RjggQUNBRSZu YnNwOzxhIGhyZWY9InRlbDo3NDE1JTIwMDA1MCI+NzQxNSAwMDUwPC9hPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_6E58094ECC8D8344914996DAD28F1CCD8370ECDGGEMM506MBXchina_-- From nobody Tue Nov 14 23:44: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 A674A12954B for ; Tue, 14 Nov 2017 23:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 GybhxLE2bheb for ; Tue, 14 Nov 2017 23:44:03 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8E975127444 for ; Tue, 14 Nov 2017 23:44:03 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 06BBE9930FE5 for ; Wed, 15 Nov 2017 07:44:00 +0000 (GMT) Received: from DGGEMM404-HUB.china.huawei.com (10.3.20.212) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 07:44:01 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM404-HUB.china.huawei.com ([10.3.20.212]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 15:43:55 +0800 From: Roni Even To: Mike Bishop , QUIC WG Subject: RE: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQAAPS1iAAAgH6gAAC4MDg Date: Wed, 15 Nov 2017 07:43:55 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.43.147] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD837112DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:44:06 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD837112DGGEMM506MBXchina_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable inline From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 08:23 To: Roni Even; QUIC WG Subject: RE: connection migration Exactly the same way that TCP-to-TCP handoff between these interfaces works= today, because (non-MP) TCP isn=92t capable of changing to a different int= erface. We=92re trying to build a better answer, but you=92re positing fro= m the start that connection migration fails, so we=92re now in =93no worse= =94 land. The QUIC stack in the client device will see a new interface is available. = It attempts to switch to it, because of some local policy. The transition= fails for whatever reason, but the cellular connection is still active. I= t is the application=92s choice [Roni Even] which application if there is more than one? In the TCP case yo= u stay in the cell. Here there are two options, stay on the cell with QUIC = or move to wifi on TCP whether it wants to wind down and close that connection and start a new one= using TCP, or keep using the old one if the interface remains available. = If there are multiple applications, each application makes that choice inde= pendently. And if the first interface becomes unavailable for whatever reason, the cho= ice is made for it, and the application will have to recover. From: Roni Even [mailto:roni.even@huawei.com] Sent: Wednesday, November 15, 2017 1:25 PM To: Mike Bishop >; QUIC W= G > Subject: RE: connection migration So what is the connection migration flow here. The quic stack in the cell n= etwork will try to migrate to wifi without application request and fail but= will not fall back to TCP. There may be multiple application running over quic? HTTP and peer to peer = at the same time, so who will handle this case? Roni From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 05:35 To: Roni Even; QUIC WG Subject: RE: connection migration That may well be the case, but it=92s not the QUIC stack=92s choice to make= . The application could choose to open a new connection, but that remains = outside the scope of the transport and the mapping to it which we=92re defi= ning. For HTTP, this is fairly straightforward =96 it could stop issuing new flow= control credit, let currently-in-transit data arrive and any losses recove= red, and open a TCP connection to issue a range request starting at whateve= r data offset it hasn=92t seen. But that=92s still a property of an HTTP m= anagement above the HTTP/QUIC mapping. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, November 15, 2017 11:25 AM To: QUIC WG > Subject: connection migration Hi, When moving from cell to wifi the reason may be due to cost (money or quota= ). In this case the user (client) may want to move to wifi even if it will= mean dropping to TCP. Roni --_000_6E58094ECC8D8344914996DAD28F1CCD837112DGGEMM506MBXchina_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

inline

 

From: Mike Bis= hop [mailto:mbishop@evequefou.be]
Sent: =E9=E5=ED =E3 15 =F0=E5=E1= =EE=E1=F8 2017 08:23
To: Roni Even; QUIC WG
Subject: RE: connection migration

 

Exactly the same way that TCP-to-TCP handoff between= these interfaces works today, because (non-MP) TCP isn=92t capable of chan= ging to a different interface.  We=92re trying to build a better answe= r, but you=92re positing from the start that connection migration fails, so we=92re now in =93no worse=94 land.

 

The QUIC stack in the client device will see a new i= nterface is available.  It attempts to switch to it, because of some l= ocal policy.  The transition fails for whatever reason, but the cellul= ar connection is still active.  It is the application=92s choice

[Roni Even] whic= h application if there is more than one? In the TCP case you stay in the ce= ll. Here there are two options, stay on the cell with QUIC or move to wifi = on TCP

whether it wants to wind down and close that connect= ion and start a new one using TCP, or keep using the old one if the interfa= ce remains available.  If there are multiple applications, each applic= ation makes that choice independently.

 

And if the first interface becomes unavailable for w= hatever reason, the choice is made for it, and the application will have to= recover.

 

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <mbishop@= evequefou.be>; QUIC WG <quic@iet= f.org>
Subject: RE: connection migration

 

So what is the connect= ion migration flow here. The quic stack in the cell network will try to mig= rate to wifi without application request and fail but will not fall back to= TCP.

There may be multiple = application running over quic? HTTP and peer to peer at the same time, so w= ho will handle this case?

 

Roni=

 

 

That may well be the case, but it=92s not the QUIC s= tack=92s choice to make.  The application could choose to open a new c= onnection, but that remains outside the scope of the transport and the mapp= ing to it which we=92re defining.

 

For HTTP, this is fairly straightforward =96 it coul= d stop issuing new flow control credit, let currently-in-transit data arriv= e and any losses recovered, and open a TCP connection to issue a range requ= est starting at whatever data offset it hasn=92t seen.  But that=92s still a property of an HTTP managemen= t above the HTTP/QUIC mapping.

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <quic@ietf.org&g= t;
Subject: connection migration

 

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the  user (client) may want to = move to wifi even if it will mean dropping to TCP.

 

Roni

--_000_6E58094ECC8D8344914996DAD28F1CCD837112DGGEMM506MBXchina_-- From nobody Wed Nov 15 00:15: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 9D4F1129484 for ; Wed, 15 Nov 2017 00:15:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.124 X-Spam-Level: X-Spam-Status: No, score=-1.124 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FORGED_HOTMAIL_RCVD2=0.874, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tLzrfKZltzEr for ; Wed, 15 Nov 2017 00:15:39 -0800 (PST) Received: from APC01-SG2-obe.outbound.protection.outlook.com (mail-oln040092253108.outbound.protection.outlook.com [40.92.253.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68338129549 for ; Wed, 15 Nov 2017 00:15:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JCsglcyw+RNLDBT+Dw1PGyyrxknndcxY3wWJqS6UmHQ=; b=f3IXDkJNualKhycRFEJR85zbCpYKWUqeKcv4A5+Mn7bw11oZGXCMmI/RQBxrbg+uUGLnTHUThzeXy+TTiWMfIaOegPLlUrYSvQqbsO08L2aR2KgL2QTVFxQPxx7qYvWKqrVKrLBlA38gPa3t68CRDiZqa/3NSWCLvEiQ8sZvs9W+bmk/rJT6syCVSP06+oHG4F4YfiXx0YmneAu3PcMNiNArkjAKDa8mgkG8Iv/yGONdQbVR8bs2LvY08EQPC4POWq2WPeyfVkYPoZXfd6oakx0KY0DpZAvQaFIAd+C5RgTVuyEhlJ+45fLzw50hs9uYsVAtgxXiiOm4XZlHsrgVug== Received: from HK2APC01FT048.eop-APC01.prod.protection.outlook.com (10.152.248.60) by HK2APC01HT115.eop-APC01.prod.protection.outlook.com (10.152.249.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.156.4; Wed, 15 Nov 2017 08:15:35 +0000 Received: from PS1PR0601MB1483.apcprd06.prod.outlook.com (10.152.248.60) by HK2APC01FT048.mail.protection.outlook.com (10.152.249.200) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.178.5 via Frontend Transport; Wed, 15 Nov 2017 08:15:34 +0000 Received: from PS1PR0601MB1483.apcprd06.prod.outlook.com ([fe80::4176:7396:9664:9b40]) by PS1PR0601MB1483.apcprd06.prod.outlook.com ([fe80::4176:7396:9664:9b40%14]) with mapi id 15.20.0218.015; Wed, 15 Nov 2017 08:15:34 +0000 From: Liang GENG To: Fioccola Giuseppe , "Huangyihong (Rachel)" , "DRUTA, DAN" , Ian Swett , quic CC: "emile.stephan@orange.com" Subject: Re: R: spin bit in QUIC: troubleshooting Thread-Topic: R: spin bit in QUIC: troubleshooting Thread-Index: AdNdsWjQiXFl+idYSdWDiJw89tZdFw== Date: Wed, 15 Nov 2017 08:15:34 +0000 Message-ID: References: <51E6A56BD6A85142B9D172C87FC3ABBB9C603BA1@nkgeml513-mbs.china.huawei.com>, <6d41835fd0a448e583a8f845ec5f5508@TELMBXB02RM001.telecomitalia.local> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: telecomitalia.it; dkim=none (message not signed) header.d=none;telecomitalia.it; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:13772AE53670D965C195AF6548F09EB0D60680BB559EE5CDECF5DC8F5BA197BB; UpperCasedChecksum:AF405B25B0C870FA561C7D785000BBFC4901064397886B0DCB38CA9F5A4BABA1; SizeAsReceived:7311; Count:46 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [IEKLENgE3qktopWTSCRIBOCPvYNZH3+Q] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; HK2APC01HT115; 6:40Lr7EkPvl6rUsDzv1xA/nIikeO6Ev9U3OOwon6ZuJLkFA90s8B085bfv0q5nNGpqVTKCbKlrWh3+rYyUk69R65YTdq0lJQI+kcxyGi/vt/y4YvN7biuguUJwzUlqCGN0IZ+2NXUESK4pNYhNVU/0tFfWxPbPFH6085eNkxbVxbyP5nAkvqGo9+ESl1MrWSWG1HEaIckE3h+GFZpiC9D5CXFZD3sx3eLhpZYp8U7hgFa6fwFO8e+PaEONjz4SJEakMZktC3N/pi9MlhbIMpLXgHToN2MCfhfrqCWI/l5ToQDJFlJOz06hqNluv73lpjdn5/0m8AFLV0USW5GmmGnhQ==; 5:9LHUNQvtfiqf2+JNyXzpDhELhg6/5wkzZ5Gzmm7Q47VOltYkta9iIeFz9UzZN4uiOaTYB6ahSwNhijECjIC82lnkYRKLP6YAlXWdMp6t9sB025blj9iS7HbcSvrDpPKavviaCKF4WEOhWRYK1Aw3aA==; 24:k60cvAWWw5l775PoUsxEAJKivlihiSLDnDNOWH8THTn8V0dl7VJR/yGlLkBhRx9qkM/YSY7jO7KxHTi4VWJBxaUg5wTh/ql5op99tIAWxRc=; 7:EZ8YvmMmj4Py8E9oJuHKChQNPHOp2S47hPQyVgZm+1vtWmmYsOcojH2P1cms/ThwhQwlfUKF9oRjM5H0Pi5PFrEo9cBnkv/mm+4L2gOAaHhgcH0NtKNNpwXJ7zIn5OlpTybpQnVLYz/N35eGomeddNh3lfC7XrXHeglkGcrZ+wjnBNRanyM50JDtFeeJofueBqE7gEGyxKMpJJbEhUWYQGyMDtBoPLlK2Hx4EuU4Kag= x-incomingheadercount: 46 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 63e06010-0936-45bd-1bec-08d52c010af2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(201702061074)(5061506573)(5061507331)(1603103135)(2017031320274)(2017031324274)(2017031323274)(2017031322404)(1603101448)(1601125374)(1701031045); SRVR:HK2APC01HT115; x-ms-traffictypediagnostic: HK2APC01HT115: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(444000031); SRVR:HK2APC01HT115; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:HK2APC01HT115; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(7070007)(98901004); DIR:OUT; SFP:1901; SCL:1; SRVR:HK2APC01HT115; H:PS1PR0601MB1483.apcprd06.prod.outlook.com; FPR:; SPF:None; LANG:; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_PS1PR0601MB1483F8B2EB22D710B676919887290PS1PR0601MB1483_" MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-Network-Message-Id: 63e06010-0936-45bd-1bec-08d52c010af2 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 08:15:34.4897 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT115 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:15:41 -0000 --_000_PS1PR0601MB1483F8B2EB22D710B676919887290PS1PR0601MB1483_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIGFsc28gc3VwcG9ydCB0aGUgaW5jbHVzaW9uIG9mIHRoZSBzcGluIGJpdC4g QXMgbmV0d29yayBpcyBnb2luZyB0byBiZSBlcXVpcHBlZCB3aXRoIG1vcmUgZGl2ZXJzaWZpZWQg ZGVkaWNhdGlvbiAobXVjaCBmaW5lciBncmFudWxhcml0eSAsIGkuZS4gc2xpY2luZyksIG1vbml0 b3JpbmcgYW5kIG1lYXN1cmVtZW50IHdpbGwgYmUgZXZlbiBtb3JlIGVzc2VudGlhbCBmb3IgbWFp bnRhaW4gdmFyaW91cyB0eXBlIG9mIGd1YXJhbnRlZXMgKGxhdGVuY3ksIGJhbmR3aWR0aCwgZGV0 ZXJtaW5pc3RpYyBldGMuKS4gU3BpbiBiaXQgaXMgYSBub3QtdG8tbWlzcyBmZWF0dXJlIGZvciBR dWljIGl0c2VsZiB0byBmaXQgaW4gdGhpcyBuZWFyLWZ1dHVyZSBldm9sdXRpb24uDQoNCkJlc3Qg d2lzaGVzDQpMaWFuZw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpMaWFu ZyBHRU5HDQpDaGluYSBNb2JpbGUgUmVzZWFyY2ggSW5zdGl0dXRlDQoNCkZyb206IEZpb2Njb2xh IEdpdXNlcHBlPG1haWx0bzpnaXVzZXBwZS5maW9jY29sYUB0ZWxlY29taXRhbGlhLml0Pg0KRGF0 ZTogMjAxNy0xMS0xNSAxMDo1NA0KVG86IEh1YW5neWlob25nIChSYWNoZWwpPG1haWx0bzpyYWNo ZWwuaHVhbmdAaHVhd2VpLmNvbT47IERSVVRBLCBEQU48bWFpbHRvOmRkNTgyNkBhdHQuY29tPjsg SWFuIFN3ZXR0PG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPjsgUVVJQyBXRzxtYWlsdG86cXVp Y0BpZXRmLm9yZz4NCkNDOiBlbWlsZS5zdGVwaGFuQG9yYW5nZS5jb208bWFpbHRvOmVtaWxlLnN0 ZXBoYW5Ab3JhbmdlLmNvbT4NClN1YmplY3Q6IFI6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVz aG9vdGluZw0KSGkgQWxsLA0KSSBzdXBwb3J0IHRoZSBpbmNsdXNpb24gb2YgdGhlIHNwaW4gYml0 IGludG8gVjEuIE15IHN1Z2dlc3Rpb24gaXMgdG8gaGF2ZSBvbmUgYml0IGZvciBwYWNrZXQgbG9z cywgb25lIGZvciBsYXRlbmN5IGFuZCBvbmUgZm9yIGNvbmdlc3Rpb24uIEkgd291bGQgYWxzbyBt ZW50aW9uIGRyYWZ0LWlldGYtaXBwbS1hbHQtbWFyayB0aGF0IGRldGFpbHMgaG93IHRvIHVzZSBv bmUgYml0IG9yIHR3byBiaXRzIGZvciBwYWNrZXQgbG9zcyBhbmQgbGF0ZW5jeSBjYWxjdWxhdGlv bi4NCg0KQmVzdCBSZWdhcmRzLA0KDQpHaXVzZXBwZQ0KDQpEYTogUVVJQyBbbWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZ10gUGVyIGNvbnRvIGRpIEh1YW5neWlob25nIChSYWNoZWwpDQpJbnZp YXRvOiBtZXJjb2xlZMOsIDE1IG5vdmVtYnJlIDIwMTcgMDI6MzUNCkE6IERSVVRBLCBEQU47IElh biBTd2V0dA0KQ2M6IFFVSUMgV0c7IGVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbQ0KT2dnZXR0bzog UmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVzaG9vdGluZw0KDQpUaGF04oCZcyBhIGdvb2Qg cG9pbnQuIEkgcmVhbGx5IHRoaW5rIHRoZSBiYWxhbmNlIHNob3VsZCBiZSBhY2hpZXZlZCBiZXR3 ZWVuIHByaXZhY3kgYW5kIG9wZXJhdGlvbi4gU3BpbiBiaXQgaXMgYSBnb29kIGV4YW1wbGUuIEkg c3VwcG9ydCBpdC4NCg0KQlIsDQpSYWNoZWwNCg0K5Y+R5Lu25Lq6OiBRVUlDIFttYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnXSDku6PooaggRFJVVEEsIERBTg0K5Y+R6YCB5pe26Ze0OiAyMDE3 5bm0MTHmnIgxNeaXpSA5OjExDQrmlLbku7bkuro6IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xl LmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+DQrmioTpgIE6IFFVSUMgV0cgPHF1aWNA aWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+PjsgZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29t PG1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+DQrkuLvpopg6IFJlOiBzcGluIGJpdCBp biBRVUlDOiB0cm91Ymxlc2hvb3RpbmcNCg0KSSB3aWxsIGFkZCBteSBzdXBwb3J0IGZvciB0aGUg aW5jbHVzaW9uIG9mIHRoZSBzcGluIGJpdCBpbnRvIFYxIGFuZCBtYWtlIGEgZmV3IG1vcmUgcG9p bnRzLg0KQ29uc2lkZXJpbmcgdGhhdCB0aGUgZGVzaWduIHRlYW0gYW5hbHlzaXMgY29uY2x1ZGVk IHRoYXQgdGhlIHNwaW4gYml0IGRvZXMgbm90IGFkZCBhbnkgYWRkaXRpb25hbCBwcml2YWN5IHJp c2sgYW5kIHRoZSB2ZXJ5IHNwZWNpZmljIG5lZWQgYWRkcmVzc2luZyBsYXRlbmN5IGhhcyBiZWVu IGRvY3VtZW50ZWQgYW5kIHZhbGlkYXRlZCBieSBhIGxhcmdlIG51bWJlciBvZiBXRyBtZW1iZXJz LCBJIGJlbGlldmUgdGhlIFFVSUMgd29ya2luZyBncm91cCBoYXMgYSB1bmlxdWUgb3Bwb3J0dW5p dHkgdG8gc2hvdyB0aGF0IHdlIGNhbiBkZXNpZ24gcHJvdG9jb2xzIHRoYXQgYXJlIGVmZmljaWVu dCwgcHJpdmFjeSBzZW5zaXRpdmUgYW5kIG5ldHdvcmsgbWFuYWdlbWVudCBmcmllbmRseS4NClRo aXMgcGFydGljdWxhciBkZXNpZ24sIHdoaWxlIG5vdCBwZXJmZWN0IGRvZXMgaGF2ZSB0aGUgYmln Z2VzdCBiZW5lZml0IHJlbGF0aXZlIHRvIHRoZSByaXNrcyBhbmQgaXQgc2hvdWxkIGJlIGFkb3B0 ZWQgZnJvbSB0aGUgYmVnaW5uaW5nLg0KQmVzdCBSZWdhcmRzLA0KRGFuDQoNCg0KT24gTm92IDE1 LCAyMDE3LCBhdCA1OjIxIEFNLCBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRv OmlhbnN3ZXR0QGdvb2dsZS5jb20+PiB3cm90ZToNClRoYW5rcyBmb3IgY2xhcmlmeWluZyBFbWls ZS4NCg0KT24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgMTowNiBQTSwgPGVtaWxlLnN0ZXBoYW5Ab3Jh bmdlLmNvbTxtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPj4gd3JvdGU6DQpIaSBJYW4s DQoNCkl0IHdhcyBzdWdnZXN0ZWQgaW4gdGhlIGxhdGVzdCBkaXNjdXNzaW9uIG9uIHRoZSBSVFQg ZGVzaWduIHRlYW0gbWFpbGluZyBsaXN0IHRvIGhhdmUgb25lIGJpdCBmb3IgcGFja2V0IGxvc3Qs IG9uZSBmb3IgbGF0ZW5jeSAoc3BpbiBiaXQgb3IgZXEuKSBhbmQgb25lIGZvciBjb25nZXN0aW9u Lg0KSXQgc2VlbXMgYSBzaW1wbGlzdGljIGFwcHJvYWNoIG9uIG9uZSBoYW5kIGJ1dCBhbiBpbnZh cmlhbnQgb24gdGhlIGxvbmcgdGVybS4NCg0KUmVnYXJkcw0KRW1pbGUNCg0KDQpEZSA6IElhbiBT d2V0dCBbbWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5j b20+XQ0KRW52b3nDqSA6IG1hcmRpIDE0IG5vdmVtYnJlIDIwMTcgMjI6NTENCsOAIDogU1RFUEhB TiBFbWlsZSBJTVQvT0xODQpDYyA6IFFVSUMgV0cNCk9iamV0IDogUmU6IHNwaW4gYml0IGluIFFV SUM6IHRyb3VibGVzaG9vdGluZw0KDQpXaGF0IHdvdWxkIHRoZSBvdGhlciBiaXQgb3IgdHdvIGJl IHVzZWQgZm9yPyAgSWYgdGhlcmUgaXMgbm8gc3RhbmRhcmRpemVkIHVzZSBvZiB0aG9zZSBiaXRz IGluIHYxLCB0aGVuIEkgYmVsaWV2ZSB3ZSBzaG91bGQgd2FpdCB0byByZXNlcnZlIHRoZW0gd2hl biB0aGVpciB1c2FnZSBpcyBkZWZpbmVkLCBnaXZlbiB3ZSdkIG5lZWQgYSB2ZXJzaW9uIGJ1bXAg dG8gc3BlY2lmeSBob3cgdGhleSB3ZXJlIGJlaW5nIHVzZWQuICBBdCB0aGUgbW9tZW50LCB0aGUg bWFuYWdlbWVudCB1c2UgY2FzZSBpcyBub3QgY29tcGV0aW5nIHdpdGggYW55b25lIGVsc2UgZm9y IGJpdHMgaW4gdGhlIHNob3J0IGhlYWRlci4NCg0KT24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgNTox NCBBTSwgPGVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbTxtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFu Z2UuY29tPj4gd3JvdGU6DQpIaQ0KDQpMYXN0IHdlZWsgT3JhbmdlIGV4cGVyaWVuY2VkIGEgZmFs bGJhY2sgb2YgUVVJQyB0byBUQ1Agb24gb25lIG9mIGl0cyBuZXR3b3Jrcy4gVGhlIGlzc3VlcyB3 ZXJlIG5vdCB2aXNpYmxlIGluIFFVSUMgdHJhZmZpYy4gVGhlIHRyb3VibGVzaG9vdGluZyB3YXMg bWFkZSB1c2luZyBUQ1AgcGFja2V0cyBpbmZvcm1hdGlvbi4gVGhpcyBpcyBub3Qgc3VzdGFpbmFi bGUgb24gdGhlIGxvbmcgdGVybSB3aGVuIG51bWVyb3VzIGFwcGxpY2F0aW9ucyB1c2luZyBkaWZm ZXJlbnQgdmVyc2lvbnMgb2YgUVVJQyB3aWxsIHN0b3AgdG8gZmFsbGJhY2sgdG8gVENQLg0KDQpC YXNlZCBvbiB0aGUgZXhjaGFuZ2Ugd2UgaGFkIGluIHRoZSBSVFQgZGVzaWduIHRlYW0gYW5kIGlu IHRvZGF5IG1lZXRpbmcgLCBpdCBzb3VuZHMgcmVhc29uYWJsZSB0byByZXNlcnZlIGF0IGxlYXN0 IDIgYml0cyAoaWRlYWxseSAzIGJpdHMgYXMgZGlzY3Vzc2VkIGluIHRoZSBkZXNpZ24gdGVhbSkg Zm9yIG1hbmFnZWFiaWxpdHkgaW4gdGhlIFFVSUMgaW52YXJpYW50cyBhbmQgdG8gc3RhcnQgZXhw ZXJpbWVudGluZyB0aGUgc3BpbiBiaXQgaW4gUVVJQyBWMS4NCg0KUmVnYXJkcw0KRW1pbGUNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQoNCg0KDQpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMNCg0KcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBj b3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFy IGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXINCg0KYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0 cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9u aXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwNCg0KT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLg0KDQoNCg0KVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVu dHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhh dCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsNCg0KdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1 dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uDQoNCklmIHlvdSBoYXZl IHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBh bmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLg0KDQpBcyBlbWFpbHMg bWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhh dmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuDQoNClRoYW5rIHlvdS4NCg0K UXVlc3RvIG1lc3NhZ2dpbyBlIGkgc3VvaSBhbGxlZ2F0aSBzb25vIGluZGlyaXp6YXRpIGVzY2x1 c2l2YW1lbnRlIGFsbGUgcGVyc29uZSBpbmRpY2F0ZS4gTGEgZGlmZnVzaW9uZSwgY29waWEgbyBx dWFsc2lhc2kgYWx0cmEgYXppb25lIGRlcml2YW50ZSBkYWxsYSBjb25vc2NlbnphIGRpIHF1ZXN0 ZSBpbmZvcm1hemlvbmkgc29ubyByaWdvcm9zYW1lbnRlIHZpZXRhdGUuIFF1YWxvcmEgYWJiaWF0 ZSByaWNldnV0byBxdWVzdG8gZG9jdW1lbnRvIHBlciBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRl IHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRhIGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBk aSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3RydXppb25lLCBHcmF6aWUuDQoNClRoaXMgZS1tYWls IGFuZCBhbnkgYXR0YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgY29udGFpbiBwcml2 aWxlZ2VkIGluZm9ybWF0aW9uIGludGVuZGVkIGZvciB0aGUgYWRkcmVzc2VlKHMpIG9ubHkuIERp c3NlbWluYXRpb24sIGNvcHlpbmcsIHByaW50aW5nIG9yIHVzZSBieSBhbnlib2R5IGVsc2UgaXMg dW5hdXRob3Jpc2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVh c2UgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhl IHNlbmRlciBieSByZXR1cm4gZS1tYWlsLCBUaGFua3MuDQoNClJpc3BldHRhIGwnYW1iaWVudGUu IE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg== --_000_PS1PR0601MB1483F8B2EB22D710B676919887290PS1PR0601MB1483_ Content-Type: text/html; charset="utf-8" Content-ID: <534C9A788D406448B14E8CAEB99D98E7@apcprd06.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxzdHlsZT5ib2R5IHsgbGluZS1oZWlnaHQ6IDEu NTsgfWJsb2NrcXVvdGUgeyBtYXJnaW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDBweDsgbWFy Z2luLWxlZnQ6IDAuNWVtOyB9cCB7IG1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogMHB4 OyB9ZGl2LmZveGRpdjIwMTcxMTE1MTYxMDE3MjAzODY5IHsgfWJvZHkgeyBmb250LXNpemU6IDEw LjVwdDsgZm9udC1mYW1pbHk6IFRhaG9tYTsgY29sb3I6IHJnYigwLCAwLCAwKTsgbGluZS1oZWln aHQ6IDEuNTsgfTwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keT4NCjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPgo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiA+PC9vOnNo YXBlZGVmYXVsdHM+CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPgo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiA+PC9vOmlkbWFwPgo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2Pjxz cGFuPjwvc3Bhbj5IaSBhbGwsPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5JIGFsc28g c3VwcG9ydCB0aGUgaW5jbHVzaW9uIG9mIHRoZSBzcGluIGJpdC4gQXMgbmV0d29yayBpcyBnb2lu ZyB0byBiZSBlcXVpcHBlZCB3aXRoIG1vcmUgZGl2ZXJzaWZpZWQgZGVkaWNhdGlvbiAobXVjaCBm aW5lciBncmFudWxhcml0eSAsIGkuZS4gc2xpY2luZyksIG1vbml0b3JpbmcgYW5kIG1lYXN1cmVt ZW50IHdpbGwgYmUgZXZlbiBtb3JlIGVzc2VudGlhbCBmb3IgbWFpbnRhaW4gdmFyaW91cyB0eXBl IG9mIGd1YXJhbnRlZXMgKGxhdGVuY3ksDQogYmFuZHdpZHRoLCBkZXRlcm1pbmlzdGljIGV0Yy4p LiBTcGluIGJpdCBpcyBhIG5vdC10by1taXNzIGZlYXR1cmUgZm9yIFF1aWMgaXRzZWxmIHRvIGZp dCBpbiB0aGlzIG5lYXItZnV0dXJlIGV2b2x1dGlvbi48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+ DQo8ZGl2PkJlc3Qgd2lzaGVzPC9kaXY+DQo8ZGl2PkxpYW5nPC9kaXY+DQo8ZGl2PiZuYnNwOzwv ZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxociBzdHlsZT0id2lkdGg6IDIxMHB4OyBoZWlnaHQ6 IDFweDsiIGNvbG9yPSIjYjVjNGRmIiBzaXplPSIxIiBhbGlnbj0ibGVmdCI+DQo8ZGl2PjxzcGFu PkxpYW5nIEdFTkcNCjxkaXY+Q2hpbmEgTW9iaWxlIFJlc2VhcmNoIEluc3RpdHV0ZTwvZGl2Pg0K PC9zcGFuPjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2lu LWJvdHRvbTogMHB4OyBtYXJnaW4tbGVmdDogMC41ZW07Ij4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2IHN0eWxlPSJQQURESU5HLVJJR0hUOiA4cHg7 IFBBRERJTkctTEVGVDogOHB4OyBGT05ULVNJWkU6IDEycHg7Rk9OVC1GQU1JTFk6dGFob21hO0NP TE9SOiMwMDAwMDA7IEJBQ0tHUk9VTkQ6ICNlZmVmZWY7IFBBRERJTkctQk9UVE9NOiA4cHg7IFBB RERJTkctVE9QOiA4cHgiPg0KPGRpdj48Yj5Gcm9tOjwvYj4mbmJzcDs8YSBocmVmPSJtYWlsdG86 Z2l1c2VwcGUuZmlvY2NvbGFAdGVsZWNvbWl0YWxpYS5pdCIgc3R5bGU9ImNvbG9yOiBibHVlOyB0 ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPkZpb2Njb2xhIEdpdXNlcHBlPC9hPjwvZGl2Pg0K PGRpdj48Yj5EYXRlOjwvYj4mbmJzcDsyMDE3LTExLTE1Jm5ic3A7MTA6NTQ8L2Rpdj4NCjxkaXY+ PGI+VG86PC9iPiZuYnNwOzxhIGhyZWY9Im1haWx0bzpyYWNoZWwuaHVhbmdAaHVhd2VpLmNvbSIg c3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPkh1YW5neWlo b25nIChSYWNoZWwpPC9hPjsNCjxhIGhyZWY9Im1haWx0bzpkZDU4MjZAYXR0LmNvbSIgc3R5bGU9 ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiPg0KRFJVVEEsIERBTjwv YT47IDxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiBzdHlsZT0iY29sb3I6IGJs dWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+DQpJYW4gU3dldHQ8L2E+OyA8YSBocmVm PSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRp b246IHVuZGVybGluZTsiPg0KUVVJQyBXRzwvYT48L2Rpdj4NCjxkaXY+PGI+Q0M6PC9iPiZuYnNw OzxhIGhyZWY9Im1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20iIHN0eWxlPSJjb2xvcjog Ymx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5lbWlsZS5zdGVwaGFuQG9yYW5nZS5j b208L2E+PC9kaXY+DQo8ZGl2PjxiPlN1YmplY3Q6PC9iPiZuYnNwO1I6IHNwaW4gYml0IGluIFFV SUM6IHRyb3VibGVzaG9vdGluZzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2IGNs YXNzPSJGb3hEaXYyMDE3MTExNTE2MTAxNzIwMzg2OSI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+ CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiID48L286c2hhcGVk ZWZhdWx0cz4KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+CjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiID48 L286aWRtYXA+CjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSIgc3R5bGU9InBhZ2U6IFdvcmRTZWN0aW9uMTsiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0 OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIEFsbCw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJv bWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+SSBzdXBwb3J0IHRoZSBpbmNsdXNpb24gb2YgdGhlIHNwaW4gYml0IGlu dG8gVjEuIE15IHN1Z2dlc3Rpb24gaXMgdG8gaGF2ZSBvbmUgYml0IGZvciBwYWNrZXQgbG9zcywg b25lIGZvciBsYXRlbmN5IGFuZCBvbmUgZm9yIGNvbmdlc3Rpb24uIEkgd291bGQgYWxzbyBtZW50 aW9uDQo8dT5kcmFmdC1pZXRmLWlwcG0tYWx0LW1hcms8L3U+IHRoYXQgZGV0YWlscyBob3cgdG8g dXNlIG9uZSBiaXQgb3IgdHdvIGJpdHMgZm9yIHBhY2tldCBsb3NzIGFuZCBsYXRlbmN5IGNhbGN1 bGF0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6 ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4N CjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5CZXN0IFJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVz IE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250 LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2l1c2VwcGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpz b2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAx MnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EYTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+UGVyIGNv bnRvIGRpIDwvYj5IdWFuZ3lpaG9uZyAoUmFjaGVsKTxicj4NCjxiPkludmlhdG86PC9iPiBtZXJj b2xlZMOsIDE1IG5vdmVtYnJlIDIwMTcgMDI6MzU8YnI+DQo8Yj5BOjwvYj4gRFJVVEEsIERBTjsg SWFuIFN3ZXR0PGJyPg0KPGI+Q2M6PC9iPiBRVUlDIFdHOyBlbWlsZS5zdGVwaGFuQG9yYW5nZS5j b208YnI+DQo8Yj5PZ2dldHRvOjwvYj4gUmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVzaG9v dGluZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlRoYXTigJlzIGEgZ29vZCBwb2ludC4g SSByZWFsbHkgdGhpbmsgdGhlIGJhbGFuY2Ugc2hvdWxkIGJlIGFjaGlldmVkIGJldHdlZW4gcHJp dmFjeSBhbmQgb3BlcmF0aW9uLiBTcGluIGJpdCBpcyBhIGdvb2QgZXhhbXBsZS4gSSBzdXBwb3J0 IGl0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5CUiw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMg TmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RDttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+UmFjaGVsPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0Q7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxiPjxz cGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpTaW1T dW47bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuWPkeS7tuS6ujwvc3Bhbj48L2I+PGI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OuW+rui9 r+mbhem7kTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7 kTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQogUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZyIgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPC9zcGFuPjxi PjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtNUyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuS7o+ihqDwv c3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OuW+rui9r+mbhem7kTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+DQo8L3Nw YW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTrlvq7ova/pm4Xpu5E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkRSVVRBLCBEQU48 YnI+DQo8L3NwYW4+PGI+PHNwYW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5Y+R6YCB5pe2 6Ze0PC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj46 PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk65b6u6L2v6ZuF6buRO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiAyMDE3 PC9zcGFuPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuW5 tDwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk65b6u6L2v6ZuF6buRO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4xMTwvc3Bhbj48 c3BhbiBsYW5nPSJaSC1DTiIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7TVMgR290aGljJnF1b3Q7O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj7mnIg8L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OuW+ rui9r+mbhem7kTttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+MTU8L3NwYW4+PHNwYW4gbGFu Zz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01TIEdv dGhpYyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5pelPC9zcGFuPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTrlvq7ova/pm4Xp u5E7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPg0KIDk6MTE8YnI+DQo8L3NwYW4+PGI+PHNw YW4gbGFuZz0iWkgtQ04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O01TIEdvdGhpYyZxdW90Ozttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+5pS25Lu25Lq6PC9z cGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk65b6u6L2v6ZuF6buRO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj46PC9zcGFu PjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk65b6u6L2v6ZuF6buRO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj4NCiBJYW4gU3dldHQg Jmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiBzdHlsZT0iY29sb3I6IGJs dWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+aWFuc3dldHRAZ29vZ2xlLmNvbTwvYT4m Z3Q7PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPuaKhOmAgTwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTttc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+DQogUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHN0eWxl PSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5xdWljQGlldGYub3Jn PC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tIiBzdHls ZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+DQplbWlsZS5zdGVw aGFuQG9yYW5nZS5jb208L2E+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIGxhbmc9IlpILUNOIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNUyBHb3RoaWMmcXVvdDs7bXNv LWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPuS4uzwvc3Bhbj48L2I+PGI+PHNwYW4gbGFuZz0iWkgt Q04iIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OlNpbVN1bjttc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+6aKYPC9zcGFuPjwvYj48Yj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk65b6u6L2v6ZuF6buRO21zby1mYXJlYXN0LWxhbmd1 YWdlOlpILUNOIj4NCiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJsZXNob290aW5nPG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsg Zm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+ DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5J IHdpbGwgYWRkIG15IHN1cHBvcnQgZm9yIHRoZSBpbmNsdXNpb24gb2YgdGhlIHNwaW4gYml0IGlu dG8gVjEgYW5kIG1ha2UgYSBmZXcgbW9yZSBwb2ludHMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNl cmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj5Db25zaWRlcmluZyB0aGF0IHRoZSBkZXNpZ24gdGVhbSBhbmFseXNpcyBjb25jbHVkZWQg dGhhdCB0aGUgc3BpbiBiaXQgZG9lcyBub3QgYWRkIGFueSBhZGRpdGlvbmFsIHByaXZhY3kgcmlz ayBhbmQgdGhlIHZlcnkgc3BlY2lmaWMgbmVlZCBhZGRyZXNzaW5nIGxhdGVuY3kgaGFzIGJlZW4g ZG9jdW1lbnRlZCBhbmQgdmFsaWRhdGVkIGJ5IGEgbGFyZ2UgbnVtYmVyDQogb2YgV0cgbWVtYmVy cywgSSBiZWxpZXZlIHRoZSBRVUlDIHdvcmtpbmcgZ3JvdXAgaGFzIGEgdW5pcXVlIG9wcG9ydHVu aXR5IHRvIHNob3cgdGhhdCB3ZSBjYW4gZGVzaWduIHByb3RvY29scyB0aGF0IGFyZSBlZmZpY2ll bnQsIHByaXZhY3kgc2Vuc2l0aXZlIGFuZCBuZXR3b3JrIG1hbmFnZW1lbnQgZnJpZW5kbHkuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5UaGlzIHBhcnRpY3VsYXIgZGVzaWduLCB3 aGlsZSBub3QgcGVyZmVjdCBkb2VzIGhhdmUgdGhlIGJpZ2dlc3QgYmVuZWZpdCByZWxhdGl2ZSB0 byB0aGUgcmlza3MgYW5kIGl0IHNob3VsZCBiZSBhZG9wdGVkIGZyb20gdGhlIGJlZ2lubmluZy48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1m YW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTMuMHB0O21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5CZXN0IFJl Z2FyZHMsPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTog MTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RGFuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTog J1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+PGJyPg0KT24gTm92IDE1LCAyMDE3LCBhdCA1OjIxIEFNLCBJYW4g U3dldHQgJmx0OzxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiBzdHlsZT0iY29s b3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+aWFuc3dldHRAZ29vZ2xlLmNv bTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6IDBweDsgbWFyZ2luLWJvdHRvbTogNXB0OyI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+VGhhbmtzIGZvciBjbGFyaWZ5aW5nIEVtaWxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJw dDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+T24gVHVlLCBOb3YgMTQs IDIwMTcgYXQgMTowNiBQTSwgJmx0OzxhIGhyZWY9Im1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5n ZS5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyI+ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlci1zdHlsZTogbm9u ZSBub25lIG5vbmUgc29saWQ7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMjA0LCAyMDQsIDIwNCk7 IGJvcmRlci1sZWZ0LXdpZHRoOiAxcHQ7IHBhZGRpbmc6IDBjbSAwY20gMGNtIDZwdDsgbWFyZ2lu OiAwcHggMGNtIDVwdCA0LjhwdDsiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQt ZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5IaSBJYW4sPC9zcGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1p bHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZu YnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAn VGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5JdCB3YXMg c3VnZ2VzdGVkIGluIHRoZSBsYXRlc3QgZGlzY3Vzc2lvbiBvbiB0aGUgUlRUIGRlc2lnbiB0ZWFt IG1haWxpbmcgbGlzdCB0byBoYXZlIG9uZSBiaXQgZm9yIHBhY2tldCBsb3N0LCBvbmUgZm9yIGxh dGVuY3kgKHNwaW4gYml0IG9yIGVxLikNCiBhbmQgb25lIGZvciBjb25nZXN0aW9uLiA8L3NwYW4+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SXQgc2VlbXMgYSBzaW1wbGlz dGljIGFwcHJvYWNoIG9uIG9uZSBoYW5kIGJ1dCBhbiBpbnZhcmlhbnQgb24gdGhlIGxvbmcgdGVy bS48L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1D TiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1Rp bWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9z cGFuPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBO ZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlJlZ2FyZHM8L3NwYW4+ PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBS b21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RW1pbGU8L3NwYW4+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAx cHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJp ZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2s7 bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJGUiIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4N CjxiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Ozttc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPiBJYW4gU3dldHQgW21haWx0 bzo8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiIHN0 eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7Ij5pYW5zd2V0dEBn b29nbGUuY29tPC9hPl0NCjxicj4NCjxiPkVudm95w6kmbmJzcDs6PC9iPiBtYXJkaSAxNCBub3Zl bWJyZSAyMDE3IDIyOjUxPGJyPg0KPGI+w4AmbmJzcDs6PC9iPiBTVEVQSEFOIEVtaWxlIElNVC9P TE48YnI+DQo8Yj5DYyZuYnNwOzo8L2I+IFFVSUMgV0c8YnI+DQo8Yj5PYmpldCZuYnNwOzo8L2I+ IFJlOiBzcGluIGJpdCBpbiBRVUlDOiB0cm91Ymxlc2hvb3Rpbmc8L3NwYW4+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3 IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6WkgtQ04iPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6 IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPldoYXQgd291bGQgdGhl IG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBmb3I/Jm5ic3A7IElmIHRoZXJlIGlzIG5vIHN0YW5k YXJkaXplZCB1c2Ugb2YgdGhvc2UgYml0cyBpbiB2MSwgdGhlbiBJIGJlbGlldmUgd2Ugc2hvdWxk IHdhaXQgdG8gcmVzZXJ2ZSB0aGVtIHdoZW4gdGhlaXIgdXNhZ2UgaXMgZGVmaW5lZCwgZ2l2ZW4g d2UnZCBuZWVkIGEgdmVyc2lvbiBidW1wIHRvDQogc3BlY2lmeSBob3cgdGhleSB3ZXJlIGJlaW5n IHVzZWQuJm5ic3A7IEF0IHRoZSBtb21lbnQsIHRoZSBtYW5hZ2VtZW50IHVzZSBjYXNlIGlzIG5v dCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxzZSBmb3IgYml0cyBpbiB0aGUgc2hvcnQgaGVhZGVy LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9u dC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+T24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgNToxNCBBTSwgJmx0OzxhIGhyZWY9Im1haWx0 bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIiBzdHlsZT0iY29sb3I6 IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyI+ZW1pbGUuc3RlcGhhbkBvcmFuZ2Uu Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0 LWxhbmd1YWdlOlpILUNOIj5IaTwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEycHQ7 IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxzcGFuIGxhbmc9IkZS IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZh bWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+ TGFzdCB3ZWVrIE9yYW5nZSBleHBlcmllbmNlZCBhIGZhbGxiYWNrIG9mIFFVSUMgdG8gVENQIG9u IG9uZSBvZiBpdHMgbmV0d29ya3MuIFRoZSBpc3N1ZXMgd2VyZSBub3QgdmlzaWJsZSBpbiBRVUlD IHRyYWZmaWMuIFRoZSB0cm91Ymxlc2hvb3RpbmcNCiB3YXMgbWFkZSB1c2luZyBUQ1AgcGFja2V0 cyBpbmZvcm1hdGlvbi4gVGhpcyBpcyBub3Qgc3VzdGFpbmFibGUgb24gdGhlIGxvbmcgdGVybSB3 aGVuIG51bWVyb3VzIGFwcGxpY2F0aW9ucyB1c2luZyBkaWZmZXJlbnQgdmVyc2lvbnMgb2YgUVVJ QyB3aWxsIHN0b3AgdG8gZmFsbGJhY2sgdG8gVENQLjwvc3Bhbj48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5OiAnVGltZXMgTmV3IFJvbWFuJywgc2VyaWY7Ij4NCjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1s YW5ndWFnZTpaSC1DTiI+QmFzZWQgb24gdGhlIGV4Y2hhbmdlIHdlIGhhZCBpbiB0aGUgUlRUIGRl c2lnbiB0ZWFtIGFuZCBpbiB0b2RheSBtZWV0aW5nICwgaXQgc291bmRzIHJlYXNvbmFibGUgdG8g cmVzZXJ2ZSBhdCBsZWFzdCAyIGJpdHMgKGlkZWFsbHkgMyBiaXRzIGFzDQogZGlzY3Vzc2VkIGlu IHRoZSBkZXNpZ24gdGVhbSkgZm9yIG1hbmFnZWFiaWxpdHkgaW4gdGhlIFFVSUMgaW52YXJpYW50 cyBhbmQgdG8gc3RhcnQgZXhwZXJpbWVudGluZyB0aGUgc3BpbiBiaXQgaW4gUVVJQyBWMS48L3Nw YW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5l dyBSb21hbicsIHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Jm5ic3A7PC9zcGFuPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9t YW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPlJlZ2FyZHM8L3NwYW4+PHNwYW4g bGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbics IHNlcmlmOyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpi bGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+RW1pbGU8L3NwYW4+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWlseTogJ1RpbWVzIE5ldyBSb21hbicsIHNlcmlm OyI+DQo8c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFn ZTpaSC1DTiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlIHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3Vy aWVyIE5ldyc7Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVy IE5ldyc7Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3 JzsiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPkNl IG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9y bWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAu MDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+PHNw YW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+cGFzIGV0cmUg ZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMg YXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXI8bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZv bnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij48c3BhbiBsYW5nPSJG UiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5PcmFuZ2UgZGVjbGluZSB0b3V0 ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBm YWxzaWZpZS4gTWVyY2kuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJn aW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3Vy aWVyIE5ldyc7Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpI LUNOIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIg TmV3JzsiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04i PlRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlh bCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7 PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4w MDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij48c3Bh biBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj50aGV5IHNob3Vs ZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlv bi48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw LjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPjxz cGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPklmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRl ciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250 LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+PHNwYW4gbGFuZz0iRlIi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+QXMgZW1haWxzIG1heSBiZSBhbHRl cmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9k aWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHBy ZSBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEwcHQ7IGZvbnQt ZmFtaWx5OiAnQ291cmllciBOZXcnOyI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpaSC1DTiI+VGhhbmsgeW91LjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdUaW1lcyBOZXcgUm9tYW4n LCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpa SC1DTiI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFw dDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPjxzcGFuIGxh bmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBm b250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+PHNwYW4gbGFuZz0i RlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+Q2UgbWVzc2FnZSBldCBzZXMg cGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVu dGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPG86cD48L286cD48L3Nw YW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij48c3BhbiBsYW5nPSJGUiIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNOIj5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNpemU6IDEw cHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+PHNwYW4gbGFuZz0iRlIiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CjxwcmUgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXplOiAxMHB0OyBm b250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPjxzcGFuIGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRl IHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAw MDFwdDsgZm9udC1zaXplOiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPjxzcGFu IGxhbmc9IkZSIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0 OyBmb250LXNpemU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+PHNwYW4gbGFu Zz0iRlIiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+VGhpcyBtZXNzYWdlIGFu ZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMHB0OyBmb250LWZhbWlseTogJ0NvdXJpZXIgTmV3JzsiPjxzcGFuIGxhbmc9IkZSIiBzdHls ZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6WkgtQ04iPnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmli dXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDAuMDAwMXB0OyBmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiAnQ291cmllciBOZXcnOyI+PHNwYW4gbGFuZz0iRlIiIHN0 eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+SWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhp cyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8 cHJlIHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9u dC1mYW1pbHk6ICdDb3VyaWVyIE5ldyc7Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJl YXN0LWxhbmd1YWdlOlpILUNOIj5BcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBu b3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBv ciBmYWxzaWZpZWQuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTBwdDsgZm9udC1mYW1pbHk6ICdDb3VyaWVy IE5ldyc7Ij48c3BhbiBsYW5nPSJGUiIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOlpILUNO Ij5UaGFuayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMC4wMDAxcHQ7IGZvbnQtc2l6ZTogMTJwdDsgZm9udC1mYW1pbHk6ICdU aW1lcyBOZXcgUm9tYW4nLCBzZXJpZjsiPg0KPHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpaSC1DTiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8dGFibGUgc3R5bGU9 IndpZHRoOjYwMHB4OyI+DQo8dGJvZHk+DQo8dHI+DQo8dGQgc3R5bGU9IndpZHRoOjU4NXB4OyBm b250LWZhbWlseTogVmVyZGFuYTsgZm9udC1zaXplOjcuNXB0OyBjb2xvcjojMDAwOyB0ZXh0LWFs aWduOiBqdXN0aWZ5IiB3aWR0aD0iMzk1Ij4NClF1ZXN0byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxs ZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNpdmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNh dGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8gcXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFu dGUgZGFsbGEgY29ub3NjZW56YSBkaSBxdWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2Ft ZW50ZSB2aWV0YXRlLiBRdWFsb3JhIGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBw ZXINCiBlcnJvcmUgc2lldGUgY29ydGVzZW1lbnRlIHByZWdhdGkgZGkgZGFybmUgaW1tZWRpYXRh IGNvbXVuaWNhemlvbmUgYWwgbWl0dGVudGUgZSBkaSBwcm92dmVkZXJlIGFsbGEgc3VhIGRpc3Ry dXppb25lLCBHcmF6aWUuDQo8YnI+DQo8YnI+DQo8aT5UaGlzIGUtbWFpbCBhbmQgYW55IGF0dGFj aG1lbnRzIGlzIGNvbmZpZGVudGlhbCBhbmQgbWF5IGNvbnRhaW4gcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1pbmF0aW9uLCBj b3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVuYXV0aG9yaXNlZC4g SWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNlIGRlbGV0ZSB0aGlz DQogbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIGFuZCBhZHZpc2UgdGhlIHNlbmRlciBieSBy ZXR1cm4gZS1tYWlsLCBUaGFua3MuIDwvaT4NCjxicj4NCjxicj4NCjxiPlJpc3BldHRhIGwnYW1i aWVudGUuIE5vbiBzdGFtcGFyZSBxdWVzdGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby48L2I+ IDwvdGQ+DQo8L3RyPg0KPC90Ym9keT4NCjwvdGFibGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9j a3F1b3RlPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_PS1PR0601MB1483F8B2EB22D710B676919887290PS1PR0601MB1483_-- From nobody Wed Nov 15 00:18: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 D3975126C25 for ; Wed, 15 Nov 2017 00:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 ewd0c2Wq9svo for ; Wed, 15 Nov 2017 00:18:28 -0800 (PST) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0131.outbound.protection.outlook.com [104.47.42.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 BD12C129577 for ; Wed, 15 Nov 2017 00:18:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UMvMtwy4WqCRXKlphIUmHySe9LqMNhaVesH/5BUDhWI=; b=Qb+xHSfZCNWtnxbTarhgL5JHGjqCjTx13e/MECqS+9i8zYE9+Cm5IbM+vg3MyTvzmtcxbYn9Y/xaevRnqFCHZ4maPQZuCMddwnpxtTwJzCr92gWpYxbcFcOnvAUqG3g+hbGVrVlpdNAYbD91FNYhJz+eImuPdFtdAdpCMvr/goo= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2429.namprd08.prod.outlook.com (10.169.203.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 15 Nov 2017 08:18:27 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0239.005; Wed, 15 Nov 2017 08:18:27 +0000 From: Mike Bishop To: Roni Even , QUIC WG Subject: RE: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQAAPS1iAAAgH6gAAC4MDgAAExe/A= Date: Wed, 15 Nov 2017 08:18:26 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2001:67c:370:1998:5880:6587:261f:ee54] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2429; 6:OFyDkzGinZc6VSKX1/iTIPyt8MMUmy7rIv7CjHd0aodAKLPDvNqjFxjTXpsnQREHL8Bl6lgfLNMinHDcKB113YgfzAsoXlM4VGeSSUC5IrxZnarK1c/CZi3t4QnXycHQzmTTV1a1Jye3ggR11zQs+YQE1LyBehpLnM0INE/8fKAbyd8pLecxb6VK2/4uEHLUkHaznnTQ7Bha6DmeVCc8YI6n9YxW5RI7ODTOrXi5zXxkUlokJDzwj+4i7CDKWkkGL1Kd6AyROEGE71AxBgbVcIcwyGfKYybpx7SV+fKKHUvqzZfy/Vwc31H3TP+tCev1LHWcll1Dgz5+OdUzsERG30Ss0rzcWFMncuTL356jGuQ=; 5:/Ni3Cq+3mjU7GEhoGAxoUVnThsnP8caq2OmGzw/lKq898eZyzai396vJwrMHTHGOos/tiWK95FW3O7FljuitPBkfydx3CABy9BL3fx6bCJge9pS8aDh34n6WkG8PtPesP3XdF1kEXOrdb/VB6JEiCb5VAXSCFwHc8TBmpaGC5gw=; 24:qKG+B4gnQkFZZObILjUlGfhcSK9DCsy17z0wL0d7qhORpYRX6q987E9yE8eGxAx6XlSf3wGRurtgpxP8dTHXfr2wSA8Xwg1sDRaKj1pJBR8=; 7:9BTIEeEoO5PIoqA1PjEZY6izQ3PsZtsyrX/o0UZgABNxeB3RDtGeVQnQbzuhrWFhLH0POpjAN+9L7TAH9mTxA713mvFzxGMGmLVqClXuiO1pf1WpWHHjYJXP/SqMvARWZOocsX0q6UwekwO2Gtc/ZBPbMVBqfqY8tnS4CWzadYc1oG/8xd7ajTu9uWnvMZhe8YNchWxYzoWpAL2oNpMkSfoK+094D6sa74ny+25CXsZMGtqxCx2kgKOeEWRr+6LO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 67bef756-e5b5-4620-e71f-08d52c017282 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603199); SRVR:MWHPR08MB2429; x-ms-traffictypediagnostic: MWHPR08MB2429: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(50582790962513)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3231022)(3002001)(10201501046)(6041248)(2016111802025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2429; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2429; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400002)(346002)(376002)(189002)(199003)(6246003)(478600001)(221733001)(105586002)(106356001)(229853002)(7736002)(77096006)(19609705001)(97736004)(3280700002)(3660700001)(86362001)(93886005)(189998001)(14454004)(53936002)(236005)(68736007)(9686003)(6306002)(54896002)(790700001)(6116002)(102836003)(110136005)(2906002)(101416001)(81166006)(81156014)(8676002)(33656002)(316002)(7696004)(54356999)(76176999)(74482002)(55016002)(99286004)(6436002)(3480700004)(5660300001)(2950100002)(7116003)(2900100001)(6506006)(50986999)(8936002)(74316002)(25786009)(53546010)(111123002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2429; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432F6AC0EBBC7F1E792DE9BDA290MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 67bef756-e5b5-4620-e71f-08d52c017282 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 08:18:26.8376 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2429 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:18:32 -0000 --_000_MWHPR08MB2432F6AC0EBBC7F1E792DE9BDA290MWHPR08MB2432namp_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable No; in the TCP case your transport doesn=92t have any migration provision, = so it=92s up to the application whether it wants to wind down the existing = connection and start a new one. If migration fails with QUIC, the situatio= n is exactly the same, and the application decides whether it wants to wind= down the existing connection and start a new one. If there=92s more than one application, then the answer to =93which applica= tion=94 is =93each application=94 because each application owns its own con= nections. From: Roni Even [mailto:roni.even@huawei.com] Sent: Wednesday, November 15, 2017 3:44 PM To: Mike Bishop ; QUIC WG Subject: RE: connection migration inline From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 08:23 To: Roni Even; QUIC WG Subject: RE: connection migration Exactly the same way that TCP-to-TCP handoff between these interfaces works= today, because (non-MP) TCP isn=92t capable of changing to a different int= erface. We=92re trying to build a better answer, but you=92re positing fro= m the start that connection migration fails, so we=92re now in =93no worse= =94 land. The QUIC stack in the client device will see a new interface is available. = It attempts to switch to it, because of some local policy. The transition= fails for whatever reason, but the cellular connection is still active. I= t is the application=92s choice [Roni Even] which application if there is more than one? In the TCP case yo= u stay in the cell. Here there are two options, stay on the cell with QUIC = or move to wifi on TCP whether it wants to wind down and close that connection and start a new one= using TCP, or keep using the old one if the interface remains available. = If there are multiple applications, each application makes that choice inde= pendently. And if the first interface becomes unavailable for whatever reason, the cho= ice is made for it, and the application will have to recover. From: Roni Even [mailto:roni.even@huawei.com] Sent: Wednesday, November 15, 2017 1:25 PM To: Mike Bishop >; QUIC W= G > Subject: RE: connection migration So what is the connection migration flow here. The quic stack in the cell n= etwork will try to migrate to wifi without application request and fail but= will not fall back to TCP. There may be multiple application running over quic? HTTP and peer to peer = at the same time, so who will handle this case? Roni From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 05:35 To: Roni Even; QUIC WG Subject: RE: connection migration That may well be the case, but it=92s not the QUIC stack=92s choice to make= . The application could choose to open a new connection, but that remains = outside the scope of the transport and the mapping to it which we=92re defi= ning. For HTTP, this is fairly straightforward =96 it could stop issuing new flow= control credit, let currently-in-transit data arrive and any losses recove= red, and open a TCP connection to issue a range request starting at whateve= r data offset it hasn=92t seen. But that=92s still a property of an HTTP m= anagement above the HTTP/QUIC mapping. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, November 15, 2017 11:25 AM To: QUIC WG > Subject: connection migration Hi, When moving from cell to wifi the reason may be due to cost (money or quota= ). In this case the user (client) may want to move to wifi even if it will= mean dropping to TCP. Roni --_000_MWHPR08MB2432F6AC0EBBC7F1E792DE9BDA290MWHPR08MB2432namp_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

No; in the TCP case your transport doesn=92t have an= y migration provision, so it=92s up to the application whether it wants to = wind down the existing connection and start a new one.  If migration f= ails with QUIC, the situation is exactly the same, and the application decides whether it wants to wi= nd down the existing connection and start a new one.

 

If there=92s more than one application, then the ans= wer to =93which application=94 is =93each application=94 because each appli= cation owns its own connections.

 

From: Roni Even [mailto:roni.even@huawei.com]=
Sent: Wednesday, November 15, 2017 3:44 PM
To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.= org>
Subject: RE: connection migration

 

inline

 

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =E9=E5=ED =E3 15 =F0=E5=E1= =EE=E1=F8 2017 08:23
To: Roni Even; QUIC WG
Subject: RE: connection migration

 

Exactly the same way that TCP-to-TCP handoff between= these interfaces works today, because (non-MP) TCP isn=92t capable of chan= ging to a different interface.  We=92re trying to build a better answe= r, but you=92re positing from the start that connection migration fails, so we=92re now in =93no worse=94 land.

 

The QUIC stack in the client device will see a new i= nterface is available.  It attempts to switch to it, because of some l= ocal policy.  The transition fails for whatever reason, but the cellul= ar connection is still active.  It is the application=92s choice

[Roni Even] whic= h application if there is more than one? In the TCP case you stay in the ce= ll. Here there are two options, stay on the cell with QUIC or move to wifi = on TCP

whether it wants to wind down and close that connect= ion and start a new one using TCP, or keep using the old one if the interfa= ce remains available.  If there are multiple applications, each applic= ation makes that choice independently.

 

And if the first interface becomes unavailable for w= hatever reason, the choice is made for it, and the application will have to= recover.

 

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <mbishop@= evequefou.be>; QUIC WG <quic@iet= f.org>
Subject: RE: connection migration

 

So what is the connect= ion migration flow here. The quic stack in the cell network will try to mig= rate to wifi without application request and fail but will not fall back to= TCP.

There may be multiple = application running over quic? HTTP and peer to peer at the same time, so w= ho will handle this case?

 

Roni=

 

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =E9=E5=ED =E3 = 15 =F0=E5=E1=EE=E1=F8 <= /span><= /span>2017 05:35
To: Roni Even; QUIC WG
Subject: RE: connection migration

 

That may well be the case, but it=92s not the QUIC s= tack=92s choice to make.  The application could choose to open a new c= onnection, but that remains outside the scope of the transport and the mapp= ing to it which we=92re defining.

 

For HTTP, this is fairly straightforward =96 it coul= d stop issuing new flow control credit, let currently-in-transit data arriv= e and any losses recovered, and open a TCP connection to issue a range requ= est starting at whatever data offset it hasn=92t seen.  But that=92s still a property of an HTTP managemen= t above the HTTP/QUIC mapping.

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <quic@ietf.org&g= t;
Subject: connection migration

 

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the  user (client) may want to = move to wifi even if it will mean dropping to TCP.

 

Roni

--_000_MWHPR08MB2432F6AC0EBBC7F1E792DE9BDA290MWHPR08MB2432namp_-- From nobody Wed Nov 15 00: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 E693F1279EB for ; Wed, 15 Nov 2017 00:21:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 M4QDES3Qq4_L for ; Wed, 15 Nov 2017 00:21:31 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0126.outbound.protection.outlook.com [104.47.33.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 1C241126C25 for ; Wed, 15 Nov 2017 00:21:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zrfNjDqr66P1jNsXbuO5+gIcFM2t0VRETy4O0ZujetA=; b=tdwtm7K6wY/D0MqLLwSWwv+fOqOFcES7v4Hy1VBM9EOUTr3CMkTKwkwCbbkm5zbOtbo5DfjMZdpnrfF8qUkMpsENOkTOLYu6Gqd7aKxNY5L/JGFwnmgxdwpr0Dgh/V/ONkxWsusACTvDPfq/4xwolxS+LJnNKyvrcxjjmwEhcJ0= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2429.namprd08.prod.outlook.com (10.169.203.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 15 Nov 2017 08:21:28 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0239.005; Wed, 15 Nov 2017 08:21:28 +0000 From: Mike Bishop To: Roni Even , Bret Jordan , "quic@ietf.org" Subject: RE: ACKs in encrypted tunnel Thread-Topic: ACKs in encrypted tunnel Thread-Index: AQHTXcGN/P1o2Nv99U6OtVBH7RML2qMUyNsAgAABT+CAAEP/gIAACzjQ Date: Wed, 15 Nov 2017 08:21:28 +0000 Message-ID: References: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8370EC@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8370EC@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2001:67c:370:1998:5880:6587:261f:ee54] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2429; 6:dDK4Ub+gBvG2fjXa/WTWvXGx4ynEImCTvRxfSCkr1t/bTiFO9eIJp28zpn4dpavywL0+3VH+8hBsZE8zOiufLd+GDApSTY4SXszYZvh/iEwu1NZNBQrmGRMXKzbXIBjYngrOsYc4+AQvFuIUosuHw0T4iXl3yxjs55LUB2wwfLADtSHbmZ5tShpkQy3EZjlsbjK67CyDLEid8rKHDqovR6+rSihpYCC4vjAxsueyceRIFHSS6tmbfR2Qn9t7BLZ9DK9jn6LhSXQVeI99kdYneNEN0B8lbPI6EtEL8ljLdLcxZEK89U0XqLMCfW71RkHBSfKj35GcFYNpg+WgT7sumcPkzQIIXYrMHx+IvKMFFrk=; 5:7QaXE8WE5Abd5JAsp728OCxS571KEC2MwPwEC9N4Wi8lVeUdgH1hRyC0rHKb9pzMyBlihz6KNT/Rx26eStFfVZhN5lI7KinQbwaNr4+U1GHWrON4X8v65XWVdo6vbuWyYqUC96o7Th8VP57xxVHq6zvUIMwrFdWa9V8YzROeOrQ=; 24:tm8sQVqnCM2SxoR/NB1q2A7c2F8hWhfEc3oJIge4yxqJ8B4QQeGw8UVhIrQGtqPLcaUm4EjyjrLzmnvZaBxoT5GR1FJaiklLh9KdI20TjzU=; 7:WZeGCSNLFEUmlWn39xR5+NPpbouoDuoQJuJC8azjYvrk0ii8+kvTB1RnwH63Oqkk4GuKNK8VSe92WbC8kgiamQTy9J3tTVfrRu0MbSovEm9+IbDYJoeHg5+t+wz+MTsjipslBk0LN5YD41/sK0Mq19hieZJruNuhJoREvcCDXaCNuBxobWC0hqFlwHMzAG801gqDy3a7urP+Yq2da/QvVA+CHoweuzK4Yy9y6A+VAt+Bq4Ki/hCS30A6hfHB1iuz x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4ce4f594-87cc-44f6-d36f-08d52c01dec3 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603199); SRVR:MWHPR08MB2429; x-ms-traffictypediagnostic: MWHPR08MB2429: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(227612066756510)(21748063052155)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3231022)(3002001)(10201501046)(6041248)(2016111802025)(20161123555025)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2429; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2429; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39830400002)(346002)(376002)(189002)(199003)(6246003)(478600001)(105586002)(106356001)(229853002)(7736002)(77096006)(2501003)(19609705001)(97736004)(3280700002)(39060400002)(3660700001)(86362001)(93886005)(189998001)(14454004)(53936002)(236005)(68736007)(9686003)(6306002)(54896002)(790700001)(6116002)(102836003)(110136005)(2906002)(101416001)(81166006)(81156014)(8676002)(33656002)(316002)(7696004)(54356999)(76176999)(74482002)(55016002)(99286004)(6436002)(3480700004)(5660300001)(2950100002)(2900100001)(6506006)(50986999)(8936002)(74316002)(25786009)(53546010); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2429; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB24323B4282F12CFF3A461B8EDA290MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 4ce4f594-87cc-44f6-d36f-08d52c01dec3 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 08:21:28.4570 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2429 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:21:34 -0000 --_000_MWHPR08MB24323B4282F12CFF3A461B8EDA290MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Tm87IHRoZSBwcm92aWRlciBpcyBhYmxlIHRvIHJldmlldyB0aGUgY29udGVudHMgb2YgdGhlIGlu ZGl2aWR1YWwgZmxvdyB0aGV54oCZdmUgYmVlbiBpbnZpdGVkIHRvIGluc3BlY3QgZm9yIHRlc3Rp bmcgcHVycG9zZXMuICBObyBvbmUgaXMgZ29pbmcgdG8gZGlzY2xvc2UgdGhlaXIgcHJpdmF0ZSBr ZXlzLCBidXQgaWYgdGhleSBoYXZlIGEgcmVwcm9kdWNpYmxlIHByb2JsZW0gdGhleSBtaWdodCB3 ZWxsIGJlIHdpbGxpbmcgdG8gaWRlbnRpZnkgdGhlIGRlcml2ZWQgc3ltbWV0cmljIGtleXMgd2hp Y2ggcHJvdGVjdGVkIHRoZSBzZXNzaW9uIHRoZXnigJlyZSBhc2tpbmcgeW91IHRvIGludmVzdGln YXRlLg0KDQpGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbV0NClNl bnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIwMTcgMzozOSBQTQ0KVG86IE1pa2UgQmlzaG9w IDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZT47IEJyZXQgSm9yZGFuIDxqb3JkYW4uaWV0ZkBnbWFpbC5j b20+OyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSRTogQUNLcyBpbiBlbmNyeXB0ZWQgdHVubmVs DQoNClRoaXMgd2lsbCBhbGxvdyB0aGUgU2VydmljZSBwcm92aWRlciB0byByZXZpZXcgdGhlIGNv bnRlbnQgKGFsc28gY2hhbmdlKS4gVGhpcyBpcyBub3Qgd2hhdCB3ZSB3YW50IGFuZCBJIGFzc3Vt ZSB0aGF0IHRoaXMgaXMgbm90IHdoYXQgeW91IHdhbnQNClJvbmkNCg0KRnJvbTogTWlrZSBCaXNo b3AgW21haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZV0NClNlbnQ6INeZ15XXnSDXkyAxNSDXoNeV 15HXnteR16ggMjAxNyAwNTozOA0KVG86IFJvbmkgRXZlbjsgQnJldCBKb3JkYW47IHF1aWNAaWV0 Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSRTogQUNLcyBpbiBlbmNyeXB0 ZWQgdHVubmVsDQoNCkFsc28sIGlmIHRoZSBlbmQgcG9pbnQocykgY29uc2VudCB0byBnaXZlIHlv dSB0aGUga2V5cywgbm90aGluZyBzdG9wcyB5b3UgZnJvbSBpbnNwZWN0aW5nIGEgcGFydGljdWxh ciBmbG93LiAgSXQgcmVxdWlyZXMgdGhlIGFjdGl2ZSBjb29wZXJhdGlvbiBvZiBhdCBsZWFzdCBv bmUgcGFydHkgdG8gdGhlIGNvbm5lY3Rpb24sIGJ1dCBpZiBzb21lb25l4oCZcyBjYWxsaW5nIHlv dSBmb3IgaGVscCwgdGhhdOKAmXMgcHJlc3VtYWJseSB0aGUgY2FzZS4NCg0KRnJvbTogUVVJQyBb bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvbmkgRXZlbg0KU2Vu dDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyAxMTozMSBBTQ0KVG86IEJyZXQgSm9yZGFu IDxqb3JkYW4uaWV0ZkBnbWFpbC5jb208bWFpbHRvOmpvcmRhbi5pZXRmQGdtYWlsLmNvbT4+OyBx dWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPg0KU3ViamVjdDogUkU6IEFDS3MgaW4g ZW5jcnlwdGVkIHR1bm5lbA0KDQpIaSwNClRoaXMgaXMgZGlzY3Vzc2VkIGluIHRoZSBzcGluIGJp dCB0aGF0IHdhcyBwcmVzZW50ZWQgeWVzdGVyZGF5DQpSb25pDQoNCkZyb206IFFVSUMgW21haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBCcmV0IEpvcmRhbg0KU2VudDog 15nXldedINeTIDE1INeg15XXkdee15HXqCAyMDE3IDA1OjI2DQpUbzogcXVpY0BpZXRmLm9yZzxt YWlsdG86cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IEFDS3MgaW4gZW5jcnlwdGVkIHR1bm5lbA0K DQpTbyBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYWxsIEFDS3MgYW5kIG5vdGljZXMgYWJvdXQg bG9zdCBwYWNrZXRzLCBmcmFtZXMsIGV0YyB3aWxsIGJlIGNvbW11bmljYXRlZCBpbnNpZGUgdGhl IGVuY3J5cHRlZCB0dW5uZWwgd2l0aCBRVUlDLg0KDQpXaGF0IGlzIG91ciBwbGFuIHRvIGVuYWJs ZSBuZXR3b3JrIG9wZXJhdG9ycyB0byBoZWxwIHRyb3VibGVzaG9vdCBuZXR3b3JrIHByb2JsZW1z IHdpdGggUVVJQz8NCg0KV2hlbiBydW5uaW5nIGEgbGFyZ2UgbmV0d29yayB0aGUgbmV0d29yayB0 ZWFtIC8gbmV0d29yayBvcGVyYXRvcnMgYXJlIG9mdGVuIGFza2VkIHRvIGhlbHAgaWRlbnRpZnkg cHJvYmxlbXMgd2hlbiBhbiBhcHBsaWNhdGlvbiBpcyBub3Qgd29ya2luZyBvciBpcyBzbHVnZ2lz aC4gSWYgYWxsIGluZm9ybWF0aW9uIGlzIGluc2lkZSB0aGUgZW5jcnlwdGVkIHR1bm5lbCwgYXJl IHdlIGp1c3Qgc2F5aW5nIOKAnGVuZCB1c2VyIGFuZCBhcHBsaWNhdGlvbiBzdXBwb3J0IHBlcnNv biwgeW91IGZpZ3VyZSBpdCBvdXQ/4oCdDQoNClRoaXMgc2VlbXMgbGlrZSBhIGh1Z2UgcHJvYmxl bS4gIEkgbWVhbiB0aGUgbmV0d29yayBkb2VzIG5vdCBhbHdheXMgd29yayBmbGF3bGVzc2x5IGFu ZCBpdCBzZWVtcyBsaWtlIHdlIGFyZSByZW1vdmluZyBhbGwgdGhlIGFiaWxpdGllcyBmb3IgbmV0 d29yayBvcGVyYXRvcnMgdG8gZW5zdXJlIGFueSBsZXZlbCBvZiBTTEEgb3IgT0xBLg0KDQpCcmV0 DQoNClNlbnQgZnJvbSBteSBDb21tb2RvcmUgMTI4RA0KDQpQR1AgRmluZ2VycHJpbnQ6IDYzQjQg RkM1MyA2ODBBIDZCN0QgMTQ0NyAgRjJDMCA3NEY4IEFDQUUgNzQxNSAwMDUwPHRlbDo3NDE1JTIw MDA1MD4NCg== --_000_MWHPR08MB24323B4282F12CFF3A461B8EDA290MWHPR08MB2432namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2 IDQgMyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBs aS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9t Oi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0Fj ZXRhdGUsIGxpLk1zb0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZhbWls eToiVGFob21hIixzYW5zLXNlcmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2 Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9w LWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5CYWxsb29uVGV4dENoYXINCgl7bXNvLXN0eWxl LW5hbWU6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNv LXN0eWxlLWxpbms6IkJhbGxvb24gVGV4dCI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsc2Fucy1z ZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxl MjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNh bnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk5vOyB0 aGUgcHJvdmlkZXIgaXMgYWJsZSB0byByZXZpZXcgdGhlIGNvbnRlbnRzIG9mIHRoZSBpbmRpdmlk dWFsIGZsb3cgdGhleeKAmXZlIGJlZW4gaW52aXRlZCB0byBpbnNwZWN0IGZvciB0ZXN0aW5nIHB1 cnBvc2VzLiZuYnNwOyBObyBvbmUgaXMgZ29pbmcgdG8gZGlzY2xvc2UgdGhlaXIgcHJpdmF0ZSBr ZXlzLA0KIGJ1dCBpZiB0aGV5IGhhdmUgYSByZXByb2R1Y2libGUgcHJvYmxlbSB0aGV5IG1pZ2h0 IHdlbGwgYmUgd2lsbGluZyB0byBpZGVudGlmeSB0aGUgZGVyaXZlZCBzeW1tZXRyaWMga2V5cyB3 aGljaCBwcm90ZWN0ZWQgdGhlIHNlc3Npb24gdGhleeKAmXJlIGFza2luZyB5b3UgdG8gaW52ZXN0 aWdhdGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFt ZT0iX01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvYT48L3A+DQo8c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+ PC9zcGFuPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+IFJvbmkgRXZlbiBbbWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tXQ0KPGJyPg0KPGI+U2Vu dDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIwMTcgMzozOSBQTTxicj4NCjxiPlRvOjwv Yj4gTWlrZSBCaXNob3AgJmx0O21iaXNob3BAZXZlcXVlZm91LmJlJmd0OzsgQnJldCBKb3JkYW4g Jmx0O2pvcmRhbi5pZXRmQGdtYWlsLmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUkU6IEFDS3MgaW4gZW5jcnlwdGVkIHR1bm5lbDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdE Ij5UaGlzIHdpbGwgYWxsb3cgdGhlIFNlcnZpY2UgcHJvdmlkZXIgdG8gcmV2aWV3IHRoZSBjb250 ZW50IChhbHNvIGNoYW5nZSkuIFRoaXMgaXMgbm90IHdoYXQgd2Ugd2FudCBhbmQgSSBhc3N1bWUg dGhhdCB0aGlzIGlzIG5vdCB3aGF0IHlvdSB3YW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJvbmk8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0i Ym9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNl cmlmIj4gTWlrZSBCaXNob3AgWzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSI+ bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiA8L3Nw YW4+PHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+15nXldedJm5ic3A715MgMTUg 16DXldeR157XkdeoIDIwMTcgMDU6Mzg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlRv OjwvYj4gUm9uaSBFdmVuOyBCcmV0IEpvcmRhbjsgPGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5v cmciPnF1aWNAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBBQ0tzIGluIGVu Y3J5cHRlZCB0dW5uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkFsc28sIGlmIHRoZSBlbmQgcG9pbnQocykgY29uc2VudCB0 byBnaXZlIHlvdSB0aGUga2V5cywgbm90aGluZyBzdG9wcyB5b3UgZnJvbSBpbnNwZWN0aW5nIGEg cGFydGljdWxhciBmbG93LiZuYnNwOyBJdCByZXF1aXJlcyB0aGUgYWN0aXZlIGNvb3BlcmF0aW9u IG9mIGF0IGxlYXN0IG9uZSBwYXJ0eSB0byB0aGUNCiBjb25uZWN0aW9uLCBidXQgaWYgc29tZW9u ZeKAmXMgY2FsbGluZyB5b3UgZm9yIGhlbHAsIHRoYXTigJlzIHByZXN1bWFibHkgdGhlIGNhc2Uu PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGlu IDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9t Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1aWMt Ym91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5P biBCZWhhbGYgT2YgPC9iPlJvbmkgRXZlbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5v dmVtYmVyIDE1LCAyMDE3IDExOjMxIEFNPGJyPg0KPGI+VG86PC9iPiBCcmV0IEpvcmRhbiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmpvcmRhbi5pZXRmQGdtYWlsLmNvbSI+am9yZGFuLmlldGZAZ21haWwu Y29tPC9hPiZndDs7DQo8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyI+cXVpY0BpZXRmLm9y ZzwvYT48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEFDS3MgaW4gZW5jcnlwdGVkIHR1bm5lbDxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+VGhpcyBpcyBkaXNjdXNz ZWQgaW4gdGhlIHNwaW4gYml0IHRoYXQgd2FzIHByZXNlbnRlZCB5ZXN0ZXJkYXk8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6 IzFGNDk3RCI+Um9uaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4g MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bh bj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFo b21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBRVUlDIFs8YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+QnJldCBKb3JkYW48YnI+DQo8Yj5TZW50OjwvYj4gPC9zcGFuPjxzcGFuIGxhbmc9 IkhFIiBkaXI9IlJUTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPteZ15XXnSZuYnNwO9eTIDE1INeg15XXkdee15HXqCAy MDE3IDA1OjI2PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9 Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPjxicj4NCjxiPlN1YmplY3Q6 PC9iPiBBQ0tzIGluIGVuY3J5cHRlZCB0dW5uZWw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5TbyBteSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgYWxsIEFDS3Mg YW5kIG5vdGljZXMgYWJvdXQgbG9zdCBwYWNrZXRzLCBmcmFtZXMsIGV0YyB3aWxsIGJlIGNvbW11 bmljYXRlZCBpbnNpZGUgdGhlIGVuY3J5cHRlZCB0dW5uZWwgd2l0aCBRVUlDLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEy LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5XaGF0IGlzIG91ciBwbGFuIHRvIGVuYWJsZSBuZXR3b3JrIG9wZXJhdG9ycyB0byBo ZWxwIHRyb3VibGVzaG9vdCBuZXR3b3JrIHByb2JsZW1zIHdpdGggUVVJQz8mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVuIHJ1bm5pbmcgYSBsYXJnZSBuZXR3b3JrIHRoZSBuZXR3 b3JrIHRlYW0gLyBuZXR3b3JrIG9wZXJhdG9ycyBhcmUgb2Z0ZW4gYXNrZWQgdG8gaGVscCBpZGVu dGlmeSBwcm9ibGVtcyB3aGVuIGFuIGFwcGxpY2F0aW9uIGlzIG5vdCB3b3JraW5nIG9yIGlzIHNs dWdnaXNoLiBJZiBhbGwgaW5mb3JtYXRpb24gaXMgaW5zaWRlIHRoZSBlbmNyeXB0ZWQgdHVubmVs LCBhcmUgd2UganVzdCBzYXlpbmcg4oCcZW5kIHVzZXINCiBhbmQgYXBwbGljYXRpb24gc3VwcG9y dCBwZXJzb24sIHlvdSBmaWd1cmUgaXQgb3V0P+KAnSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlRoaXMgc2VlbXMgbGlrZSBhIGh1Z2UgcHJvYmxlbS4gJm5ic3A7SSBtZWFuIHRoZSBu ZXR3b3JrIGRvZXMgbm90IGFsd2F5cyB3b3JrIGZsYXdsZXNzbHkgYW5kIGl0IHNlZW1zIGxpa2Ug d2UgYXJlIHJlbW92aW5nIGFsbCB0aGUgYWJpbGl0aWVzIGZvciBuZXR3b3JrIG9wZXJhdG9ycyB0 byBlbnN1cmUgYW55IGxldmVsIG9mIFNMQSBvciBPTEEuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPkJyZXQmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1 cmUiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U2VudCBmcm9tIG15IENvbW1vZG9yZSAxMjhEPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1i b3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlBHUCBGaW5nZXJwcmludDombmJzcDs2M0I0IEZDNTMgNjgwQSA2QjdE IDE0NDcgJm5ic3A7RjJDMCA3NEY4IEFDQUUmbmJzcDs8YSBocmVmPSJ0ZWw6NzQxNSUyMDAwNTAi Pjc0MTUgMDA1MDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_MWHPR08MB24323B4282F12CFF3A461B8EDA290MWHPR08MB2432namp_-- From nobody Wed Nov 15 00:54: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 EB77E12956D for ; Wed, 15 Nov 2017 00:54:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 jfj4SR8OFyDd for ; Wed, 15 Nov 2017 00:54:35 -0800 (PST) Received: from orange.com (mta136.mail.business.static.orange.com [80.12.70.36]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CB90129562 for ; Wed, 15 Nov 2017 00:54:34 -0800 (PST) Received: from opfednr06.francetelecom.fr (unknown [xx.xx.xx.70]) by opfednr23.francetelecom.fr (ESMTP service) with ESMTP id 0C231C0F02; Wed, 15 Nov 2017 09:54:24 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.18]) by opfednr06.francetelecom.fr (ESMTP service) with ESMTP id E0BC61A0051; Wed, 15 Nov 2017 09:54:23 +0100 (CET) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([fe80::cba:56d0:a732:ef5a%19]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 09:54:23 +0100 From: To: Piotr Galecki , "gorry@erg.abdn.ac.uk" , "MORTON, ALFRED C (AL)" CC: Ian Swett , QUIC WG Subject: RE: spin bit in QUIC Thread-Topic: spin bit in QUIC Thread-Index: AdNd7xkq6gl0mbBoQK2OefMQeCMH+w== Date: Wed, 15 Nov 2017 08:54:23 +0000 Message-ID: <30502_1510736063_5A0C00BF_30502_41_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7EB1C@OPEXCLILM44.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.4] 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.22 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 Nov 2017 08:54:37 -0000 SGkgQWwsDQoNCkl0J3MgYSBnb29kIGNhdGNoLiBNeSBwb2ludCBpcyB0byBoYXZlIHJvb20gZm9y IGl0IGluIHRoZSBpbnZhcmlhbnQgdG8gYWRkcmVzcyB0aGUgb3NzaWZpY2F0aW9uIGNvbmNlcm4u DQoNCkVtaWxlDQoNCg0KDQpPbiAxNS8xMS8yMDE3LCAwOTo1MSwgTU9SVE9OLCBBTEZSRUQgQyAo QUwpIHdyb3RlOg0KPg0KPiBJ4oCZZCBsaWtlIHRvIG9mZmVyIHN1cHBvcnQgZm9yIFNwaW4gQml0 IChhbmQgb25lIG9yIHR3bw0KPg0KPiBiaXRzIGZvciBtYW5hZ2VtZW50IGlmIHRoZXkgY2FuIGJl IGp1c3RpZmllZCBxdWlja2x5KSBpbiB2MS4NCj4NCj4gT24gdGhpcyB0b3BpYyBvZiBtb3JlIGJp dHMsDQo+DQo+IGFza2luZyBmdXJ0aGVyIGNsYXJpZmljYXRpb24gZnJvbSBFbWlsZSwgYmVsb3cg W0FDTV0uDQo+DQo+IEFsDQo+DQo+ICpGcm9tOipRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnXSAqT24gQmVoYWxmIE9mICpJYW4gU3dldHQNCj4gKlNlbnQ6KiBUdWVzZGF5LCBOb3Zl bWJlciAxNCwgMjAxNyA0OjIxIFBNDQo+ICpUbzoqIGVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbQ0K PiAqQ2M6KiBRVUlDIFdHDQo+ICpTdWJqZWN0OiogUmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3Vi bGVzaG9vdGluZw0KPg0KPiBUaGFua3MgZm9yIGNsYXJpZnlpbmcgRW1pbGUuDQo+DQo+IE9uIFR1 ZSwgTm92IDE0LCAyMDE3IGF0IDE6MDYgUE0sIDxlbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20gDQo+ IDxtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPj4gd3JvdGU6DQo+DQo+IEhpIElhbiwN Cj4NCj4gSXQgd2FzIHN1Z2dlc3RlZCBpbiB0aGUgbGF0ZXN0IGRpc2N1c3Npb24gb24gdGhlIFJU VCBkZXNpZ24gdGVhbSANCj4gbWFpbGluZyBsaXN0IHRvIGhhdmUgb25lIGJpdCBmb3IgcGFja2V0 IGxvc3QsIG9uZSBmb3IgbGF0ZW5jeSAoc3BpbiANCj4gYml0IG9yIGVxLikgYW5kIG9uZSBmb3Ig Y29uZ2VzdGlvbi4NCj4NCj4gKi9bQUNNXSAvKiBUaGVyZSBtYXkgYmUgc29tZSBvdmVybGFwIHdp dGggRUNOIGFuZCDCqyBvbmUgYml0IGZvciANCj4gY29uZ2VzdGlvbiDCuy4NCj4NCj4gRGlkIHlv dSBhbHNvIGNvbnNpZGVyIHRoaXMgZGVwZW5kZW5jeSwgRW1pbGUgPyAoSeKAmW0gZWNob2luZyBh IGhhbGx3YXkNCj4gZGlzY3Vzc2lvbikNCj4NCj4gSXQgc2VlbXMgYSBzaW1wbGlzdGljIGFwcHJv YWNoIG9uIG9uZSBoYW5kIGJ1dCBhbiBpbnZhcmlhbnQgb24gdGhlIA0KPiBsb25nIHRlcm0uDQo+ DQo+IFJlZ2FyZHMNCj4NCj4gRW1pbGUNCj4NCj4gKkRlIDoqSWFuIFN3ZXR0IFttYWlsdG86aWFu c3dldHRAZ29vZ2xlLmNvbSANCj4gPG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPl0gKkVudm95 w6kgOiogbWFyZGkgMTQgbm92ZW1icmUgMjAxNyAyMjo1MSANCj4gKsOAIDoqIFNURVBIQU4gRW1p bGUgSU1UL09MTiAqQ2MgOiogUVVJQyBXRyAqT2JqZXQgOiogUmU6IHNwaW4gYml0IGluDQo+IFFV SUM6IHRyb3VibGVzaG9vdGluZw0KPg0KPiBXaGF0IHdvdWxkIHRoZSBvdGhlciBiaXQgb3IgdHdv IGJlIHVzZWQgZm9yPyAgSWYgdGhlcmUgaXMgbm8gDQo+IHN0YW5kYXJkaXplZCB1c2Ugb2YgdGhv c2UgYml0cyBpbiB2MSwgdGhlbiBJIGJlbGlldmUgd2Ugc2hvdWxkIHdhaXQgdG8gDQo+IHJlc2Vy dmUgdGhlbSB3aGVuIHRoZWlyIHVzYWdlIGlzIGRlZmluZWQsIGdpdmVuIHdlJ2QgbmVlZCBhIHZl cnNpb24gDQo+IGJ1bXAgdG8gc3BlY2lmeSBob3cgdGhleSB3ZXJlIGJlaW5nIHVzZWQuICBBdCB0 aGUgbW9tZW50LCB0aGUgDQo+IG1hbmFnZW1lbnQgdXNlIGNhc2UgaXMgbm90IGNvbXBldGluZyB3 aXRoIGFueW9uZSBlbHNlIGZvciBiaXRzIGluIHRoZSANCj4gc2hvcnQgaGVhZGVyLg0KPg0KPiBP biBUdWUsIE5vdiAxNCwgMjAxNyBhdCA1OjE0IEFNLCA8ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29t IA0KPiA8bWFpbHRvOmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbT4+IHdyb3RlOg0KPg0KPiBIaQ0K Pg0KPiBMYXN0IHdlZWsgT3JhbmdlIGV4cGVyaWVuY2VkIGEgZmFsbGJhY2sgb2YgUVVJQyB0byBU Q1Agb24gb25lIG9mIGl0cyANCj4gbmV0d29ya3MuIFRoZSBpc3N1ZXMgd2VyZSBub3QgdmlzaWJs ZSBpbiBRVUlDIHRyYWZmaWMuIFRoZSANCj4gdHJvdWJsZXNob290aW5nIHdhcyBtYWRlIHVzaW5n IFRDUCBwYWNrZXRzIGluZm9ybWF0aW9uLiBUaGlzIGlzIG5vdCANCj4gc3VzdGFpbmFibGUgb24g dGhlIGxvbmcgdGVybSB3aGVuIG51bWVyb3VzIGFwcGxpY2F0aW9ucyB1c2luZyANCj4gZGlmZmVy ZW50IHZlcnNpb25zIG9mIFFVSUMgd2lsbCBzdG9wIHRvIGZhbGxiYWNrIHRvIFRDUC4NCj4NCj4g QmFzZWQgb24gdGhlIGV4Y2hhbmdlIHdlIGhhZCBpbiB0aGUgUlRUIGRlc2lnbiB0ZWFtIGFuZCBp biB0b2RheSANCj4gbWVldGluZyAsIGl0IHNvdW5kcyByZWFzb25hYmxlIHRvIHJlc2VydmUgYXQg bGVhc3QgMiBiaXRzIChpZGVhbGx5IDMgDQo+IGJpdHMgYXMgZGlzY3Vzc2VkIGluIHRoZSBkZXNp Z24gdGVhbSkgZm9yIG1hbmFnZWFiaWxpdHkgaW4gdGhlIFFVSUMgDQo+IGludmFyaWFudHMgYW5k IHRvIHN0YXJ0IGV4cGVyaW1lbnRpbmcgdGhlIHNwaW4gYml0IGluIFFVSUMgVjEuDQo+DQo+IFJl Z2FyZHMNCj4NCj4gRW1pbGUNCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gICANCj4gQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIA0K PiBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMg ZXRyZSBkaWZmdXNlcywgDQo+IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24u IFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgDQo+IHBhciBlcnJldXIsIHZldWlsbGV6IGxl IHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGll Y2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxl cyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNl IG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCj4gICAN Cj4gVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIA0KPiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7IHRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2Ug YW5kIGl0cyBhdHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2Ug aXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5n ZWQgb3IgZmFsc2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ICAgDQo+ IENlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyANCj4gY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2 ZW50IGRvbmMgcGFzIGV0cmUgZGlmZnVzZXMsIA0KPiBleHBsb2l0ZXMgb3UgY29waWVzIHNhbnMg YXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIA0KPiBwYXIgZXJyZXVy LCB2ZXVpbGxleiBsZSBzaWduYWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5z aSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFu dCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25z YWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4g TWVyY2kuDQo+ICAgDQo+IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250 YWluIGNvbmZpZGVudGlhbCBvciANCj4gcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBi ZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQg b3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4NCj4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUg dGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuDQo+IEFzIGVtYWlscyBtYXkgYmUgYWx0 ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1v ZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4NCj4gVGhhbmsgeW91Lg0KPg0KCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18K CkNlIG1lc3NhZ2UgZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGlu Zm9ybWF0aW9ucyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQg ZG9uYwpwYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNh dGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBs ZSBzaWduYWxlcgphIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBp ZWNlcyBqb2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJs ZXMgZCdhbHRlcmF0aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBj ZSBtZXNzYWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlz IG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3Ig cHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5 IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9y aXNhdGlvbi4KSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNo bWVudHMuCkFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9y IG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4K VGhhbmsgeW91LgoK From nobody Wed Nov 15 02:00: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 A703A1243FE for ; Wed, 15 Nov 2017 02:00:49 -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, 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 (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 4OYBb_GZ_Lmo for ; Wed, 15 Nov 2017 02:00:46 -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 D24A7124205 for ; Wed, 15 Nov 2017 02:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1510740043; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:From:References:To: Subject; bh=y/g/MVVS1BlnCF7BMlBZJou5OVvtdOO5TxGzUwWU4+w=; b=CcZut66AcVTkhUqT1kdR4ro6Y2+9bkvArxVCpriX3W0DVYaL4f3mudWaDGlhKT40qm Roe86+4eQZKAzC4oIcrT1EQnl8Eaf96CZu83x7Uk/fN8rmHXg9LKch0aULGVXfzLP0Sf k4IHc3+tRTdx3UYLrexLKh16d9dZsZ/OyQIVw= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKm0oaa3tXPmXnk4ryDlA== X-RZG-CLASS-ID: mo00 Received: from [10.10.10.80] (p5DCF5EA2.dip0.t-ipconnect.de [93.207.94.162]) by smtp.strato.de (RZmta 42.9 DYNA|AUTH) with ESMTPSA id Z05d51tAFA0hdQe (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Wed, 15 Nov 2017 11:00:43 +0100 (CET) Subject: Re: ACKs in encrypted tunnel To: quic@ietf.org References: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> From: Roland Zink Message-ID: <4b4cc53c-25c0-1761-5cfd-ecc66f103de1@zinks.de> Date: Wed, 15 Nov 2017 11:00:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CBC3B6BC31DE1E701FB5F2FE" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:00:50 -0000 This is a multi-part message in MIME format. --------------CBC3B6BC31DE1E701FB5F2FE Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Not sure about that. The end user doesn't know how to do this and the OS are trying to ensure that this will not happen. Assuming it is easy to get the keys from users then this is a security problem. So we must assume keys are not available. Roland Am 15.11.2017 um 04:37 schrieb Mike Bishop: > > Also, if the end point(s) consent to give you the keys, nothing stops > you from inspecting a particular flow.  It requires the active > cooperation of at least one party to the connection, but if someone’s > calling you for help, that’s presumably the case. > > *From:*QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Roni Even > *Sent:* Wednesday, November 15, 2017 11:31 AM > *To:* Bret Jordan ; quic@ietf.org > *Subject:* RE: ACKs in encrypted tunnel > > Hi, > > This is discussed in the spin bit that was presented yesterday > > Roni > > *From:*QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Bret Jordan > *Sent:* יו× ד 15 נובמבר 2017 05:26 > *To:* quic@ietf.org > *Subject:* ACKs in encrypted tunnel > > So my understanding is that all ACKs and notices about lost packets, > frames, etc will be communicated inside the encrypted tunnel with QUIC. > > What is our plan to enable network operators to help troubleshoot > network problems with QUIC? > > When running a large network the network team / network operators are > often asked to help identify problems when an application is not > working or is sluggish. If all information is inside the encrypted > tunnel, are we just saying “end user and application support person, > you figure it out?†> > This seems like a huge problem.  I mean the network does not always > work flawlessly and it seems like we are removing all the abilities > for network operators to ensure any level of SLA or OLA. > > Bret > > Sent from my Commodore 128D > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050 > > --------------CBC3B6BC31DE1E701FB5F2FE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Not sure about that. The end user doesn't know how to do this and the OS are trying to ensure that this will not happen. Assuming it is easy to get the keys from users then this is a security problem. So we must assume keys are not available.


Roland



Am 15.11.2017 um 04:37 schrieb Mike Bishop:

Also, if the end point(s) consent to give you the keys, nothing stops you from inspecting a particular flow.  It requires the active cooperation of at least one party to the connection, but if someone’s calling you for help, that’s presumably the case.

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:31 AM
To: Bret Jordan <jordan.ietf@gmail.com>; quic@ietf.org
Subject: RE: ACKs in encrypted tunnel

 

Hi,

This is discussed in the spin bit that was presented yesterday

Roni

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Bret Jordan
Sent: יו× ד 15 נובמבר 2017 05:26
To: quic@ietf.org
Subject: ACKs in encrypted tunnel

 

So my understanding is that all ACKs and notices about lost packets, frames, etc will be communicated inside the encrypted tunnel with QUIC.

 

What is our plan to enable network operators to help troubleshoot network problems with QUIC? 

 

When running a large network the network team / network operators are often asked to help identify problems when an application is not working or is sluggish. If all information is inside the encrypted tunnel, are we just saying “end user and application support person, you figure it out?â€Â 

 

This seems like a huge problem.  I mean the network does not always work flawlessly and it seems like we are removing all the abilities for network operators to ensure any level of SLA or OLA.  

 

Bret 

 

Sent from my Commodore 128D

 

PGP Fingerprint: 63B4 FC53 680A 6B7D 1447  F2C0 74F8 ACAE 7415 0050


--------------CBC3B6BC31DE1E701FB5F2FE-- From nobody Wed Nov 15 02:38: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 7563D12706D for ; Wed, 15 Nov 2017 02:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 i5bOs8VMhuCC for ; Wed, 15 Nov 2017 02:38:45 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4DA126CC7 for ; Wed, 15 Nov 2017 02:38:45 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 48F7A13C79E7B for ; Wed, 15 Nov 2017 10:38:42 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 10:38:43 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 18:38:26 +0800 From: Roni Even To: Mike Bishop , QUIC WG Subject: RE: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQAAPS1iAAAgH6gAAC4MDgAAExe/AABPYHoA== Date: Wed, 15 Nov 2017 10:38:26 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.47.221] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8371EADGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:38:47 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8371EADGGEMM506MBXchina_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 10:18 To: Roni Even; QUIC WG Subject: RE: connection migration No; in the TCP case your transport doesn=92t have any migration provision, = so it=92s up to the application whether it wants to wind down the existing = connection and start a new one. If migration fails with QUIC, the situatio= n is exactly the same, and the application decides whether it wants to wind= down the existing connection and start a new one. If there=92s more than one application, then the answer to =93which applica= tion=94 is =93each application=94 because each application owns its own con= nections. [Roni Even] So we can end up with one application on the cell and the other= on the wifi. Nice!!! From: Roni Even [mailto:roni.even@huawei.com] Sent: Wednesday, November 15, 2017 3:44 PM To: Mike Bishop >; QUIC W= G > Subject: RE: connection migration inline From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 08:23 To: Roni Even; QUIC WG Subject: RE: connection migration Exactly the same way that TCP-to-TCP handoff between these interfaces works= today, because (non-MP) TCP isn=92t capable of changing to a different int= erface. We=92re trying to build a better answer, but you=92re positing fro= m the start that connection migration fails, so we=92re now in =93no worse= =94 land. The QUIC stack in the client device will see a new interface is available. = It attempts to switch to it, because of some local policy. The transition= fails for whatever reason, but the cellular connection is still active. I= t is the application=92s choice [Roni Even] which application if there is more than one? In the TCP case yo= u stay in the cell. Here there are two options, stay on the cell with QUIC = or move to wifi on TCP whether it wants to wind down and close that connection and start a new one= using TCP, or keep using the old one if the interface remains available. = If there are multiple applications, each application makes that choice inde= pendently. And if the first interface becomes unavailable for whatever reason, the cho= ice is made for it, and the application will have to recover. From: Roni Even [mailto:roni.even@huawei.com] Sent: Wednesday, November 15, 2017 1:25 PM To: Mike Bishop >; QUIC W= G > Subject: RE: connection migration So what is the connection migration flow here. The quic stack in the cell n= etwork will try to migrate to wifi without application request and fail but= will not fall back to TCP. There may be multiple application running over quic? HTTP and peer to peer = at the same time, so who will handle this case? Roni From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 05:35 To: Roni Even; QUIC WG Subject: RE: connection migration That may well be the case, but it=92s not the QUIC stack=92s choice to make= . The application could choose to open a new connection, but that remains = outside the scope of the transport and the mapping to it which we=92re defi= ning. For HTTP, this is fairly straightforward =96 it could stop issuing new flow= control credit, let currently-in-transit data arrive and any losses recove= red, and open a TCP connection to issue a range request starting at whateve= r data offset it hasn=92t seen. But that=92s still a property of an HTTP m= anagement above the HTTP/QUIC mapping. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, November 15, 2017 11:25 AM To: QUIC WG > Subject: connection migration Hi, When moving from cell to wifi the reason may be due to cost (money or quota= ). In this case the user (client) may want to move to wifi even if it will= mean dropping to TCP. Roni --_000_6E58094ECC8D8344914996DAD28F1CCD8371EADGGEMM506MBXchina_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

 

 

From: Mike Bis= hop [mailto:mbishop@evequefou.be]
Sent: =E9=E5=ED =E3 15 =F0=E5=E1= =EE=E1=F8 2017 10:18
To: Roni Even; QUIC WG
Subject: RE: connection migration

 

No; in the TCP case your transport doesn=92t have an= y migration provision, so it=92s up to the application whether it wants to = wind down the existing connection and start a new one.  If migration f= ails with QUIC, the situation is exactly the same, and the application decides whether it wants to wi= nd down the existing connection and start a new one.

 

If there=92s more than one application, then the ans= wer to =93which application=94 is =93each application=94 because each appli= cation owns its own connections.

[Roni Even] So w= e can end up with one application on the cell and the other on the wifi. Ni= ce!!!

 

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 3:44 PM
To: Mike Bishop <mbishop@= evequefou.be>; QUIC WG <quic@iet= f.org>
Subject: RE: connection migration

 

inline

 

 

Exactly the same way that TCP-to-TCP handoff between= these interfaces works today, because (non-MP) TCP isn=92t capable of chan= ging to a different interface.  We=92re trying to build a better answe= r, but you=92re positing from the start that connection migration fails, so we=92re now in =93no worse=94 land.

 

The QUIC stack in the client device will see a new i= nterface is available.  It attempts to switch to it, because of some l= ocal policy.  The transition fails for whatever reason, but the cellul= ar connection is still active.  It is the application=92s choice

[Roni Even] whic= h application if there is more than one? In the TCP case you stay in the ce= ll. Here there are two options, stay on the cell with QUIC or move to wifi = on TCP

whether it wants to wind down and close that connect= ion and start a new one using TCP, or keep using the old one if the interfa= ce remains available.  If there are multiple applications, each applic= ation makes that choice independently.

 

And if the first interface becomes unavailable for w= hatever reason, the choice is made for it, and the application will have to= recover.

 

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <mbishop@= evequefou.be>; QUIC WG <quic@iet= f.org>
Subject: RE: connection migration

 

So what is the connect= ion migration flow here. The quic stack in the cell network will try to mig= rate to wifi without application request and fail but will not fall back to= TCP.

There may be multiple = application running over quic? HTTP and peer to peer at the same time, so w= ho will handle this case?

 

Roni=

 

 

That may well be the case, but it=92s not the QUIC s= tack=92s choice to make.  The application could choose to open a new c= onnection, but that remains outside the scope of the transport and the mapp= ing to it which we=92re defining.

 

For HTTP, this is fairly straightforward =96 it coul= d stop issuing new flow control credit, let currently-in-transit data arriv= e and any losses recovered, and open a TCP connection to issue a range requ= est starting at whatever data offset it hasn=92t seen.  But that=92s still a property of an HTTP managemen= t above the HTTP/QUIC mapping.

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <quic@ietf.org&g= t;
Subject: connection migration

 

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the  user (client) may want to = move to wifi even if it will mean dropping to TCP.

 

Roni

--_000_6E58094ECC8D8344914996DAD28F1CCD8371EADGGEMM506MBXchina_-- From nobody Wed Nov 15 02:41: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 81A18129409 for ; Wed, 15 Nov 2017 02:41:02 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 9u8bjw1KXbo5 for ; Wed, 15 Nov 2017 02:41:00 -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 E9FEF12706D for ; Wed, 15 Nov 2017 02:40:59 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3ycLWZ3qxhz15MWB; Wed, 15 Nov 2017 11:40:58 +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 XCayYv1aLkGp; Wed, 15 Nov 2017 11:40:56 +0100 (CET) X-MtScore: NO score=0 Received: from dhcp-8cbf.meeting.ietf.org (dhcp-8cbf.meeting.ietf.org [31.133.140.191]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Wed, 15 Nov 2017 11:40:54 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: spin bit in QUIC From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <30502_1510736063_5A0C00BF_30502_41_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7EB1C@OPEXCLILM44.corporate.adroot.infra.ftgroup> Date: Wed, 15 Nov 2017 18:40:50 +0800 Cc: Piotr Galecki , "gorry@erg.abdn.ac.uk" , "MORTON, ALFRED C (AL)" , Ian Swett , emile.stephan@orange.com Content-Transfer-Encoding: quoted-printable Message-Id: <64D4260E-E58F-402B-895A-EEE1B81158B6@tik.ee.ethz.ch> References: <30502_1510736063_5A0C00BF_30502_41_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7EB1C@OPEXCLILM44.corporate.adroot.infra.ftgroup> To: QUIC WG X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:41:02 -0000 Hi all, we use two bits in ConEx for congestion exposure (however, that=E2=80=99s = in an IPv6 option that has its own (deployment) problems; see rfc7837). = The same scheme can be directly applied in QUIC. See also rfc7713 that = describes the abstract mechanisms behind this; however, note that this = was designed for congestion-based policing, but it also provides a = really nice measurement signal, especially when you can=E2=80=99t rely = on knowledge about retransmissions (which is the way congestion is = measured in TCP today). Just as some background information the = mechanisms that could be applied here. Mirja =20 > Am 15.11.2017 um 16:54 schrieb emile.stephan@orange.com: >=20 > Hi Al, >=20 > It's a good catch. My point is to have room for it in the invariant to = address the ossification concern. >=20 > Emile >=20 >=20 >=20 > On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote: >>=20 >> I=E2=80=99d like to offer support for Spin Bit (and one or two >>=20 >> bits for management if they can be justified quickly) in v1. >>=20 >> On this topic of more bits, >>=20 >> asking further clarification from Emile, below [ACM]. >>=20 >> Al >>=20 >> *From:*QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett >> *Sent:* Tuesday, November 14, 2017 4:21 PM >> *To:* emile.stephan@orange.com >> *Cc:* QUIC WG >> *Subject:* Re: spin bit in QUIC: troubleshooting >>=20 >> Thanks for clarifying Emile. >>=20 >> On Tue, Nov 14, 2017 at 1:06 PM, > > wrote: >>=20 >> Hi Ian, >>=20 >> It was suggested in the latest discussion on the RTT design team=20 >> mailing list to have one bit for packet lost, one for latency (spin=20= >> bit or eq.) and one for congestion. >>=20 >> */[ACM] /* There may be some overlap with ECN and =C2=AB one bit for=20= >> congestion =C2=BB. >>=20 >> Did you also consider this dependency, Emile ? (I=E2=80=99m echoing a = hallway >> discussion) >>=20 >> It seems a simplistic approach on one hand but an invariant on the=20 >> long term. >>=20 >> Regards >>=20 >> Emile >>=20 >> *De :*Ian Swett [mailto:ianswett@google.com=20 >> ] *Envoy=C3=A9 :* mardi 14 novembre 2017 = 22:51=20 >> *=C3=80 :* STEPHAN Emile IMT/OLN *Cc :* QUIC WG *Objet :* Re: spin = bit in >> QUIC: troubleshooting >>=20 >> What would the other bit or two be used for? If there is no=20 >> standardized use of those bits in v1, then I believe we should wait = to=20 >> reserve them when their usage is defined, given we'd need a version=20= >> bump to specify how they were being used. At the moment, the=20 >> management use case is not competing with anyone else for bits in the=20= >> short header. >>=20 >> On Tue, Nov 14, 2017 at 5:14 AM, > > wrote: >>=20 >> Hi >>=20 >> Last week Orange experienced a fallback of QUIC to TCP on one of its=20= >> networks. The issues were not visible in QUIC traffic. The=20 >> troubleshooting was made using TCP packets information. This is not=20= >> sustainable on the long term when numerous applications using=20 >> different versions of QUIC will stop to fallback to TCP. >>=20 >> Based on the exchange we had in the RTT design team and in today=20 >> meeting , it sounds reasonable to reserve at least 2 bits (ideally 3=20= >> bits as discussed in the design team) for manageability in the QUIC=20= >> invariants and to start experimenting the spin bit in QUIC V1. >>=20 >> Regards >>=20 >> Emile >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >> = ______________________________________________________________________ >> ___________________________________________________ >>=20 >> Ce message et ses pieces jointes peuvent contenir des informations=20 >> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,=20= >> exploites ou copies sans autorisation. Si vous avez recu ce message=20= >> par erreur, veuillez le signaler a l'expediteur et le detruire ainsi = que les pieces jointes. Les messages electroniques etant susceptibles = d'alteration, Orange decline toute responsabilite si ce message a ete = altere, deforme ou falsifie. Merci. >>=20 >> This message and its attachments may contain confidential or=20 >> privileged information that may be protected by law; they should not = be distributed, used or copied without authorisation. >> If you have received this email in error, please notify the sender = and delete this message and its attachments. >> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. >> Thank you. >>=20 >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 From nobody Wed Nov 15 03:02: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 5B7B9129435 for ; Wed, 15 Nov 2017 03:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=evequefou.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 t3YF8EtkGAV1 for ; Wed, 15 Nov 2017 03:02:34 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0108.outbound.protection.outlook.com [104.47.38.108]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C23B129426 for ; Wed, 15 Nov 2017 03:02:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rJWSUyRgLS/qpqqO4muw+AsxQDRE+rov7a1fchPD9WI=; b=nlgwNbm0di4krQObBwWMjkXCmJrcXM7s8leC8Z3ycU3SIYBl6Kb0SE7Lw1emT/aUv3Fdg1jks1aKminb4Mj5//KvDihZMzPswJfwuY+2UbYNQoVEqFrjDQvUnHAmzeRYKn9NtXa2uN4mcsjjF6ZwoBqBVPcIWV7TAVzpnfNCXyg= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2429.namprd08.prod.outlook.com (10.169.203.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Wed, 15 Nov 2017 11:02:32 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0239.005; Wed, 15 Nov 2017 11:02:32 +0000 From: Mike Bishop To: Roni Even , QUIC WG Subject: RE: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQAAPS1iAAAgH6gAAC4MDgAAExe/AABPYHoAAA0SZA Date: Wed, 15 Nov 2017 11:02:32 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=mbishop@evequefou.be; x-originating-ip: [2001:67c:370:1998:2868:bb72:748a:4414] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2429; 6:ZGgNp6m/URIGsK+SJ2gLTYwO9MyISJlfqRV2s4NYlNpjmYNF3hn/ETixel2IjTaHN1VMPnOSG8ZGFbDtqfQcA/P+4JCZFwoc4Q1A9Q0erfyCM4ofYfw5di6/g3vRI5y0fXnRv3PY+ujZp82VpckRUhXx+XT5qYwiP28kJjM7wpmxlQgXR1X4uyxsxfQ0Y0imE8oHYUgpWkt2v9zOMpiPgbo+DYcXqVF2zpRxuwYQddhglhSzO8aBdCrGv0+sGtOZV9aKN2HXh6D9vuwrI15x7NHbMp7MJQ2HIOdBQnixm4eAv8+x3WZwzlRfkFv7Ht2BKaTy0El5fXERXoplNCLl24UquH/RpUMlgPUPbSUXTvo=; 5:N7VnzawevrQ+Oxu9ZReoJz8hKuDDJOmNbaOPKFpEvO4RAsyAHYJEvnFothscYOxOfSLX0EZvky7KcuZNnOiZ1n1i2VIf+T4Q1B3aFcQ27md0zv8Zs+fdVrUSfcBA+sUMtKigs+tjxokDqoL4+LkT+1sRxrPmcL8DtJmNmd/jbUw=; 24:ez/7DkFFZKqC6vSvlPLYuuM63/741UULwHN/twXsfD0kdOBvizkoFLHvHPMSDL4kAwWmkNq/dVWR3g6rki2FbGGO/tPoS0OWJJtnKhwFqxw=; 7:+Qhu6Shgp4/YttulfjC4WVXafnZU3LyQUz5yZDdTqox5FPE1QsRzllllLP8VMn6ALxxSJuKDC5WMtda4W3hpZuYnIWB9s0AvU7gyVrC0sfABgHadIb/It/Wq3AjZeL2LiESbstFEawsL0A0FZZc2u6u9yEfr5TRlpvGk9f1k3Ft4yZJLAH7MlgPVHCvZ4slfQgG2F69TVwJx9wlGYuU7MTNDz6DUX07maEZaBzRMnGjzpJfi9CQc4NrMlj+JWYZy x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: f365f1d9-17a1-4b26-2098-08d52c185ea9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603199); SRVR:MWHPR08MB2429; x-ms-traffictypediagnostic: MWHPR08MB2429: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(278428928389397)(50582790962513)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(3231022)(6041248)(20161123562025)(20161123555025)(2016111802025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(6043046)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2429; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2429; x-forefront-prvs: 0492FD61DD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39830400002)(199003)(189002)(76176999)(7696004)(54356999)(74482002)(316002)(6436002)(99286004)(55016002)(2906002)(110136005)(33656002)(101416001)(81166006)(8676002)(81156014)(74316002)(53546010)(25786009)(8936002)(2950100002)(7116003)(3480700004)(5660300001)(2900100001)(50986999)(6506006)(77096006)(7736002)(229853002)(106356001)(97736004)(19609705001)(105586002)(14454004)(6246003)(478600001)(221733001)(9686003)(68736007)(6306002)(54896002)(236005)(53936002)(6116002)(102836003)(790700001)(3660700001)(3280700002)(189998001)(93886005)(86362001)(111123002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2429; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB24327938B246743D78C45F94DA290MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: f365f1d9-17a1-4b26-2098-08d52c185ea9 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Nov 2017 11:02:32.0210 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2429 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 11:02:37 -0000 --_000_MWHPR08MB24327938B246743D78C45F94DA290MWHPR08MB2432namp_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Your sarcasm notwithstanding, I=92ll emphasize that this is identical to TC= P today. Either the applications move, or they don=92t. If the device for= cibly brings down the cellular interface=92s data connection, the applicati= ons will have to move if they didn=92t already move gracefully, which is in= dependent of the transport=92s properties. From: Roni Even [mailto:roni.even@huawei.com] Sent: Wednesday, November 15, 2017 6:38 PM To: Mike Bishop ; QUIC WG Subject: RE: connection migration From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 10:18 To: Roni Even; QUIC WG Subject: RE: connection migration No; in the TCP case your transport doesn=92t have any migration provision, = so it=92s up to the application whether it wants to wind down the existing = connection and start a new one. If migration fails with QUIC, the situatio= n is exactly the same, and the application decides whether it wants to wind= down the existing connection and start a new one. If there=92s more than one application, then the answer to =93which applica= tion=94 is =93each application=94 because each application owns its own con= nections. [Roni Even] So we can end up with one application on the cell and the other= on the wifi. Nice!!! From: Roni Even [mailto:roni.even@huawei.com] Sent: Wednesday, November 15, 2017 3:44 PM To: Mike Bishop >; QUIC W= G > Subject: RE: connection migration inline From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 08:23 To: Roni Even; QUIC WG Subject: RE: connection migration Exactly the same way that TCP-to-TCP handoff between these interfaces works= today, because (non-MP) TCP isn=92t capable of changing to a different int= erface. We=92re trying to build a better answer, but you=92re positing fro= m the start that connection migration fails, so we=92re now in =93no worse= =94 land. The QUIC stack in the client device will see a new interface is available. = It attempts to switch to it, because of some local policy. The transition= fails for whatever reason, but the cellular connection is still active. I= t is the application=92s choice [Roni Even] which application if there is more than one? In the TCP case yo= u stay in the cell. Here there are two options, stay on the cell with QUIC = or move to wifi on TCP whether it wants to wind down and close that connection and start a new one= using TCP, or keep using the old one if the interface remains available. = If there are multiple applications, each application makes that choice inde= pendently. And if the first interface becomes unavailable for whatever reason, the cho= ice is made for it, and the application will have to recover. From: Roni Even [mailto:roni.even@huawei.com] Sent: Wednesday, November 15, 2017 1:25 PM To: Mike Bishop >; QUIC W= G > Subject: RE: connection migration So what is the connection migration flow here. The quic stack in the cell n= etwork will try to migrate to wifi without application request and fail but= will not fall back to TCP. There may be multiple application running over quic? HTTP and peer to peer = at the same time, so who will handle this case? Roni From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: =E9=E5=ED =E3 15 =F0=E5=E1=EE=E1=F8 2017 05:35 To: Roni Even; QUIC WG Subject: RE: connection migration That may well be the case, but it=92s not the QUIC stack=92s choice to make= . The application could choose to open a new connection, but that remains = outside the scope of the transport and the mapping to it which we=92re defi= ning. For HTTP, this is fairly straightforward =96 it could stop issuing new flow= control credit, let currently-in-transit data arrive and any losses recove= red, and open a TCP connection to issue a range request starting at whateve= r data offset it hasn=92t seen. But that=92s still a property of an HTTP m= anagement above the HTTP/QUIC mapping. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even Sent: Wednesday, November 15, 2017 11:25 AM To: QUIC WG > Subject: connection migration Hi, When moving from cell to wifi the reason may be due to cost (money or quota= ). In this case the user (client) may want to move to wifi even if it will= mean dropping to TCP. Roni --_000_MWHPR08MB24327938B246743D78C45F94DA290MWHPR08MB2432namp_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Your sarcasm notwithstanding, I=92ll emphasize that = this is identical to TCP today.  Either the applications move, or they= don=92t.  If the device forcibly brings down the cellular interface= =92s data connection, the applications will have to move if they didn=92t already move gracefully, which is independent of the= transport=92s properties.

 

From: Roni Even [mailto:roni.even@huawei.com]=
Sent: Wednesday, November 15, 2017 6:38 PM
To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.= org>
Subject: RE: connection migration

 

 

 

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =E9=E5=ED =E3 15 =F0=E5=E1= =EE=E1=F8 2017 10:18
To: Roni Even; QUIC WG
Subject: RE: connection migration

 

No; in the TCP case your transport doesn=92t have an= y migration provision, so it=92s up to the application whether it wants to = wind down the existing connection and start a new one.  If migration f= ails with QUIC, the situation is exactly the same, and the application decides whether it wants to wi= nd down the existing connection and start a new one.

 

If there=92s more than one application, then the ans= wer to =93which application=94 is =93each application=94 because each appli= cation owns its own connections.

[Roni Even] So w= e can end up with one application on the cell and the other on the wifi. Ni= ce!!!

 

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 3:44 PM
To: Mike Bishop <mbishop@= evequefou.be>; QUIC WG <quic@iet= f.org>
Subject: RE: connection migration

 

inline

 

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =E9=E5=ED =E3 15 =F0=E5=E1= =EE=E1=F8 2017 08:23
To: Roni Even; QUIC WG
Subject: RE: connection migration

 

Exactly the same way that TCP-to-TCP handoff between= these interfaces works today, because (non-MP) TCP isn=92t capable of chan= ging to a different interface.  We=92re trying to build a better answe= r, but you=92re positing from the start that connection migration fails, so we=92re now in =93no worse=94 land.

 

The QUIC stack in the client device will see a new i= nterface is available.  It attempts to switch to it, because of some l= ocal policy.  The transition fails for whatever reason, but the cellul= ar connection is still active.  It is the application=92s choice

[Roni Even] whic= h application if there is more than one? In the TCP case you stay in the ce= ll. Here there are two options, stay on the cell with QUIC or move to wifi = on TCP

whether it wants to wind down and close that connect= ion and start a new one using TCP, or keep using the old one if the interfa= ce remains available.  If there are multiple applications, each applic= ation makes that choice independently.

 

And if the first interface becomes unavailable for w= hatever reason, the choice is made for it, and the application will have to= recover.

 

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <mbishop@= evequefou.be>; QUIC WG <quic@iet= f.org>
Subject: RE: connection migration

 

So what is the connect= ion migration flow here. The quic stack in the cell network will try to mig= rate to wifi without application request and fail but will not fall back to= TCP.

There may be multiple = application running over quic? HTTP and peer to peer at the same time, so w= ho will handle this case?

 

Roni=

 

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =E9=E5=ED =E3 = 15 =F0=E5=E1=EE=E1=F8 <= /span><= /span>2017 05:35
To: Roni Even; QUIC WG
Subject: RE: connection migration

 

That may well be the case, but it=92s not the QUIC s= tack=92s choice to make.  The application could choose to open a new c= onnection, but that remains outside the scope of the transport and the mapp= ing to it which we=92re defining.

 

For HTTP, this is fairly straightforward =96 it coul= d stop issuing new flow control credit, let currently-in-transit data arriv= e and any losses recovered, and open a TCP connection to issue a range requ= est starting at whatever data offset it hasn=92t seen.  But that=92s still a property of an HTTP managemen= t above the HTTP/QUIC mapping.

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <quic@ietf.org&g= t;
Subject: connection migration

 

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the  user (client) may want to = move to wifi even if it will mean dropping to TCP.

 

Roni

--_000_MWHPR08MB24327938B246743D78C45F94DA290MWHPR08MB2432namp_-- From nobody Wed Nov 15 03:42: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 447E1126FB3 for ; Wed, 15 Nov 2017 03:42:50 -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, 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 uVDmuN0-teoQ for ; Wed, 15 Nov 2017 03:42:47 -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 88D16124BE8 for ; Wed, 15 Nov 2017 03:42:47 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id d2so11662152ywb.11 for ; Wed, 15 Nov 2017 03:42:47 -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=mPtDI98uQaSR3AfWfzCeojGeChx/6g2x2PJK8P380iY=; b=co8lehDYi9KyG0VLVxO48pa+UaO87c8JVu+Wk1B6qJ257pY10+ovwgS9kQ/NWX8mTK dt+tqh+1HY8nYn7Ths+AuhSwBnR+7R+Ih3TOwbdR92bUDTKOZqfkw59YxeX3QEtshGsy FmgSnLcpE0g4AXefNqcCFM31oDXH9tW2/uL+3jR3lAfDO2FmFpx5ANPTel+hCSI7ZCOi a87UiyMB8YNV9/F6pNwp8aEJ+9OqSRNIcMUh/pFz2zRvnlxevdmBVHkvQneMCNFJ4YU9 p04Tx6ZyqiJAg5qorJglvXqWSR7J+3WeJkxX8LdWYNpuTMRyqDZ2l/oIO8wY/eYuvvNb dJPw== 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=mPtDI98uQaSR3AfWfzCeojGeChx/6g2x2PJK8P380iY=; b=HyueTWeRyNrFUyfqj6K2ZqfyuSnhIT0U5219fMW7JfzGnfHjGIL2+swufkNwoUE6aW 1Oc5SyOF0MHprky3nfo/fiQBJa9BCmXZD3lXcA3ycOGU48gjQsqQomfeKX29RjmKszJf AvBsUQvLRTdzKcen1S+OlqgYUZXnMlLYgQO1oB+6QLS3K47qDCnASXe4R3RPxL3hNK3D giSFgB98ZwWBn7AU8fRmPx4LU7b2GTvleOrvvs/nhiuOfysYwUeeNicaKI/aOwvWHprR ln9iXWwnQ56wxmA/JUuIKQi34ZH+Hh2Tsxx5i4AYP8M6Sn+qihXOVp24uL/x9GamZjLK LYRQ== X-Gm-Message-State: AJaThX5DI7iOiEs8HLlRVF1BcWoErQI3r7ISr8i3piYEB857XXGQoKzx FDPIt0C458U9zxmLZ1mpiofO6iS4iGduC8pMsoruiA== X-Google-Smtp-Source: AGs4zMbI6yzOqvk/vinI5huIknLJ8ZJVKHKptc/EICuMemGWFB6BdkSHlCIvgv+bJNfxTvFwneBW6Ku+rmRI2JeNu3g= X-Received: by 10.37.132.73 with SMTP id r9mr9149210ybm.323.1510746166315; Wed, 15 Nov 2017 03:42:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.70.5 with HTTP; Wed, 15 Nov 2017 03:42:45 -0800 (PST) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> From: Jana Iyengar Date: Wed, 15 Nov 2017 19:42:45 +0800 Message-ID: Subject: Re: connection migration To: Mike Bishop Cc: Roni Even , QUIC WG Content-Type: multipart/alternative; boundary="089e0826fee497c185055e04000b" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 11:42:50 -0000 --089e0826fee497c185055e04000b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable What Mike said. The scope of QUIC, by definition, is not larger than QUIC. On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop wrote: > Your sarcasm notwithstanding, I=E2=80=99ll emphasize that this is identic= al to TCP > today. Either the applications move, or they don=E2=80=99t. If the devi= ce > forcibly brings down the cellular interface=E2=80=99s data connection, th= e > applications will have to move if they didn=E2=80=99t already move gracef= ully, > which is independent of the transport=E2=80=99s properties. > > > > *From:* Roni Even [mailto:roni.even@huawei.com] > *Sent:* Wednesday, November 15, 2017 6:38 PM > > *To:* Mike Bishop ; QUIC WG > *Subject:* RE: connection migration > > > > > > > > *From:* Mike Bishop [mailto:mbishop@evequefou.be ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 10:18 > *To:* Roni Even; QUIC WG > *Subject:* RE: connection migration > > > > No; in the TCP case your transport doesn=E2=80=99t have any migration pro= vision, > so it=E2=80=99s up to the application whether it wants to wind down the e= xisting > connection and start a new one. If migration fails with QUIC, the > situation is *exactly the same*, and the application decides whether it > wants to wind down the existing connection and start a new one. > > > > If there=E2=80=99s more than one application, then the answer to =E2=80= =9Cwhich > application=E2=80=9D is =E2=80=9Ceach application=E2=80=9D because each a= pplication owns its own > connections. > > *[Roni Even] So we can end up with one application on the cell and the > other on the wifi. Nice!!!* > > > > *From:* Roni Even [mailto:roni.even@huawei.com ] > *Sent:* Wednesday, November 15, 2017 3:44 PM > *To:* Mike Bishop ; QUIC WG > *Subject:* RE: connection migration > > > > inline > > > > *From:* Mike Bishop [mailto:mbishop@evequefou.be ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 08:23 > *To:* Roni Even; QUIC WG > *Subject:* RE: connection migration > > > > Exactly the same way that TCP-to-TCP handoff between these interfaces > works today, because (non-MP) TCP isn=E2=80=99t capable of changing to a = different > interface. We=E2=80=99re trying to build a better answer, but you=E2=80= =99re positing from > the start that connection migration fails, so we=E2=80=99re now in =E2=80= =9Cno worse=E2=80=9D land. > > > > The QUIC stack in the client device will see a new interface is > available. It attempts to switch to it, because of some local policy. T= he > transition fails for whatever reason, but the cellular connection is stil= l > active. It is the application=E2=80=99s choice > > *[Roni Even] which application if there is more than one? In the TCP case > you stay in the cell. Here there are two options, stay on the cell with > QUIC or move to wifi on TCP* > > whether it wants to wind down and close that connection and start a new > one using TCP, or keep using the old one if the interface remains > available. If there are multiple applications, each application makes th= at > choice independently. > > > > And if the first interface becomes unavailable for whatever reason, the > choice is made for it, and the application will have to recover. > > > > *From:* Roni Even [mailto:roni.even@huawei.com ] > *Sent:* Wednesday, November 15, 2017 1:25 PM > *To:* Mike Bishop ; QUIC WG > *Subject:* RE: connection migration > > > > So what is the connection migration flow here. The quic stack in the cell > network will try to migrate to wifi without application request and fail > but will not fall back to TCP. > > There may be multiple application running over quic? HTTP and peer to pee= r > at the same time, so who will handle this case? > > > > Roni > > > > *From:* Mike Bishop [mailto:mbishop@evequefou.be ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 05:35 > *To:* Roni Even; QUIC WG > *Subject:* RE: connection migration > > > > That may well be the case, but it=E2=80=99s not the QUIC stack=E2=80=99s = choice to make. > The application could choose to open a new connection, but that remains > outside the scope of the transport and the mapping to it which we=E2=80= =99re > defining. > > > > For HTTP, this is fairly straightforward =E2=80=93 it could stop issuing = new flow > control credit, let currently-in-transit data arrive and any losses > recovered, and open a TCP connection to issue a range request starting at > whatever data offset it hasn=E2=80=99t seen. But that=E2=80=99s still a = property of an > HTTP management above the HTTP/QUIC mapping. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Roni Even > *Sent:* Wednesday, November 15, 2017 11:25 AM > *To:* QUIC WG > *Subject:* connection migration > > > > Hi, > > When moving from cell to wifi the reason may be due to cost (money or > quota). In this case the user (client) may want to move to wifi even if = it > will mean dropping to TCP. > > > > Roni > --089e0826fee497c185055e04000b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
What Mike said. The scope of QUIC, by definition, is = not larger than QUIC.

On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop <mbis= hop@evequefou.be> wrote:

Your sarcasm notwithstanding, I=E2=80=99ll emphasize= that this is identical to TCP today.=C2=A0 Either the applications move, o= r they don=E2=80=99t.=C2=A0 If the device forcibly brings down the cellular= interface=E2=80=99s data connection, the applications will have to move if they didn=E2=80=99t already move gracefully, which is independent = of the transport=E2=80=99s properties.

=C2=A0

=C2=A0

=C2=A0

=C2=A0

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 1= 5 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 10:18
To: Roni Even; QUIC WG
Subject: RE: connection migration

=C2=A0

No; in the TCP case your transport doesn=E2=80=99t h= ave any migration provision, so it=E2=80=99s up to the application whether = it wants to wind down the existing connection and start a new one.=C2=A0 If= migration fails with QUIC, the situation is exactly the same, and the application decides whether it wants to wi= nd down the existing connection and start a new one.

=C2=A0

If there=E2=80=99s more than one application, then t= he answer to =E2=80=9Cwhich application=E2=80=9D is =E2=80=9Ceach applicati= on=E2=80=9D because each application owns its own connections.

[Roni Even] So w= e can end up with one application on the cell and the other on the wifi. Ni= ce!!!

=C2=A0

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 3:44 PM
To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.org>
Subject: RE: connection migration

=C2=A0

inline

=C2=A0

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 1= 5 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 08:23
To: Roni Even; QUIC WG
Subject: RE: connection migration

=C2=A0

Exactly the same way that TCP-to-TCP handoff between= these interfaces works today, because (non-MP) TCP isn=E2=80=99t capable o= f changing to a different interface.=C2=A0 We=E2=80=99re trying to build a = better answer, but you=E2=80=99re positing from the start that connection migration fails, so we=E2=80=99re now in =E2=80=9Cno worse=E2= =80=9D land.

=C2=A0

The QUIC stack in the client device will see a new i= nterface is available.=C2=A0 It attempts to switch to it, because of some l= ocal policy.=C2=A0 The transition fails for whatever reason, but the cellul= ar connection is still active.=C2=A0 It is the application=E2=80=99s choice

[Roni Even] whic= h application if there is more than one? In the TCP case you stay in the ce= ll. Here there are two options, stay on the cell with QUIC or move to wifi = on TCP

whether it wants to wind down and close that connect= ion and start a new one using TCP, or keep using the old one if the interfa= ce remains available.=C2=A0 If there are multiple applications, each applic= ation makes that choice independently.

=C2=A0

And if the first interface becomes unavailable for w= hatever reason, the choice is made for it, and the application will have to= recover.

=C2=A0

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.org>
Subject: RE: connection migration

=C2=A0

So what is the connect= ion migration flow here. The quic stack in the cell network will try to mig= rate to wifi without application request and fail but will not fall back to= TCP.

There may be multiple = application running over quic? HTTP and peer to peer at the same time, so w= ho will handle this case?

=C2=A0

Roni<= /u>

=C2=A0

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 = 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 <= span dir=3D"LTR"><= span dir=3D"LTR">2017 05:35
To: Roni Even; QUIC WG
Subject: RE: connection migration

=C2=A0

That may well be the case, but it=E2=80=99s not the = QUIC stack=E2=80=99s choice to make.=C2=A0 The application could choose to = open a new connection, but that remains outside the scope of the transport = and the mapping to it which we=E2=80=99re defining.

=C2=A0

For HTTP, this is fairly straightforward =E2=80=93 i= t could stop issuing new flow control credit, let currently-in-transit data= arrive and any losses recovered, and open a TCP connection to issue a rang= e request starting at whatever data offset it hasn=E2=80=99t seen.=C2=A0 But that=E2=80=99s still a property of an HT= TP management above the HTTP/QUIC mapping.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <q= uic@ietf.org>
Subject: connection migration

=C2=A0

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the=C2=A0 user (client) may want to = move to wifi even if it will mean dropping to TCP.

=C2=A0

Roni


--089e0826fee497c185055e04000b-- From nobody Wed Nov 15 06:21: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 46231129484 for ; Wed, 15 Nov 2017 06:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, 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 ACENyzY5AYp8 for ; Wed, 15 Nov 2017 06:21:15 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 8344F12025C for ; Wed, 15 Nov 2017 06:21:15 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id D86E21A8E99E0 for ; Wed, 15 Nov 2017 14:21:11 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 14:21:13 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 22:21:09 +0800 From: Roni Even To: Jana Iyengar , Mike Bishop CC: QUIC WG Subject: RE: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQAAPS1iAAAgH6gAAC4MDgAAExe/AABPYHoAAA0SZA//+FloD//1OtwA== Date: Wed, 15 Nov 2017 14:21:09 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD837234@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.47.150] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD837234DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:21:18 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD837234DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJIGFwb2xvZ2l6ZSBpZiBhbnlvbmUgZmVsdCB0aGF0IEkgd2FzIGJlaW5nIHNhcmNhc3Rp Yy4gVG8gbWUgaXQgbG9va3MgdGhhdCB0aGVyZSBpcyBzb21lIGRpZmZlcmVuY2UuIE15IHVuZGVy c3RhbmRpbmcgdGhhdCB0aGVyZSBpcyBzZXBhcmF0aW9uIGJldHdlZW4gdGhlIHRyYW5zcG9ydCAo UVVJQykgYW5kIHRoZSBhcHBsaWNhdGlvbiAoSFRUUCBmaXJzdCBhbmQgb3RoZXIgbGF0ZXIpLg0K QW4gYXBwbGljYXRpb24gY2FuIHNlZSBpbiB0aGUgVENQIGNhc2UgdHdvIG9wdGlvbnMgVENQIG9u IG9yIFRDUCBvZmYuIEluIFFVSUMgaXQgc2VlcyB0aHJlZSBvcHRpb25zIFFVSUMgb24sIFFVSUMg b2ZmIChubyBjb25uZWN0aW9uKSwgVENQLiBJZiBvbmUgb2YgdGhlIHBoeXNpY2FsIGNvbm5lY3Rp b24gaXMgY2xvc2VkIHRoZXJlIGlzIG5vIHByb2JsZW0uIEkgYXNzdW1lZCB0aGF0IGJvdGggcGh5 c2ljYWwgY29ubmVjdGlvbiBhcmUga2VwdCBvcGVuICh3aGVuIEkgZW50ZXIgdGhlIGhvdXNlIEkg Y29ubmVjdCB0byB0aGUgQVAgYnV0IHRoZSAzRyBkYXRhIGNoYW5uZWwgaXMgc3RpbGwgb3Blbikg YnV0IHRoZSBhcHBsaWNhdGlvbiB3aWxsIHRyeSB0byBzZW5kIGRhdGEgb24gdGhlIHdpZmkgbmV0 d29yayBhbmQgbm90IG9uIHRoZSBjZWxsdWxhciBuZXR3b3JrIHNpbmNlIHRoaXMgaXMgdGhlIHBv bGljeSwgYW0gSSB3cm9uZz8NClJvbmkNCg0KRnJvbTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJp QGdvb2dsZS5jb21dDQpTZW50OiDXmdeV150g15MgMTUg16DXldeR157XkdeoIDIwMTcgMTM6NDMN ClRvOiBNaWtlIEJpc2hvcA0KQ2M6IFJvbmkgRXZlbjsgUVVJQyBXRw0KU3ViamVjdDogUmU6IGNv bm5lY3Rpb24gbWlncmF0aW9uDQoNCldoYXQgTWlrZSBzYWlkLiBUaGUgc2NvcGUgb2YgUVVJQywg YnkgZGVmaW5pdGlvbiwgaXMgbm90IGxhcmdlciB0aGFuIFFVSUMuDQoNCk9uIFdlZCwgTm92IDE1 LCAyMDE3IGF0IDc6MDIgUE0sIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWls dG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3cm90ZToNCllvdXIgc2FyY2FzbSBub3R3aXRoc3Rh bmRpbmcsIEnigJlsbCBlbXBoYXNpemUgdGhhdCB0aGlzIGlzIGlkZW50aWNhbCB0byBUQ1AgdG9k YXkuICBFaXRoZXIgdGhlIGFwcGxpY2F0aW9ucyBtb3ZlLCBvciB0aGV5IGRvbuKAmXQuICBJZiB0 aGUgZGV2aWNlIGZvcmNpYmx5IGJyaW5ncyBkb3duIHRoZSBjZWxsdWxhciBpbnRlcmZhY2XigJlz IGRhdGEgY29ubmVjdGlvbiwgdGhlIGFwcGxpY2F0aW9ucyB3aWxsIGhhdmUgdG8gbW92ZSBpZiB0 aGV5IGRpZG7igJl0IGFscmVhZHkgbW92ZSBncmFjZWZ1bGx5LCB3aGljaCBpcyBpbmRlcGVuZGVu dCBvZiB0aGUgdHJhbnNwb3J04oCZcyBwcm9wZXJ0aWVzLg0KDQpGcm9tOiBSb25pIEV2ZW4gW21h aWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbTxtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20+XQ0K U2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyA2OjM4IFBNDQoNClRvOiBNaWtlIEJp c2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj47 IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDog UkU6IGNvbm5lY3Rpb24gbWlncmF0aW9uDQoNCg0KDQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRv Om1iaXNob3BAZXZlcXVlZm91LmJlXQ0KU2VudDog15nXldedINeTIDE1INeg15XXkdee15HXqCAy MDE3IDEwOjE4DQpUbzogUm9uaSBFdmVuOyBRVUlDIFdHDQpTdWJqZWN0OiBSRTogY29ubmVjdGlv biBtaWdyYXRpb24NCg0KTm87IGluIHRoZSBUQ1AgY2FzZSB5b3VyIHRyYW5zcG9ydCBkb2VzbuKA mXQgaGF2ZSBhbnkgbWlncmF0aW9uIHByb3Zpc2lvbiwgc28gaXTigJlzIHVwIHRvIHRoZSBhcHBs aWNhdGlvbiB3aGV0aGVyIGl0IHdhbnRzIHRvIHdpbmQgZG93biB0aGUgZXhpc3RpbmcgY29ubmVj dGlvbiBhbmQgc3RhcnQgYSBuZXcgb25lLiAgSWYgbWlncmF0aW9uIGZhaWxzIHdpdGggUVVJQywg dGhlIHNpdHVhdGlvbiBpcyBleGFjdGx5IHRoZSBzYW1lLCBhbmQgdGhlIGFwcGxpY2F0aW9uIGRl Y2lkZXMgd2hldGhlciBpdCB3YW50cyB0byB3aW5kIGRvd24gdGhlIGV4aXN0aW5nIGNvbm5lY3Rp b24gYW5kIHN0YXJ0IGEgbmV3IG9uZS4NCg0KSWYgdGhlcmXigJlzIG1vcmUgdGhhbiBvbmUgYXBw bGljYXRpb24sIHRoZW4gdGhlIGFuc3dlciB0byDigJx3aGljaCBhcHBsaWNhdGlvbuKAnSBpcyDi gJxlYWNoIGFwcGxpY2F0aW9u4oCdIGJlY2F1c2UgZWFjaCBhcHBsaWNhdGlvbiBvd25zIGl0cyBv d24gY29ubmVjdGlvbnMuDQpbUm9uaSBFdmVuXSBTbyB3ZSBjYW4gZW5kIHVwIHdpdGggb25lIGFw cGxpY2F0aW9uIG9uIHRoZSBjZWxsIGFuZCB0aGUgb3RoZXIgb24gdGhlIHdpZmkuIE5pY2UhISEN Cg0KRnJvbTogUm9uaSBFdmVuIFttYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb21dDQpTZW50OiBX ZWRuZXNkYXksIE5vdmVtYmVyIDE1LCAyMDE3IDM6NDQgUE0NClRvOiBNaWtlIEJpc2hvcCA8bWJp c2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj47IFFVSUMgV0cg PHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IGNvbm5l Y3Rpb24gbWlncmF0aW9uDQoNCmlubGluZQ0KDQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOm1i aXNob3BAZXZlcXVlZm91LmJlXQ0KU2VudDog15nXldedINeTIDE1INeg15XXkdee15HXqCAyMDE3 IDA4OjIzDQpUbzogUm9uaSBFdmVuOyBRVUlDIFdHDQpTdWJqZWN0OiBSRTogY29ubmVjdGlvbiBt aWdyYXRpb24NCg0KRXhhY3RseSB0aGUgc2FtZSB3YXkgdGhhdCBUQ1AtdG8tVENQIGhhbmRvZmYg YmV0d2VlbiB0aGVzZSBpbnRlcmZhY2VzIHdvcmtzIHRvZGF5LCBiZWNhdXNlIChub24tTVApIFRD UCBpc27igJl0IGNhcGFibGUgb2YgY2hhbmdpbmcgdG8gYSBkaWZmZXJlbnQgaW50ZXJmYWNlLiAg V2XigJlyZSB0cnlpbmcgdG8gYnVpbGQgYSBiZXR0ZXIgYW5zd2VyLCBidXQgeW914oCZcmUgcG9z aXRpbmcgZnJvbSB0aGUgc3RhcnQgdGhhdCBjb25uZWN0aW9uIG1pZ3JhdGlvbiBmYWlscywgc28g d2XigJlyZSBub3cgaW4g4oCcbm8gd29yc2XigJ0gbGFuZC4NCg0KVGhlIFFVSUMgc3RhY2sgaW4g dGhlIGNsaWVudCBkZXZpY2Ugd2lsbCBzZWUgYSBuZXcgaW50ZXJmYWNlIGlzIGF2YWlsYWJsZS4g IEl0IGF0dGVtcHRzIHRvIHN3aXRjaCB0byBpdCwgYmVjYXVzZSBvZiBzb21lIGxvY2FsIHBvbGlj eS4gIFRoZSB0cmFuc2l0aW9uIGZhaWxzIGZvciB3aGF0ZXZlciByZWFzb24sIGJ1dCB0aGUgY2Vs bHVsYXIgY29ubmVjdGlvbiBpcyBzdGlsbCBhY3RpdmUuICBJdCBpcyB0aGUgYXBwbGljYXRpb27i gJlzIGNob2ljZQ0KW1JvbmkgRXZlbl0gd2hpY2ggYXBwbGljYXRpb24gaWYgdGhlcmUgaXMgbW9y ZSB0aGFuIG9uZT8gSW4gdGhlIFRDUCBjYXNlIHlvdSBzdGF5IGluIHRoZSBjZWxsLiBIZXJlIHRo ZXJlIGFyZSB0d28gb3B0aW9ucywgc3RheSBvbiB0aGUgY2VsbCB3aXRoIFFVSUMgb3IgbW92ZSB0 byB3aWZpIG9uIFRDUA0Kd2hldGhlciBpdCB3YW50cyB0byB3aW5kIGRvd24gYW5kIGNsb3NlIHRo YXQgY29ubmVjdGlvbiBhbmQgc3RhcnQgYSBuZXcgb25lIHVzaW5nIFRDUCwgb3Iga2VlcCB1c2lu ZyB0aGUgb2xkIG9uZSBpZiB0aGUgaW50ZXJmYWNlIHJlbWFpbnMgYXZhaWxhYmxlLiAgSWYgdGhl cmUgYXJlIG11bHRpcGxlIGFwcGxpY2F0aW9ucywgZWFjaCBhcHBsaWNhdGlvbiBtYWtlcyB0aGF0 IGNob2ljZSBpbmRlcGVuZGVudGx5Lg0KDQpBbmQgaWYgdGhlIGZpcnN0IGludGVyZmFjZSBiZWNv bWVzIHVuYXZhaWxhYmxlIGZvciB3aGF0ZXZlciByZWFzb24sIHRoZSBjaG9pY2UgaXMgbWFkZSBm b3IgaXQsIGFuZCB0aGUgYXBwbGljYXRpb24gd2lsbCBoYXZlIHRvIHJlY292ZXIuDQoNCkZyb206 IFJvbmkgRXZlbiBbbWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5 LCBOb3ZlbWJlciAxNSwgMjAxNyAxOjI1IFBNDQpUbzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZl cXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+OyBRVUlDIFdHIDxxdWljQGll dGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBjb25uZWN0aW9uIG1p Z3JhdGlvbg0KDQpTbyB3aGF0IGlzIHRoZSBjb25uZWN0aW9uIG1pZ3JhdGlvbiBmbG93IGhlcmUu IFRoZSBxdWljIHN0YWNrIGluIHRoZSBjZWxsIG5ldHdvcmsgd2lsbCB0cnkgdG8gbWlncmF0ZSB0 byB3aWZpIHdpdGhvdXQgYXBwbGljYXRpb24gcmVxdWVzdCBhbmQgZmFpbCBidXQgd2lsbCBub3Qg ZmFsbCBiYWNrIHRvIFRDUC4NClRoZXJlIG1heSBiZSBtdWx0aXBsZSBhcHBsaWNhdGlvbiBydW5u aW5nIG92ZXIgcXVpYz8gSFRUUCBhbmQgcGVlciB0byBwZWVyIGF0IHRoZSBzYW1lIHRpbWUsIHNv IHdobyB3aWxsIGhhbmRsZSB0aGlzIGNhc2U/DQoNClJvbmkNCg0KRnJvbTogTWlrZSBCaXNob3Ag W21haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZV0NClNlbnQ6INeZ15XXnSDXkyAxNSDXoNeV15HX nteR16ggMjAxNyAwNTozNQ0KVG86IFJvbmkgRXZlbjsgUVVJQyBXRw0KU3ViamVjdDogUkU6IGNv bm5lY3Rpb24gbWlncmF0aW9uDQoNClRoYXQgbWF5IHdlbGwgYmUgdGhlIGNhc2UsIGJ1dCBpdOKA mXMgbm90IHRoZSBRVUlDIHN0YWNr4oCZcyBjaG9pY2UgdG8gbWFrZS4gIFRoZSBhcHBsaWNhdGlv biBjb3VsZCBjaG9vc2UgdG8gb3BlbiBhIG5ldyBjb25uZWN0aW9uLCBidXQgdGhhdCByZW1haW5z IG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSB0cmFuc3BvcnQgYW5kIHRoZSBtYXBwaW5nIHRvIGl0 IHdoaWNoIHdl4oCZcmUgZGVmaW5pbmcuDQoNCkZvciBIVFRQLCB0aGlzIGlzIGZhaXJseSBzdHJh aWdodGZvcndhcmQg4oCTIGl0IGNvdWxkIHN0b3AgaXNzdWluZyBuZXcgZmxvdyBjb250cm9sIGNy ZWRpdCwgbGV0IGN1cnJlbnRseS1pbi10cmFuc2l0IGRhdGEgYXJyaXZlIGFuZCBhbnkgbG9zc2Vz IHJlY292ZXJlZCwgYW5kIG9wZW4gYSBUQ1AgY29ubmVjdGlvbiB0byBpc3N1ZSBhIHJhbmdlIHJl cXVlc3Qgc3RhcnRpbmcgYXQgd2hhdGV2ZXIgZGF0YSBvZmZzZXQgaXQgaGFzbuKAmXQgc2Vlbi4g IEJ1dCB0aGF04oCZcyBzdGlsbCBhIHByb3BlcnR5IG9mIGFuIEhUVFAgbWFuYWdlbWVudCBhYm92 ZSB0aGUgSFRUUC9RVUlDIG1hcHBpbmcuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb25pIEV2ZW4NClNlbnQ6IFdlZG5lc2RheSwgTm92 ZW1iZXIgMTUsIDIwMTcgMTE6MjUgQU0NClRvOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0 bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IGNvbm5lY3Rpb24gbWlncmF0aW9uDQoNCkhpLA0K V2hlbiBtb3ZpbmcgZnJvbSBjZWxsIHRvIHdpZmkgdGhlIHJlYXNvbiBtYXkgYmUgZHVlIHRvIGNv c3QgKG1vbmV5IG9yIHF1b3RhKS4gSW4gdGhpcyBjYXNlIHRoZSAgdXNlciAoY2xpZW50KSBtYXkg d2FudCB0byBtb3ZlIHRvIHdpZmkgZXZlbiBpZiBpdCB3aWxsIG1lYW4gZHJvcHBpbmcgdG8gVENQ Lg0KDQpSb25pDQoNCg== --_000_6E58094ECC8D8344914996DAD28F1CCD837234DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBjbTsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5 bGUtbmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fu cy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0 OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4w cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5JIGFwb2xvZ2l6ZSBpZiBhbnlvbmUgZmVsdCB0aGF0IEkgd2FzIGJlaW5nIHNhcmNhc3Rp Yy4gVG8gbWUgaXQgbG9va3MgdGhhdCB0aGVyZSBpcyBzb21lIGRpZmZlcmVuY2UuIE15IHVuZGVy c3RhbmRpbmcgdGhhdCB0aGVyZSBpcyBzZXBhcmF0aW9uIGJldHdlZW4gdGhlIHRyYW5zcG9ydA0K IChRVUlDKSBhbmQgdGhlIGFwcGxpY2F0aW9uIChIVFRQIGZpcnN0IGFuZCBvdGhlciBsYXRlciku IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbiBhcHBsaWNhdGlvbiBjYW4gc2VlIGlu IHRoZSBUQ1AgY2FzZSB0d28gb3B0aW9ucyBUQ1Agb24gb3IgVENQIG9mZi4gSW4gUVVJQyBpdCBz ZWVzIHRocmVlIG9wdGlvbnMgUVVJQyBvbiwgUVVJQyBvZmYgKG5vIGNvbm5lY3Rpb24pLCBUQ1Au IElmIG9uZSBvZiB0aGUgcGh5c2ljYWwNCiBjb25uZWN0aW9uIGlzIGNsb3NlZCB0aGVyZSBpcyBu byBwcm9ibGVtLiBJIGFzc3VtZWQgdGhhdCBib3RoIHBoeXNpY2FsIGNvbm5lY3Rpb24gYXJlIGtl cHQgb3BlbiAod2hlbiBJIGVudGVyIHRoZSBob3VzZSBJIGNvbm5lY3QgdG8gdGhlIEFQIGJ1dCB0 aGUgM0cgZGF0YSBjaGFubmVsIGlzIHN0aWxsIG9wZW4pIGJ1dCB0aGUgYXBwbGljYXRpb24gd2ls bCB0cnkgdG8gc2VuZCBkYXRhIG9uIHRoZSB3aWZpIG5ldHdvcmsgYW5kIG5vdCBvbiB0aGUNCiBj ZWxsdWxhciBuZXR3b3JrIHNpbmNlIHRoaXMgaXMgdGhlIHBvbGljeSwgYW0gSSB3cm9uZz8gPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0 Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhv bWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21d DQo8YnI+DQo8Yj5TZW50OjwvYj4gPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV150mbmJz cDvXkyAxNSDXoNeV15HXnteR16ggMjAxNyAxMzo0Mzwvc3Bhbj48YnI+DQo8Yj5Ubzo8L2I+IE1p a2UgQmlzaG9wPGJyPg0KPGI+Q2M6PC9iPiBSb25pIEV2ZW47IFFVSUMgV0c8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IGNvbm5lY3Rpb24gbWlncmF0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGF0IE1pa2Ugc2FpZC4gVGhl IHNjb3BlIG9mIFFVSUMsIGJ5IGRlZmluaXRpb24sIGlzIG5vdCBsYXJnZXIgdGhhbiBRVUlDLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBX ZWQsIE5vdiAxNSwgMjAxNyBhdCA3OjAyIFBNLCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFp bHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBldmVxdWVm b3UuYmU8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5Zb3VyIHNhcmNhc20gbm90d2l0aHN0YW5kaW5nLCBJ4oCZbGwgZW1w aGFzaXplIHRoYXQgdGhpcyBpcyBpZGVudGljYWwgdG8gVENQIHRvZGF5LiZuYnNwOyBFaXRoZXIg dGhlIGFwcGxpY2F0aW9ucyBtb3ZlLCBvciB0aGV5IGRvbuKAmXQuJm5ic3A7IElmIHRoZSBkZXZp Y2UgZm9yY2libHkgYnJpbmdzIGRvd24gdGhlIGNlbGx1bGFyDQogaW50ZXJmYWNl4oCZcyBkYXRh IGNvbm5lY3Rpb24sIHRoZSBhcHBsaWNhdGlvbnMgd2lsbCBoYXZlIHRvIG1vdmUgaWYgdGhleSBk aWRu4oCZdCBhbHJlYWR5IG1vdmUgZ3JhY2VmdWxseSwgd2hpY2ggaXMgaW5kZXBlbmRlbnQgb2Yg dGhlIHRyYW5zcG9ydOKAmXMgcHJvcGVydGllcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGEgbmFtZT0ibV82NjI5NDkyNjUwMTY3MDAzMzg3X19NYWlsRW5kQ29tcG9z ZSI+Jm5ic3A7PC9hPjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20g MGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+RnJvbTo8L2I+IFJvbmkgRXZlbiBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsi PnJvbmkuZXZlbkBodWF3ZWkuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXks IE5vdmVtYmVyIDE1LCAyMDE3IDY6MzggUE08bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGI+VG86PC9iPiBNaWtlIEJpc2hvcCAmbHQ7PGEg aHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hv cEBldmVxdWVmb3UuYmU8L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUkU6IGNvbm5lY3Rpb24gbWlncmF0aW9uPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0 OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij4gTWlrZSBCaXNob3AgWzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5i ZSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT5dDQo8YnI+ DQo8Yj5TZW50OjwvYj4gPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV150mbmJzcDvXkyAx NSDXoNeV15HXnteR16ggMjAxNyAxMDoxODwvc3Bhbj48YnI+DQo8Yj5Ubzo8L2I+IFJvbmkgRXZl bjsgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogY29ubmVjdGlvbiBtaWdyYXRpb248 L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Tm87IGlu IHRoZSBUQ1AgY2FzZSB5b3VyIHRyYW5zcG9ydCBkb2VzbuKAmXQgaGF2ZSBhbnkgbWlncmF0aW9u IHByb3Zpc2lvbiwgc28gaXTigJlzIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiB3aGV0aGVyIGl0IHdh bnRzIHRvIHdpbmQgZG93biB0aGUgZXhpc3RpbmcgY29ubmVjdGlvbiBhbmQgc3RhcnQgYSBuZXcg b25lLiZuYnNwOw0KIElmIG1pZ3JhdGlvbiBmYWlscyB3aXRoIFFVSUMsIHRoZSBzaXR1YXRpb24g aXMgPHU+ZXhhY3RseSB0aGUgc2FtZTwvdT4sIGFuZCB0aGUgYXBwbGljYXRpb24gZGVjaWRlcyB3 aGV0aGVyIGl0IHdhbnRzIHRvIHdpbmQgZG93biB0aGUgZXhpc3RpbmcgY29ubmVjdGlvbiBhbmQg c3RhcnQgYSBuZXcgb25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgdGhlcmXigJlz IG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24sIHRoZW4gdGhlIGFuc3dlciB0byDigJx3aGljaCBh cHBsaWNhdGlvbuKAnSBpcyDigJxlYWNoIGFwcGxpY2F0aW9u4oCdIGJlY2F1c2UgZWFjaCBhcHBs aWNhdGlvbiBvd25zIGl0cyBvd24gY29ubmVjdGlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5bUm9uaSBF dmVuXSBTbyB3ZSBjYW4gZW5kIHVwIHdpdGggb25lIGFwcGxpY2F0aW9uIG9uIHRoZSBjZWxsIGFu ZCB0aGUgb3RoZXIgb24gdGhlIHdpZmkuIE5pY2UhISE8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5G cm9tOjwvYj4gUm9uaSBFdmVuIFs8YSBocmVmPSJtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20i IHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb208L2E+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIwMTcgMzo0NCBQTTxicj4NCjxi PlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZv dS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDs7IFFVSUMg V0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVp Y0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBjb25uZWN0aW9uIG1p Z3JhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJjb2xvcjojMUY0OTdEIj5pbmxpbmU8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3Nw YW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+IE1pa2UgQmlzaG9wIFs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUi IHRhcmdldD0iX2JsYW5rIj5tYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+XQ0KPGJyPg0K PGI+U2VudDo8L2I+IDxzcGFuIGxhbmc9IkhFIiBkaXI9IlJUTCI+15nXldedJm5ic3A715MgMTUg 16DXldeR157XkdeoIDIwMTcgMDg6MjM8L3NwYW4+PGJyPg0KPGI+VG86PC9iPiBSb25pIEV2ZW47 IFFVSUMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGNvbm5lY3Rpb24gbWlncmF0aW9uPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkV4YWN0bHkg dGhlIHNhbWUgd2F5IHRoYXQgVENQLXRvLVRDUCBoYW5kb2ZmIGJldHdlZW4gdGhlc2UgaW50ZXJm YWNlcyB3b3JrcyB0b2RheSwgYmVjYXVzZSAobm9uLU1QKSBUQ1AgaXNu4oCZdCBjYXBhYmxlIG9m IGNoYW5naW5nIHRvIGEgZGlmZmVyZW50IGludGVyZmFjZS4mbmJzcDsgV2XigJlyZSB0cnlpbmcg dG8gYnVpbGQNCiBhIGJldHRlciBhbnN3ZXIsIGJ1dCB5b3XigJlyZSBwb3NpdGluZyBmcm9tIHRo ZSBzdGFydCB0aGF0IGNvbm5lY3Rpb24gbWlncmF0aW9uIGZhaWxzLCBzbyB3ZeKAmXJlIG5vdyBp biDigJxubyB3b3JzZeKAnSBsYW5kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIFFV SUMgc3RhY2sgaW4gdGhlIGNsaWVudCBkZXZpY2Ugd2lsbCBzZWUgYSBuZXcgaW50ZXJmYWNlIGlz IGF2YWlsYWJsZS4mbmJzcDsgSXQgYXR0ZW1wdHMgdG8gc3dpdGNoIHRvIGl0LCBiZWNhdXNlIG9m IHNvbWUgbG9jYWwgcG9saWN5LiZuYnNwOyBUaGUgdHJhbnNpdGlvbiBmYWlscyBmb3Igd2hhdGV2 ZXIgcmVhc29uLA0KIGJ1dCB0aGUgY2VsbHVsYXIgY29ubmVjdGlvbiBpcyBzdGlsbCBhY3RpdmUu Jm5ic3A7IEl0IGlzIHRoZSBhcHBsaWNhdGlvbuKAmXMgY2hvaWNlIDxvOnA+DQo8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij5bUm9uaSBFdmVuXSB3aGljaCBhcHBsaWNhdGlvbiBpZiB0aGVyZSBpcyBtb3JlIHRoYW4gb25l PyBJbiB0aGUgVENQIGNhc2UgeW91IHN0YXkgaW4gdGhlIGNlbGwuIEhlcmUgdGhlcmUgYXJlIHR3 byBvcHRpb25zLCBzdGF5IG9uIHRoZSBjZWxsIHdpdGgNCiBRVUlDIG9yIG1vdmUgdG8gd2lmaSBv biBUQ1A8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+d2hldGhlciBpdCB3YW50cyB0byB3aW5kIGRvd24gYW5kIGNsb3NlIHRoYXQgY29ubmVjdGlv biBhbmQgc3RhcnQgYSBuZXcgb25lIHVzaW5nIFRDUCwgb3Iga2VlcCB1c2luZyB0aGUgb2xkIG9u ZSBpZiB0aGUgaW50ZXJmYWNlIHJlbWFpbnMgYXZhaWxhYmxlLiZuYnNwOyBJZiB0aGVyZSBhcmUg bXVsdGlwbGUgYXBwbGljYXRpb25zLA0KIGVhY2ggYXBwbGljYXRpb24gbWFrZXMgdGhhdCBjaG9p Y2UgaW5kZXBlbmRlbnRseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCBpZiB0aGUg Zmlyc3QgaW50ZXJmYWNlIGJlY29tZXMgdW5hdmFpbGFibGUgZm9yIHdoYXRldmVyIHJlYXNvbiwg dGhlIGNob2ljZSBpcyBtYWRlIGZvciBpdCwgYW5kIHRoZSBhcHBsaWNhdGlvbiB3aWxsIGhhdmUg dG8gcmVjb3Zlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRv cDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUm9uaSBFdmVuIFs8YSBocmVmPSJtYWlsdG86 cm9uaS5ldmVuQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cm9uaS5ldmVuQGh1 YXdlaS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUs IDIwMTcgMToyNSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1h aWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVl Zm91LmJlPC9hPiZndDs7IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3Jn IiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8 L2I+IFJFOiBjb25uZWN0aW9uIG1pZ3JhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TbyB3aGF0IGlzIHRo ZSBjb25uZWN0aW9uIG1pZ3JhdGlvbiBmbG93IGhlcmUuIFRoZSBxdWljIHN0YWNrIGluIHRoZSBj ZWxsIG5ldHdvcmsgd2lsbCB0cnkgdG8gbWlncmF0ZSB0byB3aWZpIHdpdGhvdXQgYXBwbGljYXRp b24gcmVxdWVzdCBhbmQgZmFpbCBidXQNCiB3aWxsIG5vdCBmYWxsIGJhY2sgdG8gVENQLjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPlRoZXJlIG1heSBiZSBtdWx0aXBsZSBhcHBsaWNhdGlvbiBydW5uaW5nIG92 ZXIgcXVpYz8gSFRUUCBhbmQgcGVlciB0byBwZWVyIGF0IHRoZSBzYW1lIHRpbWUsIHNvIHdobyB3 aWxsIGhhbmRsZSB0aGlzIGNhc2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFG NDk3RCI+Um9uaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFk ZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20i Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWlrZSBCaXNob3Ag WzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1h aWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gPHNwYW4g bGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV1508L3NwYW4+PHNwYW4gZGlyPSJMVFIiPjwvc3Bhbj48 c3BhbiBkaXI9IkxUUiI+PC9zcGFuPiZuYnNwOzxzcGFuIGxhbmc9IkhFIiBkaXI9IlJUTCI+15MN Cjwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+MTUg PHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj4NCteg15XXkdee15HXqCA8L3NwYW4+PHNwYW4gZGly PSJMVFIiPjwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjIwMTcgMDU6MzU8YnI+DQo8Yj5U bzo8L2I+IFJvbmkgRXZlbjsgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogY29ubmVj dGlvbiBtaWdyYXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+VGhhdCBtYXkgd2VsbCBiZSB0aGUgY2FzZSwgYnV0IGl04oCZcyBub3QgdGhlIFFV SUMgc3RhY2vigJlzIGNob2ljZSB0byBtYWtlLiZuYnNwOyBUaGUgYXBwbGljYXRpb24gY291bGQg Y2hvb3NlIHRvIG9wZW4gYSBuZXcgY29ubmVjdGlvbiwgYnV0IHRoYXQgcmVtYWlucyBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGUgdHJhbnNwb3J0DQogYW5kIHRoZSBtYXBwaW5nIHRvIGl0IHdoaWNo IHdl4oCZcmUgZGVmaW5pbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3IgSFRUUCwg dGhpcyBpcyBmYWlybHkgc3RyYWlnaHRmb3J3YXJkIOKAkyBpdCBjb3VsZCBzdG9wIGlzc3Vpbmcg bmV3IGZsb3cgY29udHJvbCBjcmVkaXQsIGxldCBjdXJyZW50bHktaW4tdHJhbnNpdCBkYXRhIGFy cml2ZSBhbmQgYW55IGxvc3NlcyByZWNvdmVyZWQsIGFuZCBvcGVuIGEgVENQIGNvbm5lY3Rpb24N CiB0byBpc3N1ZSBhIHJhbmdlIHJlcXVlc3Qgc3RhcnRpbmcgYXQgd2hhdGV2ZXIgZGF0YSBvZmZz ZXQgaXQgaGFzbuKAmXQgc2Vlbi4mbmJzcDsgQnV0IHRoYXTigJlzIHN0aWxsIGEgcHJvcGVydHkg b2YgYW4gSFRUUCBtYW5hZ2VtZW50IGFib3ZlIHRoZSBIVFRQL1FVSUMgbWFwcGluZy48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj5Gcm9tOjwvYj4gUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5Sb25pIEV2ZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3Zl bWJlciAxNSwgMjAxNyAxMToyNSBBTTxicj4NCjxiPlRvOjwvYj4gUVVJQyBXRyAmbHQ7PGEgaHJl Zj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9h PiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gY29ubmVjdGlvbiBtaWdyYXRpb248bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+V2hlbiBtb3ZpbmcgZnJvbSBjZWxsIHRvIHdpZmkgdGhlIHJl YXNvbiBtYXkgYmUgZHVlIHRvIGNvc3QgKG1vbmV5IG9yIHF1b3RhKS4gSW4gdGhpcyBjYXNlIHRo ZSZuYnNwOyB1c2VyIChjbGllbnQpIG1heSB3YW50IHRvIG1vdmUgdG8gd2lmaSBldmVuIGlmIGl0 IHdpbGwgbWVhbiBkcm9wcGluZyB0byBUQ1AuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5S b25pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD837234DGGEMM506MBXchina_-- From nobody Wed Nov 15 06:40: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 CA1D41200E5 for ; Wed, 15 Nov 2017 06:40:26 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YefqjbmAQ4jf for ; Wed, 15 Nov 2017 06:40:25 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5331241F5 for ; Wed, 15 Nov 2017 06:40:25 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 36F0AA5DCB6D4 for ; Wed, 15 Nov 2017 14:40:22 +0000 (GMT) Received: from DGGEMM424-HUB.china.huawei.com (10.1.198.41) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 15 Nov 2017 14:40:24 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by dggemm424-hub.china.huawei.com ([10.1.198.41]) with mapi id 14.03.0361.001; Wed, 15 Nov 2017 22:40:20 +0800 From: Roni Even To: QUIC WG Subject: Why one spin bit and not more in the QUIC header Thread-Topic: Why one spin bit and not more in the QUIC header Thread-Index: AdNeH6tR/xkcD+UdTlO8ySCcdD1waQ== Date: Wed, 15 Nov 2017 14:40:19 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD837283@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.52.47.150] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD837283DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:40:27 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD837283DGGEMM506MBXchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, There is a reason why we are asking for one bit. The QUIC transport header has starts with one type byte. The long header start with 1 and the rest 7 bits are the type. The long hea= der is used only in the handshake where the message is in the clear so we c= an get the RTT from the handshake. The short header starts with a zero bit followed by C and K bits and 5 type= bits, so bits are scarce resource. The spin bit proposal in the github is= sue #609 propose using one but and making the type only 4 bits. The defined= types are in the quic transport table 2, three types are used to specify t= he packet number size (values 1-3). So it looks like there are more bits av= ailable but that may prevent other usages for the first type byte. Roni --_000_6E58094ECC8D8344914996DAD28F1CCD837283DGGEMM506MBXchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There is a reason why we are asking for one bit.

The QUIC transport header has starts with one type b= yte.

The long header start with 1 and the rest 7 bits are= the type. The long header is used only in the handshake where the message = is in the clear so we can get the RTT from the handshake.

The short header starts with a zero bit followed by = C and K bits and 5 type bits, so bits are scarce resource.  The spin b= it proposal in the github issue #609 propose using one but and making the t= ype only 4 bits. The defined types are in the quic transport table 2, three types are used to specify the packet = number size (values 1-3). So it looks like there are more bits available bu= t that may prevent other usages for the first type byte.

Roni

--_000_6E58094ECC8D8344914996DAD28F1CCD837283DGGEMM506MBXchina_-- From nobody Wed Nov 15 07:43: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 801111200FC for ; Wed, 15 Nov 2017 07:43:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=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=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 Kx887rjtKLqq for ; Wed, 15 Nov 2017 07:43:49 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 4709C124C27 for ; Wed, 15 Nov 2017 07:43:49 -0800 (PST) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAFFhBGw026670; Wed, 15 Nov 2017 15:43:33 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=up3Q0wm81ZWn5COEwUsfETshmMLtJRwtyH5sPKbh81k=; b=jNj64bGhMCrFe4rZm/QQUqynPq9/8F4oNFaAkUadEQ5E2gimp2ABxqgXwEwp6b6oBy/1 aWrqg6qOQPZAF+8HhqN+cGrDG0PtJesenBI8/ma7H1Gg39NtYu3hETWnydcBkRoLd7qa RDV/SMOgdTmtYrOnY5EjmU7hVjTnrlMSjWdIOE3k+pGFQPQ1aQUYu0mfpLO4lj1c4NCv 0/ekpOpRfYR7btfGdF1QTSJWgfr+2ELu5EE7YtRv7XJIgP81CIMMVelCdh4NWpjo3Fxs YYZdTqhFzWBU/JgdkdQSoWz6xieT8Wa8g1BUHLXIIckIE3Z2Ekeb2ef5RmXmQzqFygQw bw== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2e8d5vhj8j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 15 Nov 2017 15:43:33 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vAFFaiPJ004716; Wed, 15 Nov 2017 10:43:33 -0500 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2e7p3wntgw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 15 Nov 2017 10:43:32 -0500 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.1263.5; Wed, 15 Nov 2017 10:43:31 -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.1263.000; Wed, 15 Nov 2017 10:43:31 -0500 From: "Lubashev, Igor" To: Roni Even , Jana Iyengar , "Mike Bishop" CC: QUIC WG Subject: RE: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQAAPS1iAAAgH6gAAC4MDgAAExe/AABPYHoAAA0SZAAAvwmoAABYg1gAAH1z0w Date: Wed, 15 Nov 2017 15:43:30 +0000 Message-ID: <55a2d469c30d4ba58c55c328defd2872@usma1ex-dag1mb5.msg.corp.akamai.com> References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837234@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD837234@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.147.36] Content-Type: multipart/alternative; boundary="_000_55a2d469c30d4ba58c55c328defd2872usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-15_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150211 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-15_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711150213 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 15:43:52 -0000 --_000_55a2d469c30d4ba58c55c328defd2872usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9uaSwgaWYgYW4gYXBwbGljYXRpb24gZGVjaWRlcyB0byBzd2l0Y2ggZnJvbSBRVUlDIHRvIFRD UCwgdGhlcmUgd2lsbCBiZSBubyBjb25uZWN0aW9uIG1pZ3JhdGlvbi4gIFRoZSBhcHBsaWNhdGlv biB3aWxsIGhhdmUgdG8gZXN0YWJsaXNoIGEgbmV3IGNvbm5lY3Rpb24gb3ZlciBUQ1AsIGxpa2Vs eSwgcmVuZWdvdGlhdGUgY3J5cHRvLCBhbmQgd2hhdGV2ZXIgUVVJQyBzdHJlYW1zIHdlcmUgaW4g cHJvZ3Jlc3Mgd2lsbCBub3QganVzdCBtaWdyYXRlIGFuZCBjb250aW51ZSBvdmVyIFRDUCBzb21l aG93LiAgU2VhbWxlc3MgY29ubmVjdGlvbiBtaWdyYXRpb24gYmV0d2VlbiBRVUlDIGFuZCBUQ1Ag aXMgY2VydGFpbmx5IG91dHNpZGUgb2YgdGhlIGNoYXJ0ZXIuDQoNCkFwb2xvZ2llcywgaWYgSSBt aXN1bmRlcnN0b29kIHlvdXIgaW50ZW50LCBhbmQgeW91IHdlcmUgdGFsa2luZyBhYm91dCBzb21l dGhpbmcgb3RoZXIgdGhhbiBob3cgdG8gbWlncmF0ZSBjb25uZWN0aW9ucyBmcm9tIFFVSUMgdG8g VENQLg0KDQoNCiAgKiAgIElnb3INCg0KDQpGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb25pLmV2 ZW5AaHVhd2VpLmNvbV0NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIwMTcgMTA6MjEg UE0NClRvOiBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPjsgTWlrZSBCaXNob3AgPG1iaXNo b3BAZXZlcXVlZm91LmJlPg0KQ2M6IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS RTogY29ubmVjdGlvbiBtaWdyYXRpb24NCg0KSGksDQpJIGFwb2xvZ2l6ZSBpZiBhbnlvbmUgZmVs dCB0aGF0IEkgd2FzIGJlaW5nIHNhcmNhc3RpYy4gVG8gbWUgaXQgbG9va3MgdGhhdCB0aGVyZSBp cyBzb21lIGRpZmZlcmVuY2UuIE15IHVuZGVyc3RhbmRpbmcgdGhhdCB0aGVyZSBpcyBzZXBhcmF0 aW9uIGJldHdlZW4gdGhlIHRyYW5zcG9ydCAoUVVJQykgYW5kIHRoZSBhcHBsaWNhdGlvbiAoSFRU UCBmaXJzdCBhbmQgb3RoZXIgbGF0ZXIpLg0KQW4gYXBwbGljYXRpb24gY2FuIHNlZSBpbiB0aGUg VENQIGNhc2UgdHdvIG9wdGlvbnMgVENQIG9uIG9yIFRDUCBvZmYuIEluIFFVSUMgaXQgc2VlcyB0 aHJlZSBvcHRpb25zIFFVSUMgb24sIFFVSUMgb2ZmIChubyBjb25uZWN0aW9uKSwgVENQLiBJZiBv bmUgb2YgdGhlIHBoeXNpY2FsIGNvbm5lY3Rpb24gaXMgY2xvc2VkIHRoZXJlIGlzIG5vIHByb2Js ZW0uIEkgYXNzdW1lZCB0aGF0IGJvdGggcGh5c2ljYWwgY29ubmVjdGlvbiBhcmUga2VwdCBvcGVu ICh3aGVuIEkgZW50ZXIgdGhlIGhvdXNlIEkgY29ubmVjdCB0byB0aGUgQVAgYnV0IHRoZSAzRyBk YXRhIGNoYW5uZWwgaXMgc3RpbGwgb3BlbikgYnV0IHRoZSBhcHBsaWNhdGlvbiB3aWxsIHRyeSB0 byBzZW5kIGRhdGEgb24gdGhlIHdpZmkgbmV0d29yayBhbmQgbm90IG9uIHRoZSBjZWxsdWxhciBu ZXR3b3JrIHNpbmNlIHRoaXMgaXMgdGhlIHBvbGljeSwgYW0gSSB3cm9uZz8NClJvbmkNCg0KRnJv bTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5jb21dDQpTZW50OiDXmdeV150g15Mg MTUg16DXldeR157XkdeoIDIwMTcgMTM6NDMNClRvOiBNaWtlIEJpc2hvcA0KQ2M6IFJvbmkgRXZl bjsgUVVJQyBXRw0KU3ViamVjdDogUmU6IGNvbm5lY3Rpb24gbWlncmF0aW9uDQoNCldoYXQgTWlr ZSBzYWlkLiBUaGUgc2NvcGUgb2YgUVVJQywgYnkgZGVmaW5pdGlvbiwgaXMgbm90IGxhcmdlciB0 aGFuIFFVSUMuDQoNCk9uIFdlZCwgTm92IDE1LCAyMDE3IGF0IDc6MDIgUE0sIE1pa2UgQmlzaG9w IDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU+PiB3cm90 ZToNCllvdXIgc2FyY2FzbSBub3R3aXRoc3RhbmRpbmcsIEnigJlsbCBlbXBoYXNpemUgdGhhdCB0 aGlzIGlzIGlkZW50aWNhbCB0byBUQ1AgdG9kYXkuICBFaXRoZXIgdGhlIGFwcGxpY2F0aW9ucyBt b3ZlLCBvciB0aGV5IGRvbuKAmXQuICBJZiB0aGUgZGV2aWNlIGZvcmNpYmx5IGJyaW5ncyBkb3du IHRoZSBjZWxsdWxhciBpbnRlcmZhY2XigJlzIGRhdGEgY29ubmVjdGlvbiwgdGhlIGFwcGxpY2F0 aW9ucyB3aWxsIGhhdmUgdG8gbW92ZSBpZiB0aGV5IGRpZG7igJl0IGFscmVhZHkgbW92ZSBncmFj ZWZ1bGx5LCB3aGljaCBpcyBpbmRlcGVuZGVudCBvZiB0aGUgdHJhbnNwb3J04oCZcyBwcm9wZXJ0 aWVzLg0KDQpGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbTxtYWls dG86cm9uaS5ldmVuQGh1YXdlaS5jb20+XQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwg MjAxNyA2OjM4IFBNDQoNClRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFp bHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRv OnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IGNvbm5lY3Rpb24gbWlncmF0aW9uDQoNCg0K DQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlXQ0KU2VudDog 15nXldedINeTIDE1INeg15XXkdee15HXqCAyMDE3IDEwOjE4DQpUbzogUm9uaSBFdmVuOyBRVUlD IFdHDQpTdWJqZWN0OiBSRTogY29ubmVjdGlvbiBtaWdyYXRpb24NCg0KTm87IGluIHRoZSBUQ1Ag Y2FzZSB5b3VyIHRyYW5zcG9ydCBkb2VzbuKAmXQgaGF2ZSBhbnkgbWlncmF0aW9uIHByb3Zpc2lv biwgc28gaXTigJlzIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiB3aGV0aGVyIGl0IHdhbnRzIHRvIHdp bmQgZG93biB0aGUgZXhpc3RpbmcgY29ubmVjdGlvbiBhbmQgc3RhcnQgYSBuZXcgb25lLiAgSWYg bWlncmF0aW9uIGZhaWxzIHdpdGggUVVJQywgdGhlIHNpdHVhdGlvbiBpcyBleGFjdGx5IHRoZSBz YW1lLCBhbmQgdGhlIGFwcGxpY2F0aW9uIGRlY2lkZXMgd2hldGhlciBpdCB3YW50cyB0byB3aW5k IGRvd24gdGhlIGV4aXN0aW5nIGNvbm5lY3Rpb24gYW5kIHN0YXJ0IGEgbmV3IG9uZS4NCg0KSWYg dGhlcmXigJlzIG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24sIHRoZW4gdGhlIGFuc3dlciB0byDi gJx3aGljaCBhcHBsaWNhdGlvbuKAnSBpcyDigJxlYWNoIGFwcGxpY2F0aW9u4oCdIGJlY2F1c2Ug ZWFjaCBhcHBsaWNhdGlvbiBvd25zIGl0cyBvd24gY29ubmVjdGlvbnMuDQpbUm9uaSBFdmVuXSBT byB3ZSBjYW4gZW5kIHVwIHdpdGggb25lIGFwcGxpY2F0aW9uIG9uIHRoZSBjZWxsIGFuZCB0aGUg b3RoZXIgb24gdGhlIHdpZmkuIE5pY2UhISENCg0KRnJvbTogUm9uaSBFdmVuIFttYWlsdG86cm9u aS5ldmVuQGh1YXdlaS5jb21dDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE1LCAyMDE3IDM6 NDQgUE0NClRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNo b3BAZXZlcXVlZm91LmJlPj47IFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0 Zi5vcmc+Pg0KU3ViamVjdDogUkU6IGNvbm5lY3Rpb24gbWlncmF0aW9uDQoNCmlubGluZQ0KDQpG cm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlXQ0KU2VudDog15nX ldedINeTIDE1INeg15XXkdee15HXqCAyMDE3IDA4OjIzDQpUbzogUm9uaSBFdmVuOyBRVUlDIFdH DQpTdWJqZWN0OiBSRTogY29ubmVjdGlvbiBtaWdyYXRpb24NCg0KRXhhY3RseSB0aGUgc2FtZSB3 YXkgdGhhdCBUQ1AtdG8tVENQIGhhbmRvZmYgYmV0d2VlbiB0aGVzZSBpbnRlcmZhY2VzIHdvcmtz IHRvZGF5LCBiZWNhdXNlIChub24tTVApIFRDUCBpc27igJl0IGNhcGFibGUgb2YgY2hhbmdpbmcg dG8gYSBkaWZmZXJlbnQgaW50ZXJmYWNlLiAgV2XigJlyZSB0cnlpbmcgdG8gYnVpbGQgYSBiZXR0 ZXIgYW5zd2VyLCBidXQgeW914oCZcmUgcG9zaXRpbmcgZnJvbSB0aGUgc3RhcnQgdGhhdCBjb25u ZWN0aW9uIG1pZ3JhdGlvbiBmYWlscywgc28gd2XigJlyZSBub3cgaW4g4oCcbm8gd29yc2XigJ0g bGFuZC4NCg0KVGhlIFFVSUMgc3RhY2sgaW4gdGhlIGNsaWVudCBkZXZpY2Ugd2lsbCBzZWUgYSBu ZXcgaW50ZXJmYWNlIGlzIGF2YWlsYWJsZS4gIEl0IGF0dGVtcHRzIHRvIHN3aXRjaCB0byBpdCwg YmVjYXVzZSBvZiBzb21lIGxvY2FsIHBvbGljeS4gIFRoZSB0cmFuc2l0aW9uIGZhaWxzIGZvciB3 aGF0ZXZlciByZWFzb24sIGJ1dCB0aGUgY2VsbHVsYXIgY29ubmVjdGlvbiBpcyBzdGlsbCBhY3Rp dmUuICBJdCBpcyB0aGUgYXBwbGljYXRpb27igJlzIGNob2ljZQ0KW1JvbmkgRXZlbl0gd2hpY2gg YXBwbGljYXRpb24gaWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9uZT8gSW4gdGhlIFRDUCBjYXNlIHlv dSBzdGF5IGluIHRoZSBjZWxsLiBIZXJlIHRoZXJlIGFyZSB0d28gb3B0aW9ucywgc3RheSBvbiB0 aGUgY2VsbCB3aXRoIFFVSUMgb3IgbW92ZSB0byB3aWZpIG9uIFRDUA0Kd2hldGhlciBpdCB3YW50 cyB0byB3aW5kIGRvd24gYW5kIGNsb3NlIHRoYXQgY29ubmVjdGlvbiBhbmQgc3RhcnQgYSBuZXcg b25lIHVzaW5nIFRDUCwgb3Iga2VlcCB1c2luZyB0aGUgb2xkIG9uZSBpZiB0aGUgaW50ZXJmYWNl IHJlbWFpbnMgYXZhaWxhYmxlLiAgSWYgdGhlcmUgYXJlIG11bHRpcGxlIGFwcGxpY2F0aW9ucywg ZWFjaCBhcHBsaWNhdGlvbiBtYWtlcyB0aGF0IGNob2ljZSBpbmRlcGVuZGVudGx5Lg0KDQpBbmQg aWYgdGhlIGZpcnN0IGludGVyZmFjZSBiZWNvbWVzIHVuYXZhaWxhYmxlIGZvciB3aGF0ZXZlciBy ZWFzb24sIHRoZSBjaG9pY2UgaXMgbWFkZSBmb3IgaXQsIGFuZCB0aGUgYXBwbGljYXRpb24gd2ls bCBoYXZlIHRvIHJlY292ZXIuDQoNCkZyb206IFJvbmkgRXZlbiBbbWFpbHRvOnJvbmkuZXZlbkBo dWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyAxOjI1IFBNDQpU bzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9wQGV2ZXF1 ZWZvdS5iZT4+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4N ClN1YmplY3Q6IFJFOiBjb25uZWN0aW9uIG1pZ3JhdGlvbg0KDQpTbyB3aGF0IGlzIHRoZSBjb25u ZWN0aW9uIG1pZ3JhdGlvbiBmbG93IGhlcmUuIFRoZSBxdWljIHN0YWNrIGluIHRoZSBjZWxsIG5l dHdvcmsgd2lsbCB0cnkgdG8gbWlncmF0ZSB0byB3aWZpIHdpdGhvdXQgYXBwbGljYXRpb24gcmVx dWVzdCBhbmQgZmFpbCBidXQgd2lsbCBub3QgZmFsbCBiYWNrIHRvIFRDUC4NClRoZXJlIG1heSBi ZSBtdWx0aXBsZSBhcHBsaWNhdGlvbiBydW5uaW5nIG92ZXIgcXVpYz8gSFRUUCBhbmQgcGVlciB0 byBwZWVyIGF0IHRoZSBzYW1lIHRpbWUsIHNvIHdobyB3aWxsIGhhbmRsZSB0aGlzIGNhc2U/DQoN ClJvbmkNCg0KRnJvbTogTWlrZSBCaXNob3AgW21haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZV0N ClNlbnQ6INeZ15XXnSDXkyAxNSDXoNeV15HXnteR16ggMjAxNyAwNTozNQ0KVG86IFJvbmkgRXZl bjsgUVVJQyBXRw0KU3ViamVjdDogUkU6IGNvbm5lY3Rpb24gbWlncmF0aW9uDQoNClRoYXQgbWF5 IHdlbGwgYmUgdGhlIGNhc2UsIGJ1dCBpdOKAmXMgbm90IHRoZSBRVUlDIHN0YWNr4oCZcyBjaG9p Y2UgdG8gbWFrZS4gIFRoZSBhcHBsaWNhdGlvbiBjb3VsZCBjaG9vc2UgdG8gb3BlbiBhIG5ldyBj b25uZWN0aW9uLCBidXQgdGhhdCByZW1haW5zIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSB0cmFu c3BvcnQgYW5kIHRoZSBtYXBwaW5nIHRvIGl0IHdoaWNoIHdl4oCZcmUgZGVmaW5pbmcuDQoNCkZv ciBIVFRQLCB0aGlzIGlzIGZhaXJseSBzdHJhaWdodGZvcndhcmQg4oCTIGl0IGNvdWxkIHN0b3Ag aXNzdWluZyBuZXcgZmxvdyBjb250cm9sIGNyZWRpdCwgbGV0IGN1cnJlbnRseS1pbi10cmFuc2l0 IGRhdGEgYXJyaXZlIGFuZCBhbnkgbG9zc2VzIHJlY292ZXJlZCwgYW5kIG9wZW4gYSBUQ1AgY29u bmVjdGlvbiB0byBpc3N1ZSBhIHJhbmdlIHJlcXVlc3Qgc3RhcnRpbmcgYXQgd2hhdGV2ZXIgZGF0 YSBvZmZzZXQgaXQgaGFzbuKAmXQgc2Vlbi4gIEJ1dCB0aGF04oCZcyBzdGlsbCBhIHByb3BlcnR5 IG9mIGFuIEhUVFAgbWFuYWdlbWVudCBhYm92ZSB0aGUgSFRUUC9RVUlDIG1hcHBpbmcuDQoNCkZy b206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBSb25p IEV2ZW4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIwMTcgMTE6MjUgQU0NClRvOiBR VUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IGNv bm5lY3Rpb24gbWlncmF0aW9uDQoNCkhpLA0KV2hlbiBtb3ZpbmcgZnJvbSBjZWxsIHRvIHdpZmkg dGhlIHJlYXNvbiBtYXkgYmUgZHVlIHRvIGNvc3QgKG1vbmV5IG9yIHF1b3RhKS4gSW4gdGhpcyBj YXNlIHRoZSAgdXNlciAoY2xpZW50KSBtYXkgd2FudCB0byBtb3ZlIHRvIHdpZmkgZXZlbiBpZiBp dCB3aWxsIG1lYW4gZHJvcHBpbmcgdG8gVENQLg0KDQpSb25pDQoNCg== --_000_55a2d469c30d4ba58c55c328defd2872usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglw YW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7 DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0 Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBo LCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUt cHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJn aW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNl cmlmO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNv LXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJ e21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhv bWEiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3 RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjU2OTc3NDU1MDsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MjExMjI1MDYwMCA1NzI5NTExNjAgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkg Njc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6 bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDoxMDsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6LTsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFt aWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGww OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxp c3QtaWQ6MTg1ODY5MjU0OTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1w bGF0ZS1pZHM6MTU5ODQ1NTEyNCAxMDUzNjAwMzcwIDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5 IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGwx OmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MTA7DQoJbXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Oi07DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgltc28tZmFyZWFzdC1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwxOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBs MTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMTpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0 b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlJvbmksIGlm IGFuIGFwcGxpY2F0aW9uIGRlY2lkZXMgdG8gc3dpdGNoIGZyb20gUVVJQyB0byBUQ1AsIHRoZXJl IHdpbGwgYmUgbm8gY29ubmVjdGlvbiBtaWdyYXRpb24uJm5ic3A7IFRoZSBhcHBsaWNhdGlvbiB3 aWxsIGhhdmUgdG8gZXN0YWJsaXNoIGEgbmV3IGNvbm5lY3Rpb24gb3ZlciBUQ1AsIGxpa2VseSwN CiByZW5lZ290aWF0ZSBjcnlwdG8sIGFuZCB3aGF0ZXZlciBRVUlDIHN0cmVhbXMgd2VyZSBpbiBw cm9ncmVzcyB3aWxsIG5vdCBqdXN0IG1pZ3JhdGUgYW5kIGNvbnRpbnVlIG92ZXIgVENQIHNvbWVo b3cuJm5ic3A7IFNlYW1sZXNzIGNvbm5lY3Rpb24gbWlncmF0aW9uIGJldHdlZW4gUVVJQyBhbmQg VENQIGlzIGNlcnRhaW5seSBvdXRzaWRlIG9mIHRoZSBjaGFydGVyLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5B cG9sb2dpZXMsIGlmIEkgbWlzdW5kZXJzdG9vZCB5b3VyIGludGVudCwgYW5kIHlvdSB3ZXJlIHRh bGtpbmcgYWJvdXQgc29tZXRoaW5nIG90aGVyIHRoYW4gaG93IHRvIG1pZ3JhdGUgY29ubmVjdGlv bnMgZnJvbSBRVUlDIHRvIFRDUC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx1 bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8y Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPklnb3I8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+IFJvbmkgRXZlbiBbbWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tXQ0KPGJy Pg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIwMTcgMTA6MjEgUE08YnI+ DQo8Yj5Ubzo8L2I+IEphbmEgSXllbmdhciAmbHQ7anJpQGdvb2dsZS5jb20mZ3Q7OyBNaWtlIEJp c2hvcCAmbHQ7bWJpc2hvcEBldmVxdWVmb3UuYmUmZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBRVUlDIFdH ICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogY29ubmVjdGlv biBtaWdyYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkg YXBvbG9naXplIGlmIGFueW9uZSBmZWx0IHRoYXQgSSB3YXMgYmVpbmcgc2FyY2FzdGljLiBUbyBt ZSBpdCBsb29rcyB0aGF0IHRoZXJlIGlzIHNvbWUgZGlmZmVyZW5jZS4gTXkgdW5kZXJzdGFuZGlu ZyB0aGF0IHRoZXJlIGlzIHNlcGFyYXRpb24gYmV0d2VlbiB0aGUgdHJhbnNwb3J0DQogKFFVSUMp IGFuZCB0aGUgYXBwbGljYXRpb24gKEhUVFAgZmlyc3QgYW5kIG90aGVyIGxhdGVyKS4gPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPkFuIGFwcGxpY2F0aW9uIGNhbiBzZWUgaW4gdGhlIFRDUCBjYXNlIHR3byBv cHRpb25zIFRDUCBvbiBvciBUQ1Agb2ZmLiBJbiBRVUlDIGl0IHNlZXMgdGhyZWUgb3B0aW9ucyBR VUlDIG9uLCBRVUlDIG9mZiAobm8gY29ubmVjdGlvbiksIFRDUC4gSWYgb25lIG9mIHRoZSBwaHlz aWNhbA0KIGNvbm5lY3Rpb24gaXMgY2xvc2VkIHRoZXJlIGlzIG5vIHByb2JsZW0uIEkgYXNzdW1l ZCB0aGF0IGJvdGggcGh5c2ljYWwgY29ubmVjdGlvbiBhcmUga2VwdCBvcGVuICh3aGVuIEkgZW50 ZXIgdGhlIGhvdXNlIEkgY29ubmVjdCB0byB0aGUgQVAgYnV0IHRoZSAzRyBkYXRhIGNoYW5uZWwg aXMgc3RpbGwgb3BlbikgYnV0IHRoZSBhcHBsaWNhdGlvbiB3aWxsIHRyeSB0byBzZW5kIGRhdGEg b24gdGhlIHdpZmkgbmV0d29yayBhbmQgbm90IG9uIHRoZQ0KIGNlbGx1bGFyIG5ldHdvcmsgc2lu Y2UgdGhpcyBpcyB0aGUgcG9saWN5LCBhbSBJIHdyb25nPyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9u aTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGlu IDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10 b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNh bnMtc2VyaWYiPiBKYW5hIEl5ZW5nYXIgWzxhIGhyZWY9Im1haWx0bzpqcmlAZ29vZ2xlLmNvbSI+ bWFpbHRvOmpyaUBnb29nbGUuY29tPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiA8L3NwYW4+PHNw YW4gbGFuZz0iSEUiIGRpcj0iUlRMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+15nXldedJm5ic3A715MgMTUg16DXldeR 157XkdeoIDIwMTcgMTM6NDM8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlRvOjwvYj4g TWlrZSBCaXNob3A8YnI+DQo8Yj5DYzo8L2I+IFJvbmkgRXZlbjsgUVVJQyBXRzxicj4NCjxiPlN1 YmplY3Q6PC9iPiBSZTogY29ubmVjdGlvbiBtaWdyYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldoYXQgTWlrZSBzYWlkLiBU aGUgc2NvcGUgb2YgUVVJQywgYnkgZGVmaW5pdGlvbiwgaXMgbm90IGxhcmdlciB0aGFuIFFVSUMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IFdlZCwgTm92IDE1LCAyMDE3IGF0IDc6MDIgUE0sIE1pa2UgQmlzaG9wICZsdDs8YSBocmVmPSJt YWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYmlzaG9wQGV2ZXF1 ZWZvdS5iZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPllvdXIgc2FyY2FzbSBub3R3aXRoc3RhbmRpbmcsIEnigJlsbCBl bXBoYXNpemUgdGhhdCB0aGlzIGlzIGlkZW50aWNhbCB0byBUQ1AgdG9kYXkuJm5ic3A7IEVpdGhl ciB0aGUgYXBwbGljYXRpb25zIG1vdmUsIG9yIHRoZXkgZG9u4oCZdC4mbmJzcDsgSWYgdGhlIGRl dmljZSBmb3JjaWJseSBicmluZ3MgZG93biB0aGUgY2VsbHVsYXINCiBpbnRlcmZhY2XigJlzIGRh dGEgY29ubmVjdGlvbiwgdGhlIGFwcGxpY2F0aW9ucyB3aWxsIGhhdmUgdG8gbW92ZSBpZiB0aGV5 IGRpZG7igJl0IGFscmVhZHkgbW92ZSBncmFjZWZ1bGx5LCB3aGljaCBpcyBpbmRlcGVuZGVudCBv ZiB0aGUgdHJhbnNwb3J04oCZcyBwcm9wZXJ0aWVzLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48YSBuYW1lPSJtXzY2Mjk0OTI2NTAxNjcwMDMzODdfX01haWxFbmRDb21w b3NlIj4mbmJzcDs8L2E+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUm9uaSBFdmVuIFtt YWlsdG86PGEgaHJlZj0ibWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFu ayI+cm9uaS5ldmVuQGh1YXdlaS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2Rh eSwgTm92ZW1iZXIgMTUsIDIwMTcgNjozOCBQTTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8Yj5Ubzo8L2I+IE1pa2UgQmlzaG9wICZsdDs8 YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYmlz aG9wQGV2ZXF1ZWZvdS5iZTwvYT4mZ3Q7OyBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVp Y0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxi PlN1YmplY3Q6PC9iPiBSRTogY29ubmVjdGlvbiBtaWdyYXRpb248bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxl ZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8 ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFk ZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oyxz YW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBNaWtlIEJpc2hvcCBb PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWFp bHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiA8L3NwYW4+ PHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+15nXldedJm5ic3A715MgMTUg16DX ldeR157XkdeoIDIwMTcgMTA6MTg8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjxiPlRvOjwv Yj4gUm9uaSBFdmVuOyBRVUlDIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBjb25uZWN0aW9u IG1pZ3JhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5ObzsgaW4gdGhlIFRDUCBjYXNlIHlvdXIgdHJhbnNwb3J0IGRvZXNu4oCZdCBoYXZlIGFu eSBtaWdyYXRpb24gcHJvdmlzaW9uLCBzbyBpdOKAmXMgdXAgdG8gdGhlIGFwcGxpY2F0aW9uIHdo ZXRoZXIgaXQgd2FudHMgdG8gd2luZCBkb3duIHRoZSBleGlzdGluZyBjb25uZWN0aW9uIGFuZCBz dGFydCBhIG5ldyBvbmUuJm5ic3A7DQogSWYgbWlncmF0aW9uIGZhaWxzIHdpdGggUVVJQywgdGhl IHNpdHVhdGlvbiBpcyA8dT5leGFjdGx5IHRoZSBzYW1lPC91PiwgYW5kIHRoZSBhcHBsaWNhdGlv biBkZWNpZGVzIHdoZXRoZXIgaXQgd2FudHMgdG8gd2luZCBkb3duIHRoZSBleGlzdGluZyBjb25u ZWN0aW9uIGFuZCBzdGFydCBhIG5ldyBvbmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5J ZiB0aGVyZeKAmXMgbW9yZSB0aGFuIG9uZSBhcHBsaWNhdGlvbiwgdGhlbiB0aGUgYW5zd2VyIHRv IOKAnHdoaWNoIGFwcGxpY2F0aW9u4oCdIGlzIOKAnGVhY2ggYXBwbGljYXRpb27igJ0gYmVjYXVz ZSBlYWNoIGFwcGxpY2F0aW9uIG93bnMgaXRzIG93biBjb25uZWN0aW9ucy48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5 N0QiPltSb25pIEV2ZW5dIFNvIHdlIGNhbiBlbmQgdXAgd2l0aCBvbmUgYXBwbGljYXRpb24gb24g dGhlIGNlbGwgYW5kIHRoZSBvdGhlciBvbiB0aGUgd2lmaS4gTmljZSEhITwvc3Bhbj48L2k+PC9i PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNF MUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxiPkZyb206PC9iPiBSb25pIEV2ZW4gWzxhIGhyZWY9Im1haWx0bzpyb25pLmV2ZW5A aHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbTwv YT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyAzOjQ0 IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNo b3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+ Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0i X2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGNv bm5lY3Rpb24gbWlncmF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPmlubGluZTwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssc2Fucy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj4gTWlrZSBC aXNob3AgWzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxh bmsiPm1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g PC9zcGFuPjxzcGFuIGxhbmc9IkhFIiBkaXI9IlJUTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPteZ15XXnSZuYnNwO9eT IDE1INeg15XXkdee15HXqCAyMDE3IDA4OjIzPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj48YnI+DQo8 Yj5Ubzo8L2I+IFJvbmkgRXZlbjsgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogY29u bmVjdGlvbiBtaWdyYXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+RXhhY3RseSB0aGUgc2FtZSB3YXkgdGhhdCBUQ1AtdG8tVENQIGhhbmRvZmYg YmV0d2VlbiB0aGVzZSBpbnRlcmZhY2VzIHdvcmtzIHRvZGF5LCBiZWNhdXNlIChub24tTVApIFRD UCBpc27igJl0IGNhcGFibGUgb2YgY2hhbmdpbmcgdG8gYSBkaWZmZXJlbnQgaW50ZXJmYWNlLiZu YnNwOyBXZeKAmXJlIHRyeWluZyB0byBidWlsZA0KIGEgYmV0dGVyIGFuc3dlciwgYnV0IHlvdeKA mXJlIHBvc2l0aW5nIGZyb20gdGhlIHN0YXJ0IHRoYXQgY29ubmVjdGlvbiBtaWdyYXRpb24gZmFp bHMsIHNvIHdl4oCZcmUgbm93IGluIOKAnG5vIHdvcnNl4oCdIGxhbmQuPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGUgUVVJQyBzdGFjayBpbiB0aGUgY2xpZW50IGRldmljZSB3aWxsIHNl ZSBhIG5ldyBpbnRlcmZhY2UgaXMgYXZhaWxhYmxlLiZuYnNwOyBJdCBhdHRlbXB0cyB0byBzd2l0 Y2ggdG8gaXQsIGJlY2F1c2Ugb2Ygc29tZSBsb2NhbCBwb2xpY3kuJm5ic3A7IFRoZSB0cmFuc2l0 aW9uIGZhaWxzIGZvciB3aGF0ZXZlciByZWFzb24sDQogYnV0IHRoZSBjZWxsdWxhciBjb25uZWN0 aW9uIGlzIHN0aWxsIGFjdGl2ZS4mbmJzcDsgSXQgaXMgdGhlIGFwcGxpY2F0aW9u4oCZcyBjaG9p Y2UgPG86cD4NCjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PGk+PHNwYW4g c3R5bGU9ImNvbG9yOiMxRjQ5N0QiPltSb25pIEV2ZW5dIHdoaWNoIGFwcGxpY2F0aW9uIGlmIHRo ZXJlIGlzIG1vcmUgdGhhbiBvbmU/IEluIHRoZSBUQ1AgY2FzZSB5b3Ugc3RheSBpbiB0aGUgY2Vs bC4gSGVyZSB0aGVyZSBhcmUgdHdvIG9wdGlvbnMsIHN0YXkgb24gdGhlIGNlbGwgd2l0aA0KIFFV SUMgb3IgbW92ZSB0byB3aWZpIG9uIFRDUDwvc3Bhbj48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj53aGV0aGVyIGl0IHdhbnRzIHRvIHdpbmQgZG93biBhbmQg Y2xvc2UgdGhhdCBjb25uZWN0aW9uIGFuZCBzdGFydCBhIG5ldyBvbmUgdXNpbmcgVENQLCBvciBr ZWVwIHVzaW5nIHRoZSBvbGQgb25lIGlmIHRoZSBpbnRlcmZhY2UgcmVtYWlucyBhdmFpbGFibGUu Jm5ic3A7IElmIHRoZXJlIGFyZSBtdWx0aXBsZSBhcHBsaWNhdGlvbnMsDQogZWFjaCBhcHBsaWNh dGlvbiBtYWtlcyB0aGF0IGNob2ljZSBpbmRlcGVuZGVudGx5LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+QW5kIGlmIHRoZSBmaXJzdCBpbnRlcmZhY2UgYmVjb21lcyB1bmF2YWlsYWJsZSBm b3Igd2hhdGV2ZXIgcmVhc29uLCB0aGUgY2hvaWNlIGlzIG1hZGUgZm9yIGl0LCBhbmQgdGhlIGFw cGxpY2F0aW9uIHdpbGwgaGF2ZSB0byByZWNvdmVyLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBSb25pIEV2 ZW4gWzxhIGhyZWY9Im1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2Vk bmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyAxOjI1IFBNPGJyPg0KPGI+VG86PC9iPiBNaWtlIEJp c2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9i bGFuayI+bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0i bWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZn dDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGNvbm5lY3Rpb24gbWlncmF0aW9uPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPlNvIHdoYXQgaXMgdGhlIGNvbm5lY3Rpb24gbWlncmF0aW9uIGZsb3cgaGVyZS4gVGhl IHF1aWMgc3RhY2sgaW4gdGhlIGNlbGwgbmV0d29yayB3aWxsIHRyeSB0byBtaWdyYXRlIHRvIHdp Zmkgd2l0aG91dCBhcHBsaWNhdGlvbiByZXF1ZXN0IGFuZCBmYWlsIGJ1dA0KIHdpbGwgbm90IGZh bGwgYmFjayB0byBUQ1AuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+VGhlcmUgbWF5IGJlIG11bHRpcGxlIGFw cGxpY2F0aW9uIHJ1bm5pbmcgb3ZlciBxdWljPyBIVFRQIGFuZCBwZWVyIHRvIHBlZXIgYXQgdGhl IHNhbWUgdGltZSwgc28gd2hvIHdpbGwgaGFuZGxlIHRoaXMgY2FzZT88L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Sb25pPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5z LXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPiBNaWtlIEJpc2hvcCBbPGEg aHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRv Om1iaXNob3BAZXZlcXVlZm91LmJlPC9hPl0NCjxicj4NCjxiPlNlbnQ6PC9iPiA8L3NwYW4+PHNw YW4gbGFuZz0iSEUiIGRpcj0iUlRMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+15nXldedPC9zcGFuPjxzcGFuIGRpcj0i TFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+Jm5ic3A7 PC9zcGFuPjxzcGFuIGxhbmc9IkhFIiBkaXI9IlJUTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPteTDQo8L3NwYW4+PHNw YW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssc2Fucy1zZXJpZiI+PHNwYW4gZGlyPSJMVFIiPjwvc3Bh bj4xNQ0KPC9zcGFuPjxzcGFuIGxhbmc9IkhFIiBkaXI9IlJUTCIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPteg15XXkdee 15HXqA0KPC9zcGFuPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNhbnMtc2VyaWYiPjxzcGFu IGRpcj0iTFRSIj48L3NwYW4+MjAxNyAwNTozNTxicj4NCjxiPlRvOjwvYj4gUm9uaSBFdmVuOyBR VUlDIFdHPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBjb25uZWN0aW9uIG1pZ3JhdGlvbjwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGF0IG1heSB3 ZWxsIGJlIHRoZSBjYXNlLCBidXQgaXTigJlzIG5vdCB0aGUgUVVJQyBzdGFja+KAmXMgY2hvaWNl IHRvIG1ha2UuJm5ic3A7IFRoZSBhcHBsaWNhdGlvbiBjb3VsZCBjaG9vc2UgdG8gb3BlbiBhIG5l dyBjb25uZWN0aW9uLCBidXQgdGhhdCByZW1haW5zIG91dHNpZGUgdGhlIHNjb3BlIG9mIHRoZSB0 cmFuc3BvcnQNCiBhbmQgdGhlIG1hcHBpbmcgdG8gaXQgd2hpY2ggd2XigJlyZSBkZWZpbmluZy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkZvciBIVFRQLCB0aGlzIGlzIGZhaXJseSBzdHJh aWdodGZvcndhcmQg4oCTIGl0IGNvdWxkIHN0b3AgaXNzdWluZyBuZXcgZmxvdyBjb250cm9sIGNy ZWRpdCwgbGV0IGN1cnJlbnRseS1pbi10cmFuc2l0IGRhdGEgYXJyaXZlIGFuZCBhbnkgbG9zc2Vz IHJlY292ZXJlZCwgYW5kIG9wZW4gYSBUQ1AgY29ubmVjdGlvbg0KIHRvIGlzc3VlIGEgcmFuZ2Ug cmVxdWVzdCBzdGFydGluZyBhdCB3aGF0ZXZlciBkYXRhIG9mZnNldCBpdCBoYXNu4oCZdCBzZWVu LiZuYnNwOyBCdXQgdGhhdOKAmXMgc3RpbGwgYSBwcm9wZXJ0eSBvZiBhbiBIVFRQIG1hbmFnZW1l bnQgYWJvdmUgdGhlIEhUVFAvUVVJQyBtYXBwaW5nLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAw aW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBRVUlDIFs8 YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+bWFp bHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPlJvbmkg RXZlbjxicj4NCjxiPlNlbnQ6PC9iPiBXZWRuZXNkYXksIE5vdmVtYmVyIDE1LCAyMDE3IDExOjI1 IEFNPGJyPg0KPGI+VG86PC9iPiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1Ympl Y3Q6PC9iPiBjb25uZWN0aW9uIG1pZ3JhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkhpLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5XaGVuIG1vdmluZyBmcm9tIGNlbGwgdG8gd2lmaSB0aGUgcmVhc29uIG1heSBiZSBkdWUgdG8g Y29zdCAobW9uZXkgb3IgcXVvdGEpLiBJbiB0aGlzIGNhc2UgdGhlJm5ic3A7IHVzZXIgKGNsaWVu dCkgbWF5IHdhbnQgdG8gbW92ZSB0byB3aWZpIGV2ZW4gaWYgaXQgd2lsbCBtZWFuIGRyb3BwaW5n IHRvIFRDUC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJvbmk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_55a2d469c30d4ba58c55c328defd2872usma1exdag1mb5msgcorpak_-- From nobody Wed Nov 15 14:55: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 643BB128BBB for ; Wed, 15 Nov 2017 14:55: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 TNKeAfq_HqW7 for ; Wed, 15 Nov 2017 14:55:47 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::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 841371293E8 for ; Wed, 15 Nov 2017 14:54:51 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id 9so6028909wme.4 for ; Wed, 15 Nov 2017 14:54:51 -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=ermUyj0fGkGKeIbycP7EcCQRtTy2aE9/sJXXYO3jBVk=; b=jtu+j0VDd2PZtteB2g+b8KUOL99uJyLdo7gXcxzhS8xTvX23gjni8VXrVKyAVZ3GFd q+luWMqPpQLXvUDp3TX0j8a6ljO7Ii80p0vJ3pQ61rn3zB88DRH5uwNMsToZcFsQ120k bz4hvulJzhYVz4vhGs1IKNvF6o3t74jwUxrJu0DVl+G/m8orlcvY9yMsMXFNpTCqBe6B 8m6Xr/IG6kOX383nDUCGFOZNSwck8uOGGWNNsRNnXBJTruov4E72HbD1X7Fwp2K2QsXe ShO/qFN+rv8pNxEaLuwYZZaNWRPhANocGj7zJIC7nE/PyxesyttcvTyxMugLQc6dYPOA 1lBQ== 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=ermUyj0fGkGKeIbycP7EcCQRtTy2aE9/sJXXYO3jBVk=; b=sDZldheRHbB/Dv0SE/Pe/vw6GWT6zd76arCmIdO5GbstOiIei+iW9NKF54Zr3NnXyh UfqKWHgEamXW2IWxzL9o1O7kV/qetOYq7YUy/39N7mZ9m4McofKUSEgouMxRJHTrKHcD EBejB0FoF5s14zA7S8xLJBCG+yWgGcvYqC0bvcWfd/JcEqh4nFPtzyMsZr0km34wsS5L j9uj8hgV48G8H9wAprzHV4EDosGEYTSy4BxJe7I0Jz2jPS2DbyqWAYCVjFw8bkZLT1oL wyJQPwk4A3gTjSdVWa8k+UAyZmuH6KEa2k7RTDjwcZQ7mfq51IumFpG2ya2w3IGPgrMp oSfg== X-Gm-Message-State: AJaThX56P1bCb58ghOcVYkSpp4zGv52OYXpEKXSQmbIhYhdb1TLg70wA aD68iQIHcTnj3OKx9RhGfIlNDKcCgrKSptV1Og0= X-Google-Smtp-Source: AGs4zMbJL2n/YLUiOxbapdqghP+Yz6msQD7JTb6S3BR2+rcI00JwZO0b2PjFRpi+nU3sP4klmEq5h6ZF2yjqkuhsDdo= X-Received: by 10.28.230.140 with SMTP id e12mr6204wmi.118.1510786489844; Wed, 15 Nov 2017 14:54:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.3 with HTTP; Wed, 15 Nov 2017 14:54:49 -0800 (PST) In-Reply-To: <2C515BE8694C6F4B9B6A578BCAC32E2F83AC9673@MBX021-W3-CA-2.exch021.domain.local> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> <5A0BD528.3040106@erg.abdn.ac.uk> <2C515BE8694C6F4B9B6A578BCAC32E2F83AC9673@MBX021-W3-CA-2.exch021.domain.local> From: Martin Duke Date: Wed, 15 Nov 2017 14:54:49 -0800 Message-ID: Subject: Re: spin bit in QUIC: troubleshooting To: Piotr Galecki Cc: "gorry@erg.abdn.ac.uk" , "MORTON, ALFRED C (AL)" , Ian Swett , QUIC WG , "emile.stephan@orange.com" Content-Type: multipart/alternative; boundary="001a11476fe20f0906055e0d643e" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 22:55:50 -0000 --001a11476fe20f0906055e0d643e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Packet numbers are unencrypted and monotonically increasing. It is therefore relatively straightforward to measure reordering between any two points in the network if you have instruments there. On Tue, Nov 14, 2017 at 9:59 PM, Piotr Galecki < piotr_galecki@affirmednetworks.com> wrote: > How would a network probe be able to measure the level of packet > reordering in QUIC stream with only a spin bit? > > I'm asking because one of the common techniques to diagnose network issue= s > is to insert a probe in different points in the network and measure: > * RTT > * TCP segment loss > * TCP segment retransmissions > * TCP segment out-of-order > as a few basic data points. > With measurements in point A and point B one can determine for example if > a network device is misordering packets. > > -Piotr > > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Gorry Fairhurst > Sent: Wednesday, November 15, 2017 12:48 AM > To: MORTON, ALFRED C (AL) > Cc: Ian Swett ; QUIC WG ; > emile.stephan@orange.com > Subject: Re: spin bit in QUIC: troubleshooting > > As I said at the mic: I think the spin-bit analysis was helpful, thanks. > > I can see how spin-bit is really useful to get basic diagnostics of RTT i= f > it can be relied to be present in every packet. (It is important to measu= re > latency within the network). > > There are places where 1-bit gives restricted value, and using more would > help: My additional comment at the Mic related to how much extra would be > the gain from an additional one or two bits? > > In particular, I'd like to see a method that can let me detect some loss > patterns and measure reordering, at least I think it is important to know > and measure when there is small-scale reordering <3. > > A suggestion:is to use a 2-bit counter for the spin ( > 00->01->10->11->00), that would help detect these path anomlies. > > Gorry > > On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote: > > > > I=E2=80=99d like to offer support for Spin Bit (and one or two > > > > bits for management if they can be justified quickly) in v1. > > > > On this topic of more bits, > > > > asking further clarification from Emile, below [ACM]. > > > > Al > > > > *From:*QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > > *Sent:* Tuesday, November 14, 2017 4:21 PM > > *To:* emile.stephan@orange.com > > *Cc:* QUIC WG > > *Subject:* Re: spin bit in QUIC: troubleshooting > > > > Thanks for clarifying Emile. > > > > On Tue, Nov 14, 2017 at 1:06 PM, > > wrote: > > > > Hi Ian, > > > > It was suggested in the latest discussion on the RTT design team > > mailing list to have one bit for packet lost, one for latency (spin > > bit or eq.) and one for congestion. > > > > */[ACM] /* There may be some overlap with ECN and =C2=AB one bit for > > congestion =C2=BB. > > > > Did you also consider this dependency, Emile ? (I=E2=80=99m echoing a h= allway > > discussion) > > > > It seems a simplistic approach on one hand but an invariant on the > > long term. > > > > Regards > > > > Emile > > > > *De :*Ian Swett [mailto:ianswett@google.com > > ] *Envoy=C3=A9 :* mardi 14 novembre 2017 22= :51 > > *=C3=80 :* STEPHAN Emile IMT/OLN *Cc :* QUIC WG *Objet :* Re: spin bit = in > > QUIC: troubleshooting > > > > What would the other bit or two be used for? If there is no > > standardized use of those bits in v1, then I believe we should wait to > > reserve them when their usage is defined, given we'd need a version > > bump to specify how they were being used. At the moment, the > > management use case is not competing with anyone else for bits in the > > short header. > > > > On Tue, Nov 14, 2017 at 5:14 AM, > > wrote: > > > > Hi > > > > Last week Orange experienced a fallback of QUIC to TCP on one of its > > networks. The issues were not visible in QUIC traffic. The > > troubleshooting was made using TCP packets information. This is not > > sustainable on the long term when numerous applications using > > different versions of QUIC will stop to fallback to TCP. > > > > Based on the exchange we had in the RTT design team and in today > > meeting , it sounds reasonable to reserve at least 2 bits (ideally 3 > > bits as discussed in the design team) for manageability in the QUIC > > invariants and to start experimenting the spin bit in QUIC V1. > > > > Regards > > > > Emile > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e > les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > > Thank you. > > > > ______________________________________________________________________ > > ___________________________________________________ > > > > Ce message et ses pieces jointes peuvent contenir des informations > > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, > > exploites ou copies sans autorisation. Si vous avez recu ce message > > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi qu= e > les pieces jointes. Les messages electroniques etant susceptibles > d'alteration, Orange decline toute responsabilite si ce message a ete > altere, deforme ou falsifie. Merci. > > > > This message and its attachments may contain confidential or > > privileged information that may be protected by law; they should not be > distributed, used or copied without authorisation. > > If you have received this email in error, please notify the sender and > delete this message and its attachments. > > As emails may be altered, Orange is not liable for messages that have > been modified, changed or falsified. > > Thank you. > > > --001a11476fe20f0906055e0d643e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Packet numbers are unencrypted and monotonically increasin= g. It is therefore relatively straightforward to measure reordering between= any two points in the network if you have instruments there.

On Tue, Nov 14, 2017 at 9= :59 PM, Piotr Galecki <piotr_galecki@affirmednetworks.com= > wrote:
How would a networ= k probe be able to measure the level of packet reordering in QUIC stream wi= th only a spin bit?

I'm asking because one of the common techniques to diagnose network iss= ues
is to insert a probe in different points in the network and measure:
* RTT
* TCP segment loss
* TCP segment retransmissions
* TCP segment out-of-order
as a few basic data points.
With measurements in point A and point B one can determine for example if a= network device is misordering packets.

-Piotr

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Gorry Fairhurst
Sent: Wednesday, November 15, 2017 12:48 AM
To: MORTON, ALFRED C (AL) <acmorton@= att.com>
Cc: Ian Swett <ianswett@google.co= m>; QUIC WG <quic@ietf.org&g= t;; emile.stephan@orange.com
Subject: Re: spin bit in QUI= C: troubleshooting

As I said at the mic: I think the spin-bit analysis was helpful, thanks.
I can see how spin-bit is really useful to get basic diagnostics of RTT if = it can be relied to be present in every packet. (It is important to measure= latency within the network).

There are places where 1-bit gives restricted value, and using more would h= elp: My additional comment at the Mic related to how much extra would be th= e gain from an additional one or two bits?

In particular, I'd like to see a method that can let me detect some los= s patterns and measure reordering, at least I think it is important to know= and measure when there is small-scale reordering <3.

A suggestion:is to use a 2-bit counter for the spin (
00->01->10->11->00), that would help detect these path anomlies= .

Gorry

On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote:
>
> I=E2=80=99d like to offer support for Spin Bit (and one or two
>
> bits for management if they can be justified quickly) in v1.
>
> On this topic of more bits,
>
> asking further clarification from Emile, below [ACM].
>
> Al
>
> *From:*QUIC [mailto:quic-boun= ces@ietf.org] *On Behalf Of *Ian Swett
> *Sent:* Tuesday, November 14, 2017 4:21 PM
> *To:* emile.stephan@orange= .com
> *Cc:* QUIC WG
> *Subject:* Re: spin bit in QUIC: troubleshooting
>
> Thanks for clarifying Emile.
>
> On Tue, Nov 14, 2017 at 1:06 PM, <emile.stephan@orange.com
> <mailto:emile.stephan@o= range.com>> wrote:
>
> Hi Ian,
>
> It was suggested in the latest discussion on the RTT design team
> mailing list to have one bit for packet lost, one for latency (spin > bit or eq.) and one for congestion.
>
> */[ACM] /* There may be some overlap with ECN and =C2=AB one bit for > congestion =C2=BB.
>
> Did you also consider this dependency, Emile ? (I=E2=80=99m echoing a = hallway
> discussion)
>
> It seems a simplistic approach on one hand but an invariant on the
> long term.
>
> Regards
>
> Emile
>
> *De :*Ian Swett [mailto:ianswet= t@google.com
> <mailto:ianswett@google.com<= /a>>] *Envoy=C3=A9 :* mardi 14 novembre 2017 22:51
> *=C3=80 :* STEPHAN Emile IMT/OLN *Cc :* QUIC WG *Objet :* Re: spin bit= in
> QUIC: troubleshooting
>
> What would the other bit or two be used for?=C2=A0 If there is no
> standardized use of those bits in v1, then I believe we should wait to=
> reserve them when their usage is defined, given we'd need a versio= n
> bump to specify how they were being used.=C2=A0 At the moment, the
> management use case is not competing with anyone else for bits in the<= br> > short header.
>
> On Tue, Nov 14, 2017 at 5:14 AM, <emile.stephan@orange.com
> <mailto:emile.stephan@o= range.com>> wrote:
>
> Hi
>
> Last week Orange experienced a fallback of QUIC to TCP on one of its > networks. The issues were not visible in QUIC traffic. The
> troubleshooting was made using TCP packets information. This is not > sustainable on the long term when numerous applications using
> different versions of QUIC will stop to fallback to TCP.
>
> Based on the exchange we had in the RTT design team and in today
> meeting , it sounds reasonable to reserve at least 2 bits (ideally 3 > bits as discussed in the design team) for manageability in the QUIC > invariants and to start experimenting the spin bit in QUIC V1.
>
> Regards
>
> Emile
>
> ____________________________________________________________= __________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,<= br> > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ain= si que les pieces jointes. Les messages electroniques etant susceptibles d&= #39;alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
> Thank you.
>
> ____________________________________________________________= __________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,<= br> > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ain= si que les pieces jointes. Les messages electroniques etant susceptibles d&= #39;alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
> Thank you.
>

--001a11476fe20f0906055e0d643e-- From nobody Wed Nov 15 14:57: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 08FAA128BBB for ; Wed, 15 Nov 2017 14:57:57 -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 dpxBQ1GYNI3P for ; Wed, 15 Nov 2017 14:57:55 -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 BACFF128B93 for ; Wed, 15 Nov 2017 14:57:54 -0800 (PST) Received: by mail-wr0-x231.google.com with SMTP id y42so21827573wrd.3 for ; Wed, 15 Nov 2017 14: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=xmRY3pl7DFM9lX+kIH0aFMLb92+FMLjVQwDspqHKgAI=; b=GO+pq4x1HFir0Z4YjctnkY5qVZTrY+N3JoxQ1s6RctLyY9S4LU0AP8bIdVvKDMLxqv DxfkQJbDsJfGt6WDJL1mn4p2SLcAZj6kp0yjC3AdzXB0Iwzl4OlvB1J44+9g+zk0johe axWFq0h0gxUyU5SDColAqH5gJXHG7Am4C3Xv+Nrm15Stf0bHn7PV0ILgQsARJ6J3JFhC f1eWK0v+vZRlRc/+MZAzBtkKFJURo2Zdt/JFooRW+DUbDMKAnp/sG27IcGqIvWWWpPUu 2GgJqonCySN/FNe18gbTXtxu6us4GYRAPag0Mt6pe8Vi6yCqfL3PXHROyL/znmMY1Snz Y3tg== 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=xmRY3pl7DFM9lX+kIH0aFMLb92+FMLjVQwDspqHKgAI=; b=ODOKpPa0hUEi/5/HVskgsZretP0hvoWqCcp1o4jn9i1moakwgmxkWiLq+oOhFEApwc GGHiwtIMj6Z3VPHODM5QGPWe7utzfsPkb/sC/md/umEhwS8VxnSzPxMapKJu+uvQaZKc w/LardGJQuE+VaLlJqR5NchsRjMqOpuZypYCOGfjZK/nkKVHhVssXhY7Xyc4F16RXZml pflfSLAU9NooGXTUJKhj06OoRnFFYkd02U0BoXK9hJJLjDGH3Xo+mOL0dEvbV1/BCz9t G0S55MroUjkN2NaY9tHck7UhjBSBC7Tcs+abdrBzUQ0fr9Bl4SVztIJBmlsszBtuGSEx PcdQ== X-Gm-Message-State: AJaThX4I+4sZmYeJ82EbdtdQOcYRinY2VwXeoag2VKZh5JISsudVZDud FzD87gFEjgQWoOYHkLV8CW0PQZne0ySybnBqYgy+9w== X-Google-Smtp-Source: AGs4zMYRqC5fs9Sna78eOg9HcIggdmOWgCexp8J+8lydPGgauDaujAb+vdml+LQwyuYY4/Y4MbwEKuBdEkSZVkxU7wA= X-Received: by 10.223.186.142 with SMTP id p14mr954428wrg.169.1510786673328; Wed, 15 Nov 2017 14:57:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.223.165.3 with HTTP; Wed, 15 Nov 2017 14:57:52 -0800 (PST) In-Reply-To: <4b4cc53c-25c0-1761-5cfd-ecc66f103de1@zinks.de> References: <841DB971-DB34-4948-B65E-B9E27741D7EC@gmail.com> <6E58094ECC8D8344914996DAD28F1CCD836F41@DGGEMM506-MBX.china.huawei.com> <4b4cc53c-25c0-1761-5cfd-ecc66f103de1@zinks.de> From: Martin Duke Date: Wed, 15 Nov 2017 14:57:52 -0800 Message-ID: Subject: Re: ACKs in encrypted tunnel To: Roland Zink Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e08243200fec6e4055e0d6e2c" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 22:57:57 -0000 --089e08243200fec6e4055e0d6e2c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There are some issues open for additional bits to signal loss and flow control limitations, but I believe the rough consensus is that RTT (plus the packet numbers available in cleartext) are sufficient for v1. As the person who filed several of those issues, my opinion is that other signals would require their own analysis of information leakage and the WG will probably not take action in the limited time for v1. On Wed, Nov 15, 2017 at 2:00 AM, Roland Zink wrote: > Not sure about that. The end user doesn't know how to do this and the OS > are trying to ensure that this will not happen. Assuming it is easy to ge= t > the keys from users then this is a security problem. So we must assume ke= ys > are not available. > > > Roland > > > > Am 15.11.2017 um 04:37 schrieb Mike Bishop: > > Also, if the end point(s) consent to give you the keys, nothing stops you > from inspecting a particular flow. It requires the active cooperation of > at least one party to the connection, but if someone=E2=80=99s calling yo= u for > help, that=E2=80=99s presumably the case. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Roni Even > *Sent:* Wednesday, November 15, 2017 11:31 AM > *To:* Bret Jordan ; > quic@ietf.org > *Subject:* RE: ACKs in encrypted tunnel > > > > Hi, > > This is discussed in the spin bit that was presented yesterday > > Roni > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Bret Jordan > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 05:26 > *To:* quic@ietf.org > *Subject:* ACKs in encrypted tunnel > > > > So my understanding is that all ACKs and notices about lost packets, > frames, etc will be communicated inside the encrypted tunnel with QUIC. > > > > What is our plan to enable network operators to help troubleshoot network > problems with QUIC? > > > > When running a large network the network team / network operators are > often asked to help identify problems when an application is not working = or > is sluggish. If all information is inside the encrypted tunnel, are we ju= st > saying =E2=80=9Cend user and application support person, you figure it ou= t?=E2=80=9D > > > > This seems like a huge problem. I mean the network does not always work > flawlessly and it seems like we are removing all the abilities for networ= k > operators to ensure any level of SLA or OLA. > > > > Bret > > > > Sent from my Commodore 128D > > > > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > > > --089e08243200fec6e4055e0d6e2c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
There are some issues open for additional bits to signal l= oss and flow control limitations, but I believe the rough consensus is that= RTT (plus the packet numbers available in cleartext) are sufficient for v1= .

As the person who filed several of those issues, my op= inion is that other signals would require their own analysis of information= leakage and the WG will probably not take action in the limited time for v= 1.

On = Wed, Nov 15, 2017 at 2:00 AM, Roland Zink <roland@zinks.de> wr= ote:
=20 =20 =20

Not sure about that. The end user doesn't know how to do this an= d the OS are trying to ensure that this will not happen. Assuming it is easy to get the keys from users then this is a security problem. So we must assume keys are not available.


Roland



Am 15.11.2017 um 04= :37 schrieb Mike Bishop:
=20 =20 =20

Also, if the end point(s) consent to give you the keys, nothing stops you from inspecting a particular flow.=C2=A0 It requires the active cooperation of at least one party to the connection, but if someone=E2=80=99s calling you for help, that= =E2=80=99s presumably the case.

=C2=A0

From: QUIC [mailto:quic-boun= ces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:31 AM
To: Bret Jordan <jordan.ietf@gmail.com>; quic@ietf.org
Subject: RE: ACKs in encrypted tunnel<= /span>

=C2=A0

Hi,

This is discussed in the spin bit that was presented yesterday

Roni

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Bret Jordan
Sent: =D7=99=D7=95= =D7=9D=C2=A0=D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 05:26
To: quic@ietf.org
Subject: ACKs in encrypted tunnel

=C2=A0

So my understanding is that all ACKs and notices about lost packets, frames, etc will be communicated inside the encrypted tunnel with QUIC.

= =C2=A0

What is our plan to enable network operators to help troubleshoot network problems with QUIC?=C2=A0

= =C2=A0

When running a large network the network team / network operators are often asked to help identify problems when an application is not working or is sluggish. If all information is inside the encrypted tunnel, are we just saying =E2=80=9Cend user and application support person, you figure it out?=E2=80=9D=C2=A0

= =C2=A0

This seems like a huge problem.=C2=A0 I = mean the network does not always work flawlessly and it seems like we are removing all the abilities for network operators to ensure any level of SLA or OLA. =C2=A0=

= =C2=A0

Bret=C2=A0

=C2=A0

Sent from my Commodore 128D

= =C2=A0

PGP Fingerprint:=C2=A063B4 FC53 680A 6= B7D 1447 =C2=A0F2C0 74F8 ACAE=C2=A07415 0050



--089e08243200fec6e4055e0d6e2c-- From nobody Wed Nov 15 16:24: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 5F300126DFE for ; Wed, 15 Nov 2017 16:24:35 -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 AROGrfg3Wjxm for ; Wed, 15 Nov 2017 16:24:32 -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 3821D120721 for ; Wed, 15 Nov 2017 16:24:32 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id q1so18026663ywh.5 for ; Wed, 15 Nov 2017 16:24: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=ygv4WiFlfVRLY7VxSdPenIzj3R/icGCX+ePt5jrn6mQ=; b=DRgji+/zrRTtDJ9rMMKidYxLHIwEBHNVMR3oATnsqOmejNs27HT5lPNYdbS+OPlTIx kUYM/XN3QA2M9klR4I1npk6fgDErCx4lBYINzv9XS48IPkllszburJD58iA2GSY1PeEn GsLTU0W0PNotwBHL29X661ZXUN4RZT6xZOOfBNWVw7wrqDOOTg+CjwHvzHLsihFGyduL JInW94xzof778/JlPhzH3sI+S5pOgyMXZObw5BmO+h+W77WYzGyPH/Y9DJytCr+27uto QjguN4a/WV1wkoQ4E+xq11/pNPx7EktKKN4BdCsRvoaSOMuVmRO7zYSiLgqvAlFjiRMB Ns9g== 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=ygv4WiFlfVRLY7VxSdPenIzj3R/icGCX+ePt5jrn6mQ=; b=k0FEkmH+bvbyDfTIAYO0KqWV3ROF+w3VgIsEw48d7AfbJlvnwW9yZ6SrIniAaVzlj1 I7fykvFaB79VBqyoI4PB7S8yBalFGAeBupjf0+/kWqY8ggqqo3JVSRm+xVqpQ70ZRU+p zWmqkx/WflWVdSZ2NBmAOujGrtgZPuiNx1kFNGo4LYWOQaAwpNOvYAU2wr81qU14HovQ jCHDdSRVZJjj3FsaYP50cmbU55MvZZT9U6frYhzwXDVh6igf8dD+oOLa8WAjx47J26QF amH1iqDDW/UTdO9lrmycrI4rEhKUxoQgu4VNJz04O5Ub08/xc4s1jV6aVzecEk3TMBDV 2bZg== X-Gm-Message-State: AJaThX7vOjeA+bcQIg32J8P7e9EyJx5X4lVTqDhMVubClMM/FNHEBs6G z3Kd1fq4PCkd/I7USYT9aFTyrxPRwWvblFFTTh8= X-Google-Smtp-Source: AGs4zMY4L9uJdpl5rszaUf7P0svyBK0cNJm6WcmoJ5bZBZsxm1ZlX4tPLcFfmD0nfhydPlcKjmuHuYmylhmlMA0jeOM= X-Received: by 10.37.177.6 with SMTP id g6mr1055988ybj.379.1510791871224; Wed, 15 Nov 2017 16:24:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.75 with HTTP; Wed, 15 Nov 2017 16:24:30 -0800 (PST) In-Reply-To: <55a2d469c30d4ba58c55c328defd2872@usma1ex-dag1mb5.msg.corp.akamai.com> References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837234@DGGEMM506-MBX.china.huawei.com> <55a2d469c30d4ba58c55c328defd2872@usma1ex-dag1mb5.msg.corp.akamai.com> From: Spencer Dawkins at IETF Date: Thu, 16 Nov 2017 08:24:30 +0800 Message-ID: Subject: Re: connection migration To: "Lubashev, Igor" Cc: Roni Even , Jana Iyengar , Mike Bishop , QUIC WG Content-Type: multipart/alternative; boundary="f403045f2b44d06008055e0ea49a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 00:24:35 -0000 --f403045f2b44d06008055e0ea49a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking as a curious individual, but not more. On Wed, Nov 15, 2017 at 11:43 PM, Lubashev, Igor wrote: > Roni, if an application decides to switch from QUIC to TCP, there will be > no connection migration. The application will have to establish a new > connection over TCP, likely, renegotiate crypto, and whatever QUIC stream= s > were in progress will not just migrate and continue over TCP somehow. > Seamless connection migration between QUIC and TCP is certainly outside o= f > the charter. > It's probably good for me to say that as I understand it, migration, and especially migration between transport protocols, is a session protocol thing, and we really don't have a session protocol level in the Internet. We rely on applications making decisions like this, rather than trying to make decisions lower in the stack for the application. When we have MP-TCP, as I understand it, TCP itself barely changes, so that's less true, but it's still close. I rely on working groups to make informed decisions about stuff like this, but I wouldn't be surprised to see an MP-QUIC to be look sort of like MP-TCP, when the working group starts making decisions about multi-path. And I see migration as roughly multipath when an application uses one path at a time, at the 10,000-meter level. I could be wrong, but that's my guess. IMO. Spencer Apologies, if I misunderstood your intent, and you were talking about > something other than how to migrate connections from QUIC to TCP. > > > > - Igor > > > > > > *From:* Roni Even [mailto:roni.even@huawei.com] > *Sent:* Wednesday, November 15, 2017 10:21 PM > *To:* Jana Iyengar ; Mike Bishop > *Cc:* QUIC WG > *Subject:* RE: connection migration > > > > Hi, > > I apologize if anyone felt that I was being sarcastic. To me it looks tha= t > there is some difference. My understanding that there is separation betwe= en > the transport (QUIC) and the application (HTTP first and other later). > > An application can see in the TCP case two options TCP on or TCP off. In > QUIC it sees three options QUIC on, QUIC off (no connection), TCP. If one > of the physical connection is closed there is no problem. I assumed that > both physical connection are kept open (when I enter the house I connect = to > the AP but the 3G data channel is still open) but the application will tr= y > to send data on the wifi network and not on the cellular network since th= is > is the policy, am I wrong? > > Roni > > > > *From:* Jana Iyengar [mailto:jri@google.com ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 13:43 > *To:* Mike Bishop > *Cc:* Roni Even; QUIC WG > *Subject:* Re: connection migration > > > > What Mike said. The scope of QUIC, by definition, is not larger than QUIC= . > > > > On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop wrote= : > > Your sarcasm notwithstanding, I=E2=80=99ll emphasize that this is identic= al to TCP > today. Either the applications move, or they don=E2=80=99t. If the devi= ce > forcibly brings down the cellular interface=E2=80=99s data connection, th= e > applications will have to move if they didn=E2=80=99t already move gracef= ully, > which is independent of the transport=E2=80=99s properties. > > > > *From:* Roni Even [mailto:roni.even@huawei.com] > *Sent:* Wednesday, November 15, 2017 6:38 PM > > > *To:* Mike Bishop ; QUIC WG > *Subject:* RE: connection migration > > > > > > > > *From:* Mike Bishop [mailto:mbishop@evequefou.be ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 10:18 > *To:* Roni Even; QUIC WG > *Subject:* RE: connection migration > > > > No; in the TCP case your transport doesn=E2=80=99t have any migration pro= vision, > so it=E2=80=99s up to the application whether it wants to wind down the e= xisting > connection and start a new one. If migration fails with QUIC, the > situation is *exactly the same*, and the application decides whether it > wants to wind down the existing connection and start a new one. > > > > If there=E2=80=99s more than one application, then the answer to =E2=80= =9Cwhich > application=E2=80=9D is =E2=80=9Ceach application=E2=80=9D because each a= pplication owns its own > connections. > > *[Roni Even] So we can end up with one application on the cell and the > other on the wifi. Nice!!!* > > > > *From:* Roni Even [mailto:roni.even@huawei.com ] > *Sent:* Wednesday, November 15, 2017 3:44 PM > *To:* Mike Bishop ; QUIC WG > *Subject:* RE: connection migration > > > > inline > > > > *From:* Mike Bishop [mailto:mbishop@evequefou.be ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 08:23 > *To:* Roni Even; QUIC WG > *Subject:* RE: connection migration > > > > Exactly the same way that TCP-to-TCP handoff between these interfaces > works today, because (non-MP) TCP isn=E2=80=99t capable of changing to a = different > interface. We=E2=80=99re trying to build a better answer, but you=E2=80= =99re positing from > the start that connection migration fails, so we=E2=80=99re now in =E2=80= =9Cno worse=E2=80=9D land. > > > > The QUIC stack in the client device will see a new interface is > available. It attempts to switch to it, because of some local policy. T= he > transition fails for whatever reason, but the cellular connection is stil= l > active. It is the application=E2=80=99s choice > > *[Roni Even] which application if there is more than one? In the TCP case > you stay in the cell. Here there are two options, stay on the cell with > QUIC or move to wifi on TCP* > > whether it wants to wind down and close that connection and start a new > one using TCP, or keep using the old one if the interface remains > available. If there are multiple applications, each application makes th= at > choice independently. > > > > And if the first interface becomes unavailable for whatever reason, the > choice is made for it, and the application will have to recover. > > > > *From:* Roni Even [mailto:roni.even@huawei.com ] > *Sent:* Wednesday, November 15, 2017 1:25 PM > *To:* Mike Bishop ; QUIC WG > *Subject:* RE: connection migration > > > > So what is the connection migration flow here. The quic stack in the cell > network will try to migrate to wifi without application request and fail > but will not fall back to TCP. > > There may be multiple application running over quic? HTTP and peer to pee= r > at the same time, so who will handle this case? > > > > Roni > > > > *From:* Mike Bishop [mailto:mbishop@evequefou.be ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 05:35 > *To:* Roni Even; QUIC WG > *Subject:* RE: connection migration > > > > That may well be the case, but it=E2=80=99s not the QUIC stack=E2=80=99s = choice to make. > The application could choose to open a new connection, but that remains > outside the scope of the transport and the mapping to it which we=E2=80= =99re > defining. > > > > For HTTP, this is fairly straightforward =E2=80=93 it could stop issuing = new flow > control credit, let currently-in-transit data arrive and any losses > recovered, and open a TCP connection to issue a range request starting at > whatever data offset it hasn=E2=80=99t seen. But that=E2=80=99s still a = property of an > HTTP management above the HTTP/QUIC mapping. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Roni Even > *Sent:* Wednesday, November 15, 2017 11:25 AM > *To:* QUIC WG > *Subject:* connection migration > > > > Hi, > > When moving from cell to wifi the reason may be due to cost (money or > quota). In this case the user (client) may want to move to wifi even if = it > will mean dropping to TCP. > > > > Roni > > > --f403045f2b44d06008055e0ea49a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking as a curious individual, but not more.

On Wed, Nov 15, 2017 at 11:= 43 PM, Lubashev, Igor <ilubashe@akamai.com> wrote:

Roni, if an application decides to switch from QUIC= to TCP, there will be no connection migration.=C2=A0 The application will = have to establish a new connection over TCP, likely, renegotiate crypto, and whatever QUIC streams were in progress will not ju= st migrate and continue over TCP somehow.=C2=A0 Seamless connection migrati= on between QUIC and TCP is certainly outside of the charter.


It's probably good for me to s= ay that as I understand it, migration, and especially migration between tra= nsport protocols, is a session protocol thing, and we really don't have= a session protocol level in the Internet. We rely on applications making d= ecisions like this, rather than trying to make decisions lower in the stack= for the application.=C2=A0

When we have MP-TCP, a= s I understand it, TCP itself barely changes, so that's less true, but = it's still close.=C2=A0

I rely on working grou= ps to make informed decisions about stuff like this, but I wouldn't be = surprised to see an MP-QUIC to be look sort of like MP-TCP, when the workin= g group starts making decisions about multi-path.

= And I see migration as roughly multipath when an application uses one path = at a time, at the 10,000-meter level.=C2=A0

I coul= d be wrong, but that's my guess.=C2=A0

IMO.

Spencer

Apologies, if I misunderstood your intent, and you were talking a= bout something other than how to migrate connections from QUIC to TCP.

=C2=A0

  • Igor

=C2=A0

=C2=A0

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 10:21 PM
To: Jana Iyengar <jri@google.com>; Mike Bishop <mbishop@evequefou.be>
Cc: QUIC WG <q= uic@ietf.org>
Subject: RE: connection migration

=C2=A0

Hi,

I apologize if anyone felt that I was= being sarcastic. To me it looks that there is some difference. My understa= nding that there is separation between the transport (QUIC) and the application (HTTP first and other later).

An application can see in the TCP cas= e two options TCP on or TCP off. In QUIC it sees three options QUIC on, QUI= C off (no connection), TCP. If one of the physical connection is closed there is no problem. I assumed that both physical con= nection are kept open (when I enter the house I connect to the AP but the 3= G data channel is still open) but the application will try to send data on = the wifi network and not on the cellular network since this is the policy, am I wrong?

Roni

=C2=A0

From: Jana Iyengar [mailto:jri@google.com]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 = 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 13:43
To: Mike Bishop
Cc: Roni Even; QUIC WG
Subject: Re: connection migration

=C2=A0

What Mike said. The scope of QUIC, by definition, is= not larger than QUIC.

=C2=A0

On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop <mbishop@evequefou.be= > wrote:

Your sarcasm notwithstanding, I=E2=80=99ll emphasize= that this is identical to TCP today.=C2=A0 Either the applications move, o= r they don=E2=80=99t.=C2=A0 If the device forcibly brings down the cellular interface=E2=80=99s data connection, the applications will have to move if= they didn=E2=80=99t already move gracefully, which is independent of the t= ransport=E2=80=99s properties.

=C2=A0

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 6:38 PM


To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.org>
Subject: RE: connection migration

=C2=A0

=C2=A0

=C2=A0

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 = 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 10:18
To: Roni Even; QUIC WG
Subject: RE: connection migration

=C2=A0

No; in the TCP case your transport doesn=E2=80=99t h= ave any migration provision, so it=E2=80=99s up to the application whether = it wants to wind down the existing connection and start a new one.=C2=A0 If migration fails with QUIC, the situation is exactly the same, an= d the application decides whether it wants to wind down the existing connec= tion and start a new one.

=C2=A0

If there=E2=80=99s more than one application, then t= he answer to =E2=80=9Cwhich application=E2=80=9D is =E2=80=9Ceach applicati= on=E2=80=9D because each application owns its own connections.

[Roni Even] So w= e can end up with one application on the cell and the other on the wifi. Ni= ce!!!

=C2=A0

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 3:44 PM
To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.org>
Subject: RE: connection migration

=C2=A0

inline

=C2=A0

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 = 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 08:23
To: Roni Even; QUIC WG
Subject: RE: connection migration

=C2=A0

Exactly the same way that TCP-to-TCP handoff between= these interfaces works today, because (non-MP) TCP isn=E2=80=99t capable o= f changing to a different interface.=C2=A0 We=E2=80=99re trying to build a better answer, but you=E2=80=99re positing from the start that connectio= n migration fails, so we=E2=80=99re now in =E2=80=9Cno worse=E2=80=9D land.=

=C2=A0

The QUIC stack in the client device will see a new i= nterface is available.=C2=A0 It attempts to switch to it, because of some l= ocal policy.=C2=A0 The transition fails for whatever reason, but the cellular connection is still active.=C2=A0 It is the application= =E2=80=99s choice

[Roni Even] whic= h application if there is more than one? In the TCP case you stay in the ce= ll. Here there are two options, stay on the cell with QUIC or move to wifi on TCP

whether it wants to wind down and close that connect= ion and start a new one using TCP, or keep using the old one if the interfa= ce remains available.=C2=A0 If there are multiple applications, each application makes that choice independently.

=C2=A0

And if the first interface becomes unavailable for w= hatever reason, the choice is made for it, and the application will have to= recover.

=C2=A0

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.org>
Subject: RE: connection migration

=C2=A0

So what is the connect= ion migration flow here. The quic stack in the cell network will try to mig= rate to wifi without application request and fail but will not fall back to TCP.

There may be multiple = application running over quic? HTTP and peer to peer at the same time, so w= ho will handle this case?

=C2=A0

Roni<= /u>

=C2=A0

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 05:35
To: Roni Even; QUIC WG
Subject: RE: connection migration

=C2=A0

That may well be the case, but it=E2=80=99s not the = QUIC stack=E2=80=99s choice to make.=C2=A0 The application could choose to = open a new connection, but that remains outside the scope of the transport and the mapping to it which we=E2=80=99re defining.

=C2=A0

For HTTP, this is fairly straightforward =E2=80=93 i= t could stop issuing new flow control credit, let currently-in-transit data= arrive and any losses recovered, and open a TCP connection to issue a range request starting at whatever data offset it hasn=E2=80=99= t seen.=C2=A0 But that=E2=80=99s still a property of an HTTP management abo= ve the HTTP/QUIC mapping.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <q= uic@ietf.org>
Subject: connection migration

=C2=A0

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the=C2=A0 user (client) may want to = move to wifi even if it will mean dropping to TCP.

=C2=A0

Roni

=C2=A0


--f403045f2b44d06008055e0ea49a-- From nobody Wed Nov 15 16:28: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 B6B5C120227 for ; Wed, 15 Nov 2017 16:28:49 -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 k2U1CaLjI_oA for ; Wed, 15 Nov 2017 16:28:47 -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 BC54912714F for ; Wed, 15 Nov 2017 16:28:46 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id k3so18002020ywk.8 for ; Wed, 15 Nov 2017 16:28: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=igbGUUQMjNuX2P7+IV4mIc3P2/B0tP4nuioYZwXp0P0=; b=lXVzjmsVqHplrUlqLevrUrANd6yfgPaaX41r9l8f3pEyRnZeGWsNHichdT1xMedCJu Keqfwthjv8W5vkqQ5kCpI5J2HTtwXYp+14B4a7x/dhfo9NV8N6YJnDekFo+9vwVPBgMO 04CeYDustG32srxdawLQuHUNH0JFSrw4hTpW24Z8g0/FJ65yYBjzVh66mpE7R8KWB2GH 0EHualQrjBmhvitA/VrsWZBrCPuLznY6E5kXv+ikJY5f+nr+euPvjTCbxOgkP/r4fVlo ps4O91nAg9AofArUIhznMWrs8o1w3GNfZciK7Cvt2RYZTqx5Dd9PjF78VrxhR/3WiVpI GLkQ== 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=igbGUUQMjNuX2P7+IV4mIc3P2/B0tP4nuioYZwXp0P0=; b=MeAvf+dcykb48qfIq70gq1HwWuomS/CpGcAESN2Iy//l7zHRdSQwwjtMviUEF6UYWK vg+GXba9ySzATuD88h58MkI619Cmpqmk9lpEHLx7Tbwxla/5/bQtjdUFMh7GRMNoDrq6 /W7HXtR231v2B9F8ydiDBK5G3UFKVsf9S36/lRv1VJ6eBeHGig5jmEDGI1spxfVvYOzB SA0GsjgF4rc16WAzfmAnnUpG2nz51WrTqfoiE2szursjiJBN/X2ddnTCns+j8z+iFu2d Jx/+gd7LLGy7sCzHNjhCtFSYhCYZNubh/hwVwzapmH54SkMXBcTm/id8fSq2KurnBJKg 4I1g== X-Gm-Message-State: AJaThX7oJAcqWGkDPz0r2qNIIcjZYwQSF+9VFtyudY3fsTAJOV7TZ5WL yT2G0TMX7MTipWyKfTAA0prg7mQzlsnaiLcEbO4= X-Google-Smtp-Source: AGs4zMbyNlKA1Gp6qRMvOwpsetrBklyaE+oHGd1699Wk1v0eUzb8RC6+/R5EMP4VIEefxRiBMd096nCessK1Su9lcgc= X-Received: by 10.37.252.5 with SMTP id v5mr1565265ybd.518.1510792125897; Wed, 15 Nov 2017 16:28:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.75 with HTTP; Wed, 15 Nov 2017 16:28:45 -0800 (PST) In-Reply-To: References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> <5A0BD528.3040106@erg.abdn.ac.uk> <2C515BE8694C6F4B9B6A578BCAC32E2F83AC9673@MBX021-W3-CA-2.exch021.domain.local> From: Spencer Dawkins at IETF Date: Thu, 16 Nov 2017 08:28:45 +0800 Message-ID: Subject: Re: spin bit in QUIC: troubleshooting To: Martin Duke Cc: Piotr Galecki , "gorry@erg.abdn.ac.uk" , Ian Swett , QUIC WG , "MORTON, ALFRED C (AL)" , "emile.stephan@orange.com" Content-Type: multipart/alternative; boundary="f403045db63efe6367055e0eb3da" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 00:28:50 -0000 --f403045db63efe6367055e0eb3da Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Speaking as a curious individual, On Thu, Nov 16, 2017 at 6:54 AM, Martin Duke wrote: > Packet numbers are unencrypted and monotonically increasing. It is > therefore relatively straightforward to measure reordering between any tw= o > points in the network if you have instruments there. > And that's certainly the way carriers were monitoring large networks when I was working in that space in the mid-2000s. It's also the direction I see in recent IPPM docs I've shepherded, IIUC. Monitoring at one point in the network would be awesome, but it would be a pleasant surprise if operators are doing it now. Spencer > > On Tue, Nov 14, 2017 at 9:59 PM, Piotr Galecki affirmednetworks.com> wrote: > >> How would a network probe be able to measure the level of packet >> reordering in QUIC stream with only a spin bit? >> >> I'm asking because one of the common techniques to diagnose network issu= es >> is to insert a probe in different points in the network and measure: >> * RTT >> * TCP segment loss >> * TCP segment retransmissions >> * TCP segment out-of-order >> as a few basic data points. >> With measurements in point A and point B one can determine for example i= f >> a network device is misordering packets. >> >> -Piotr >> >> -----Original Message----- >> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Gorry Fairhurst >> Sent: Wednesday, November 15, 2017 12:48 AM >> To: MORTON, ALFRED C (AL) >> Cc: Ian Swett ; QUIC WG ; >> emile.stephan@orange.com >> Subject: Re: spin bit in QUIC: troubleshooting >> >> As I said at the mic: I think the spin-bit analysis was helpful, thanks. >> >> I can see how spin-bit is really useful to get basic diagnostics of RTT >> if it can be relied to be present in every packet. (It is important to >> measure latency within the network). >> >> There are places where 1-bit gives restricted value, and using more woul= d >> help: My additional comment at the Mic related to how much extra would b= e >> the gain from an additional one or two bits? >> >> In particular, I'd like to see a method that can let me detect some loss >> patterns and measure reordering, at least I think it is important to kno= w >> and measure when there is small-scale reordering <3. >> >> A suggestion:is to use a 2-bit counter for the spin ( >> 00->01->10->11->00), that would help detect these path anomlies. >> >> Gorry >> >> On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote: >> > >> > I=E2=80=99d like to offer support for Spin Bit (and one or two >> > >> > bits for management if they can be justified quickly) in v1. >> > >> > On this topic of more bits, >> > >> > asking further clarification from Emile, below [ACM]. >> > >> > Al >> > >> > *From:*QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett >> > *Sent:* Tuesday, November 14, 2017 4:21 PM >> > *To:* emile.stephan@orange.com >> > *Cc:* QUIC WG >> > *Subject:* Re: spin bit in QUIC: troubleshooting >> > >> > Thanks for clarifying Emile. >> > >> > On Tue, Nov 14, 2017 at 1:06 PM, > > > wrote: >> > >> > Hi Ian, >> > >> > It was suggested in the latest discussion on the RTT design team >> > mailing list to have one bit for packet lost, one for latency (spin >> > bit or eq.) and one for congestion. >> > >> > */[ACM] /* There may be some overlap with ECN and =C2=AB one bit for >> > congestion =C2=BB. >> > >> > Did you also consider this dependency, Emile ? (I=E2=80=99m echoing a = hallway >> > discussion) >> > >> > It seems a simplistic approach on one hand but an invariant on the >> > long term. >> > >> > Regards >> > >> > Emile >> > >> > *De :*Ian Swett [mailto:ianswett@google.com >> > ] *Envoy=C3=A9 :* mardi 14 novembre 2017 2= 2:51 >> > *=C3=80 :* STEPHAN Emile IMT/OLN *Cc :* QUIC WG *Objet :* Re: spin bit= in >> > QUIC: troubleshooting >> > >> > What would the other bit or two be used for? If there is no >> > standardized use of those bits in v1, then I believe we should wait to >> > reserve them when their usage is defined, given we'd need a version >> > bump to specify how they were being used. At the moment, the >> > management use case is not competing with anyone else for bits in the >> > short header. >> > >> > On Tue, Nov 14, 2017 at 5:14 AM, > > > wrote: >> > >> > Hi >> > >> > Last week Orange experienced a fallback of QUIC to TCP on one of its >> > networks. The issues were not visible in QUIC traffic. The >> > troubleshooting was made using TCP packets information. This is not >> > sustainable on the long term when numerous applications using >> > different versions of QUIC will stop to fallback to TCP. >> > >> > Based on the exchange we had in the RTT design team and in today >> > meeting , it sounds reasonable to reserve at least 2 bits (ideally 3 >> > bits as discussed in the design team) for manageability in the QUIC >> > invariants and to start experimenting the spin bit in QUIC V1. >> > >> > Regards >> > >> > Emile >> > >> > ______________________________________________________________________ >> > ___________________________________________________ >> > >> > Ce message et ses pieces jointes peuvent contenir des informations >> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> > exploites ou copies sans autorisation. Si vous avez recu ce message >> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> > >> > This message and its attachments may contain confidential or >> > privileged information that may be protected by law; they should not b= e >> distributed, used or copied without authorisation. >> > If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> > As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> > Thank you. >> > >> > ______________________________________________________________________ >> > ___________________________________________________ >> > >> > Ce message et ses pieces jointes peuvent contenir des informations >> > confidentielles ou privilegiees et ne doivent donc pas etre diffuses, >> > exploites ou copies sans autorisation. Si vous avez recu ce message >> > par erreur, veuillez le signaler a l'expediteur et le detruire ainsi >> que les pieces jointes. Les messages electroniques etant susceptibles >> d'alteration, Orange decline toute responsabilite si ce message a ete >> altere, deforme ou falsifie. Merci. >> > >> > This message and its attachments may contain confidential or >> > privileged information that may be protected by law; they should not b= e >> distributed, used or copied without authorisation. >> > If you have received this email in error, please notify the sender and >> delete this message and its attachments. >> > As emails may be altered, Orange is not liable for messages that have >> been modified, changed or falsified. >> > Thank you. >> > >> > > --f403045db63efe6367055e0eb3da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Speaking as a curious individual,

On Thu, Nov 16, 2017 at 6:54 AM, Martin Du= ke <martin.h.duke@gmail.com> wrote:
Packet numbers are unencrypted and monoto= nically increasing. It is therefore relatively straightforward to measure r= eordering between any two points in the network if you have instruments the= re.

And that's certainly the way = carriers were monitoring large networks when I was working in that space in= the mid-2000s. It's also the direction I see in recent IPPM docs I'= ;ve shepherded, IIUC.=C2=A0

Monitoring at one poin= t in the network would be awesome, but it would be a pleasant surprise if o= perators are doing it now.

Spencer
=C2= =A0

On Tue, Nov = 14, 2017 at 9:59 PM, Piotr Galecki <piotr_galecki@af= firmednetworks.com> wrote:
= How would a network probe be able to measure the level of packet reordering= in QUIC stream with only a spin bit?

I'm asking because one of the common techniques to diagnose network iss= ues
is to insert a probe in different points in the network and measure:
* RTT
* TCP segment loss
* TCP segment retransmissions
* TCP segment out-of-order
as a few basic data points.
With measurements in point A and point B one can determine for example if a= network device is misordering packets.

-Piotr

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Gorry Fairhurst
Sent: Wednesday, November 15, 2017 12:48 AM
To: MORTON, ALFRED C (AL) <acmorton@att.com>
Cc: Ian Swett <= ianswett@google.com>; QUIC WG <quic@ietf.org>; emile.stephan@orange.com
Subject: Re: spin bit in QUIC: troubleshooting

As I said at the mic: I think the spin-bit analysis was helpful, thanks.
I can see how spin-bit is really useful to get basic diagnostics of RTT if = it can be relied to be present in every packet. (It is important to measure= latency within the network).

There are places where 1-bit gives restricted value, and using more would h= elp: My additional comment at the Mic related to how much extra would be th= e gain from an additional one or two bits?

In particular, I'd like to see a method that can let me detect some los= s patterns and measure reordering, at least I think it is important to know= and measure when there is small-scale reordering <3.

A suggestion:is to use a 2-bit counter for the spin (
00->01->10->11->00), that would help detect these path anomlies= .

Gorry

On 15/11/2017, 09:51, MORTON, ALFRED C (AL) wrote:
>
> I=E2=80=99d like to offer support for Spin Bit (and one or two
>
> bits for management if they can be justified quickly) in v1.
>
> On this topic of more bits,
>
> asking further clarification from Emile, below [ACM].
>
> Al
>
> *From:*QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett
> *Sent:* Tuesday, November 14, 2017 4:21 PM
> *To:* em= ile.stephan@orange.com
> *Cc:* QUIC WG
> *Subject:* Re: spin bit in QUIC: troubleshooting
>
> Thanks for clarifying Emile.
>
> On Tue, Nov 14, 2017 at 1:06 PM, <emile.stephan@orange.com
> <mailto:emile.stephan@orange.com>> wrote:
>
> Hi Ian,
>
> It was suggested in the latest discussion on the RTT design team
> mailing list to have one bit for packet lost, one for latency (spin > bit or eq.) and one for congestion.
>
> */[ACM] /* There may be some overlap with ECN and =C2=AB one bit for > congestion =C2=BB.
>
> Did you also consider this dependency, Emile ? (I=E2=80=99m echoing a = hallway
> discussion)
>
> It seems a simplistic approach on one hand but an invariant on the
> long term.
>
> Regards
>
> Emile
>
> *De :*Ian Swett [mailto:ianswett@google.com
> <mailto:ia= nswett@google.com>] *Envoy=C3=A9 :* mardi 14 novembre 2017 22:51
> *=C3=80 :* STEPHAN Emile IMT/OLN *Cc :* QUIC WG *Objet :* Re: spin bit= in
> QUIC: troubleshooting
>
> What would the other bit or two be used for?=C2=A0 If there is no
> standardized use of those bits in v1, then I believe we should wait to=
> reserve them when their usage is defined, given we'd need a versio= n
> bump to specify how they were being used.=C2=A0 At the moment, the
> management use case is not competing with anyone else for bits in the<= br> > short header.
>
> On Tue, Nov 14, 2017 at 5:14 AM, <emile.stephan@orange.com
> <mailto:emile.stephan@orange.com>> wrote:
>
> Hi
>
> Last week Orange experienced a fallback of QUIC to TCP on one of its > networks. The issues were not visible in QUIC traffic. The
> troubleshooting was made using TCP packets information. This is not > sustainable on the long term when numerous applications using
> different versions of QUIC will stop to fallback to TCP.
>
> Based on the exchange we had in the RTT design team and in today
> meeting , it sounds reasonable to reserve at least 2 bits (ideally 3 > bits as discussed in the design team) for manageability in the QUIC > invariants and to start experimenting the spin bit in QUIC V1.
>
> Regards
>
> Emile
>
> ____________________________________________________________= __________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,<= br> > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ain= si que les pieces jointes. Les messages electroniques etant susceptibles d&= #39;alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
> Thank you.
>
> ____________________________________________________________= __________
> ___________________________________________________
>
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses,<= br> > exploites ou copies sans autorisation. Si vous avez recu ce message > par erreur, veuillez le signaler a l'expediteur et le detruire ain= si que les pieces jointes. Les messages electroniques etant susceptibles d&= #39;alteration, Orange decline toute responsabilite si ce message a ete alt= ere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or
> privileged information that may be protected by law; they should not b= e distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and= delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified.
> Thank you.
>


--f403045db63efe6367055e0eb3da-- From nobody Wed Nov 15 17:30: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 38F491293E1 for ; Wed, 15 Nov 2017 17:30:00 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0j5yHFk4y3YI for ; Wed, 15 Nov 2017 17:29:57 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6B7B8124319 for ; Wed, 15 Nov 2017 17:29:57 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4A1EFCE39CBE2 for ; Thu, 16 Nov 2017 01:29:54 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 16 Nov 2017 01:29:55 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.14]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 09:29:51 +0800 From: Roni Even To: Spencer Dawkins at IETF , "Lubashev, Igor" CC: Jana Iyengar , Mike Bishop , QUIC WG Subject: RE: connection migration Thread-Topic: connection migration Thread-Index: AdNdwNP0qRkaQfNYSy6X5QYPoBCVZQAAXPzQAAPS1iAAAgH6gAAC4MDgAAExe/AABPYHoAAA0SZA//+FloD//1OtwIAA75cAgACRkQD//2ksQA== Date: Thu, 16 Nov 2017 01:29:49 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8373C9@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837234@DGGEMM506-MBX.china.huawei.com> <55a2d469c30d4ba58c55c328defd2872@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-originating-ip: [10.52.45.35] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8373C9DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 01:30:00 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8373C9DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpKdXN0IGZvciBjbGFyaWZpY2F0aW9uLCAgSSB3YXMgd29uZGVyaW5nIGFib3V0IG1pZ3Jh dGlvbiBmcm9tIHRoZSBjZWxsdWxhciBuZXR3b3JrIHRvIHdpZmksIGZvciBleGFtcGxlIHdoZW4g d2Fsa2luZyBmcm9tIHRoZSBzdHJlZXQgdG8gbXkgd29yayBvZmZpY2UgaWYgbXkgb2ZmaWNlIEZX IHdpbGwgYmxvY2sgUVVJQyBob3cgd2lsbCBpdCBoYXBwZW4gdGhhdCBtdWx0aXBsZSBhcHBsaWNh dGlvbiBydW5uaW5nIG92ZXIgUVVJQyBvbiBDZWxsdWxhciB3aWxsIGFsbCBzd2l0Y2ggdG8gVENQ IG92ZXIgV0lGSSBhbmQgSSB3aWxsIG5vdCBzZWUgc29tZSBvZiB0aGUgYXBwbGljYXRpb25zICB0 aGF0IHdpbGwgY29udGludWUgIHJ1bm5pbmcgUVVJQyBvdmVyIENlbGx1bGFyIHdoaWxlIHRoZSBy ZXN0IHdpbGwgc3dpdGNoIHRvIFRDUCBvdmVyIFdJRkkuDQpSb25pDQoNCkZyb206IFNwZW5jZXIg RGF3a2lucyBhdCBJRVRGIFttYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBnbWFpbC5jb21dDQpT ZW50OiDXmdeV150g15QgMTYg16DXldeR157XkdeoIDIwMTcgMDI6MjUNClRvOiBMdWJhc2hldiwg SWdvcg0KQ2M6IFJvbmkgRXZlbjsgSmFuYSBJeWVuZ2FyOyBNaWtlIEJpc2hvcDsgUVVJQyBXRw0K U3ViamVjdDogUmU6IGNvbm5lY3Rpb24gbWlncmF0aW9uDQoNClNwZWFraW5nIGFzIGEgY3VyaW91 cyBpbmRpdmlkdWFsLCBidXQgbm90IG1vcmUuDQoNCk9uIFdlZCwgTm92IDE1LCAyMDE3IGF0IDEx OjQzIFBNLCBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbTxtYWlsdG86aWx1YmFz aGVAYWthbWFpLmNvbT4+IHdyb3RlOg0KUm9uaSwgaWYgYW4gYXBwbGljYXRpb24gZGVjaWRlcyB0 byBzd2l0Y2ggZnJvbSBRVUlDIHRvIFRDUCwgdGhlcmUgd2lsbCBiZSBubyBjb25uZWN0aW9uIG1p Z3JhdGlvbi4gIFRoZSBhcHBsaWNhdGlvbiB3aWxsIGhhdmUgdG8gZXN0YWJsaXNoIGEgbmV3IGNv bm5lY3Rpb24gb3ZlciBUQ1AsIGxpa2VseSwgcmVuZWdvdGlhdGUgY3J5cHRvLCBhbmQgd2hhdGV2 ZXIgUVVJQyBzdHJlYW1zIHdlcmUgaW4gcHJvZ3Jlc3Mgd2lsbCBub3QganVzdCBtaWdyYXRlIGFu ZCBjb250aW51ZSBvdmVyIFRDUCBzb21laG93LiAgU2VhbWxlc3MgY29ubmVjdGlvbiBtaWdyYXRp b24gYmV0d2VlbiBRVUlDIGFuZCBUQ1AgaXMgY2VydGFpbmx5IG91dHNpZGUgb2YgdGhlIGNoYXJ0 ZXIuDQoNCkl0J3MgcHJvYmFibHkgZ29vZCBmb3IgbWUgdG8gc2F5IHRoYXQgYXMgSSB1bmRlcnN0 YW5kIGl0LCBtaWdyYXRpb24sIGFuZCBlc3BlY2lhbGx5IG1pZ3JhdGlvbiBiZXR3ZWVuIHRyYW5z cG9ydCBwcm90b2NvbHMsIGlzIGEgc2Vzc2lvbiBwcm90b2NvbCB0aGluZywgYW5kIHdlIHJlYWxs eSBkb24ndCBoYXZlIGEgc2Vzc2lvbiBwcm90b2NvbCBsZXZlbCBpbiB0aGUgSW50ZXJuZXQuIFdl IHJlbHkgb24gYXBwbGljYXRpb25zIG1ha2luZyBkZWNpc2lvbnMgbGlrZSB0aGlzLCByYXRoZXIg dGhhbiB0cnlpbmcgdG8gbWFrZSBkZWNpc2lvbnMgbG93ZXIgaW4gdGhlIHN0YWNrIGZvciB0aGUg YXBwbGljYXRpb24uDQoNCldoZW4gd2UgaGF2ZSBNUC1UQ1AsIGFzIEkgdW5kZXJzdGFuZCBpdCwg VENQIGl0c2VsZiBiYXJlbHkgY2hhbmdlcywgc28gdGhhdCdzIGxlc3MgdHJ1ZSwgYnV0IGl0J3Mg c3RpbGwgY2xvc2UuDQoNCkkgcmVseSBvbiB3b3JraW5nIGdyb3VwcyB0byBtYWtlIGluZm9ybWVk IGRlY2lzaW9ucyBhYm91dCBzdHVmZiBsaWtlIHRoaXMsIGJ1dCBJIHdvdWxkbid0IGJlIHN1cnBy aXNlZCB0byBzZWUgYW4gTVAtUVVJQyB0byBiZSBsb29rIHNvcnQgb2YgbGlrZSBNUC1UQ1AsIHdo ZW4gdGhlIHdvcmtpbmcgZ3JvdXAgc3RhcnRzIG1ha2luZyBkZWNpc2lvbnMgYWJvdXQgbXVsdGkt cGF0aC4NCg0KQW5kIEkgc2VlIG1pZ3JhdGlvbiBhcyByb3VnaGx5IG11bHRpcGF0aCB3aGVuIGFu IGFwcGxpY2F0aW9uIHVzZXMgb25lIHBhdGggYXQgYSB0aW1lLCBhdCB0aGUgMTAsMDAwLW1ldGVy IGxldmVsLg0KDQpJIGNvdWxkIGJlIHdyb25nLCBidXQgdGhhdCdzIG15IGd1ZXNzLg0KDQpJTU8u DQoNClNwZW5jZXINCg0KQXBvbG9naWVzLCBpZiBJIG1pc3VuZGVyc3Rvb2QgeW91ciBpbnRlbnQs IGFuZCB5b3Ugd2VyZSB0YWxraW5nIGFib3V0IHNvbWV0aGluZyBvdGhlciB0aGFuIGhvdyB0byBt aWdyYXRlIGNvbm5lY3Rpb25zIGZyb20gUVVJQyB0byBUQ1AuDQoNCg0KICAqICAgSWdvcg0KDQoN CkZyb206IFJvbmkgRXZlbiBbbWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tPG1haWx0bzpyb25p LmV2ZW5AaHVhd2VpLmNvbT5dDQpTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDE1LCAyMDE3IDEw OjIxIFBNDQpUbzogSmFuYSBJeWVuZ2FyIDxqcmlAZ29vZ2xlLmNvbTxtYWlsdG86anJpQGdvb2ds ZS5jb20+PjsgTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJlPG1haWx0bzptYmlzaG9w QGV2ZXF1ZWZvdS5iZT4+DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0Bp ZXRmLm9yZz4+DQpTdWJqZWN0OiBSRTogY29ubmVjdGlvbiBtaWdyYXRpb24NCg0KSGksDQpJIGFw b2xvZ2l6ZSBpZiBhbnlvbmUgZmVsdCB0aGF0IEkgd2FzIGJlaW5nIHNhcmNhc3RpYy4gVG8gbWUg aXQgbG9va3MgdGhhdCB0aGVyZSBpcyBzb21lIGRpZmZlcmVuY2UuIE15IHVuZGVyc3RhbmRpbmcg dGhhdCB0aGVyZSBpcyBzZXBhcmF0aW9uIGJldHdlZW4gdGhlIHRyYW5zcG9ydCAoUVVJQykgYW5k IHRoZSBhcHBsaWNhdGlvbiAoSFRUUCBmaXJzdCBhbmQgb3RoZXIgbGF0ZXIpLg0KQW4gYXBwbGlj YXRpb24gY2FuIHNlZSBpbiB0aGUgVENQIGNhc2UgdHdvIG9wdGlvbnMgVENQIG9uIG9yIFRDUCBv ZmYuIEluIFFVSUMgaXQgc2VlcyB0aHJlZSBvcHRpb25zIFFVSUMgb24sIFFVSUMgb2ZmIChubyBj b25uZWN0aW9uKSwgVENQLiBJZiBvbmUgb2YgdGhlIHBoeXNpY2FsIGNvbm5lY3Rpb24gaXMgY2xv c2VkIHRoZXJlIGlzIG5vIHByb2JsZW0uIEkgYXNzdW1lZCB0aGF0IGJvdGggcGh5c2ljYWwgY29u bmVjdGlvbiBhcmUga2VwdCBvcGVuICh3aGVuIEkgZW50ZXIgdGhlIGhvdXNlIEkgY29ubmVjdCB0 byB0aGUgQVAgYnV0IHRoZSAzRyBkYXRhIGNoYW5uZWwgaXMgc3RpbGwgb3BlbikgYnV0IHRoZSBh cHBsaWNhdGlvbiB3aWxsIHRyeSB0byBzZW5kIGRhdGEgb24gdGhlIHdpZmkgbmV0d29yayBhbmQg bm90IG9uIHRoZSBjZWxsdWxhciBuZXR3b3JrIHNpbmNlIHRoaXMgaXMgdGhlIHBvbGljeSwgYW0g SSB3cm9uZz8NClJvbmkNCg0KRnJvbTogSmFuYSBJeWVuZ2FyIFttYWlsdG86anJpQGdvb2dsZS5j b21dDQpTZW50OiDXmdeV150g15MgMTUg16DXldeR157XkdeoIDIwMTcgMTM6NDMNClRvOiBNaWtl IEJpc2hvcA0KQ2M6IFJvbmkgRXZlbjsgUVVJQyBXRw0KU3ViamVjdDogUmU6IGNvbm5lY3Rpb24g bWlncmF0aW9uDQoNCldoYXQgTWlrZSBzYWlkLiBUaGUgc2NvcGUgb2YgUVVJQywgYnkgZGVmaW5p dGlvbiwgaXMgbm90IGxhcmdlciB0aGFuIFFVSUMuDQoNCk9uIFdlZCwgTm92IDE1LCAyMDE3IGF0 IDc6MDIgUE0sIE1pa2UgQmlzaG9wIDxtYmlzaG9wQGV2ZXF1ZWZvdS5iZTxtYWlsdG86bWJpc2hv cEBldmVxdWVmb3UuYmU+PiB3cm90ZToNCllvdXIgc2FyY2FzbSBub3R3aXRoc3RhbmRpbmcsIEni gJlsbCBlbXBoYXNpemUgdGhhdCB0aGlzIGlzIGlkZW50aWNhbCB0byBUQ1AgdG9kYXkuICBFaXRo ZXIgdGhlIGFwcGxpY2F0aW9ucyBtb3ZlLCBvciB0aGV5IGRvbuKAmXQuICBJZiB0aGUgZGV2aWNl IGZvcmNpYmx5IGJyaW5ncyBkb3duIHRoZSBjZWxsdWxhciBpbnRlcmZhY2XigJlzIGRhdGEgY29u bmVjdGlvbiwgdGhlIGFwcGxpY2F0aW9ucyB3aWxsIGhhdmUgdG8gbW92ZSBpZiB0aGV5IGRpZG7i gJl0IGFscmVhZHkgbW92ZSBncmFjZWZ1bGx5LCB3aGljaCBpcyBpbmRlcGVuZGVudCBvZiB0aGUg dHJhbnNwb3J04oCZcyBwcm9wZXJ0aWVzLg0KDQpGcm9tOiBSb25pIEV2ZW4gW21haWx0bzpyb25p LmV2ZW5AaHVhd2VpLmNvbTxtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20+XQ0KU2VudDogV2Vk bmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyA2OjM4IFBNDQoNClRvOiBNaWtlIEJpc2hvcCA8bWJp c2hvcEBldmVxdWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj47IFFVSUMgV0cg PHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IGNvbm5l Y3Rpb24gbWlncmF0aW9uDQoNCg0KDQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOm1iaXNob3BA ZXZlcXVlZm91LmJlXQ0KU2VudDog15nXldedINeTIDE1INeg15XXkdee15HXqCAyMDE3IDEwOjE4 DQpUbzogUm9uaSBFdmVuOyBRVUlDIFdHDQpTdWJqZWN0OiBSRTogY29ubmVjdGlvbiBtaWdyYXRp b24NCg0KTm87IGluIHRoZSBUQ1AgY2FzZSB5b3VyIHRyYW5zcG9ydCBkb2VzbuKAmXQgaGF2ZSBh bnkgbWlncmF0aW9uIHByb3Zpc2lvbiwgc28gaXTigJlzIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiB3 aGV0aGVyIGl0IHdhbnRzIHRvIHdpbmQgZG93biB0aGUgZXhpc3RpbmcgY29ubmVjdGlvbiBhbmQg c3RhcnQgYSBuZXcgb25lLiAgSWYgbWlncmF0aW9uIGZhaWxzIHdpdGggUVVJQywgdGhlIHNpdHVh dGlvbiBpcyBleGFjdGx5IHRoZSBzYW1lLCBhbmQgdGhlIGFwcGxpY2F0aW9uIGRlY2lkZXMgd2hl dGhlciBpdCB3YW50cyB0byB3aW5kIGRvd24gdGhlIGV4aXN0aW5nIGNvbm5lY3Rpb24gYW5kIHN0 YXJ0IGEgbmV3IG9uZS4NCg0KSWYgdGhlcmXigJlzIG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24s IHRoZW4gdGhlIGFuc3dlciB0byDigJx3aGljaCBhcHBsaWNhdGlvbuKAnSBpcyDigJxlYWNoIGFw cGxpY2F0aW9u4oCdIGJlY2F1c2UgZWFjaCBhcHBsaWNhdGlvbiBvd25zIGl0cyBvd24gY29ubmVj dGlvbnMuDQpbUm9uaSBFdmVuXSBTbyB3ZSBjYW4gZW5kIHVwIHdpdGggb25lIGFwcGxpY2F0aW9u IG9uIHRoZSBjZWxsIGFuZCB0aGUgb3RoZXIgb24gdGhlIHdpZmkuIE5pY2UhISENCg0KRnJvbTog Um9uaSBFdmVuIFttYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb21dDQpTZW50OiBXZWRuZXNkYXks IE5vdmVtYmVyIDE1LCAyMDE3IDM6NDQgUE0NClRvOiBNaWtlIEJpc2hvcCA8bWJpc2hvcEBldmVx dWVmb3UuYmU8bWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlPj47IFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUkU6IGNvbm5lY3Rpb24gbWln cmF0aW9uDQoNCmlubGluZQ0KDQpGcm9tOiBNaWtlIEJpc2hvcCBbbWFpbHRvOm1iaXNob3BAZXZl cXVlZm91LmJlXQ0KU2VudDog15nXldedINeTIDE1INeg15XXkdee15HXqCAyMDE3IDA4OjIzDQpU bzogUm9uaSBFdmVuOyBRVUlDIFdHDQpTdWJqZWN0OiBSRTogY29ubmVjdGlvbiBtaWdyYXRpb24N Cg0KRXhhY3RseSB0aGUgc2FtZSB3YXkgdGhhdCBUQ1AtdG8tVENQIGhhbmRvZmYgYmV0d2VlbiB0 aGVzZSBpbnRlcmZhY2VzIHdvcmtzIHRvZGF5LCBiZWNhdXNlIChub24tTVApIFRDUCBpc27igJl0 IGNhcGFibGUgb2YgY2hhbmdpbmcgdG8gYSBkaWZmZXJlbnQgaW50ZXJmYWNlLiAgV2XigJlyZSB0 cnlpbmcgdG8gYnVpbGQgYSBiZXR0ZXIgYW5zd2VyLCBidXQgeW914oCZcmUgcG9zaXRpbmcgZnJv bSB0aGUgc3RhcnQgdGhhdCBjb25uZWN0aW9uIG1pZ3JhdGlvbiBmYWlscywgc28gd2XigJlyZSBu b3cgaW4g4oCcbm8gd29yc2XigJ0gbGFuZC4NCg0KVGhlIFFVSUMgc3RhY2sgaW4gdGhlIGNsaWVu dCBkZXZpY2Ugd2lsbCBzZWUgYSBuZXcgaW50ZXJmYWNlIGlzIGF2YWlsYWJsZS4gIEl0IGF0dGVt cHRzIHRvIHN3aXRjaCB0byBpdCwgYmVjYXVzZSBvZiBzb21lIGxvY2FsIHBvbGljeS4gIFRoZSB0 cmFuc2l0aW9uIGZhaWxzIGZvciB3aGF0ZXZlciByZWFzb24sIGJ1dCB0aGUgY2VsbHVsYXIgY29u bmVjdGlvbiBpcyBzdGlsbCBhY3RpdmUuICBJdCBpcyB0aGUgYXBwbGljYXRpb27igJlzIGNob2lj ZQ0KW1JvbmkgRXZlbl0gd2hpY2ggYXBwbGljYXRpb24gaWYgdGhlcmUgaXMgbW9yZSB0aGFuIG9u ZT8gSW4gdGhlIFRDUCBjYXNlIHlvdSBzdGF5IGluIHRoZSBjZWxsLiBIZXJlIHRoZXJlIGFyZSB0 d28gb3B0aW9ucywgc3RheSBvbiB0aGUgY2VsbCB3aXRoIFFVSUMgb3IgbW92ZSB0byB3aWZpIG9u IFRDUA0Kd2hldGhlciBpdCB3YW50cyB0byB3aW5kIGRvd24gYW5kIGNsb3NlIHRoYXQgY29ubmVj dGlvbiBhbmQgc3RhcnQgYSBuZXcgb25lIHVzaW5nIFRDUCwgb3Iga2VlcCB1c2luZyB0aGUgb2xk IG9uZSBpZiB0aGUgaW50ZXJmYWNlIHJlbWFpbnMgYXZhaWxhYmxlLiAgSWYgdGhlcmUgYXJlIG11 bHRpcGxlIGFwcGxpY2F0aW9ucywgZWFjaCBhcHBsaWNhdGlvbiBtYWtlcyB0aGF0IGNob2ljZSBp bmRlcGVuZGVudGx5Lg0KDQpBbmQgaWYgdGhlIGZpcnN0IGludGVyZmFjZSBiZWNvbWVzIHVuYXZh aWxhYmxlIGZvciB3aGF0ZXZlciByZWFzb24sIHRoZSBjaG9pY2UgaXMgbWFkZSBmb3IgaXQsIGFu ZCB0aGUgYXBwbGljYXRpb24gd2lsbCBoYXZlIHRvIHJlY292ZXIuDQoNCkZyb206IFJvbmkgRXZl biBbbWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tXQ0KU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJl ciAxNSwgMjAxNyAxOjI1IFBNDQpUbzogTWlrZSBCaXNob3AgPG1iaXNob3BAZXZlcXVlZm91LmJl PG1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZT4+OyBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1h aWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJFOiBjb25uZWN0aW9uIG1pZ3JhdGlvbg0K DQpTbyB3aGF0IGlzIHRoZSBjb25uZWN0aW9uIG1pZ3JhdGlvbiBmbG93IGhlcmUuIFRoZSBxdWlj IHN0YWNrIGluIHRoZSBjZWxsIG5ldHdvcmsgd2lsbCB0cnkgdG8gbWlncmF0ZSB0byB3aWZpIHdp dGhvdXQgYXBwbGljYXRpb24gcmVxdWVzdCBhbmQgZmFpbCBidXQgd2lsbCBub3QgZmFsbCBiYWNr IHRvIFRDUC4NClRoZXJlIG1heSBiZSBtdWx0aXBsZSBhcHBsaWNhdGlvbiBydW5uaW5nIG92ZXIg cXVpYz8gSFRUUCBhbmQgcGVlciB0byBwZWVyIGF0IHRoZSBzYW1lIHRpbWUsIHNvIHdobyB3aWxs IGhhbmRsZSB0aGlzIGNhc2U/DQoNClJvbmkNCg0KRnJvbTogTWlrZSBCaXNob3AgW21haWx0bzpt YmlzaG9wQGV2ZXF1ZWZvdS5iZV0NClNlbnQ6INeZ15XXnSDXkyAxNSDXoNeV15HXnteR16ggMjAx NyAwNTozNQ0KVG86IFJvbmkgRXZlbjsgUVVJQyBXRw0KU3ViamVjdDogUkU6IGNvbm5lY3Rpb24g bWlncmF0aW9uDQoNClRoYXQgbWF5IHdlbGwgYmUgdGhlIGNhc2UsIGJ1dCBpdOKAmXMgbm90IHRo ZSBRVUlDIHN0YWNr4oCZcyBjaG9pY2UgdG8gbWFrZS4gIFRoZSBhcHBsaWNhdGlvbiBjb3VsZCBj aG9vc2UgdG8gb3BlbiBhIG5ldyBjb25uZWN0aW9uLCBidXQgdGhhdCByZW1haW5zIG91dHNpZGUg dGhlIHNjb3BlIG9mIHRoZSB0cmFuc3BvcnQgYW5kIHRoZSBtYXBwaW5nIHRvIGl0IHdoaWNoIHdl 4oCZcmUgZGVmaW5pbmcuDQoNCkZvciBIVFRQLCB0aGlzIGlzIGZhaXJseSBzdHJhaWdodGZvcndh cmQg4oCTIGl0IGNvdWxkIHN0b3AgaXNzdWluZyBuZXcgZmxvdyBjb250cm9sIGNyZWRpdCwgbGV0 IGN1cnJlbnRseS1pbi10cmFuc2l0IGRhdGEgYXJyaXZlIGFuZCBhbnkgbG9zc2VzIHJlY292ZXJl ZCwgYW5kIG9wZW4gYSBUQ1AgY29ubmVjdGlvbiB0byBpc3N1ZSBhIHJhbmdlIHJlcXVlc3Qgc3Rh cnRpbmcgYXQgd2hhdGV2ZXIgZGF0YSBvZmZzZXQgaXQgaGFzbuKAmXQgc2Vlbi4gIEJ1dCB0aGF0 4oCZcyBzdGlsbCBhIHByb3BlcnR5IG9mIGFuIEhUVFAgbWFuYWdlbWVudCBhYm92ZSB0aGUgSFRU UC9RVUlDIG1hcHBpbmcuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBSb25pIEV2ZW4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUs IDIwMTcgMTE6MjUgQU0NClRvOiBRVUlDIFdHIDxxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGll dGYub3JnPj4NClN1YmplY3Q6IGNvbm5lY3Rpb24gbWlncmF0aW9uDQoNCkhpLA0KV2hlbiBtb3Zp bmcgZnJvbSBjZWxsIHRvIHdpZmkgdGhlIHJlYXNvbiBtYXkgYmUgZHVlIHRvIGNvc3QgKG1vbmV5 IG9yIHF1b3RhKS4gSW4gdGhpcyBjYXNlIHRoZSAgdXNlciAoY2xpZW50KSBtYXkgd2FudCB0byBt b3ZlIHRvIHdpZmkgZXZlbiBpZiBpdCB3aWxsIG1lYW4gZHJvcHBpbmcgdG8gVENQLg0KDQpSb25p DQoNCg0K --_000_6E58094ECC8D8344914996DAD28F1CCD8373C9DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6 Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29I eXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0 YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMt c2VyaWYiO30NCnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29u IFRleHQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJC YWxsb29uIFRleHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5 Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNl Y3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBs aXN0IGwwDQoJe21zby1saXN0LWlkOjE5ODgyNDA0MDU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0zNzI5ODA0NzQ7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjM2LjBw dDsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NzIuMHB0Ow0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDoxMDguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWIt c3RvcDoxNDQuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxODAuMHB0Ow0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyMTYuMHB0Ow0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDoyNTIuMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDoyODguMHB0Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotMTguMHB0Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3lt Ym9sO30NCkBsaXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozMjQuMHB0Ow0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCm9sDQoJe21h cmdpbi1ib3R0b206MGNtO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGNtO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xh c3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPkp1c3QgZm9yIGNsYXJpZmljYXRpb24sICZuYnNwO0kgd2FzIHdvbmRlcmluZyBhYm91dCBt aWdyYXRpb24gZnJvbSB0aGUgY2VsbHVsYXIgbmV0d29yayB0byB3aWZpLCBmb3IgZXhhbXBsZSB3 aGVuIHdhbGtpbmcgZnJvbSB0aGUgc3RyZWV0IHRvIG15IHdvcmsgb2ZmaWNlIGlmIG15DQogb2Zm aWNlIEZXIHdpbGwgYmxvY2sgUVVJQyBob3cgd2lsbCBpdCBoYXBwZW4gdGhhdCBtdWx0aXBsZSBh cHBsaWNhdGlvbiBydW5uaW5nIG92ZXIgUVVJQyBvbiBDZWxsdWxhciB3aWxsIGFsbCBzd2l0Y2gg dG8gVENQIG92ZXIgV0lGSSBhbmQgSSB3aWxsIG5vdCBzZWUgc29tZSBvZiB0aGUgYXBwbGljYXRp b25zICZuYnNwO3RoYXQgd2lsbCBjb250aW51ZSZuYnNwOyBydW5uaW5nIFFVSUMgb3ZlciBDZWxs dWxhciB3aGlsZSB0aGUgcmVzdCB3aWxsIHN3aXRjaCB0bw0KIFRDUCBvdmVyIFdJRkkuPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbmk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4N CjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYg MS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gU3BlbmNlciBEYXdraW5zIGF0IElFVEYgW21haWx0bzpzcGVuY2Vy ZGF3a2lucy5pZXRmQGdtYWlsLmNvbV0NCjxicj4NCjxiPlNlbnQ6PC9iPiA8c3BhbiBsYW5nPSJI RSIgZGlyPSJSVEwiPteZ15XXnSZuYnNwO9eUIDE2INeg15XXkdee15HXqCAyMDE3IDAyOjI1PC9z cGFuPjxicj4NCjxiPlRvOjwvYj4gTHViYXNoZXYsIElnb3I8YnI+DQo8Yj5DYzo8L2I+IFJvbmkg RXZlbjsgSmFuYSBJeWVuZ2FyOyBNaWtlIEJpc2hvcDsgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6 PC9iPiBSZTogY29ubmVjdGlvbiBtaWdyYXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlYWtpbmcgYXMgYSBjdXJpb3VzIGluZGl2aWR1 YWwsIGJ1dCBub3QgbW9yZS48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBXZWQsIE5vdiAxNSwgMjAxNyBhdCAxMTo0MyBQTSwgTHViYXNoZXYsIElnb3IgJmx0OzxhIGhy ZWY9Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWx1YmFzaGVA YWthbWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Um9uaSwg aWYgYW4gYXBwbGljYXRpb24gZGVjaWRlcyB0byBzd2l0Y2ggZnJvbSBRVUlDIHRvIFRDUCwgdGhl cmUgd2lsbCBiZSBubyBjb25uZWN0aW9uIG1pZ3JhdGlvbi4mbmJzcDsgVGhlIGFwcGxpY2F0aW9u DQogd2lsbCBoYXZlIHRvIGVzdGFibGlzaCBhIG5ldyBjb25uZWN0aW9uIG92ZXIgVENQLCBsaWtl bHksIHJlbmVnb3RpYXRlIGNyeXB0bywgYW5kIHdoYXRldmVyIFFVSUMgc3RyZWFtcyB3ZXJlIGlu IHByb2dyZXNzIHdpbGwgbm90IGp1c3QgbWlncmF0ZSBhbmQgY29udGludWUgb3ZlciBUQ1Agc29t ZWhvdy4mbmJzcDsgU2VhbWxlc3MgY29ubmVjdGlvbiBtaWdyYXRpb24gYmV0d2VlbiBRVUlDIGFu ZCBUQ1AgaXMgY2VydGFpbmx5IG91dHNpZGUgb2YgdGhlIGNoYXJ0ZXIuPC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0 J3MgcHJvYmFibHkgZ29vZCBmb3IgbWUgdG8gc2F5IHRoYXQgYXMgSSB1bmRlcnN0YW5kIGl0LCBt aWdyYXRpb24sIGFuZCBlc3BlY2lhbGx5IG1pZ3JhdGlvbiBiZXR3ZWVuIHRyYW5zcG9ydCBwcm90 b2NvbHMsIGlzIGEgc2Vzc2lvbiBwcm90b2NvbCB0aGluZywgYW5kIHdlIHJlYWxseSBkb24ndCBo YXZlIGEgc2Vzc2lvbiBwcm90b2NvbCBsZXZlbCBpbiB0aGUgSW50ZXJuZXQuIFdlIHJlbHkgb24g YXBwbGljYXRpb25zDQogbWFraW5nIGRlY2lzaW9ucyBsaWtlIHRoaXMsIHJhdGhlciB0aGFuIHRy eWluZyB0byBtYWtlIGRlY2lzaW9ucyBsb3dlciBpbiB0aGUgc3RhY2sgZm9yIHRoZSBhcHBsaWNh dGlvbi4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+V2hlbiB3ZSBoYXZlIE1QLVRDUCwgYXMgSSB1bmRlcnN0YW5kIGl0LCBUQ1AgaXRz ZWxmIGJhcmVseSBjaGFuZ2VzLCBzbyB0aGF0J3MgbGVzcyB0cnVlLCBidXQgaXQncyBzdGlsbCBj bG9zZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSByZWx5IG9uIHdvcmtpbmcgZ3JvdXBzIHRvIG1ha2UgaW5mb3JtZWQgZGVjaXNp b25zIGFib3V0IHN0dWZmIGxpa2UgdGhpcywgYnV0IEkgd291bGRuJ3QgYmUgc3VycHJpc2VkIHRv IHNlZSBhbiBNUC1RVUlDIHRvIGJlIGxvb2sgc29ydCBvZiBsaWtlIE1QLVRDUCwgd2hlbiB0aGUg d29ya2luZyBncm91cCBzdGFydHMgbWFraW5nIGRlY2lzaW9ucyBhYm91dCBtdWx0aS1wYXRoLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmQg SSBzZWUgbWlncmF0aW9uIGFzIHJvdWdobHkgbXVsdGlwYXRoIHdoZW4gYW4gYXBwbGljYXRpb24g dXNlcyBvbmUgcGF0aCBhdCBhIHRpbWUsIGF0IHRoZSAxMCwwMDAtbWV0ZXIgbGV2ZWwuJm5ic3A7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkg Y291bGQgYmUgd3JvbmcsIGJ1dCB0aGF0J3MgbXkgZ3Vlc3MuJm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTy48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlbmNlcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BcG9sb2dpZXMsIGlmIEkg bWlzdW5kZXJzdG9vZCB5b3VyIGludGVudCwgYW5kIHlvdSB3ZXJlIHRhbGtpbmcgYWJvdXQgc29t ZXRoaW5nIG90aGVyIHRoYW4gaG93IHRvIG1pZ3JhdGUgY29ubmVjdGlvbnMNCiBmcm9tIFFVSUMg dG8gVENQLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8 dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+SWdvcjwvc3Bhbj48bzpwPjwv bzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQg I0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUm9uaSBFdmVuIFttYWlsdG86PGEgaHJlZj0i bWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+cm9uaS5ldmVuQGh1 YXdlaS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUs IDIwMTcgMTA6MjEgUE08YnI+DQo8Yj5Ubzo8L2I+IEphbmEgSXllbmdhciAmbHQ7PGEgaHJlZj0i bWFpbHRvOmpyaUBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+anJpQGdvb2dsZS5jb208L2E+ Jmd0OzsgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5i ZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDs8YnI+DQo8Yj5D Yzo8L2I+IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9 Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBj b25uZWN0aW9uIG1pZ3JhdGlvbjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IaSw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGFwb2xv Z2l6ZSBpZiBhbnlvbmUgZmVsdCB0aGF0IEkgd2FzIGJlaW5nIHNhcmNhc3RpYy4gVG8gbWUgaXQg bG9va3MgdGhhdCB0aGVyZSBpcyBzb21lIGRpZmZlcmVuY2UuDQogTXkgdW5kZXJzdGFuZGluZyB0 aGF0IHRoZXJlIGlzIHNlcGFyYXRpb24gYmV0d2VlbiB0aGUgdHJhbnNwb3J0IChRVUlDKSBhbmQg dGhlIGFwcGxpY2F0aW9uIChIVFRQIGZpcnN0IGFuZCBvdGhlciBsYXRlcikuDQo8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5BbiBhcHBsaWNhdGlvbiBjYW4gc2VlIGluIHRoZSBUQ1Ag Y2FzZSB0d28gb3B0aW9ucyBUQ1Agb24gb3IgVENQIG9mZi4gSW4gUVVJQyBpdCBzZWVzIHRocmVl IG9wdGlvbnMNCiBRVUlDIG9uLCBRVUlDIG9mZiAobm8gY29ubmVjdGlvbiksIFRDUC4gSWYgb25l IG9mIHRoZSBwaHlzaWNhbCBjb25uZWN0aW9uIGlzIGNsb3NlZCB0aGVyZSBpcyBubyBwcm9ibGVt LiBJIGFzc3VtZWQgdGhhdCBib3RoIHBoeXNpY2FsIGNvbm5lY3Rpb24gYXJlIGtlcHQgb3BlbiAo d2hlbiBJIGVudGVyIHRoZSBob3VzZSBJIGNvbm5lY3QgdG8gdGhlIEFQIGJ1dCB0aGUgM0cgZGF0 YSBjaGFubmVsIGlzIHN0aWxsIG9wZW4pIGJ1dCB0aGUgYXBwbGljYXRpb24NCiB3aWxsIHRyeSB0 byBzZW5kIGRhdGEgb24gdGhlIHdpZmkgbmV0d29yayBhbmQgbm90IG9uIHRoZSBjZWxsdWxhciBu ZXR3b3JrIHNpbmNlIHRoaXMgaXMgdGhlIHBvbGljeSwgYW0gSSB3cm9uZz8NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlJvbmk8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+IEphbmEgSXllbmdhciBbPGEgaHJlZj0ibWFpbHRvOmpyaUBnb29n bGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+bWFpbHRvOmpyaUBnb29nbGUuY29tPC9hPl0NCjxicj4N CjxiPlNlbnQ6PC9iPiA8c3BhbiBsYW5nPSJIRSIgZGlyPSJSVEwiPteZ15XXnSZuYnNwO9eTIDE1 INeg15XXkdee15HXqCAyMDE3IDEzOjQzPC9zcGFuPjxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNo b3A8YnI+DQo8Yj5DYzo8L2I+IFJvbmkgRXZlbjsgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogY29ubmVjdGlvbiBtaWdyYXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5XaGF0IE1pa2Ugc2FpZC4gVGhlIHNj b3BlIG9mIFFVSUMsIGJ5IGRlZmluaXRpb24sIGlzIG5vdCBsYXJnZXIgdGhhbiBRVUlDLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T24g V2VkLCBOb3YgMTUsIDIwMTcgYXQgNzowMiBQTSwgTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1h aWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVl Zm91LmJlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+WW91ciBzYXJjYXNtIG5vdHdpdGhzdGFuZGluZywgSeKAmWxsIGVt cGhhc2l6ZSB0aGF0IHRoaXMgaXMgaWRlbnRpY2FsIHRvIFRDUCB0b2RheS4mbmJzcDsgRWl0aGVy IHRoZSBhcHBsaWNhdGlvbnMgbW92ZSwgb3IgdGhleSBkb27igJl0LiZuYnNwOyBJZiB0aGUgZGV2 aWNlIGZvcmNpYmx5IGJyaW5ncyBkb3duIHRoZSBjZWxsdWxhcg0KIGludGVyZmFjZeKAmXMgZGF0 YSBjb25uZWN0aW9uLCB0aGUgYXBwbGljYXRpb25zIHdpbGwgaGF2ZSB0byBtb3ZlIGlmIHRoZXkg ZGlkbuKAmXQgYWxyZWFkeSBtb3ZlIGdyYWNlZnVsbHksIHdoaWNoIGlzIGluZGVwZW5kZW50IG9m IHRoZSB0cmFuc3BvcnTigJlzIHByb3BlcnRpZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxhIG5hbWU9Im1fMTU0ODg1NzUzNDI2NTQxNDQxMV9tXzY2Mjk0OTI2NTAx NjcwMDMiPiZuYnNwOzwvYT48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20g MGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBSb25pIEV2ZW4g W21haWx0bzo8YSBocmVmPSJtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20iIHRhcmdldD0iX2Js YW5rIj5yb25pLmV2ZW5AaHVhd2VpLmNvbTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVz ZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyA2OjM4IFBNPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGJyPg0KPGI+VG86PC9iPiBNaWtlIEJpc2hvcCAm bHQ7PGEgaHJlZj0ibWFpbHRvOm1iaXNob3BAZXZlcXVlZm91LmJlIiB0YXJnZXQ9Il9ibGFuayI+ bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRv OnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPiZndDs8YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGNvbm5lY3Rpb24gbWlncmF0aW9uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij4gTWlrZSBCaXNob3AgWzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1 ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT5d DQo8YnI+DQo8Yj5TZW50OjwvYj4gPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV150mbmJz cDvXkyAxNSDXoNeV15HXnteR16ggMjAxNyAxMDoxODwvc3Bhbj48YnI+DQo8Yj5Ubzo8L2I+IFJv bmkgRXZlbjsgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTogY29ubmVjdGlvbiBtaWdy YXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Tm87IGluIHRoZSBUQ1AgY2FzZSB5b3VyIHRyYW5zcG9ydCBkb2VzbuKAmXQgaGF2ZSBhbnkgbWln cmF0aW9uIHByb3Zpc2lvbiwgc28gaXTigJlzIHVwIHRvIHRoZSBhcHBsaWNhdGlvbiB3aGV0aGVy IGl0IHdhbnRzIHRvIHdpbmQgZG93biB0aGUgZXhpc3RpbmcgY29ubmVjdGlvbiBhbmQgc3RhcnQg YSBuZXcgb25lLiZuYnNwOw0KIElmIG1pZ3JhdGlvbiBmYWlscyB3aXRoIFFVSUMsIHRoZSBzaXR1 YXRpb24gaXMgPHU+ZXhhY3RseSB0aGUgc2FtZTwvdT4sIGFuZCB0aGUgYXBwbGljYXRpb24gZGVj aWRlcyB3aGV0aGVyIGl0IHdhbnRzIHRvIHdpbmQgZG93biB0aGUgZXhpc3RpbmcgY29ubmVjdGlv biBhbmQgc3RhcnQgYSBuZXcgb25lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SWYgdGhl cmXigJlzIG1vcmUgdGhhbiBvbmUgYXBwbGljYXRpb24sIHRoZW4gdGhlIGFuc3dlciB0byDigJx3 aGljaCBhcHBsaWNhdGlvbuKAnSBpcyDigJxlYWNoIGFwcGxpY2F0aW9u4oCdIGJlY2F1c2UgZWFj aCBhcHBsaWNhdGlvbiBvd25zIGl0cyBvd24gY29ubmVjdGlvbnMuPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5b Um9uaSBFdmVuXSBTbyB3ZSBjYW4gZW5kIHVwIHdpdGggb25lIGFwcGxpY2F0aW9uIG9uIHRoZSBj ZWxsIGFuZCB0aGUgb3RoZXIgb24gdGhlIHdpZmkuIE5pY2UhISE8L3NwYW4+PC9pPjwvYj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUx IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij48Yj5Gcm9tOjwvYj4gUm9uaSBFdmVuIFs8YSBocmVmPSJtYWlsdG86cm9uaS5ldmVuQGh1YXdl aS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb208L2E+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIwMTcgMzo0NCBQTTxi cj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2 ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BAZXZlcXVlZm91LmJlPC9hPiZndDs7 IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBjb25uZWN0 aW9uIG1pZ3JhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5pbmxpbmU8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IE1pa2UgQmlzaG9wIFs8YSBocmVmPSJtYWlsdG86bWJpc2hvcEBldmVxdWVm b3UuYmUiIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86bWJpc2hvcEBldmVxdWVmb3UuYmU8L2E+XQ0K PGJyPg0KPGI+U2VudDo8L2I+IDxzcGFuIGxhbmc9IkhFIiBkaXI9IlJUTCI+15nXldedJm5ic3A7 15MgMTUg16DXldeR157XkdeoIDIwMTcgMDg6MjM8L3NwYW4+PGJyPg0KPGI+VG86PC9iPiBSb25p IEV2ZW47IFFVSUMgV0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IGNvbm5lY3Rpb24gbWlncmF0 aW9uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkV4 YWN0bHkgdGhlIHNhbWUgd2F5IHRoYXQgVENQLXRvLVRDUCBoYW5kb2ZmIGJldHdlZW4gdGhlc2Ug aW50ZXJmYWNlcyB3b3JrcyB0b2RheSwgYmVjYXVzZSAobm9uLU1QKSBUQ1AgaXNu4oCZdCBjYXBh YmxlIG9mIGNoYW5naW5nIHRvIGEgZGlmZmVyZW50IGludGVyZmFjZS4mbmJzcDsgV2XigJlyZSB0 cnlpbmcgdG8gYnVpbGQNCiBhIGJldHRlciBhbnN3ZXIsIGJ1dCB5b3XigJlyZSBwb3NpdGluZyBm cm9tIHRoZSBzdGFydCB0aGF0IGNvbm5lY3Rpb24gbWlncmF0aW9uIGZhaWxzLCBzbyB3ZeKAmXJl IG5vdyBpbiDigJxubyB3b3JzZeKAnSBsYW5kLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ VGhlIFFVSUMgc3RhY2sgaW4gdGhlIGNsaWVudCBkZXZpY2Ugd2lsbCBzZWUgYSBuZXcgaW50ZXJm YWNlIGlzIGF2YWlsYWJsZS4mbmJzcDsgSXQgYXR0ZW1wdHMgdG8gc3dpdGNoIHRvIGl0LCBiZWNh dXNlIG9mIHNvbWUgbG9jYWwgcG9saWN5LiZuYnNwOyBUaGUgdHJhbnNpdGlvbiBmYWlscyBmb3Ig d2hhdGV2ZXIgcmVhc29uLA0KIGJ1dCB0aGUgY2VsbHVsYXIgY29ubmVjdGlvbiBpcyBzdGlsbCBh Y3RpdmUuJm5ic3A7IEl0IGlzIHRoZSBhcHBsaWNhdGlvbuKAmXMgY2hvaWNlIDxvOnA+DQo8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxiPjxpPjxzcGFuIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj5bUm9uaSBFdmVuXSB3aGljaCBhcHBsaWNhdGlvbiBpZiB0aGVyZSBpcyBtb3JlIHRo YW4gb25lPyBJbiB0aGUgVENQIGNhc2UgeW91IHN0YXkgaW4gdGhlIGNlbGwuIEhlcmUgdGhlcmUg YXJlIHR3byBvcHRpb25zLCBzdGF5IG9uIHRoZSBjZWxsIHdpdGgNCiBRVUlDIG9yIG1vdmUgdG8g d2lmaSBvbiBUQ1A8L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+d2hldGhlciBpdCB3YW50cyB0byB3aW5kIGRvd24gYW5kIGNsb3NlIHRoYXQgY29u bmVjdGlvbiBhbmQgc3RhcnQgYSBuZXcgb25lIHVzaW5nIFRDUCwgb3Iga2VlcCB1c2luZyB0aGUg b2xkIG9uZSBpZiB0aGUgaW50ZXJmYWNlIHJlbWFpbnMgYXZhaWxhYmxlLiZuYnNwOyBJZiB0aGVy ZSBhcmUgbXVsdGlwbGUgYXBwbGljYXRpb25zLA0KIGVhY2ggYXBwbGljYXRpb24gbWFrZXMgdGhh dCBjaG9pY2UgaW5kZXBlbmRlbnRseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFuZCBp ZiB0aGUgZmlyc3QgaW50ZXJmYWNlIGJlY29tZXMgdW5hdmFpbGFibGUgZm9yIHdoYXRldmVyIHJl YXNvbiwgdGhlIGNob2ljZSBpcyBtYWRlIGZvciBpdCwgYW5kIHRoZSBhcHBsaWNhdGlvbiB3aWxs IGhhdmUgdG8gcmVjb3Zlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUm9uaSBFdmVuIFs8YSBocmVmPSJt YWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20iIHRhcmdldD0iX2JsYW5rIj5tYWlsdG86cm9uaS5l dmVuQGh1YXdlaS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTm92ZW1i ZXIgMTUsIDIwMTcgMToyNSBQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgJmx0OzxhIGhy ZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxhbmsiPm1iaXNob3BA ZXZlcXVlZm91LmJlPC9hPiZndDs7IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGll dGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJFOiBjb25uZWN0aW9uIG1pZ3JhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5TbyB3aGF0 IGlzIHRoZSBjb25uZWN0aW9uIG1pZ3JhdGlvbiBmbG93IGhlcmUuIFRoZSBxdWljIHN0YWNrIGlu IHRoZSBjZWxsIG5ldHdvcmsgd2lsbCB0cnkgdG8gbWlncmF0ZSB0byB3aWZpIHdpdGhvdXQgYXBw bGljYXRpb24gcmVxdWVzdCBhbmQgZmFpbCBidXQNCiB3aWxsIG5vdCBmYWxsIGJhY2sgdG8gVENQ Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMxRjQ5N0QiPlRoZXJlIG1heSBiZSBtdWx0aXBsZSBhcHBsaWNhdGlvbiBydW5u aW5nIG92ZXIgcXVpYz8gSFRUUCBhbmQgcGVlciB0byBwZWVyIGF0IHRoZSBzYW1lIHRpbWUsIHNv IHdobyB3aWxsIGhhbmRsZSB0aGlzIGNhc2U/PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iY29s b3I6IzFGNDk3RCI+Um9uaTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gTWlrZSBC aXNob3AgWzxhIGhyZWY9Im1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZSIgdGFyZ2V0PSJfYmxh bmsiPm1haWx0bzptYmlzaG9wQGV2ZXF1ZWZvdS5iZTwvYT5dDQo8YnI+DQo8Yj5TZW50OjwvYj4g PHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV1508L3NwYW4+PHNwYW4gZGlyPSJMVFIiPjwv c3Bhbj48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPiZuYnNwOzxzcGFuIGxhbmc9IkhFIiBkaXI9IlJU TCI+15MNCjwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIGRpcj0iTFRSIj48L3Nw YW4+MTUgPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj4NCteg15XXkdee15HXqCA8L3NwYW4+PHNw YW4gZGlyPSJMVFIiPjwvc3Bhbj48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjIwMTcgMDU6MzU8YnI+ DQo8Yj5Ubzo8L2I+IFJvbmkgRXZlbjsgUVVJQyBXRzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSRTog Y29ubmVjdGlvbiBtaWdyYXRpb248L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhhdCBtYXkgd2VsbCBiZSB0aGUgY2FzZSwgYnV0IGl04oCZcyBub3Qg dGhlIFFVSUMgc3RhY2vigJlzIGNob2ljZSB0byBtYWtlLiZuYnNwOyBUaGUgYXBwbGljYXRpb24g Y291bGQgY2hvb3NlIHRvIG9wZW4gYSBuZXcgY29ubmVjdGlvbiwgYnV0IHRoYXQgcmVtYWlucyBv dXRzaWRlIHRoZSBzY29wZSBvZiB0aGUgdHJhbnNwb3J0DQogYW5kIHRoZSBtYXBwaW5nIHRvIGl0 IHdoaWNoIHdl4oCZcmUgZGVmaW5pbmcuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Gb3Ig SFRUUCwgdGhpcyBpcyBmYWlybHkgc3RyYWlnaHRmb3J3YXJkIOKAkyBpdCBjb3VsZCBzdG9wIGlz c3VpbmcgbmV3IGZsb3cgY29udHJvbCBjcmVkaXQsIGxldCBjdXJyZW50bHktaW4tdHJhbnNpdCBk YXRhIGFycml2ZSBhbmQgYW55IGxvc3NlcyByZWNvdmVyZWQsIGFuZCBvcGVuIGEgVENQIGNvbm5l Y3Rpb24NCiB0byBpc3N1ZSBhIHJhbmdlIHJlcXVlc3Qgc3RhcnRpbmcgYXQgd2hhdGV2ZXIgZGF0 YSBvZmZzZXQgaXQgaGFzbuKAmXQgc2Vlbi4mbmJzcDsgQnV0IHRoYXTigJlzIHN0aWxsIGEgcHJv cGVydHkgb2YgYW4gSFRUUCBtYW5hZ2VtZW50IGFib3ZlIHRoZSBIVFRQL1FVSUMgbWFwcGluZy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48Yj5Gcm9tOjwvYj4gUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0K PGI+T24gQmVoYWxmIE9mIDwvYj5Sb25pIEV2ZW48YnI+DQo8Yj5TZW50OjwvYj4gV2VkbmVzZGF5 LCBOb3ZlbWJlciAxNSwgMjAxNyAxMToyNSBBTTxicj4NCjxiPlRvOjwvYj4gUVVJQyBXRyAmbHQ7 PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYu b3JnPC9hPiZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gY29ubmVjdGlvbiBtaWdyYXRpb248bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IaSw8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V2hlbiBtb3ZpbmcgZnJvbSBjZWxsIHRvIHdpZmkg dGhlIHJlYXNvbiBtYXkgYmUgZHVlIHRvIGNvc3QgKG1vbmV5IG9yIHF1b3RhKS4gSW4gdGhpcyBj YXNlIHRoZSZuYnNwOyB1c2VyIChjbGllbnQpIG1heSB3YW50IHRvIG1vdmUgdG8gd2lmaSBldmVu IGlmIGl0IHdpbGwgbWVhbiBkcm9wcGluZyB0byBUQ1AuPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5Sb25pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_6E58094ECC8D8344914996DAD28F1CCD8373C9DGGEMM506MBXchina_-- From nobody Wed Nov 15 17:37: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 9E96A124319 for ; Wed, 15 Nov 2017 17:37:24 -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 (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 YayvLt2S_hcl for ; Wed, 15 Nov 2017 17:37:21 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::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 D155F12008A for ; Wed, 15 Nov 2017 17:37:20 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id r127so4032905itb.5 for ; Wed, 15 Nov 2017 17:37: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=0uY/Xb8nzvm+pPBY/4gezuVXS5Xm47OXUqvhzBxddm0=; b=RqI/yryihtmIgli5VrY0wHzFYvCjrc2cmzqdvXl/heSZNhdVVTAy3I6CZGScyEfuER BWFRdyDjVH2gfgvkEx3U3LgYzhdY8rpiP3HLy15dEejNQ5mNqkHboIIDC5egDDls3m6B am1fGoqqkf4oXG3U83e7ezkroXwvEaGTYDjEPYMQ43Kn3BS0hNEm16uckg0P/wfGSqWq N23AGIIOqJM+M2HGd70mFx0F3cOGUtI/Mod1hX2ZQG0IrZArnkGZFI1nd2ouuiknlWp+ i74AS7kivZVtNBpGGWTWaVosPirbIxdQKuIf4v2SVtBQM4sSC/Tk3VHYx9wEHoJRwkTm zq0g== 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=0uY/Xb8nzvm+pPBY/4gezuVXS5Xm47OXUqvhzBxddm0=; b=h6SW4mNHqDac0FGNeIH7awm/5+ce6hxQeb+4cceYPOQEcG6N02oG8XESBrf0z3vOuN e3dajxjkIhKbPcK+hKQKC8Cn/YUlxxysAhgj5k/C+aNpiGwJ1SLLi7nTxFAOVdsyACY7 sH9RHNCAaUz1idvJuIcuXClxEHX/iFlyWLYdhU9g6lBhYmMZfymKR2picprtvkYi2ETd tTbqlACP59ck+5m+Z/f166IquPV6lYsIRVBTyY0wtwZT4CXQekOmyaTPWtudBGplrByM vNCZa/iu+dlcnF5ie9PGfNRHMZnWNTh0eIoGX3EkgMvPwpne94QXrOhooCV0OmjEwcVu BdVQ== X-Gm-Message-State: AJaThX7n3ELWPUyBqAW8ksshpNYKYeaQHILoF9Cf1i/PNjWDghLf4kLu A6Srcidn9sC+7EUcbDqoWnuJSHJV3vO+qzXaWR89lg== X-Google-Smtp-Source: AGs4zMa3f4rBdHdSPgp5GCidBodDvo3pq1zlh4X/cRKXaRMoBNM/lWpNMCXNMFiqZfyWyCYapsm0CiM9haZlEhHHy8Q= X-Received: by 10.36.17.130 with SMTP id 124mr487816itf.81.1510796239840; Wed, 15 Nov 2017 17:37:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.101.16 with HTTP; Wed, 15 Nov 2017 17:36:59 -0800 (PST) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8373C9@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837234@DGGEMM506-MBX.china.huawei.com> <55a2d469c30d4ba58c55c328defd2872@usma1ex-dag1mb5.msg.corp.akamai.com> <6E58094ECC8D8344914996DAD28F1CCD8373C9@DGGEMM506-MBX.china.huawei.com> From: Ian Swett Date: Wed, 15 Nov 2017 20:36:59 -0500 Message-ID: Subject: Re: connection migration To: Roni Even Cc: Spencer Dawkins at IETF , "Lubashev, Igor" , Jana Iyengar , QUIC WG , Mike Bishop Content-Type: multipart/alternative; boundary="001a1144659a348e92055e0fa9d2" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 01:37:25 -0000 --001a1144659a348e92055e0fa9d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is a policy question more than a QUIC transport one, but a good behavior in such a situation is to finish any in-flight communications(ie: HTTP requests) and then send new traffic over Wifi. Applications have to deal with this exact situation today, because they do not have migration. On Wed, Nov 15, 2017 at 8:29 PM, Roni Even wrote: > Hi, > > Just for clarification, I was wondering about migration from the cellula= r > network to wifi, for example when walking from the street to my work offi= ce > if my office FW will block QUIC how will it happen that multiple > application running over QUIC on Cellular will all switch to TCP over WIF= I > and I will not see some of the applications that will continue running > QUIC over Cellular while the rest will switch to TCP over WIFI. > > Roni > > > > *From:* Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > *Sent:* =D7=99=D7=95=D7=9D =D7=94 16 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 02:25 > *To:* Lubashev, Igor > *Cc:* Roni Even; Jana Iyengar; Mike Bishop; QUIC WG > *Subject:* Re: connection migration > > > > Speaking as a curious individual, but not more. > > > > On Wed, Nov 15, 2017 at 11:43 PM, Lubashev, Igor > wrote: > > Roni, if an application decides to switch from QUIC to TCP, there will be > no connection migration. The application will have to establish a new > connection over TCP, likely, renegotiate crypto, and whatever QUIC stream= s > were in progress will not just migrate and continue over TCP somehow. > Seamless connection migration between QUIC and TCP is certainly outside o= f > the charter. > > > > It's probably good for me to say that as I understand it, migration, and > especially migration between transport protocols, is a session protocol > thing, and we really don't have a session protocol level in the Internet. > We rely on applications making decisions like this, rather than trying to > make decisions lower in the stack for the application. > > > > When we have MP-TCP, as I understand it, TCP itself barely changes, so > that's less true, but it's still close. > > > > I rely on working groups to make informed decisions about stuff like this= , > but I wouldn't be surprised to see an MP-QUIC to be look sort of like > MP-TCP, when the working group starts making decisions about multi-path. > > > > And I see migration as roughly multipath when an application uses one pat= h > at a time, at the 10,000-meter level. > > > > I could be wrong, but that's my guess. > > > > IMO. > > > > Spencer > > > > Apologies, if I misunderstood your intent, and you were talking about > something other than how to migrate connections from QUIC to TCP. > > > > - Igor > > > > > > *From:* Roni Even [mailto:roni.even@huawei.com] > *Sent:* Wednesday, November 15, 2017 10:21 PM > *To:* Jana Iyengar ; Mike Bishop > *Cc:* QUIC WG > *Subject:* RE: connection migration > > > > Hi, > > I apologize if anyone felt that I was being sarcastic. To me it looks tha= t > there is some difference. My understanding that there is separation betwe= en > the transport (QUIC) and the application (HTTP first and other later). > > An application can see in the TCP case two options TCP on or TCP off. In > QUIC it sees three options QUIC on, QUIC off (no connection), TCP. If one > of the physical connection is closed there is no problem. I assumed that > both physical connection are kept open (when I enter the house I connect = to > the AP but the 3G data channel is still open) but the application will tr= y > to send data on the wifi network and not on the cellular network since th= is > is the policy, am I wrong? > > Roni > > > > *From:* Jana Iyengar [mailto:jri@google.com ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 13:43 > *To:* Mike Bishop > *Cc:* Roni Even; QUIC WG > *Subject:* Re: connection migration > > > > What Mike said. The scope of QUIC, by definition, is not larger than QUIC= . > > > > On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop wrote= : > > Your sarcasm notwithstanding, I=E2=80=99ll emphasize that this is identic= al to TCP > today. Either the applications move, or they don=E2=80=99t. If the devi= ce > forcibly brings down the cellular interface=E2=80=99s data connection, th= e > applications will have to move if they didn=E2=80=99t already move gracef= ully, > which is independent of the transport=E2=80=99s properties. > > > > *From:* Roni Even [mailto:roni.even@huawei.com] > *Sent:* Wednesday, November 15, 2017 6:38 PM > > > *To:* Mike Bishop ; QUIC WG > *Subject:* RE: connection migration > > > > > > > > *From:* Mike Bishop [mailto:mbishop@evequefou.be ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 10:18 > *To:* Roni Even; QUIC WG > *Subject:* RE: connection migration > > > > No; in the TCP case your transport doesn=E2=80=99t have any migration pro= vision, > so it=E2=80=99s up to the application whether it wants to wind down the e= xisting > connection and start a new one. If migration fails with QUIC, the > situation is *exactly the same*, and the application decides whether it > wants to wind down the existing connection and start a new one. > > > > If there=E2=80=99s more than one application, then the answer to =E2=80= =9Cwhich > application=E2=80=9D is =E2=80=9Ceach application=E2=80=9D because each a= pplication owns its own > connections. > > *[Roni Even] So we can end up with one application on the cell and the > other on the wifi. Nice!!!* > > > > *From:* Roni Even [mailto:roni.even@huawei.com ] > *Sent:* Wednesday, November 15, 2017 3:44 PM > *To:* Mike Bishop ; QUIC WG > *Subject:* RE: connection migration > > > > inline > > > > *From:* Mike Bishop [mailto:mbishop@evequefou.be ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 08:23 > *To:* Roni Even; QUIC WG > *Subject:* RE: connection migration > > > > Exactly the same way that TCP-to-TCP handoff between these interfaces > works today, because (non-MP) TCP isn=E2=80=99t capable of changing to a = different > interface. We=E2=80=99re trying to build a better answer, but you=E2=80= =99re positing from > the start that connection migration fails, so we=E2=80=99re now in =E2=80= =9Cno worse=E2=80=9D land. > > > > The QUIC stack in the client device will see a new interface is > available. It attempts to switch to it, because of some local policy. T= he > transition fails for whatever reason, but the cellular connection is stil= l > active. It is the application=E2=80=99s choice > > *[Roni Even] which application if there is more than one? In the TCP case > you stay in the cell. Here there are two options, stay on the cell with > QUIC or move to wifi on TCP* > > whether it wants to wind down and close that connection and start a new > one using TCP, or keep using the old one if the interface remains > available. If there are multiple applications, each application makes th= at > choice independently. > > > > And if the first interface becomes unavailable for whatever reason, the > choice is made for it, and the application will have to recover. > > > > *From:* Roni Even [mailto:roni.even@huawei.com ] > *Sent:* Wednesday, November 15, 2017 1:25 PM > *To:* Mike Bishop ; QUIC WG > *Subject:* RE: connection migration > > > > So what is the connection migration flow here. The quic stack in the cell > network will try to migrate to wifi without application request and fail > but will not fall back to TCP. > > There may be multiple application running over quic? HTTP and peer to pee= r > at the same time, so who will handle this case? > > > > Roni > > > > *From:* Mike Bishop [mailto:mbishop@evequefou.be ] > *Sent:* =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 05:35 > *To:* Roni Even; QUIC WG > *Subject:* RE: connection migration > > > > That may well be the case, but it=E2=80=99s not the QUIC stack=E2=80=99s = choice to make. > The application could choose to open a new connection, but that remains > outside the scope of the transport and the mapping to it which we=E2=80= =99re > defining. > > > > For HTTP, this is fairly straightforward =E2=80=93 it could stop issuing = new flow > control credit, let currently-in-transit data arrive and any losses > recovered, and open a TCP connection to issue a range request starting at > whatever data offset it hasn=E2=80=99t seen. But that=E2=80=99s still a = property of an > HTTP management above the HTTP/QUIC mapping. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Roni Even > *Sent:* Wednesday, November 15, 2017 11:25 AM > *To:* QUIC WG > *Subject:* connection migration > > > > Hi, > > When moving from cell to wifi the reason may be due to cost (money or > quota). In this case the user (client) may want to move to wifi even if = it > will mean dropping to TCP. > > > > Roni > > > > > --001a1144659a348e92055e0fa9d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a policy question more than a QUIC transport one, = but a good behavior in such a situation is to finish any in-flight communic= ations(ie: HTTP requests) and then send new traffic over Wifi.

Applications have to deal with this exact situation today, because t= hey do not have migration.

On Wed, Nov 15, 2017 at 8:29 PM, Roni Even <roni= .even@huawei.com> wrote:

Hi,<= /p>

Just for clarification, = =C2=A0I was wondering about migration from the cellular network to wifi, fo= r example when walking from the street to my work office if my office FW will block QUIC how will it happen that multiple application run= ning over QUIC on Cellular will all switch to TCP over WIFI and I will not = see some of the applications =C2=A0that will continue=C2=A0 running QUIC ov= er Cellular while the rest will switch to TCP over WIFI.

Roni=

=C2=A0

From: Spencer = Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=94 1= 6 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 02:25
To: Lubashev, Igor
Cc: Roni Even; Jana Iyengar; Mike Bishop; QUIC WG
Subject: Re: connection migration

=C2=A0

Speaking as a curious individual, but not more.

=C2=A0

On Wed, Nov 15, 2017 at 11:43 PM, Lubashev, Igor <= ;ilubashe@akamai.c= om> wrote:

Roni, if an application decides to swit= ch from QUIC to TCP, there will be no connection migration.=C2=A0 The appli= cation will have to establish a new connection over TCP, likely, renegotiate cryp= to, and whatever QUIC streams were in progress will not just migrate and co= ntinue over TCP somehow.=C2=A0 Seamless connection migration between QUIC a= nd TCP is certainly outside of the charter.

=C2=A0

It's probably good for me to say that as I under= stand it, migration, and especially migration between transport protocols, = is a session protocol thing, and we really don't have a session protoco= l level in the Internet. We rely on applications making decisions like this, rather than trying to make decisions lower in = the stack for the application.=C2=A0

=C2=A0

When we have MP-TCP, as I understand it, TCP itself = barely changes, so that's less true, but it's still close.=C2=A0=

=C2=A0

I rely on working groups to make informed decisions = about stuff like this, but I wouldn't be surprised to see an MP-QUIC to= be look sort of like MP-TCP, when the working group starts making decision= s about multi-path.

=C2=A0

And I see migration as roughly multipath when an app= lication uses one path at a time, at the 10,000-meter level.=C2=A0

=C2=A0

I could be wrong, but that's my guess.=C2=A0<= /u>

=C2=A0

IMO.

=C2=A0

Spencer

=C2=A0

Apologies, if I misunderstood your inte= nt, and you were talking about something other than how to migrate connecti= ons from QUIC to TCP.

=C2=A0

  • Igor

=C2=A0

=C2=A0

From: Roni E= ven [mailto:roni.= even@huawei.com]
Sent: Wednesday, November 15, 2017 10:21 PM
To: Jana Iyengar <jri@google.com>; Mike Bishop <mbishop@evequefou.be>
Cc: QUIC WG <q= uic@ietf.org>
Subject: RE: connection migration

=C2=A0

Hi,<= /p>

I apologize if anyone fel= t that I was being sarcastic. To me it looks that there is some difference. My understanding that there is separation between the transport (QUIC) and= the application (HTTP first and other later).

An application can see in= the TCP case two options TCP on or TCP off. In QUIC it sees three options QUIC on, QUIC off (no connection), TCP. If one of the physical connection = is closed there is no problem. I assumed that both physical connection are = kept open (when I enter the house I connect to the AP but the 3G data chann= el is still open) but the application will try to send data on the wifi network and not on the cellular network = since this is the policy, am I wrong?

Roni=

=C2=A0

From: Jana Iye= ngar [mailto:jri@google= .com]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 1= 5 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 13:43
To: Mike Bishop
Cc: Roni Even; QUIC WG
Subject: Re: connection migration

=C2=A0

What Mike said. The scope of QUIC, by definition, is= not larger than QUIC.

=C2=A0

On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop <mbishop@evequefou.be= > wrote:

Your sarcasm notwithstanding, I=E2=80=99ll emphasize= that this is identical to TCP today.=C2=A0 Either the applications move, o= r they don=E2=80=99t.=C2=A0 If the device forcibly brings down the cellular interface=E2=80=99s data connection, the applications will have to move if= they didn=E2=80=99t already move gracefully, which is independent of the t= ransport=E2=80=99s properties.

=C2=A0

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 6:38 PM


To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.org>
Subject: RE: connection migration

=C2=A0

=C2=A0

=C2=A0

From: Mike Bis= hop [mailto:mbish= op@evequefou.be]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 1= 5 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 10:18
To: Roni Even; QUIC WG
Subject: RE: connection migration

=C2=A0

No; in the TCP case your transport doesn=E2=80=99t h= ave any migration provision, so it=E2=80=99s up to the application whether = it wants to wind down the existing connection and start a new one.=C2=A0 If migration fails with QUIC, the situation is exactly the same, an= d the application decides whether it wants to wind down the existing connec= tion and start a new one.

=C2=A0

If there=E2=80=99s more than one application, then t= he answer to =E2=80=9Cwhich application=E2=80=9D is =E2=80=9Ceach applicati= on=E2=80=9D because each application owns its own connections.

[Roni Even] So w= e can end up with one application on the cell and the other on the wifi. Ni= ce!!!

=C2=A0

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 3:44 PM
To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.org>
Subject: RE: connection migration

=C2=A0

inline

=C2=A0

From: Mike Bis= hop [mailto:mbish= op@evequefou.be]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 1= 5 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 08:23
To: Roni Even; QUIC WG
Subject: RE: connection migration

=C2=A0

Exactly the same way that TCP-to-TCP handoff between= these interfaces works today, because (non-MP) TCP isn=E2=80=99t capable o= f changing to a different interface.=C2=A0 We=E2=80=99re trying to build a better answer, but you=E2=80=99re positing from the start that connectio= n migration fails, so we=E2=80=99re now in =E2=80=9Cno worse=E2=80=9D land.=

=C2=A0

The QUIC stack in the client device will see a new i= nterface is available.=C2=A0 It attempts to switch to it, because of some l= ocal policy.=C2=A0 The transition fails for whatever reason, but the cellular connection is still active.=C2=A0 It is the application= =E2=80=99s choice

[Roni Even] whic= h application if there is more than one? In the TCP case you stay in the ce= ll. Here there are two options, stay on the cell with QUIC or move to wifi on TCP

whether it wants to wind down and close that connect= ion and start a new one using TCP, or keep using the old one if the interfa= ce remains available.=C2=A0 If there are multiple applications, each application makes that choice independently.

=C2=A0

And if the first interface becomes unavailable for w= hatever reason, the choice is made for it, and the application will have to= recover.

=C2=A0

From: Roni Even [mailto:roni.even@huawei.com]
Sent: Wednesday, November 15, 2017 1:25 PM
To: Mike Bishop <mbishop@evequefou.be>; QUIC WG <quic@ietf.org>
Subject: RE: connection migration

=C2=A0

So what is the connect= ion migration flow here. The quic stack in the cell network will try to mig= rate to wifi without application request and fail but will not fall back to TCP.

There may be multiple = application running over quic? HTTP and peer to peer at the same time, so w= ho will handle this case?

=C2=A0

Roni<= /u>

=C2=A0

From: Mike Bis= hop [mailto:mbish= op@evequefou.be]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 05:35
To: Roni Even; QUIC WG
Subject: RE: connection migration

=C2=A0

That may well be the case, but it=E2=80=99s not the = QUIC stack=E2=80=99s choice to make.=C2=A0 The application could choose to = open a new connection, but that remains outside the scope of the transport and the mapping to it which we=E2=80=99re defining.

=C2=A0

For HTTP, this is fairly straightforward =E2=80=93 i= t could stop issuing new flow control credit, let currently-in-transit data= arrive and any losses recovered, and open a TCP connection to issue a range request starting at whatever data offset it hasn=E2=80=99= t seen.=C2=A0 But that=E2=80=99s still a property of an HTTP management abo= ve the HTTP/QUIC mapping.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even
Sent: Wednesday, November 15, 2017 11:25 AM
To: QUIC WG <q= uic@ietf.org>
Subject: connection migration

=C2=A0

Hi,

When moving from cell to wifi the reason may be due = to cost (money or quota). In this case the=C2=A0 user (client) may want to = move to wifi even if it will mean dropping to TCP.

=C2=A0

Roni

=C2=A0

=C2=A0


--001a1144659a348e92055e0fa9d2-- From nobody Wed Nov 15 17:38: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 49F9A124319 for ; Wed, 15 Nov 2017 17:38:27 -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, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-W5eJmYA8dO for ; Wed, 15 Nov 2017 17:38: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 32E2A12008A for ; Wed, 15 Nov 2017 17:38:24 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by virgo02.ee.ethz.ch (Postfix) with ESMTP id 3yckR25NXMz15MWq; Thu, 16 Nov 2017 02:38: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 JWvDU9GOSQYt; Thu, 16 Nov 2017 02:38:21 +0100 (CET) X-MtScore: NO score=0 Received: from dhcp-8cbf.meeting.ietf.org (dhcp-8cbf.meeting.ietf.org [31.133.140.191]) by virgo02.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 16 Nov 2017 02:38:19 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: connection migration From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8373C9@DGGEMM506-MBX.china.huawei.com> Date: Thu, 16 Nov 2017 09:38:16 +0800 Cc: Spencer Dawkins at IETF , "Lubashev, Igor" , Jana Iyengar , QUIC WG , Mike Bishop Content-Transfer-Encoding: quoted-printable Message-Id: References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837234@DGGEMM506-MBX.china.huawei.com> <55a2d469c30d4ba58c55c328defd2872@usma1ex-dag1mb5.msg.corp.akamai.com> <6E58094ECC8D8344914996DAD28F1CCD8373C9@DGGEMM506-MBX.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 01:38:27 -0000 Hi Roni, that's for sure it an interesting use case but that is not the kind of = migration that would actually influence the quic protocol design because = effectively you=E2=80=99ll have to =E2=80=9Esimply=E2=80=9C open a NEW = TCP connection. I guess this use case is rather in scope for the taps = working group though. Mirja > Am 16.11.2017 um 09:29 schrieb Roni Even : >=20 > Hi, > Just for clarification, I was wondering about migration from the = cellular network to wifi, for example when walking from the street to my = work office if my office FW will block QUIC how will it happen that = multiple application running over QUIC on Cellular will all switch to = TCP over WIFI and I will not see some of the applications that will = continue running QUIC over Cellular while the rest will switch to TCP = over WIFI. > Roni > =20 > From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]=20= > Sent: =D7=99=D7=95=D7=9D =D7=94 16 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 = 2017 02:25 > To: Lubashev, Igor > Cc: Roni Even; Jana Iyengar; Mike Bishop; QUIC WG > Subject: Re: connection migration > =20 > Speaking as a curious individual, but not more. > =20 > On Wed, Nov 15, 2017 at 11:43 PM, Lubashev, Igor = wrote: > Roni, if an application decides to switch from QUIC to TCP, there will = be no connection migration. The application will have to establish a = new connection over TCP, likely, renegotiate crypto, and whatever QUIC = streams were in progress will not just migrate and continue over TCP = somehow. Seamless connection migration between QUIC and TCP is = certainly outside of the charter. > =20 > It's probably good for me to say that as I understand it, migration, = and especially migration between transport protocols, is a session = protocol thing, and we really don't have a session protocol level in the = Internet. We rely on applications making decisions like this, rather = than trying to make decisions lower in the stack for the application.=20 > =20 > When we have MP-TCP, as I understand it, TCP itself barely changes, so = that's less true, but it's still close.=20 > =20 > I rely on working groups to make informed decisions about stuff like = this, but I wouldn't be surprised to see an MP-QUIC to be look sort of = like MP-TCP, when the working group starts making decisions about = multi-path. > =20 > And I see migration as roughly multipath when an application uses one = path at a time, at the 10,000-meter level.=20 > =20 > I could be wrong, but that's my guess.=20 > =20 > IMO. > =20 > Spencer > =20 > Apologies, if I misunderstood your intent, and you were talking about = something other than how to migrate connections from QUIC to TCP. > =20 > =E2=80=A2 Igor > =20 > =20 > From: Roni Even [mailto:roni.even@huawei.com]=20 > Sent: Wednesday, November 15, 2017 10:21 PM > To: Jana Iyengar ; Mike Bishop > Cc: QUIC WG > Subject: RE: connection migration > =20 > Hi, > I apologize if anyone felt that I was being sarcastic. To me it looks = that there is some difference. My understanding that there is separation = between the transport (QUIC) and the application (HTTP first and other = later). > An application can see in the TCP case two options TCP on or TCP off. = In QUIC it sees three options QUIC on, QUIC off (no connection), TCP. If = one of the physical connection is closed there is no problem. I assumed = that both physical connection are kept open (when I enter the house I = connect to the AP but the 3G data channel is still open) but the = application will try to send data on the wifi network and not on the = cellular network since this is the policy, am I wrong? > Roni > =20 > From: Jana Iyengar [mailto:jri@google.com]=20 > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 = 2017 13:43 > To: Mike Bishop > Cc: Roni Even; QUIC WG > Subject: Re: connection migration > =20 > What Mike said. The scope of QUIC, by definition, is not larger than = QUIC. > =20 > On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop = wrote: > Your sarcasm notwithstanding, I=E2=80=99ll emphasize that this is = identical to TCP today. Either the applications move, or they don=E2=80=99= t. If the device forcibly brings down the cellular interface=E2=80=99s = data connection, the applications will have to move if they didn=E2=80=99t= already move gracefully, which is independent of the transport=E2=80=99s = properties. > =20 > From: Roni Even [mailto:roni.even@huawei.com]=20 > Sent: Wednesday, November 15, 2017 6:38 PM >=20 > To: Mike Bishop ; QUIC WG > Subject: RE: connection migration > =20 > =20 > =20 > From: Mike Bishop [mailto:mbishop@evequefou.be]=20 > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 = 2017 10:18 > To: Roni Even; QUIC WG > Subject: RE: connection migration > =20 > No; in the TCP case your transport doesn=E2=80=99t have any migration = provision, so it=E2=80=99s up to the application whether it wants to = wind down the existing connection and start a new one. If migration = fails with QUIC, the situation is exactly the same, and the application = decides whether it wants to wind down the existing connection and start = a new one. > =20 > If there=E2=80=99s more than one application, then the answer to = =E2=80=9Cwhich application=E2=80=9D is =E2=80=9Ceach application=E2=80=9D = because each application owns its own connections. > [Roni Even] So we can end up with one application on the cell and the = other on the wifi. Nice!!! > =20 > From: Roni Even [mailto:roni.even@huawei.com]=20 > Sent: Wednesday, November 15, 2017 3:44 PM > To: Mike Bishop ; QUIC WG > Subject: RE: connection migration > =20 > inline > =20 > From: Mike Bishop [mailto:mbishop@evequefou.be]=20 > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 = 2017 08:23 > To: Roni Even; QUIC WG > Subject: RE: connection migration > =20 > Exactly the same way that TCP-to-TCP handoff between these interfaces = works today, because (non-MP) TCP isn=E2=80=99t capable of changing to a = different interface. We=E2=80=99re trying to build a better answer, but = you=E2=80=99re positing from the start that connection migration fails, = so we=E2=80=99re now in =E2=80=9Cno worse=E2=80=9D land. > =20 > The QUIC stack in the client device will see a new interface is = available. It attempts to switch to it, because of some local policy. = The transition fails for whatever reason, but the cellular connection is = still active. It is the application=E2=80=99s choice=20 > [Roni Even] which application if there is more than one? In the TCP = case you stay in the cell. Here there are two options, stay on the cell = with QUIC or move to wifi on TCP > whether it wants to wind down and close that connection and start a = new one using TCP, or keep using the old one if the interface remains = available. If there are multiple applications, each application makes = that choice independently. > =20 > And if the first interface becomes unavailable for whatever reason, = the choice is made for it, and the application will have to recover. > =20 > From: Roni Even [mailto:roni.even@huawei.com]=20 > Sent: Wednesday, November 15, 2017 1:25 PM > To: Mike Bishop ; QUIC WG > Subject: RE: connection migration > =20 > So what is the connection migration flow here. The quic stack in the = cell network will try to migrate to wifi without application request and = fail but will not fall back to TCP. > There may be multiple application running over quic? HTTP and peer to = peer at the same time, so who will handle this case? > =20 > Roni > =20 > From: Mike Bishop [mailto:mbishop@evequefou.be]=20 > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 = 2017 05:35 > To: Roni Even; QUIC WG > Subject: RE: connection migration > =20 > That may well be the case, but it=E2=80=99s not the QUIC stack=E2=80=99s= choice to make. The application could choose to open a new connection, = but that remains outside the scope of the transport and the mapping to = it which we=E2=80=99re defining. > =20 > For HTTP, this is fairly straightforward =E2=80=93 it could stop = issuing new flow control credit, let currently-in-transit data arrive = and any losses recovered, and open a TCP connection to issue a range = request starting at whatever data offset it hasn=E2=80=99t seen. But = that=E2=80=99s still a property of an HTTP management above the = HTTP/QUIC mapping. > =20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even > Sent: Wednesday, November 15, 2017 11:25 AM > To: QUIC WG > Subject: connection migration > =20 > Hi, > When moving from cell to wifi the reason may be due to cost (money or = quota). In this case the user (client) may want to move to wifi even if = it will mean dropping to TCP. > =20 > Roni From nobody Wed Nov 15 18:46:01 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 4C9C01292CE for ; Wed, 15 Nov 2017 18:45:59 -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 iQnVkdQm1som for ; Wed, 15 Nov 2017 18:45:56 -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 D628A126DFB for ; Wed, 15 Nov 2017 18:45:55 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id g204so6577237ywa.6 for ; Wed, 15 Nov 2017 18:45:55 -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=Ki+PvToX7VzPgwwcrTgJbDswi7OqkMSM/OWSgwHpTmI=; b=H0eFy/ZjgzSLaCOWulSiZd/64u0Z+bQWN+XsLGDqZIsZt95hTewmhxgdQAtILOE/QB 0fflsmQPEB+efE1ei4xXA0w5Y4DVey9ti+1M1jySbo2GAZZS/X5gsXbK2X8o3bwdolRV ybm4T6ZOQp2fmWA4CsKCZ8u9RrqVtrpLhHRpG0NaTzLi2X1qgfLTVJx9od37eOgdktTV kPttV5x+nkFt2wYttfFuFwR7M+jxqOzBtshd70ENVfiuyUdLi/xRj3MyjNizZMEwrwhN ++SnPY96pvkGvami+KfUnywRadi7QCySsJyPcQepa6z7eeAcS2sxopUMSenBZjiH7tK+ slgQ== 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=Ki+PvToX7VzPgwwcrTgJbDswi7OqkMSM/OWSgwHpTmI=; b=HyiPj8SHmViWsu5KBJcLxjKcQPFyFFnTtLfdh2MSQJJ3xFMrzGchZFzFjJbxItCTU9 K31ka+d85QLCrvPfzUx3mFpAv2f9t+ysRTtkVd192arBi5mumOxZ81yM2NpmLcqMkLH+ 45tY3IwFuOIPAvN45KNpvWPiP4yyGf+XXBag823XyP8sKXbEw7/U5nAmxgPvyiBiewrC H/vo2hpMqd6iZH2WhVCuHSjDrie2mXARsp4QLfsRBSJ+XJ6StP7uXgd3bEztUyxETxGB fro2PIQT4JnVlbXORPi5UvwBjF1MoUmYSoxnKQRsTSqs+QFjcnvJg69dvQrgkSpv1Yzo FI6g== X-Gm-Message-State: AJaThX6cicbQZrCcIdznqwugzlz7rWXXi/xrq960iM+5wxQW6DZnxkGl 8VsamDeJH0p7YSXdl2G4oxRsJvQOndJBEso9bU0= X-Google-Smtp-Source: AGs4zMbZP2Hp84OJAOjNo/3zR3GE6bFkMhVmhvlYGz/Q32s0ruAV2yaYd4zI8FFWPqk4N4cUktz8i7LYPUEzFjoW/J8= X-Received: by 10.37.252.5 with SMTP id v5mr88033ybd.518.1510800354889; Wed, 15 Nov 2017 18:45:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.135.75 with HTTP; Wed, 15 Nov 2017 18:45:54 -0800 (PST) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837234@DGGEMM506-MBX.china.huawei.com> <55a2d469c30d4ba58c55c328defd2872@usma1ex-dag1mb5.msg.corp.akamai.com> <6E58094ECC8D8344914996DAD28F1CCD8373C9@DGGEMM506-MBX.china.huawei.com> From: Spencer Dawkins at IETF Date: Thu, 16 Nov 2017 10:45:54 +0800 Message-ID: Subject: Re: connection migration To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= Cc: Roni Even , "Lubashev, Igor" , Jana Iyengar , QUIC WG , Mike Bishop Content-Type: multipart/alternative; boundary="f403045db63e7ad844055e109ea0" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 02:45:59 -0000 --f403045db63e7ad844055e109ea0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to chime in, On Thu, Nov 16, 2017 at 9:38 AM, Mirja K=C3=BChlewind < mirja.kuehlewind@tik.ee.ethz.ch> wrote: > Hi Roni, > > that's for sure it an interesting use case but that is not the kind of > migration that would actually influence the quic protocol design because > effectively you=E2=80=99ll have to =E2=80=9Esimply=E2=80=9C open a NEW TC= P connection. I guess this > use case is rather in scope for the taps working group though. > As responsible AD for QUIC and TAPS, I agree with Mirja - interesting, but more appropriate for TAPS. And thanks for raising the question, Roni. I bet you're not the only person thinking about this. Spencer > Mirja > > > > Am 16.11.2017 um 09:29 schrieb Roni Even : > > > > Hi, > > Just for clarification, I was wondering about migration from the > cellular network to wifi, for example when walking from the street to my > work office if my office FW will block QUIC how will it happen that > multiple application running over QUIC on Cellular will all switch to TCP > over WIFI and I will not see some of the applications that will continue > running QUIC over Cellular while the rest will switch to TCP over WIFI. > > Roni > > > > From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com] > > Sent: =D7=99=D7=95=D7=9D =D7=94 16 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 02:25 > > To: Lubashev, Igor > > Cc: Roni Even; Jana Iyengar; Mike Bishop; QUIC WG > > Subject: Re: connection migration > > > > Speaking as a curious individual, but not more. > > > > On Wed, Nov 15, 2017 at 11:43 PM, Lubashev, Igor > wrote: > > Roni, if an application decides to switch from QUIC to TCP, there will > be no connection migration. The application will have to establish a new > connection over TCP, likely, renegotiate crypto, and whatever QUIC stream= s > were in progress will not just migrate and continue over TCP somehow. > Seamless connection migration between QUIC and TCP is certainly outside o= f > the charter. > > > > It's probably good for me to say that as I understand it, migration, an= d > especially migration between transport protocols, is a session protocol > thing, and we really don't have a session protocol level in the Internet. > We rely on applications making decisions like this, rather than trying to > make decisions lower in the stack for the application. > > > > When we have MP-TCP, as I understand it, TCP itself barely changes, so > that's less true, but it's still close. > > > > I rely on working groups to make informed decisions about stuff like > this, but I wouldn't be surprised to see an MP-QUIC to be look sort of li= ke > MP-TCP, when the working group starts making decisions about multi-path. > > > > And I see migration as roughly multipath when an application uses one > path at a time, at the 10,000-meter level. > > > > I could be wrong, but that's my guess. > > > > IMO. > > > > Spencer > > > > Apologies, if I misunderstood your intent, and you were talking about > something other than how to migrate connections from QUIC to TCP. > > > > =E2=80=A2 Igor > > > > > > From: Roni Even [mailto:roni.even@huawei.com] > > Sent: Wednesday, November 15, 2017 10:21 PM > > To: Jana Iyengar ; Mike Bishop > > Cc: QUIC WG > > Subject: RE: connection migration > > > > Hi, > > I apologize if anyone felt that I was being sarcastic. To me it looks > that there is some difference. My understanding that there is separation > between the transport (QUIC) and the application (HTTP first and other > later). > > An application can see in the TCP case two options TCP on or TCP off. I= n > QUIC it sees three options QUIC on, QUIC off (no connection), TCP. If one > of the physical connection is closed there is no problem. I assumed that > both physical connection are kept open (when I enter the house I connect = to > the AP but the 3G data channel is still open) but the application will tr= y > to send data on the wifi network and not on the cellular network since th= is > is the policy, am I wrong? > > Roni > > > > From: Jana Iyengar [mailto:jri@google.com] > > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 13:43 > > To: Mike Bishop > > Cc: Roni Even; QUIC WG > > Subject: Re: connection migration > > > > What Mike said. The scope of QUIC, by definition, is not larger than > QUIC. > > > > On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop > wrote: > > Your sarcasm notwithstanding, I=E2=80=99ll emphasize that this is ident= ical to > TCP today. Either the applications move, or they don=E2=80=99t. If the = device > forcibly brings down the cellular interface=E2=80=99s data connection, th= e > applications will have to move if they didn=E2=80=99t already move gracef= ully, > which is independent of the transport=E2=80=99s properties. > > > > From: Roni Even [mailto:roni.even@huawei.com] > > Sent: Wednesday, November 15, 2017 6:38 PM > > > > To: Mike Bishop ; QUIC WG > > Subject: RE: connection migration > > > > > > > > From: Mike Bishop [mailto:mbishop@evequefou.be] > > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 10:18 > > To: Roni Even; QUIC WG > > Subject: RE: connection migration > > > > No; in the TCP case your transport doesn=E2=80=99t have any migration p= rovision, > so it=E2=80=99s up to the application whether it wants to wind down the e= xisting > connection and start a new one. If migration fails with QUIC, the > situation is exactly the same, and the application decides whether it wan= ts > to wind down the existing connection and start a new one. > > > > If there=E2=80=99s more than one application, then the answer to =E2=80= =9Cwhich > application=E2=80=9D is =E2=80=9Ceach application=E2=80=9D because each a= pplication owns its own > connections. > > [Roni Even] So we can end up with one application on the cell and the > other on the wifi. Nice!!! > > > > From: Roni Even [mailto:roni.even@huawei.com] > > Sent: Wednesday, November 15, 2017 3:44 PM > > To: Mike Bishop ; QUIC WG > > Subject: RE: connection migration > > > > inline > > > > From: Mike Bishop [mailto:mbishop@evequefou.be] > > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 08:23 > > To: Roni Even; QUIC WG > > Subject: RE: connection migration > > > > Exactly the same way that TCP-to-TCP handoff between these interfaces > works today, because (non-MP) TCP isn=E2=80=99t capable of changing to a = different > interface. We=E2=80=99re trying to build a better answer, but you=E2=80= =99re positing from > the start that connection migration fails, so we=E2=80=99re now in =E2=80= =9Cno worse=E2=80=9D land. > > > > The QUIC stack in the client device will see a new interface is > available. It attempts to switch to it, because of some local policy. T= he > transition fails for whatever reason, but the cellular connection is stil= l > active. It is the application=E2=80=99s choice > > [Roni Even] which application if there is more than one? In the TCP cas= e > you stay in the cell. Here there are two options, stay on the cell with > QUIC or move to wifi on TCP > > whether it wants to wind down and close that connection and start a new > one using TCP, or keep using the old one if the interface remains > available. If there are multiple applications, each application makes th= at > choice independently. > > > > And if the first interface becomes unavailable for whatever reason, the > choice is made for it, and the application will have to recover. > > > > From: Roni Even [mailto:roni.even@huawei.com] > > Sent: Wednesday, November 15, 2017 1:25 PM > > To: Mike Bishop ; QUIC WG > > Subject: RE: connection migration > > > > So what is the connection migration flow here. The quic stack in the > cell network will try to migrate to wifi without application request and > fail but will not fall back to TCP. > > There may be multiple application running over quic? HTTP and peer to > peer at the same time, so who will handle this case? > > > > Roni > > > > From: Mike Bishop [mailto:mbishop@evequefou.be] > > Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8= 2017 05:35 > > To: Roni Even; QUIC WG > > Subject: RE: connection migration > > > > That may well be the case, but it=E2=80=99s not the QUIC stack=E2=80=99= s choice to > make. The application could choose to open a new connection, but that > remains outside the scope of the transport and the mapping to it which > we=E2=80=99re defining. > > > > For HTTP, this is fairly straightforward =E2=80=93 it could stop issuin= g new > flow control credit, let currently-in-transit data arrive and any losses > recovered, and open a TCP connection to issue a range request starting at > whatever data offset it hasn=E2=80=99t seen. But that=E2=80=99s still a = property of an > HTTP management above the HTTP/QUIC mapping. > > > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Roni Even > > Sent: Wednesday, November 15, 2017 11:25 AM > > To: QUIC WG > > Subject: connection migration > > > > Hi, > > When moving from cell to wifi the reason may be due to cost (money or > quota). In this case the user (client) may want to move to wifi even if = it > will mean dropping to TCP. > > > > Roni > > --f403045db63e7ad844055e109ea0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to chime in,

On Thu, Nov 16, 2017 at 9:38 AM, Mirja K=C3=BChlewind <mirja.kuehlewind@tik.ee.ethz.ch> wrote:
Hi Roni,

that's for sure it an interesting use case but that is not the kind of = migration that would actually influence the quic protocol design because ef= fectively you=E2=80=99ll have to =E2=80=9Esimply=E2=80=9C open a NEW TCP co= nnection. I guess this use case is rather in scope for the taps working gro= up though.

As responsible AD for QUIC a= nd TAPS, I agree with Mirja - interesting, but more appropriate for TAPS.

And thanks for raising the question, Roni. I bet yo= u're not the only person thinking about this.

= Spencer
=C2=A0
Mirja


> Am 16.11.2017 um 09:29 schrieb Roni Even <roni.even@huawei.com>:
>
> Hi,
> Just for clarification,=C2=A0 I was wondering about migration from the= cellular network to wifi, for example when walking from the street to my w= ork office if my office FW will block QUIC how will it happen that multiple= application running over QUIC on Cellular will all switch to TCP over WIFI= and I will not see some of the applications=C2=A0 that will continue=C2=A0= running QUIC over Cellular while the rest will switch to TCP over WIFI. > Roni
>
> From: Spencer Dawkins at IETF [mailto:spencerdawkins.ietf@gmail.com]
> Sent: =D7=99=D7=95=D7=9D =D7=94 16 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7= =A8 2017 02:25
> To: Lubashev, Igor
> Cc: Roni Even; Jana Iyengar; Mike Bishop; QUIC WG
> Subject: Re: connection migration
>
> Speaking as a curious individual, but not more.
>
> On Wed, Nov 15, 2017 at 11:43 PM, Lubashev, Igor <ilubashe@akamai.com> wrote:
> Roni, if an application decides to switch from QUIC to TCP, there will= be no connection migration.=C2=A0 The application will have to establish a= new connection over TCP, likely, renegotiate crypto, and whatever QUIC str= eams were in progress will not just migrate and continue over TCP somehow.= =C2=A0 Seamless connection migration between QUIC and TCP is certainly outs= ide of the charter.
>
> It's probably good for me to say that as I understand it, migratio= n, and especially migration between transport protocols, is a session proto= col thing, and we really don't have a session protocol level in the Int= ernet. We rely on applications making decisions like this, rather than tryi= ng to make decisions lower in the stack for the application.
>
> When we have MP-TCP, as I understand it, TCP itself barely changes, so= that's less true, but it's still close.
>
> I rely on working groups to make informed decisions about stuff like t= his, but I wouldn't be surprised to see an MP-QUIC to be look sort of l= ike MP-TCP, when the working group starts making decisions about multi-path= .
>
> And I see migration as roughly multipath when an application uses one = path at a time, at the 10,000-meter level.
>
> I could be wrong, but that's my guess.
>
> IMO.
>
> Spencer
>
> Apologies, if I misunderstood your intent, and you were talking about = something other than how to migrate connections from QUIC to TCP.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0=E2=80=A2 Igor
>
>
> From: Roni Even [mailto:roni.e= ven@huawei.com]
> Sent: Wednesday, November 15, 2017 10:21 PM
> To: Jana Iyengar <jri@google.com<= /a>>; Mike Bishop <mbishop@ev= equefou.be>
> Cc: QUIC WG <quic@ietf.org>=
> Subject: RE: connection migration
>
> Hi,
> I apologize if anyone felt that I was being sarcastic. To me it looks = that there is some difference. My understanding that there is separation be= tween the transport (QUIC) and the application (HTTP first and other later)= .
> An application can see in the TCP case two options TCP on or TCP off. = In QUIC it sees three options QUIC on, QUIC off (no connection), TCP. If on= e of the physical connection is closed there is no problem. I assumed that = both physical connection are kept open (when I enter the house I connect to= the AP but the 3G data channel is still open) but the application will try= to send data on the wifi network and not on the cellular network since thi= s is the policy, am I wrong?
> Roni
>
> From: Jana Iyengar [mailto:jri@googl= e.com]
> Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7= =A8 2017 13:43
> To: Mike Bishop
> Cc: Roni Even; QUIC WG
> Subject: Re: connection migration
>
> What Mike said. The scope of QUIC, by definition, is not larger than Q= UIC.
>
> On Wed, Nov 15, 2017 at 7:02 PM, Mike Bishop <mbishop@evequefou.be> wrote:
> Your sarcasm notwithstanding, I=E2=80=99ll emphasize that this is iden= tical to TCP today.=C2=A0 Either the applications move, or they don=E2=80= =99t.=C2=A0 If the device forcibly brings down the cellular interface=E2=80= =99s data connection, the applications will have to move if they didn=E2=80= =99t already move gracefully, which is independent of the transport=E2=80= =99s properties.
>
> From: Roni Even [mailto:roni.e= ven@huawei.com]
> Sent: Wednesday, November 15, 2017 6:38 PM
>
> To: Mike Bishop <mbishop@ev= equefou.be>; QUIC WG <quic@ietf.= org>
> Subject: RE: connection migration
>
>
>
> From: Mike Bishop [mailto:mbis= hop@evequefou.be]
> Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7= =A8 2017 10:18
> To: Roni Even; QUIC WG
> Subject: RE: connection migration
>
> No; in the TCP case your transport doesn=E2=80=99t have any migration = provision, so it=E2=80=99s up to the application whether it wants to wind d= own the existing connection and start a new one.=C2=A0 If migration fails w= ith QUIC, the situation is exactly the same, and the application decides wh= ether it wants to wind down the existing connection and start a new one. >
> If there=E2=80=99s more than one application, then the answer to =E2= =80=9Cwhich application=E2=80=9D is =E2=80=9Ceach application=E2=80=9D beca= use each application owns its own connections.
> [Roni Even] So we can end up with one application on the cell and the = other on the wifi. Nice!!!
>
> From: Roni Even [mailto:roni.e= ven@huawei.com]
> Sent: Wednesday, November 15, 2017 3:44 PM
> To: Mike Bishop <mbishop@ev= equefou.be>; QUIC WG <quic@ietf.= org>
> Subject: RE: connection migration
>
> inline
>
> From: Mike Bishop [mailto:mbis= hop@evequefou.be]
> Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7= =A8 2017 08:23
> To: Roni Even; QUIC WG
> Subject: RE: connection migration
>
> Exactly the same way that TCP-to-TCP handoff between these interfaces = works today, because (non-MP) TCP isn=E2=80=99t capable of changing to a di= fferent interface.=C2=A0 We=E2=80=99re trying to build a better answer, but= you=E2=80=99re positing from the start that connection migration fails, so= we=E2=80=99re now in =E2=80=9Cno worse=E2=80=9D land.
>
> The QUIC stack in the client device will see a new interface is availa= ble.=C2=A0 It attempts to switch to it, because of some local policy.=C2=A0= The transition fails for whatever reason, but the cellular connection is s= till active.=C2=A0 It is the application=E2=80=99s choice
> [Roni Even] which application if there is more than one? In the TCP ca= se you stay in the cell. Here there are two options, stay on the cell with = QUIC or move to wifi on TCP
> whether it wants to wind down and close that connection and start a ne= w one using TCP, or keep using the old one if the interface remains availab= le.=C2=A0 If there are multiple applications, each application makes that c= hoice independently.
>
> And if the first interface becomes unavailable for whatever reason, th= e choice is made for it, and the application will have to recover.
>
> From: Roni Even [mailto:roni.e= ven@huawei.com]
> Sent: Wednesday, November 15, 2017 1:25 PM
> To: Mike Bishop <mbishop@ev= equefou.be>; QUIC WG <quic@ietf.= org>
> Subject: RE: connection migration
>
> So what is the connection migration flow here. The quic stack in the c= ell network will try to migrate to wifi without application request and fai= l but will not fall back to TCP.
> There may be multiple application running over quic? HTTP and peer to = peer at the same time, so who will handle this case?
>
> Roni
>
> From: Mike Bishop [mailto:mbis= hop@evequefou.be]
> Sent: =D7=99=D7=95=D7=9D =D7=93 15 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7= =A8 2017 05:35
> To: Roni Even; QUIC WG
> Subject: RE: connection migration
>
> That may well be the case, but it=E2=80=99s not the QUIC stack=E2=80= =99s choice to make.=C2=A0 The application could choose to open a new conne= ction, but that remains outside the scope of the transport and the mapping = to it which we=E2=80=99re defining.
>
> For HTTP, this is fairly straightforward =E2=80=93 it could stop issui= ng new flow control credit, let currently-in-transit data arrive and any lo= sses recovered, and open a TCP connection to issue a range request starting= at whatever data offset it hasn=E2=80=99t seen.=C2=A0 But that=E2=80=99s s= till a property of an HTTP management above the HTTP/QUIC mapping.
>
> From: QUIC [mailto:quic-bounc= es@ietf.org] On Behalf Of Roni Even
> Sent: Wednesday, November 15, 2017 11:25 AM
> To: QUIC WG <quic@ietf.org>=
> Subject: connection migration
>
> Hi,
> When moving from cell to wifi the reason may be due to cost (money or = quota). In this case the=C2=A0 user (client) may want to move to wifi even = if it will mean dropping to TCP.
>
> Roni


--f403045db63e7ad844055e109ea0-- From nobody Wed Nov 15 23:13: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 2182A12702E for ; Wed, 15 Nov 2017 23:13:31 -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, SPF_PASS=-0.001] autolearn=ham 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 swF6lDPr2_xa for ; Wed, 15 Nov 2017 23:13:29 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [IPv6:2620:10a:4005:8000:2306::c]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD7DA12421A for ; Wed, 15 Nov 2017 23:13:29 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,402,1505804400"; d="asc'?scan'208";a="228189360" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx143-out.netapp.com with ESMTP; 15 Nov 2017 23:13:29 -0800 Received: from VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 23:13:28 -0800 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS03-PRD.hq.netapp.com (10.122.105.19) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 15 Nov 2017 23:13:28 -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=GywNnohgVY37GNoB21MmZc3aa8ObCkon/dIr0M7V8Qg=; b=rID4rknJ/u8mVAbm3WWLDPQAUtyY5M5dZFmrLhFDEtGO6SxSnT8wfa7WVxZZ9ESmdkRol0gg2JkOksfY6WV4ZNPkBEjBUYmQZB/82vQW2prlp0dR8+YUTSnZpj5FTxhIqqJ1kSTo44g9nrDQ8FU7me5z0bz22EHqefCI8F2x65E= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 16 Nov 2017 07:13:27 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 07:13:26 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Remote interop days Thread-Topic: Remote interop days Thread-Index: AQHTXqpltrrh85WP+0Su7C4XtR4mtQ== Date: Thu, 16 Nov 2017 07:13:26 +0000 Message-ID: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:67c:370:128:b479:2ab3:d58a:89b0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:NCeAKEgJlK7evlR+Fa8TonTRVy6jo1UP1lYNdXKtEfbEuUBJ/D1hXDtpEkQjhdr8dn2/LVfaHVZZVtrwariqrqbNNCYClKIf24IccNEA85TVeiqrC8tltS/me2Hwr9Sfso7ryyniAu8dfMjzyckaWQYEcNYdmu+9STS70xX3WVX+T/haKGAezHpblmUPARg7AzLOACpgYFNXd6Wf7QvOKoisxk432QseMwWGJzUTGyzRhIooJtmcEgPVzstAcEwEbv4ePBO/ow+OohGhOXBVIL57es6PjHbwTHYN08onxCRnCRKGBW0QP7zEqt+Bih6bjqCBUxCCfXArbMyqYwEK6fJx/gaykWFspNO4tRysH5g=; 5:IyWwUDLS4KwC+gXwbBBeGLPq3pbFg+4KomxdMBGhAQzweHAKpTZxpqU/fqkteMtGASGg59Wqx4btsQ62vRYBIVV0P2FKDsYeIKUfMPxHMF0yBvO9cw/7Z5r+ccQW985k4KKlwC2RK1cn1YqRxm8JF56X7uZdiu1k2gNR8s2jusQ=; 24:sT/w0BbaPOXozmjWm9oTiKxN42ZwOkrG/jxZp6DfiV28MRiRJNpg0bAJRXFSckk3crDZs81TWKZUk/Lwb3KnIj5VD0CmKkgRuBZTUw2AIKA=; 7:soqs28Q574+IYG2wlaiRb5TthjH2GDMgaHbv63Mp6H+TPnac66KhA/PmnGD1wCQ3lCqK5K1fox/syQtrIs3shV3iJfjHRlSpnfW59codcM6zGrLikr42mtF1JZpLJtkHZMUJa1OUs+dwj49suT+qFnlVsSqDvkYbzTOwlkLlFaJZM28t2STssor+abCf5ptQnBa/Y3t9XTq18eJIrP86zxpukuaUYMskdWz1e0puH+h8DLgKSB0uTauT5YZtqyqH x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 10ff9105-2c3d-41ed-4a40-08d52cc1884b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3231022)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123555025)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1763; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(14454004)(99936001)(82746002)(478600001)(101416001)(36756003)(6512007)(8676002)(81156014)(86362001)(81166006)(50986999)(99286004)(316002)(6916009)(53936002)(68736007)(57306001)(83716003)(25786009)(33656002)(8936002)(2906002)(77096006)(6486002)(6506006)(6116002)(189998001)(97736004)(102836003)(6436002)(7736002)(2900100001)(3480700004)(106356001)(105586002)(3660700001)(5660300001)(305945005)(50226002)(3280700002)(7116003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.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=_61F17FEA-21EA-4A8F-8DB0-0B1173A9B8C1"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 10ff9105-2c3d-41ed-4a40-08d52cc1884b X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 07:13:26.7238 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:13:31 -0000 --Apple-Mail=_61F17FEA-21EA-4A8F-8DB0-0B1173A9B8C1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, someone brought up the idea to have more frequent remote interop days, = in addition to our in-person interop events, where implementers could = use Slack and Hangout, etc. to coordinate testing and debugging their = stacks. Designating a given day each week/fortnight/month for this might be = simpler to arrange than pairwise agreements between implementers, = because you could just show up and reasonably expect for someone to be = available who'd want to try and interop. My guess is that it'd be a 24h = thing (due to time zones). Questions to the implementers: (1) Should we try this? (2) Cadence? (3) Any suggestions/tweaks/additions? Lars --Apple-Mail=_61F17FEA-21EA-4A8F-8DB0-0B1173A9B8C1 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloNOokACgkQVLXDCb9w wVemChAAthAHOuNBhWkPX+ITF9e79BeuK/aAssJgThK/tZKyVmrEoIsfVCxvf2dW jEtXVPcO9edq+tyRALvIe3PIr9VqLhvso4nnMi1cKz3YSt6vnQqqn/AvMRDmHRFH Ga8mWk1U/wXl4Tdc4+Sno9VE0zpXPss3DTDeXB0LYnNogm6x+c+zWRUgpCaX2Lfa 5Eh/kMEbKYO03lWESbeEz0dQRDbdjcaHHV1EL//KRjZQjLOSAyYFPvF3ANJQPhO4 eQFzq6Ru+zvmkc2C4ugXyzWIseDuOHmQ7vupM1gNvT/4s2CS2yDLq9USiN0b/FdP /PQ9G1JQMtdMHYiFb9dgIgpvkBsnUGhG5l0y8clwf425pM4/ylxv4lUDD+wbnKew /ye2Il6r2R1Vb5ZqAvWEuGnJbnGhwvP4iCpBGuKgc+F2Ka4jnYus8xSVZjR7dSo2 wByidZvUFe9692eMlscMEOpnXvHp3/owzqUIyHI7QxtVa2i8i4fjf47zFvUwBMgx C77l1025Cq0GWj6f8bU8/tOCf7D6i99lCtCTNTcXQB62hgn/TPom8MUtpb3+YTaf T7dfrs5Wd5z872gc1VF1C3dityDBoQS4q+AoHk04d8NcdLPnMSbApgbe5pcFx/vo zTYjtLwZ8oQIAWH8BTidxmKL2H4OxZN2MYspxBM2aSQj3e3qel0= =u/r4 -----END PGP SIGNATURE----- --Apple-Mail=_61F17FEA-21EA-4A8F-8DB0-0B1173A9B8C1-- From nobody Wed Nov 15 23:32: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 D99A3126D73 for ; Wed, 15 Nov 2017 23:32:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o8B35k8W6tzS for ; Wed, 15 Nov 2017 23:32:32 -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 1516D120724 for ; Wed, 15 Nov 2017 23:32:32 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id r58so16480073qtc.0 for ; Wed, 15 Nov 2017 23:32: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=7Aa4mrVi3hkWda2pxQkP92TtEWW+wBU/1wk+hJSwW5Y=; b=MP+rgq2H0w3bTffMsKWPN2pgGRK3D2rtjVBlOSMv67/paja+JxYYY1NMczsqgkj603 MWJ3y23ctCdo8tZRHCrvSoF/X9qbU4PSdohLALqahMqOa0noEYnWKvdw1jtwDwNWV+Hs ClCUiQdRTi4pqkkvk9mOhS9CDxcohk8bX1eeRolG7YDl1DsOoHq+0H39wLWWAPpPjImn spTyYqsNwURibVLTJyYR8MKzSWg4l3vMYBOacYV8GzKnazgsrlplgga8Dk5nhWdecNJp BraoS1vQDCcvdU9LW0XCLoo5Cu2F/HUd8zSdzSCsEgSGhSe/zmkxiZ2GIoPo7IWMMpM9 TlLA== 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=7Aa4mrVi3hkWda2pxQkP92TtEWW+wBU/1wk+hJSwW5Y=; b=ZMCpLIRMr0VDrS/hIe4cRFwU6f9D1XLk7Vpi0AdkzYICZdlN4Jarnn40dfiH2OG1IW zvpq5bsodHcxLqUZH5XU5o/5KRkxy5Kl3hL3Qj8asRbBHVT0iUoMwsS+WOeHXCL88eFP MlNcBiQbUiprI2IcDH5b49oH6c+WQXDRxDn0rK1fRIrrr2z2XBy/gLMoBb2XmcND3Xao cNcqqQZcE+7cuId/BsNB6xkMhQ7+m8GwC6kc5rk70xj/qYKxVN9kX4w/hawGOnAKWzbS BCM8oFVxeE67Wj8Fd2VwWqJMF/Cb/SfutBMVmUrNEO7FHYUcUnHsnWgsz7hE9qm1tkFL gCoQ== X-Gm-Message-State: AJaThX76hr6w0CHxhvDGUyypdEIlmuLdpjMr2EAfKf/Uztx4WPjaDZMT Yl6BPFoCV9vXGOZV+1iniqJtbkPTWugGXovXYSM= X-Google-Smtp-Source: AGs4zMbNa02CC7l3l47uEjcrTEkE6NyWatUMDHivBdh2W6qi2/oZR6HnV9cIddVPKmOsiSv8d+6zuA+RJml6d0Rs568= X-Received: by 10.200.44.70 with SMTP id e6mr1062061qta.197.1510817551260; Wed, 15 Nov 2017 23:32:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.25.143 with HTTP; Wed, 15 Nov 2017 23:32:10 -0800 (PST) In-Reply-To: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> References: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> From: Sebastiaan Deckers Date: Thu, 16 Nov 2017 15:32:10 +0800 Message-ID: Subject: Re: Remote interop days To: "Eggert, Lars" Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a114063d276a00b055e149f72" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:32:34 -0000 --001a114063d276a00b055e149f72 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 16, 2017 at 3:13 PM, Eggert, Lars wrote: > (3) Any suggestions/tweaks/additions? > The current QUIC WG About page links [1] to a Slack instance for, apparently, the same purpose. However there is no public signup AFAICT. Would these remote interop days be public, private, or somewhere in between? 1. https://datatracker.ietf.org/wg/quic/about/#dependency_graph "Slack channels for interop/implementors; not covered by IETF Note Well" --001a114063d276a00b055e149f72 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 16, 2017 at 3:13 PM, Eggert, Lars <lars@netapp.= com> wrote:
(3) Any suggestions/tweaks/additions?

The current QUIC WG About page links [1] to a Slack inst= ance for, apparently, the same purpose. However there is no public signup A= FAICT. Would these remote interop days be public, private, or somewhere in = between?

1. https://datatracker.ietf.org/wg/quic/about/#dependency_gra= ph
=C2=A0 =C2=A0"Slack channels fo= r interop/implementors; not covered by IETF Note Well"
--001a114063d276a00b055e149f72-- From nobody Wed Nov 15 23:43: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 0B8FD1274D0 for ; Wed, 15 Nov 2017 23:43: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, HTML_MESSAGE=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=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 s0JJOnezNISk for ; Wed, 15 Nov 2017 23:43:18 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05CBE120724 for ; Wed, 15 Nov 2017 23:43:17 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,402,1505804400"; d="asc'?scan'208,217";a="222831864" Received: from hioexcmbx06-prd.hq.netapp.com ([10.122.105.39]) by mx142-out.netapp.com with ESMTP; 15 Nov 2017 23:43:17 -0800 Received: from VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) by hioexcmbx06-prd.hq.netapp.com (10.122.105.39) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 23:43:17 -0800 Received: from NAM02-SN1-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.1320.4 via Frontend Transport; Wed, 15 Nov 2017 23:43:17 -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=PXKzfWSvuY0bYr/njKhnuRKcqsL4fRrnwwH6xgos7Jg=; b=VI9LUTwv3bvbZLd5JbahnXS0myjQul/5EDCt7SDHrS0R6NiFTj7/T3Tq92m6kxCRISOLScBKTxOWJC+KRZXpdCtqvys2aH2xQW+wMR0arjlwaLD+Xk3bAHsT4PQqERCz5S28kTTQ6DnsABeu9C0DHTFDAR/8cuKZgzNsrwKBiaM= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 16 Nov 2017 07:43:14 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 07:43:14 +0000 From: "Eggert, Lars" To: Sebastiaan Deckers CC: QUIC WG Subject: Re: Remote interop days Thread-Topic: Remote interop days Thread-Index: AQHTXqpmNhsf5NWstUuSN6L6vJuwOqMWnLEAgAADCQA= Date: Thu, 16 Nov 2017 07:43:14 +0000 Message-ID: References: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:67c:370:128:b479:2ab3:d58a:89b0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:jWjVYWQ+1lxLxOUW+PjPh+lU6Fos6V+GLTNFREfWjBriels6noztG9hM2h16BBh2c1BI4BpDRjA7xjlF+a8DZvlnQ7SH9D6vg0dlHl8dnHt7gBp1qi4jEg9WZxtvZ+jgSwzICQQ7Ng/fvrtaLU9BQQ9lGgoFpIbJEdsPPsBxokPyqxRtbAwuymj09+2tda+AuWBvaPigSb+I0/KUL2e2SQPWG4PzegwZnSipg1h2T5eP5QXu54Z3UNyhLuRIx7DGlkqkq3/++GA86xGNl9J5euKKtAiEBhRRZDxGJ1ZSR27aE5vHBBWf41QHBwM5o299l2UoQOwWhvJI19HQ5tiU69LIc9PMoSVY3E66vE4jIss=; 5:wal8zcSJ8uRIOF7urJzqUChXmpKbKXe/PHuu4eZgKWU7v9A7tlv1CSa4xpM4Bg/2JS/FPXf4pjo3tePRle1vC4Fet1xZ7jWzDHUrx9QcGTKg3QfwcoRKg4IJruaU6CswLy0vaqXW1eyjErsqLxdFLIkU7BIzwKF5dfEFCxO7bJM=; 24:UwPDgUd0w3o2xHQzGWbMBr3m7Wp3NC/5okGj06B4CzI/CR2UpsutKJuh+5ZITcWxypuOj7wFqwMFj6Kp5n0fgAmpdpaXBORN1LlzQz8Gg4w=; 7:HeKgL032LsMluuI4s65jAYwTjJGIH7Pb696CF4nPX5OcnW2RUTwdNHabm7PrrncoJHSWeI9pWf5Zujbj2wu1H3AcXci54mS6LvbCRvnEkm1yigNSdwZzJU2Pj4qQnV4Ychn/Q8owZ8P9WPhHkIbguectItRe/U8vzhoPyrPmMCRAOqAU59+m/ysJNtE9fjVY7ACdBWDRuNln+Hv0OCoFonJZ+nNWceTNaNKOTrDAmOsJi8vhJji85prUtyQ1obHQ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b85e8151-5276-476e-a19f-08d52cc5b1ea x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1761; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(199003)(377424004)(189002)(24454002)(6436002)(36756003)(6506006)(606006)(6306002)(4326008)(966005)(6512007)(316002)(82746002)(102836003)(8936002)(6116002)(6486002)(105586002)(106356001)(7116003)(5660300001)(14454004)(83716003)(53546010)(25786009)(54896002)(6246003)(53936002)(236005)(2900100001)(39060400002)(229853002)(478600001)(77096006)(50986999)(76176999)(4001150100001)(97736004)(81166006)(81156014)(99936001)(33656002)(6916009)(2906002)(2950100002)(101416001)(8676002)(3660700001)(3280700002)(57306001)(50226002)(3480700004)(86362001)(189998001)(7736002)(99286004)(1411001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.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=_D79DDB7F-C02D-463D-9F64-4CCCAD8329D9"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b85e8151-5276-476e-a19f-08d52cc5b1ea X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 07:43:14.5729 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:43:20 -0000 --Apple-Mail=_D79DDB7F-C02D-463D-9F64-4CCCAD8329D9 Content-Type: multipart/alternative; boundary="Apple-Mail=_B6B69B6B-89B9-4877-9772-A02F7592B649" --Apple-Mail=_B6B69B6B-89B9-4877-9772-A02F7592B649 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-11-16, at 15:32, Sebastiaan Deckers = wrote: >=20 > On Thu, Nov 16, 2017 at 3:13 PM, Eggert, Lars > wrote: > (3) Any suggestions/tweaks/additions? >=20 > The current QUIC WG About page links [1] to a Slack instance for, = apparently, the same purpose. That is the Slack instance we would use. > However there is no public signup AFAICT. Would these remote interop = days be public, private, or somewhere in between? Please correct me if I'm wrong, but I think Slack unfortunately can be = configured for public (unconfirmed) signup. (We would do that if we = could.) The *intent* here is certainly that this Slack is public: everyone on it = can add more members, and if anyone would like to join, they should = simply email the editors or (preferred) chairs. Lars > 1. https://datatracker.ietf.org/wg/quic/about/#dependency_graph = > "Slack channels for interop/implementors; not covered by IETF Note = Well" --Apple-Mail=_B6B69B6B-89B9-4877-9772-A02F7592B649 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 2017-11-16, at 15:32, Sebastiaan Deckers <sebdeckers83@gmail.com> wrote:

On Thu, Nov 16, 2017 at 3:13 PM, = Eggert, Lars <lars@netapp.com> wrote:
(3) Any suggestions/tweaks/additions?

The current = QUIC WG About page links [1] to a Slack instance for, apparently, the = same purpose.

That is the Slack instance we would use.

However there is no public signup AFAICT. Would = these remote interop days be public, private, or somewhere in = between?

Please correct me if I'm wrong, but I think Slack = unfortunately can be configured for public (unconfirmed) signup. (We = would do that if we could.)

The = *intent* here is certainly that this Slack is public: everyone on it can = add more members, and if anyone would like to join, they should simply = email the editors or (preferred) chairs.

Lars

1. https://datatracker.ietf.org/wg/quic/about/#dependency_graph
   "Slack channels for = interop/implementors; not covered by IETF Note Well"

= --Apple-Mail=_B6B69B6B-89B9-4877-9772-A02F7592B649-- --Apple-Mail=_D79DDB7F-C02D-463D-9F64-4CCCAD8329D9 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloNQYYACgkQVLXDCb9w wVcOqw//StOCkmuuQSxtLhfSpdDOkYX+2mCbVp8v6hn86v3qtWYBon8uUGOLaNqR qorQi3pDoYIut+d/saWclCH1bPxyOzDEKmZf2glMy5kcvcHdOKp3aSLS0ErDbFHy ErP7pqyMxS5Ul0szsD7r1J3OecvtAO7wxtV2AirTdz/IkL0FvYyKxtSy3z+xtc63 sKImyROuO/ZNUDr6c5Gv2IzaQbaNLdLo4nZ0kt3V0mE7nAR/Ljtc97FBjRLTWkZH bxE8jJr4RdAzi0g/huzwJpDNlwl00LhyPBbrp/mnL/ED6YQ1KG3SMv24qC9QfpwV AsciUnm5ZRbhHLvjgFWqVa4YXgaA7wJk4wpkhAbAPcnaXLQbZEwQHsKam3NvxvJX MXguS6uvT8d2IaiW2ax8ZKNJm7SG1MHf2iLqsXU4SVQ1m7AUr5wCjB/zUSblInZ4 Ra/DzWMi0gg4xtN/HXaFhaGua/Gkqo+XP+3+Z0C9PMO0e0n+ql+HtN5CzWggm4mh 1u4D8ZklLJGgjfiQbaucREihnKvGKjRe+yD0/YIosBEq+iGLzFaRhaWsquGDN0rF dTkAQInTIjP8piROUWOIZcfwjgzO9/na1FhRkTSlCcVE0OTCr1RoFRVeYquD3nas w9BlmUFptWxkpXqxt9FCMIgH5YVTLwzg/YeitLpyAEytoKecWa8= =nbX4 -----END PGP SIGNATURE----- --Apple-Mail=_D79DDB7F-C02D-463D-9F64-4CCCAD8329D9-- From nobody Wed Nov 15 23:44: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 E3A891294A2 for ; Wed, 15 Nov 2017 23:44: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 4Isr_CTqFWGM for ; Wed, 15 Nov 2017 23:44:10 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDFA712421A for ; Wed, 15 Nov 2017 23:44:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,402,1505804400"; d="asc'?scan'208,217";a="227059987" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx144-out.netapp.com with ESMTP; 15 Nov 2017 23:44:09 -0800 Received: from VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 15 Nov 2017 23:44:09 -0800 Received: from NAM02-SN1-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.1320.4 via Frontend Transport; Wed, 15 Nov 2017 23:44:09 -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=S01lfMCFcA4KN9ixv68qa+HlRBvCsXz5yYDNWBpBskg=; b=Qi1Ed1Q3jIOF8P9JKsBke5iSOd90Dn8ab6+JGOqrkQ1H+2TWTo/KSw/2C8GVssJG2kGWakP9Pkp+OIbuJLXUhYJbmlurJ2BAT+asKPQtQF8VStvVezZ6+7ln2KEHZMdvNnk3jcknTQD+cKHhxT+wjYw4iWtXXK3rFfNFJaRBjoU= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 16 Nov 2017 07:44:07 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 07:44:06 +0000 From: "Eggert, Lars" To: Sebastiaan Deckers CC: QUIC WG Subject: Re: Remote interop days Thread-Topic: Remote interop days Thread-Index: AQHTXqpmNhsf5NWstUuSN6L6vJuwOqMWnLEAgAADCQCAAAA+AA== Date: Thu, 16 Nov 2017 07:44:06 +0000 Message-ID: References: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:67c:370:128:b479:2ab3:d58a:89b0] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:6rkUYia1J5NFLSUbEwCE/Cs4BNF1I+sbCT/zAzLeMB4aLmH8Kvbs8q6+9fYGqMbPMv/gNi+NK0dXee3FFx6NCV/pOjWOtfcILhWJJTNcKHWm7LFt7KtkD1iq1HjVQdjj7xM7PUEOiUeVXLPz7mmtjJ5J9SD1jWb1t22zOrjzmCcx2oRWj33jXouSnJdj2ArVYQA3C5Fgk6NqLPkraBtpVNo5G5xr/f3klIqntxPn9P0+CgVemTot6sGHbObWQRcFVhjEs5ROuRap+TmRMnUoCjV7Hdc8sG0MDMk1XSG3Sw75enmKbRom8BMhWAdKChIrezCu+3WIZsvrdRA/nP4qli07BYmZE9/+WLf50ehXvWQ=; 5:j2ic5t+hAiwO7Kw8yxA9tEepwxD24ZEyyogMFKcUppGpVVl2VgY/xsbKbp6kOSKevTXNXNfZEkneprEpLOoeRow61xcZ72JoSTHGsq7pxYH8f0vwH0ffTy3p7CJxwfax7DLzvCHV3hkuXaoDStv8pRWMcFSB483Xgky2hFt4Ei0=; 24:5uN+4hdFPt+CZZrtAdAyqe2y830z9F04i8Sj/GF8eFsHHd5oqVpoFBlCFxhPtJDRci0f3aoWqhzMbodHf0Xo7BqxGovXSP76uwwN5dCl3kg=; 7:RHpSCYWWq98qI3gmroPeYzE69kM6gTpeJRXcDiXn1jcUhfc1xS4o0pscpqnSwIMAZfbTmHGrHGzV97t3HwCzzY+MTEf5TohwPamtQyUIN+LeIX3Bv/atvsnhM6Xs73ALo8ujorW5StqFnC1NrZhvRMA90aXbla2HHKzSe5YI/i70OAFlpJ391GmFIXXU9lgWaQ2gEG+3RzRXWruOeNZgjqhHsdpSkbO5OO+kGHkW0YV83gyejKMFWeVNSsXL5EsB x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b6cbe26e-2030-4a7f-479f-08d52cc5d0b0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(3231022)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1761; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(199003)(377424004)(189002)(24454002)(6436002)(36756003)(6506006)(606006)(6306002)(4326008)(966005)(6512007)(316002)(82746002)(102836003)(8936002)(6116002)(6486002)(105586002)(106356001)(7116003)(5660300001)(14454004)(83716003)(53546010)(25786009)(54896002)(6246003)(53936002)(236005)(2900100001)(39060400002)(229853002)(478600001)(77096006)(50986999)(76176999)(4001150100001)(97736004)(81166006)(81156014)(99936001)(33656002)(6916009)(2906002)(2950100002)(101416001)(8676002)(3660700001)(3280700002)(57306001)(50226002)(3480700004)(86362001)(189998001)(7736002)(99286004)(1411001)(68736007); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.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=_8EF4FB8A-2EC4-464D-8830-995ACEAA2EA4"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b6cbe26e-2030-4a7f-479f-08d52cc5d0b0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 07:44:06.1842 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:44:12 -0000 --Apple-Mail=_8EF4FB8A-2EC4-464D-8830-995ACEAA2EA4 Content-Type: multipart/alternative; boundary="Apple-Mail=_0285BD17-154C-4F30-B23D-2634A9D630B2" --Apple-Mail=_0285BD17-154C-4F30-B23D-2634A9D630B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-11-16, at 15:43, Lars Eggert wrote: >=20 > On 2017-11-16, at 15:32, Sebastiaan Deckers > wrote: >>=20 >> On Thu, Nov 16, 2017 at 3:13 PM, Eggert, Lars > wrote: >> (3) Any suggestions/tweaks/additions? >>=20 >> The current QUIC WG About page links [1] to a Slack instance for, = apparently, the same purpose. >=20 > That is the Slack instance we would use. >=20 >> However there is no public signup AFAICT. Would these remote interop = days be public, private, or somewhere in between? >=20 > Please correct me if I'm wrong, but I think Slack unfortunately can be = configured for public (unconfirmed) signup. (We would do that if we = could.) unfortunately *cannot* be configured >=20 > The *intent* here is certainly that this Slack is public: everyone on = it can add more members, and if anyone would like to join, they should = simply email the editors or (preferred) chairs. >=20 > Lars >=20 >> 1. https://datatracker.ietf.org/wg/quic/about/#dependency_graph = >> "Slack channels for interop/implementors; not covered by IETF Note = Well" >=20 --Apple-Mail=_0285BD17-154C-4F30-B23D-2634A9D630B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 2017-11-16, at 15:43, Lars Eggert <lars@netapp.com> wrote:

On = 2017-11-16, at 15:32, Sebastiaan Deckers <sebdeckers83@gmail.com> wrote:

On Thu, Nov 16, 2017 at 3:13 PM, = Eggert, Lars <lars@netapp.com> wrote:
(3) Any suggestions/tweaks/additions?

The current = QUIC WG About page links [1] to a Slack instance for, apparently, the = same purpose.

That is the Slack instance we would = use.

However there is no public signup AFAICT. Would = these remote interop days be public, private, or somewhere in = between?

Please correct me if I'm = wrong, but I think Slack unfortunately can be configured for public = (unconfirmed) signup. (We would do that if we = could.)

unfortunately *cannot* be configured


The *intent* here is certainly that = this Slack is public: everyone on it can add more members, and if anyone = would like to join, they should simply email the editors or (preferred) = chairs.

Lars

1. https://datatracker.ietf.org/wg/quic/about/#dependency_graph
   "Slack channels for = interop/implementors; not covered by IETF Note Well"

= --Apple-Mail=_0285BD17-154C-4F30-B23D-2634A9D630B2-- --Apple-Mail=_8EF4FB8A-2EC4-464D-8830-995ACEAA2EA4 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloNQboACgkQVLXDCb9w wVcx5A/+J5CaodecHOq/oS92awUUQhLWuw/iQmKCKlUqY5g5caXhNocnC8KZNhtC chRWQcGVTONMHCuzjdiOIlrl1GrtRCvo9YQT32qgO3y6sejf19MPAUy/Y2Tix6xg MYjHvJVReILDcqqjqXfzL6xgRT8NsGMAOd6IbCBE/ttzHqejl6Ve1Jiup+dvtNfk m9xyTAneAuumn1sYlEb7BpSvezdKxBu7YKjSFyT3JeEviI9xtNPYtYcIGay4QZsH YB108aQvayEGb3JZkDKOMLoWwzI4bPylCz8xO00XjvyYTR8MMXExQOoKEbKQkTsU gqRCWvUVcBVqbUo1/pXje1wnKyCND1OmyS5fNFoQh21MmIcv0w5s7VX3G3GxQktD CrIS68czRvNbsh2RYPkeDs8MtAHyfky9us0sMNCY5tKlXirMl/mTH7ISLnGGb8C5 r3vy6ZWCWSqf0nspKs2uX17n23yaG8E67UBFVkvxkeICIxXAntgsiq84ZNyenx3T 2EoqzDbwdbjSRpCKn48vMuIxJeKhgVdTT77yyfbjffcfF6d9I4kkdxokf7qQZSEe MJ/IEpd9p/V/9Ay0grXWThcMf7bMuZU/Jo7tEv5SYTbRkxnrEH87dPKHO3ClTn1B 9WhElBl5uw7TlDhi1gRRutX/aW8NfTg/jt9pXjy6XNuJlOm87HM= =f81e -----END PGP SIGNATURE----- --Apple-Mail=_8EF4FB8A-2EC4-464D-8830-995ACEAA2EA4-- From nobody Thu Nov 16 00:01:01 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 B3FC2120724 for ; Thu, 16 Nov 2017 00:01:00 -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, UNPARSEABLE_RELAY=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 wwKjrVnZJl3f for ; Thu, 16 Nov 2017 00:00:58 -0800 (PST) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23EFB12947C for ; Thu, 16 Nov 2017 00:00:56 -0800 (PST) Received: by mail-it0-x233.google.com with SMTP id x28so4862145ita.0 for ; Thu, 16 Nov 2017 00:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to; bh=oZNxdmBCyZCgai7AyaMX8a0ixOvMJd4NajCwJeIlFeQ=; b=LkVHtSzE7BsO7Ykxi3/sihxEY8FePXf+uLx4tvNTVpZfa2QnUQ+zo6RFZ3CY2eCN1y D9lMdUxzShzbsmoHCFUDEwA1CtOyyxcI6LtMvhsqMbidFrD2ozB4w/M+ZO+d/J9JndYs F3MFpZJL4L75E2GvSPAkvcAa970tl7e0q2k7JJkvZ0R167FfKkirutpV7L097I1KOBAM JB81NQtg9hLjMXCIvO0ZGaX0ro84hKz2706dksGamaLoP7c9Arz0hRGeha9WZhuR7l+J dJutneyGOw6YejqPPGPsS9Gadu95ocinufc6bf2LxZHP0FLrmMkd7AU50GgL3mDtYUUg G9pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to; bh=oZNxdmBCyZCgai7AyaMX8a0ixOvMJd4NajCwJeIlFeQ=; b=ioEYYsukKK0iUpXgOHt96HbOOSHrsK0KdH/aqGznWDzCQh5t7U0N8Jsju3SjbdfA/+ tixatWTGEfRMClw/bx+VOMhdnZgfX7k74z9HBUPq+POP+HRKeq18+mYcMt6EqyGARZxp QCwukhgPv75bhqYc215dD/vKinUBk+Su3KjoM10D5XxAt9xpgWDCfUIrLVHjCdZ8kpM2 cWu3Gi3xmfTwNT/fATOpGDVPCd4ZbKAxJIl3ldZTAi63zyusP0OtLlMlRR2Cu8ltsjhT DN54VoW9yZBXLm155j/QnBzMiFH6V1z78Vw5l5Xm2Y3EvJp9LEnCgmVI3/j7DZvAWuRc 1jzQ== X-Gm-Message-State: AJaThX4mxKlkMRIc9Ukz3B2IXyoG+f/QOFwEqGKYguVWnE8TcNV6m61u fbKGy2HSdX167AW+8ppvXocF7/8Lj2cKL01urG7OWQ== X-Google-Smtp-Source: AGs4zMYw0A8TM4dwuwxWAo+e0pBUXFKRHbfAYeMhpZndhWe6tgPLdaHYR+qBxMKYmQja0g5I/+szMExbe7mXMh9M5Rs= X-Received: by 10.36.94.7 with SMTP id h7mr1306561itb.42.1510819255283; Thu, 16 Nov 2017 00:00:55 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 16 Nov 2017 09:00:54 +0100 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 16 Nov 2017 09:00:54 +0100 Message-ID: Subject: Avoidng gaps in packet numbs at connection migration To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114404ba07f397055e1505e8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:01:00 -0000 --001a114404ba07f397055e1505e8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Initial packet randomisation is being proposed removed in https://github.com/quicwg/base-drafts/issues/850 Connection migration still randomises at gap length as per transport section 7.7.1.1. This made me consider: how about resetting the packet number when the connection ID changes? Or alternatively avoiding the gap and encrypting or encoding packet numbers based on connection ID such that all packet numbers increment by one after decoding. Randomizing gaps would reveal that a migration took place on short lived connection if #850 is in effect which might or might be considered a privacy issue. Large gaps during migration also eats into the 2^64 packet space. The following considers a packet number reset (not claiming this is preferably to encoding packet numbers). By resetting the packet number and ensuring all packet numbers increment by one, it becomes practically impossible to exhaust the packet number space, thus removing the need for tearing down a connection, except if running out of stream ID=E2=80=99s. The internal packet number would then be larger than 64 bit, adding 2^64 on each migration. RTT measurements etc. would also trivially be able to avoid comparing timestamps across different connections. A major downside to this is that working with more than 64 bit packet numbers is a real pain. One workaround for this is to require connection migration after at most, say 2^48 packets and allow the high bits to roll over if there are many migrations. To prevent the off chance of an old packet getting through with the wrong packet number, AEAD could take the connection ID into account thus rejecting old packets. Due to the above downside of having a larger internal packet number space, or the complexity of working around this, I tend to prefer encoding packet numbers if feasible. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --001a114404ba07f397055e1505e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Initial packet rando= misation is being proposed removed in

Connection migration still rando= mises at gap length as per transport section 7.7.1.1.

This made me consider: how about resetting= the packet number when the connection ID changes? Or alternatively avoidin= g the gap and encrypting or encoding packet numbers based on connection ID = such that all packet numbers increment by one after decoding.

Randomizing gaps would reveal that a migration took place = on short lived connection if #850 is in effect which might or might be cons= idered a privacy issue. Large gaps during migration also eats into the 2^64= packet space.

The following considers a packet number reset (not c= laiming this is preferably to encoding packet numbers).

By resetting the packet number and ensur= ing all packet numbers increment by one, it becomes practically impossible = to exhaust the packet number space, thus removing the need for tearing down= a connection, except if running out of stream ID=E2=80=99s.

The internal packet number would = then be larger than 64 bit, adding 2^64 on each migration.

RTT measurements etc. would also triv= ially be able to avoid comparing timestamps across different connections.

A major downside to th= is is that working with more than 64 bit packet numbers is a real pain. One= workaround for this is to require connection migration after at most, say = 2^48 packets and allow the high bits to roll over if there are many migrati= ons. To prevent the off chance of an old packet getting through with the wr= ong packet number, AEAD could take the connection ID into account thus reje= cting old packets.

Du= e to the above downside of having a larger internal packet number space, or= the complexity of working around this, I tend to prefer encoding packet nu= mbers if feasible.

Kind Regards,
<= div style=3D"font-family:helvetica,arial;font-size:13px">Mikkel Fahn=C3=B8e= J=C3=B8rgensen

--001a114404ba07f397055e1505e8-- From nobody Thu Nov 16 00:15: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 5A6D7127369 for ; Thu, 16 Nov 2017 00:15:29 -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 (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 n3XzdN8ujyyI for ; Thu, 16 Nov 2017 00:15:27 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1AD0120724 for ; Thu, 16 Nov 2017 00:15:26 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id n134so858402itg.0 for ; Thu, 16 Nov 2017 00:15:26 -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=XILeK2Ehml6mje7G3YNmwq6+6iMmfLmiufnnmJNJ1cM=; b=ATnhsnxF4CfC/rutawXBUFA8/V96M6+KqMae/ePXggrSeEEbW5BJmWuEKzGzDTvPPU Gau2H9rc++Ir0QwS9GvXZarBAldFxy+/q+71yNVTz6Uh2C28reqFRbimxfd9YTzKDrTo JpVlyVm+imu4j6MhHppLCqRaZaAMvAFZLRrw6IV50xV1LBTy/ErMsdC1jng0RBU99PRZ EDnAylojES3fZU8pXA4Wk1i7I++r+5Ifa4Bpx2QWmF1Hie2QC+CbOwBsomUBckzeHimU R7ewcVNMW6LP0cvLg8C6NIXAUU4Ae2JHexVA3wgR9HtQLtN7k1Nq6n45A+CxGykb1uRT 0lGQ== 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=XILeK2Ehml6mje7G3YNmwq6+6iMmfLmiufnnmJNJ1cM=; b=eKa3LDz0390lpkDIUFp2WahOqIq42bbS+hBcJmGUeQAqYEq5nwDtWA32yLrhfU/Ylu fKsL1y14lz9sNnZbK/2nOBIbwAVOUABCYl/xBJcA1wO6IJT5QI16RX22FK/reetp/tGR BTNaB7T24n17tY7gLKcw1IWSxHE4dlP1ctCEpSpsi+TOMB+1bQTcemU8Pc844ZouGC4m x5niIjNmG63lQ0KIQiVp+43VlUiu4cXWIglN99uejd4QHgXt+E3GJ0NKkUe301AV0hH8 DlTqqKMIvBrXpHaHQPjJvzdGwiA1aeVrEF2OmEBquLPac9MyvYBqBdpa/vEJdKFDvXyo aRyg== X-Gm-Message-State: AJaThX4T2mcVmIo7bdy6mQD6+T38kC6xsbAoPiMS3yeATt8EfbbtfBHY 58RE45dllAhMvec6pkBdoZIxCE5U8eTloFkql5nEJSNmDnE= X-Google-Smtp-Source: AGs4zMbESOo6tW789gA6jMwl7H1R4oZJMkmVpWZ2e36YO1u0tRSsYXuMMc5MkJW94tXiCET7hckqE6AsQ/FwM+hhBBk= X-Received: by 10.36.145.203 with SMTP id i194mr1349368ite.73.1510820125734; Thu, 16 Nov 2017 00:15:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.101.16 with HTTP; Thu, 16 Nov 2017 00:15:05 -0800 (PST) From: Ian Swett Date: Thu, 16 Nov 2017 03:15:05 -0500 Message-ID: Subject: Moving the version 4 bytes earlier in the long header To: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0ef650ea899f055e153845" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:15:29 -0000 --94eb2c0ef650ea899f055e153845 Content-Type: text/plain; charset="UTF-8" I am very supportive of Martin's work to define QUIC invariants. It seems ideal to make the invariants as early in the packet as possible, so I'd suggest we move the 4 byte version in front of the 4 byte packet number in the long header. This is filed in Issue #926 . For reference, it is proposed the size and location of the version is an invariant, but nothing about the packet number is. Just because the packet number is before the version doesn't mean the packet number length can't change, but it does mean we're stuck with those 4 bytes in that location, which makes future changes to the packet number length very awkward. I don't anticipate future changes, but this is going to be an invariant for a very long time, so I'd like to move it now. Thanks, Ian --94eb2c0ef650ea899f055e153845 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am very supportive of Martin's work to define QUIC i= nvariants.=C2=A0=C2=A0

It seems ideal to make the invari= ants as early in the packet as possible, so I'd suggest we move the 4 b= yte version in front of the 4 byte packet number in the long header.=C2=A0 = This is filed in Issue #926.=C2=A0 For reference, it is proposed the size and locatio= n of the version is an invariant, but nothing about the packet number is.

Just because the packet number is before the versio= n doesn't mean the packet number length can't change, but it does m= ean we're stuck with those 4 bytes in that location, which makes future= changes to the packet number length very awkward.

I don't anticipate future changes, but this is going to be an invarian= t for a very long time, so I'd like to move it now.

<= /div>
Thanks, Ian
--94eb2c0ef650ea899f055e153845-- From nobody Thu Nov 16 00:37: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 A904B129A9A for ; Thu, 16 Nov 2017 00:37:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sfA6wXg0wrLR for ; Thu, 16 Nov 2017 00:37:34 -0800 (PST) Received: from orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69B1112955D for ; Thu, 16 Nov 2017 00:37:31 -0800 (PST) Received: from opfednr00.francetelecom.fr (unknown [xx.xx.xx.64]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 1E07A40D00; Thu, 16 Nov 2017 09:37:30 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfednr00.francetelecom.fr (ESMTP service) with ESMTP id DFA461A0074; Thu, 16 Nov 2017 09:37:29 +0100 (CET) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 09:37:29 +0100 From: To: Salvatore Loreto , Marcus Ihlar , Roni Even CC: Ian Swett , QUIC WG Subject: RE: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AdNdMS3xiXFl+idYSdWDiJw89tZdFwAHmowAAAE+vIAAAeNlgAABKzeAAAImHGA= Date: Thu, 16 Nov 2017 08:37:29 +0000 Message-ID: <27425_1510821450_5A0D4E49_27425_244_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7F1C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <6E58094ECC8D8344914996DAD28F1CCD836D79@DGGEMM506-MBX.china.huawei.com> <37B26B29-2193-443B-8B27-0CF68A8619CA@ericsson.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7F1C5OPEXCLILM44corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:37:36 -0000 --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7F1C5OPEXCLILM44corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 KzENCg0KRGUgOiBTYWx2YXRvcmUgTG9yZXRvIFttYWlsdG86c2FsdmF0b3JlLmxvcmV0b0Blcmlj c3Nvbi5jb21dDQpFbnZvecOpIDogbWVyY3JlZGkgMTUgbm92ZW1icmUgMjAxNyAwMDo1NA0Kw4Ag OiBNYXJjdXMgSWhsYXI7IFJvbmkgRXZlbg0KQ2MgOiBJYW4gU3dldHQ7IFFVSUMgV0c7IFNURVBI QU4gRW1pbGUgSU1UL09MTg0KT2JqZXQgOiBSRTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJsZXNo b290aW5nDQoNCisxDQpMYXRlbmN5IGlzIHRoZSBtb3N0IGNydWNpYWwgY29tcG9uZW50IG5lZWRl ZCBpbiBRdWljIHZlcnNpb24gMQ0KDQpBbHNvIGNvbnNpZGVyaW5nIHRoZSBmYWN0IHRoYXQgUVVJ QyB3aWxsIGJlIGVpdGhlciBtb3N0IGxpa2VseSBhZG9wdGVkIGluIDNHUFAgZm9yIDVHIFNCQQ0K YW5kIHRoZSBtYWpvcml0eSBvZiB0aGUgdHJhZmZpYyBpbiA1RyBuZXR3b3JrcyBRVUlDIChwZXIg R2VvcmcgTWF5ZXIgbWFpbCBvbiB0aG9zZSBwb2ludHMpDQpPcGVyYXRvcnMgd2lsbCBoYXZlIHRv IG1ha2Ugc3VyZSB0byBrZWVwIHRoZSBsYXRlbmN5IHJlYWxseSBsb3cgaW4gNUcgbmV0d29ya3Mg YW5kIHRoZXkNCndpbGwgYmUgbWVhc3VyZWQgb24gbGF0ZW5jeS4NCg0KL1NhbA0KDQpGcm9tOiBR VUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyY3VzIElo bGFyDQpTZW50OiBkZW4gMTQgbm92ZW1iZXIgMjAxNyAxNzoyMQ0KVG86IFJvbmkgRXZlbiA8cm9u aS5ldmVuQGh1YXdlaS5jb208bWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tPj4NCkNjOiBJYW4g U3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+Pjsg UVVJQyBXRyA8cXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+OyBlbWlsZS5zdGVw aGFuQG9yYW5nZS5jb208bWFpbHRvOmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbT4NClN1YmplY3Q6 IFJlOiBzcGluIGJpdCBpbiBRVUlDOiB0cm91Ymxlc2hvb3RpbmcNCg0KKzEgb24gUm9uaXMgc3Rh dGVtZW50IGJlbG93Lg0KTGV0IHVzIGJlZ2luIHdpdGggbGF0ZW5jeSwgd2hpY2ggaXMgdGhlIG1v c3QgY3J1Y2lhbCBjb21wb25lbnQgdG8gaGF2ZSBpbiBwbGFjZS4NCkFzIFYxIGdldHMgZGVwbG95 ZWQgd2Ugd2lsbCBnZXQgYSBiZXR0ZXIgdW5kZXJzdGFuZGluZyBvZiB3aGF0IGVsc2UgbWlnaHQg YmUgbmVlZGVkLg0KDQpPbiAxNCBOb3YgMjAxNywgYXQgMjM6MjcsIFJvbmkgRXZlbiA8cm9uaS5l dmVuQGh1YXdlaS5jb208bWFpbHRvOnJvbmkuZXZlbkBodWF3ZWkuY29tPj4gd3JvdGU6DQpJIHRo aW5rIHRoYXQgbGF0ZW5jeSBpcyB3aGF0IHdlIG5lZWQgcmlnaHQgbm93Lg0KT25jZSB3ZSB1bmRl cnN0YW5kIG1vcmUgYWJvdXQgcXVpYyBhbmQgcGFja2V0IGxvc3MgKHdpbGwgRUNOIGJlIHVzZWQg cmVkdWNpbmcgcGFja2V0IGxvc3MpIGFuZCBvdGhlciBmdW5jdGlvbmFsaXR5IHdlIGNhbiBzZWUg d2hhdCBlbHNlIGlzIG5lZWRlZC4gVGhpcyBtYXkgYmUgZG9uZSBpbiBuZXh0IHZlcnNpb24gdXNp bmcgdmFyaWFudHMuDQpSb25pDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBJYW4gU3dldHQNClNlbnQ6INeZ15XXnSDXkiAxNCDXoNeV15HX nteR16ggMjAxNyAxNjo1MQ0KVG86IGVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbTxtYWlsdG86ZW1p bGUuc3RlcGhhbkBvcmFuZ2UuY29tPg0KQ2M6IFFVSUMgV0cNClN1YmplY3Q6IFJlOiBzcGluIGJp dCBpbiBRVUlDOiB0cm91Ymxlc2hvb3RpbmcNCg0KV2hhdCB3b3VsZCB0aGUgb3RoZXIgYml0IG9y IHR3byBiZSB1c2VkIGZvcj8gIElmIHRoZXJlIGlzIG5vIHN0YW5kYXJkaXplZCB1c2Ugb2YgdGhv c2UgYml0cyBpbiB2MSwgdGhlbiBJIGJlbGlldmUgd2Ugc2hvdWxkIHdhaXQgdG8gcmVzZXJ2ZSB0 aGVtIHdoZW4gdGhlaXIgdXNhZ2UgaXMgZGVmaW5lZCwgZ2l2ZW4gd2UnZCBuZWVkIGEgdmVyc2lv biBidW1wIHRvIHNwZWNpZnkgaG93IHRoZXkgd2VyZSBiZWluZyB1c2VkLiAgQXQgdGhlIG1vbWVu dCwgdGhlIG1hbmFnZW1lbnQgdXNlIGNhc2UgaXMgbm90IGNvbXBldGluZyB3aXRoIGFueW9uZSBl bHNlIGZvciBiaXRzIGluIHRoZSBzaG9ydCBoZWFkZXIuDQoNCk9uIFR1ZSwgTm92IDE0LCAyMDE3 IGF0IDU6MTQgQU0sIDxlbWlsZS5zdGVwaGFuQG9yYW5nZS5jb208bWFpbHRvOmVtaWxlLnN0ZXBo YW5Ab3JhbmdlLmNvbT4+IHdyb3RlOg0KSGkNCg0KTGFzdCB3ZWVrIE9yYW5nZSBleHBlcmllbmNl ZCBhIGZhbGxiYWNrIG9mIFFVSUMgdG8gVENQIG9uIG9uZSBvZiBpdHMgbmV0d29ya3MuIFRoZSBp c3N1ZXMgd2VyZSBub3QgdmlzaWJsZSBpbiBRVUlDIHRyYWZmaWMuIFRoZSB0cm91Ymxlc2hvb3Rp bmcgd2FzIG1hZGUgdXNpbmcgVENQIHBhY2tldHMgaW5mb3JtYXRpb24uIFRoaXMgaXMgbm90IHN1 c3RhaW5hYmxlIG9uIHRoZSBsb25nIHRlcm0gd2hlbiBudW1lcm91cyBhcHBsaWNhdGlvbnMgdXNp bmcgZGlmZmVyZW50IHZlcnNpb25zIG9mIFFVSUMgd2lsbCBzdG9wIHRvIGZhbGxiYWNrIHRvIFRD UC4NCg0KQmFzZWQgb24gdGhlIGV4Y2hhbmdlIHdlIGhhZCBpbiB0aGUgUlRUIGRlc2lnbiB0ZWFt IGFuZCBpbiB0b2RheSBtZWV0aW5nICwgaXQgc291bmRzIHJlYXNvbmFibGUgdG8gcmVzZXJ2ZSBh dCBsZWFzdCAyIGJpdHMgKGlkZWFsbHkgMyBiaXRzIGFzIGRpc2N1c3NlZCBpbiB0aGUgZGVzaWdu IHRlYW0pIGZvciBtYW5hZ2VhYmlsaXR5IGluIHRoZSBRVUlDIGludmFyaWFudHMgYW5kIHRvIHN0 YXJ0IGV4cGVyaW1lbnRpbmcgdGhlIHNwaW4gYml0IGluIFFVSUMgVjEuDQoNClJlZ2FyZHMNCkVt aWxlDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQoNCg0KQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMg cGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2 aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jDQoNCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0 ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNz YWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyDQoNCmEgbCdleHBlZGl0ZXVyIGV0 IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBl bGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sDQoNCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4NCg0KDQoNClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0 dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0 aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7DQoNCnRoZXkgc2hvdWxkIG5vdCBiZSBk aXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLg0KDQpJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBz ZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4NCg0KQXMg ZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMg dGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLg0KDQpUaGFuayB5 b3UuDQoNCgpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KCg== --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7F1C5OPEXCLILM44corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5IDIg MiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNv Tm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAw MXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIs InNlcmlmIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQcsOpZm9ybWF0w6kgSFRNTCBD YXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIENhciI7DQoJbWFyZ2luOjBjbTsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEi LCJzYW5zLXNlcmlmIjt9DQpzcGFuLlByZm9ybWF0SFRNTENhcg0KCXttc28tc3R5bGUtbmFtZToi UHLDqWZvcm1hdMOpIEhUTUwgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0 eWxlLWxpbms6IlByw6lmb3JtYXTDqSBIVE1MIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0K cC5IVE1MUHJlZm9ybWF0dGVkLCBsaS5IVE1MUHJlZm9ybWF0dGVkLCBkaXYuSFRNTFByZWZvcm1h dHRlZA0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCW1zby1zdHlsZS1s aW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUt bmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29s YXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCnNwYW4u RW1haWxTdHlsZTIzDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLlRleHRlZGVi dWxsZXNDYXINCgl7bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglm b250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjYNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiI7DQoJY29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBw dCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAy NiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+ DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5n PSJGUiIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiYjNDM7MTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBTYWx2YXRvcmUgTG9yZXRvIFttYWlsdG86c2FsdmF0b3JlLmxvcmV0b0Blcmljc3Nvbi5j b21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gbWVyY3JlZGkgMTUgbm92ZW1icmUgMjAx NyAwMDo1NDxicj4NCjxiPsOAJm5ic3A7OjwvYj4gTWFyY3VzIElobGFyOyBSb25pIEV2ZW48YnI+ DQo8Yj5DYyZuYnNwOzo8L2I+IElhbiBTd2V0dDsgUVVJQyBXRzsgU1RFUEhBTiBFbWlsZSBJTVQv T0xOPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSRTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJs ZXNob290aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+JiM0MzsxPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+TGF0ZW5jeSBpcyB0aGUgbW9zdCBjcnVjaWFsIGNvbXBvbmVu dCBuZWVkZWQgaW4gUXVpYyB2ZXJzaW9uIDE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBs YW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5BbHNvIGNvbnNpZGVyaW5nIHRoZSBm YWN0IHRoYXQgUVVJQyB3aWxsIGJlIGVpdGhlciBtb3N0IGxpa2VseSBhZG9wdGVkIGluIDNHUFAg Zm9yIDVHIFNCQTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPmFuZCB0aGUgbWFqb3JpdHkg b2YgdGhlIHRyYWZmaWMgaW4gNUcgbmV0d29ya3MgUVVJQyAocGVyIEdlb3JnIE1heWVyIG1haWwg b24gdGhvc2UgcG9pbnRzKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPk9wZXJhdG9ycyB3 aWxsIGhhdmUgdG8gbWFrZSBzdXJlIHRvIGtlZXAgdGhlIGxhdGVuY3kgcmVhbGx5IGxvdyBpbiA1 RyBuZXR3b3JrcyBhbmQgdGhleTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPndpbGwgYmUg bWVhc3VyZWQgb24gbGF0ZW5jeS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4vU2FsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZyI+bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhh bGYgT2YgPC9iPk1hcmN1cyBJaGxhcjxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMTQgbm92ZW1iZXIg MjAxNyAxNzoyMTxicj4NCjxiPlRvOjwvYj4gUm9uaSBFdmVuICZsdDs8YSBocmVmPSJtYWlsdG86 cm9uaS5ldmVuQGh1YXdlaS5jb20iPnJvbmkuZXZlbkBodWF3ZWkuY29tPC9hPiZndDs8YnI+DQo8 Yj5DYzo8L2I+IElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5j b20iPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+Jmd0OzsgUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFp bHRvOnF1aWNAaWV0Zi5vcmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0OzsNCjxhIGhyZWY9Im1haWx0 bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20iPmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbTwvYT48 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVzaG9vdGlu ZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPiYjNDM7MSBvbiBSb25pcyBzdGF0 ZW1lbnQgYmVsb3cuJm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5MZXQgdXMgYmVnaW4gd2l0aCBsYXRlbmN5LCB3aGlj aCBpcyB0aGUgbW9zdCBjcnVjaWFsIGNvbXBvbmVudCB0byBoYXZlIGluIHBsYWNlLiZuYnNwOzxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5BcyBWMSBnZXRzIGRlcGxveWVkIHdlIHdpbGwgZ2V0IGEgYmV0 dGVyIHVuZGVyc3RhbmRpbmcgb2Ygd2hhdCBlbHNlIG1pZ2h0IGJlIG5lZWRlZC4mbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJy Pg0KT24gMTQgTm92IDIwMTcsIGF0IDIzOjI3LCBSb25pIEV2ZW4gJmx0OzxhIGhyZWY9Im1haWx0 bzpyb25pLmV2ZW5AaHVhd2VpLmNvbSI+cm9uaS5ldmVuQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90 ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB0aGluayB0aGF0IGxhdGVuY3kgaXMgd2hhdCB3ZSBuZWVkIHJpZ2h0IG5vdy48L3Nw YW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6 IzFGNDk3RCI+T25jZSB3ZSB1bmRlcnN0YW5kIG1vcmUgYWJvdXQgcXVpYyBhbmQgcGFja2V0IGxv c3MgKHdpbGwgRUNOIGJlIHVzZWQgcmVkdWNpbmcgcGFja2V0IGxvc3MpIGFuZCBvdGhlciBmdW5j dGlvbmFsaXR5IHdlIGNhbiBzZWUgd2hhdCBlbHNlIGlzIG5lZWRlZC4NCiBUaGlzIG1heSBiZSBk b25lIGluIG5leHQgdmVyc2lvbiB1c2luZyB2YXJpYW50cy48L3NwYW4+PHNwYW4gbGFuZz0iRU4t VVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9uaTwvc3Bh bj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij4gUVVJQyBbPGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZyI+bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2Yg PC9iPklhbiBTd2V0dDxicj4NCjxiPlNlbnQ6PC9iPiA8L3NwYW4+PHNwYW4gbGFuZz0iSEUiIGRp cj0iUlRMIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+15nXldedJm5ic3A715IgMTQg16DXldeR157X kdeoIDIwMTcgMTY6NTE8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7Ij48YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5n ZS5jb20iPmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbTwvYT48YnI+DQo8Yj5DYzo8L2I+IFFVSUMg V0c8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IHNwaW4gYml0IGluIFFVSUM6IHRyb3VibGVzaG9v dGluZzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPldoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0d28gYmUgdXNlZCBm b3I/Jm5ic3A7IElmIHRoZXJlIGlzIG5vIHN0YW5kYXJkaXplZCB1c2Ugb2YgdGhvc2UgYml0cyBp biB2MSwgdGhlbiBJIGJlbGlldmUgd2Ugc2hvdWxkIHdhaXQgdG8gcmVzZXJ2ZSB0aGVtIHdoZW4g dGhlaXIgdXNhZ2UgaXMgZGVmaW5lZCwgZ2l2ZW4gd2UnZCBuZWVkIGEgdmVyc2lvbiBidW1wIHRv IHNwZWNpZnkgaG93DQogdGhleSB3ZXJlIGJlaW5nIHVzZWQuJm5ic3A7IEF0IHRoZSBtb21lbnQs IHRoZSBtYW5hZ2VtZW50IHVzZSBjYXNlIGlzIG5vdCBjb21wZXRpbmcgd2l0aCBhbnlvbmUgZWxz ZSBmb3IgYml0cyBpbiB0aGUgc2hvcnQgaGVhZGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPk9uIFR1ZSwgTm92IDE0LCAyMDE3IGF0IDU6MTQgQU0sICZsdDs8YSBo cmVmPSJtYWlsdG86ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZW1p bGUuc3RlcGhhbkBvcmFuZ2UuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPkhpPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+TGFzdCB3ZWVrIE9yYW5nZSBl eHBlcmllbmNlZCBhIGZhbGxiYWNrIG9mIFFVSUMgdG8gVENQIG9uIG9uZSBvZiBpdHMgbmV0d29y a3MuIFRoZSBpc3N1ZXMNCiB3ZXJlIG5vdCB2aXNpYmxlIGluIFFVSUMgdHJhZmZpYy4gVGhlIHRy b3VibGVzaG9vdGluZyB3YXMgbWFkZSB1c2luZyBUQ1AgcGFja2V0cyBpbmZvcm1hdGlvbi4gVGhp cyBpcyBub3Qgc3VzdGFpbmFibGUgb24gdGhlIGxvbmcgdGVybSB3aGVuIG51bWVyb3VzIGFwcGxp Y2F0aW9ucyB1c2luZyBkaWZmZXJlbnQgdmVyc2lvbnMgb2YgUVVJQyB3aWxsIHN0b3AgdG8gZmFs bGJhY2sgdG8gVENQLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5CYXNlZCBvbiB0aGUgZXhj aGFuZ2Ugd2UgaGFkIGluIHRoZSBSVFQgZGVzaWduIHRlYW0gYW5kIGluIHRvZGF5IG1lZXRpbmcg LCBpdCBzb3VuZHMgcmVhc29uYWJsZQ0KIHRvIHJlc2VydmUgYXQgbGVhc3QgMiBiaXRzIChpZGVh bGx5IDMgYml0cyBhcyBkaXNjdXNzZWQgaW4gdGhlIGRlc2lnbiB0ZWFtKSBmb3IgbWFuYWdlYWJp bGl0eSBpbiB0aGUgUVVJQyBpbnZhcmlhbnRzIGFuZCB0byBzdGFydCBleHBlcmltZW50aW5nIHRo ZSBzcGluIGJpdCBpbiBRVUlDIFYxLjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxz cGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5SZWdhcmRz PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj5FbWlsZTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyI+Jm5ic3A7 PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cHJlPl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPiZuYnNwOzxzcGFuIGxhbmc9IkVO LVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+Q2UgbWVzc2FnZSBldCBzZXMgcGll Y2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGll bGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jPHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT5wYXMgZXRyZSBkaWZmdXNlcywgZXhwbG9p dGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6IHJlY3UgY2UgbWVz c2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+YSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVp cmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1 ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiw8c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPiZu YnNwOzxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+VGhp cyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9y IHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzs8c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPnRoZXkgc2hvdWxk IG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9u LjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+SWYgeW91 IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2Vu ZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuPHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT5BcyBlbWFpbHMgbWF5IGJl IGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVl biBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuPHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZT5UaGFuayB5b3UuPHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPFBSRT5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmly IGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBk b2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1 aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVl IGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3Vz Y2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxp dGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNp LgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxh dzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0 IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Is IHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRz IGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlh YmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxz aWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7F1C5OPEXCLILM44corp_-- From nobody Thu Nov 16 00:39: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 C7C71127A91 for ; Thu, 16 Nov 2017 00:39:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6jMXthvqy6md for ; Thu, 16 Nov 2017 00:39:01 -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 21FF2126BFD for ; Thu, 16 Nov 2017 00:39:01 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id r39so24425950qtr.13 for ; Thu, 16 Nov 2017 00:39: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=Y8qtQY+hRqrA/bZkzbj+e/99Q/oekQWAmu0pQMfPFcY=; b=Asm5IjiMs+hN9noOKNg9eYrBN5CBnKy2CuHfR0pKBDmKNWCOi45lAFZwAamV1zlODx QTHuHJ6Vax403KWtE9kaf+SO3N6QI9h866bpXUpiPakeFtf3M74WGY1D9SMvYCrcb9Pd zmCkxPgYoQGXYRZ9UOC913v+B4a9zxwKQKJR8W0FtUkLvwrmJsAGDQGiX0983qSyEH3/ ltoA2Z0fImyBKq14m9FHVV0nk6M3czyHHEHIPs6/Z/qwKaEocKsNbqRSDYEwLyv030oR I1Ot8+a4DRkd9B4M6cCi40mve9oOf6iGkqoz+FmNnneEMOn8W85jBcnc8rbo58qO7neL nbGQ== 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=Y8qtQY+hRqrA/bZkzbj+e/99Q/oekQWAmu0pQMfPFcY=; b=cZ98/o3ztpMu75uYDevN90EANQ+S+CJmioLtlYt0eJ9+ZXLy61Auoh2ZpbdL5Ltm+n eWuKp2VThkFM9tGDNw6600Qu6tc2FUW1g2yrkHrtkou4VdSockTGAWHto5WOuQlo6A/E cYgV6gRdxLSqEn34fyXgqgPhZDHCiQbwvdU5WeCKrW8tsjvxbTGODhV00TZIAMDuxzJh 2+BKnT6vQh/FmM5N1GY/pzC/fo3DXZyeRR8JLrFCpSInKIthGWIZeB4J7Vbw3MG5+9rQ 8UN2NGFaewwSY3+aPGKG1W36ZysrGWE0lJpKpgTFeGwbhvAJBQrCsJhQwb3iNuvVaftC gp1A== X-Gm-Message-State: AJaThX4fgggOeupLMZIzcEOs9hYp1ebtlLK7mZXPU9rA/baDyQ5c24NS YmAKm7VDXtHuAFMC2TgvyMaQWmvpiZhg5EMP22I= X-Google-Smtp-Source: AGs4zMZcF6muFDyAePGVLw3l224TAqgF0RgpJYldPoLwc+Whch3pXx3dC1rqfqOKhToFw/JyjS1cl2z+6Eq0XjUMtZU= X-Received: by 10.55.214.133 with SMTP id p5mr1206008qkl.212.1510821540339; Thu, 16 Nov 2017 00:39:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.25.143 with HTTP; Thu, 16 Nov 2017 00:38:39 -0800 (PST) In-Reply-To: References: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> From: Sebastiaan Deckers Date: Thu, 16 Nov 2017 16:38:39 +0800 Message-ID: Subject: Re: Remote interop days To: "Eggert, Lars" Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a114797b03b2500055e158d40" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:39:08 -0000 --001a114797b03b2500055e158d40 Content-Type: text/plain; charset="UTF-8" On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars wrote: > I think Slack unfortunately cannot be configured for public (unconfirmed) > signup. (We would do that if we could.) Suggestions (in no particular order nor exhaustive): - https://github.com/outsideris/slack-invite-automation - https://github.com/rauchg/slackin - https://publicslack.com --001a114797b03b2500055e158d40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars <lars@netapp.= com> wrote:
I think Slack unfortunately cannot be configured f= or public (unconfirmed) signup. (We would do that if we could.)

Suggestions (in no particular order nor exhaustive):<= div>- https://github.com/rauc= hg/slackin
--001a114797b03b2500055e158d40-- From nobody Thu Nov 16 00:43: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 6D901127369 for ; Thu, 16 Nov 2017 00:43:41 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZU0gWoX_Qll9 for ; Thu, 16 Nov 2017 00:43:39 -0800 (PST) Received: from mailout-taastrup.gigahost.dk (mailout-taastrup.gigahost.dk [46.183.139.199]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F26126BFD for ; Thu, 16 Nov 2017 00:43:39 -0800 (PST) Received: from mailout.gigahost.dk (mailout.gigahost.dk [89.186.169.112]) by mailout-taastrup.gigahost.dk (Postfix) with ESMTP id 9D06E84919D for ; Thu, 16 Nov 2017 08:43:37 +0000 (UTC) Received: from smtp.gigahost.dk (smtp.gigahost.dk [89.186.169.109]) by mailout.gigahost.dk (Postfix) with ESMTP id 80791DD719A for ; Thu, 16 Nov 2017 08:43:37 +0000 (UTC) Received: by smtp.gigahost.dk (Postfix, from userid 1000) id 777D12721987; Thu, 16 Nov 2017 08:43:37 +0000 (UTC) X-Screener-Id: f8b5956341cafa01bc0fc2c7b7d4a245e1dff3de Received: from [10.10.138.125] (unknown [77.243.62.138]) by smtp.gigahost.dk (Postfix) with ESMTPSA id 538AE27214A1 for ; Thu, 16 Nov 2017 08:43:37 +0000 (UTC) Subject: Re: Remote interop days To: quic@ietf.org References: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> From: "Morten V. Pedersen" Message-ID: <868b3587-79c3-330b-641c-aee849f115c7@steinwurf.com> Date: Thu, 16 Nov 2017 09:43:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------C85314978C3C494201028950" Content-Language: en-US Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:43:41 -0000 This is a multi-part message in MIME format. --------------C85314978C3C494201028950 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit You may also consider: https://zulipchat.com/ Fee and open source. - M On 11/16/2017 09:38 AM, Sebastiaan Deckers wrote: > On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars > wrote: > > I think Slack unfortunately cannot be configured for public > (unconfirmed) signup. (We would do that if we could.) > > > Suggestions (in no particular order nor exhaustive): > - https://github.com/outsideris/slack-invite-automation > - https://github.com/rauchg/slackin > - https://publicslack.com --------------C85314978C3C494201028950 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit You may also consider: https://zulipchat.com/
Fee and open source.

- M

On 11/16/2017 09:38 AM, Sebastiaan Deckers wrote:
On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars <lars@netapp.com> wrote:
I think Slack unfortunately cannot be configured for public (unconfirmed) signup. (We would do that if we could.)

Suggestions (in no particular order nor exhaustive):

--------------C85314978C3C494201028950-- From nobody Thu Nov 16 00:56: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 49AE3124217 for ; Thu, 16 Nov 2017 00:56:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.234 X-Spam-Level: X-Spam-Status: No, score=-1.234 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 4nCX63e83G4U for ; Thu, 16 Nov 2017 00:56:02 -0800 (PST) Received: from linode64.ducksong.com (www.ducksong.com [192.155.95.102]) by ietfa.amsl.com (Postfix) with ESMTP id 0669E1200CF for ; Thu, 16 Nov 2017 00:56:01 -0800 (PST) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id 57A723A0E6 for ; Thu, 16 Nov 2017 03:56:01 -0500 (EST) Received: by mail-lf0-f50.google.com with SMTP id f125so29229972lff.4 for ; Thu, 16 Nov 2017 00:56:01 -0800 (PST) X-Gm-Message-State: AJaThX7OjbfuQ0GPfJPw3Dx+ShDUDPY+oB3LOo0RxljJVICNMOSaT9SF rqGownAfNiOO6FqaQMMTnmBcrPfYzEQZMK5xV/Y= X-Google-Smtp-Source: AGs4zMa8+0/Fb2uh69ZOr8sqUR9TSW0KsZ4UfchAVCvzmXmaoajFIB/LJSE8bg78RKB6s//jY5IkrgiRzb4eDj0flPQ= X-Received: by 10.25.23.165 with SMTP id 37mr308667lfx.127.1510822559977; Thu, 16 Nov 2017 00:55:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.151.9 with HTTP; Thu, 16 Nov 2017 00:55:59 -0800 (PST) In-Reply-To: <868b3587-79c3-330b-641c-aee849f115c7@steinwurf.com> References: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> <868b3587-79c3-330b-641c-aee849f115c7@steinwurf.com> From: Patrick McManus Date: Thu, 16 Nov 2017 16:55:59 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Remote interop days To: "Morten V. Pedersen" Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11401a040198c9055e15ca34" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:56:04 -0000 --001a11401a040198c9055e15ca34 Content-Type: text/plain; charset="UTF-8" if anyone in this thread would like a slack signup, just mail me (or just about anyone else on the list :)) - happy to oblige. On Thu, Nov 16, 2017 at 4:43 PM, Morten V. Pedersen wrote: > You may also consider: https://zulipchat.com/ > Fee and open source. > > - M > > > On 11/16/2017 09:38 AM, Sebastiaan Deckers wrote: > > On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars wrote: > >> I think Slack unfortunately cannot be configured for public (unconfirmed) >> signup. (We would do that if we could.) > > > Suggestions (in no particular order nor exhaustive): > - https://github.com/outsideris/slack-invite-automation > - https://github.com/rauchg/slackin > - https://publicslack.com > > > --001a11401a040198c9055e15ca34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
if anyone in this thread would like a slack signup, j= ust mail me (or just about anyone else on the list :)) - happy to oblige.


On Thu, Nov 16, 2017 at 4:43 PM, Morten V. Pedersen <morten@ste= inwurf.com> wrote:
=20 =20 =20
You may also consider: https://zulipcha= t.com/
Fee and open source.

- M


On 11/16/2017 09:3= 8 AM, Sebastiaan Deckers wrote:
On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars <lars@n= etapp.com> wrote:
I think Slack unfortunately cannot be configured for public (unconfirmed) signup. (We would do that if we could.)

Suggestions (in no particular order nor exhaustive):


--001a11401a040198c9055e15ca34-- From nobody Thu Nov 16 01:09: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 D041C128B8D for ; Thu, 16 Nov 2017 01:09:48 -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=tessares-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPw7647D-AdX for ; Thu, 16 Nov 2017 01:09:46 -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 0760E127275 for ; Thu, 16 Nov 2017 01:09:45 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id 9so7989445wme.4 for ; Thu, 16 Nov 2017 01:09:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=PCc+lMY1jva5Z5LNpuCUaDFA70zlBY/L/xEyhPB0+Kg=; b=C7lRI89panYH6UVvAhE278cGzH8+aCDB6G+LK+ls5S0/wGX4XoUj2hdJ8BItn+QroO JINJLVNjRlwctNSmh7bgPIhSaJBD/OdjL8sBht/ovmx5vvCChrKP2olTlgjgzgjUihNT rsonKGPSKFrsmvP2qWYL1WXAi2HixXXOhkJe5H4AjIBL3XKaw/k/6+oC1dlgTqsm7jqs gLKuq2fQLlHXMr0xKS6UrrTrXuz3TQcxw1Q8cY4ljg71c6816av/1AdiEQlsH/W5GIgC lP65H8tzrclLrkrv0zGWDloZU6zsE0/LnLunrR4DMjnS2RO2TNdYF9IKfwR6G0Rgyt3S D/ag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=PCc+lMY1jva5Z5LNpuCUaDFA70zlBY/L/xEyhPB0+Kg=; b=hcSwwZPuMWHISvl6b1R54+v9f0ON1rjUTccW1ZvTquEKtay4gmLiY8VA+bsABDVVAR Ad0yuaXJb19JbKrIbxaHNdrBqEN9vUIf5Fak7Ma3PFuhTG09KXVZ8DyKALhQxcErsfwm /hCd+T6xEs/3Gl8ph/I6Z7MuYzqsykuZv+XLLSAODi184oP538Oeitg/o79oyPUru/i1 bbHwFwH4gEC0SEnywd0k8sojKv3NaVoWnxjpVDH3rJ6ualxS+m4rtSWoOndqkAd7tDNv 85hEPpNNyZVOc6GKHxRgJVIcMpxS3nkduhYBNY9KRXlpsTlqE4naKsx6M6qXsLBeQHKo 1y5g== X-Gm-Message-State: AJaThX7u4UiuPTfm7u/VbwZCSElDPgi0xQXOW4fdnOSEJX7cmJoqGx44 iO4iKBxR0Q9I8w7erfUp3ch+JXnjl1QyxhFmiLY2WBNKKDAJPZawzK6/uQUIRjX9YDOrT4Da X-Google-Smtp-Source: AGs4zMYsM9t+4/bEe3ppP+uX3S2csjZdTQ6iwuJZ+YJ8yl16AyG6tMaKuGi9ZlGgGgRup0o6GEfjFQ== X-Received: by 10.80.212.133 with SMTP id s5mr1791642edi.286.1510823384387; Thu, 16 Nov 2017 01:09:44 -0800 (PST) Received: from mbpobo.local ([130.104.228.107]) by smtp.gmail.com with ESMTPSA id z1sm756756edz.17.2017.11.16.01.09.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 16 Nov 2017 01:09:43 -0800 (PST) Subject: Re: connection migration To: Spencer Dawkins at IETF , "Lubashev, Igor" Cc: Jana Iyengar , Roni Even , QUIC WG , Mike Bishop , Quentin De Coninck References: <6E58094ECC8D8344914996DAD28F1CCD836EFA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD83701D@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837112@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8371EA@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD837234@DGGEMM506-MBX.china.huawei.com> <55a2d469c30d4ba58c55c328defd2872@usma1ex-dag1mb5.msg.corp.akamai.com> From: Olivier Bonaventure Message-ID: Date: Thu, 16 Nov 2017 10:08:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: quoted-printable Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:09:49 -0000 Spencer, >=20 > On Wed, Nov 15, 2017 at 11:43 PM, Lubashev, Igor > wrote: >=20 > Roni, if an application decides to switch from QUIC to TCP, there > will be no connection migration.=C2=A0 The application will have to > establish a new connection over TCP, likely, renegotiate crypto, and > whatever QUIC streams were in progress will not just migrate and > continue over TCP somehow.=C2=A0 Seamless connection migration betwee= n > QUIC and TCP is certainly outside of the charter. >=20 >=20 > It's probably good for me to say that as I understand it, migration, and= =20 > especially migration between transport protocols, is a session protocol= =20 > thing, and we really don't have a session protocol level in the=20 > Internet. We rely on applications making decisions like this, rather=20 > than trying to make decisions lower in the stack for the application. >=20 > When we have MP-TCP, as I understand it, TCP itself barely changes, so=20 > that's less true, but it's still close. >=20 > I rely on working groups to make informed decisions about stuff like=20 > this, but I wouldn't be surprised to see an MP-QUIC to be look sort of=20 > like MP-TCP, when the working group starts making decisions about=20 > multi-path. >=20 > And I see migration as roughly multipath when an application uses one=20 > path at a time, at the 10,000-meter level. I totally agree with you. Connection migration as it is currently=20 discussed in the QUIC documents focuses on a narrow subset of the real=20 problem. Connection migration works well in the case of NAT rebinding or=20 when there is an explicit move from one IP address to another. In=20 practice, there are many situations where a endhost cannot know whether=20 it should use interface A or interface B. On wireless devices such as=20 smartphones interfaces are not either up or down. When a host moves,=20 when one of its interfaces moves from the up state to the down state,=20 there is a period during which it is partially up (e.g. it works but=20 with a very high latency due to link layer retransmissions or many=20 losses). Experience with Multipath TCP has shown that to cope perfectly=20 with those situations that are frequent with mobile hosts, it is=20 important to be able to use the multipath capabilities to transmit over=20 two paths simultaneously. We have already proposed a Multipath extension to QUIC that allows to=20 cope with those problems. In Prague, Multipath QUIC was on the agenda=20 but there was no time to present it : https://datatracker.ietf.org/doc/slides-99-quic-sessb-first-experiments-wit= h-multipath-quic/ We have improved the design and documented it in an internet draft that=20 was announced on the list : https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/ This solution is implemented and works well. More details are available=20 in a forthcoming paper : Q. De Coninck, O. Bonaventure, Multipath QUIC: Design and Evaluation",=20 to be presented the 13th International Conference on emerging Networking=20 EXperiments and Technologies (CoNEXT 2017). a preprint is available from http://multipath-quic.org code will be available after the presentation from the same website As the working group is focusing on basic v1 features we did not request=20 specific slots to present this approach, but I would encourage the=20 working group to think beyond connection migration and consider=20 multipath capabilities as a much desireable objective. Olivier --=20 We will be moving on November 15th, 2017. Please update your records with= =20 our new address.=20 1 Avenue Jean Monnet, 1348 Louvain-la-Neuve, Belgium --=20 ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the system manager.= =20 This message contains confidential information and is intended only for the= =20 individual named. If you are not the named addressee you should not=20 disseminate, distribute or copy this e-mail. Please notify the sender=20 immediately by e-mail if you have received this e-mail by mistake and=20 delete this e-mail from your system. If you are not the intended recipient= =20 you are notified that disclosing, copying, distributing or taking any=20 action in reliance on the contents of this information is strictly=20 prohibited. From nobody Thu Nov 16 02:56: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 8395E127909 for ; Thu, 16 Nov 2017 02:56:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.7 X-Spam-Level: X-Spam-Status: No, score=-4.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 2E1UudubnUai for ; Thu, 16 Nov 2017 02:56:31 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0107.outbound.protection.outlook.com [104.47.37.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F2B127873 for ; Thu, 16 Nov 2017 02:56:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XeHx6KbieVZwwcCzrqrHtN3r7qw5YbSoqZp/zzM9R6g=; b=cLmNaRVzXcMixZ5EtpWj+cgayKqQ+35bBUBSq9fDfXFvH7538YuyaMHTXzGFXFh5YwJKU0ERRIlGkNNQK6XoZ479TmIEzEobw7zKVNtntZZBdqwaL0h420WcDjn2i+HNlXRjsGR87aGXmjF30LtMx3DGrnN/zyys2jak/W8N920= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 16 Nov 2017 10:56:29 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 10:56:29 +0000 From: Mike Bishop To: Ian Swett , IETF QUIC WG Subject: RE: Moving the version 4 bytes earlier in the long header Thread-Topic: Moving the version 4 bytes earlier in the long header Thread-Index: AQHTXrMVsGiMH152YU6Ch+QhTyZgtqMW1LjA Date: Thu, 16 Nov 2017 10:56:28 +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=mbishop@evequefou.be; x-originating-ip: [2001:67c:370:1998:7c25:82f6:b822:cc3a] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2432; 6:okChrQVSY8A6rVi7r89MPq5SBlNILFJzRkhhYl1ecCO1s7UyM9XjF8ciuDuP6pGxk000WGgWzyOJASQ4Fgk04ZAHSQTWZZ1B2Qt9Tqcn36q/tbIk7FC4I9IQcmnsmsB41XGSK27U8lMBO7T3ub1/D+i7v9KaTOl1dvGag+cThPupKwhrfTmv+AuV6MJIvB9pERYUJ6+CMgN4uXN9g+W1b2qHtMLScUZ7HJ/lSKEB8NoQemntu/SNsqMkAByygFGVp+bt0SQMg1b9FxdFKkf0B96UgfaZ3Ox/cGodhsiMBkNajBMESNHwODZFbJn9qfyP07aVeNR1/i2wOIxbFFOmVep7RcquYeCUUnFqgn/XnzQ=; 5:w7UAxmsqiSY2EgOIBBL0TRKGu8YvSGs9jdDPjTTi73sydtHcwvS+FUf7QubNFpwxX5GYjegs5G3Q6JPZH5JWdfdY22x/rnePhgWQPWPMQ23oko+mgMMo85OhF0ZJLG/bIe58R1BH8wxJfS5oVXYCw+VRiUm+9QGx8GkW95JNvjk=; 24:gYeSHHZmTGlrPWmUawTCDbSiQOsRJHgGPRiFcj5JFLLB7BQBmSdxr12uk6W9g8107upWbNuE9jYGnsx7E2qzJZtKak5C8j605fJIZXr56/I=; 7:plmVOdTN5hV7bkojqmIh7Kb8LJGxiZJCBOPpQBLAuEe0uXmkYNnrfluVieTYYWVu49JUpmpbcq5NDtQJhD/y6GREbsHHHRHJLJzga9sTmm3DfIfAslElTl03jRkKIgK2SOSM10Z2MFMXBonoT+TifSn/vrYnvBf/sNFItwTVTcJKlsJM22stTdwn4Ldtz2wnwnnL1ObJHIUSsuf2/Zo0byZDOT6xIuuW8Y9KkLcypLp0nGOrDokDFRIKr78rR7Yv x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 37c18688-9037-4232-5ef6-08d52ce0b0b5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603199); SRVR:MWHPR08MB2432; x-ms-traffictypediagnostic: MWHPR08MB2432: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231022)(93006095)(93001095)(100000703101)(100105400095)(6041248)(2016111802025)(20161123558100)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(201703131423075)(201703061421075)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2432; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2432; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(189002)(199003)(8676002)(33656002)(74316002)(229853002)(105586002)(106356001)(6436002)(6506006)(6306002)(236005)(54896002)(9686003)(6116002)(508600001)(25786009)(790700001)(53936002)(2900100001)(102836003)(55016002)(6246003)(7736002)(81156014)(81166006)(86362001)(8936002)(77096006)(53546010)(74482002)(19609705001)(5660300001)(3660700001)(99286004)(606006)(14454004)(3280700002)(110136005)(189998001)(50986999)(54356999)(101416001)(2906002)(7696004)(76176999)(68736007)(2950100002)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2432; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432823F12AA6C78CB296CCADA2E0MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 37c18688-9037-4232-5ef6-08d52ce0b0b5 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 10:56:28.9422 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2432 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:56:34 -0000 --_000_MWHPR08MB2432823F12AA6C78CB296CCADA2E0MWHPR08MB2432namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWN0dWFsbHksIOKAnHRoZSBsb2NhdGlvbiBhbmQgc2l6ZSBvZiB0aGUgUGFja2V0IE51bWJlciBm aWVsZCBpbiBsb25nIGhlYWRlcnPigJ0gaXMgY3VycmVudGx5IGxpc3RlZCBhcyBhbiBpbnZhcmlh bnQuICBJdOKAmXMgdGhlIHNlbWFudGljcyBvZiB0aGF0IGZpZWxkIHRoYXQgYXJlIG11dGFibGUg cGVyIHZlcnNpb24sIHRob3VnaCBhcyBCcmlhbiBoYXMgb2JzZXJ2ZWQsIHNvbWUgc2VtYW50aWNz IG1heSBnZXQgb3NzaWZpZWQgb24gdXMgaWYgd2XigJlyZSBub3QgY2FyZWZ1bC4NCg0KSXQgbmVl ZHMgdG8gYmUgYW4gaW52YXJpYW50LCBiZWNhdXNlIHRoZSBWZXJzaW9uIE5lZ290aWF0aW9uIHBh Y2tldCAoYW5kIGhvdyB5b3UgZ2VuZXJhdGUgb25lKSBuZWVkcyB0byBiZSBpbnZhcmlhbnQsIGFu ZCBhIHZhbHVlIGlzIHJlYWQgZnJvbSB0aGUgaW5jb21pbmcgcGFja2V0IGFuZCBzZXQgaW4gdGhl IFZlcnNpb24gTmVnb3RpYXRpb24gcGFja2V0IGFzIHBhcnQgb2YgdmVyc2lvbiBuZWdvdGlhdGlv bi4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxm IE9mIElhbiBTd2V0dA0KU2VudDogVGh1cnNkYXksIE5vdmVtYmVyIDE2LCAyMDE3IDQ6MTUgUE0N ClRvOiBJRVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBNb3ZpbmcgdGhlIHZl cnNpb24gNCBieXRlcyBlYXJsaWVyIGluIHRoZSBsb25nIGhlYWRlcg0KDQpJIGFtIHZlcnkgc3Vw cG9ydGl2ZSBvZiBNYXJ0aW4ncyB3b3JrIHRvIGRlZmluZSBRVUlDIGludmFyaWFudHMuDQoNCkl0 IHNlZW1zIGlkZWFsIHRvIG1ha2UgdGhlIGludmFyaWFudHMgYXMgZWFybHkgaW4gdGhlIHBhY2tl dCBhcyBwb3NzaWJsZSwgc28gSSdkIHN1Z2dlc3Qgd2UgbW92ZSB0aGUgNCBieXRlIHZlcnNpb24g aW4gZnJvbnQgb2YgdGhlIDQgYnl0ZSBwYWNrZXQgbnVtYmVyIGluIHRoZSBsb25nIGhlYWRlci4g IFRoaXMgaXMgZmlsZWQgaW4gSXNzdWUgIzkyNjxodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jh c2UtZHJhZnRzL2lzc3Vlcy85MjY+LiAgRm9yIHJlZmVyZW5jZSwgaXQgaXMgcHJvcG9zZWQgdGhl IHNpemUgYW5kIGxvY2F0aW9uIG9mIHRoZSB2ZXJzaW9uIGlzIGFuIGludmFyaWFudCwgYnV0IG5v dGhpbmcgYWJvdXQgdGhlIHBhY2tldCBudW1iZXIgaXMuDQoNCkp1c3QgYmVjYXVzZSB0aGUgcGFj a2V0IG51bWJlciBpcyBiZWZvcmUgdGhlIHZlcnNpb24gZG9lc24ndCBtZWFuIHRoZSBwYWNrZXQg bnVtYmVyIGxlbmd0aCBjYW4ndCBjaGFuZ2UsIGJ1dCBpdCBkb2VzIG1lYW4gd2UncmUgc3R1Y2sg d2l0aCB0aG9zZSA0IGJ5dGVzIGluIHRoYXQgbG9jYXRpb24sIHdoaWNoIG1ha2VzIGZ1dHVyZSBj aGFuZ2VzIHRvIHRoZSBwYWNrZXQgbnVtYmVyIGxlbmd0aCB2ZXJ5IGF3a3dhcmQuDQoNCkkgZG9u J3QgYW50aWNpcGF0ZSBmdXR1cmUgY2hhbmdlcywgYnV0IHRoaXMgaXMgZ29pbmcgdG8gYmUgYW4g aW52YXJpYW50IGZvciBhIHZlcnkgbG9uZyB0aW1lLCBzbyBJJ2QgbGlrZSB0byBtb3ZlIGl0IG5v dy4NCg0KVGhhbmtzLCBJYW4NCg== --_000_MWHPR08MB2432823F12AA6C78CB296CCADA2E0MWHPR08MB2432namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2 aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25v cm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1z b25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1 bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0K CW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3Bh Z2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFb ZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0i ZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91 dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJi bHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BY3R1YWxseSwg4oCcPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMz MyI+dGhlIGxvY2F0aW9uIGFuZCBzaXplIG9mIHRoZSBQYWNrZXQgTnVtYmVyIGZpZWxkIGluIGxv bmcgaGVhZGVyc+KAnTwvc3Bhbj48YSBuYW1lPSJfTWFpbEVuZENvbXBvc2UiPiBpcyBjdXJyZW50 bHkgbGlzdGVkIGFzIGFuIGludmFyaWFudC4mbmJzcDsgSXTigJlzIHRoZQ0KPGk+c2VtYW50aWNz PC9pPiBvZiB0aGF0IGZpZWxkIHRoYXQgYXJlIG11dGFibGUgcGVyIHZlcnNpb24sIHRob3VnaCBh cyBCcmlhbiBoYXMgb2JzZXJ2ZWQsIHNvbWUgc2VtYW50aWNzIG1heSBnZXQgb3NzaWZpZWQgb24g dXMgaWYgd2XigJlyZSBub3QgY2FyZWZ1bC48bzpwPjwvbzpwPjwvYT48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsRW5kQ29tcG9zZSI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPkl0IG5lZWRzIHRvIGJlIGFuIGludmFy aWFudCwgYmVjYXVzZSB0aGUgVmVyc2lvbiBOZWdvdGlhdGlvbiBwYWNrZXQgKGFuZCBob3cgeW91 IGdlbmVyYXRlIG9uZSkgbmVlZHMgdG8gYmUgaW52YXJpYW50LCBhbmQgYSB2YWx1ZSBpcyByZWFk IGZyb20gdGhlIGluY29taW5nIHBhY2tldCBhbmQgc2V0IGluIHRoZSBWZXJzaW9uIE5lZ290aWF0 aW9uDQogcGFja2V0IGFzIHBhcnQgb2YgdmVyc2lvbiBuZWdvdGlhdGlvbi48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJr Ol9NYWlsRW5kQ29tcG9zZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbEVuZENvbXBvc2UiPjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8 Yj5PbiBCZWhhbGYgT2YNCjwvYj5JYW4gU3dldHQ8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXks IE5vdmVtYmVyIDE2LCAyMDE3IDQ6MTUgUE08YnI+DQo8Yj5Ubzo8L2I+IElFVEYgUVVJQyBXRyAm bHQ7cXVpY0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gTW92aW5nIHRoZSB2ZXJz aW9uIDQgYnl0ZXMgZWFybGllciBpbiB0aGUgbG9uZyBoZWFkZXI8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgYW0gdmVyeSBzdXBwb3J0aXZlIG9mIE1hcnRpbidzIHdvcmsgdG8gZGVm aW5lIFFVSUMgaW52YXJpYW50cy4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNlZW1zIGlkZWFsIHRvIG1ha2UgdGhlIGludmFyaWFu dHMgYXMgZWFybHkgaW4gdGhlIHBhY2tldCBhcyBwb3NzaWJsZSwgc28gSSdkIHN1Z2dlc3Qgd2Ug bW92ZSB0aGUgNCBieXRlIHZlcnNpb24gaW4gZnJvbnQgb2YgdGhlIDQgYnl0ZSBwYWNrZXQgbnVt YmVyIGluIHRoZSBsb25nIGhlYWRlci4mbmJzcDsgVGhpcyBpcyBmaWxlZCBpbg0KPGEgaHJlZj0i aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9pc3N1ZXMvOTI2Ij5Jc3N1ZSAj OTI2PC9hPi4mbmJzcDsgRm9yIHJlZmVyZW5jZSwgaXQgaXMgcHJvcG9zZWQgdGhlIHNpemUgYW5k IGxvY2F0aW9uIG9mIHRoZSB2ZXJzaW9uIGlzIGFuIGludmFyaWFudCwgYnV0IG5vdGhpbmcgYWJv dXQgdGhlIHBhY2tldCBudW1iZXIgaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkp1c3QgYmVjYXVzZSB0aGUgcGFja2V0IG51bWJlciBpcyBi ZWZvcmUgdGhlIHZlcnNpb24gZG9lc24ndCBtZWFuIHRoZSBwYWNrZXQgbnVtYmVyIGxlbmd0aCBj YW4ndCBjaGFuZ2UsIGJ1dCBpdCBkb2VzIG1lYW4gd2UncmUgc3R1Y2sgd2l0aCB0aG9zZSA0IGJ5 dGVzIGluIHRoYXQgbG9jYXRpb24sIHdoaWNoIG1ha2VzIGZ1dHVyZSBjaGFuZ2VzIHRvIHRoZSBw YWNrZXQgbnVtYmVyIGxlbmd0aCB2ZXJ5IGF3a3dhcmQuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9uJ3QgYW50aWNpcGF0ZSBmdXR1cmUg Y2hhbmdlcywgYnV0IHRoaXMgaXMgZ29pbmcgdG8gYmUgYW4gaW52YXJpYW50IGZvciBhIHZlcnkg bG9uZyB0aW1lLCBzbyBJJ2QgbGlrZSB0byBtb3ZlIGl0IG5vdy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLCBJYW48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR08MB2432823F12AA6C78CB296CCADA2E0MWHPR08MB2432namp_-- From nobody Thu Nov 16 03: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 DACCD129418 for ; Thu, 16 Nov 2017 03:12: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, 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=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 YRHa9-Q4QYia for ; Thu, 16 Nov 2017 03:12:17 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 951661270AC for ; Thu, 16 Nov 2017 03:12:17 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id f187so5490120itb.1 for ; Thu, 16 Nov 2017 03:12: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=iPKVPxj6Tv1gyWw75ThegCCgRaf9jjCLqaVkx/bhhmI=; b=sTZD90JbhR98kNBVrtgw/zIPGnWLy6Yj6Wl0jmcUlRYJZOZLAlyC05E5T5uk2YVJVZ 0DgRXYYVWpDgXBxcP8avQ4SNfgE5Gjh+Bevv0nctRrVKs3NBJXG793CDw/cUcOXN2RIL WQ7ITMHWkt8qKbnKTNH80daKvGglurQFhxAefo2Xdbok2UyEN0CuiMkD8zB9Ome0R+pV Me6xOQhNeKR5BGNP/p6mo+fi9JtkO4Q85HwlBRRR1dusChFMCRlBqB9jxoSWbMmrzfYJ oi3+MWhLyQq+Or0u968OYbZgX20dH/ZxI6BLmzm/lKaLVGtkof6S92Ock9PngF+awg6G m4Yw== 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=iPKVPxj6Tv1gyWw75ThegCCgRaf9jjCLqaVkx/bhhmI=; b=GXRP2vXuSVzFKIyxGu0HcGT3fBCJRofFJhVl1xGD5hNOFrT0LyPJDhS20tb9286VoC 5xDVE1E6F5oQnrAs47aOGEm/ys5DvqZICxp2+MBWLPgeOYwxbBkxmeN7IBi3Urx+Nq1R 8uBJRjVVNV2nSuIdKGrEQqHr8nPxt41KZZ7neVWBqkr+FCUFzDkjXanbe762toFPasxP gYHGnHerP4duVGwJHZoIiN98q3LZ9nwRGKApCaU5tN9rKD/6Z9LGUErRv5OoIjIBt9Nk eYoyq+wTI02FQcso7CZNl2VII34jjIZGpHpHgUlsI7Af2BnRJW0iH2ulMz690tbi/Uaq mKYA== X-Gm-Message-State: AJaThX6OP3m1m7aL+tWZCt1x/mI9Bmk4SAeuDIFXsxs53gjU/rAzYA09 VuR+8//Zf/8rAuvG0Pjw+hRwg9fjSHB/HYDw8UPjHg== X-Google-Smtp-Source: AGs4zMbtuw3YMOrGoLreXxlPgQk9nPwFXcmxbt/LlwevmaBGQf0uXrKnHbYao1NOskJsnLqh8mOP3InZ6Oa5xHFcj2s= X-Received: by 10.36.175.17 with SMTP id t17mr1910314ite.66.1510830736723; Thu, 16 Nov 2017 03:12:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.101.16 with HTTP; Thu, 16 Nov 2017 03:11:56 -0800 (PST) In-Reply-To: References: From: Ian Swett Date: Thu, 16 Nov 2017 06:11:56 -0500 Message-ID: Subject: Re: Moving the version 4 bytes earlier in the long header To: Mike Bishop Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c198400616c11055e17b110" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 11:12:20 -0000 --94eb2c198400616c11055e17b110 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the reminder on the version negotiation packet, Mike. I would expect the version negotiation packet could echo the connection ID and do anything with the packet number, given the connection ID provides 8 bytes of entropy? If we no longer randomize the initial packet number(#850 ), it would not be providing much entropy anyway. That would mean we'd be echoing the portion of the packet up to the end of the version(like before), but wouldn't say anything about the portion afterwards. On Thu, Nov 16, 2017 at 5:56 AM, Mike Bishop wrote: > Actually, =E2=80=9Cthe location and size of the Packet Number field in lo= ng > headers=E2=80=9D is currently listed as an invariant. It=E2=80=99s the *= semantics* of > that field that are mutable per version, though as Brian has observed, so= me > semantics may get ossified on us if we=E2=80=99re not careful. > > > > It needs to be an invariant, because the Version Negotiation packet (and > how you generate one) needs to be invariant, and a value is read from the > incoming packet and set in the Version Negotiation packet as part of > version negotiation. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Ian Swett > *Sent:* Thursday, November 16, 2017 4:15 PM > *To:* IETF QUIC WG > *Subject:* Moving the version 4 bytes earlier in the long header > > > > I am very supportive of Martin's work to define QUIC invariants. > > > > It seems ideal to make the invariants as early in the packet as possible, > so I'd suggest we move the 4 byte version in front of the 4 byte packet > number in the long header. This is filed in Issue #926 > . For reference, it is > proposed the size and location of the version is an invariant, but nothin= g > about the packet number is. > > > > Just because the packet number is before the version doesn't mean the > packet number length can't change, but it does mean we're stuck with thos= e > 4 bytes in that location, which makes future changes to the packet number > length very awkward. > > > > I don't anticipate future changes, but this is going to be an invariant > for a very long time, so I'd like to move it now. > > > > Thanks, Ian > --94eb2c198400616c11055e17b110 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the reminder on the version negotiation packet,= Mike.

I would expect the version negotiation packet cou= ld echo the connection ID and do anything with the packet number, given the= connection ID provides 8 bytes of entropy?

If we = no longer randomize the initial packet number(#850), it would not b= e providing much entropy anyway.

That would mean w= e'd be echoing the portion of the packet up to the end of the version(l= ike before), but wouldn't say anything about the portion afterwards.

On Thu, = Nov 16, 2017 at 5:56 AM, Mike Bishop <mbishop@evequefou.be> wrote:

Actually, =E2=80=9Cthe location and= size of the Packet Number field in long headers=E2=80=9D is currently listed as an invarian= t.=C2=A0 It=E2=80=99s the semantics of that field that are mutable per version, though as Bria= n has observed, some semantics may get ossified on us if we=E2=80=99re not = careful.

=C2=A0

It needs to be an invariant, because the Versi= on Negotiation packet (and how you generate one) needs to be invariant, and= a value is read from the incoming packet and set in the Version Negotiatio= n packet as part of version negotiation.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Thursday, November 16, 2017 4:15 PM
To: IETF QUIC WG <quic@ietf.org>
Subject: Moving the version 4 bytes earlier in the long header

=C2=A0

I am very supportive of Martin's work to define = QUIC invariants.=C2=A0=C2=A0

=C2=A0

It seems ideal to make the invariants as early in th= e packet as possible, so I'd suggest we move the 4 byte version in fron= t of the 4 byte packet number in the long header.=C2=A0 This is filed in Issue #926.=C2=A0 For reference, it is proposed the size and locati= on of the version is an invariant, but nothing about the packet number is.<= u>

=C2=A0

Just because the packet number is before the version= doesn't mean the packet number length can't change, but it does me= an we're stuck with those 4 bytes in that location, which makes future = changes to the packet number length very awkward.

=C2=A0

I don't anticipate future changes, but this is g= oing to be an invariant for a very long time, so I'd like to move it no= w.

=C2=A0

Thanks, Ian


--94eb2c198400616c11055e17b110-- From nobody Thu Nov 16 05:52: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 54E561293F4 for ; Thu, 16 Nov 2017 05:52:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.398 X-Spam-Level: X-Spam-Status: No, score=-5.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q_7coyT0O6qm for ; Thu, 16 Nov 2017 05:52:01 -0800 (PST) Received: from orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EF5C129400 for ; Thu, 16 Nov 2017 05:52:01 -0800 (PST) Received: from opfednr05.francetelecom.fr (unknown [xx.xx.xx.69]) by opfednr22.francetelecom.fr (ESMTP service) with ESMTP id 7EB272063B; Thu, 16 Nov 2017 14:51:59 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.43]) by opfednr05.francetelecom.fr (ESMTP service) with ESMTP id 588B32007D; Thu, 16 Nov 2017 14:51:59 +0100 (CET) Received: from OPEXCLILMA1.corporate.adroot.infra.ftgroup ([fe80::95e2:eb4b:3053:fabf]) by OPEXCLILM5F.corporate.adroot.infra.ftgroup ([fe80::e172:f13e:8be6:71cc%18]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 14:51:54 +0100 From: To: Spencer Dawkins at IETF , Martin Duke CC: Piotr Galecki , "gorry@erg.abdn.ac.uk" , Ian Swett , QUIC WG , "MORTON, ALFRED C (AL)" , "STEPHAN Emile IMT/OLN" , =?utf-8?B?VFVGRklOIFN0w6lwaGFuZSBJTVQvT0xO?= Subject: RE: spin bit in QUIC: troubleshooting Thread-Topic: spin bit in QUIC: troubleshooting Thread-Index: AQHTXnp1PxolJwlJmUqb1TQshOYLfaMXBjOA Date: Thu, 16 Nov 2017 13:51:54 +0000 Message-ID: <26610_1510840319_5A0D97FF_26610_49_1_d3c183d8-a3a0-480c-a1e5-19601e9b72f0@OPEXCLILM5F.corporate.adroot.infra.ftgroup> References: <11937_1510654451_5A0AC1F3_11937_138_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E4C5@OPEXCLILM44.corporate.adroot.infra.ftgroup> <11102_1510682780_5A0B309C_11102_260_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E7E67B@OPEXCLILM44.corporate.adroot.infra.ftgroup> <4D7F4AD313D3FC43A053B309F97543CF490457FA@njmtexg5.research.att.com> <5A0BD528.3040106@erg.abdn.ac.uk> <2C515BE8694C6F4B9B6A578BCAC32E2F83AC9673@MBX021-W3-CA-2.exch021.domain.local> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/related; boundary="_004_d3c183d8a3a0480ca1e519601e9b72f0OPEXCLILM5Fcorporateadr_"; type="multipart/alternative" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 13:52:05 -0000 --_004_d3c183d8a3a0480ca1e519601e9b72f0OPEXCLILM5Fcorporateadr_ Content-Type: multipart/alternative; boundary="_000_d3c183d8a3a0480ca1e519601e9b72f0OPEXCLILM5Fcorporateadr_" --_000_d3c183d8a3a0480ca1e519601e9b72f0OPEXCLILM5Fcorporateadr_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpTcGVha2luZyBhcyBhbiBvcGVyYXRvciwNCg0KQXMgaXQgdHVybnMgb3V0LCB3ZSBkbyB1c2Ug ZGljaG90b215ICBldmVyeSBkYXkgZm9yIHRyb3VibGVzaG9vdGluZywgbW92aW5nIGEgc2luZ2xl IGNhcHR1cmUgcG9pbnQgYXJvdW5kIHdoZXJlIHBvc3NpYmxlLg0KRm9yIHRoaXMgcmVhc29uLCB3 ZSBhcmUgdmVyeSBhbnhpb3VzIHRvIHNlZSB0aGUgbmVjZXNzYXJ5IGNsZWFyIGZpZWxkcyBsYW5k IGluIFFVSUMgdG8ga2VlcCBkb2luZyB0aGlzLg0KW2NpZDppbWFnZTAwMi5wbmdAMDFEMDNDOTcu ODExNjEyNjBdDQpJc2FiZWxsZSBIQU1DSEFPVUkNCk9yYW5nZTxodHRwOi8vb25lLWRpcmVjdG9y eS5zc28uZnJhbmNldGVsZWNvbS5mci9hbm51YWlyZS9lbnRpdGUuZG8/YWN0aW9uPVZpZXcmdWlk PSUyMyUwMCU3RSUwRiUwNEQlMEElMDdxJTEwLSUxRCUxOSUxQyUwQyUxNyUzRlklMjclMEFNJTAx JTBCJTA2JTNFJTE0LSUwNyUwNSUwOSUwQyUwMCUyOVklMjclMEFNJTBFJTE3JTEzJTIyJTE2JTI2 JTFEJTE1JTA0JTAwJTExJTIzJTE4byUwRCUxM1UlMDMlMDA+L0lNVDxodHRwOi8vb25lLWRpcmVj dG9yeS5zc28uZnJhbmNldGVsZWNvbS5mci9hbm51YWlyZS9lbnRpdGUuZG8/YWN0aW9uPVZpZXcm dWlkPSUyMyUwMCU3RSUwNiUxQyUwNiUwNiU1RSUyMyUwMCU3RSUwRiUwNEQlMEElMDdxJTEwLSUx RCUxOSUxQyUwQyUxNyUzRlklMjclMEFNJTAxJTBCJTA2JTNFJTE0LSUwNyUwNSUwOSUwQyUwMCUy OVklMjclMEFNJTBFJTE3JTEzJTIyJTE2JTI2JTFEJTE1JTA0JTAwJTExJTIzJTE4byUwRCUxM1Ul MDMlMDA+L09MTjxodHRwOi8vb25lLWRpcmVjdG9yeS5zc28uZnJhbmNldGVsZWNvbS5mci9hbm51 YWlyZS9lbnRpdGUuZG8/YWN0aW9uPVZpZXcmdWlkPSUyMyUwMCU3RSUwNiUxQyUwNkklMUQ5SCUy QyUwNSUxRSUwQkklMUQ5SCUyNSUxRCU1QyUwNyUxME8lMjklMUI3JTAwJTA0JTAxJTAwJTAxJTYw JTExK1QlMTklMDYlMTElMDAtJTFCLSUxQyUxMSUwMSUxNyUxNyU2MCUxMStUJTE2JTFBJTA0JTFD JTJGJTEwNyUwQyUxQyUwRCUwNiUxRCUyMVklMjclMEFNJTBFJTE3Pi9XVEM8aHR0cDovL29uZS1k aXJlY3Rvcnkuc3NvLmZyYW5jZXRlbGVjb20uZnIvYW5udWFpcmUvZW50aXRlLmRvP2FjdGlvbj1W aWV3JnVpZD0lMjMlMDAlN0UlMUUlMDQlMEJJJTFEOUglMkMlMDUlMUVEJTBBJTA3cSUxQSUyRiUw NyUxM0QlMEElMDdxJTEzN0UlMUYlMURYJTE3JTIyJTAxKiUxRCUxOSUwRCUxNiU1RSUyOCUxNiU3 RSUwMCUxRSUxQyUxNyUxMyUyMiUxQjYlMDglMTklMUElMDAlNUUlMjglMTYlN0UlMEYlMDIlMDkl MEIlMTElMjklMDElMjYlMDUlMTUlMEIlMEElMUYlNjAlMTErVCUxNiUxQT4vSUVFDQp0w6lsLiAr MzMgMiA5NiAwNyAxNCA5Mg0KTW9iLiArMzMgNiA4NSAzNyAwMiA5Mg0KaXNhYmVsbGUuaGFtY2hh b3VpQG9yYW5nZS5jb208bWFpbHRvOmlzYWJlbGxlLmhhbWNoYW91aUBvcmFuZ2UuY29tPg0KDQpE ZSA6IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIFttYWlsdG86c3BlbmNlcmRhd2tpbnMuaWV0ZkBn bWFpbC5jb21dDQpFbnZvecOpIDogamV1ZGkgMTYgbm92ZW1icmUgMjAxNyAwMToyOQ0Kw4AgOiBN YXJ0aW4gRHVrZQ0KQ2MgOiBQaW90ciBHYWxlY2tpOyBnb3JyeUBlcmcuYWJkbi5hYy51azsgSWFu IFN3ZXR0OyBRVUlDIFdHOyBNT1JUT04sIEFMRlJFRCBDIChBTCk7IFNURVBIQU4gRW1pbGUgSU1U L09MTg0KT2JqZXQgOiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJvdWJsZXNob290aW5nDQoNClNw ZWFraW5nIGFzIGEgY3VyaW91cyBpbmRpdmlkdWFsLA0KDQpPbiBUaHUsIE5vdiAxNiwgMjAxNyBh dCA2OjU0IEFNLCBNYXJ0aW4gRHVrZSA8bWFydGluLmguZHVrZUBnbWFpbC5jb208bWFpbHRvOm1h cnRpbi5oLmR1a2VAZ21haWwuY29tPj4gd3JvdGU6DQpQYWNrZXQgbnVtYmVycyBhcmUgdW5lbmNy eXB0ZWQgYW5kIG1vbm90b25pY2FsbHkgaW5jcmVhc2luZy4gSXQgaXMgdGhlcmVmb3JlIHJlbGF0 aXZlbHkgc3RyYWlnaHRmb3J3YXJkIHRvIG1lYXN1cmUgcmVvcmRlcmluZyBiZXR3ZWVuIGFueSB0 d28gcG9pbnRzIGluIHRoZSBuZXR3b3JrIGlmIHlvdSBoYXZlIGluc3RydW1lbnRzIHRoZXJlLg0K DQpBbmQgdGhhdCdzIGNlcnRhaW5seSB0aGUgd2F5IGNhcnJpZXJzIHdlcmUgbW9uaXRvcmluZyBs YXJnZSBuZXR3b3JrcyB3aGVuIEkgd2FzIHdvcmtpbmcgaW4gdGhhdCBzcGFjZSBpbiB0aGUgbWlk LTIwMDBzLiBJdCdzIGFsc28gdGhlIGRpcmVjdGlvbiBJIHNlZSBpbiByZWNlbnQgSVBQTSBkb2Nz IEkndmUgc2hlcGhlcmRlZCwgSUlVQy4NCg0KTW9uaXRvcmluZyBhdCBvbmUgcG9pbnQgaW4gdGhl IG5ldHdvcmsgd291bGQgYmUgYXdlc29tZSwgYnV0IGl0IHdvdWxkIGJlIGEgcGxlYXNhbnQgc3Vy cHJpc2UgaWYgb3BlcmF0b3JzIGFyZSBkb2luZyBpdCBub3cuDQoNClNwZW5jZXINCg0KDQpPbiBU dWUsIE5vdiAxNCwgMjAxNyBhdCA5OjU5IFBNLCBQaW90ciBHYWxlY2tpIDxwaW90cl9nYWxlY2tp QGFmZmlybWVkbmV0d29ya3MuY29tPG1haWx0bzpwaW90cl9nYWxlY2tpQGFmZmlybWVkbmV0d29y a3MuY29tPj4gd3JvdGU6DQpIb3cgd291bGQgYSBuZXR3b3JrIHByb2JlIGJlIGFibGUgdG8gbWVh c3VyZSB0aGUgbGV2ZWwgb2YgcGFja2V0IHJlb3JkZXJpbmcgaW4gUVVJQyBzdHJlYW0gd2l0aCBv bmx5IGEgc3BpbiBiaXQ/DQoNCkknbSBhc2tpbmcgYmVjYXVzZSBvbmUgb2YgdGhlIGNvbW1vbiB0 ZWNobmlxdWVzIHRvIGRpYWdub3NlIG5ldHdvcmsgaXNzdWVzDQppcyB0byBpbnNlcnQgYSBwcm9i ZSBpbiBkaWZmZXJlbnQgcG9pbnRzIGluIHRoZSBuZXR3b3JrIGFuZCBtZWFzdXJlOg0KKiBSVFQN CiogVENQIHNlZ21lbnQgbG9zcw0KKiBUQ1Agc2VnbWVudCByZXRyYW5zbWlzc2lvbnMNCiogVENQ IHNlZ21lbnQgb3V0LW9mLW9yZGVyDQphcyBhIGZldyBiYXNpYyBkYXRhIHBvaW50cy4NCldpdGgg bWVhc3VyZW1lbnRzIGluIHBvaW50IEEgYW5kIHBvaW50IEIgb25lIGNhbiBkZXRlcm1pbmUgZm9y IGV4YW1wbGUgaWYgYSBuZXR3b3JrIGRldmljZSBpcyBtaXNvcmRlcmluZyBwYWNrZXRzLg0KDQot UGlvdHINCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFVSUMgW21haWx0bzpx dWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJl aGFsZiBPZiBHb3JyeSBGYWlyaHVyc3QNClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTUsIDIw MTcgMTI6NDggQU0NClRvOiBNT1JUT04sIEFMRlJFRCBDIChBTCkgPGFjbW9ydG9uQGF0dC5jb208 bWFpbHRvOmFjbW9ydG9uQGF0dC5jb20+Pg0KQ2M6IElhbiBTd2V0dCA8aWFuc3dldHRAZ29vZ2xl LmNvbTxtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbT4+OyBRVUlDIFdHIDxxdWljQGlldGYub3Jn PG1haWx0bzpxdWljQGlldGYub3JnPj47IGVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbTxtYWlsdG86 ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPg0KU3ViamVjdDogUmU6IHNwaW4gYml0IGluIFFVSUM6 IHRyb3VibGVzaG9vdGluZw0KDQpBcyBJIHNhaWQgYXQgdGhlIG1pYzogSSB0aGluayB0aGUgc3Bp bi1iaXQgYW5hbHlzaXMgd2FzIGhlbHBmdWwsIHRoYW5rcy4NCg0KSSBjYW4gc2VlIGhvdyBzcGlu LWJpdCBpcyByZWFsbHkgdXNlZnVsIHRvIGdldCBiYXNpYyBkaWFnbm9zdGljcyBvZiBSVFQgaWYg aXQgY2FuIGJlIHJlbGllZCB0byBiZSBwcmVzZW50IGluIGV2ZXJ5IHBhY2tldC4gKEl0IGlzIGlt cG9ydGFudCB0byBtZWFzdXJlIGxhdGVuY3kgd2l0aGluIHRoZSBuZXR3b3JrKS4NCg0KVGhlcmUg YXJlIHBsYWNlcyB3aGVyZSAxLWJpdCBnaXZlcyByZXN0cmljdGVkIHZhbHVlLCBhbmQgdXNpbmcg bW9yZSB3b3VsZCBoZWxwOiBNeSBhZGRpdGlvbmFsIGNvbW1lbnQgYXQgdGhlIE1pYyByZWxhdGVk IHRvIGhvdyBtdWNoIGV4dHJhIHdvdWxkIGJlIHRoZSBnYWluIGZyb20gYW4gYWRkaXRpb25hbCBv bmUgb3IgdHdvIGJpdHM/DQoNCkluIHBhcnRpY3VsYXIsIEknZCBsaWtlIHRvIHNlZSBhIG1ldGhv ZCB0aGF0IGNhbiBsZXQgbWUgZGV0ZWN0IHNvbWUgbG9zcyBwYXR0ZXJucyBhbmQgbWVhc3VyZSBy ZW9yZGVyaW5nLCBhdCBsZWFzdCBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBrbm93IGFuZCBt ZWFzdXJlIHdoZW4gdGhlcmUgaXMgc21hbGwtc2NhbGUgcmVvcmRlcmluZyA8My4NCg0KQSBzdWdn ZXN0aW9uOmlzIHRvIHVzZSBhIDItYml0IGNvdW50ZXIgZm9yIHRoZSBzcGluICgNCjAwLT4wMS0+ MTAtPjExLT4wMCksIHRoYXQgd291bGQgaGVscCBkZXRlY3QgdGhlc2UgcGF0aCBhbm9tbGllcy4N Cg0KR29ycnkNCg0KT24gMTUvMTEvMjAxNywgMDk6NTEsIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSB3 cm90ZToNCj4NCj4gSeKAmWQgbGlrZSB0byBvZmZlciBzdXBwb3J0IGZvciBTcGluIEJpdCAoYW5k IG9uZSBvciB0d28NCj4NCj4gYml0cyBmb3IgbWFuYWdlbWVudCBpZiB0aGV5IGNhbiBiZSBqdXN0 aWZpZWQgcXVpY2tseSkgaW4gdjEuDQo+DQo+IE9uIHRoaXMgdG9waWMgb2YgbW9yZSBiaXRzLA0K Pg0KPiBhc2tpbmcgZnVydGhlciBjbGFyaWZpY2F0aW9uIGZyb20gRW1pbGUsIGJlbG93IFtBQ01d Lg0KPg0KPiBBbA0KPg0KPiAqRnJvbToqUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9y ZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0gKk9uIEJlaGFsZiBPZiAqSWFuIFN3ZXR0 DQo+ICpTZW50OiogVHVlc2RheSwgTm92ZW1iZXIgMTQsIDIwMTcgNDoyMSBQTQ0KPiAqVG86KiBl bWlsZS5zdGVwaGFuQG9yYW5nZS5jb208bWFpbHRvOmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbT4N Cj4gKkNjOiogUVVJQyBXRw0KPiAqU3ViamVjdDoqIFJlOiBzcGluIGJpdCBpbiBRVUlDOiB0cm91 Ymxlc2hvb3RpbmcNCj4NCj4gVGhhbmtzIGZvciBjbGFyaWZ5aW5nIEVtaWxlLg0KPg0KPiBPbiBU dWUsIE5vdiAxNCwgMjAxNyBhdCAxOjA2IFBNLCA8ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPG1h aWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+DQo+IDxtYWlsdG86ZW1pbGUuc3RlcGhhbkBv cmFuZ2UuY29tPG1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+Pj4gd3JvdGU6DQo+DQo+ IEhpIElhbiwNCj4NCj4gSXQgd2FzIHN1Z2dlc3RlZCBpbiB0aGUgbGF0ZXN0IGRpc2N1c3Npb24g b24gdGhlIFJUVCBkZXNpZ24gdGVhbQ0KPiBtYWlsaW5nIGxpc3QgdG8gaGF2ZSBvbmUgYml0IGZv ciBwYWNrZXQgbG9zdCwgb25lIGZvciBsYXRlbmN5IChzcGluDQo+IGJpdCBvciBlcS4pIGFuZCBv bmUgZm9yIGNvbmdlc3Rpb24uDQo+DQo+ICovW0FDTV0gLyogVGhlcmUgbWF5IGJlIHNvbWUgb3Zl cmxhcCB3aXRoIEVDTiBhbmQgwqsgb25lIGJpdCBmb3INCj4gY29uZ2VzdGlvbiDCuy4NCj4NCj4g RGlkIHlvdSBhbHNvIGNvbnNpZGVyIHRoaXMgZGVwZW5kZW5jeSwgRW1pbGUgPyAoSeKAmW0gZWNo b2luZyBhIGhhbGx3YXkNCj4gZGlzY3Vzc2lvbikNCj4NCj4gSXQgc2VlbXMgYSBzaW1wbGlzdGlj IGFwcHJvYWNoIG9uIG9uZSBoYW5kIGJ1dCBhbiBpbnZhcmlhbnQgb24gdGhlDQo+IGxvbmcgdGVy bS4NCj4NCj4gUmVnYXJkcw0KPg0KPiBFbWlsZQ0KPg0KPiAqRGUgOipJYW4gU3dldHQgW21haWx0 bzppYW5zd2V0dEBnb29nbGUuY29tPG1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tPg0KPiA8bWFp bHRvOmlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+Pl0gKkVu dm95w6kgOiogbWFyZGkgMTQgbm92ZW1icmUgMjAxNyAyMjo1MQ0KPiAqw4AgOiogU1RFUEhBTiBF bWlsZSBJTVQvT0xOICpDYyA6KiBRVUlDIFdHICpPYmpldCA6KiBSZTogc3BpbiBiaXQgaW4NCj4g UVVJQzogdHJvdWJsZXNob290aW5nDQo+DQo+IFdoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0 d28gYmUgdXNlZCBmb3I/ICBJZiB0aGVyZSBpcyBubw0KPiBzdGFuZGFyZGl6ZWQgdXNlIG9mIHRo b3NlIGJpdHMgaW4gdjEsIHRoZW4gSSBiZWxpZXZlIHdlIHNob3VsZCB3YWl0IHRvDQo+IHJlc2Vy dmUgdGhlbSB3aGVuIHRoZWlyIHVzYWdlIGlzIGRlZmluZWQsIGdpdmVuIHdlJ2QgbmVlZCBhIHZl cnNpb24NCj4gYnVtcCB0byBzcGVjaWZ5IGhvdyB0aGV5IHdlcmUgYmVpbmcgdXNlZC4gIEF0IHRo ZSBtb21lbnQsIHRoZQ0KPiBtYW5hZ2VtZW50IHVzZSBjYXNlIGlzIG5vdCBjb21wZXRpbmcgd2l0 aCBhbnlvbmUgZWxzZSBmb3IgYml0cyBpbiB0aGUNCj4gc2hvcnQgaGVhZGVyLg0KPg0KPiBPbiBU dWUsIE5vdiAxNCwgMjAxNyBhdCA1OjE0IEFNLCA8ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPG1h aWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+DQo+IDxtYWlsdG86ZW1pbGUuc3RlcGhhbkBv cmFuZ2UuY29tPG1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20+Pj4gd3JvdGU6DQo+DQo+ IEhpDQo+DQo+IExhc3Qgd2VlayBPcmFuZ2UgZXhwZXJpZW5jZWQgYSBmYWxsYmFjayBvZiBRVUlD IHRvIFRDUCBvbiBvbmUgb2YgaXRzDQo+IG5ldHdvcmtzLiBUaGUgaXNzdWVzIHdlcmUgbm90IHZp c2libGUgaW4gUVVJQyB0cmFmZmljLiBUaGUNCj4gdHJvdWJsZXNob290aW5nIHdhcyBtYWRlIHVz aW5nIFRDUCBwYWNrZXRzIGluZm9ybWF0aW9uLiBUaGlzIGlzIG5vdA0KPiBzdXN0YWluYWJsZSBv biB0aGUgbG9uZyB0ZXJtIHdoZW4gbnVtZXJvdXMgYXBwbGljYXRpb25zIHVzaW5nDQo+IGRpZmZl cmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdpbGwgc3RvcCB0byBmYWxsYmFjayB0byBUQ1AuDQo+DQo+ IEJhc2VkIG9uIHRoZSBleGNoYW5nZSB3ZSBoYWQgaW4gdGhlIFJUVCBkZXNpZ24gdGVhbSBhbmQg aW4gdG9kYXkNCj4gbWVldGluZyAsIGl0IHNvdW5kcyByZWFzb25hYmxlIHRvIHJlc2VydmUgYXQg bGVhc3QgMiBiaXRzIChpZGVhbGx5IDMNCj4gYml0cyBhcyBkaXNjdXNzZWQgaW4gdGhlIGRlc2ln biB0ZWFtKSBmb3IgbWFuYWdlYWJpbGl0eSBpbiB0aGUgUVVJQw0KPiBpbnZhcmlhbnRzIGFuZCB0 byBzdGFydCBleHBlcmltZW50aW5nIHRoZSBzcGluIGJpdCBpbiBRVUlDIFYxLg0KPg0KPiBSZWdh cmRzDQo+DQo+IEVtaWxlDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+IENlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiBjb25m aWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRyZSBk aWZmdXNlcywNCj4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZQ0KPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxl ciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2lu dGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRl cmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdl IGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+DQo+IFRoaXMgbWVz c2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0KPiBw cml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRoZXkg c2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jp c2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVh c2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJs ZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lm aWVkLg0KPiBUaGFuayB5b3UuDQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+DQo+IENlIG1lc3NhZ2UgZXQg c2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucw0KPiBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYyBwYXMgZXRy ZSBkaWZmdXNlcywNCj4gZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kg dm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZQ0KPiBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWdu YWxlciBhIGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBq b2ludGVzLiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdh bHRlcmF0aW9uLCBPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNz YWdlIGEgZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuDQo+DQo+IFRoaXMg bWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvcg0K PiBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7IHRo ZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRo b3Jpc2F0aW9uLg0KPiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBw bGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cy4NCj4gQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxp YWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFs c2lmaWVkLg0KPiBUaGFuayB5b3UuDQo+DQoNCg0KCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2UgZXQgc2Vz IHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBjb25maWRl bnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRyZSBkaWZm dXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91cyBhdmV6 IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgphIGwnZXhw ZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVzLiBMZXMg bWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0aW9uLApP cmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEgZXRlIGFs dGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5kIGl0cyBh dHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBpbmZvcm1h dGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3QgYmUgZGlz dHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVtYWlscyBt YXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2 ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_d3c183d8a3a0480ca1e519601e9b72f0OPEXCLILM5Fcorporateadr_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQg MyA1IDQgNCAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvQWNl dGF0ZSwgbGkuTXNvQWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJUZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltYXJnaW46MGNt Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1p bHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCnNwYW4ubS03MTk3MzI5MDM0MjQ4Nzg3NzI1aG9l bnpiDQoJe21zby1zdHlsZS1uYW1lOm1fLTcxOTczMjkwMzQyNDg3ODc3MjVob2VuemI7fQ0Kc3Bh bi5tLTcxOTczMjkwMzQyNDg3ODc3MjVpbQ0KCXttc28tc3R5bGUtbmFtZTptXy03MTk3MzI5MDM0 MjQ4Nzg3NzI1aW07fQ0Kc3Bhbi5UZXh0ZWRlYnVsbGVzQ2FyDQoJe21zby1zdHlsZS1uYW1lOiJU ZXh0ZSBkZSBidWxsZXMgQ2FyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IlRleHRlIGRlIGJ1bGxlcyI7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkZSO30NCnNwYW4uRW1haWxTdHlsZTIxDQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMt c2VyaWYiOw0KCWNvbG9yOmJsYWNrOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglmb250LXN0eWxl Om5vcm1hbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1 YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91 dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpz aGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkZSIiBs aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNr Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+U3BlYWtpbmcg YXMgYW4gb3BlcmF0b3IsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5BcyBpdCB0dXJucyBv dXQsIHdlIGRvIHVzZSBkaWNob3RvbXkgJm5ic3A7ZXZlcnkgZGF5IGZvciB0cm91Ymxlc2hvb3Rp bmcsIG1vdmluZyBhIHNpbmdsZSBjYXB0dXJlIHBvaW50IGFyb3VuZCB3aGVyZSBwb3NzaWJsZS48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+Rm9yIHRoaXMgcmVhc29uLCB3 ZSBhcmUgdmVyeSBhbnhpb3VzIHRvIHNlZSB0aGUgbmVjZXNzYXJ5IGNsZWFyIGZpZWxkcyBsYW5k IGluIFFVSUMgdG8ga2VlcCBkb2luZyB0aGlzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MTAuMHB0O21hcmdpbi1y aWdodDowY207bWFyZ2luLWJvdHRvbToxMC4wcHQ7bWFyZ2luLWxlZnQ6MGNtO3RleHQtYXV0b3Nw YWNlOm5vbmUiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48aW1n IHdpZHRoPSIzMiIgaGVpZ2h0PSIzMiIgaWQ9IkltYWdlX3gwMDIwXzEiIHNyYz0iY2lkOmltYWdl MDAyLnBuZ0AwMUQzNUVFQS43MEZBRDAwMCIgYWx0PSJjaWQ6aW1hZ2UwMDIucG5nQDAxRDAzQzk3 LjgxMTYxMjYwIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQt YXV0b3NwYWNlOm5vbmUiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2si PklzYWJlbGxlIEhBTUNIQU9VSTxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48YSBocmVm PSJodHRwOi8vb25lLWRpcmVjdG9yeS5zc28uZnJhbmNldGVsZWNvbS5mci9hbm51YWlyZS9lbnRp dGUuZG8/YWN0aW9uPVZpZXcmYW1wO3VpZD0lMjMlMDAlN0UlMEYlMDREJTBBJTA3cSUxMC0lMUQl MTklMUMlMEMlMTclM0ZZJTI3JTBBTSUwMSUwQiUwNiUzRSUxNC0lMDclMDUlMDklMEMlMDAlMjlZ JTI3JTBBTSUwRSUxNyUxMyUyMiUxNiUyNiUxRCUxNSUwNCUwMCUxMSUyMyUxOG8lMEQlMTNVJTAz JTAwIiB0aXRsZT0iRnJhbmNlIFTDqWzDqWNvbSI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3Rl eHQtZGVjb3JhdGlvbjpub25lIj5PcmFuZ2U8L3NwYW4+PC9hPi88YSBocmVmPSJodHRwOi8vb25l LWRpcmVjdG9yeS5zc28uZnJhbmNldGVsZWNvbS5mci9hbm51YWlyZS9lbnRpdGUuZG8/YWN0aW9u PVZpZXcmYW1wO3VpZD0lMjMlMDAlN0UlMDYlMUMlMDYlMDYlNUUlMjMlMDAlN0UlMEYlMDREJTBB JTA3cSUxMC0lMUQlMTklMUMlMEMlMTclM0ZZJTI3JTBBTSUwMSUwQiUwNiUzRSUxNC0lMDclMDUl MDklMEMlMDAlMjlZJTI3JTBBTSUwRSUxNyUxMyUyMiUxNiUyNiUxRCUxNSUwNCUwMCUxMSUyMyUx OG8lMEQlMTNVJTAzJTAwIiB0aXRsZT0iT3JhbmdlIExhYnMgTmV0d29ya3MgYW5kIENhcnJpZXJz Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2s7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPklNVDwvc3Bh bj48L2E+LzxhIGhyZWY9Imh0dHA6Ly9vbmUtZGlyZWN0b3J5LnNzby5mcmFuY2V0ZWxlY29tLmZy L2FubnVhaXJlL2VudGl0ZS5kbz9hY3Rpb249VmlldyZhbXA7dWlkPSUyMyUwMCU3RSUwNiUxQyUw NkklMUQ5SCUyQyUwNSUxRSUwQkklMUQ5SCUyNSUxRCU1QyUwNyUxME8lMjklMUI3JTAwJTA0JTAx JTAwJTAxJTYwJTExJiM0MztUJTE5JTA2JTExJTAwLSUxQi0lMUMlMTElMDElMTclMTclNjAlMTEm IzQzO1QlMTYlMUElMDQlMUMlMkYlMTA3JTBDJTFDJTBEJTA2JTFEJTIxWSUyNyUwQU0lMEUlMTci IHRpdGxlPSJPcmFuZ2UgTGFicyBOZXR3b3JrcyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrO3Rl eHQtZGVjb3JhdGlvbjpub25lIj5PTE48L3NwYW4+PC9hPi88YSBocmVmPSJodHRwOi8vb25lLWRp cmVjdG9yeS5zc28uZnJhbmNldGVsZWNvbS5mci9hbm51YWlyZS9lbnRpdGUuZG8/YWN0aW9uPVZp ZXcmYW1wO3VpZD0lMjMlMDAlN0UlMUUlMDQlMEJJJTFEOUglMkMlMDUlMUVEJTBBJTA3cSUxQSUy RiUwNyUxM0QlMEElMDdxJTEzN0UlMUYlMURYJTE3JTIyJTAxKiUxRCUxOSUwRCUxNiU1RSUyOCUx NiU3RSUwMCUxRSUxQyUxNyUxMyUyMiUxQjYlMDglMTklMUElMDAlNUUlMjglMTYlN0UlMEYlMDIl MDklMEIlMTElMjklMDElMjYlMDUlMTUlMEIlMEElMUYlNjAlMTEmIzQzO1QlMTYlMUEiIHRpdGxl PSJXaXJlbGluZSBhbmQgVHJhbnNwb3J0IENvbnZlcmdlbnQgbmV0d29ya3MiPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjazt0ZXh0LWRlY29yYXRpb246bm9uZSI+V1RDPC9zcGFuPjwvYT4vSUVFPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0 b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6YmxhY2siPnTDqWwu ICYjNDM7MzMgMiA5NiAwNyAxNCA5Mg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNlOm5vbmUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6YmxhY2siPk1vYi4gJiM0MzszMyA2IDg1IDM3IDAyIDkyPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtYXV0b3NwYWNl Om5vbmUiPjxiPjx1PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6I0YwNzIwQSI+PGEg aHJlZj0ibWFpbHRvOmlzYWJlbGxlLmhhbWNoYW91aUBvcmFuZ2UuY29tIj5pc2FiZWxsZS5oYW1j aGFvdWlAb3JhbmdlLmNvbTwvYT48L3NwYW4+PC91PjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOiNGMDcyMEEiPjxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+RGUmbmJzcDs6PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90OyI+IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRGIFttYWlsdG86c3BlbmNlcmRhd2tp bnMuaWV0ZkBnbWFpbC5jb21dDQo8YnI+DQo8Yj5FbnZvecOpJm5ic3A7OjwvYj4gamV1ZGkgMTYg bm92ZW1icmUgMjAxNyAwMToyOTxicj4NCjxiPsOAJm5ic3A7OjwvYj4gTWFydGluIER1a2U8YnI+ DQo8Yj5DYyZuYnNwOzo8L2I+IFBpb3RyIEdhbGVja2k7IGdvcnJ5QGVyZy5hYmRuLmFjLnVrOyBJ YW4gU3dldHQ7IFFVSUMgV0c7IE1PUlRPTiwgQUxGUkVEIEMgKEFMKTsgU1RFUEhBTiBFbWlsZSBJ TVQvT0xOPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBSZTogc3BpbiBiaXQgaW4gUVVJQzogdHJv dWJsZXNob290aW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3BlYWtp bmcgYXMgYSBjdXJpb3VzIGluZGl2aWR1YWwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+T24gVGh1LCBOb3YgMTYsIDIwMTcgYXQgNjo1NCBBTSwgTWFydGluIER1a2UgJmx0 OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbSIgdGFyZ2V0PSJfYmxhbmsi Pm1hcnRpbi5oLmR1a2VAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UGFja2V0IG51bWJlcnMgYXJlIHVuZW5jcnlwdGVk IGFuZCBtb25vdG9uaWNhbGx5IGluY3JlYXNpbmcuIEl0IGlzIHRoZXJlZm9yZSByZWxhdGl2ZWx5 IHN0cmFpZ2h0Zm9yd2FyZCB0byBtZWFzdXJlIHJlb3JkZXJpbmcgYmV0d2VlbiBhbnkgdHdvIHBv aW50cyBpbiB0aGUgbmV0d29yayBpZiB5b3UgaGF2ZSBpbnN0cnVtZW50cyB0aGVyZS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIHRoYXQn cyBjZXJ0YWlubHkgdGhlIHdheSBjYXJyaWVycyB3ZXJlIG1vbml0b3JpbmcgbGFyZ2UgbmV0d29y a3Mgd2hlbiBJIHdhcyB3b3JraW5nIGluIHRoYXQgc3BhY2UgaW4gdGhlIG1pZC0yMDAwcy4gSXQn cyBhbHNvIHRoZSBkaXJlY3Rpb24gSSBzZWUgaW4gcmVjZW50IElQUE0gZG9jcyBJJ3ZlIHNoZXBo ZXJkZWQsIElJVUMuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPk1vbml0b3JpbmcgYXQgb25lIHBvaW50IGluIHRoZSBuZXR3b3JrIHdv dWxkIGJlIGF3ZXNvbWUsIGJ1dCBpdCB3b3VsZCBiZSBhIHBsZWFzYW50IHN1cnByaXNlIGlmIG9w ZXJhdG9ycyBhcmUgZG9pbmcgaXQgbm93LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGVuY2VyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0Mg MS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4t cmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFR1ZSwg Tm92IDE0LCAyMDE3IGF0IDk6NTkgUE0sIFBpb3RyIEdhbGVja2kgJmx0OzxhIGhyZWY9Im1haWx0 bzpwaW90cl9nYWxlY2tpQGFmZmlybWVkbmV0d29ya3MuY29tIiB0YXJnZXQ9Il9ibGFuayI+cGlv dHJfZ2FsZWNraUBhZmZpcm1lZG5ldHdvcmtzLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SG93IHdvdWxkIGEgbmV0d29yayBwcm9iZSBiZSBh YmxlIHRvIG1lYXN1cmUgdGhlIGxldmVsIG9mIHBhY2tldCByZW9yZGVyaW5nIGluIFFVSUMgc3Ry ZWFtIHdpdGggb25seSBhIHNwaW4gYml0Pzxicj4NCjxicj4NCkknbSBhc2tpbmcgYmVjYXVzZSBv bmUgb2YgdGhlIGNvbW1vbiB0ZWNobmlxdWVzIHRvIGRpYWdub3NlIG5ldHdvcmsgaXNzdWVzPGJy Pg0KaXMgdG8gaW5zZXJ0IGEgcHJvYmUgaW4gZGlmZmVyZW50IHBvaW50cyBpbiB0aGUgbmV0d29y ayBhbmQgbWVhc3VyZTo8YnI+DQoqIFJUVDxicj4NCiogVENQIHNlZ21lbnQgbG9zczxicj4NCiog VENQIHNlZ21lbnQgcmV0cmFuc21pc3Npb25zPGJyPg0KKiBUQ1Agc2VnbWVudCBvdXQtb2Ytb3Jk ZXI8YnI+DQphcyBhIGZldyBiYXNpYyBkYXRhIHBvaW50cy48YnI+DQpXaXRoIG1lYXN1cmVtZW50 cyBpbiBwb2ludCBBIGFuZCBwb2ludCBCIG9uZSBjYW4gZGV0ZXJtaW5lIGZvciBleGFtcGxlIGlm IGEgbmV0d29yayBkZXZpY2UgaXMgbWlzb3JkZXJpbmcgcGFja2V0cy48YnI+DQo8c3BhbiBzdHls ZT0iY29sb3I6Izg4ODg4OCI+PGJyPg0KPHNwYW4gY2xhc3M9Im0tNzE5NzMyOTAzNDI0ODc4Nzcy NWhvZW56YiI+LVBpb3RyPC9zcGFuPjxicj4NCjwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0ibS03 MTk3MzI5MDM0MjQ4Nzg3NzI1aW0iPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPC9zcGFuPjxi cj4NCjxzcGFuIGNsYXNzPSJtLTcxOTczMjkwMzQyNDg3ODc3MjVpbSI+RnJvbTogUVVJQyBbbWFp bHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgR29ycnkgRmFpcmh1cnN0 PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtLTcxOTczMjkwMzQyNDg3ODc3MjVpbSI+U2VudDog V2VkbmVzZGF5LCBOb3ZlbWJlciAxNSwgMjAxNyAxMjo0OCBBTTwvc3Bhbj48YnI+DQo8c3BhbiBj bGFzcz0ibS03MTk3MzI5MDM0MjQ4Nzg3NzI1aW0iPlRvOiBNT1JUT04sIEFMRlJFRCBDIChBTCkg Jmx0OzxhIGhyZWY9Im1haWx0bzphY21vcnRvbkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+YWNt b3J0b25AYXR0LmNvbTwvYT4mZ3Q7PC9zcGFuPjxicj4NCjxzcGFuIGNsYXNzPSJtLTcxOTczMjkw MzQyNDg3ODc3MjVpbSI+Q2M6IElhbiBTd2V0dCAmbHQ7PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0 QGdvb2dsZS5jb20iIHRhcmdldD0iX2JsYW5rIj5pYW5zd2V0dEBnb29nbGUuY29tPC9hPiZndDs7 IFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFu ayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7Ow0KPGEgaHJlZj0ibWFpbHRvOmVtaWxlLnN0ZXBoYW5A b3JhbmdlLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVtaWxlLnN0ZXBoYW5Ab3JhbmdlLmNvbTwvYT48 L3NwYW4+PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlN1YmplY3Q6IFJlOiBzcGluIGJpdCBpbiBRVUlDOiB0cm91Ymxlc2hvb3Rpbmc8YnI+DQo8YnI+ DQpBcyBJIHNhaWQgYXQgdGhlIG1pYzogSSB0aGluayB0aGUgc3Bpbi1iaXQgYW5hbHlzaXMgd2Fz IGhlbHBmdWwsIHRoYW5rcy48YnI+DQo8YnI+DQpJIGNhbiBzZWUgaG93IHNwaW4tYml0IGlzIHJl YWxseSB1c2VmdWwgdG8gZ2V0IGJhc2ljIGRpYWdub3N0aWNzIG9mIFJUVCBpZiBpdCBjYW4gYmUg cmVsaWVkIHRvIGJlIHByZXNlbnQgaW4gZXZlcnkgcGFja2V0LiAoSXQgaXMgaW1wb3J0YW50IHRv IG1lYXN1cmUgbGF0ZW5jeSB3aXRoaW4gdGhlIG5ldHdvcmspLjxicj4NCjxicj4NClRoZXJlIGFy ZSBwbGFjZXMgd2hlcmUgMS1iaXQgZ2l2ZXMgcmVzdHJpY3RlZCB2YWx1ZSwgYW5kIHVzaW5nIG1v cmUgd291bGQgaGVscDogTXkgYWRkaXRpb25hbCBjb21tZW50IGF0IHRoZSBNaWMgcmVsYXRlZCB0 byBob3cgbXVjaCBleHRyYSB3b3VsZCBiZSB0aGUgZ2FpbiBmcm9tIGFuIGFkZGl0aW9uYWwgb25l IG9yIHR3byBiaXRzPzxicj4NCjxicj4NCkluIHBhcnRpY3VsYXIsIEknZCBsaWtlIHRvIHNlZSBh IG1ldGhvZCB0aGF0IGNhbiBsZXQgbWUgZGV0ZWN0IHNvbWUgbG9zcyBwYXR0ZXJucyBhbmQgbWVh c3VyZSByZW9yZGVyaW5nLCBhdCBsZWFzdCBJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBrbm93 IGFuZCBtZWFzdXJlIHdoZW4gdGhlcmUgaXMgc21hbGwtc2NhbGUgcmVvcmRlcmluZyAmbHQ7My48 YnI+DQo8YnI+DQpBIHN1Z2dlc3Rpb246aXMgdG8gdXNlIGEgMi1iaXQgY291bnRlciBmb3IgdGhl IHNwaW4gKDxicj4NCjAwLSZndDswMS0mZ3Q7MTAtJmd0OzExLSZndDswMCksIHRoYXQgd291bGQg aGVscCBkZXRlY3QgdGhlc2UgcGF0aCBhbm9tbGllcy48YnI+DQo8YnI+DQpHb3JyeTxicj4NCjxi cj4NCk9uIDE1LzExLzIwMTcsIDA5OjUxLCBNT1JUT04sIEFMRlJFRCBDIChBTCkgd3JvdGU6PGJy Pg0KJmd0Ozxicj4NCiZndDsgSeKAmWQgbGlrZSB0byBvZmZlciBzdXBwb3J0IGZvciBTcGluIEJp dCAoYW5kIG9uZSBvciB0d288YnI+DQomZ3Q7PGJyPg0KJmd0OyBiaXRzIGZvciBtYW5hZ2VtZW50 IGlmIHRoZXkgY2FuIGJlIGp1c3RpZmllZCBxdWlja2x5KSBpbiB2MS48YnI+DQomZ3Q7PGJyPg0K Jmd0OyBPbiB0aGlzIHRvcGljIG9mIG1vcmUgYml0cyw8YnI+DQomZ3Q7PGJyPg0KJmd0OyBhc2tp bmcgZnVydGhlciBjbGFyaWZpY2F0aW9uIGZyb20gRW1pbGUsIGJlbG93IFtBQ01dLjxicj4NCiZn dDs8YnI+DQomZ3Q7IEFsPGJyPg0KJmd0Ozxicj4NCiZndDsgKkZyb206KlFVSUMgW21haWx0bzo8 YSBocmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+cXVp Yy1ib3VuY2VzQGlldGYub3JnPC9hPl0gKk9uIEJlaGFsZiBPZiAqSWFuIFN3ZXR0PGJyPg0KJmd0 OyAqU2VudDoqIFR1ZXNkYXksIE5vdmVtYmVyIDE0LCAyMDE3IDQ6MjEgUE08YnI+DQomZ3Q7ICpU bzoqIDxhIGhyZWY9Im1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20iIHRhcmdldD0iX2Js YW5rIj5lbWlsZS5zdGVwaGFuQG9yYW5nZS5jb208L2E+PGJyPg0KJmd0OyAqQ2M6KiBRVUlDIFdH PGJyPg0KJmd0OyAqU3ViamVjdDoqIFJlOiBzcGluIGJpdCBpbiBRVUlDOiB0cm91Ymxlc2hvb3Rp bmc8YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGFua3MgZm9yIGNsYXJpZnlpbmcgRW1pbGUuPGJyPg0K Jmd0Ozxicj4NCiZndDsgT24gVHVlLCBOb3YgMTQsIDIwMTcgYXQgMTowNiBQTSwgJmx0OzxhIGhy ZWY9Im1haWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5lbWls ZS5zdGVwaGFuQG9yYW5nZS5jb208L2E+PGJyPg0KJmd0OyAmbHQ7bWFpbHRvOjxhIGhyZWY9Im1h aWx0bzplbWlsZS5zdGVwaGFuQG9yYW5nZS5jb20iIHRhcmdldD0iX2JsYW5rIj5lbWlsZS5zdGVw aGFuQG9yYW5nZS5jb208L2E+Jmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgSGkg SWFuLDxicj4NCiZndDs8YnI+DQomZ3Q7IEl0IHdhcyBzdWdnZXN0ZWQgaW4gdGhlIGxhdGVzdCBk aXNjdXNzaW9uIG9uIHRoZSBSVFQgZGVzaWduIHRlYW08YnI+DQomZ3Q7IG1haWxpbmcgbGlzdCB0 byBoYXZlIG9uZSBiaXQgZm9yIHBhY2tldCBsb3N0LCBvbmUgZm9yIGxhdGVuY3kgKHNwaW48YnI+ DQomZ3Q7IGJpdCBvciBlcS4pIGFuZCBvbmUgZm9yIGNvbmdlc3Rpb24uPGJyPg0KJmd0Ozxicj4N CiZndDsgKi9bQUNNXSAvKiBUaGVyZSBtYXkgYmUgc29tZSBvdmVybGFwIHdpdGggRUNOIGFuZCDC qyBvbmUgYml0IGZvcjxicj4NCiZndDsgY29uZ2VzdGlvbiDCuy48YnI+DQomZ3Q7PGJyPg0KJmd0 OyBEaWQgeW91IGFsc28gY29uc2lkZXIgdGhpcyBkZXBlbmRlbmN5LCBFbWlsZSA/IChJ4oCZbSBl Y2hvaW5nIGEgaGFsbHdheTxicj4NCiZndDsgZGlzY3Vzc2lvbik8YnI+DQomZ3Q7PGJyPg0KJmd0 OyBJdCBzZWVtcyBhIHNpbXBsaXN0aWMgYXBwcm9hY2ggb24gb25lIGhhbmQgYnV0IGFuIGludmFy aWFudCBvbiB0aGU8YnI+DQomZ3Q7IGxvbmcgdGVybS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBSZWdh cmRzPGJyPg0KJmd0Ozxicj4NCiZndDsgRW1pbGU8YnI+DQomZ3Q7PGJyPg0KJmd0OyAqRGUgOipJ YW4gU3dldHQgW21haWx0bzo8YSBocmVmPSJtYWlsdG86aWFuc3dldHRAZ29vZ2xlLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmlhbnN3ZXR0QGdvb2dsZS5jb208L2E+PGJyPg0KJmd0OyAmbHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzppYW5zd2V0dEBnb29nbGUuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWFu c3dldHRAZ29vZ2xlLmNvbTwvYT4mZ3Q7XSAqRW52b3nDqSA6KiBtYXJkaSAxNCBub3ZlbWJyZSAy MDE3IDIyOjUxPGJyPg0KJmd0OyAqw4AgOiogU1RFUEhBTiBFbWlsZSBJTVQvT0xOICpDYyA6KiBR VUlDIFdHICpPYmpldCA6KiBSZTogc3BpbiBiaXQgaW48YnI+DQomZ3Q7IFFVSUM6IHRyb3VibGVz aG9vdGluZzxicj4NCiZndDs8YnI+DQomZ3Q7IFdoYXQgd291bGQgdGhlIG90aGVyIGJpdCBvciB0 d28gYmUgdXNlZCBmb3I/Jm5ic3A7IElmIHRoZXJlIGlzIG5vPGJyPg0KJmd0OyBzdGFuZGFyZGl6 ZWQgdXNlIG9mIHRob3NlIGJpdHMgaW4gdjEsIHRoZW4gSSBiZWxpZXZlIHdlIHNob3VsZCB3YWl0 IHRvPGJyPg0KJmd0OyByZXNlcnZlIHRoZW0gd2hlbiB0aGVpciB1c2FnZSBpcyBkZWZpbmVkLCBn aXZlbiB3ZSdkIG5lZWQgYSB2ZXJzaW9uPGJyPg0KJmd0OyBidW1wIHRvIHNwZWNpZnkgaG93IHRo ZXkgd2VyZSBiZWluZyB1c2VkLiZuYnNwOyBBdCB0aGUgbW9tZW50LCB0aGU8YnI+DQomZ3Q7IG1h bmFnZW1lbnQgdXNlIGNhc2UgaXMgbm90IGNvbXBldGluZyB3aXRoIGFueW9uZSBlbHNlIGZvciBi aXRzIGluIHRoZTxicj4NCiZndDsgc2hvcnQgaGVhZGVyLjxicj4NCiZndDs8YnI+DQomZ3Q7IE9u IFR1ZSwgTm92IDE0LCAyMDE3IGF0IDU6MTQgQU0sICZsdDs8YSBocmVmPSJtYWlsdG86ZW1pbGUu c3RlcGhhbkBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZW1pbGUuc3RlcGhhbkBvcmFuZ2Uu Y29tPC9hPjxicj4NCiZndDsgJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86ZW1pbGUuc3RlcGhh bkBvcmFuZ2UuY29tIiB0YXJnZXQ9Il9ibGFuayI+ZW1pbGUuc3RlcGhhbkBvcmFuZ2UuY29tPC9h PiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IEhpPGJyPg0KJmd0Ozxicj4NCiZn dDsgTGFzdCB3ZWVrIE9yYW5nZSBleHBlcmllbmNlZCBhIGZhbGxiYWNrIG9mIFFVSUMgdG8gVENQ IG9uIG9uZSBvZiBpdHM8YnI+DQomZ3Q7IG5ldHdvcmtzLiBUaGUgaXNzdWVzIHdlcmUgbm90IHZp c2libGUgaW4gUVVJQyB0cmFmZmljLiBUaGU8YnI+DQomZ3Q7IHRyb3VibGVzaG9vdGluZyB3YXMg bWFkZSB1c2luZyBUQ1AgcGFja2V0cyBpbmZvcm1hdGlvbi4gVGhpcyBpcyBub3Q8YnI+DQomZ3Q7 IHN1c3RhaW5hYmxlIG9uIHRoZSBsb25nIHRlcm0gd2hlbiBudW1lcm91cyBhcHBsaWNhdGlvbnMg dXNpbmc8YnI+DQomZ3Q7IGRpZmZlcmVudCB2ZXJzaW9ucyBvZiBRVUlDIHdpbGwgc3RvcCB0byBm YWxsYmFjayB0byBUQ1AuPGJyPg0KJmd0Ozxicj4NCiZndDsgQmFzZWQgb24gdGhlIGV4Y2hhbmdl IHdlIGhhZCBpbiB0aGUgUlRUIGRlc2lnbiB0ZWFtIGFuZCBpbiB0b2RheTxicj4NCiZndDsgbWVl dGluZyAsIGl0IHNvdW5kcyByZWFzb25hYmxlIHRvIHJlc2VydmUgYXQgbGVhc3QgMiBiaXRzIChp ZGVhbGx5IDM8YnI+DQomZ3Q7IGJpdHMgYXMgZGlzY3Vzc2VkIGluIHRoZSBkZXNpZ24gdGVhbSkg Zm9yIG1hbmFnZWFiaWxpdHkgaW4gdGhlIFFVSUM8YnI+DQomZ3Q7IGludmFyaWFudHMgYW5kIHRv IHN0YXJ0IGV4cGVyaW1lbnRpbmcgdGhlIHNwaW4gYml0IGluIFFVSUMgVjEuPGJyPg0KJmd0Ozxi cj4NCiZndDsgUmVnYXJkczxicj4NCiZndDs8YnI+DQomZ3Q7IEVtaWxlPGJyPg0KJmd0Ozxicj4N CiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0Ozxicj4NCiZndDsgQ2UgbWVzc2FnZSBl dCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zPGJy Pg0KJmd0OyBjb25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9u YyBwYXMgZXRyZSBkaWZmdXNlcyw8YnI+DQomZ3Q7IGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBh dXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2U8YnI+DQomZ3Q7IHBhciBl cnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyIGEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJl IGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVz IGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sIE9yYW5nZSBkZWNsaW5lIHRvdXRlIHJl c3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNp ZmllLiBNZXJjaS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBUaGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRh Y2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3I8YnI+DQomZ3Q7IHByaXZpbGVnZWQg aW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsgdGhleSBzaG91bGQgbm90 IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uPGJy Pg0KJmd0OyBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2ht ZW50cy48YnI+DQomZ3Q7IEFzIGVtYWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBs aWFibGUgZm9yIG1lc3NhZ2VzIHRoYXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZh bHNpZmllZC48YnI+DQomZ3Q7IFRoYW5rIHlvdS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQomZ3Q7PGJyPg0KJmd0OyBDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMg am9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnM8YnI+DQomZ3Q7IGNvbmZp ZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jIHBhcyBldHJlIGRp ZmZ1c2VzLDxicj4NCiZndDsgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4g U2kgdm91cyBhdmV6IHJlY3UgY2UgbWVzc2FnZTxicj4NCiZndDsgcGFyIGVycmV1ciwgdmV1aWxs ZXogbGUgc2lnbmFsZXIgYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxl cyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2Vw dGlibGVzIGQnYWx0ZXJhdGlvbiwgT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUg c2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLjxi cj4NCiZndDs8YnI+DQomZ3Q7IFRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBj b250YWluIGNvbmZpZGVudGlhbCBvcjxicj4NCiZndDsgcHJpdmlsZWdlZCBpbmZvcm1hdGlvbiB0 aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3OyB0aGV5IHNob3VsZCBub3QgYmUgZGlzdHJpYnV0 ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi48YnI+DQomZ3Q7IElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLjxicj4NCiZn dDsgQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVz c2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLjxicj4N CiZndDsgVGhhbmsgeW91Ljxicj4NCiZndDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxQ UkU+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2VzIGpvaW50ZXMgcGV1dmVudCBjb250 ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxlcyBvdSBwcml2aWxlZ2llZXMgZXQg bmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBleHBsb2l0ZXMgb3UgY29waWVzIHNh bnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBjZSBtZXNzYWdlIHBhciBlcnJldXIs IHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVyIGV0IGxlIGRldHJ1aXJlIGFpbnNp IHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdlcyBlbGVjdHJvbmlxdWVzIGV0YW50 IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBkZWNsaW5lIHRvdXRlIHJlc3BvbnNh YmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBkZWZvcm1lIG91IGZhbHNpZmllLiBN ZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNvbmZp ZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRoYXQgbWF5IGJlIHByb3RlY3RlZCBi eSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRlZCwgdXNlZCBvciBjb3BpZWQgd2l0 aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBhbHRlcmVkLCBPcmFuZ2UgaXMgbm90 IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4gbW9kaWZpZWQsIGNoYW5nZWQgb3Ig ZmFsc2lmaWVkLgpUaGFuayB5b3UuCjwvUFJFPjwvYm9keT4NCjwvaHRtbD4NCg== --_000_d3c183d8a3a0480ca1e519601e9b72f0OPEXCLILM5Fcorporateadr_-- --_004_d3c183d8a3a0480ca1e519601e9b72f0OPEXCLILM5Fcorporateadr_ Content-Type: image/png; name="image002.png" Content-Description: image002.png Content-Disposition: inline; filename="image002.png"; size=962; creation-date="Thu, 16 Nov 2017 13:51:54 GMT"; modification-date="Thu, 16 Nov 2017 13:51:54 GMT" Content-ID: Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0IArs4c6QAAAAlwSFlzAAAO xAAADsQBlSsOGwAAABl0RVh0U29mdHdhcmUATWljcm9zb2Z0IE9mZmljZX/tNXEAAANCSURBVFhH 7ZdLSFRxFMa/ybEZTE3JHiZh2tMsJaJFLyNLJKI2QUQtchH22NQqaNkiWtWyiKigRS2ijVlB9A4x g8yCCjG0h+mIjxrTScuZ6Xfm3ltCrWd1L/y9/9c533e+c85wDSbqlVSan0AAwCmMuJYF04z9D5xP wFfAV8BXwFfAV8BXwFfAVyC9Cnhfn/ZN6D7pJZAA1Rth5qD/JWAHEwxj5+3G3bV9wRp7W9s8w3Vk e2bn2dja82F7ds/2fjIy2SiukMJ52OBoqEPq6nOhPPDcmYBweyQqTTUH/MmATdJFyZkuxb7hcAwi MAlkSjnZ0niMvR+OqNn5AHD/J3vxXw7B6eYX0GCONHcF6xlSKxhfjYBdEI427pM21AEwLDWc5D0g bTsOEGG8bJDyiqQl66XBbunJBal0tbRgHQRwFu2Rrp8gwkqp5jCgAEf7pIfnHcBVO6RRAJuuSM1X IQmRH/1SoYk9Dn7ZGqn6EEB3YDdHqj0ivWa+qEpquyVFkCucKw0PSRVbcY5x8UopNA2b2xDfI63e DsFNUne7o9DaXQ6J8lqph715yL+pXrp00PGDqeARTOW1cDFyEumN01LJUqmOd0GJ1PtOunUGcG4W lZG3j0QyKGWRR8vx+2fS80apskaas0jKh/ydc0SHApWbpdkLASlA6rvSAEHEiTZMWgO8rZaol2Bq 0gtDy9fOY0g9CyBkjkY4JTUBbpVXS8uJ/MlFh6g9lppMzkMhnFIHZmMFtmW/UwMh9noIoGA+fgAd o3YGupx6MfJuSwZl7dDZLD04i5TUgdVA4ynYcTGP4kkiZ/t9JEeB2aXcJeqPLcj4hcgYcXLb8Zj9 VqkPgDW7yTFRh7JQ6IX0meCq9pKWYuzanA6Y1PzBVEBxomy6LL266SgRw2kQaSJEkGQ9Qs6vHXW6 4heEAm5/JgnD5la05rXmAKpYRNh2v5b6kT3ySfrwFL/cHUcFREup7v4YOSmwYd0wSuXbgfmw1kvQ kkbQWnKCNrNh556E3n+5CQJIMt7e4w6Ek5Cy+XfAKR/FKDp7LHLP3qmBgBXhsj+HbnpTa8+5/bCY oTH/32PndmbvljfSI4Y9tkfGUgFM9uv5s4Cz1fkbpxMUAcDPwqMAAAAASUVORK5CYII= --_004_d3c183d8a3a0480ca1e519601e9b72f0OPEXCLILM5Fcorporateadr_-- From nobody Thu Nov 16 11:46: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 A323E126C22 for ; Thu, 16 Nov 2017 11:46:43 -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, 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 XRaWs2YQRdHw for ; Thu, 16 Nov 2017 11:46:42 -0800 (PST) Received: from mailout1.telhc.bbc.co.uk (mailout1.telhc.bbc.co.uk [132.185.161.180]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD2851201F2 for ; Thu, 16 Nov 2017 11:46:41 -0800 (PST) Received: from BGB01XI1001.national.core.bbc.co.uk ([10.184.50.51]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vAGJkdT8005321 for ; Thu, 16 Nov 2017 19:46:39 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1001.national.core.bbc.co.uk ([10.184.50.51]) with mapi id 14.03.0361.001; Thu, 16 Nov 2017 19:46:39 +0000 From: Lucas Pardue To: IETF QUIC WG Subject: Connection coalescing aka. HTTP/2 Connection reuse Thread-Topic: Connection coalescing aka. HTTP/2 Connection reuse Thread-Index: AdNfEgZq4vMpcfW9SnGtSL73Xb0d2A== Date: Thu, 16 Nov 2017 19:46:39 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BA9C346@bgb01xud1012> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.211] x-exclaimer-md-config: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23470.001 x-tm-as-result: No--13.960400-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 19:46:44 -0000 Hello, To start, this area is distinct from the connection migration discussion. RFC 7540 Section 9.1.1 discusses connection reuse, also known informally as= h2 connection coalescing. I wondered how the HTTP/QUIC mapping handled this concept but a search didn= 't yield me an answer. I wondered if the concept was more transport-level b= ut couldn't find anything there either. Is this a "thing" in QUIC? Are there any special consideration that need be= paid, apart from the mechanical transpilation? Kind regards Lucad ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specif= ically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From nobody Thu Nov 16 11: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 0E93A1205D3 for ; Thu, 16 Nov 2017 11:58:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.731 X-Spam-Level: X-Spam-Status: No, score=-0.731 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, 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=fb.com header.b=lKmW55He; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=NZJN4U8S Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BtOlYyKrkdF4 for ; Thu, 16 Nov 2017 11:58:17 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 8E5F91201F2 for ; Thu, 16 Nov 2017 11:58:17 -0800 (PST) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vAGJvL5k032752; Thu, 16 Nov 2017 11:58:16 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=MiajBkPCvEN9jo7DzSJTQ68BxTrDKbrUeNCAUDOVzWw=; b=lKmW55HeXlC0NFRLwzN0zcIb9ELCL9i/AqLQs2T+c46gBqOytXotmPigl7Tf0bROgTiB GfY4vXsIRki34KQV3rwjNwfIZn78pG3d9weah8MZCR1XdUFnwlaSWK7gmwkkeZ6I4M39 rywkGHhcssxQHh9FuU1qeUEXwGeXHYxEr1g= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2e9g83g7w5-16 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 16 Nov 2017 11:58:16 -0800 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.13) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 16 Nov 2017 11:58:12 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MiajBkPCvEN9jo7DzSJTQ68BxTrDKbrUeNCAUDOVzWw=; b=NZJN4U8SvoxOuIyNHjSSU9oTQF7faJf9+XBKe4G4H9GnFbGZKpnJvik95JLlIRWDzJ4lS+jwd5T9s/ForUXCcWUup7HGTxfpg0H/e5W34jMXMxUQtU9nGKtitzSKfssKZ5CC1sVaIlDKpqV6nciYcgKN1hTc21Wg8cltqFYahsU= Received: from MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) by MWHPR15MB1455.namprd15.prod.outlook.com (10.173.234.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Thu, 16 Nov 2017 19:58:11 +0000 Received: from MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) by MWHPR15MB1455.namprd15.prod.outlook.com ([10.173.234.145]) with mapi id 15.20.0218.015; Thu, 16 Nov 2017 19:58:11 +0000 From: Subodh Iyengar To: Patrick McManus , "Morten V. Pedersen" CC: IETF QUIC WG Subject: Re: Remote interop days Thread-Topic: Remote interop days Thread-Index: AQHTXqpltrrh85WP+0Su7C4XtR4mtaMWnLEAgAADGACAAA97gIAAAWIAgAADdoCAALY8Rw== Date: Thu, 16 Nov 2017 19:58:11 +0000 Message-ID: References: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> <868b3587-79c3-330b-641c-aee849f115c7@steinwurf.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::4:eec1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR15MB1455; 20:fehERWFtUdCWUEo1bS2Yfae6iexZN5IAc07Tvrh1J+10K5aNmzREvMbbl3Cnz8IjO4KVXNe4ZzEqyQYuEUrR7JGvFy5WRTc0DUPNXAwAa6NKeyt99a41hRE7h5PcUa8xUmLMYsOY92UOhL4DRgsfjqad+VLAPrlvCuTnXsz4Jto= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 35fc81db-f651-4c5e-57bd-08d52d2c5da7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:MWHPR15MB1455; x-ms-traffictypediagnostic: MWHPR15MB1455: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(11241501159)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(3231022)(10201501046)(6041248)(20161123558100)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR15MB1455; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR15MB1455; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(189002)(199003)(24454002)(2950100002)(316002)(54356999)(81166006)(966005)(6436002)(7116003)(110136005)(5660300001)(8936002)(86362001)(8676002)(229853002)(53936002)(81156014)(6506006)(7696004)(33656002)(3480700004)(106356001)(50986999)(25786009)(6306002)(54896002)(101416001)(97736004)(99286004)(68736007)(2900100001)(3280700002)(7736002)(236005)(19627405001)(76176999)(6116002)(2906002)(6606003)(93886005)(9686003)(53546010)(606006)(6246003)(478600001)(74316002)(189998001)(14454004)(105586002)(77096006)(3660700001)(4326008)(55016002)(102836003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR15MB1455; H:MWHPR15MB1455.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR15MB1455373EA39A42E0528B0D51B62E0MWHPR15MB1455namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 35fc81db-f651-4c5e-57bd-08d52d2c5da7 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 19:58:11.3508 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR15MB1455 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-16_06:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 19:58:20 -0000 --_000_MWHPR15MB1455373EA39A42E0528B0D51B62E0MWHPR15MB1455namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support this and would be happy to participate. A once per month cadence = would give me some time to build features to test during interop, and be fr= equent enough to give me the kick I need to keep updated with the latest dr= aft features. I imagine this would be a temporary thing for a few months until people bui= ld the tooling needed to keep their implementations running for longer with= self service options like being able to look at client and server logs. Subodh ________________________________ From: QUIC on behalf of Patrick McManus Sent: Thursday, November 16, 2017 12:55:59 AM To: Morten V. Pedersen Cc: IETF QUIC WG Subject: Re: Remote interop days if anyone in this thread would like a slack signup, just mail me (or just a= bout anyone else on the list :)) - happy to oblige. On Thu, Nov 16, 2017 at 4:43 PM, Morten V. Pedersen > wrote: You may also consider: https://zulipchat.com/ Fee and open source. - M On 11/16/2017 09:38 AM, Sebastiaan Deckers wrote: On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars > wrote: I think Slack unfortunately cannot be configured for public (unconfirmed) s= ignup. (We would do that if we could.) Suggestions (in no particular order nor exhaustive): - https://github.com/outsideris/slack-invite-automation - https://github.com/rauchg/slackin - https://publicslack.com --_000_MWHPR15MB1455373EA39A42E0528B0D51B62E0MWHPR15MB1455namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support this and would be happy to participate. A once per month caden= ce would give me some time to build features to test during interop, and be= frequent enough to give me the kick I need to keep updated with the l= atest draft features.


I imagine this would be a temporary thing for a few months until pe= ople build the tooling needed to keep their implementations running for lon= ger with self service options like being able to look at client and server = logs.


Subodh

From: QUIC <quic-bounces= @ietf.org> on behalf of Patrick McManus <pmcmanus@mozilla.com>
Sent: Thursday, November 16, 2017 12:55:59 AM
To: Morten V. Pedersen
Cc: IETF QUIC WG
Subject: Re: Remote interop days
 
if anyone in this thread would like a slack signup, just mail me (or j= ust about anyone else on the list :)) - happy to oblige.


On Thu, Nov 16, 2017 at 4:43 PM, Morten V. Ped= ersen <morten@steinw= urf.com> wrote:
You may also consider: https://zulipchat.com/
Fee and open source.

- M


On 11/16/2017 09:38 = AM, Sebastiaan Deckers wrote:
On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars <lars@netapp.= com> wrote:
I think Slack unfortunately cannot be configured for public (unconfirmed) s= ignup. (We would do that if we could.)

Suggestions (in no particular order nor exhaustive):


--_000_MWHPR15MB1455373EA39A42E0528B0D51B62E0MWHPR15MB1455namp_-- From nobody Thu Nov 16 15:49: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 977F91273E2 for ; Thu, 16 Nov 2017 15:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 xLfnmewrFEeC for ; Thu, 16 Nov 2017 15:49:29 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0129.outbound.protection.outlook.com [104.47.38.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5079124B09 for ; Thu, 16 Nov 2017 15:49:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yz7MQbtn2U/N/JQ8Wd50dcN7YhIb/OWynfrBb50hhWc=; b=HDo915z7XYAxZjRh3fgb/GoRQd/MIsAZ2l3WghIbZaJBMakE8EIowbkJ5CcCcNtCk9PRrIli8awuuLFpm8ueea3HN4+XTHo4eghmVXGJCrfMSnl14Aa1ntz9/HSDolt+Oof/ekhzn7OfmF86t1zbA7XznEA72Kxn0m/PiyCi5/U= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Thu, 16 Nov 2017 23:49:25 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0239.005; Thu, 16 Nov 2017 23:49:25 +0000 From: Mike Bishop To: Lucas Pardue , IETF QUIC WG Subject: RE: Connection coalescing aka. HTTP/2 Connection reuse Thread-Topic: Connection coalescing aka. HTTP/2 Connection reuse Thread-Index: AdNfEgZq4vMpcfW9SnGtSL73Xb0d2AAILDbg Date: Thu, 16 Nov 2017 23:49:25 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BA9C346@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BA9C346@bgb01xud1012> 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=mbishop@evequefou.be; x-originating-ip: [2001:67c:1232:144:682b:de3d:7e8a:a562] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2432; 6:0VnSZzaVHo8mqhxPvi7AMxrJ+ReIQEO++J62L4hs9yBoNiMCK6LVdJgwsRd0jTwyoqyFsl42RyygCOZ1qfqmr77n1eZTN8KK/zBwOioljCQOMQBDOjrPWCYdqr3Z+VKql6IyOhzUep2nR/Szo2pBsGUb5RAo9jMwSsIVxhyCC2Xbd31gya7c+iPivJJ9cr9QqzoxboKn0v6iQLBx2wiBaEVwq/+wjNdFBKkRycD8CPW/0uotKBtZ4wC6SUp4mtTjUqy9diEpYXvo10wVeFV+gA3pSvAWD3/rLR1Lb6qOcMS0qQUjYzKFso7UPZgrL/uvqsLFyT+peZVpc1kwCReAsUf7UMTqmPDO/wxK/l2QmBw=; 5:A/xUMnarUW4MvqC+GaBAth56VEzjnE8HYkfIDa6ochfqXgDPfu72w8SO4aX446WR0dxf1io7eAuC/0g3bZwEVDfr45st+IszI0flQvG0Yd6swhnkii/Jj+5Eh+U7DlOAoS0KHlaXhTpS7A4osymz5lSUeYwkMymlaHAFQLCm3ag=; 24:gZTFjTSHxlhutt3y5KbwFiJjFv7CVlZqWb0WFDezKHARcIAc/2tuLFg6Fyhqc6W/SS65NB6BzoW84tHrgUmzuV4+O52X3IHadW8cB8XeoNI=; 7:/AYT8HAuNf/EF22+bNJEdCm/8IOGyE+EZepbKqd2M5sq9z9ikpesvFMkaOvhd9i56IZdPclolWiPOp5tWEtTy9RmjGFeziZ9DmIKQ4r43eKQ5hlSeMY+mh66IM8tj3aaX2p0LVbAvdZsmX5Ul8Tt4lY7C4n9RSQDU+aDQLlAKJWs+1QmbcQnjKEzbzTMDJbYPx4R63gmeTL7w0erBehzje/3ebZ660SaQdeYMz3pg95xJ+iJYjPy8/3fegGOLkql x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b779b97f-7ead-4d6f-57d5-08d52d4cab3a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603199); SRVR:MWHPR08MB2432; x-ms-traffictypediagnostic: MWHPR08MB2432: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(204407124797145)(166708455590820)(227612066756510)(127952516941037)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3231022)(3002001)(10201501046)(6041248)(20161123558100)(201703131423075)(201703061421075)(20161123555025)(20161123564025)(20161123562025)(2016111802025)(20161123560025)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2432; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2432; x-forefront-prvs: 0493852DA9 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(189002)(38605003)(13464003)(199003)(33656002)(8676002)(81166006)(74316002)(5890100001)(9686003)(229853002)(105586002)(106356001)(6436002)(6506006)(54896002)(53386004)(236005)(6306002)(790700001)(508600001)(966005)(6116002)(25786009)(2900100001)(53936002)(102836003)(7736002)(77096006)(6246003)(81156014)(55016002)(8936002)(86362001)(53546010)(74482002)(5660300001)(99286004)(606006)(3660700001)(14454004)(110136005)(3280700002)(2950100002)(50986999)(7696004)(2906002)(101416001)(189998001)(54356999)(68736007)(97736004)(76176999); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2432; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB243246204A946C1F8D896A3EDA2E0MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: b779b97f-7ead-4d6f-57d5-08d52d4cab3a X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2017 23:49:25.3941 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2432 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 23:49:31 -0000 --_000_MWHPR08MB243246204A946C1F8D896A3EDA2E0MWHPR08MB2432namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable You're right, we should probably add some text on it. As a first pass, not= e that there is no way to directly address an HTTP/QUIC endpoint by URI/URL= . So an HTTP/QUIC endpoint is somewhat analogous to an HTTP/2 endpoint for= an origin which doesn't appear in the DNS record. With that as our starting point, here are some thoughts: * The only reason you're speaking HTTP/QUIC for example.com in the firs= t place is because you have an Alt-Svc record for example.com. If you have= Alt-Svc records for other origins that happen to share the same certificat= e pointing to the same host:port, this should be coalesced. * It seems a pity that you would need to speak individually to each = origin for this. Coincidentally, Ben Schwartz and I were having a conversa= tion about reviving Alt-Svc records in DNS.... * In the absence of Alt-Svc records, draft-ietf-httpbis-origin-frame pe= rmits coalescing in HTTP/2 based on the combination of the server's possess= ion of the correct certificate and assertion that it wants the traffic. Li= ke #371, there would need= to be a very short draft that defines the ORIGIN frame for HTTP/QUIC as Ex= ceptionally Similar(tm) to the one in draft-ietf-httpbis-origin-frame. I've opened #940 to track= this. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Lucas Pardue Sent: Friday, November 17, 2017 3:47 AM To: IETF QUIC WG Subject: Connection coalescing aka. HTTP/2 Connection reuse Hello, To start, this area is distinct from the connection migration discussion. RFC 7540 Section 9.1.1 discusses connection reuse, also known informally as= h2 connection coalescing. I wondered how the HTTP/QUIC mapping handled this concept but a search didn= 't yield me an answer. I wondered if the concept was more transport-level b= ut couldn't find anything there either. Is this a "thing" in QUIC? Are there any special consideration that need be= paid, apart from the mechanical transpilation? Kind regards Lucad ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal = views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender imme= diately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- --_000_MWHPR08MB243246204A946C1F8D896A3EDA2E0MWHPR08MB2432namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

You're right, we should probably add some text on= it.  As a first pass, note that there is no way to directly address a= n HTTP/QUIC endpoint by URI/URL.  So an HTTP/QUIC endpoint is somewhat= analogous to an HTTP/2 endpoint for an origin which doesn’t appear in the DNS record.

 

With that as our starting point, here are some th= oughts:

  • The only reaso= n you’re speaking HTTP/QUIC for example.com in the first place is bec= ause you have an Alt-Svc record for example.com.  If you have Alt-Svc = records for other origins that happen to share the same certificate pointing to the same host:port, this should be coales= ced.
    • It seems a pit= y that you would need to speak individually to each origin for this.  = Coincidentally, Ben Schwartz and I were having a conversation about revivin= g Alt-Svc records in DNS….
  • In the ab= sence of Alt-Svc records, draft-ietf-httpbis-origin-frame permits coalescin= g in HTTP/2 based on the combination of the server’s possession of th= e correct certificate and assertion that it wants the traffic.  Like #371, there would need to be a very short draft that defines= the ORIGIN frame for HTTP/QUIC as Exceptionally Similar™ to the one = in draft-ietf-httpbis-origin-frame.

 =

I= 217;ve opened #940 to tra= ck this.

 

-----Original Message-----
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Lucas Pardue
Sent: Friday, November 17, 2017 3:47 AM
To: IETF QUIC WG <quic@ietf.org>
Subject: Connection coalescing aka. HTTP/2 Connection reuse

 

Hello,

 

To start, this area is distinct from the connecti= on migration discussion.

 

RFC 7540 Section 9.1.1 discusses connection reuse= , also known informally as h2 connection coalescing.

 

I wondered how the HTTP/QUIC mapping handled this= concept but a search didn't yield me an answer. I wondered if the concept = was more transport-level but couldn't find anything there either.

 

Is this a "thing" in QUIC? Are there an= y special consideration that need be paid, apart from the mechanical transp= ilation?

 

Kind regards

Lucad

 

 

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

http://www.bbc.co.uk<= /o:p>

This e-mail (and any attachments) is confidential= and may contain personal views which are not the views of the BBC unless s= pecifically stated.

If you have received it in

error, please delete it from your system.

Do not use, copy or disclose the

information in any way nor act in reliance on it = and notify the sender immediately.

Please note that the BBC monitors e-mails sent or= received.

Further communication will signify your consent t= o this.

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

 

--_000_MWHPR08MB243246204A946C1F8D896A3EDA2E0MWHPR08MB2432namp_-- From nobody Thu Nov 16 18:03: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 3001D124239 for ; Thu, 16 Nov 2017 18:03:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.189 X-Spam-Level: X-Spam-Status: No, score=-4.189 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzKqmsREh--K for ; Thu, 16 Nov 2017 18:03:35 -0800 (PST) Received: from mailout0.telhc.bbc.co.uk (mailout0.telhc.bbc.co.uk [132.185.161.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 965E9126BF0 for ; Thu, 16 Nov 2017 18:03:35 -0800 (PST) Received: from BGB01XI1011.national.core.bbc.co.uk (bgb01xi1011.national.core.bbc.co.uk [10.161.14.15]) by mailout0.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id vAH23UHm014512; Fri, 17 Nov 2017 02:03:30 GMT Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1011.national.core.bbc.co.uk ([10.161.14.15]) with mapi id 14.03.0361.001; Fri, 17 Nov 2017 02:03:30 +0000 From: Lucas Pardue To: Mike Bishop , IETF QUIC WG Subject: RE: Connection coalescing aka. HTTP/2 Connection reuse Thread-Topic: Connection coalescing aka. HTTP/2 Connection reuse Thread-Index: AdNfEgZq4vMpcfW9SnGtSL73Xb0d2AAILDbgAAT7pyA= Date: Fri, 17 Nov 2017 02:03:29 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BA9C3E2@bgb01xud1012> References: <7CF7F94CB496BF4FAB1676F375F9666A3BA9C346@bgb01xud1012> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.19.161.212] x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23470.004 x-tm-as-result: No--24.522600-0.000000-31 x-tm-as-user-approved-sender: Yes x-tm-as-user-blocked-sender: No Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BA9C3E2bgb01xud1012_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 02:03:38 -0000 --_000_7CF7F94CB496BF4FAB1676F375F9666A3BA9C3E2bgb01xud1012_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Mike, Sounds like a good starter for ten. I'll follow that ticket. In simple terms, how do we imagine this would look once a client has decide= d to coalesce? Would it be a singular connection ID on which HTTP/QUIC HEAD= ER frames carry requests with different :authority pseudo-headers as requir= ed? I had initially worried there might be some complexities using a coalesced = connection but am coming around to thinking its not so bad. Deciding when a= nd what to coalesce seems like the trickier bit. Lucas From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: 16 November 2017 23:49 To: Lucas Pardue ; IETF QUIC WG Subject: RE: Connection coalescing aka. HTTP/2 Connection reuse You're right, we should probably add some text on it. As a first pass, not= e that there is no way to directly address an HTTP/QUIC endpoint by URI/URL= . So an HTTP/QUIC endpoint is somewhat analogous to an HTTP/2 endpoint for= an origin which doesn't appear in the DNS record. With that as our starting point, here are some thoughts: * The only reason you're speaking HTTP/QUIC for example.com in the firs= t place is because you have an Alt-Svc record for example.com. If you have= Alt-Svc records for other origins that happen to share the same certificat= e pointing to the same host:port, this should be coalesced. * It seems a pity that you would need to speak individually to each = origin for this. Coincidentally, Ben Schwartz and I were having a conversa= tion about reviving Alt-Svc records in DNS.... * In the absence of Alt-Svc records, draft-ietf-httpbis-origin-frame pe= rmits coalescing in HTTP/2 based on the combination of the server's possess= ion of the correct certificate and assertion that it wants the traffic. Li= ke #371, there would need= to be a very short draft that defines the ORIGIN frame for HTTP/QUIC as Ex= ceptionally Similar(tm) to the one in draft-ietf-httpbis-origin-frame. I've opened #940 to track= this. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Lucas Pardue Sent: Friday, November 17, 2017 3:47 AM To: IETF QUIC WG > Subject: Connection coalescing aka. HTTP/2 Connection reuse Hello, To start, this area is distinct from the connection migration discussion. RFC 7540 Section 9.1.1 discusses connection reuse, also known informally as= h2 connection coalescing. I wondered how the HTTP/QUIC mapping handled this concept but a search didn= 't yield me an answer. I wondered if the concept was more transport-level b= ut couldn't find anything there either. Is this a "thing" in QUIC? Are there any special consideration that need be= paid, apart from the mechanical transpilation? Kind regards Lucad ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal = views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender imme= diately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- --_000_7CF7F94CB496BF4FAB1676F375F9666A3BA9C3E2bgb01xud1012_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Mike, =

&nbs= p;

Sounds li= ke a good starter for ten. I’ll follow that ticket.=

&nbs= p;

In simple= terms, how do we imagine this would look once a client has decided to coal= esce? Would it be a singular connection ID on which HTTP/QUIC HEADER frames= carry requests with different :authority pseudo-headers as required?

&nbs= p;

I had ini= tially worried there might be some complexities using a coalesced connectio= n but am coming around to thinking its not so bad. Deciding when and what t= o coalesce seems like the trickier bit.

&nbs= p;

Lucas

&nbs= p;

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: 16 November 2017 23:49
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>; IETF QUIC WG <qu= ic@ietf.org>
Subject: RE: Connection coalescing aka. HTTP/2 Connection reuse=

 

You're right, we should prob= ably add some text on it.  As a first pass, note that there is no way = to directly address an HTTP/QUIC endpoint by URI/URL.  So an HTTP/QUIC= endpoint is somewhat analogous to an HTTP/2 endpoint for an origin which doesn’t appear in the DNS record.

 

With that as our starting po= int, here are some thoughts:

  • <= span lang=3D"EN-US">The only reason you’re speaking HTTP/QUIC for exa= mple.com in the first place is because you have an Alt-Svc record for examp= le.com.  If you have Alt-Svc records for other origins that happen to share the same certificate pointing to the same hos= t:port, this should be coalesced.
    • <= span lang=3D"EN-US">It seems a pity that you would need to speak individual= ly to each origin for this.  Coincidentally, Ben Schwartz and I were h= aving a conversation about reviving Alt-Svc records in DNS….
  • <= span lang=3D"EN-US">In the absence of Alt-Svc records, draft-ietf-httpbis-o= rigin-frame permits coalescing in HTTP/2 based on the combination of the se= rver’s possession of the correct certificate and assertion that it wants the traffic.  Like #371, there would need to be a very short draft that defines the ORIGIN= frame for HTTP/QUIC as Exceptionally Similar™ to the one in draft-ie= tf-httpbis-origin-frame.

=  

I’ve opened = #940 to track this.

 

-----Original Message----- From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Lucas Pardue
Sent: Friday, November 17, 2017 3:47 AM
To: IETF QUIC WG <quic@ietf.org>=
Subject: Connection coalescing aka. HTTP/2 Connection reuse

 

Hello,

 

To start, this area is disti= nct from the connection migration discussion.

 

RFC 7540 Section 9.1.1 discu= sses connection reuse, also known informally as h2 connection coalescing.

 

I wondered how the HTTP/QUIC= mapping handled this concept but a search didn't yield me an answer. I won= dered if the concept was more transport-level but couldn't find anything th= ere either.

 

Is this a "thing" = in QUIC? Are there any special consideration that need be paid, apart from = the mechanical transpilation?

 

Kind regards

Lucad

 

 

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

http://www.bbc.c= o.uk

This e-mail (and any attachm= ents) is confidential and may contain personal views which are not the view= s of the BBC unless specifically stated.

If you have received it in

error, please delete it from= your system.

Do not use, copy or disclose= the

information in any way nor a= ct in reliance on it and notify the sender immediately.

Please note that the BBC mon= itors e-mails sent or received.

Further communication will s= ignify your consent to this.

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

 

--_000_7CF7F94CB496BF4FAB1676F375F9666A3BA9C3E2bgb01xud1012_-- From nobody Thu Nov 16 19: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 06410127843 for ; Thu, 16 Nov 2017 19:41:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, 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 RUU5N2YLJiMg for ; Thu, 16 Nov 2017 19:41:25 -0800 (PST) Received: from mail-io0-x244.google.com (mail-io0-x244.google.com [IPv6:2607:f8b0:4001:c06::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 5CD3A1241F3 for ; Thu, 16 Nov 2017 19:41:25 -0800 (PST) Received: by mail-io0-x244.google.com with SMTP id w127so7442508iow.11 for ; Thu, 16 Nov 2017 19:41:25 -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=NJoqgRwvSg+T2mX/jP/OpF0Yl6kzYJnxfAYYWaJi1co=; b=l6o2ncyZDwwrgLMNbUN2FRAPta2foF3xEDgnki2bXtOs07ox6xgILZ50PCFT8EsXSh 2rmsUbdRD022fKJkjVhzwN6VLdSsGRnIMh6lEGPgYFh49o0xbW9hB9pmSOaq6i4Pxjzk bHssXjGLYEKik0woGVaXy5+Y0U3+VISWmRCsDku3rWqQrr5UXeH3OmPb5xqjZOV+W3Wu MZVTGYRSHlD/20qzkcpISAXINWg+1RDagz+dHJ3MfjhyXVNHPnzj4W6cAlJ+mRudk1// 0KEDRUPskJAEo+R4JWxfHKAApEQjlAEYzI8kd5clWFAurzDlDMNSqYa1NSqhQIrx0j7D hvqQ== 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=NJoqgRwvSg+T2mX/jP/OpF0Yl6kzYJnxfAYYWaJi1co=; b=CBvNo1OxCZIer4ZtOVLgyTLunjePBIjO29jEAlFk+4c3FEjIQcmW4+IafsEMCK8re7 pfRpUdGJOe7/4guOINMhpzLFC4tbSD/I7JG+MRZS5WjcCBRjXXiGsSe+WlOb3Ecz0tpt SUdaDOENptgfqqi1aA9umeV+/RcW78q783yuCWEoa8+t/vRTx8jKDIKkPlZSIjHOfIUQ kBzhtaB4Xfz5xmRJlsfVH5TEKhnJhGcW5aPUz32XF+cXaMBOrOYakTEMPrbpyCPRVX+I oEsSrxuYPUZtZy806Flt+klPp4clzwxPby+XLRgMnYRki6JLetOi9Rkops+i/7x3DCkF bu4A== X-Gm-Message-State: AJaThX6IzGhWiK46dlh0qsaXamseloNjXovHDnkH9thTcl6VwYWqpXY7 kPBTkHKZvwOqZjzP0FFF6V9RXpqTQQaEPnYbukgqrQ== X-Google-Smtp-Source: AGs4zMZFWUgH9KA9+ST6ma9ATXk3Z2QuhZ/t6iXYxSiwgqoh+Eh4ZtkGzmhzs9Hcq8znxeGblmlXmOloFfKyc7yrRhA= X-Received: by 10.107.20.1 with SMTP id 1mr1256085iou.170.1510890084364; Thu, 16 Nov 2017 19:41:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.101.16 with HTTP; Thu, 16 Nov 2017 19:41:03 -0800 (PST) In-Reply-To: References: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> <868b3587-79c3-330b-641c-aee849f115c7@steinwurf.com> From: Ian Swett Date: Thu, 16 Nov 2017 22:41:03 -0500 Message-ID: Subject: Re: Remote interop days To: Subodh Iyengar Cc: Patrick McManus , "Morten V. Pedersen" , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114fd624c6a1dc055e25821d" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 03:41:28 -0000 --001a114fd624c6a1dc055e25821d Content-Type: text/plain; charset="UTF-8" I would participate if we held one in mid-December. Any more often than one per month would likely not be that helpful at this point. On Thu, Nov 16, 2017 at 2:58 PM, Subodh Iyengar wrote: > I support this and would be happy to participate. A once per month cadence > would give me some time to build features to test during interop, and be > frequent enough to give me the kick I need to keep updated with the latest > draft features. > > > I imagine this would be a temporary thing for a few months until people > build the tooling needed to keep their implementations running for longer > with self service options like being able to look at client and server > logs. > > > Subodh > ------------------------------ > *From:* QUIC on behalf of Patrick McManus < > pmcmanus@mozilla.com> > *Sent:* Thursday, November 16, 2017 12:55:59 AM > *To:* Morten V. Pedersen > *Cc:* IETF QUIC WG > *Subject:* Re: Remote interop days > > if anyone in this thread would like a slack signup, just mail me (or just > about anyone else on the list :)) - happy to oblige. > > > On Thu, Nov 16, 2017 at 4:43 PM, Morten V. Pedersen > wrote: > > You may also consider: https://zulipchat.com/ > > Fee and open source. > > - M > > > On 11/16/2017 09:38 AM, Sebastiaan Deckers wrote: > > On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars wrote: > > I think Slack unfortunately cannot be configured for public (unconfirmed) > signup. (We would do that if we could.) > > > Suggestions (in no particular order nor exhaustive): > - https://github.com/outsideris/slack-invite-automation > - https://github.com/rauchg/slackin > - https://publicslack.com > > > > > --001a114fd624c6a1dc055e25821d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would participate if we held one in mid-December.=C2=A0 = Any more often than one per month would likely not be that helpful at this = point.

On Th= u, Nov 16, 2017 at 2:58 PM, Subodh Iyengar <subodh@fb.com> wrote= :

I support this and would be happy to participate. A once per month caden= ce would give me some time to build features to test during interop, and be= frequent enough to give me the kick I need to=C2=A0keep updated with the l= atest draft features.


I=C2=A0imagine this would be a temporary thing for a few months until pe= ople build the tooling needed to keep their implementations running for lon= ger with self service options like being able to look at client and server = logs.


Subodh

From: = QUIC <quic-bo= unces@ietf.org> on behalf of Patrick McManus <pmcmanus@mozilla.com>
Sent: Thursday, November 16, 2017 12:55:59 AM
To: Morten V. Pedersen
Cc: IETF QUIC WG
Subject: Re: Remote interop days
=C2=A0
if anyone in this thread would like a slack signup, just mail me (or j= ust about anyone else on the list :)) - happy to oblige.


On Thu, Nov 16, 2017 at 4= :43 PM, Morten V. Pedersen <morten@steinw= urf.com> wrote:
You may also consider: https://zulipchat.com/
Fee and open source.

- M


On 11/16/2017 09:38 AM, Sebastiaan Deckers wrote:
On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars <lars@netapp.= com> wrote:
I think Slack unfortunately cannot be configured for public (unconfirmed) s= ignup. (We would do that if we could.)

Suggestions (in no particular order nor exhaustive):



--001a114fd624c6a1dc055e25821d-- From nobody Thu Nov 16 22:34: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 489B0127B5A for ; Thu, 16 Nov 2017 22:34:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, 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 wVfBrwlSWizW for ; Thu, 16 Nov 2017 22:34:02 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 4A16F1200C1 for ; Thu, 16 Nov 2017 22:34:02 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx16.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eFaDs-0000Pv-Dr for quic@ietf.org; Fri, 17 Nov 2017 07:33:59 +0100 Received: from [10.5.2.35] (helo=xmail10.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eFaDm-00055I-5y for quic@ietf.org; Fri, 17 Nov 2017 01:33:54 -0500 Received: (qmail 26394 invoked from network); 17 Nov 2017 06:33:48 -0000 Received: from unknown (HELO [192.168.100.66]) (Authenticated-user:_huitema@huitema.net@[80.13.34.254]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Nov 2017 06:33:47 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-7A7EDA57-825B-4D60-A08F-F0BA6DE59257 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Thu, 16 Nov 2017 22:33:45 -0800 Cc: Subodh Iyengar , "Morten V. Pedersen" , IETF QUIC WG , Patrick McManus Content-Transfer-Encoding: 7bit Message-Id: <920CD29E-7016-4223-924C-FED39E3CFF50@huitema.net> References: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> <868b3587-79c3-330b-641c-aee849f115c7@steinwurf.com> To: Ian Swett Subject: Re: Remote interop days X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5p04y5rGRRS9Iu4eHXcuHgoXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fuR71/bjJFb+02kS5J2i/pfB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYdfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XIKcwsOsYjBjCZN249H7KzSqpR+WsWEoFdiO1WLSqm BAzs72eE3bOj/WMWwUa+fYPGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATyzYT8K6rd4RA3UMT6Em/UONoJfh+XjGSeeT90H/uIEC /1G6gw+Ao5dBRI3AZSdxW8X40ADRDO4vd7zUZNdeEWbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW/a7J4lI9dq2HBFg+iT3zKvfFcHV2tQAVqGdj/zM7G/H0fgN5y0tqqfuQuS1mj2Wr5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:34:05 -0000 --Apple-Mail-7A7EDA57-825B-4D60-A08F-F0BA6DE59257 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Great idea. And +1 for the mid December target. With a draft-08 published, w= e could test varints. -- Christian Huitema=20 > On Nov 16, 2017, at 7:41 PM, Ian Swett wrote: >=20 > I would participate if we held one in mid-December. Any more often than o= ne per month would likely not be that helpful at this point. >=20 >> On Thu, Nov 16, 2017 at 2:58 PM, Subodh Iyengar wrote: >> I support this and would be happy to participate. A once per month cadenc= e would give me some time to build features to test during interop, and be f= requent enough to give me the kick I need to keep updated with the latest dr= aft features. >>=20 >>=20 >> I imagine this would be a temporary thing for a few months until people b= uild the tooling needed to keep their implementations running for longer wit= h self service options like being able to look at client and server logs.=20= >>=20 >> Subodh >> =20 >> From: QUIC on behalf of Patrick McManus >> Sent: Thursday, November 16, 2017 12:55:59 AM >> To: Morten V. Pedersen >> Cc: IETF QUIC WG >> Subject: Re: Remote interop days >> =20 >> if anyone in this thread would like a slack signup, just mail me (or just= about anyone else on the list :)) - happy to oblige. >>=20 >>=20 >> On Thu, Nov 16, 2017 at 4:43 PM, Morten V. Pedersen wrote: >> You may also consider: https://zulipchat.com/ >> Fee and open source. >>=20 >> - M >>=20 >>=20 >>> On 11/16/2017 09:38 AM, Sebastiaan Deckers wrote: >>> On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars wrote: >>> I think Slack unfortunately cannot be configured for public (unconfirmed= ) signup. (We would do that if we could.) >>>=20 >>> Suggestions (in no particular order nor exhaustive): >>> - https://github.com/outsideris/slack-invite-automation >>> - https://github.com/rauchg/slackin >>> - https://publicslack.com >>=20 >>=20 >=20 --Apple-Mail-7A7EDA57-825B-4D60-A08F-F0BA6DE59257 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Great idea. And +1 for the mid December target. With a draft-08 published, we could test varints.

-- Christian Huitema 

On Nov 16, 2017, at 7:41 PM, Ian Swett <ianswett@google.com> wrote:

I would participate if we held one in mid-December.  Any more often than one per month would likely not be that helpful at this point.

On Thu, Nov 16, 2017 at 2:58 PM, Subodh Iyengar <subodh@fb.com> wrote:

I support this and would be happy to participate. A once per month cadence would give me some time to build features to test during interop, and be frequent enough to give me the kick I need to keep updated with the latest draft features.


I imagine this would be a temporary thing for a few months until people build the tooling needed to keep their implementations running for longer with self service options like being able to look at client and server logs.


Subodh

From: QUIC <quic-bounces@ietf.org> on behalf of Patrick McManus <pmcmanus@mozilla.com>
Sent: Thursday, November 16, 2017 12:55:59 AM
To: Morten V. Pedersen
Cc: IETF QUIC WG
Subject: Re: Remote interop days
 
if anyone in this thread would like a slack signup, just mail me (or just about anyone else on the list :)) - happy to oblige.


On Thu, Nov 16, 2017 at 4:43 PM, Morten V. Pedersen <morten@steinwurf.com> wrote:
You may also consider: https://zulipchat.com/
Fee and open source.

- M


On 11/16/2017 09:38 AM, Sebastiaan Deckers wrote:
On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars <lars@netapp.com> wrote:
I think Slack unfortunately cannot be configured for public (unconfirmed) signup. (We would do that if we could.)

Suggestions (in no particular order nor exhaustive):



--Apple-Mail-7A7EDA57-825B-4D60-A08F-F0BA6DE59257-- From nobody Thu Nov 16 23:54: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 421391293DB for ; Thu, 16 Nov 2017 23:54:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.889 X-Spam-Level: X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=evequefou.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 Sz07dO-7Wxwq for ; Thu, 16 Nov 2017 23:54:08 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0107.outbound.protection.outlook.com [104.47.34.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F041C12741D for ; Thu, 16 Nov 2017 23:54:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=wzYiQNgz66I5SXzRTUvKZjQAZYKFcAR4Mo6xazLkatA=; b=eHkX+EP+ODSFcJQDBw9UUksv/wmd9Dy1ewERUo1fuHmXXduURKLJBWT9w0MmzeTfTbGQ5NbBEDOCIkF1MjkqeO3w37Fyxc3YhSpn+i0B+qO6vd+YzErsv0ynbTnbnSHyl4jm3UpGcrLPyza2kQ1nsDbVQIFAMTIG9ouGj6ulBvs= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2430.namprd08.prod.outlook.com (10.169.203.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Fri, 17 Nov 2017 07:54:04 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0239.007; Fri, 17 Nov 2017 07:54:04 +0000 From: Mike Bishop To: Lucas Pardue , IETF QUIC WG Subject: RE: Connection coalescing aka. HTTP/2 Connection reuse Thread-Topic: Connection coalescing aka. HTTP/2 Connection reuse Thread-Index: AdNfEgZq4vMpcfW9SnGtSL73Xb0d2AAILDbgAAT7pyAADJ0AEA== Date: Fri, 17 Nov 2017 07:54:04 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BA9C346@bgb01xud1012> <7CF7F94CB496BF4FAB1676F375F9666A3BA9C3E2@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BA9C3E2@bgb01xud1012> 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=mbishop@evequefou.be; x-originating-ip: [2001:67c:1232:144:f435:6e8f:cf6f:7ce9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2430; 6:Gtrb9cH3MKBMPAKnMehCIFM732JZqELJgaevT7fvIxySKEETJaPRz926yO8UA/FJeVU5cBLmjKk0K5rR20Ow/jTr4s8y44NqP6m785nq+ikF2QcEwmbnObKYEHwXw/wuJfy0Ol9vDuKXMLylEvzb1x3NvIghgbwP4+pyRK7a/qx+/ut10/mEzYlRFJXh+yBiNyZppGmqP0HJCN950z95MolI2KLAi9uv/m+MmXZwymTeMm4AiJZwaxXk2DVSNSLLqRKS6xqOdTeCxzag8F9JraUNTR9cK7uIJGECbn8K/NFha0hMZ8yGG0f1XW8B0gMd2sLBkhnZ8h7DpsjPJ9k0Wjz2uGAWSx+FA7skYXcV64M=; 5:eDWnzvCewd1FH4Vcfbzjlm7UlvmmtCdWxHoJaMhxf4mXEYh1+8qpeqevZtVxuAvmlTaB6mk8xQbLPMjhWR0EcFsfYdw9cUB/XDyJrl5hKHCHOtjJJj9R9onXrqkRQjRhd2itcOlTrJf59QSvdqojR1NGIgH3g5yfHPn2OmFfDgg=; 24:mvpPgxpYwgIi2iw9P6G1Tx+qYCK796YhTrQ8kwsx++0//tMwrlWYvrC7SR31LZZEDjram8k3uWlL6Fu5afMYfFoKg3U4AHxI9gtSlMaMbuM=; 7:GUk/B9ysQkjOLebZuOtqbqPqzlwRMTpx+QNrjj4PCgC/+xSvIoZUco/C9vLxDS87LNc8HJWCA+yeVLHWVMrsPBk/eGWKEF7zDU2C+k28b0LXwSH1ihMQ62CAgpo1HWAWHUFJkDJMh80jk1165TruBDbhmTV6kWoMC49bqJEEnAImm7UhqOiJtfzjmeuY0d/G+8YbGh/IyO/J2t8y2ryJJ2wtUyG8+ENdJgcMGnEeXGAeUqnd/KIw4XZC0/jS5vHD x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 49cfd672-308b-46e2-37cd-08d52d905fcd x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4603075)(4627115)(201702281549075)(2017052603199); SRVR:MWHPR08MB2430; x-ms-traffictypediagnostic: MWHPR08MB2430: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(204407124797145)(166708455590820)(227612066756510)(127952516941037)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(3231022)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(2016111802025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(6043046)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR08MB2430; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR08MB2430; x-forefront-prvs: 049486C505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39830400002)(13464003)(199003)(189002)(38605003)(2900100001)(7736002)(74316002)(14454004)(966005)(478600001)(316002)(25786009)(189998001)(110136005)(606006)(77096006)(229853002)(6436002)(8936002)(97736004)(53546010)(6506006)(2950100002)(86362001)(55016002)(7696004)(5890100001)(3660700001)(54356999)(6246003)(53386004)(50986999)(76176999)(53936002)(3280700002)(33656002)(2906002)(101416001)(5660300001)(99286004)(81166006)(81156014)(8676002)(105586002)(106356001)(236005)(74482002)(9686003)(6306002)(54896002)(68736007)(102836003)(6116002)(790700001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2430; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB24325E8B00A75B096985BE2BDA2F0MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 49cfd672-308b-46e2-37cd-08d52d905fcd X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 07:54:04.5805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2430 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:54:11 -0000 --_000_MWHPR08MB24325E8B00A75B096985BE2BDA2F0MWHPR08MB2432namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just like HTTP/2. HEADERS frames have different :authority values, but it'= s the same connection. Deciding what to coalesce is also just like HTTP/2 = in the Alt-Svc case, just that there's no non-Alt-Svc case for HTTP/QUIC at= the moment. From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] Sent: Friday, November 17, 2017 10:03 AM To: Mike Bishop ; IETF QUIC WG Subject: RE: Connection coalescing aka. HTTP/2 Connection reuse Hi Mike, Sounds like a good starter for ten. I'll follow that ticket. In simple terms, how do we imagine this would look once a client has decide= d to coalesce? Would it be a singular connection ID on which HTTP/QUIC HEAD= ER frames carry requests with different :authority pseudo-headers as requir= ed? I had initially worried there might be some complexities using a coalesced = connection but am coming around to thinking its not so bad. Deciding when a= nd what to coalesce seems like the trickier bit. Lucas From: Mike Bishop [mailto:mbishop@evequefou.be] Sent: 16 November 2017 23:49 To: Lucas Pardue >; I= ETF QUIC WG > Subject: RE: Connection coalescing aka. HTTP/2 Connection reuse You're right, we should probably add some text on it. As a first pass, not= e that there is no way to directly address an HTTP/QUIC endpoint by URI/URL= . So an HTTP/QUIC endpoint is somewhat analogous to an HTTP/2 endpoint for= an origin which doesn't appear in the DNS record. With that as our starting point, here are some thoughts: * The only reason you're speaking HTTP/QUIC for example.com in the firs= t place is because you have an Alt-Svc record for example.com. If you have= Alt-Svc records for other origins that happen to share the same certificat= e pointing to the same host:port, this should be coalesced. * It seems a pity that you would need to speak individually to each = origin for this. Coincidentally, Ben Schwartz and I were having a conversa= tion about reviving Alt-Svc records in DNS.... * In the absence of Alt-Svc records, draft-ietf-httpbis-origin-frame pe= rmits coalescing in HTTP/2 based on the combination of the server's possess= ion of the correct certificate and assertion that it wants the traffic. Li= ke #371, there would need= to be a very short draft that defines the ORIGIN frame for HTTP/QUIC as Ex= ceptionally Similar(tm) to the one in draft-ietf-httpbis-origin-frame. I've opened #940 to track= this. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Lucas Pardue Sent: Friday, November 17, 2017 3:47 AM To: IETF QUIC WG > Subject: Connection coalescing aka. HTTP/2 Connection reuse Hello, To start, this area is distinct from the connection migration discussion. RFC 7540 Section 9.1.1 discusses connection reuse, also known informally as= h2 connection coalescing. I wondered how the HTTP/QUIC mapping handled this concept but a search didn= 't yield me an answer. I wondered if the concept was more transport-level b= ut couldn't find anything there either. Is this a "thing" in QUIC? Are there any special consideration that need be= paid, apart from the mechanical transpilation? Kind regards Lucad ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal = views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender imme= diately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- --_000_MWHPR08MB24325E8B00A75B096985BE2BDA2F0MWHPR08MB2432namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just like HTTP/2.  HEADERS frames have differen= t :authority values, but it’s the same connection.  Deciding wha= t to coalesce is also just like HTTP/2 in the Alt-Svc case, just that there= ’s no non-Alt-Svc case for HTTP/QUIC at the moment.

 

From: Lucas Pardue [mailto:Lucas.Pardue@bbc.c= o.uk]
Sent: Friday, November 17, 2017 10:03 AM
To: Mike Bishop <mbishop@evequefou.be>; IETF QUIC WG <quic@= ietf.org>
Subject: RE: Connection coalescing aka. HTTP/2 Connection reuse=

 

Hi Mike,

 

Sounds like a good starter for = ten. I’ll follow that ticket.

 

In simple terms, how do we imag= ine this would look once a client has decided to coalesce? Would it be a si= ngular connection ID on which HTTP/QUIC HEADER frames carry requests with d= ifferent :authority pseudo-headers as required?

 

I had initially worried there m= ight be some complexities using a coalesced connection but am coming around= to thinking its not so bad. Deciding when and what to coalesce seems like = the trickier bit.

 

Lucas

 

From: Mike Bishop [mailto:mbishop@evequefou.be]
Sent: 16 November 2017 23:49
To: Lucas Pardue <Lucas= .Pardue@bbc.co.uk>; IETF QUIC WG <quic@ietf.org>
Subject: RE: Connection coalescing aka. HTTP/2 Connection reuse=

 

You're right, we should probably add some text on= it.  As a first pass, note that there is no way to directly address a= n HTTP/QUIC endpoint by URI/URL.  So an HTTP/QUIC endpoint is somewhat= analogous to an HTTP/2 endpoint for an origin which doesn’t appear in the DNS record.

 

With that as our starting point, here are some th= oughts:

  • The only reason y= ou’re speaking HTTP/QUIC for example.com in the first place is becaus= e you have an Alt-Svc record for example.com.  If you have Alt-Svc rec= ords for other origins that happen to share the same certificate pointing to the same host:port, this should be coalesced.=
    • It seems a pity t= hat you would need to speak individually to each origin for this.  Coi= ncidentally, Ben Schwartz and I were having a conversation about reviving A= lt-Svc records in DNS….
  • In the absence of= Alt-Svc records, draft-ietf-httpbis-origin-frame permits coalescing in HTT= P/2 based on the combination of the server’s possession of the correc= t certificate and assertion that it wants the traffic.  Like #371, there would need to be a very short draft that defines= the ORIGIN frame for HTTP/QUIC as Exceptionally Similar™ to the one = in draft-ietf-httpbis-origin-frame.

 

I’ve opened #94= 0 to track this.

 

-----Original Message-----
From: QUIC [mailto:quic-bounces@ie= tf.org] On Behalf Of Lucas Pardue
Sent: Friday, November 17, 2017 3:47 AM
To: IETF QUIC WG <quic@ietf.org>=
Subject: Connection coalescing aka. HTTP/2 Connection reuse

 

Hello,

 

To start, this area is distinct from the connecti= on migration discussion.

 

RFC 7540 Section 9.1.1 discusses connection reuse= , also known informally as h2 connection coalescing.

 

I wondered how the HTTP/QUIC mapping handled this= concept but a search didn't yield me an answer. I wondered if the concept = was more transport-level but couldn't find anything there either.

 

Is this a "thing" in QUIC? Are there an= y special consideration that need be paid, apart from the mechanical transp= ilation?

 

Kind regards

Lucad

 

 

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

http://www.bbc.co.uk<= /o:p>

This e-mail (and any attachments) is confidential= and may contain personal views which are not the views of the BBC unless s= pecifically stated.

If you have received it in

error, please delete it from your system.

Do not use, copy or disclose the

information in any way nor act in reliance on it = and notify the sender immediately.

Please note that the BBC monitors e-mails sent or= received.

Further communication will signify your consent t= o this.

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

 

--_000_MWHPR08MB24325E8B00A75B096985BE2BDA2F0MWHPR08MB2432namp_-- From nobody Fri Nov 17 01:14: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 426BF127241 for ; Fri, 17 Nov 2017 01:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 Kg0d1OF9TcQ0 for ; Fri, 17 Nov 2017 01:14:55 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EA44126CF6 for ; Fri, 17 Nov 2017 01:14:55 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,408,1505804400"; d="asc'?scan'208";a="240272314" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx141-out.netapp.com with ESMTP; 17 Nov 2017 01:14:55 -0800 Received: from VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 17 Nov 2017 01:14:54 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS04-PRD.hq.netapp.com (10.122.105.20) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Fri, 17 Nov 2017 01:14:54 -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=7uRe94LFOO7WwbEBjqqSxl/2y/FrJtAUYU9UgwyE/pg=; b=cPKSraqhnX75BSSceWH/SyQrk0RlZEJJhrkkaHL72jwAUENpbekQfSc6S/csN2chhesPKkSQaHGP1IiDVng50NSxB1AavAzK7qqYQH3d+2Pdh71FrElqtEBJqZW8P5Pp7S6SZCM6Z7Yy5ash2Bjuo5QCc+lDuR5rBlG6D+ZaTxU= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Fri, 17 Nov 2017 09:14:53 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0239.007; Fri, 17 Nov 2017 09:14:52 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Doodle poll for Dec 2017 interop day Thread-Topic: Doodle poll for Dec 2017 interop day Thread-Index: AQHTX4SGm8RfodI9iESXA4HNJSTdGA== Date: Fri, 17 Nov 2017 09:14:52 +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.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:31a3:3101:3c8d:df47:dfe1:d564] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:JbeaYpM0zieditlORJlF3fZNVZclcSeVu74Hv+VsBejWPibY/3/gNJ/e2RAyEFNtaUChciu5WV8z7CBv6LK2exlYW/6HInv3dksuTxLt9lX97iHPHODIcI0++i9NMwRYQVIFuk3cyut/xuJcnaklc6TtcuN3cx+0hONQp06x6RY4tlW67uy4wCNPbJq1W0xlYmnjQvM0J/RbHSI1ezm2F6bnxcitu9x3r61MVCvscQ9Y+kqj0PHjQREL7d1Re5QLlyGu5tzn/zok1JPA8wAS4eqG3K3nxM+8v4yY4sa4cVITw8c2/YQwirYN5VyJI196C5JorouW10sFZfgkqQwbqEcASoK/o2fVfciCuw8kwiE=; 5:bApSy2n2UdT3j5Cl2lfoScBwt7uZy+E4NFf6u1LIHDy65rafjxp/b5b7km+enWeoDYowzME/eaq3cprEccn2h8oqxyvx/js4vNEmL5xwvoCTeZkTTM0Mz32lVD1nvXU9sKzeH+gVd6t6FJVwPmNI5rCWe4Y85NgSgpZKd/qd/Qc=; 24:em/igWU0Wqu8tLr5QvXWzcgXVjmWdT3YMq8xtiJsgMxgIaSA+BcrIlVboh8oXkiSRFo/syrXiEWpgqWwTrBQ3zkbnlX2uLWMODMynTJs8wA=; 7:bkaXKOIRSyuS3G9Xsj4rLpFkkpknNyQNxzuMuDQ1U5Yp/qL9FsSACnGHe+YDxGiUbk4Y8jUIjLOw4oJYFKHqRl6ObVPikgRS1ar6zi0kdWdk6VoH7FmlJvlp52DOHPP+oQ/5YeQ6/sZdNKGeBm5nEyOVmRhw4+tNvaB2EyIxyz8D+kzmD4dp4mv4qmsjJZPmL8RUI9Zmu4zONYJs+/yMdpCIgsgQLyvU/63e2wZCh0DuZhbBXijRiQDIzYaHpu51 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b0203e32-5bbb-4a75-241f-08d52d9ba97d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60409825278598); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3002001)(3231022)(93006095)(93001095)(10201501046)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1761; x-forefront-prvs: 049486C505 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(189002)(199003)(36756003)(68736007)(6916009)(81166006)(101416001)(6436002)(6486002)(77096006)(53936002)(478600001)(83716003)(25786009)(97736004)(316002)(6512007)(2900100001)(966005)(6306002)(14454004)(82746002)(8676002)(102836003)(3280700002)(6116002)(3660700001)(86362001)(50226002)(57306001)(6506006)(106356001)(8936002)(105586002)(99936001)(7736002)(99286004)(5660300001)(81156014)(50986999)(305945005)(189998001)(558084003)(2906002)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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=_D3FFDD5E-DC33-4D5F-A1B7-D1E1F20E45D1"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b0203e32-5bbb-4a75-241f-08d52d9ba97d X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 09:14:52.9056 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:14:57 -0000 --Apple-Mail=_D3FFDD5E-DC33-4D5F-A1B7-D1E1F20E45D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Please indicate your availability, if you have a stack you wish to test: = https://doodle.com/poll/4nmiegw29q84x6t9 Lars --Apple-Mail=_D3FFDD5E-DC33-4D5F-A1B7-D1E1F20E45D1 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloOqIwACgkQVLXDCb9w wVdotBAAko55lm2uIpSPIWI2Jnb8pPUtFz6Ge8W13PbJXyjGlTomHq2rRrf6Rter 3p+FTBYc9Z84IooSmWMU4FQ2DryW0c9WpNGow02av1BbBEI/8EOYlCuB80OnR9sQ 5uI8+7Hki6yJTr5KaUX8HqUSGd3tdHeoN07j6NtovKBTQugjl3YcovE67SfS5C2N wReL2wBL95rlP2zzgJa0pD7UH2FKWvosqtMMA/vGOMJCLsa9ZGevfcqosuAHJHO1 xTud8LrBzEjkiQg9jE5c1gFfhMhRfszfuYxHOEVWddGsJqsahtHhjJAhLiOknLk8 2Ivpjy2fKofuyTyX3k/KyP8dCElvtuHBH4lKdfgsjkt+Fxxs8SzyCja2celDrk6i PvkbGCvt6XbAUtjanQpOLd3BdkwYd/LCkoI14VbbDVr/yTgsXHaDLCWMiBjfOkyq G+FlSH+Rb+HK81Kt++rjux5YTYw097w8S6WMIGoTa+yPX4HNlIiJdAlfQAO6/7oV Cl+AYjx2OllHgaXLQmNdTFoKAVUv7KwIibaAz/v0JAVe2bP2VMtAao2sEEjaP6CM 7e/We1Eun2GJlGmpJGAjUu2Ocn+6vL+JkyipzO1iSDX0Av0o27qoFduyM5adPjK7 tKrRLXypWJIZmyX6mF31N6BOjy358XGqKUuAsO8HkLBXIny5Y+0= =DFeQ -----END PGP SIGNATURE----- --Apple-Mail=_D3FFDD5E-DC33-4D5F-A1B7-D1E1F20E45D1-- From nobody Fri Nov 17 07:20: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 814FC124BFA for ; Fri, 17 Nov 2017 07:20:47 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 v9WWJnNuB7St for ; Fri, 17 Nov 2017 07:20:35 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 5DE06126B72 for ; Fri, 17 Nov 2017 07:20:35 -0800 (PST) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx1.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.89) (envelope-from ) id 1eFiRT-0006IZ-6Q for quic@ietf.org; Fri, 17 Nov 2017 16:20:33 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eFiRN-0001GO-Tr for quic@ietf.org; Fri, 17 Nov 2017 10:20:29 -0500 Received: (qmail 2894 invoked from network); 17 Nov 2017 15:20:23 -0000 Received: from unknown (HELO [192.168.100.66]) (Authenticated-user:_huitema@huitema.net@[80.13.34.254]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 17 Nov 2017 15:20:22 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-64B70926-0244-4069-9741-6CDD76D3664D Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Fri, 17 Nov 2017 16:20:20 +0100 Cc: Ian Swett , IETF QUIC WG Content-Transfer-Encoding: 7bit Message-Id: <39B9EFDC-B513-45F4-8112-2913F3FE967A@huitema.net> References: To: Mike Bishop Subject: Re: Moving the version 4 bytes earlier in the long header X-Originating-IP: 168.144.250.177 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.25) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5lWIkRicE1b9xFS3FvjifpIXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftJejUQGnMLO4rivwhIBDb0B98yDTitFWvbHwz9vKZpm3I5 mq5AFk9iXeoOoZGPBgSZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyZFjIToX6GLbbHCBsyyfoCLFQwbgMCItJaYYOhQRv6/ UE+MYBysAg9EysZu/PX2Rzjh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GzCf4c0o7D6gM9WJQM09qxZnHEeB4hpRrmo/duzUUp/IB dx+K1yn8EkJ4iddO3DgbqSCdDnwOt/sD4msYGp1R2HLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+R4HKWR6SMBqrz1a2dl/GB4j2lB9TLiDMfXuvSrucRXom7I3bwInONPnB4uC7Qfcgpsib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 15:20:47 -0000 --Apple-Mail-64B70926-0244-4069-9741-6CDD76D3664D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable If we move the version up, maybe we should move it up before the connection I= D. Right now, implementations of draft 7 cannot understand the version numbe= r proposed by a draft 8 implementation, if the sequence number uses varint e= ncoding. Which means it is a good time for a spec change. But someone is bou= nd to invent variable length coding of the connection ID. And we will have t= he same issue. -- Christian Huitema=20 > On Nov 16, 2017, at 11:56 AM, Mike Bishop wrote: >=20 > Actually, =E2=80=9Cthe location and size of the Packet Number field in lon= g headers=E2=80=9D is currently listed as an invariant. It=E2=80=99s the se= mantics of that field that are mutable per version, though as Brian has obse= rved, some semantics may get ossified on us if we=E2=80=99re not careful. > =20 > It needs to be an invariant, because the Version Negotiation packet (and h= ow you generate one) needs to be invariant, and a value is read from the inc= oming packet and set in the Version Negotiation packet as part of version ne= gotiation. > =20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett > Sent: Thursday, November 16, 2017 4:15 PM > To: IETF QUIC WG > Subject: Moving the version 4 bytes earlier in the long header > =20 > I am very supportive of Martin's work to define QUIC invariants. =20 > =20 > It seems ideal to make the invariants as early in the packet as possible, s= o I'd suggest we move the 4 byte version in front of the 4 byte packet numbe= r in the long header. This is filed in Issue #926. For reference, it is pr= oposed the size and location of the version is an invariant, but nothing abo= ut the packet number is. > =20 > Just because the packet number is before the version doesn't mean the pack= et number length can't change, but it does mean we're stuck with those 4 byt= es in that location, which makes future changes to the packet number length v= ery awkward. > =20 > I don't anticipate future changes, but this is going to be an invariant fo= r a very long time, so I'd like to move it now. > =20 > Thanks, Ian --Apple-Mail-64B70926-0244-4069-9741-6CDD76D3664D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable If we move the version up, maybe we should m= ove it up before the connection ID. Right now, implementations of draft 7 ca= nnot understand the version number proposed by a draft 8 implementation, if t= he sequence number uses varint encoding. Which means it is a good time for a= spec change. But someone is bound to invent variable length coding of the c= onnection ID. And we will have the same issue.

-- Christian Huitema 

On Nov 16, 2017, at 11:56 A= M, Mike Bishop <mbishop@evequefou= .be> wrote:

Actually, =E2=80=9Cthe location and s= ize of the Packet Number field in long headers=E2=80=9D is currently listed as an invariant.  It=E2=80=99s the semantics of that field that are mutable per version, though as Brian= has observed, some semantics may get ossified on us if we=E2=80=99re not ca= reful.

&nb= sp;

It needs= to be an invariant, because the Version Negotiation packet (and how you gen= erate one) needs to be invariant, and a value is read from the incoming pack= et and set in the Version Negotiation packet as part of version negotiation.

&nb= sp;

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Thursday, November 16, 2017 4:15 PM
To: IETF QUIC WG <quic@ietf.org>
Subject: Moving the version 4 bytes earlier in the long header

 

I am very supportive of Martin's work to define QUIC i= nvariants.  

 

 

Just because the packet number is before the version d= oesn't mean the packet number length can't change, but it does mean we're st= uck with those 4 bytes in that location, which makes future changes to the p= acket number length very awkward.

 

I don't anticipate future changes, but this is going t= o be an invariant for a very long time, so I'd like to move it now.

 

Thanks, Ian

= --Apple-Mail-64B70926-0244-4069-9741-6CDD76D3664D-- From nobody Fri Nov 17 10:13: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 73EBC1288B8 for ; Fri, 17 Nov 2017 10:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, 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=fb.com header.b=nueDL4u9; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=A5KoWkXg Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kaiNPtmSifRo for ; Fri, 17 Nov 2017 10:13:30 -0800 (PST) Received: from mx0a-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 6754F1200FC for ; Fri, 17 Nov 2017 10:13:30 -0800 (PST) Received: from pps.filterd (m0089730.ppops.net [127.0.0.1]) by m0089730.ppops.net (8.16.0.21/8.16.0.21) with SMTP id vAHI8fJE013587; Fri, 17 Nov 2017 10:13:18 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=oeVYSO5CcoM2RCx69G1hIJiyikLU443uo98kzE53VCU=; b=nueDL4u9ZNRP2T5c5XeTb/dvfd7J6oCvMHpVZSk33LvZK/ROjq7Z0SJMNdNyGlHL6FgQ wwjPxMZNWufkdIgABftWL2FOstoa8aZKiv1RHSYmxAU4ZvjmfCirwofQbfOZkRQE2x/M trMzqSdkDUkXPDIsDiNxPOf4Uqp2Bt7sjbc= Received: from maileast.thefacebook.com ([199.201.65.23]) by m0089730.ppops.net with ESMTP id 2ea4mx01mp-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 17 Nov 2017 10:13:18 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.24) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 17 Nov 2017 13:13:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oeVYSO5CcoM2RCx69G1hIJiyikLU443uo98kzE53VCU=; b=A5KoWkXg2bP2Zn+NHLoeuTohf8IfNlf/x+NuOsbZpND5USXp7fYUvw1whekJ6LR2HKrrO0AaFTRrIOiQ6pSgFyHlEQQsC9vUWe6TgqRLT1PvoezIEKhJ8bIM22mMNaT26AYvPU1j8307hf1V6yRBHs1yOTuZmXK16TvsUfYop4o= Received: from DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) by DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.218.12; Fri, 17 Nov 2017 18:13:15 +0000 Received: from DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) by DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) with mapi id 15.20.0218.015; Fri, 17 Nov 2017 18:13:15 +0000 From: Roberto Peon To: Christian Huitema , Mike Bishop CC: Ian Swett , IETF QUIC WG Subject: Re: Moving the version 4 bytes earlier in the long header Thread-Topic: Moving the version 4 bytes earlier in the long header Thread-Index: AQHTXrMgLhrCMbLbY0Sos9GRr7lNo6MW1bQAgAHcDgCAADBRsg== Date: Fri, 17 Nov 2017 18:13:15 +0000 Message-ID: References: , <39B9EFDC-B513-45F4-8112-2913F3FE967A@huitema.net> In-Reply-To: <39B9EFDC-B513-45F4-8112-2913F3FE967A@huitema.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::4:25b5] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1883; 20:D9MG24xNHvqHgIZxw0ISspWNneODuhuSfzJmSGR++vsTNyMBNMaxgKwFbp1wSC7S156xNVYD+Gv8n2gYhHo7yQO4ad69Co0nC4uDAXYRk5IAymB5LXiNfHmxmWKc1203k4dTpx4HH20Mgt+JVwjkHiS2T9BTR3jZx5w0/VsvKjI= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: abcd4ea7-c002-4100-7bce-08d52de6df8b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:DM5PR15MB1883; x-ms-traffictypediagnostic: DM5PR15MB1883: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(211936372134217)(153496737603132); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(11241501159)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(10201501046)(3231022)(920507027)(6041248)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR15MB1883; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR15MB1883; x-forefront-prvs: 049486C505 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(199003)(189002)(24454002)(8676002)(236005)(81156014)(54356999)(8936002)(9686003)(33656002)(2900100001)(4326008)(25786009)(81166006)(76176999)(101416001)(2906002)(55016002)(68736007)(3280700002)(106356001)(3660700001)(2950100002)(34040400001)(7696004)(7736002)(5660300001)(6306002)(6246003)(74316002)(53936002)(316002)(53546010)(77096006)(6436002)(6506006)(14454004)(189998001)(50986999)(105586002)(54896002)(606006)(478600001)(54906003)(99286004)(229853002)(110136005)(97736004)(86362001)(102836003)(6116002)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1883; H:DM5PR15MB1883.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR15MB1883E73550F9D0E82FB12122CD2F0DM5PR15MB1883namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: abcd4ea7-c002-4100-7bce-08d52de6df8b X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Nov 2017 18:13:15.7575 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1883 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-17_06:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 18:13:32 -0000 --_000_DM5PR15MB1883E73550F9D0E82FB12122CD2F0DM5PR15MB1883namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable If we're going to cause a bunch of migration pain for those folks using QUI= C in production, them or is best to do it all at once! Does the benefit of moving these bytes around accomplish anything interesti= ng, however? I don't mean this to say it should or shouldn't happen, just a= sking the question. Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone -------- Original message -------- From: Christian Huitema Date: 11/17/17 7:21 AM (GMT-08:00) To: Mike Bishop Cc: Ian Swett , IETF QUIC WG Subject: Re: Moving the version 4 bytes earlier in the long header If we move the version up, maybe we should move it up before the connection= ID. Right now, implementations of draft 7 cannot understand the version nu= mber proposed by a draft 8 implementation, if the sequence number uses vari= nt encoding. Which means it is a good time for a spec change. But someone i= s bound to invent variable length coding of the connection ID. And we will = have the same issue. -- Christian Huitema On Nov 16, 2017, at 11:56 AM, Mike Bishop > wrote: Actually, =93the location and size of the Packet Number field in long heade= rs=94 is currently listed as an invariant. It=92s the semantics of that fi= eld that are mutable per version, though as Brian has observed, some semant= ics may get ossified on us if we=92re not careful. It needs to be an invariant, because the Version Negotiation packet (and ho= w you generate one) needs to be invariant, and a value is read from the inc= oming packet and set in the Version Negotiation packet as part of version n= egotiation. From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett Sent: Thursday, November 16, 2017 4:15 PM To: IETF QUIC WG > Subject: Moving the version 4 bytes earlier in the long header I am very supportive of Martin's work to define QUIC invariants. It seems ideal to make the invariants as early in the packet as possible, s= o I'd suggest we move the 4 byte version in front of the 4 byte packet numb= er in the long header. This is filed in Issue #926. For reference, it is proposed the size and loc= ation of the version is an invariant, but nothing about the packet number i= s. Just because the packet number is before the version doesn't mean the packe= t number length can't change, but it does mean we're stuck with those 4 byt= es in that location, which makes future changes to the packet number length= very awkward. I don't anticipate future changes, but this is going to be an invariant for= a very long time, so I'd like to move it now. Thanks, Ian --_000_DM5PR15MB1883E73550F9D0E82FB12122CD2F0DM5PR15MB1883namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
If we're going to cause a bunch of migration pain for those folks usin= g QUIC in production, them or is best to do it all at once!

Does the benefit of moving these bytes around accomplish anything inte= resting, however? I don't mean this to say it should or shouldn't happen, j= ust asking the question. 



Sent via the Samsu= ng Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: Christian Huitema <huitema@huitema.net>
Date: 11/17/17 7:21 AM (GMT-08:00)
To: Mike Bishop <mbishop@evequefou.be>
Cc: Ian Swett <ianswett@google.com>, IETF QUIC WG <quic@ietf.= org>
Subject: Re: Moving the version 4 bytes earlier in the long header

If we move the version up, maybe we should move it up before the conne= ction ID. Right now, implementations of draft 7 cannot understand the versi= on number proposed by a draft 8 implementation, if the sequence number uses= varint encoding. Which means it is a good time for a spec change. But someone is bound to invent variable = length coding of the connection ID. And we will have the same issue.

-- Christian Huitema 

On Nov 16, 2017, at 11:56 AM, Mike Bishop <mbishop@evequefou.be> wrote:

Actually, =93the location and siz= e of the Packet Number field in long headers=94 is currently listed as an invariant.  It=92s the semantics of that field that are mutable per version, though as Bria= n has observed, some semantics may get ossified on us if we=92re not carefu= l.

 

It needs to be an invariant, becaus= e the Version Negotiation packet (and how you generate one) needs to be inv= ariant, and a value is read from the incoming packet and set in the Version= Negotiation packet as part of version negotiation.

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Thursday, November 16, 2017 4:15 PM
To: IETF QUIC WG <quic@ietf.org<= /a>>
Subject: Moving the version 4 bytes earlier in the long header

 

I am very supportive of Martin's work to define QUIC= invariants.  

 

 

Just because the packet number is before the version= doesn't mean the packet number length can't change, but it does mean we're= stuck with those 4 bytes in that location, which makes future changes to t= he packet number length very awkward.

 

I don't anticipate future changes, but this is going= to be an invariant for a very long time, so I'd like to move it now.

 

Thanks, Ian

--_000_DM5PR15MB1883E73550F9D0E82FB12122CD2F0DM5PR15MB1883namp_-- From nobody Fri Nov 17 16:56: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 BD278126557 for ; Fri, 17 Nov 2017 16:55:58 -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 (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 jf9vzzDyIAIf for ; Fri, 17 Nov 2017 16:55:56 -0800 (PST) Received: from mail-io0-x22b.google.com (mail-io0-x22b.google.com [IPv6:2607:f8b0:4001: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 4FBDC120725 for ; Fri, 17 Nov 2017 16:55:56 -0800 (PST) Received: by mail-io0-x22b.google.com with SMTP id z74so10528858iof.12 for ; Fri, 17 Nov 2017 16:55:56 -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=6X8E2/8XYRQjI8UKgqyL1oqBECZrExBtoBleShW6V48=; b=hXZegEtVEWO5qPJKt7kvnIeWKiF3qLeqbZuD0uKIpmtO+YFlF22qAEAzfyeyV1NnmX 73pbCItxVmQbEtyOkmSswwVAcZMIRuKMYR/2ajwuqulHTAY+7vzi6xGrs1LmzcbaNbcf gHTPDXhUvGce0sedGvELBguQ3mA+RLdye4pXmaF53R17JeSecLB5c55wRkWoP0AnCcum O0Nz4qUqDkRdKt7NmViBaojhTqLl/M97QBQtOUg7Rz8cH1uyFlw4JbFoeE5oDV0oZOwI h7b6Ym+4g4IAGtoOx32Ud++zTEny+YE/tibiw5n4jSZpgC1kG+LmVeKmpG5KfsIv8Ji6 hcUQ== 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=6X8E2/8XYRQjI8UKgqyL1oqBECZrExBtoBleShW6V48=; b=MHJgk6a2b30bq+LNFxx1o8hzOUtaI4fIjQYWM+7YKGJhIMr72aINVNjcqDOksm7N5R 99p7Tyt8sHYE3tnPeWhIOe5/1X/P+oYozpCz5ziiS4CEZ3UsAlczPo/swsT3J9KAzFxr nEF+rPfk9NcpvQeLuILSpcpBq47+aMoGj/UDoR/byVNBcRbvpOKKTbxN8WjuTo7/Ilc2 C0rTbVnBElgUkekNkVJCflA0le6HQhM7G+8hBdsKUxgIg1sobBqkUat80h6Y7nEmR2+0 irje0YPjytP87yn7KoEWZJAOTC6aykAOMTXgbJaLzYG2BxXoMDMZDwGJ6LgVhVRP2cPC pyfA== X-Gm-Message-State: AJaThX40ybgJcnyhwmmB0BpORzWp1+pnEUQJHP9LyMzEgsyU3dZfVh7L wYMo1rNnkH7eqexIbEtPl/3209vBDvD/HTDfYxebCw== X-Google-Smtp-Source: AGs4zMYrhSzq2P7CZdZsfgMZeQkFTSeWGiANS6Y6nfpnJxPCTjeaBmUC3xFlT+D2Jsgm+ARUAMCu3Ysv+tEo83jpuck= X-Received: by 10.107.183.76 with SMTP id h73mr5153297iof.154.1510966555353; Fri, 17 Nov 2017 16:55:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.101.16 with HTTP; Fri, 17 Nov 2017 16:55:34 -0800 (PST) In-Reply-To: References: <39B9EFDC-B513-45F4-8112-2913F3FE967A@huitema.net> From: Ian Swett Date: Fri, 17 Nov 2017 19:55:34 -0500 Message-ID: Subject: Re: Moving the version 4 bytes earlier in the long header To: Roberto Peon Cc: Christian Huitema , Mike Bishop , IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0b9e3acdd973055e375016" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 00:55:59 -0000 --94eb2c0b9e3acdd973055e375016 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Christian, having the connection id in a fixed spot is really nice for routing, so I'd prefer not to move version before connection ID. The packet number in the header doesn't change in draft 8, since it's not using the new varint format, but rather the defined codepoints in the header. But yes, if we wanted to make such a change soon or in the future, it's a LOT easier if the version comes before the packet number. Roberto, agreed. In particular, Google QUIC is currently putting version before packet number when version is present. We have written code to move it in IETF QUIC and support both IETF QUIC headers and GQUIC at once, but once that's out, moving version again is going to become VERY difficult for us. And of course the location of the version is an invariant as Martin presented. Both are good reasons why IF we're going to move it we should do it soon. And I think it is slightly better to have version before packet number. On Fri, Nov 17, 2017 at 1:13 PM, Roberto Peon wrote: > If we're going to cause a bunch of migration pain for those folks using > QUIC in production, them or is best to do it all at once! > > Does the benefit of moving these bytes around accomplish anything > interesting, however? I don't mean this to say it should or shouldn't > happen, just asking the question. > > > > Sent via the Samsung Galaxy S7, an AT&T 4G LTE smartphone > > > -------- Original message -------- > From: Christian Huitema > Date: 11/17/17 7:21 AM (GMT-08:00) > To: Mike Bishop > Cc: Ian Swett , IETF QUIC WG > Subject: Re: Moving the version 4 bytes earlier in the long header > > If we move the version up, maybe we should move it up before the > connection ID. Right now, implementations of draft 7 cannot understand th= e > version number proposed by a draft 8 implementation, if the sequence numb= er > uses varint encoding. Which means it is a good time for a spec change. Bu= t > someone is bound to invent variable length coding of the connection ID. A= nd > we will have the same issue. > > -- Christian Huitema > > On Nov 16, 2017, at 11:56 AM, Mike Bishop wrote: > > Actually, =E2=80=9Cthe location and size of the Packet Number field in lo= ng > headers=E2=80=9D is currently listed as an invariant. It=E2=80=99s the *= semantics* of > that field that are mutable per version, though as Brian has observed, so= me > semantics may get ossified on us if we=E2=80=99re not careful. > > > > It needs to be an invariant, because the Version Negotiation packet (and > how you generate one) needs to be invariant, and a value is read from the > incoming packet and set in the Version Negotiation packet as part of > version negotiation. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org ] *On > Behalf Of *Ian Swett > *Sent:* Thursday, November 16, 2017 4:15 PM > *To:* IETF QUIC WG > *Subject:* Moving the version 4 bytes earlier in the long header > > > > I am very supportive of Martin's work to define QUIC invariants. > > > > It seems ideal to make the invariants as early in the packet as possible, > so I'd suggest we move the 4 byte version in front of the 4 byte packet > number in the long header. This is filed in Issue #926 > . For reference, it is > proposed the size and location of the version is an invariant, but nothin= g > about the packet number is. > > > > Just because the packet number is before the version doesn't mean the > packet number length can't change, but it does mean we're stuck with thos= e > 4 bytes in that location, which makes future changes to the packet number > length very awkward. > > > > I don't anticipate future changes, but this is going to be an invariant > for a very long time, so I'd like to move it now. > > > > Thanks, Ian > > --94eb2c0b9e3acdd973055e375016 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Christian, having the connection id in a fixed spot is rea= lly nice for routing, so I'd prefer not to move version before connecti= on ID.

The packet number in the header doesn't chang= e in draft 8, since it's not using the new varint format, but rather th= e defined codepoints in the header.=C2=A0 But yes, if we wanted to make suc= h a change soon or in the future, it's a LOT easier if the version come= s before the packet number.

Roberto, agreed.=C2=A0= In particular, Google QUIC is currently putting version before packet numb= er when version is present.=C2=A0 We have written code to move it in IETF Q= UIC and support both IETF QUIC headers and GQUIC at once, but once that'= ;s out, moving version again is going to become VERY difficult for us.=C2= =A0 And of course the location of the version is an invariant as Martin pre= sented.=C2=A0 Both are good reasons why IF we're going to move it we sh= ould do it soon.=C2=A0 And I think it is slightly better to have version be= fore packet number.

On Fri, Nov 17, 2017 at 1:13 PM, Roberto Peon <fenix@fb.com&g= t; wrote:
If we're going to cause a bunch of migration pain for those folks = using QUIC in production, them or is best to do it all at once!

Does the benefit of moving these bytes around accomplish anything inte= resting, however? I don't mean this to say it should or shouldn't h= appen, just asking the question.=C2=A0



Sent via the Samsun= g Galaxy S7, an AT&T 4G LTE smartphone


-------- Original message --------
From: Christian Huitema <huitema@huitema.net>
Date: 11/17/17 7:21 AM (GMT-08:00)
To: Mike Bishop <mbishop@evequefou.be>
Cc: Ian Swett <ianswett@google.com>, IETF QUIC WG <quic@ietf.org>
Subject: Re: Moving the version 4 bytes earlier in the long header

If we move the version up, maybe we should move it up before the conne= ction ID. Right now, implementations of draft 7 cannot understand the versi= on number proposed by a draft 8 implementation, if the sequence number uses= varint encoding. Which means it is a good time for a spec change. But someone is bound to invent variable = length coding of the connection ID. And we will have the same issue.

-- Christian Huitema= =C2=A0

On Nov 16, 2017, at 11:56 AM, Mike Bishop <mbishop@evequefou.be> wrote:

Actually, =E2=80=9Cthe location and= size of the Packet Number field in long headers=E2=80=9D is currently listed as an invarian= t.=C2=A0 It=E2=80=99s the semantics of that field that are mutable per version, though as Bria= n has observed, some semantics may get ossified on us if we=E2=80=99re not = careful.

=C2=A0

It needs to be an invariant, because the Versi= on Negotiation packet (and how you generate one) needs to be invariant, and= a value is read from the incoming packet and set in the Version Negotiatio= n packet as part of version negotiation.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Ian Swett
Sent: Thursday, November 16, 2017 4:15 PM
To: IETF QUIC WG <quic@ietf.org>
Subject: Moving the version 4 bytes earlier in the long header

=C2=A0

I am very supportive of Martin's work to define = QUIC invariants.=C2=A0=C2=A0

=C2=A0

It seems ideal to make the invariants as early in th= e packet as possible, so I'd suggest we move the 4 byte version in fron= t of the 4 byte packet number in the long header.=C2=A0 This is filed in Issue #926.=C2=A0 For reference, it is proposed the size and locati= on of the version is an invariant, but nothing about the packet number is.<= /p>

=C2=A0

Just because the packet number is before the version= doesn't mean the packet number length can't change, but it does me= an we're stuck with those 4 bytes in that location, which makes future = changes to the packet number length very awkward.

=C2=A0

I don't anticipate future changes, but this is g= oing to be an invariant for a very long time, so I'd like to move it no= w.

=C2=A0

Thanks, Ian


--94eb2c0b9e3acdd973055e375016-- From nobody Sat Nov 18 00:38:01 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 8C4D2126B7E for ; Sat, 18 Nov 2017 00:37:59 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnr8vPO7_EBw for ; Sat, 18 Nov 2017 00:37:57 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 758CF1200C1 for ; Sat, 18 Nov 2017 00:37:57 -0800 (PST) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 3052E37DC617E for ; Sat, 18 Nov 2017 08:37:54 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 18 Nov 2017 08:37:55 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0361.001; Sat, 18 Nov 2017 16:37:49 +0800 From: Roni Even To: Mark Nottingham , QUIC WG CC: Lars Eggert Subject: RE: QUIC (quic) WG Interim Meeting: 2018-01-23 - letter of invitation Thread-Topic: QUIC (quic) WG Interim Meeting: 2018-01-23 - letter of invitation Thread-Index: AdNgSDg/7KJlVpGaRn+IWwbAAaRjfQ== Date: Sat, 18 Nov 2017 08:37:49 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD83BEF4@DGGEMM506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.118.60] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD83BEF4DGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:37:59 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD83BEF4DGGEMM506MBSchina_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, According to the Australian embassy site in order to get a business visa I= need a letter of invitation to the meeting that will also state that I am= not paid for being at the meeting. I am not sure what are the visa requirements to all other travelers Thanks Roni From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham Sent: =E9=E5=ED =E1 23 =E0=E5=F7=E8=E5=E1=F8 2017 06:23 To: QUIC WG Cc: Lars Eggert Subject: Re: QUIC (quic) WG Interim Meeting: 2018-01-23 Reminder - registration for this interim closes a bit earlier, on 8 Decembe= r. Cheers, On 5 Oct 2017, at 12:45 am, IESG Secretary > wrote: The QUIC (quic) Working Group will hold a multi-day interim meeting. Session 1: 2018-01-23 09:30 to 17:00 Australia/Melbourne Session 2: 2018-01-24 09:30 to 17:00 Australia/Melbourne Session 3: 2018-01-25 09:30 to 17:00 Australia/Melbourne Meeting Location: Melbourne, AU Agenda: TBD Information about remote participation: Remote participation information will be provided upon registration. https://github.com/quicwg/wg-materials/blob/master/interim-18-01/arrangemen= ts.md -- Mark Nottingham https://www.mnot.net/ --_000_6E58094ECC8D8344914996DAD28F1CCD83BEF4DGGEMM506MBSchina_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

According to the Australi= an embassy site in order to get a  business visa I need a letter of&nb= sp; invitation to the meeting that will also state that I am not paid for being at the meeting.

I am not sure what are th= e visa requirements to all other travelers

Thanks<= /p>

Roni

 <= /p>

From: QUIC [ma= ilto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham
Sent: =E9=E5=ED =E1 23 =E0=E5=F7=E8=E5=E1=F8 2017 06:23
To: QUIC WG
Cc: Lars Eggert
Subject: Re: QUIC (quic) WG Interim Meeting: 2018-01-23

 

Reminder - registration for this interim closes a bi= t earlier, on 8 December.

 

Cheers,

 



On 5 Oct 2017, at 12:45 am, IESG Secretary <iesg-secretary@ietf.org> wrote= :

 

The QUIC (quic) Worki= ng Group will hold
a multi-day interim meeting.

Session 1:
2018-01-23     09:30 to 17:00  Australia/Melbourne=
Session 2:
2018-01-24     09:30 to 17:00  Australia/Melbourne=
Session 3:
2018-01-25     09:30 to 17:00  Australia/Melbourne=

Meeting Location:
Melbourne, AU

Agenda:
TBD

Information about remote participation:
Remote participation information will be provided upon registration.

https://github.com/quicwg/wg-materials/blob/master/interi= m-18-01/arrangements.md

 

--
Mark Nottingham   https://www.m= not.net/

 

--_000_6E58094ECC8D8344914996DAD28F1CCD83BEF4DGGEMM506MBSchina_-- From nobody Sat Nov 18 00:54: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 4CD351272E1 for ; Sat, 18 Nov 2017 00:54:20 -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, 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 Received: 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-ic3zbwCYMo for ; Sat, 18 Nov 2017 00:54:18 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 312E61200C1 for ; Sat, 18 Nov 2017 00:54:18 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 60C0D75A585AC for ; Sat, 18 Nov 2017 08:54:15 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sat, 18 Nov 2017 08:54:16 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Sat, 18 Nov 2017 16:54:08 +0800 From: Roni Even To: Mark Nottingham , QUIC WG CC: Lars Eggert Subject: RE: QUIC (quic) WG Interim Meeting: 2018-01-23 - letter of invitation - my mistake Thread-Topic: QUIC (quic) WG Interim Meeting: 2018-01-23 - letter of invitation - my mistake Thread-Index: AdNgSqbb9TlfBULqRBCZly0h9WpdBQ== Date: Sat, 18 Nov 2017 08:54:08 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD83CF17@DGGEMM506-MBS.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.201.118.60] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD83CF17DGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:54:20 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD83CF17DGGEMM506MBSchina_ Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, I read the wrong section, for a visit for business purpose (not work) short= er than 3 month need a regular tourist visa Roni From: Roni Even Sent: =F9=E1=FA 18 =F0=E5=E1=EE=E1=F8 2017 10:38 To: 'Mark Nottingham'; QUIC WG Cc: Lars Eggert Subject: RE: QUIC (quic) WG Interim Meeting: 2018-01-23 - letter of invitat= ion Hi, According to the Australian embassy site in order to get a business visa I= need a letter of invitation to the meeting that will also state that I am= not paid for being at the meeting. I am not sure what are the visa requirements to all other travelers Thanks Roni From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham Sent: =E9=E5=ED =E1 23 =E0=E5=F7=E8=E5=E1=F8 2017 06:23 To: QUIC WG Cc: Lars Eggert Subject: Re: QUIC (quic) WG Interim Meeting: 2018-01-23 Reminder - registration for this interim closes a bit earlier, on 8 Decembe= r. Cheers, On 5 Oct 2017, at 12:45 am, IESG Secretary > wrote: The QUIC (quic) Working Group will hold a multi-day interim meeting. Session 1: 2018-01-23 09:30 to 17:00 Australia/Melbourne Session 2: 2018-01-24 09:30 to 17:00 Australia/Melbourne Session 3: 2018-01-25 09:30 to 17:00 Australia/Melbourne Meeting Location: Melbourne, AU Agenda: TBD Information about remote participation: Remote participation information will be provided upon registration. https://github.com/quicwg/wg-materials/blob/master/interim-18-01/arrangemen= ts.md -- Mark Nottingham https://www.mnot.net/ --_000_6E58094ECC8D8344914996DAD28F1CCD83CF17DGGEMM506MBSchina_ Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

I read the wrong section,= for a visit for business purpose (not work) shorter than 3 month need a re= gular tourist visa

Roni

From: Roni Eve= n
Sent: =F9=E1=FA 18 =F0=E5=E1=EE=E1=F8 = 2017 10:38
To: 'Mark Nottingham'; QUIC WG
Cc: Lars Eggert
Subject: RE: QUIC (quic) WG Interim Meeting: 2018-01-23 - letter of = invitation

 

Hi,

According to the Australi= an embassy site in order to get a  business visa I need a letter of&nb= sp; invitation to the meeting that will also state that I am not paid for being at the meeting.

I am not sure what are th= e visa requirements to all other travelers

Thanks<= /p>

Roni

 <= /p>

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham
Sent: =E9=E5=ED =E1 23 =E0=E5=F7=E8=E5=E1=F8 2017 06:23
To: QUIC WG
Cc: Lars Eggert
Subject: Re: QUIC (quic) WG Interim Meeting: 2018-01-23

 

Reminder - registration for this interim closes a bi= t earlier, on 8 December.

 

Cheers,

 

 

On 5 Oct 2017, at 12:45 am, IESG Secretary <iesg-secretary@ietf.org> wrote= :

 

The QUIC (quic) Worki= ng Group will hold
a multi-day interim meeting.

Session 1:
2018-01-23     09:30 to 17:00  Australia/Melbourne=
Session 2:
2018-01-24     09:30 to 17:00  Australia/Melbourne=
Session 3:
2018-01-25     09:30 to 17:00  Australia/Melbourne=

Meeting Location:
Melbourne, AU

Agenda:
TBD

Information about remote participation:
Remote participation information will be provided upon registration.

https://github.com/quicwg/wg-materials/blob/master/interi= m-18-01/arrangements.md

 

--
Mark Nottingham   https://www.m= not.net/

 

--_000_6E58094ECC8D8344914996DAD28F1CCD83CF17DGGEMM506MBSchina_-- From nobody Sat Nov 18 20:02: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 B7EAC126BF3 for ; Sat, 18 Nov 2017 20:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, 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 (2048-bit key) header.d=mnot.net header.b=IONreP2g; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=N5H32cxT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id egBUkW724gNk for ; Sat, 18 Nov 2017 20:01:59 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 452C4120725 for ; Sat, 18 Nov 2017 20:01:59 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 8FACE20A52; Sat, 18 Nov 2017 23:01:58 -0500 (EST) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sat, 18 Nov 2017 23:01:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=16IPk7v78qgZiIlWhN0+EfYFUGjZf c0V0RjjTWy5+hU=; b=IONreP2gALUzKSWQ6nRDeALYaRZL7uuioBhKpoqDvWdWZ p9QpBWAz9IdvPEJkbj16mzuKc41u1a5PVZpobI7XAhedNnW4uq3hQWWvwn+FxvUm 7iQdscRfiRg5b3GXtP1mLxgIZ2/u9+8H9dgLK+SuCFA/4MYzLmxLhFSHyPQBMu37 APFc8QQSHkVmZ+RWZXCG8J/Eh9uKfwiItZfaIeH2WKJsYG6857Xab+VRpYBuii9s P/GD3MNez2PyzkmOPin+kH6GH7mXoYaVvgGE9FMjD5WtEkLW/6pKdjWEAiUrruJ1 55ZEO1dJqQvviAFc9G+9QdeB6JUZwA+zGanQPoI0w== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=16IPk7 v78qgZiIlWhN0+EfYFUGjZfc0V0RjjTWy5+hU=; b=N5H32cxTFQ+6ICdy/VkRdR 8zMYnS4beHuqpsj9qiXD7gcc+bh3dIJy40N+maElhux+ZE2tAFdk10aGEnB4ulAq 0HMIQRLBEpbA2yZ+/2FW4fxMuk0NepfuiCelMeQeS+khSKRcUIluLC06+ilKoFS6 z1p5gIR9usyfd+X7QNUhKcr0D/pvHfzHduexm3d9mx9RPI3K9wwAoHcrvqFOBrYQ W/oTcSmZ8/A31dlcDxSqbbGJPmknv6H/HBUnsOsyXI4Dfre0ggA+uaqHxlHSbFmE /svgSzCnShL7yaOMhBJqPXGGQYU/8vXffztvITOfa4+34BwUDebJnk/erjOjP7KA == X-ME-Sender: Received: from [192.168.1.14] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 3A7CE7E13B; Sat, 18 Nov 2017 23:01:56 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: QUIC (quic) WG Interim Meeting: 2018-01-23 - letter of invitation - my mistake From: Mark Nottingham In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD83CF17@DGGEMM506-MBS.china.huawei.com> Date: Sun, 19 Nov 2017 15:01:56 +1100 Cc: QUIC WG , Lars Eggert Content-Transfer-Encoding: quoted-printable Message-Id: <63D88AB8-0A0B-44EE-BE52-067FE7AF59F7@mnot.net> References: <6E58094ECC8D8344914996DAD28F1CCD83CF17@DGGEMM506-MBS.china.huawei.com> To: Roni Even X-Mailer: Apple Mail (2.3445.4.7) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 19 Nov 2017 04:02:02 -0000 OK - if you (or anyone) does end up needing an invitation, please = contact me ASAP. Cheers, > On 18 Nov 2017, at 7:54 pm, Roni Even wrote: >=20 > Hi, > I read the wrong section, for a visit for business purpose (not work) = shorter than 3 month need a regular tourist visa > Roni > From: Roni Even=20 > Sent: =D7=A9=D7=91=D7=AA 18 =D7=A0=D7=95=D7=91=D7=9E=D7=91=D7=A8 2017 = 10:38 > To: 'Mark Nottingham'; QUIC WG > Cc: Lars Eggert > Subject: RE: QUIC (quic) WG Interim Meeting: 2018-01-23 - letter of = invitation > =20 > Hi, > According to the Australian embassy site in order to get a business = visa I need a letter of invitation to the meeting that will also state = that I am not paid for being at the meeting. > I am not sure what are the visa requirements to all other travelers > Thanks > Roni > =20 > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham > Sent: =D7=99=D7=95=D7=9D =D7=91 23 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91=D7= =A8 2017 06:23 > To: QUIC WG > Cc: Lars Eggert > Subject: Re: QUIC (quic) WG Interim Meeting: 2018-01-23 > =20 > Reminder - registration for this interim closes a bit earlier, on 8 = December. > =20 > Cheers, > =20 > =20 >=20 > On 5 Oct 2017, at 12:45 am, IESG Secretary = wrote: > =20 > The QUIC (quic) Working Group will hold > a multi-day interim meeting. >=20 > Session 1: > 2018-01-23 09:30 to 17:00 Australia/Melbourne > Session 2: > 2018-01-24 09:30 to 17:00 Australia/Melbourne > Session 3: > 2018-01-25 09:30 to 17:00 Australia/Melbourne >=20 > Meeting Location: > Melbourne, AU >=20 > Agenda: > TBD >=20 > Information about remote participation: > Remote participation information will be provided upon registration. >=20 > = https://github.com/quicwg/wg-materials/blob/master/interim-18-01/arrangeme= nts.md >=20 > =20 > -- > Mark Nottingham https://www.mnot.net/ -- Mark Nottingham https://www.mnot.net/ From nobody Mon Nov 20 21:23: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 54AF4126C83 for ; Mon, 20 Nov 2017 21:23:51 -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, 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 DugMBXpZMSxi for ; Mon, 20 Nov 2017 21:23:48 -0800 (PST) Received: from mail-yb0-x241.google.com (mail-yb0-x241.google.com [IPv6:2607:f8b0:4002:c09::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80216126579 for ; Mon, 20 Nov 2017 21:23:48 -0800 (PST) Received: by mail-yb0-x241.google.com with SMTP id n185so3741251yba.6 for ; Mon, 20 Nov 2017 21:23:48 -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=836rQPq/nFXF4HlIwnlHE5s+yFlf2Sa5lbJ34S1RJyc=; b=K+o82Dn7Y1WxhY+N5LiNXhN7mzbJj8sI6nOQhAXFixTKF38og45KGJWebxWmMS2/hk oPfeRSyhMZ+tJtnQkLwutBi+QtwPBsLygYDbbEAtRQynwoAYKPah9wGBSScrFaXnYeBR BZ5+BqWuLimjBVBtMFVkFnhfI7+6OX5AZIuJ8qy+hJMFuJoq84Frb699c2FYAitPieY/ zR458ZyffioFlGzzSLl1o60XfcNqGvvUyb/pEmAhrKCodiPXDPXZ/25dA9pOaZkj0hpT nuDt3dl3NNaIRoufEDpaFrPet15s8yR88PfM+Ude0LUm2zLtJrFQ8cJ7hvyjqdyN8QGC pmSg== 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=836rQPq/nFXF4HlIwnlHE5s+yFlf2Sa5lbJ34S1RJyc=; b=jDnX5J3fEslW7f5aro8/iYfJLa9e6iHOxQ2QPm0Ab4/jo+exlZtdzInprxKX4XHoBS vmnqTljHefW5fzIEZSj2GSP1qBm2NpM3zwwtpsFefwNUO+MG8RmGe+awaiPuoqitxB2M OrWAU+YfeIu+D6Hkd1Gcmup06bltjdcATr3WCl1pBQCQJDnvvA5VZmbWjsFLTCDP63pu 2mUGtGKo2rYwbaO9cEI7si2oNBwHessEeHztqayHLH5Uo64zyDOpaPCl85RU3ynDQYud eT8Q6KNYD0IFuhKJxyTTAbJJWmsGvgxfGMIL7oJwDE/Ix/thAIsRnQCNXfrzWr3XkDgz TCrA== X-Gm-Message-State: AJaThX54weee9KzdbBoSmTrkAVm0Bbqr4yEqk/VbdhI3rAr+mWw8DxSu hXJHV0AuHj+rDiBjAEoEtoiU0DR/I+b17po2vsmBCg== X-Google-Smtp-Source: AGs4zMZnuVHFeeGVLhOK3qPXcoHJtyF0+LlsBqSb4eld4ZyaeQeQ1xHsqs7KZQV9dc4D0pepeI4rNEkDFwVwiS4bz1c= X-Received: by 10.37.186.8 with SMTP id t8mr10118543ybg.91.1511241827250; Mon, 20 Nov 2017 21:23:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.70.5 with HTTP; Mon, 20 Nov 2017 21:23:46 -0800 (PST) In-Reply-To: <920CD29E-7016-4223-924C-FED39E3CFF50@huitema.net> References: <47C9DC19-EFEC-42A0-8C09-802D5F5B7006@netapp.com> <868b3587-79c3-330b-641c-aee849f115c7@steinwurf.com> <920CD29E-7016-4223-924C-FED39E3CFF50@huitema.net> From: Jana Iyengar Date: Tue, 21 Nov 2017 13:23:46 +0800 Message-ID: Subject: Re: Remote interop days To: Christian Huitema Cc: Ian Swett , "Morten V. Pedersen" , Subodh Iyengar , Patrick McManus , IETF QUIC WG Content-Type: multipart/alternative; boundary="f403043da404491c7c055e776863" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 05:23:51 -0000 --f403043da404491c7c055e776863 Content-Type: text/plain; charset="UTF-8" +1 -- I would participate (if it's before I leave for vacation.) On Fri, Nov 17, 2017 at 2:33 PM, Christian Huitema wrote: > Great idea. And +1 for the mid December target. With a draft-08 published, > we could test varints. > > -- Christian Huitema > > On Nov 16, 2017, at 7:41 PM, Ian Swett wrote: > > I would participate if we held one in mid-December. Any more often than > one per month would likely not be that helpful at this point. > > On Thu, Nov 16, 2017 at 2:58 PM, Subodh Iyengar wrote: > >> I support this and would be happy to participate. A once per month >> cadence would give me some time to build features to test during interop, >> and be frequent enough to give me the kick I need to keep updated with the >> latest draft features. >> >> >> I imagine this would be a temporary thing for a few months until people >> build the tooling needed to keep their implementations running for longer >> with self service options like being able to look at client and server >> logs. >> >> >> Subodh >> ------------------------------ >> *From:* QUIC on behalf of Patrick McManus < >> pmcmanus@mozilla.com> >> *Sent:* Thursday, November 16, 2017 12:55:59 AM >> *To:* Morten V. Pedersen >> *Cc:* IETF QUIC WG >> *Subject:* Re: Remote interop days >> >> if anyone in this thread would like a slack signup, just mail me (or just >> about anyone else on the list :)) - happy to oblige. >> >> >> On Thu, Nov 16, 2017 at 4:43 PM, Morten V. Pedersen > > wrote: >> >> You may also consider: https://zulipchat.com/ >> >> Fee and open source. >> >> - M >> >> >> On 11/16/2017 09:38 AM, Sebastiaan Deckers wrote: >> >> On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars wrote: >> >> I think Slack unfortunately cannot be configured for public (unconfirmed) >> signup. (We would do that if we could.) >> >> >> Suggestions (in no particular order nor exhaustive): >> - https://github.com/outsideris/slack-invite-automation >> - https://github.com/rauchg/slackin >> - https://publicslack.com >> >> >> >> >> > --f403043da404491c7c055e776863 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 -- I would participate (if it's before I leave for = vacation.)

O= n Fri, Nov 17, 2017 at 2:33 PM, Christian Huitema <huitema@huitema.net> wrote:
Gr= eat idea. And +1 for the mid December target. With a draft-08 published, we= could test varints.

=
-- Christian Huitema= =C2=A0
I would participate if we held one in mid-Dece= mber.=C2=A0 Any more often than one per month would likely not be that help= ful at this point.

On Thu, Nov 16, 2017 at 2:58 PM, Subodh Iyengar &l= t;subodh@fb.com><= /span> wrote:

I support this and would be happy to participate. A once per month caden= ce would give me some time to build features to test during interop, and be= frequent enough to give me the kick I need to=C2=A0keep updated with the l= atest draft features.


I=C2=A0imagine this would be a temporary thing for a few months until pe= ople build the tooling needed to keep their implementations running for lon= ger with self service options like being able to look at client and server = logs.


Subodh

From: QUIC <quic-bounces@ietf.org> on behalf of Patrick McManus &= lt;pmcmanus@mozil= la.com>
Sent: Thursday, November 16, 2017 12:55:59 AM
To: Morten V. Pedersen
Cc: IETF QUIC WG
Subject: Re: Remote interop days
=C2=A0
if anyone in this thread would like a slack signup, just mail me (or j= ust about anyone else on the list :)) - happy to oblige.

On = Thu, Nov 16, 2017 at 4:43 PM, Morten V. Pedersen <morten@steinw= urf.com> wrote:
You may also consider: https://zulipchat.com/
Fee and open source.

- M


On 11/16/2017 09:38 AM, Sebastiaan Deckers wrote:
On Thu, Nov 16, 2017 at 3:43 PM, Eggert, Lars <lars@netapp.= com> wrote:
I think Slack unfortunately cannot be configured for public (unconfirmed) s= ignup. (We would do that if we could.)

Suggestions (in no particular order nor exhaustive):




--f403043da404491c7c055e776863-- From nobody Mon Nov 20 21:38: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 B38B512EACE for ; Mon, 20 Nov 2017 21:38:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, 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 (2048-bit key) header.d=mnot.net header.b=FMTK7jJq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=RsaXJYDm Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KYu3Dkv5GEzx for ; Mon, 20 Nov 2017 21:38:29 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD36612EAC1 for ; Mon, 20 Nov 2017 21:38:29 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id DD5B520F30; Tue, 21 Nov 2017 00:38:28 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Tue, 21 Nov 2017 00:38:28 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=MKC6XJc1wFWTTc/lj00RZoQJGLqqvum7Vdur3znkJ+0=; b=FMTK7jJq JweU+VW2N/MpMRhkPCI05Ayb9ez/oD2fq1IhiNiPNrdAaWVEI4QbcQAUfVBQICIJ ACukP+aqbIRc98YZxlGbsMObO1FTLHpeJk/R/EECY27ackXuiqnalF4dxKqKY69e wv1TRhYpHIRWdc6ZbKCeDy10/bWtUrGwHscVxQTgOr14jogZMVz73MDN5GAq0RoG 4Tez4xJBco1KzFmER4dVHK9V+f2p+b5nCzVcB8mFFbIv39FPuukYbEDhjJrBpOmZ GBMyFtbzrzdNJxeBrLjv8hAnXNZCBrmCJeMOMfgbTb+O/R5IZFTexecppHybw86/ WSMh2zmFTiAqFg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=MKC6XJc1wFWTTc/lj00RZoQJGLqqv um7Vdur3znkJ+0=; b=RsaXJYDmxVf5Niszdpna4WyRQj1TfUQfG5AGDmoLcPAF5 gnP2a9r7PF3QoyEcZ08kPonLbinQaon9klQq2SH6FF4cIhOKVjdYfCAQ7cB3DWxR tTlusB7jKE3WfpcsPUv0XDvcOE04H6CwPexAroewXaBpM/Ii0wiNTNu8Z/+sKtc4 UTy7r82eFx1wTGJ6ioODZRLGL8grk4mLADZAfhTHWn4328+KzL8BtMgKIkIdgxCk 9Y38t7lmMjfWSTLpuu1urDimf4+korTAkaZla/Y9dGtxHvsIXYCAiMFfzi/K4jk1 q3LX5QaoS1LEN+4pCjlPXmJaIpc6ysc35x+Oq1b4w== X-ME-Sender: Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id E4BBA24810; Tue, 21 Nov 2017 00:38:27 -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 11.1 \(3445.4.7\)) Subject: DRAFT minutes for IETF100 - Singapore Message-Id: <3C373753-24B3-4328-B879-D5BB8E4A682A@mnot.net> Date: Tue, 21 Nov 2017 16:38:23 +1100 Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3445.4.7) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 05:38:33 -0000 ... are at: https://github.com/quicwg/wg-materials/blob/master/ietf100/minutes.md Thanks again to our scribes. Please request corrections with pull = requests or responses to this e-mail. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Tue Nov 21 02:44: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 E0308129431 for ; Tue, 21 Nov 2017 02:44: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham 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 2QzWWXVPemqs for ; Tue, 21 Nov 2017 02:44:03 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41E4A126BF3 for ; Tue, 21 Nov 2017 02:44:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,432,1505804400"; d="asc'?scan'208";a="223754609" Received: from vmwexchts03-prd.hq.netapp.com ([10.122.105.31]) by mx142-out.netapp.com with ESMTP; 21 Nov 2017 02:43:54 -0800 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by VMWEXCHTS03-PRD.hq.netapp.com (10.122.105.31) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 21 Nov 2017 02:43:53 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 21 Nov 2017 02:43:53 -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=FmRIxs7swzGlKud458X+NybXHFzl9q1cbx5tV8XTGuQ=; b=KwAUllfjdMx6M7/MTtQOs5wAKbLy5aieNRxYlMuaUfj7x+kAaRHWMScmcPEQBYW6T9eSE208cLAYnQZXVamXPwx4c0cfMBA8wcnZWCXjK32pNom2Fv+IxLScI5kEaGfhgvcrRvA1Lk9NuvsPmdE+sqaOh1LoKZG4M+QE0RbW1Ps= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.239.5; Tue, 21 Nov 2017 10:43:51 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0239.009; Tue, 21 Nov 2017 10:43:51 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Re: Doodle poll for Dec 2017 interop day Thread-Topic: Doodle poll for Dec 2017 interop day Thread-Index: AQHTX4SHf7OvFQBwUU20L/H4FHI4T6MerDOA Date: Tue, 21 Nov 2017 10:43:51 +0000 Message-ID: <5F30810F-C268-483C-A6BA-02D4BC86C325@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:yWQdYLBVjiUMh6oIPwLD4DTpw4Dgze9470JsB7PDaQucwYGQ/MZ/a2QDkptANwIQSoHKtklqfHA7q5pzcsChMy7g6XlUV0fH0NyxmAOCjgHOAXdWDFbSeI8szFlDkrN9cCXvX0S6Jciw7o4V5pI40MrASkAwmkGJMv/mOPOSsj8bsweTlzUEGKL+YDy5aeTzW6VPXpOHba5a5SaMIdl7JqYje11lrmGWXQMliUA6lKVgBdyyoBAercj3hKO68Mfu3ovtnB7YHNHfuGTdDKADfbwThUgmQjfSwy2vwpPwUtdTI50sCyMKdmeC7QBvwy+d3egJ80T/8Qfl1VDPVXCnQG5PTjhA4wfhBOLAMdRep9M=; 5:wCSukd7of29p9c332/dY3EFLeNZyZLQTBBrWbuyBmhiWhEK7S28do2rD3hdOHQ24TDm4iI95UoiTX+ZRmquGlGpDjDxcvxJcBUBK0bjv8UFAAtjMglJYmcPm8yj6SP9+4gjhSbc5fAWVai0kmtD4c8oc55YVkPwU9gUJcYwyYa0=; 24:1nDQaoGdUhFtM0iWiXLdxsOOpPkyz/PTCHHIkRgbkOiopTs3pRorFcKu3JgiRdO6etRWZs7u9q/yvdEXVlYoSRw3YYpmhuUK6cS3m7dELiI=; 7:ALN1JioidWRyEFQtM6HA8VBoeK2P83RZTe0lj8oKqW2r58I0lPb/y/y8FFrsg+ftDsb7f3ZTAia9/poF/ePewDqFmUAhsMxQ4WFKyAa3qMGqboagoIOCnz9XWre4LboaOGAmOI7LhBvgCj2jH1TndCIXSjpzI6E7+Xo5BzafzI/dBqxM10bQLulOuTOaQRdxS8lK2Vv6iJod9ZekUdlLNALlkicK34r6RuJ1gRhrjEImrGDbNeePCpCbCCGFw9eO x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: a208e6c3-6cdb-4ee6-8e9c-08d530ccc15a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258)(49563074); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60409825278598); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3231022)(93006095)(93001095)(10201501046)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1764; x-forefront-prvs: 049897979A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(199003)(377424004)(24454002)(81166006)(81156014)(8676002)(316002)(86362001)(6246003)(2900100001)(6306002)(6512007)(76176999)(97736004)(101416001)(305945005)(3280700002)(7736002)(53936002)(50226002)(3660700001)(99286004)(2906002)(68736007)(50986999)(14454004)(105586002)(99936001)(106356001)(6916009)(25786009)(2950100002)(478600001)(66066001)(966005)(82746002)(83716003)(77096006)(6486002)(6506006)(36756003)(53546010)(6436002)(189998001)(4001150100001)(6116002)(8936002)(3846002)(102836003)(33656002)(57306001)(5660300001)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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=_A19DAF17-7D9A-4D8C-B84B-E9A79F2C42CB"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: a208e6c3-6cdb-4ee6-8e9c-08d530ccc15a X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2017 10:43:51.6942 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:44:08 -0000 --Apple-Mail=_A19DAF17-7D9A-4D8C-B84B-E9A79F2C42CB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-11-17, at 10:14, Eggert, Lars wrote: > Please indicate your availability, if you have a stack you wish to = test: https://doodle.com/poll/4nmiegw29q84x6t9 at the moment, Dec 18 is in the lead, followed by Dec 19. I'll leave = this open until the end of the week, so please put in your availability. Lars --Apple-Mail=_A19DAF17-7D9A-4D8C-B84B-E9A79F2C42CB 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloUA2cACgkQVLXDCb9w wVfmpw/+PQ+DOHg6C5feLy7+Z/VCegkAKUYwFLwJREZrsqU02vP495QsPVAyLQ1m wivb2jRW/c4lF/49jDMCkm3RaGQzKRgyEEQgz7d5hbksR8jwuiv0PCKwWnEVGTBP 96OBBx77cBlulZWBje56/U5z0Roq8PY0Mdkjff3gRCNeW7wr5R0e3HagFKTxcrtg vmo9qwT7Ii8AFAgLwumfcQcxj/TPglLK+/tT0245RfHT0EapXNNvacys5O/8AiuO 0j45HcyF2ks4x42oWihzTRCZ4vCaCkEpzZKjBRKV48B9/PwDlC44Zxx40hQ4L3UX B+f5X/Q4vZYHvSvgYMdJZAlCXB2hfZy6dGC7gulj2qsSbpsusJsmmxJO8UJ/MDCk 4VbrY3PfEYo9RqjIT3Z4KxB3ArR/A6SbD32oOkZe0NkGY3j9BtTb8yo4d41NJ2K9 Hrx9FQaXUKB0Dcj6pXpWKf8k8CyDTdyb7PdpIRhHaOUzyczaki+DMLpMDiArWqnl ew1JN98JOXf8W4CSzF6YomO/5tcnplRhZPZHl+wV2LLiBz6fkpghskgCE/CPjoxC rSwwp3uqexq62cPP6aZcAqer8BmujWKeC9MKjx6EqT6kTQ3Tq+BYhAtZCegIXbCc rO2FvYneEpQ9/znZbK/2jcBalTHPlKe3NAdJfhBl4s97cStsqlA= =PHOK -----END PGP SIGNATURE----- --Apple-Mail=_A19DAF17-7D9A-4D8C-B84B-E9A79F2C42CB-- From nobody Tue Nov 21 23:27:01 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 BA5C9127A91 for ; Tue, 21 Nov 2017 23:26:59 -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 a571ksyOIY6P for ; Tue, 21 Nov 2017 23:26:57 -0800 (PST) Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e: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 C1D4612751F for ; Tue, 21 Nov 2017 23:26:57 -0800 (PST) Received: by mail-pg0-x22d.google.com with SMTP id s11so12156863pgc.5 for ; Tue, 21 Nov 2017 23:26:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:to; bh=eiLaWyRZajAGBIzeas9pFSLi/Z7+IjU1MUPIRp7AM2M=; b=gZvsgJ2TVYYFjhWZmYlFZz854laVRY6i+x4PXeV/SHVppm8tkwp6GV5wwDAAHNzGUe vmm/Ptyxvn1WnFWjUIxw70Wi6xOvqVUEUNNOzjRURK5BX0TWiDhFAs4GyZMRAznbTkJj /r3vCkIqNsAYGlATp91L7T6nzUTNfzpC50PTLSrmhjbiINl8hr12uD4Jd8yg+N+u8Tq6 3wcMSa2PSW3ypp7VKy69Dwv1K0zyPVbqZINz+AY104u/EO+jqJM+qageiss7xrDG9Nt3 5T3/otvbiNPVBQR1nFRIXHlQlQG1P+yDAGj9zRGX/8lGfH4sk3RGXX1UtRLhG2jHszvS dopg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:to; bh=eiLaWyRZajAGBIzeas9pFSLi/Z7+IjU1MUPIRp7AM2M=; b=Lus2wJ4C6//cGp+o/YW5VmHf5ZUKpNi8bfhxpT6b8mNrDXJG95xVe0cgwrHNL3EYqZ GAyaFjaw1GPx/PEJGHMiXTays7qCzC0LaktWxsKH6hBeQOzGGKt+doUMUttCN9B/HNcn HbeEuzPVoxMg2+0to//fkx/+1XN2C7BfsYLvdJ/nDVd1iYm0Ehkby2fdNFW3CyDJkrR5 nt2Yj9KOMfDutzArgcXhBmr9ULEe2SYTN5s12Zy8XIBxZnLP6x+4G8teYnJXZf3uHmpN GD0Ub0BzO525+gAsMyr9cVGM6xOv/wyX4oZJecTgQyzVVMDR8poRBKBGf5s2TfwD7rf2 BpzQ== X-Gm-Message-State: AJaThX4tN4Sm0UYRDxbuuwFBP4nyQebJkzse6at1vSebY3Kt/5pGOyOW 8vvsoHElqehpjRIhsIv/9M0v8AWr X-Google-Smtp-Source: AGs4zMaxbSIzfd2oclZkdlojVVJuoTTeD30NmCgyO5t5EFMdqA7NPiyFO2csWt9xT6dJQWx2C7WbLg== X-Received: by 10.99.121.140 with SMTP id u134mr19263057pgc.16.1511335617103; Tue, 21 Nov 2017 23:26:57 -0800 (PST) Received: from ?IPv6:2402:f000:2:3001:919a:303a:9cc0:433b? ([2402:f000:2:3001:919a:303a:9cc0:433b]) by smtp.gmail.com with ESMTPSA id m25sm30738637pfg.49.2017.11.21.23.26.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 23:26:56 -0800 (PST) From: fish fish Content-Type: multipart/alternative; boundary="Apple-Mail=_4C1F72B1-A966-4A18-B844-E2960A65338D" Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Questions about QUIC server reset issues Message-Id: Date: Wed, 22 Nov 2017 15:26:52 +0800 To: quic@ietf.org X-Mailer: Apple Mail (2.3445.4.7) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:27:00 -0000 --Apple-Mail=_4C1F72B1-A966-4A18-B844-E2960A65338D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=gb2312 Respected,=20 I am Siyu Yang from Tsinghua University in Beijing, China. I am = a master candidate student interested in the transportation layer of = satellite networks ( LEO/MEO/GEO ) using QUIC. Previously I have done an experiment building QUIC server and = clients in a simulated satellite network environment. It turns out that = QUIC/UDP performs much better than TCP/IP structure because of the = reduced handshake RTTs and congestion control strategies. After reading Google=A1=AFs paper on QUIC in sigcomm 2017, would = you please tell me more about updates of quic=A1=AFs server stateless = reset strategies? Any solution if possible to solve? And I am also interested in QUIC cooperation with CDN in such a = working case: mobile clients may apply for another CDN server when they = are browsing using QUIC, if it is possible that a connection between CDN = server A and the next CDN server B, the server A would send the related = users=A1=AF authentication info in service (users=A1=AF public key and = A=A1=AFs public key so that B would not reject the clients=A1=AF = requests though it is probably the first time that these clients seek = for connection to B so that one-RTT saved in this =A1=B0new=A1=B1 = connection) to the server B if A knows that B would take over A to serve = the clients ? I might not be a very common phenomenon in terrestrial networks =A1=AD I = could think out one that: a CDN incremental deployment that the newly = established CDN server might =A1=B0inherit=A1=B1 users=A1=AF = authentication from its neighbor servers.=20 But it could be a common phenomenon happening every few hours/days in = satellite networks if we deploy a set of CDN servers for example in a = MEO satellite networks which could cover the whole world with a couple = of satellites. Some MEO-constellations has a good properties that the = relative locations within these satellites does not change, just like = constellations we observe in sky. In this time, the CDN servers serve = one client in order and the next server coming to serve could be = calculated easily. If QUIC could SUPPORT servers' authentication = transport, it would help a lot in enhancement of the network flow in = satellite networks! And I am also interested that will authentication transport work in QUIC = using TLS 1.3. Maybe it would also help a lot in terrestrial networks if mobile users = feel good to use their geolocation information =A1=AD Thanks in advance and looking forward to your reply.= --Apple-Mail=_4C1F72B1-A966-4A18-B844-E2960A65338D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=gb2312 Respected, 
I am Siyu Yang from Tsinghua University in Beijing, = China. I am a master candidate student interested in the transportation = layer of satellite networks ( LEO/MEO/GEO ) using QUIC.
Previously I have done an = experiment building QUIC server and clients in a simulated satellite = network environment. It turns out that QUIC/UDP performs much better = than TCP/IP structure because of the reduced handshake RTTs and = congestion control strategies.

After reading Google=A1=AFs paper on QUIC in sigcomm = 2017, would you please tell me more about updates of = quic=A1=AFs server stateless reset strategies? Any solution if possible = to solve?

And I am also interested in QUIC cooperation with CDN in such = a working case: mobile clients may apply for another CDN server when = they are browsing using QUIC, if it is possible that a connection = between CDN server A and the next CDN server B,  the = server A would send the related users=A1=AF authentication = info in service   (users=A1=AF public key and A=A1=AFs = public key so that B would not reject the clients=A1=AF requests though = it is probably the first time that these clients seek for connection to = B so that one-RTT saved in this =A1=B0new=A1=B1 connection) to the server B if A knows that B would take over A to serve = the clients ?

I might not be a very common = phenomenon in terrestrial networks =A1=AD I could think out one = that:  a CDN incremental deployment that the newly established CDN = server might =A1=B0inherit=A1=B1 users=A1=AF authentication from = its neighbor servers. 

But it could be a common phenomenon happening every few = hours/days in satellite networks if we deploy a set of CDN servers for = example in a MEO satellite networks which could cover the whole world = with a couple of satellites. Some MEO-constellations has a good = properties that the relative locations within these satellites does not = change, just like constellations we observe in sky. In this time, = the CDN servers serve one client in order and the next server coming to = serve could be calculated easily. If QUIC could SUPPORT servers' authentication = transport, it would help a lot in enhancement of the network flow in = satellite networks!

And I am also interested that = will authentication transport work in QUIC using TLS = 1.3.

Maybe it would also help a lot in terrestrial = networks if mobile users feel good to use their geolocation = information =A1=AD

Thanks in advance and looking forward to your = reply.
= --Apple-Mail=_4C1F72B1-A966-4A18-B844-E2960A65338D-- From nobody Wed Nov 22 00:06: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 220D512711A for ; Wed, 22 Nov 2017 00:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.721 X-Spam-Level: X-Spam-Status: No, score=-2.721 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, 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 (2048-bit key) header.d=mnot.net header.b=o6gq04qK; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=YYyB7IT1 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9NneQ2ZaJSBZ for ; Wed, 22 Nov 2017 00:06:53 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADF88126CBF for ; Wed, 22 Nov 2017 00:06:53 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EB35D20DDB; Wed, 22 Nov 2017 03:06:52 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 22 Nov 2017 03:06:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= fm1; bh=tOHCH4Axj7RDKeZJgETOjZmTlhIcCwM1Z6KezLf6+Z8=; b=o6gq04qK RbR9oJOi6eWB+6ILoLtOp31k77W2yAzn3KN7uWKFsxbGVBRazSnhL+dLL4Qh9dhq tzUmzhXL5CJsIDYNhczyYZkFHYygF2eUp9TwDCrObobIynFebzLteVRdUS+eVKTx gTEuDhzUz0NIPpJRBgCa7Kw0rpsZLvpWLLkmRh8JP8q3G1LyMIsyb0w73HhOsTm/ VsbGJocX9xmgEHwDyoCyufMv2p9/hs8UB0wZO5zOHCuNIFe53sSkbc68khpKDkZx JGOpvKr1+Zs4NKZ5QN6lakr8aWP5j9TfxywJUUxBolWel22dfC+QDHJQycfwzT7W xjM43wFmwaeBRw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=tOHCH4Axj7RDKeZJgETOjZmTlhIcC wM1Z6KezLf6+Z8=; b=YYyB7IT1/OsUzLR/cy4eNRMdSmc0coR8+XhALzdYn2rwO sFa2CgCMXUe09vL81H3deGFCyYTuC231Amo54mQPbH16stho0aXYHV5qMHLYNOgB IJ+cAXBR/U6e5OnHQlZRnEFzouBCvCtyyQWmOdY32iwuSHsR4CEn1Mseqh93htUT eDE16CwyqssFPpzObc84xktoShSnqS5E5g/CDu9fjlPPD3JioyK66x+JlfLgi8zM QCQJSX8/1asTwb3aTJLtu5GNVXSAJaQq+EY82SXnBObzajYDseZnkRvLzmczjK39 DXBdt6wY83l6+pzwpGbTNT28iLAySK67mPEaBlI2w== X-ME-Sender: Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id EDBE4244E7; Wed, 22 Nov 2017 03:06:51 -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 11.1 \(3445.4.7\)) Subject: Spin bit discussion - where we're at Message-Id: Date: Wed, 22 Nov 2017 19:06:48 +1100 Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3445.4.7) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:06:56 -0000 Hi everyone, First, thanks to everyone for their input to date on this issue, whether = as part of the Design Team (DT), in the meetings, or on the list. It'd = good to see that we can stay civil and professional even when discussing = contentious issues. Since the DT didn't return a recommendation, several people have asked = how we're going to move forward. After talking to our Area Director, = we'd like to share our current thinking in this area. The most important things here are to establish that there isn't any = significant security or privacy exposure associated with proposed = mechanism(s) to improve the manageability of QUIC, and to assure that = the mechanism we ship actually serves its purpose. How we assess these = two things are fundamentally different; security and privacy exposures = are notoriously difficult to find (often only becoming apparent years = after a protocol is adopted), while value to network operators is = (comparatively) much easier to assert. We can't prove that there is *no* security or privacy exposure (see: = Russell's teapot), but we can take reasonable steps to assess proposals = for risk. The Design Team performed this assessment for the Spin Bit = proposal, and did not identify any immediate exposure. That does not = mean it does not exist, but we've done a reasonable first review for = that proposed mechanism. Further review of the Spin Bit can take place = by circulating a full specification among security researchers (see = below). Importantly, any further proposals (e.g., for a "loss bit", or for = alternative means of determining RTT) will need to undergo similar = review and will therefore require a similar level of documentation. There are a number of things that we think will help clarify the value = provided by the Spin Bit: 1) A description of the use case(s) that motivate this proposal. We = understand that the goal is to measure RTT, but some people are still = unclear as to why that's necessary to operate a network. Detailed = scenarios and ideally real-world examples (e.g., from TCP) would help = tremendously. Saying "I need to debug the network" is not enough detail. 2) An actual protocol specification for the Spin Bit, including Privacy = Considerations. There seems to be a fairly good common understanding of = it (especially in the DT), but it would be helpful to have it written = down, so we can make sure we're talking about the same thing. If it were = proposed as an extension, current implementations (reminder: we have 12) = could implement it to see how it works on the network. Doing so would = also give the security research community something to look at (see = above). 3) Data showing that the Spin Bit is fit for purpose under real-world = conditions. Piet's experiment is a start here, but we need much more. = Analysis of how well that data meets the use cases is also necessary. = This might form part of the Manageability Considerations of the draft. 4) A comparison of other potential solutions to measuring delay, and = their relative merits. Again, ideally with detailed, real-world data. 5) An exploration of what the effects of deploying the spin bit are = likely to be. E.g.: Will even the perception of privacy issues change = endpoint behaviour? Will networks treat traffic differently based upon = the spin bit? If so, can that be gamed? Will firewalls and other = gateways police spin bit behaviour (e.g., to prevent data loss), and = what effects will that have? We're looking for volunteers to start drafting one or more documents = along these lines. If you're interested, please indicate this on-list, = so you can coordinate with other interested parties. They won't (yet) be = WG documents, but since the DT didn't resolve the issue, we will discuss = them in the WG. In terms of timeline - resolving this is NOT a blocking issue; i.e., we = can discuss this concurrently with other work on the protocol, and = because it's such a small change in the packet layout, we can add it = right before shipping the protocol to the IESG. In light of that, we will NOT discuss this (or related) issues at the = Melbourne interim. That will allow the people attending to focus on = continued protocol development, and means that people don't feel the = need to travel to discuss just this issue. We would like to be able to = move the discussion forward at IETF101 in London, provided that = significant progress is made on the items above. Cheers, Your Chairs, Mark and Lars From nobody Wed Nov 22 01: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 CEFDD128D3E for ; Wed, 22 Nov 2017 01:15:00 -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 USnbcHsQEDqd for ; Wed, 22 Nov 2017 01:14:58 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id 43C2A120726 for ; Wed, 22 Nov 2017 01:14:57 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 302B8340EA4; Wed, 22 Nov 2017 10:14:56 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.16362); Wed, 22 Nov 2017 10:14:55 +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; Wed, 22 Nov 2017 10:14:55 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 36828905; Wed, 22 Nov 2017 10:14:55 +0100 From: "Brian Trammell (IETF)" Message-Id: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_C0B04D2C-445E-433D-8AA8-B0D345D054AE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Spin bit discussion - where we're at Date: Wed, 22 Nov 2017 10:14:54 +0100 In-Reply-To: Cc: QUIC WG , Lars Eggert To: Mark Nottingham References: X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:15:01 -0000 --Apple-Mail=_C0B04D2C-445E-433D-8AA8-B0D345D054AE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Mark, all, While I disagree with the chairs as to the state of consensus on this = issue, I'm going to go ahead and (perhaps predictably) throw my name in = the hat for this one, since we're actively working on it anyway. I have a few questions and comments on the content of the work program = requested, below: > On 22 Nov 2017, at 09:06, Mark Nottingham wrote: > There are a number of things that we think will help clarify the value = provided by the Spin Bit: >=20 > 1) A description of the use case(s) that motivate this proposal. We = understand that the goal is to measure RTT, but some people are still = unclear as to why that's necessary to operate a network. Detailed = scenarios and ideally real-world examples (e.g., from TCP) would help = tremendously. Saying "I need to debug the network" is not enough detail. This seems reasonable, though I would appreciate some clear acceptance = criteria for the level of detail the WG would consider useful. "I need = to debug the network" is clearly not detailed enough, but what is? > 2) An actual protocol specification for the Spin Bit, including = Privacy Considerations. There seems to be a fairly good common = understanding of it (especially in the DT), but it would be helpful to = have it written down, so we can make sure we're talking about the same = thing. If it were proposed as an extension, current implementations = (reminder: we have 12) could implement it to see how it works on the = network. Doing so would also give the security research community = something to look at (see above). We already have this in the form of PR 609, though it needs to be = rewritten. I'd be happy to volunteer to carve this off into a separate = I-D if that's what the WG wants. The request for a privacy considerations section for a single protocol = feature seems odd to me at best, and prejudicial at worst. Where is the = privacy considerations analysis for other features, for instance, = various header compression schemes? But, again, given that the work is = already done (and mostly in markdown!), dumping it into an I-D is = marginal work. > 3) Data showing that the Spin Bit is fit for purpose under real-world = conditions. Piet's experiment is a start here, but we need much more. Piet's current work represents much more than was presented to the list = during the Singapore meeting, but some indication of how much more we = need would be useful here. Piet is producing a detailed analysis of a = number of proposed measurability features (one-bit spin is done, and = two-bit spin and a blocking bit as once proposed by Martin Duke are on = the implementation schedule now), and we can certainly feed this into = the draft. > Analysis of how well that data meets the use cases is also necessary. = This might form part of the Manageability Considerations of the draft. >=20 > 4) A comparison of other potential solutions to measuring delay, and = their relative merits. Again, ideally with detailed, real-world data. As in 1, there's a whole lot of literature here. I'll say that we'll = probably produce some numbers as part of the same evaluation above = comparing the latency spin bit to handshake RTT measurement (presuming = that the handshake remains visible enough to measure) and to "find some = TCP in your aggregate and compute latency based on that" (which reduces = to "force 1/k QUIC flows to TCP in order to get enough TCP in your = aggregate to compute latency" in a mostly-QUIC world, yay fallback!). > 5) An exploration of what the effects of deploying the spin bit are = likely to be. E.g.: Will even the perception of privacy issues change = endpoint behaviour? Will networks treat traffic differently based upon = the spin bit? If so, can that be gamed? Will firewalls and other = gateways police spin bit behaviour (e.g., to prevent data loss), and = what effects will that have? I don't see how this request is useful. Perhaps if the proposal were to add some new form of exposure not = already ubiquitously available in TCP, with which we did not have years = of operational experience, this might arguably be necessary work. = However, as it stands, the exercise would certainly lead to a = fascinating exploration of the economics of modern Internet access, but = given the lack of ability to run sensible experiments to form an = evidentiary basis for decision, such an exercise would always reflect = the prejudices of its authors. One could write an essay for 5 that will = reasonably support any view one cares to have here, which yields it = useless for helping us to make a decision. > We're looking for volunteers to start drafting one or more documents = along these lines. If you're interested, please indicate this on-list, = so you can coordinate with other interested parties. They won't (yet) be = WG documents, but since the DT didn't resolve the issue, we will discuss = them in the WG. >=20 > In terms of timeline - resolving this is NOT a blocking issue; i.e., = we can discuss this concurrently with other work on the protocol, and = because it's such a small change in the packet layout, we can add it = right before shipping the protocol to the IESG. I will note that any bits we designate to measurement will rapidly = become part of QUIC's invariants, whether we intend them to or not, so = the details of any design we choose will have to be carefully = considered. However, that probably does not imply that those bits (their = number and position) need to be proactively added to the invariants = currently under discussion. So I agree with your assessment that we can = tip this into the short header relatively late in the game. Cheers, Brian > In light of that, we will NOT discuss this (or related) issues at the = Melbourne interim. That will allow the people attending to focus on = continued protocol development, and means that people don't feel the = need to travel to discuss just this issue. We would like to be able to = move the discussion forward at IETF101 in London, provided that = significant progress is made on the items above. >=20 > Cheers, >=20 >=20 > Your Chairs, Mark and Lars >=20 --Apple-Mail=_C0B04D2C-445E-433D-8AA8-B0D345D054AE 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloVQA4ACgkQihK3vwvq RqPy8g/9ExrL4d6jfcdxQEwwXI4WC0xT5t8xpNwODpVxkkWR98n+XGbGWwEC56Yq 62oa24jvT4FO/rFnBgFqTXuEVYj3p443j5TZo45pj7w6JHJH4w4GXBbxw5iA3nWA bPIlL+vjp5JTRV6YUgFwnW3dJ+ns5Fpa3mV1E/4cbfuVHlrBpMYXQ9Gon3Izb5f6 tnmS1cz1cYI9u2vdWIjy70MZq/ntKzIZ68rCFGd+uV2EGFGs0jC+8aqDjwMZfXRf F4e+yPhsRKXTWzEan9NvpkICrvJcWzVGJSkuYth/mIiWeMreVxad5xaopNrprqmD UwMXTE9Yhy2oF+LtTq5kpTFqvTO4Fw7g14j0foJUSRmNZl/T2TXl5k7ETvRaN/L6 lQykqPpmNNOkV+F0GZPC1aKyEAcMAebj2QBwQU+Ac0i8VN9cz9HTEjzSMdJssZZz g7sX2Jg188CsM1fFoxw89kqyAo3OggTDSJUPRvfuETLPOVOY7m/eto1txYin53CS yT8QuMfUI0s8rrI4LPDSbjBf3cMWgvI5JyE/ABUAs0dlh2oL/CJDudLPK8T74vDC +rUv/0sjJnMX5G/eBan0wkq1AHGPwiUgpsHi4+C+aR0i4GHXgQRWexVQ7hNm/1nc BonkcJLbMeumU9K5C5IC15v9Tq/eaSPAem5lGImbjBj2Nl/bsT0= =YQmO -----END PGP SIGNATURE----- --Apple-Mail=_C0B04D2C-445E-433D-8AA8-B0D345D054AE-- From nobody Wed Nov 22 01:45: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 D77EC128DF6 for ; Wed, 22 Nov 2017 01:45:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.919 X-Spam-Level: X-Spam-Status: No, score=-6.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AucjShlp33Gq for ; Wed, 22 Nov 2017 01:45:41 -0800 (PST) Received: from edge20.ethz.ch (edge20.ethz.ch [82.130.99.26]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1A212420B for ; Wed, 22 Nov 2017 01:45:40 -0800 (PST) Received: from CAS20.d.ethz.ch (172.31.51.110) by edge20.ethz.ch (82.130.99.26) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 22 Nov 2017 10:45:37 +0100 Received: from [82.130.103.210] (82.130.103.210) by mail.ethz.ch (172.31.51.110) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 22 Nov 2017 10:45:37 +0100 To: QUIC WG From: Piet De Vaere | ETH Subject: More spinbit implementation experience Message-ID: Date: Wed, 22 Nov 2017 10:45:37 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8"; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Originating-IP: [82.130.103.210] Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:45:43 -0000 Hi all Since my last mail I have continued work on the analysis of the spinbit. A summary of my progress can be found here: https://devae.re/f/eth/quic/spinbit_report/ It includes tests with loss, jitter, reordering and different traffic patterns. If you have any questions / suggestions / experiments you want to see, shoot me an email and I'll see if I can run them. Piet From nobody Wed Nov 22 02:01: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 1C150127137 for ; Wed, 22 Nov 2017 02:01:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 mnZxsXgmsf-q for ; Wed, 22 Nov 2017 02:01:52 -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 3DC41120227 for ; Wed, 22 Nov 2017 02:01:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 71D25BE55; Wed, 22 Nov 2017 10:01:50 +0000 (GMT) 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 obaP-BXpJL6m; Wed, 22 Nov 2017 10:01:50 +0000 (GMT) Received: from [134.226.36.93] (bilbo.dsg.cs.tcd.ie [134.226.36.93]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 2E1D8BE53; Wed, 22 Nov 2017 10:01:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1511344910; bh=hm6YYCQeZeq+8DQSFvgbqPdDELOrN8vZrdK/EPgX5aM=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=tfg+vnplhkQqWn/8Nsj8c82mDqbfhR8D0g1o/pUWYs4v0XisvQPQUBACXwTPP24Os 0ASgsIbSemW4CXYp1zu+6hDx8KYA+6h8tW7G8NgZAkihxUTInOVcAZ/ZpI6ezUs1A8 Erbv6Il640bfc6ZcU4Z5Ru4o9km5mosQOh2oJX5M= Subject: Re: Spin bit discussion - where we're at To: "Brian Trammell (IETF)" , Mark Nottingham Cc: QUIC WG , Lars Eggert References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 22 Nov 2017 10:01:49 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Wlftsn3P25DFpD8jXt9wTtwQrHSSLX7xc" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:01:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Wlftsn3P25DFpD8jXt9wTtwQrHSSLX7xc Content-Type: multipart/mixed; boundary="buuCAcgdfq2ASX4b7xuSCsXFLjCwiUD85"; protected-headers="v1" From: Stephen Farrell To: "Brian Trammell (IETF)" , Mark Nottingham Cc: QUIC WG , Lars Eggert Message-ID: Subject: Re: Spin bit discussion - where we're at References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> In-Reply-To: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> --buuCAcgdfq2ASX4b7xuSCsXFLjCwiUD85 Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: quoted-printable Just on this one aspect... On 22/11/17 09:14, Brian Trammell (IETF) wrote: > The request for a privacy considerations section for a single > protocol feature seems odd to me at best, and prejudicial at worst. > Where is the privacy considerations analysis for other features, for > instance, various header compression schemes?=20 I agree that asking that there be a privacy considerations section in RFCs for every bit in every protocol would be OTT. But that was not how I interpreted Mark's mail. What I thought was being requested and what I do think is reasonable is to document a privacy analysis for any quic protocol bits that are visible to the path. Whether or not some or all of that text ends up in some RFC is another day's work. Cheers, S. --buuCAcgdfq2ASX4b7xuSCsXFLjCwiUD85-- --Wlftsn3P25DFpD8jXt9wTtwQrHSSLX7xc Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaFUsNAAoJEC88hzaAX42ioIYH/1ybMV5Tr0maXOL5uK14mZgk Li81oTgQgTs1LlPjc5RoT45AsE2bsrOBQ86RVnYqEKlevncSajigYEJBfLYtdjBJ Zph4e/AVofuDjYWdGfLRpGeVOqbg4GsDWQdzTdL4PVYVWOO/OwDRhf6mD11D6xd4 h3FhKDtiUaX9FKTTDh6R8cPZorG/KATyduQhy97DYDqo3WmJsK8Ctf+bMBvE01Wh pelgH8PCd47py1q6z7s2z3mW7lm5ZtOOCBuzI99j8ce/dpjlfJFSFM3lgVT0waA/ Y0U5OLiz2UKOI7gqrnhZ5aiBtHLXgrBE92Pj+UnXIgZJYCCbqW3a3lgjGNePQe8= =a7Rz -----END PGP SIGNATURE----- --Wlftsn3P25DFpD8jXt9wTtwQrHSSLX7xc-- From nobody Wed Nov 22 02:10: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 CB8D01293E8 for ; Wed, 22 Nov 2017 02:10:49 -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 fLjG9iNO3v46 for ; Wed, 22 Nov 2017 02:10:48 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id E0328127137 for ; Wed, 22 Nov 2017 02:10:47 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A1492340EA5; Wed, 22 Nov 2017 11:10:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.28817); Wed, 22 Nov 2017 11:10:46 +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; Wed, 22 Nov 2017 11:10:46 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 36837840; Wed, 22 Nov 2017 11:10:46 +0100 From: "Brian Trammell (IETF)" Message-Id: <6E8C9CCE-7AE9-40C4-B5BC-CB94486B8AC3@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_E611C3D7-2D7D-4438-8566-F70BAA20CEBA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Spin bit discussion - where we're at Date: Wed, 22 Nov 2017 11:10:45 +0100 In-Reply-To: Cc: Mark Nottingham , QUIC WG , Lars Eggert To: Stephen Farrell References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:10:50 -0000 --Apple-Mail=_E611C3D7-2D7D-4438-8566-F70BAA20CEBA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Stephen, > On 22 Nov 2017, at 11:01, Stephen Farrell = wrote: >=20 >=20 > Just on this one aspect... >=20 > On 22/11/17 09:14, Brian Trammell (IETF) wrote: >> The request for a privacy considerations section for a single >> protocol feature seems odd to me at best, and prejudicial at worst. >> Where is the privacy considerations analysis for other features, for >> instance, various header compression schemes? > I agree that asking that there be a privacy considerations section > in RFCs for every bit in every protocol would be OTT. But that was > not how I interpreted Mark's mail. >=20 > What I thought was being requested and what I do think is reasonable > is to document a privacy analysis for any quic protocol bits that are > visible to the path. I think it makes more sense to document a privacy analysis of the QUIC = protocol's wire image, holistically -- traffic analysis doesn't use one = bit at a time, and the information available in one bit may be more = readily available in others up and down the stack. So if the request is = a contribution to an eventual privacy considerations section for the = whole wire image, then great, I'm happy to contribute it for this one = bit, as I've basically already written it. :) In light of the rest of the message, though (especially point 5, which I = really can't see how to turn into something useful either for the = decision process or for future users of such a facility), I read this = request more as a proof of work, which is not what we do here, at least = not intentionally. Cheers, Brian > Whether or not some or all of that text ends up > in some RFC is another day's work. --Apple-Mail=_E611C3D7-2D7D-4438-8566-F70BAA20CEBA 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloVTSUACgkQihK3vwvq RqO8khAArnrsxoLhv7EsqG8Gfs+u7J5djxVktGQIvtqwJVHwUNU2/7rmW8nGVciF N+962oqYCh07OsRZ/F5mFJEdA8byCvxCxgWFG1XBobx0dFUj8KghYxUAKAlH7KJN KF149tmHsolGfZ5i47tczuQqbNaraZ3YfJqjS3U2m+nsQjCRCWplDvabqdJFGsvL bTaJrqOrIfR3PRl59OWl94mnVxfgfZ1XNbt4gO8EeAUFE9cG+SH/qIiT4EhSmRJd PtvRctdeNuProMaDHQD1v4ucr5aO8siUOmbLEOux7o/+eGuOV8kWLW/qUMFC6epJ 463HBxCg02QsyM3XMg2PtDa1nk75SHRWosr5pib6KCR4eb08HJ2+WXYawATo2HD8 39lnBVFtCE99O6Gr/RDsVa5pOeosUfcMqwc5XiVQ4MeFjwLQWNSny7zPrfH6Srbr 3CLfVrl6bAIYQ6LaoKhtQMzqWe/SkXDbaXdzGybCjrsvEDRr/RT2Oxf9cow8nVgY cYlbhgfO33Dx2dGNorrMG6HkFot42uq5+umBJPnIsNhlgqz/MMLxKKzbTUiUKlN6 i8CGOlxcmzvAj+tJPDD7+VhMV+xM35v4zHf3JcWZbg07ZB4BUhMcUVIKNXQWWncR JcRIZe0Lfp1toft0JW8Z6RQ41qYq/2Y/UuGjTJ2URrTOlgC7EeM= =+iKM -----END PGP SIGNATURE----- --Apple-Mail=_E611C3D7-2D7D-4438-8566-F70BAA20CEBA-- From nobody Wed Nov 22 02: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 6BEC31293F2 for ; Wed, 22 Nov 2017 02:36:00 -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, 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=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 OckzhdSoz0LL for ; Wed, 22 Nov 2017 02:35:58 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAE971293FD for ; Wed, 22 Nov 2017 02:35:58 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,436,1505804400"; d="asc'?scan'208,217";a="228178137" Received: from hioexcmbx05-prd.hq.netapp.com ([10.122.105.38]) by mx144-out.netapp.com with ESMTP; 22 Nov 2017 02:35:57 -0800 Received: from VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) by hioexcmbx05-prd.hq.netapp.com (10.122.105.38) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 22 Nov 2017 02:35:57 -0800 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS06-PRD.hq.netapp.com (10.122.105.22) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 22 Nov 2017 02:35:57 -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=yI8r6EOCW/aTwi5dyDCJ5qKjEc4+i7BFLDi3Sq2md4Q=; b=PgAK1DPLB3Pm6DFGNnMSCc4BV115qufydOEvMkkzM/B2Sxgfl+MjoaX1Xib9yYqkC7FsqgzaAaGESNHn7ox096tGmFfve2QsQS/NvKVpI0/NyNqsrLGapNRLzCLfORlQgA4+mwy8F0gBXx6sY/WfQig60bpWmmNeSaApV7TVYX4= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 22 Nov 2017 10:35:55 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.004; Wed, 22 Nov 2017 10:35:55 +0000 From: "Eggert, Lars" To: Stephen Farrell CC: Brian Trammell , Mark Nottingham , "QUIC WG" Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAANHICAAAmEgA== Date: Wed, 22 Nov 2017 10:35:54 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:HNqG7osIEtXs+WC6Gyltv4qibk3GQi+Tat6UBum8sO8cfTHTa5j7AVj9g0leAKROLzEVNpfsMC7v/7gPXgBQj+n2mfza0sxWHkPB0Tye2ovksHqiSd9dr2wu825gEuirPhHKJxqq0aOnN2dOo7QLfkbX5XJfe/5Fes8VxNZGqf6KBFx4z5txnmANoFVRqiB7iUMGpAs1hb96F6Nh8GgDpqozWvh7pF9JcI2Bg8MfrAGfb9d/Pt1SvS1u5F74FHPDL4+IaGPoPyVuIhqVGQtxjMjYnceh0p3JyUWQCiSLjTdVj2wRu8vD2Na8WzNgxU2157OJEQPuNXf2fElhV7x9IBTXj3JZv8UHSnNRUJXJYhs=; 5:Migi+tlNg1gUAznIjwBw3sy3so8OnGtvrcvv6fI1kcQITZhlgD8b4wqykB7uGlO4ecYwvkrUzi6TOOf8RtSOjzVBwVnZhxfZs1GZgU48CGvqvHcCxTzERQctKghVbvQJWWcHHKEw/ZAu6AQkTf56CQBMsfCFJtSXqtt9eCKzMd0=; 24:6idw/xAbbGdjYAyzBNh+feodhZOJpFM2wMhZJiZAJLuT8hf/E0eVZEp9ySyUOrw9vNVx4b3GfkfpKu5fIj7xyxK+ZBmk1h6xVWK9c6mnJnA=; 7:khg/ZbA8RYIbYWH4R8GgkZA1Ze+uwY3Fb145eCoTYr/0/Gwaiw5qnG8uigDI1d3wb0YnE2Zaq1VpJSXp93piyoPpBvfn7w50RPU0OkTUzKupfJr8oV7f6yA4PsbWBJxoz7thhxg8ncT7iZc9iKi1QDrTIm4w401YxDWxaOGyKBEQ3PtKOCrBRL31JdVyBU0nZTw/di/e9EQHI3F6R0CiCMA2GNFXq9myriSlOYGu2d2JGaArfTh7LeKHQOj/NIaF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4c850476-8dfd-4279-dc6d-08d53194cfb0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600022)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258)(49563074); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231022)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1764; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(199003)(377424004)(24454002)(189002)(3280700002)(99936001)(6506006)(229853002)(478600001)(2906002)(99286004)(68736007)(2950100002)(33656002)(6916009)(4001150100001)(8936002)(50986999)(6436002)(6486002)(77096006)(76176999)(25786009)(3846002)(102836003)(83716003)(6116002)(53936002)(316002)(106356001)(6246003)(8676002)(4326008)(7736002)(50226002)(86362001)(3660700001)(66066001)(82746002)(36756003)(97736004)(54906003)(2900100001)(53546010)(189998001)(81166006)(6512007)(236005)(561944003)(5660300001)(14454004)(54896002)(57306001)(105586002)(101416001)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1764.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=_4EE0BB60-5D7A-4E9A-8184-129768D94AD5"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4c850476-8dfd-4279-dc6d-08d53194cfb0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 10:35:54.9532 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:36:00 -0000 --Apple-Mail=_4EE0BB60-5D7A-4E9A-8184-129768D94AD5 Content-Type: multipart/alternative; boundary="Apple-Mail=_871F0634-C888-4FEB-97F5-9BE1D7D938E4" --Apple-Mail=_871F0634-C888-4FEB-97F5-9BE1D7D938E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-11-22, at 11:01, Stephen Farrell = wrote: > What I thought was being requested and what I do think is reasonable > is to document a privacy analysis for any quic protocol bits that are > visible to the path. Whether or not some or all of that text ends up > in some RFC is another day's work. for the Spin Bit specifically, the intent was to permanently capture the = analysis the DT has done, so that when others review the proposed Spin = Bit specification, they can take that as a given and direct any further = analysis to other aspects. It made sense to the chairs that that = specific analysis should become part of the Spin Bit specification. I = think we'd be open to a discussion on whether a broader document = analyzing the QUIC wire image would be a better home for this. The main = point is for the work that the DT has done to be documented. For proposals other than the Spin Bit (I think I have seen individual = contributors at least mention "loss" and "congestion" bits, but without = much detail), we wanted to clarify that we'd like to see an analysis and = discussion of their privacy aspects to roughly the same degree as the DT = has performed for the Spin Bit proposal. Lars --Apple-Mail=_871F0634-C888-4FEB-97F5-9BE1D7D938E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On = 2017-11-22, at 11:01, Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
What I thought was = being requested and what I do think is reasonable
is to document a privacy analysis for any quic = protocol bits that are
visible to the = path. Whether or not some or all of that text ends up
in some RFC is another day's work.

for = the Spin Bit specifically, the intent was to permanently capture the = analysis the DT has done, so that when others review the proposed Spin = Bit specification, they can take that as a given and direct any further = analysis to other aspects. It made sense to the chairs that that = specific analysis should become part of the Spin Bit specification. I = think we'd be open to a discussion on whether a broader document = analyzing the QUIC wire image would be a better home for this. The main = point is for the work that the DT has done to be documented.

For proposals other than = the Spin Bit (I think I have seen individual contributors at least = mention "loss" and "congestion" bits, but without much detail), we = wanted to clarify that we'd like to see an analysis and discussion of = their privacy aspects to roughly the same degree as the DT has performed = for the Spin Bit proposal.

Lars
= --Apple-Mail=_871F0634-C888-4FEB-97F5-9BE1D7D938E4-- --Apple-Mail=_4EE0BB60-5D7A-4E9A-8184-129768D94AD5 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloVUwkACgkQVLXDCb9w wVfUrA//dOzRm5sg0iCZwh7zPl1kfj/SqMOSu2w8fFRdivp1YgA1b7gaFjGf49wG RhVzZ/jrW1E6zysIqsnY7FWP58bYHcSG/Yy7oRO+ICGMHF2imn4/5Ie6LJ9tgekF eCHO64cuhUQR81//1K77pj6BC+wTbtUPObBJX0Jd65ikxQ7tqlS+5UfjpAHeR+HX 0oYt5mBlULZnFeMGDzw8gMronEA8DQ2gWud5c6uE8xZcLxxVaabaz6Jw8Rhj1PPj rZqQrueDSbc+YzxFqTzY8eicWO+oN0KWQ6clWPd88Gxr/ILznlQ0UV8xufb2G8yA 1BPr9f+drS5Cl5rOM0NXuGlcBxAytdHfI1QZMlipWH/dzUCAe+2hHHHSTf5npyY5 7sDkRGJ1ph237GULPVkSuD8wvZQHZhKb97gXH2N7+wqPMnf5Y14qrq+PrSbrIVXF 5rBUY8pQgvrYv5sdKCwTSwtj8MLnaBsoU93XIOzhFcNHnRuPU4wwTAZotY7EhWJV cit9h3BLT69rwKvZ60QdVIvxJ5BRz0jNWTpW18EwijfbZaf4piT1EzHaYdAlaPBd V/JZwMdQQ+F+xLYyqwnTVO7rNLVntUTDaQrnu5VNzbdEA1rkcUo7x29LwcDFRnYm 592fI9/MaYXHjSnJo66jh6RO6FWkezQG6St4c+eaDuDKpwABTs4= =Lw1m -----END PGP SIGNATURE----- --Apple-Mail=_4EE0BB60-5D7A-4E9A-8184-129768D94AD5-- From nobody Wed Nov 22 02:59:01 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 D866F129406 for ; Wed, 22 Nov 2017 02:58:59 -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 vGpY04X8fUdk for ; Wed, 22 Nov 2017 02:58:58 -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 B3DF71292F4 for ; Wed, 22 Nov 2017 02:58:57 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id E692B3405AB; Wed, 22 Nov 2017 11:58:55 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.9567); Wed, 22 Nov 2017 11:58:55 +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; Wed, 22 Nov 2017 11:58:55 +0100 (CET) Received: from vpn-global-dhcp2-174.ethz.ch (account ietf@trammell.ch [129.132.209.174] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 36845518; Wed, 22 Nov 2017 11:58:55 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_EDB9636C-93AF-49C8-B2CA-8CFC51DE20A1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Spin bit discussion - where we're at Date: Wed, 22 Nov 2017 11:58:53 +0100 In-Reply-To: Cc: Stephen Farrell , Mark Nottingham , QUIC WG To: "Eggert, Lars" References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 10:59:00 -0000 --Apple-Mail=_EDB9636C-93AF-49C8-B2CA-8CFC51DE20A1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Lars, > On 22 Nov 2017, at 11:35, Eggert, Lars wrote: >=20 > Hi, >=20 > On 2017-11-22, at 11:01, Stephen Farrell = wrote: >> What I thought was being requested and what I do think is reasonable >> is to document a privacy analysis for any quic protocol bits that are >> visible to the path. Whether or not some or all of that text ends up >> in some RFC is another day's work. >=20 > for the Spin Bit specifically, the intent was to permanently capture = the analysis the DT has done, so that when others review the proposed = Spin Bit specification, they can take that as a given and direct any = further analysis to other aspects. It made sense to the chairs that that = specific analysis should become part of the Spin Bit specification. I = think we'd be open to a discussion on whether a broader document = analyzing the QUIC wire image would be a better home for this. The main = point is for the work that the DT has done to be documented. Okay. That's somewhat more reasonable than what I read the ask to be = ("we're going to gate this on the people who care about this doing some = non-trivial amount of work"). Those of us who volunteer (help, please, = anyone? :) ) can certainly pull together what we have in a single I-D = and ask the WG what more it thinks it needs. To me all this seems pretty = clear, but I've been working on this topic for a while. > For proposals other than the Spin Bit (I think I have seen individual = contributors at least mention "loss" and "congestion" bits, but without = much detail), we wanted to clarify that we'd like to see an analysis and = discussion of their privacy aspects to roughly the same degree as the DT = has performed for the Spin Bit proposal. Ok. A couple of process questions remain open here, then: (1) can the chairs articulate why, before the finalization of v1, they = are proposing to go to a method of working that is somewhat more = heavyweight than the issues-and-PRs-plus-ML that enhancements or change = requests to the protocol to date have required? (2) to what proposals, specifically, does this heavyweight process = apply? the spin bit and measurement proposals articulated to date? = proposals impacting the measurability of the protocol? proposals = impacting specific unencrypted bits in headers? all proposals impacting = the wire image of the protocol? Thanks, cheers, Brian --Apple-Mail=_EDB9636C-93AF-49C8-B2CA-8CFC51DE20A1 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloVWG0ACgkQihK3vwvq RqNBPA//RcHezBILOcl0VEuala0t90mO/IPhf/m035mEppyq4RRnP2/jS66uBWW3 0BKQq94pm8VV1nvqjN+j80CftBQ598yx+DtxfRgY7NPn+KbqBz1uGfIBpLktUxVm WDREp1aIOgiHc7oqj2a6jnQaaPN3UAwtoIZ8+GpGAnddA8yETADSqKJeaawJJCKP EONciYE4x0pAhAFCBJag6LVz2SVZMGT3Qm/L/Jh39B74GdI8iA6ugMBn4GDkf1pd EzPNoxkswJr7nAt1oY0qrdtcUGVqus55Y43vcLYrIHsreRbVIFGVmTVF+LF6BR9z jrIzQv1gOHCSeJm4gbiyUBbbtCYTVGQ7R+MbXtC3gAY+XEED1Mce6yfnq9GQNF4+ 8qW1MbkL2Yg2recHk7offLSOGM9U+DMyCXRmBX67BchhdQdCFVY3l0YFZyChIID7 T0upu9JiUhLmvKBoR8/s/7kshaPe2mMpkJFeitGS51O3B+FdiaEYZsQlX0BUpLiu yLq/SfKBjA0BTKC4siEZTNaL9sAntB6xTU561crYZ/dDYmWrs9xQLTgP8IRR9hDs aJ0HDToabRiNEuJUFt9r5B9wvjzYes5bkTzPY50Cy2H3kbMdU9rhHBuIuwyhq5zh BJthh8q+zeilKltaKKv5aaSZvpBsrQTzxno1YyJVm21IjukLI4Y= =rIXV -----END PGP SIGNATURE----- --Apple-Mail=_EDB9636C-93AF-49C8-B2CA-8CFC51DE20A1-- From nobody Wed Nov 22 03: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 55F57129408 for ; Wed, 22 Nov 2017 03:27:07 -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 (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 FBjKmglH5IhW for ; Wed, 22 Nov 2017 03:27:05 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A1112426E for ; Wed, 22 Nov 2017 03:27:05 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,436,1505804400"; d="asc'?scan'208";a="228183737" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx144-out.netapp.com with ESMTP; 22 Nov 2017 03:27:04 -0800 Received: from VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 22 Nov 2017 03:27:04 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 22 Nov 2017 03:27:04 -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=hHl4vZrtu/JXWBDawRyiGSGgTR5CkzZirb2PjPDqG8k=; b=XfdnLzJBYG6J/7CkFLHLn58dXpbUQt5YyEvdQGOSXXmZ4YrDMgU1R1bX7aasD9Lk10F0QiqvuICWRX+LhV0Roc1M4zBPBltmvQ1dv0PaOUzwzdkXZGgbMQqGVFBKWkfwqgL/rn7Ivy7wz9l7Mor/CKbWcYa0PZoWRga3Y2TDjb4= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 22 Nov 2017 11:27:02 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.004; Wed, 22 Nov 2017 11:27:01 +0000 From: "Eggert, Lars" To: Brian Trammell CC: Stephen Farrell , Mark Nottingham , QUIC WG Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAANHICAAAmEgIAABm6AgAAH2wA= Date: Wed, 22 Nov 2017 11:27:01 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:rh5/ip2DC+6+ZvedKDVpyaFDfD1SzqeCj7Y7e18aE5i23z55s1QTRjA9KG24DSnUWV6JW/fq5r37taDVb+mX2bzwogvSkpWFM3VoNSr+HTsummSXiyDomrsr018uvKJe0RU6ppd6HZKjOSdHuvvu81eumnQ/hA3pJXTmKThJ5xs1gT6n490pEx7MlkrAoI+LazmxYwDD+AEPYj0SBIEWFK1X46KZJ1X31M6XS6geU4nB7ojdbvHZ6Pq3GcYu1nmhtNZKFHO8ryCpzTxL6xBVUicHhmvx552NntQ86twC3O4Z6HReojFbkDPkk9EB3z8xL8DIixPnr3zLUrpIAi93ge76lxWvNQCmpryUsxF5gqY=; 5:/BCtBxHGgYOECOnUACsExRLvQ+rzbExWMZ3XMINPxJLQFiNMSG+Rw+b2drOe3Vl4RymfSTclDaABrKffCueQUejJ/dsfxpG0nYNZnGY2k3pzi5H5sNMHv/FJPy1sl7LMkrfpG+XEK5G0cDRJ3yvs2079mfn7cEcKqQ06dIr5Rik=; 24:YhIKCsPqIhj76Um4HRFUqjNk9XH0qexSZLof90S012zxihFP5B1WwCezEuvpaa9kpHdS0jsNwslHOMYdC+P6LK8YjY4Z33ukTbrU4XouMuw=; 7:PDioDqgVjX2OHidsfBWby7vONsmGfFojQMsnALYAY/xo7VbpQkw4SmZY/I9nsVCgoOlH0IAh1M/gh0St9c/Cvj6eggRecNrOhYVaRr9qEo17Sjhk+cwNIprQqxFt5RjqlhpK8nMQ9Bwv5u/tR+3cIP8hwRCe9XukPPGYrJo/Up78n7Pg/RJ8GbPJgUy/q+lzOOnh+5DormroNSTa3CYamEEFrcoP0GOgjTSxBr8/hWf05Zq5dXAfiJvkyoyzno35 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2c60b86f-974e-4c3e-3d8b-08d5319bf38f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3231022)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1761; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(346002)(376002)(189002)(377424004)(24454002)(199003)(106356001)(8676002)(102836003)(53936002)(316002)(105586002)(305945005)(68736007)(54906003)(97736004)(2906002)(81166006)(81156014)(53546010)(6512007)(14454004)(36756003)(93886005)(6916009)(2950100002)(86362001)(478600001)(82746002)(2900100001)(25786009)(4001150100001)(83716003)(50226002)(4326008)(101416001)(8936002)(33656002)(6246003)(6436002)(77096006)(561944003)(5660300001)(57306001)(3660700001)(189998001)(7736002)(6116002)(3280700002)(229853002)(3846002)(66066001)(50986999)(76176999)(99286004)(99936001)(6506006)(6486002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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=_1E6E3CDE-BA96-4025-B3C0-3174F5AC4B6A"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2c60b86f-974e-4c3e-3d8b-08d5319bf38f X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 11:27:01.7954 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 11:27:07 -0000 --Apple-Mail=_1E6E3CDE-BA96-4025-B3C0-3174F5AC4B6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, Mark is asleep (I hope), so below is my personal view. On 2017-11-22, at 11:58, Brian Trammell (IETF) wrote: >> On 22 Nov 2017, at 11:35, Eggert, Lars wrote: >=20 >> For proposals other than the Spin Bit (I think I have seen individual = contributors at least mention "loss" and "congestion" bits, but without = much detail), we wanted to clarify that we'd like to see an analysis and = discussion of their privacy aspects to roughly the same degree as the DT = has performed for the Spin Bit proposal. >=20 > Ok. A couple of process questions remain open here, then: >=20 > (1) can the chairs articulate why, before the finalization of v1, they = are proposing to go to a method of working that is somewhat more = heavyweight than the issues-and-PRs-plus-ML that enhancements or change = requests to the protocol to date have required? The discussion leading up to and around the Spin Bit has demonstrated = that proposals that affect the cleartext part of the wire image are = incredibly controversial, and take the WG a lot of time to chew through. = The Spin Bit alone took six months and a DT, and it's arguably amongst = the most simple proposals one could make in this space. We're trying to find a way to have future discussions on such proposals = in an efficient manner, in a way that minimizes further delays to our = main deliverables (the base drafts). Part of this is that such proposals should be contributed to the WG in a = way that lets other contributors understand the rational, design, and = implications of the proposal, i.e., a somewhat longer and more = structured format than we'd usually see for GitHub issues and PRs. So yes, we're asking the proponents of new schemes that affect the wire = image to do a bit more work and produce a more comprehensive proposal, = compared to what we get in GitHub. But the hope is that this will reduce = the effort the WG needs to spend overall on understanding and discussing = such proposals, i.e., we hope for a net win. For the Spin Bit specifically, most of the things that Mark listed exist = in one way or another, it'll be mostly a short exercise in assembling = that material? > (2) to what proposals, specifically, does this heavyweight process = apply? the spin bit and measurement proposals articulated to date? = proposals impacting the measurability of the protocol? proposals = impacting specific unencrypted bits in headers? all proposals impacting = the wire image of the protocol? My personal view is that I'd like to see this for proposals that affect = the cleartext wire format in ways that may affect user privacy. For = example, renumbering the packet types is probably not a change we need = to be overly concerned with. (I realize this is not a clear-cut = definition.) Lars --Apple-Mail=_1E6E3CDE-BA96-4025-B3C0-3174F5AC4B6A 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloVXwQACgkQVLXDCb9w wVer0hAA2GS3ideIasbFGmv9s3qydQjgbN01keDdgsD0jYzTeIRgRwvtSu3eha0O yx+R9hcFh3TriSvuHNCB3RPymTRfH3BO7ABaRdh28MoA9VxEcyHnFtV0WgAa4qUl MvS3CWvkc6hMtd9GYEoRRylMillBMnTLKyQteJVo1KTZEzMk0uQbKPKxtDVJyoEJ /7Xtce9dZ7lmKebKAO+RF6qmJAkE210nFKlAwn91BjbFW+NeLy4MeWWu2UWgnhjo 5O3/7KPyvPfAKlIv3j4jM+dZkFAVTtQyJDE0N80PCyyBvjUtMzVKbvwad07B19qG k422vFGK4eB0qbCe2/Be5ZowRFD2yzPgNG3C8aEsJ5eboezazmk7SRt0OKvkAv3O i1YKTawlnd6guUjErGfPIYkWbbxJ8Pg9buvjfj75OmEVAI4anmO4HGRhlFEyXwYD vZECmv5JGi+NW7mwZvtTsiA14KKp+KeE3RSsT6uyuq25dLL3BEvK/ac0d5R+qS6R vuqx82Q/hGRJbrX/rcRYxBA+s1AKNEawewjb6hPqWfgA1BGXtBXHa8iQ46P2ghqz EoB69GKLgnXkb1gZY18iRCwpIXv5uhkkohskYITmb/Y98Q6kuVK6W2iOPMmIrsoA NW1IiwFJR03o3yrmCsNfnHc2Ol/GIKohxixZNMNRcKjw+qoCZBE= =Gx2z -----END PGP SIGNATURE----- --Apple-Mail=_1E6E3CDE-BA96-4025-B3C0-3174F5AC4B6A-- From nobody Wed Nov 22 03:44: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 166EA12940B for ; Wed, 22 Nov 2017 03:44:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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 (2048-bit key) header.d=mnot.net header.b=cWvrVLBt; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=k2iWMDyR Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QkIX2USzM9ot for ; Wed, 22 Nov 2017 03:44:14 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C11812762F for ; Wed, 22 Nov 2017 03:44:13 -0800 (PST) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 4A99520782; Wed, 22 Nov 2017 06:44:13 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Wed, 22 Nov 2017 06:44:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=hLA9YE0mh+S1pvnXOneYiHcQADV5v O1wJj5Wvcvayos=; b=cWvrVLBtzCpPtrOTw6fFEiXtvixMgWTgt4br290wvWYEF tEbpItH7vh8mRv/s/YyuMgJ/SQyXw2sCZADA8m8qZwESXS6MhRQ6L4g/ufwjk1zM RNQIVCbLWuyOEtmc9VAUcz/dK5g9ptLOHC581OQS/aUdG8M+5YJQ6mJD5l8f1jUG 38IpF0tK9LAYQdksiPIGeWZDpO73jY4q1DiLC5HZBdPmS+ARCeDkUBjYBT53xB6g H2r3IP6a3Z6bwS+iLtKpER2dCKWq3OajRcz3yp0tfYyDEvUNVEYOFuWsi8GmsLJy 9qEt9lYsRtBT7YXmvbGjzCj/fsZnrBPLKyysM8jNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=hLA9YE 0mh+S1pvnXOneYiHcQADV5vO1wJj5Wvcvayos=; b=k2iWMDyRS8jDHYMvWrXoIY hE5CuNkt/7W9tMb2nmp4q9orDWOcgE4qyCQ1jpRTTLye21fUhA7zBW0kF/e4M3V+ LU8TXC3Jj/iv3oWW6dnSpEawzLyWnFQPSbKv159PKUyRT0r/lcp+5RbcDGf2jt2Q S79kMxhRpsuVPEeKOIy1dVFcGPNMNaPAirKzLr2+19YORJtMrl+u4xrOM1e7XdIK /AbCrrsAYSnuXPWeoD1nzKgNzZ+cV7lHWrSYQljmYnNNebVfihjNLnKKKkLdbUBr BWq5bBbRY4EuB57wRUebtSSAGAmQACZT11pagelJmUiL+VR3lbwwVdJs7o14QKlQ == X-ME-Sender: Received: from [192.168.1.14] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id BE8D6244E7; Wed, 22 Nov 2017 06:44:11 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.1 \(3445.4.7\)) Subject: Re: Spin bit discussion - where we're at From: Mark Nottingham In-Reply-To: Date: Wed, 22 Nov 2017 22:44:08 +1100 Cc: Brian Trammell , Stephen Farrell , QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> To: Lars Eggert X-Mailer: Apple Mail (2.3445.4.7) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 11:44:17 -0000 > On 22 Nov 2017, at 10:27 pm, Eggert, Lars wrote: >=20 > Hi, >=20 > Mark is asleep (I hope), so below is my personal view. Not asleep, but close. Personal views likewise. > On 2017-11-22, at 11:58, Brian Trammell (IETF) = wrote: >>> On 22 Nov 2017, at 11:35, Eggert, Lars wrote: >>=20 >>> For proposals other than the Spin Bit (I think I have seen = individual contributors at least mention "loss" and "congestion" bits, = but without much detail), we wanted to clarify that we'd like to see an = analysis and discussion of their privacy aspects to roughly the same = degree as the DT has performed for the Spin Bit proposal. >>=20 >> Ok. A couple of process questions remain open here, then: >>=20 >> (1) can the chairs articulate why, before the finalization of v1, = they are proposing to go to a method of working that is somewhat more = heavyweight than the issues-and-PRs-plus-ML that enhancements or change = requests to the protocol to date have required? >=20 > The discussion leading up to and around the Spin Bit has demonstrated = that proposals that affect the cleartext part of the wire image are = incredibly controversial, and take the WG a lot of time to chew through. = The Spin Bit alone took six months and a DT, and it's arguably amongst = the most simple proposals one could make in this space. +1. Brian, I would remind you that the DT did *not* gain consensus on = doing the spin bit. This is (still) a contentious issue. > We're trying to find a way to have future discussions on such = proposals in an efficient manner, in a way that minimizes further delays = to our main deliverables (the base drafts). Exactly. Brian, please don't view this as a series of hoops to jump = through; we are trying to find you (and other proponents) a path that is = productive. Since you asked earlier: I see item 5 as an extension of item 3. Since = the spin bit is disconnected from the application payload, it might be = used -- both by endpoints and networks -- for other purposes, thereby = creating incentives that reduce its value and/or have unfortunate side = effects. If this happens, it might not remain fit for purpose (and I've = heard a few people expressing concern about this). An exploration of = this area -- by whoever chooses to do so -- would help address those = concerns. Not "required", just something we think would be helpful to = have. > Part of this is that such proposals should be contributed to the WG in = a way that lets other contributors understand the rational, design, and = implications of the proposal, i.e., a somewhat longer and more = structured format than we'd usually see for GitHub issues and PRs. >=20 > So yes, we're asking the proponents of new schemes that affect the = wire image to do a bit more work and produce a more comprehensive = proposal, compared to what we get in GitHub. But the hope is that this = will reduce the effort the WG needs to spend overall on understanding = and discussing such proposals, i.e., we hope for a net win. >=20 > For the Spin Bit specifically, most of the things that Mark listed = exist in one way or another, it'll be mostly a short exercise in = assembling that material? >=20 >> (2) to what proposals, specifically, does this heavyweight process = apply? the spin bit and measurement proposals articulated to date? = proposals impacting the measurability of the protocol? proposals = impacting specific unencrypted bits in headers? all proposals impacting = the wire image of the protocol? >=20 > My personal view is that I'd like to see this for proposals that = affect the cleartext wire format in ways that may affect user privacy. = For example, renumbering the packet types is probably not a change we = need to be overly concerned with. (I realize this is not a clear-cut = definition.) Agreed. If data is being added to the cleartext, we'll likely need to = examine it in a similar way. OK, *now* I'm going to sleep. -- Mark Nottingham https://www.mnot.net/ From nobody Wed Nov 22 03:49: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 25DC4128DF3 for ; Wed, 22 Nov 2017 03:49:51 -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 eXOwW7qxnmW5 for ; Wed, 22 Nov 2017 03:49:48 -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 4BB5A12426E for ; Wed, 22 Nov 2017 03:49:48 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id D05DD340D55; Wed, 22 Nov 2017 12:49:46 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.19915); Wed, 22 Nov 2017 12:49:46 +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; Wed, 22 Nov 2017 12:49:46 +0100 (CET) Received: from vpn-global-dhcp2-174.ethz.ch (account ietf@trammell.ch [129.132.209.174] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 36851780; Wed, 22 Nov 2017 12:49:46 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_AF517362-9F1C-42C2-8C81-C5A668940DE2"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Spin bit discussion - where we're at Date: Wed, 22 Nov 2017 12:49:45 +0100 In-Reply-To: Cc: Stephen Farrell , Mark Nottingham , QUIC WG To: "Eggert, Lars" References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 11:49:51 -0000 --Apple-Mail=_AF517362-9F1C-42C2-8C81-C5A668940DE2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Lars, Comments inline. > On 22 Nov 2017, at 12:27, Eggert, Lars wrote: >=20 > Hi, >=20 > Mark is asleep (I hope), so below is my personal view. >=20 > On 2017-11-22, at 11:58, Brian Trammell (IETF) = wrote: >>> On 22 Nov 2017, at 11:35, Eggert, Lars wrote: >>=20 >>> For proposals other than the Spin Bit (I think I have seen = individual contributors at least mention "loss" and "congestion" bits, = but without much detail), we wanted to clarify that we'd like to see an = analysis and discussion of their privacy aspects to roughly the same = degree as the DT has performed for the Spin Bit proposal. >>=20 >> Ok. A couple of process questions remain open here, then: >>=20 >> (1) can the chairs articulate why, before the finalization of v1, = they are proposing to go to a method of working that is somewhat more = heavyweight than the issues-and-PRs-plus-ML that enhancements or change = requests to the protocol to date have required? >=20 > The discussion leading up to and around the Spin Bit has demonstrated = that proposals that affect the cleartext part of the wire image are = incredibly controversial, and take the WG a lot of time to chew through. (...again, it seems to me that the discussion converged in Singapore, so = I'm a little perplexed as to why we're still having this conversation, = especially given a explicit statement from the chairs that consensus may = necessarily be rougher as we work to meet milestones in a timely manner, = but if I'm the only one who believed that we were done, I'm willing to = be declared in the rough here.) > The Spin Bit alone took six months and a DT, and it's arguably amongst = the most simple proposals one could make in this space. Indeed, it was specifically designed to be the simplest possible = proposal in this space. And if my read of this thread is correct, that = the chairs believe there is no consensus to add the spin bit, and that a = proposal to add the spin bit will be considered at IETF 101, it'll end = up taking basically a year. PR 609 was submitted in Paris, but the = discussion about explicit measurability predates it a bit. > We're trying to find a way to have future discussions on such = proposals in an efficient manner, in a way that minimizes further delays = to our main deliverables (the base drafts). >=20 > Part of this is that such proposals should be contributed to the WG in = a way that lets other contributors understand the rational, design, and = implications of the proposal, i.e., a somewhat longer and more = structured format than we'd usually see for GitHub issues and PRs. Ok, this makes sense to me. > So yes, we're asking the proponents of new schemes that affect the = wire image to do a bit more work and produce a more comprehensive = proposal, compared to what we get in GitHub. But the hope is that this = will reduce the effort the WG needs to spend overall on understanding = and discussing such proposals, i.e., we hope for a net win. This net win comes from shifting the effort to the proposers, which = still has uncomfortable proof-of-work optics, but I see your point. > For the Spin Bit specifically, most of the things that Mark listed = exist in one way or another, it'll be mostly a short exercise in = assembling that material? Everything except point 5 we basically already have in some form or = another, and point 5 does not really seem worth spending effort on if = the point is to come to a technical decision about this proposal. >> (2) to what proposals, specifically, does this heavyweight process = apply? the spin bit and measurement proposals articulated to date? = proposals impacting the measurability of the protocol? proposals = impacting specific unencrypted bits in headers? all proposals impacting = the wire image of the protocol? >=20 > My personal view is that I'd like to see this for proposals that = affect the cleartext wire format in ways that may affect user privacy. = For example, renumbering the packet types is probably not a change we = need to be overly concerned with. (I realize this is not a clear-cut = definition.) I think I agree that this is the right aim. But if "affect the cleartext = wire format in ways that may affect user privacy" is the criterion, then = I would submit that the one thing the DT came to conclusion on is that = the spin bit has negligible impact on user privacy, and as such would = not be subject thereto. So the criterion is probably something = different... let me propose "changes the information content of the wire = image". Thanks, cheers, Brian --Apple-Mail=_AF517362-9F1C-42C2-8C81-C5A668940DE2 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloVZFkACgkQihK3vwvq RqPoFRAAtSuVQ13r0RdqMYIS8OyFWraNmcwVY/b6GJlImpPgVGKgw6/hWIit13TL 8ZDZYHOgriGkYRqbgNB82pRwrTJwZBwx0mQAtz77IAtnBEA5Vk+6l3/eLnstKaNr OeVakA8kg2slfkkdOF3PZJ7mevc1B8x/WBuqNwxRHAgZr8YOjWNJu6INW56cP+LS KukPeBE2bLtggo5Us3bQRLQx2OiEREIcRQV7DsX6lpwxtq5GVg+5s2pJKePQjKm3 03QtOLlXJkhkkI/sTRos8NGlZmLzWwlanhI1Qy+C05KwG2p7KGreoTapgvoy3pG3 nU/udCOMJi5f6T8L0miqT6o86cKTQn6+lUHlRB/hBocIc+OY++K3lY5vQ5fqr0Ej SmranRN0olf7VCHPGumhn0HI4PUXjmAEkjLr4uEhxnKIQa7z1HYih4en4gInbmip knC36hpu7f8KoqO2voMwCRNbaFPa3nS/fYc8sKrvZc18FJ9Qb0Cf5T1/uYDfuIPp egWrgshi87YqQRUlJuoyw9OqSVsMzSIj8tdKFGfGAUgMwvQMUqf073dk8rzE+SoP j60jtpE7BNbE2wPwRiFc1X4i2UklsjvJmQDddgjB8IrJJK5ZLR/u4Awmab03J1Yz rShrOPrsAU4fTRQ+MGhX64yJSVBPvUt3vT6FiHP5mcfDaOl8BsE= =tXjk -----END PGP SIGNATURE----- --Apple-Mail=_AF517362-9F1C-42C2-8C81-C5A668940DE2-- From nobody Wed Nov 22 04:04: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 4D9CB12941C for ; Wed, 22 Nov 2017 04:03:59 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id url-PxUq4hM3 for ; Wed, 22 Nov 2017 04:03:53 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB2BB12940C for ; Wed, 22 Nov 2017 04:03:52 -0800 (PST) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 599454ACE2AD8 for ; Wed, 22 Nov 2017 12:03:49 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 22 Nov 2017 12:03:51 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.96]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Wed, 22 Nov 2017 20:03:47 +0800 From: Roni Even To: Mark Nottingham , Lars Eggert CC: Brian Trammell , QUIC WG , "Stephen Farrell" Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY4dBH8QAeH+8rEa8d6ohEvFvpKMgSxgw Date: Wed, 22 Nov 2017 12:03:47 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD846111@DGGEMM506-MBX.china.huawei.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net> In-Reply-To: <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 12:03:59 -0000 >=20 > Since you asked earlier: I see item 5 as an extension of item 3. Since th= e spin > bit is disconnected from the application payload, it might be used -- bot= h by > endpoints and networks -- for other purposes, thereby creating incentives > that reduce its value and/or have unfortunate side effects. If this happe= ns, it > might not remain fit for purpose (and I've heard a few people expressing > concern about this). An exploration of this area -- by whoever chooses to= do > so -- would help address those concerns. Not "required", just something w= e > think would be helpful to have. [Roni Even] This concern can be applied to other fields in the clear part o= f the header. For example the connection id in a peer to peer case. Even in= client server an application with a co-operating server can use this long = field to whatever they want and it will not break the protocol. We expect t= hat people will comply with protocol specification but we cannot prevent t= hem from creating non-compliant usages. >=20 >=20 > > Part of this is that such proposals should be contributed to the WG in = a way > that lets other contributors understand the rational, design, and implica= tions > of the proposal, i.e., a somewhat longer and more structured format than > we'd usually see for GitHub issues and PRs. > > > > So yes, we're asking the proponents of new schemes that affect the wire > image to do a bit more work and produce a more comprehensive proposal, > compared to what we get in GitHub. But the hope is that this will reduce = the > effort the WG needs to spend overall on understanding and discussing such > proposals, i.e., we hope for a net win. > > > > For the Spin Bit specifically, most of the things that Mark listed exis= t in one > way or another, it'll be mostly a short exercise in assembling that mater= ial? > > > >> (2) to what proposals, specifically, does this heavyweight process app= ly? > the spin bit and measurement proposals articulated to date? proposals > impacting the measurability of the protocol? proposals impacting specific > unencrypted bits in headers? all proposals impacting the wire image of th= e > protocol? > > > > My personal view is that I'd like to see this for proposals that affect= the > cleartext wire format in ways that may affect user privacy. For example, > renumbering the packet types is probably not a change we need to be overl= y > concerned with. (I realize this is not a clear-cut definition.) >=20 > Agreed. If data is being added to the cleartext, we'll likely need to exa= mine it > in a similar way. >=20 > OK, *now* I'm going to sleep. >=20 >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Wed Nov 22 04:07: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 B35C912940C for ; Wed, 22 Nov 2017 04:07:20 -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 gsvwGo_hsK1W for ; Wed, 22 Nov 2017 04:07:18 -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 44012129400 for ; Wed, 22 Nov 2017 04:07:18 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DFB52340EBC; Wed, 22 Nov 2017 13:07:16 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.25120); Wed, 22 Nov 2017 13:07:14 +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; Wed, 22 Nov 2017 13:07:14 +0100 (CET) Received: from vpn-global-dhcp2-174.ethz.ch (account ietf@trammell.ch [129.132.209.174] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 36853810; Wed, 22 Nov 2017 13:07:14 +0100 From: "Brian Trammell (IETF)" Message-Id: <918BF809-338D-4FE9-A7B8-887E532C7FA8@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_3FDC49D0-4C4C-4E02-A7AC-2C7E7DC150E8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Spin bit discussion - where we're at Date: Wed, 22 Nov 2017 13:07:13 +0100 In-Reply-To: <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net> Cc: Lars Eggert , QUIC WG , Stephen Farrell To: Mark Nottingham References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 12:07:20 -0000 --Apple-Mail=_3FDC49D0-4C4C-4E02-A7AC-2C7E7DC150E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 hi Mark, > On 22 Nov 2017, at 12:44, Mark Nottingham wrote: >=20 >> On 22 Nov 2017, at 10:27 pm, Eggert, Lars wrote: >>=20 >> Hi, >>=20 >> Mark is asleep (I hope), so below is my personal view. >=20 > Not asleep, but close. Personal views likewise. >=20 >> On 2017-11-22, at 11:58, Brian Trammell (IETF) = wrote: >>>> On 22 Nov 2017, at 11:35, Eggert, Lars wrote: >>>=20 >>>> For proposals other than the Spin Bit (I think I have seen = individual contributors at least mention "loss" and "congestion" bits, = but without much detail), we wanted to clarify that we'd like to see an = analysis and discussion of their privacy aspects to roughly the same = degree as the DT has performed for the Spin Bit proposal. >>>=20 >>> Ok. A couple of process questions remain open here, then: >>>=20 >>> (1) can the chairs articulate why, before the finalization of v1, = they are proposing to go to a method of working that is somewhat more = heavyweight than the issues-and-PRs-plus-ML that enhancements or change = requests to the protocol to date have required? >>=20 >> The discussion leading up to and around the Spin Bit has demonstrated = that proposals that affect the cleartext part of the wire image are = incredibly controversial, and take the WG a lot of time to chew through. = The Spin Bit alone took six months and a DT, and it's arguably amongst = the most simple proposals one could make in this space. >=20 > +1. Brian, I would remind you that the DT did *not* gain consensus on = doing the spin bit. This is (still) a contentious issue. The DT did not, but the WG discussed it after the DT report. I'll take = your statement here as an indication that the rough consensus I thought = I saw for the spin bit as harmless and useful in Singapore and on the = list afterward is not an impression shared by the chairs and the rest of = the WG. >> We're trying to find a way to have future discussions on such = proposals in an efficient manner, in a way that minimizes further delays = to our main deliverables (the base drafts). >=20 > Exactly. Brian, please don't view this as a series of hoops to jump = through; we are trying to find you (and other proponents) a path that is = productive. Okay. I'm trying not to, but it seems to me to be difficult to avoid the = perception of a series of hoops to jump through when an enumeration of = work items is laid out under the signature of a WG chair speaking as = such, especially when much of the information is available, albeit in a = less organized form. (in re productive: at this point I've spent my time budget on this for = the day on this thread, which is basically my fault, but I think I have = a much clearer picture of the state of things, so thank you for that.) > Since you asked earlier: I see item 5 as an extension of item 3. Since = the spin bit is disconnected from the application payload, it might be = used -- both by endpoints and networks -- for other purposes, thereby = creating incentives that reduce its value and/or have unfortunate side = effects. If this happens, it might not remain fit for purpose (and I've = heard a few people expressing concern about this). An exploration of = this area -- by whoever chooses to do so -- would help address those = concerns. Not "required", just something we think would be helpful to = have. Okay. I'm not saying it wouldn't be interesting, I'm saying it won't be = a useful input to the WG's decision. I won't spend any time on it, = except what naturally comes out of point 3, and I'll hope that's enough = for the WG to decide. >> Part of this is that such proposals should be contributed to the WG = in a way that lets other contributors understand the rational, design, = and implications of the proposal, i.e., a somewhat longer and more = structured format than we'd usually see for GitHub issues and PRs. >>=20 >> So yes, we're asking the proponents of new schemes that affect the = wire image to do a bit more work and produce a more comprehensive = proposal, compared to what we get in GitHub. But the hope is that this = will reduce the effort the WG needs to spend overall on understanding = and discussing such proposals, i.e., we hope for a net win. >>=20 >> For the Spin Bit specifically, most of the things that Mark listed = exist in one way or another, it'll be mostly a short exercise in = assembling that material? >>=20 >>> (2) to what proposals, specifically, does this heavyweight process = apply? the spin bit and measurement proposals articulated to date? = proposals impacting the measurability of the protocol? proposals = impacting specific unencrypted bits in headers? all proposals impacting = the wire image of the protocol? >>=20 >> My personal view is that I'd like to see this for proposals that = affect the cleartext wire format in ways that may affect user privacy. = For example, renumbering the packet types is probably not a change we = need to be overly concerned with. (I realize this is not a clear-cut = definition.) >=20 > Agreed. If data is being added to the cleartext, we'll likely need to = examine it in a similar way. s/data/information content/ but yeah, the boundary here is looking = pretty clear, and quite useful to ensure this process is not applied in = an arbitrary way. 'Night. I'm off to enjoy the last nice day in Z=C3=BCrich. Thanks, cheers, Brian --Apple-Mail=_3FDC49D0-4C4C-4E02-A7AC-2C7E7DC150E8 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----- iQIyBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloVaHEACgkQihK3vwvq RqM89Q/45MKDmP8mVyeD9rq/4eWSCxSl3bm7H0k5uGTKfvajoAH+plcbEE0vkoUs DqYWxFkJXhLai3ImF6U2rbI7fs++aWsLupBzmLGIDGCjUMtvGiuk7rIiVQnuouj+ yN5YsNCNvhE2drJyIhgUhXIZAelTWQQo00XMgpINLTtVqz20jpM/HFj42ohJBY8e RQ7FaeMY1TGe5Z+YfrsANR0SQsV4deegWg2KR60f5IJoB7eg0LvLljLiE70djJmI OoWjZnFqvtW8z1+sJfDbAP8bkwM0aEK6RHvG28gQOh2Wa+7eWcKdmxjPteCtwHz+ AftwAp8hj6iGbUGYwLEZzcDorbomNv5d49XUA+tpWXGEx1BP/QxALRWJiNUIVbkW iWlR+i/XPSGMCCYYaZQBsuymThi6ysvGY9HFXR9tV5R04WTvR/LKGyxlV8A9NAUn pCrrjD+Wd5ZkAPMdivJrJaYwjM8aKQ5BD/baHcN5hkkhYnjFDokZWPc+xrMlsNy9 XZd/nhiHov49j4qVBeq0g6O6p6S4825D+a5BfrmxncyBpXuhzxufcVWzo+9Ih7bK uM1C8ScjUo8uihg3SWQdqiVLOz3Smu/h6/Yli1QsKEs2yHAGM5s0jhCFtQia6byw HAkk2p+PkgTAomOguxkwslYevX1CoAFRKzxzIL41whMdQ7DWqw== =cJTy -----END PGP SIGNATURE----- --Apple-Mail=_3FDC49D0-4C4C-4E02-A7AC-2C7E7DC150E8-- From nobody Wed Nov 22 04:15: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 F0E0C12940B for ; Wed, 22 Nov 2017 04:15:43 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LDoQnUz7j5k for ; Wed, 22 Nov 2017 04:15:41 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5CED8129400 for ; Wed, 22 Nov 2017 04:15:41 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id F197E2C1024F0 for ; Wed, 22 Nov 2017 12:15:37 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 22 Nov 2017 12:15:39 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.96]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Wed, 22 Nov 2017 20:15:12 +0800 From: Roni Even To: "Brian Trammell (IETF)" , Mark Nottingham CC: QUIC WG , Lars Eggert Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jlrhBw4LAfNECHCO5hAXawWKMfl8kAgAC1W/A= Date: Wed, 22 Nov 2017 12:15:12 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> In-Reply-To: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 12:15:44 -0000 Hi , I was surprised to read the chairs email and agree with Brian's comments. My impression is that the email reflects a view that manageability is not i= mportant (and not blocking) and this is the reason for not doing the spin b= it based on issue 609 as a PR. My product development experience is that lack of tools to manage and maint= ain a product will prevent its distribution. I understand that the develope= r of the protocol care only about the protocol and not about making it eas= y to support in the field. Yet the network product manufacturers and the se= rvice providers gave a clear message that RTT is crucial for deployment. = I provided use cases from TCP in service providers networks in https://tool= s.ietf.org/id/draft-even-quic-troubleshooting-video-delivery-00.txt=20 I expect that the WG chair and AD will treat protocol maintenance and manag= ement the same as the protocol itself. What emphasis my point is the effort= the WG does on https://tools.ietf.org/html/draft-ietf-quic-manageability-0= 1=20 Roni Even=20 > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell > (IETF) > Sent: =E9=E5=ED=A0=E3 22 =F0=E5=E1=EE=E1=F8 2017 11:15 > To: Mark Nottingham > Cc: QUIC WG; Lars Eggert > Subject: Re: Spin bit discussion - where we're at >=20 > hi Mark, all, >=20 > While I disagree with the chairs as to the state of consensus on this iss= ue, I'm > going to go ahead and (perhaps predictably) throw my name in the hat for > this one, since we're actively working on it anyway. >=20 > I have a few questions and comments on the content of the work program > requested, below: >=20 > > On 22 Nov 2017, at 09:06, Mark Nottingham wrote: >=20 > >=20 > > There are a number of things that we think will help clarify the value > provided by the Spin Bit: > > > > 1) A description of the use case(s) that motivate this proposal. We > understand that the goal is to measure RTT, but some people are still unc= lear > as to why that's necessary to operate a network. Detailed scenarios and > ideally real-world examples (e.g., from TCP) would help tremendously. > Saying "I need to debug the network" is not enough detail. >=20 > This seems reasonable, though I would appreciate some clear acceptance > criteria for the level of detail the WG would consider useful. "I need to= debug > the network" is clearly not detailed enough, but what is? >=20 > > 2) An actual protocol specification for the Spin Bit, including Privacy > Considerations. There seems to be a fairly good common understanding of i= t > (especially in the DT), but it would be helpful to have it written down, = so we > can make sure we're talking about the same thing. If it were proposed as = an > extension, current implementations (reminder: we have 12) could > implement it to see how it works on the network. Doing so would also give > the security research community something to look at (see above). >=20 > We already have this in the form of PR 609, though it needs to be rewritt= en. > I'd be happy to volunteer to carve this off into a separate I-D if that's= what > the WG wants. >=20 > The request for a privacy considerations section for a single protocol fe= ature > seems odd to me at best, and prejudicial at worst. Where is the privacy > considerations analysis for other features, for instance, various header > compression schemes? But, again, given that the work is already done (and > mostly in markdown!), dumping it into an I-D is marginal work. >=20 > > 3) Data showing that the Spin Bit is fit for purpose under real-world > conditions. Piet's experiment is a start here, but we need much more. >=20 > Piet's current work represents much more than was presented to the list > during the Singapore meeting, but some indication of how much more we > need would be useful here. Piet is producing a detailed analysis of a num= ber > of proposed measurability features (one-bit spin is done, and two-bit spi= n > and a blocking bit as once proposed by Martin Duke are on the > implementation schedule now), and we can certainly feed this into the dra= ft. >=20 > > Analysis of how well that data meets the use cases is also necessary. T= his > might form part of the Manageability Considerations of the draft. > > > > 4) A comparison of other potential solutions to measuring delay, and th= eir > relative merits. Again, ideally with detailed, real-world data. >=20 > As in 1, there's a whole lot of literature here. I'll say that we'll prob= ably > produce some numbers as part of the same evaluation above comparing the > latency spin bit to handshake RTT measurement (presuming that the > handshake remains visible enough to measure) and to "find some TCP in > your aggregate and compute latency based on that" (which reduces to "forc= e > 1/k QUIC flows to TCP in order to get enough TCP in your aggregate to > compute latency" in a mostly-QUIC world, yay fallback!). >=20 > > 5) An exploration of what the effects of deploying the spin bit are lik= ely to > be. E.g.: Will even the perception of privacy issues change endpoint > behaviour? Will networks treat traffic differently based upon the spin bi= t? If > so, can that be gamed? Will firewalls and other gateways police spin bit > behaviour (e.g., to prevent data loss), and what effects will that have? >=20 > I don't see how this request is useful. >=20 > Perhaps if the proposal were to add some new form of exposure not already > ubiquitously available in TCP, with which we did not have years of operat= ional > experience, this might arguably be necessary work. However, as it stands, > the exercise would certainly lead to a fascinating exploration of the > economics of modern Internet access, but given the lack of ability to run > sensible experiments to form an evidentiary basis for decision, such an > exercise would always reflect the prejudices of its authors. One could wr= ite > an essay for 5 that will reasonably support any view one cares to have he= re, > which yields it useless for helping us to make a decision. >=20 > > We're looking for volunteers to start drafting one or more documents al= ong > these lines. If you're interested, please indicate this on-list, so you c= an > coordinate with other interested parties. They won't (yet) be WG > documents, but since the DT didn't resolve the issue, we will discuss the= m in > the WG. > > > > In terms of timeline - resolving this is NOT a blocking issue; i.e., we= can > discuss this concurrently with other work on the protocol, and because it= 's > such a small change in the packet layout, we can add it right before ship= ping > the protocol to the IESG. >=20 > I will note that any bits we designate to measurement will rapidly become > part of QUIC's invariants, whether we intend them to or not, so the detai= ls of > any design we choose will have to be carefully considered. However, that > probably does not imply that those bits (their number and position) need = to > be proactively added to the invariants currently under discussion. So I a= gree > with your assessment that we can tip this into the short header relativel= y late > in the game. >=20 > Cheers, >=20 > Brian >=20 > > In light of that, we will NOT discuss this (or related) issues at the M= elbourne > interim. That will allow the people attending to focus on continued proto= col > development, and means that people don't feel the need to travel to discu= ss > just this issue. We would like to be able to move the discussion forward = at > IETF101 in London, provided that significant progress is made on the item= s > above. > > > > Cheers, > > > > > > Your Chairs, Mark and Lars > > From nobody Wed Nov 22 04:17: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 10D3B129417 for ; Wed, 22 Nov 2017 04:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhcBr5aA93DV for ; Wed, 22 Nov 2017 04:16:58 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC02D129400 for ; Wed, 22 Nov 2017 04:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2959; q=dns/txt; s=iport; t=1511353017; x=1512562617; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=Vy7QlbfRBO+MtcYXAtUCqFiwbrXMN+wCOirRy/FikAQ=; b=GCI5NxvtGhAvjkYQyrrkSNVaihfrgrwj5P08i4SSkRtJgZsUfZU+izpQ qI/E3OG7jwvUGmEHpYa8yjV+JV5equK97xmzXPf56ZNujtxVcop98ZjNP SeRUIShqZXvNF4Zen9v92y5xHuUJn/YaNTqiF6dCckmwBvR2F4gPOYRp2 Q=; X-Files: signature.asc : 481 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQD9aBVa/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMOggKEJosTkB6YdgcDhTsChVoVAQEBAQEBAQEBayiFHwEFI1Y?= =?us-ascii?q?QCxgqAgJXBgEMCAEBih6oR4InincBAQEBAQEBAQEBAQEBAQEBAQERD4M6hW6DA?= =?us-ascii?q?ogwgmMFokCESYIojhuMBIdJljeBOjUjgXU0IQgdFUmCZYJbHIFoQItGAQEB?= X-IronPort-AV: E=Sophos;i="5.44,436,1505779200"; d="asc'?scan'208";a="416138" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Nov 2017 12:16:55 +0000 Received: from [10.61.246.10] ([10.61.246.10]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id vAMCGtpT012918; Wed, 22 Nov 2017 12:16:55 GMT Subject: Re: Spin bit discussion - where we're at To: "Brian Trammell (IETF)" , Mark Nottingham Cc: QUIC WG , Lars Eggert , Stephen Farrell References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net> <918BF809-338D-4FE9-A7B8-887E532C7FA8@trammell.ch> From: Eliot Lear Message-ID: Date: Wed, 22 Nov 2017 13:16:08 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <918BF809-338D-4FE9-A7B8-887E532C7FA8@trammell.ch> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SuDweM0n0okX2BkFvuL9jPS2XXUqaVa1M" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 12:16:59 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SuDweM0n0okX2BkFvuL9jPS2XXUqaVa1M Content-Type: multipart/mixed; boundary="0T49K088L2C94Kj6nlR09ORQobEbG2wLd"; protected-headers="v1" From: Eliot Lear To: "Brian Trammell (IETF)" , Mark Nottingham Cc: QUIC WG , Lars Eggert , Stephen Farrell Message-ID: Subject: Re: Spin bit discussion - where we're at References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net> <918BF809-338D-4FE9-A7B8-887E532C7FA8@trammell.ch> In-Reply-To: <918BF809-338D-4FE9-A7B8-887E532C7FA8@trammell.ch> --0T49K088L2C94Kj6nlR09ORQobEbG2wLd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hard to follow the bouncing ball here, but on these two points and elsewhere: On 11/22/17 1:07 PM, Brian Trammell (IETF) wrote: > > The DT did not, but the WG discussed it after the DT report. I'll take = your statement here as an indication that the rough consensus I thought I= saw for the spin bit as harmless and useful in Singapore and on the list= afterward is not an impression shared by the chairs and the rest of the = WG. Mark did say that he was speaking as a contributor. On the general point, general security considerations principles should apply.=C2=A0 If we know how to abuse a field, we should state the risk.=C2= =A0 So long as the benefit is articulated, at that point the E in IETF kicks in: make your design tradeoffs.=C2=A0 That's what engineers do.=C2=A0 Net= work management is often the flipside of privacy, so... > 'Night. I'm off to enjoy the last nice day in Z=C3=BCrich. Is Armageddon coming?=C2=A0 I missed the memo. Eliot --0T49K088L2C94Kj6nlR09ORQobEbG2wLd-- --SuDweM0n0okX2BkFvuL9jPS2XXUqaVa1M Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2 iQEcBAEBCAAGBQJaFWqIAAoJEIe2a0bZ0nozy+UH/jWxpy/e05jPthbT3WZ2Fs7I /kh+jQAOPGl/Zd0wekRARPjP4NAwgVlo/LZlAak/2K9y0XNqETMlZm737kqJ96Sk QvVDxdcUmP3xD+SOzSpLURjrvt404SX+7cS9B2ig2alQdr8zzMHEcu8LNQsWiI5H 5RpmbTADK4+h2JTL9St9HNHtEHCuI4u8Gq/sGKdKmH35qo3Mn/pktbK8dU383Lb6 pZW+rU8kJujlZ+Tc+4OEiXPpJJ3tMhkzny8QUY/dJ0MGS4Ay9NRnUxwdj6cR3zdT u2P1+KZtcj3b25VKJ0yh4lL9WTjtAjkmkZ1WLnePaG1BBDBbMgIZrGCiZItQYbQ= =/MaV -----END PGP SIGNATURE----- --SuDweM0n0okX2BkFvuL9jPS2XXUqaVa1M-- From nobody Wed Nov 22 04:21: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 35AAF129400 for ; Wed, 22 Nov 2017 04:21:16 -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 LJZLeFfvE3yH for ; Wed, 22 Nov 2017 04:21:14 -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 242AC120046 for ; Wed, 22 Nov 2017 04:21:14 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id AEAA23402E7; Wed, 22 Nov 2017 13:21:12 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.31216); Wed, 22 Nov 2017 13:21:10 +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; Wed, 22 Nov 2017 13:21:10 +0100 (CET) Received: from vpn-global-dhcp2-174.ethz.ch (account ietf@trammell.ch [129.132.209.174] verified) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 36855352; Wed, 22 Nov 2017 13:21:10 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_197C9583-A123-47A0-AFD2-DE0355C616E1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Spin bit discussion - where we're at Date: Wed, 22 Nov 2017 13:21:09 +0100 In-Reply-To: Cc: Mark Nottingham , QUIC WG , Lars Eggert , Stephen Farrell To: Eliot Lear References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net> <918BF809-338D-4FE9-A7B8-887E532C7FA8@trammell.ch> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 12:21:16 -0000 --Apple-Mail=_197C9583-A123-47A0-AFD2-DE0355C616E1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 22 Nov 2017, at 13:16, Eliot Lear wrote: >=20 > Hard to follow the bouncing ball here, but on these two points and > elsewhere: >=20 >=20 > On 11/22/17 1:07 PM, Brian Trammell (IETF) wrote: >>=20 >> The DT did not, but the WG discussed it after the DT report. I'll = take your statement here as an indication that the rough consensus I = thought I saw for the spin bit as harmless and useful in Singapore and = on the list afterward is not an impression shared by the chairs and the = rest of the WG. >=20 > Mark did say that he was speaking as a contributor. Ah, good point. Apologies, strike that, I won't take that as a = declaration of (non)consensus then. > On the general point, general security considerations principles = should > apply. If we know how to abuse a field, we should state the risk. So > long as the benefit is articulated, at that point the E in IETF kicks > in: make your design tradeoffs. That's what engineers do. Network > management is often the flipside of privacy, so... >=20 >> 'Night. I'm off to enjoy the last nice day in Z=C3=BCrich. >=20 > Is Armageddon coming? I missed the memo. It's twelve degrees and the sun is shining. in November! GO OUTSIDE! he = yells to himself... cheers, B --Apple-Mail=_197C9583-A123-47A0-AFD2-DE0355C616E1 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloVa7UACgkQihK3vwvq RqNI2Q//TdaIxq+P9NHuUocYYicN39M7hwgeQUwWCueKN9wa7jyZfIfCaC+cFHdK tPHX5RFCI1y1UxDoQPFFl/XI+uCXHXxtekp9rU+C0F9ucmZhBOgZiztwQkgGjqAM 2mdjOg0Sz7JIIkaSHnit1nH7Iu+RrlO56BoUxoHIdduhwfU9zoAv8Wi0j8BV8VHz qb4Pucej6TWlTemG8kxljCDiF5Y4QIzn3010vcSd5FZQiSb64vIjSsdhyO4TWVeo iHYgcUzYpwzFrM+RS/cyRY/GkTjYpOCBoQgpti/KQhBhP5L2tHW5iz28jV6R6TKn 04MPJTZiYfQPGB7UElpUUFo0msFmEdGMwkg9Gi1MridYazIdxUmrAPHICaA6OuLM PdihunnJu/Xe0zHAvBmvt8grzxNwmHlIDdEDXEe7dHhp1LAtI2M+WOZqfYQot5HI q1Nr830tnG+4XFN4By/w0fmA8xyGS1obwVE3zFYkP8f2eHKBNK9Eaqbz2+p5sukQ F3h1U5bPZ/IIjdzMSTjOuf2apim8Jr2HoLdfGEXhL0pEal7hsPSuIkWoxy7o9bho zYxU0FCwXbMJBY56LcmXJ3DifUTRdWZXsfBQQd7bgKOiwN8R0Hfqs8iM5PFy8vBI 6izHzCZu/D6Kn1r9aOZ/s5qxGp17DCP60zjIN2ByfQNcgnkUusg= =5sqi -----END PGP SIGNATURE----- --Apple-Mail=_197C9583-A123-47A0-AFD2-DE0355C616E1-- From nobody Wed Nov 22 04:35: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 E7360129439 for ; Wed, 22 Nov 2017 04:35:27 -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 (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 hhPwEZEPnS7q for ; Wed, 22 Nov 2017 04:35:26 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [IPv6:2620:10a:4005:8000:2306::c]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCB3129438 for ; Wed, 22 Nov 2017 04:35:26 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,436,1505804400"; d="asc'?scan'208";a="229339924" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx143-out.netapp.com with ESMTP; 22 Nov 2017 04:35:25 -0800 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 22 Nov 2017 04:35:24 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 22 Nov 2017 04:35:25 -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=w2CMJeMU1XmDle7oVqDoCrGp7pZruVLL/idzuxwZA5U=; b=dfqIduQiu+yp2apDY/X/q5cs6ha53ksoNyR2sDCLRsi/VOgqXCK630WHqVmaZDUYqVzM+BIlKDLisO3GN+oP8WE8+ASF690pI7EE7YS49JRbhBI9QSGD/+n8V3i1iTJtt63n9iPCyOlhxeEeiU1BSxqfdhe+aon7YnrK/XWag7M= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 22 Nov 2017 12:35:24 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.004; Wed, 22 Nov 2017 12:35:23 +0000 From: "Eggert, Lars" To: Roni Even CC: Brian Trammell , Mark Nottingham , "QUIC WG" Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAAyYACAAAWjAA== Date: Wed, 22 Nov 2017 12:35:23 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:eoqUm0HixP2e1eKW7u/56WIPSrlI/n/S0bn0JauzbirtRkEQrvdGN8jw5rWxTXtf+TC0ZZytlacn839t8jcqt56RBMwTqAcbsHdgX7C/tnZGlUfgnCDz+P0mD7Et0Nz9FQVElesLV4fBmZ6GJPocPvJtbkzaMdTZkoeVS9nz+zkhuwq4E2XXQgBevrlZOV8L3CAXErIoB/xyZ5CSNDTruy6tQj6VRkr4UAQEc7DEqSmbtAb2qqNDssI5cbKdvgdHh5ujLjsZKmiixSV7d9nVbwjqecrQ0r5g/la0gKqTzK8X79L4elK2rT+hYXDvd3UUR75OnMlC/d19ircprXzfwTubf2fhhxaUFya3aG/xnP4=; 5:I0BqW8A6XiUtObtij8YoyNE7xrSwKS9O80cGgIPqtXitxE37B7azmgg42kh4vB/xelBIs9l+44/r6WfLN18skgvaRb8+XXY+tN5iJlvG5nQb5ttscvqwX9YxsXGklVMaY7ok2zW20IVZiWlRxytiCl/57y+jY8cx6hKVLJjBLo8=; 24:GiXA7MwFd+T4y5oBbWp9QNMkP2kZXCv9PF05wZsXy3Htd99gxNz7jqUkJG7+PxxgajQcnhcIbIOQTI7L7o00RGUHHbhpOKfaFbEv8Mq1BUQ=; 7:E+TF4ZSb7XZI9ab1N+vBloqZPyWKvg6Yjq6f4fO6QsoPSVCCAW+NgnR/3ggePkEG8YrEaxtr5f/dHAIjFQnjrdEEoEooz7eAdAckFin827XXxYFrSwwVk/PlOK9K4aVNYkkkABMSEDgIm9NHSHCYi5q7EBq7UAJbmmfs7wYArov7CwwcPp+G8OktrcDKF597i8TrW9Rcio/Vbf61kJUyVS/bJ/2HMJY8uqoJ2QLrXn7IW2DNd+NBQijN9XXTFi5E x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: c4f9ec3d-8f2c-489a-bf8f-08d531a58097 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600022)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258)(49563074); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(3231022)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123564025)(20161123560025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1764; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(377424004)(24454002)(189002)(3280700002)(99936001)(6506006)(229853002)(478600001)(2906002)(99286004)(68736007)(33656002)(4001150100001)(6916009)(2950100002)(8936002)(50986999)(966005)(6436002)(6486002)(77096006)(76176999)(25786009)(3846002)(83716003)(102836003)(6116002)(53936002)(305945005)(316002)(106356001)(6246003)(8676002)(7736002)(50226002)(4326008)(86362001)(3660700001)(66066001)(82746002)(6306002)(36756003)(54906003)(97736004)(2900100001)(53546010)(189998001)(81166006)(6512007)(561944003)(5660300001)(14454004)(57306001)(101416001)(105586002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1764.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=_223976A5-7A66-43F9-9F47-6C90D88D995E"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c4f9ec3d-8f2c-489a-bf8f-08d531a58097 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 12:35:23.8805 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 12:35:28 -0000 --Apple-Mail=_223976A5-7A66-43F9-9F47-6C90D88D995E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Roni, On 2017-11-22, at 13:15, Roni Even wrote: > I was surprised to read the chairs email and agree with Brian's = comments. > My impression is that the email reflects a view that manageability is = not important (and not blocking) and this is the reason for not doing = the spin bit based on issue 609 as a PR. there hasn't been a consensus call on the Spin Bit proposal. = Contributors have expressed their views on the results presented by the = DT on the list, as requested by the chairs in the session in Singapore. = But that is not the same as a consensus call, and I apologize if it was = misunderstood as one. In order to hold an informed consensus call on the Spin Bit in the = future, we're asking for a more comprehensive writeup (as detailed in = the original email.) As I've said before, I think the material for that = already exists in some form or other, but it's currently in several = places, not all of which may be public (e.g., the DT mailing list.) For *other* proposals that intend to address manageability by adding = information to the cleartext wire image, we're asking for a similarly = comprehensive description, so that the WG can begin discussing a = concrete contribution. > My product development experience is that lack of tools to manage and = maintain a product will prevent its distribution. I understand that the = developer of the protocol care only about the protocol and not about = making it easy to support in the field. Yet the network product = manufacturers and the service providers gave a clear message that RTT = is crucial for deployment. I provided use cases from TCP in service = providers networks in = https://tools.ietf.org/id/draft-even-quic-troubleshooting-video-delivery-0= 0.txt > I expect that the WG chair and AD will treat protocol maintenance and = management the same as the protocol itself. What emphasis my point is = the effort the WG does on = https://tools.ietf.org/html/draft-ietf-quic-manageability-01 Lars --Apple-Mail=_223976A5-7A66-43F9-9F47-6C90D88D995E 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloVbwoACgkQVLXDCb9w wVe7fQ/8CeNpWx+CUa3aXmi6vEMpZKIDRTt71vsYgUWnP55CgB0trFFOE2CyGI5g Y5uIuYQoFgWjCnhgxq5BZ45UwoOOJGsPEO9m0t+T7xXqCvzehkIqTCiNoX0QHJjb qBPmKYHgbXbTzeelf6FRaNkZYylLLXkcx8l/omWjhNe4ZPVSXMlc4a2If0xaKZ1V ivBIN2Y8/vB7KJfANk80EmuhlzuPuDb/CY40CC8+UiMRQEcthHDPzYvsgYihf7lx xg+nBqP700OKTk6OU4OgBCy763rxp8plkhg6wjU1x1aEghkTsXyynSnxZu+LIpMC zqP2DNz7C0h6B6a1xOaKZhRiYUSP91MUyUrAL0DOBWB7dhZhgCeCQ60PIpiabT/Z CT8LqwMljd4tNMt5LogrW7ipo1PfSkvLcr+UDrlwMyQ7k0wdjZh1zNs5+eq6FrTi 2UF71RnayZrdWkzb+8fEH6qN6Joe6Jk77h6IBk1ciK0sT6k0ZPIgJu81mqeaXcuU Lv8c3HNsd7GIBzOu+kvfCHxkY3IFApnkhP+hHY7TSrvSF2qgBJraPoETyZAX93dv 25v5og2ukDBCuSLZ8WKdm+UKnKMKd2ZYVH0GUlS1Zwtmr2l5/PrzinsEtcTa2cHc b/enJoWTWDl3DTupEtTKkxAjG7i1dCDzBJrvzkVJVyVaFfXXCMg= =wzPq -----END PGP SIGNATURE----- --Apple-Mail=_223976A5-7A66-43F9-9F47-6C90D88D995E-- From nobody Wed Nov 22 04:36: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 B88671293E4 for ; Wed, 22 Nov 2017 04:36:18 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNqUeJbVEh9H for ; Wed, 22 Nov 2017 04:36:17 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 545E2126D3F for ; Wed, 22 Nov 2017 04:36:17 -0800 (PST) Received: from lhreml708-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id B34A4E1D4BC1E for ; Wed, 22 Nov 2017 12:36:12 +0000 (GMT) Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 22 Nov 2017 12:36:14 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.96]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0361.001; Wed, 22 Nov 2017 20:36:11 +0800 From: Roni Even To: "Brian Trammell (IETF)" , "Eggert, Lars" CC: Mark Nottingham , QUIC WG , Stephen Farrell Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY4gJp1VdukIM2U+G9HAjuBI8daMgUxcw Date: Wed, 22 Nov 2017 12:36:11 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD846174@DGGEMM506-MBX.china.huawei.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 12:36:19 -0000 >=20 > > The Spin Bit alone took six months and a DT, and it's arguably amongst = the > most simple proposals one could make in this space. >=20 > Indeed, it was specifically designed to be the simplest possible proposal= in > this space. And if my read of this thread is correct, that the chairs bel= ieve > there is no consensus to add the spin bit, and that a proposal to add the= spin > bit will be considered at IETF 101, it'll end up taking basically a year.= PR 609 > was submitted in Paris, but the discussion about explicit measurability > predates it a bit. >=20 [Roni Even] The process of having a DT and blocking discussion during the t= ime for the 4 month between the meeting slowed the progress. This WG trues = to work in a fast pace and I think that in Singapore and on the mailing lis= t we saw strong support from the parties who will use the spin bit to move = it fast. Waiting for London will further delay. I was planning to provide replacement text for 609 this week or no later th= an next week, defining the spin bit based on the discussions we had in Sing= apore and on the list for a new PR for the QUIC transport document. We can have in parallel a non WG document on RTT measurements using the spi= n bit even though it place may be in the QUIC manageability document. Roni Even From nobody Wed Nov 22 05:31: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 7521D129439 for ; Wed, 22 Nov 2017 05:31:49 -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 Jr514I_vv8lk for ; Wed, 22 Nov 2017 05:31:47 -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 309131200FC for ; Wed, 22 Nov 2017 05:31:47 -0800 (PST) X-AuditID: c1b4fb30-a25ff70000002554-5a-5a157c411b42 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 96.56.09556.14C751A5; Wed, 22 Nov 2017 14:31:45 +0100 (CET) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 22 Nov 2017 14:31:44 +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=ECQNL70A+hHLLka/PpUiSPFS/XehDwVNcvNJ8gfu98Q=; b=RAh7+Cnjp8ETWbU2kw7h2Vkfae3GCOgN0YFgTY9e/nDPcNH6wwKp4p6/YWLPZbbw0ams28W6p0zOgYYgzWSDaB3FXRmc3qmcR7VzxADnlmSAVSAipxTicNFeOzxfwIUL9WQPGQtwv14p20upyC+eZdgt6z4So8+1ly9nSyzLv0s= Received: from AM2PR07MB0563.eurprd07.prod.outlook.com (10.160.32.21) by AM2PR07MB0562.eurprd07.prod.outlook.com (10.160.32.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.20.239.4; Wed, 22 Nov 2017 13:31:43 +0000 Received: from AM2PR07MB0563.eurprd07.prod.outlook.com ([fe80::a8ad:67d1:587a:2f08]) by AM2PR07MB0563.eurprd07.prod.outlook.com ([fe80::a8ad:67d1:587a:2f08%15]) with mapi id 15.20.0260.004; Wed, 22 Nov 2017 13:31:43 +0000 From: Salvatore Loreto To: "Eggert, Lars" , Roni Even CC: Brian Trammell , Mark Nottingham , "QUIC WG" Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2j1n9nbkobUkkWTv+COdcSuqaMgHeUAgAAyYACAAAWkgIAACYDw Date: Wed, 22 Nov 2017 13:31:43 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.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=salvatore.loreto@ericsson.com; x-originating-ip: [192.176.1.88] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0562; 6:ibeLG+Abo6svWKB7r/r8iuYv0m5Sy8EU5nA/lPRwN2Nbus/QYYA6hipFfEleFSi6ye3TfH0flCFnEhfYu+UL8U2KoYKrP4EwFTCUEQL0pyaGjXDzCnUHqpZy/MkfdSkBy9R+Me5Qczu1tqBnEIymoaNlcJ+mGgK7sz4osNGKLtVLZeZwUSJbdil6EPHc74DK9RoODxpEmaEC4idkPcgHtHIZw+R5bPOCos+RCMN45zaS/lDat45egO+X+0qHocmb0wKmN7QbNrlqjQ3yXyiWue8J9Tx6PHQ8N2NRRr8ymacQOBWdydzi32m5xXU0Tom7v4s7e4a8Bo5jwuGd6Y5WUy8bKDvbK/yT5UsAhuCewgw=; 5:T7OLaQiSqLjJFZOn+JdPYy0SGUqoYV16w2gIsaMObEp0dFKCuRWwIAfBa0mM5KLqZP5huumRecIjnqmbN1p9/6gAasM+gFFqog8I/D2zlRj5/vnL2Rq53Yn4PagfjwfDcOKjFmm2z9fi8fCn5/uRC/OC+8AWQd8gOP1K+EHoN7A=; 24:QjNj7g3y6hl5K4CXEx5Y+gCFAi1v8pIU75X0RTcH6LeDi/w2jOye1wADCSAjC/NlvVjcn6TSCGAQnVdIOdbyk/GVKr6K0R0Hd0XNvXms9ww=; 7:fI43A9FpGOKa/SiRLBE6RZPMJnkqgnW0G2zHI4OTH17lJjlCeysBp7UmRLc3yzyvQF/yppBuWiNU6QmAEsMZ1J0o1z2VlL5pjezDqXSTCsnjboEyPp88ug9XkVix3FXM5uEN1a/kyaRPwsWVyhjjWirMnl7HqB0/pAdrUdVHK22aCVpPms8NJxH/26dA4DsXJIl/3Kuxa+bKYHg58i3s3aY7460bb9i12UgJADJ65GJwSihzUThForVx2VuGruUN x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ab9c1661-4c33-4709-befe-08d531ad5ef0 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:AM2PR07MB0562; x-ms-traffictypediagnostic: AM2PR07MB0562: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231022)(100000703101)(100105400095)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0562; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0562; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(13464003)(189002)(377424004)(199003)(24454002)(33656002)(6116002)(5660300001)(93886005)(8936002)(6436002)(6246003)(4326008)(66066001)(316002)(7736002)(53936002)(305945005)(25786009)(6306002)(3660700001)(86362001)(55016002)(7696004)(76176999)(54906003)(2900100001)(68736007)(189998001)(50986999)(105586002)(8676002)(106356001)(14454004)(2906002)(110136005)(97736004)(99286004)(81156014)(81166006)(3280700002)(966005)(54356999)(102836003)(478600001)(4001150100001)(3846002)(6506006)(5250100002)(561944003)(53546010)(101416001)(9686003)(74316002)(2950100002)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0562; H:AM2PR07MB0563.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: ab9c1661-4c33-4709-befe-08d531ad5ef0 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 13:31:43.3794 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0562 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHe/Ze9jodPC7XTmohAwuslo6MCWEJoovo4jcTRZe+qKnTNhON Poia98SJkhMv08zADFG8gV10aqgLByVBaVBuYCKumpGJl3J7FPr2O+f8z/+c8/BwlKSD8eXS tbm8TqvJlLMi2hg7HHMm4r40LrjL4K3qK3Gwqm+r1bSq12lDqmqTp8r5xkpfYtQlk2uMurNz U6Due7zBqBudv1i1/bWRvsHEiS6k8JnpebzubHiSKO2HJTGn3Te/t9nAFKJWaSXy4ACfg48W K6pEIk6CJxAYZtcZEkwjsC7tUK6Axg8pWJz6ICSVegHUVIywJLAh2GxpQC4zFp+H5a8DlIt9 cBQsjNS78xROhq6yWoGLD+MQKPqyShONEkod5eyBvtyy7e6lcSBMvJ3Z6+U4MY6HrcrrZJYD wd/vj9waDxwOz23zbh+Ej8DGbI+AzJLBJ3ubgByHofOFlSIshRXbLkP0SWCq2BGSfAA4Wiws 4WPwrq3K/RiAzUIoLh/dN1LAoGENEb4Kc4v1DBEZEfxcH2BIIQjqGpb3nTKgZnJ8f/IVmC52 CkjDPANTww7adRpgfzD0xtciRdN/ixM+DaZRJ0v4FHS1r1IuFmNvmDHaaROiu5FUz+tvZaUq lQpel56s12drFVo+tx/t/Zzxga3gEbSyHGFGmENyL3FYgTROwmjy9AVZZgQcJfcRvwzYS4lT NAX3eF12ou5uJq83Iz+OlsvEM5fFcRKcqsnlM3g+h9cdVAWch28hStBeG2uJZmIb/tCBsZEO RB3dbuWFLck3SwzdpWlZT8OYqqaeE563T86Ordvm7Enh2aGqspnPpouW1uk7xiVhUYe07wFv bg2NL8wYfB8p629K7VoOO740NMT+No0uRBn7luYPPZO9Kmq0B+7W1Ym9ErTjzTH5pRO1yif+ ftFpclqfpgkJonR6zT/kvvM/NQMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 13:31:49 -0000 Hi Lars, Mark One clarification question about the process specifically for the Spin Bit = proposal and the time frame for the consensus call While it is clear to me that a more comprehensive writeup (as detailed in t= he original email.) is a necessary condition, it is not clear if it is also a sufficient one for a consensus c= all. Indeed in the original mail Mark is on one side proposing to discuss it in = London (instead that into the next interim) but at same time is leaving open the possibility to postpone the final deci= sion until right before shipping the protocol to the IESG While I agree with Mark assessment that we can tip this into the short head= er relatively late in the game,=20 I am concerned for this huge potential delay for a proposal that I would ar= gue is already clear to all people actively involved in the QUIC design. Can you please which are the next steps you are going to follow here? Sal=20 -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: den 22 november 2017 13:35 To: Roni Even Cc: Brian Trammell ; Mark Nottingham ; QUI= C WG Subject: Re: Spin bit discussion - where we're at Hi Roni, On 2017-11-22, at 13:15, Roni Even wrote: > I was surprised to read the chairs email and agree with Brian's comments. > My impression is that the email reflects a view that manageability is not= important (and not blocking) and this is the reason for not doing the spin= bit based on issue 609 as a PR. there hasn't been a consensus call on the Spin Bit proposal. Contributors h= ave expressed their views on the results presented by the DT on the list, a= s requested by the chairs in the session in Singapore. But that is not the = same as a consensus call, and I apologize if it was misunderstood as one. In order to hold an informed consensus call on the Spin Bit in the future, = we're asking for a more comprehensive writeup (as detailed in the original = email.) As I've said before, I think the material for that already exists i= n some form or other, but it's currently in several places, not all of whic= h may be public (e.g., the DT mailing list.) For *other* proposals that intend to address manageability by adding inform= ation to the cleartext wire image, we're asking for a similarly comprehensi= ve description, so that the WG can begin discussing a concrete contribution= . > My product development experience is that lack of tools to manage and=20 > maintain a product will prevent its distribution. I understand that=20 > the developer of the protocol care only about the protocol and not=20 > about making it easy to support in the field. Yet the network product=20 > manufacturers and the service providers gave a clear message that RTT =20 > is crucial for deployment. I provided use cases from TCP in service=20 > providers networks in=20 > https://tools.ietf.org/id/draft-even-quic-troubleshooting-video-delive > ry-00.txt I expect that the WG chair and AD will treat protocol=20 > maintenance and management the same as the protocol itself. What=20 > emphasis my point is the effort the WG does on=20 > https://tools.ietf.org/html/draft-ietf-quic-manageability-01 Lars From nobody Wed Nov 22 05:55: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 7C1E8129449 for ; Wed, 22 Nov 2017 05:55:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=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 47Kqez6hfmfd for ; Wed, 22 Nov 2017 05:55:49 -0800 (PST) Received: from mx143.netapp.com (mx143.netapp.com [IPv6:2620:10a:4005:8000:2306::c]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9BCD1200FC for ; Wed, 22 Nov 2017 05:55:48 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,436,1505804400"; d="asc'?scan'208";a="229352568" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx143-out.netapp.com with ESMTP; 22 Nov 2017 05:55:48 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 22 Nov 2017 05:55:48 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 22 Nov 2017 05:55:47 -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=un6hquHIqbN7qmo7Rk3ih9dp/LKFY68QCtgaMlq6WCo=; b=EcKBLGjX088tlpi5eaGQP84hVOo0jN2nKHc2McykWpk4S8xODL9IdgXk52XxZ8bq3ZR1dj70rUlcCVxkvlcitE4CfPYmSYEVZ/fwuXbylODJficxSjoTHGu8rx0Qx0J2Nh1tVjRZDM2GqjMFhOBfQkbk+5BmhUlPR5LWD7ckgnI= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 22 Nov 2017 13:55:46 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.004; Wed, 22 Nov 2017 13:55:46 +0000 From: "Eggert, Lars" To: Salvatore Loreto CC: Roni Even , Brian Trammell , "Mark Nottingham" , QUIC WG Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAAyYACAAAWjAIAAD76AgAAGt4A= Date: Wed, 22 Nov 2017 13:55:46 +0000 Message-ID: <9F6AAAF0-02BE-4538-8D4A-1C5B58841104@netapp.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:VSTiK9NGQCeb6+SLY/A5BQw90SBIdL7TlqkHIkIQ4A18YVQPEMG/8qu/gXHfI5ZjYAAeLZgflZeSXCL+hMG5OFMlaAsNn4nGahdoY5Z9comd3ogBrctuBf7NqMuMMP5HYhVO7JnnCR9JTLsdhjuxhnCw9CpJuL+raHucxPoky8V+tNPg9HNYxIRyEXSkFN/Ht46/HYtCgMDIOTbCvSMkBY5cdo1jxtyKUbey3cnWeO1QcHBBoEkIgY8soLqsGVH+uy4L6xTZvCjfj/wL2468m9SFHFMr7GxCCJ1PDkFMP7/oKKdjiXZwuFBo3iskOheR43HvCSeORcQjxM5eSHHWDsC5SOTU1d+o8uUwhIZcZyI=; 5:oNV3s9/xppTvM0Q83ytukHQOGfNrL1UcuWDfF1HQlmJbMefhWN/PnbUqYCm3/RjeXfjEDAjHk85Sc49xPwLjIVRQWezVIhAotEWYM1/XZsAH8AGsdRSV5prDHfazBhwQuMNEODcFq/v82Uo7FMGAREGuzlUXNuiWK7CVNVxJk7w=; 24:ETDQ2zaWdQ7qk3pPe3jwRgOb1vM5hDScCUcVHG262YI/GZGb66apnsWyIGbBdZ+cwsChAzyZWJtyldL4+B5OYeeoKwy4Z14EmJfo3MQvEkk=; 7:r4cvjP2uy2ucTUgozglQBiQIKs9PeNaCEGCGMMexXMMO6c9+TYqYqyDMW87YdA5aC9k2x5v0ZEAFacPVpQqEM1woV/LZgUEJQyJxwxoYRSIFrjZ8rEFG7tAIM1ASEyTPBSnFPROcfzOJg+Qc9inCQgPfYPUrRaFFjHhoCsvl8o1m5X/eGhQCqyKKFftQMmevoObfV/cT4utSqVgB29b0dnlf1BIdAFvUtySi5ieU4U01fqOX6lXGhrYmDnoJyX9Y x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 29affe39-b245-4e20-4c5e-08d531b0bb40 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(3002001)(10201501046)(93006095)(93001095)(3231022)(6055026)(6041248)(20161123555025)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1761; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(189002)(377424004)(24454002)(199003)(106356001)(8676002)(102836003)(53936002)(316002)(105586002)(305945005)(68736007)(54906003)(97736004)(2906002)(81166006)(81156014)(6916009)(53546010)(6512007)(14454004)(36756003)(93886005)(86362001)(82746002)(478600001)(2950100002)(2900100001)(25786009)(4001150100001)(83716003)(4326008)(50226002)(8936002)(33656002)(561944003)(6436002)(77096006)(6246003)(5660300001)(101416001)(57306001)(3660700001)(189998001)(7736002)(6116002)(3280700002)(229853002)(3846002)(66066001)(50986999)(76176999)(99286004)(99936001)(6506006)(6486002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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=_BF518C97-82CB-4B90-9901-14A2F5C36B87"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 29affe39-b245-4e20-4c5e-08d531b0bb40 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 13:55:46.6945 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 13:55:50 -0000 --Apple-Mail=_BF518C97-82CB-4B90-9901-14A2F5C36B87 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-11-22, at 14:31, Salvatore Loreto = wrote: > Indeed in the original mail Mark is on one side proposing to discuss = it in London (instead that into the next interim) > but at same time is leaving open the possibility to postpone the final = decision until right before shipping the protocol to the IESG I think the decision to not discuss it at the interim is based on the = observation that the registered attendees at the interim are probably = not representative of the overall WG constituency - we want to give all = sides an ability to participate equally in the discussion. > While I agree with Mark assessment that we can tip this into the short = header relatively late in the game, > I am concerned for this huge potential delay for a proposal that I = would argue is already clear to all people actively involved in the QUIC = design. >=20 > Can you please which are the next steps you are going to follow here? I think what Mark tried to express is that the discussion on the Spin = Bit can be mostly decoupled from the (large amount of) work remaining on = the base spec. That is, we don't have to conclude the Spin Bit = discussion significantly prior to the conclusion of the overall work = (although we can), since it should be easy to merge at the later stages = before handing things to the IESG. Lars --Apple-Mail=_BF518C97-82CB-4B90-9901-14A2F5C36B87 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloVgeEACgkQVLXDCb9w wVe/VxAA3xMWSKawQtiEvZjwkTVW2ZRyubaSvUdHxSUTBowytB2ABPwh7iUJvp/I h0YtACv+6zIoQG1ElSn2eH4Hk5UqIRAD2j6EPJ2DgkDCt2R7WEITw7oCZEJxR98O UBXM3PGkA/LidBUkQoWPXG7fBbSqLER8Yf7j1Z9SPeCDoxeCYz/rRMiHqQ7h2Bxa 5ZyvLCEfjNrpvO7ciQADBtAFLZT2JLOFxwiFsjWaIQe5Jf/9PXh0MQhVj8zArW9p T9glLLCgSquG8NUKCjrBE1w90jgZHD6oas5LhD1CVfDGa3pNu7l5JW/YX72sqKCs jZH1dQzbxNI/lBFOsyIQ+9mu90N2MG5AoANMxd5os902FEwR5BY79vTXrKBt2RTc bwt0/7UEMKNc4R/P36KHMroFIyfeePj/h8M9zjMrBFqpNi15/v/o3Xgp1cL+197P fEi4IJbs0fqmQf/EkwI1VtDOkBAYsDdQ7Zwm8wlo7jX1dunGOstqfF3mWYOb7KxN S0IRaS1mELXZQs9pyXlhkMitabS/NC+hv3EOCx9qjLDaredeuS232WG3P79tNNoz EqicDXXQhd6P2sHjngEy8WleEDqKYi4Q423ThjN5jWqNOLvxYN3kv80oVxXMIrfN Wwu+syzBBCtpr/RnKviRG8+pOimj8YbOuh8EEJPP9/hF4+o7GUs= =6s6u -----END PGP SIGNATURE----- --Apple-Mail=_BF518C97-82CB-4B90-9901-14A2F5C36B87-- From nobody Wed Nov 22 06:18: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 2901E129401 for ; Wed, 22 Nov 2017 06:18:44 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6C2h78AEQCB for ; Wed, 22 Nov 2017 06:18:42 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE80128DF3 for ; Wed, 22 Nov 2017 06:18:42 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id EB51AFE87D13A for ; Wed, 22 Nov 2017 14:18:37 +0000 (GMT) Received: from DGGEMM423-HUB.china.huawei.com (10.1.198.40) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 22 Nov 2017 14:18:39 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.96]) by dggemm423-hub.china.huawei.com ([10.1.198.40]) with mapi id 14.03.0361.001; Wed, 22 Nov 2017 22:18:26 +0800 From: Roni Even To: "Eggert, Lars" CC: Brian Trammell , Mark Nottingham , "QUIC WG" Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAAyYACAAAWjAIAAGSXw Date: Wed, 22 Nov 2017 14:18:25 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8461A7@DGGEMM506-MBX.china.huawei.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:18:44 -0000 Hi Lars, > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: =E9=E5=ED=A0=E3 22 =F0=E5=E1=EE=E1=F8 2017 14:35 > To: Roni Even > Cc: Brian Trammell; Mark Nottingham; QUIC WG > Subject: Re: Spin bit discussion - where we're at >=20 > Hi Roni, >=20 > On 2017-11-22, at 13:15, Roni Even wrote: > > I was surprised to read the chairs email and agree with Brian's comment= s. > > My impression is that the email reflects a view that manageability is n= ot > important (and not blocking) and this is the reason for not doing the spi= n bit > based on issue 609 as a PR. >=20 > there hasn't been a consensus call on the Spin Bit proposal. Contributors > have expressed their views on the results presented by the DT on the list= , as > requested by the chairs in the session in Singapore. But that is not the = same > as a consensus call, and I apologize if it was misunderstood as one. >=20 > In order to hold an informed consensus call on the Spin Bit in the future= , > we're asking for a more comprehensive writeup (as detailed in the origina= l > email.) As I've said before, I think the material for that already exists= in some > form or other, but it's currently in several places, not all of which may= be > public (e.g., the DT mailing list.) [Roni Even] I agree that there is was no consensus call in Singapore, ther= e was no text to agree on. The issue is if we want a spin bit solution and = the discussion on the list supports it. From the discussion on the Microph= one I noticed that some of the group members did not agree with the content= of the presentation. So to me it look like that the only good thing that c= ame out from the DT is that the spin bit does not add any security risks wi= th regards to the security issues that were presented to them.=20 I do not understand why spin bit issues in the github are "parked"=20 >From my point of view I intend to try to expedite the needed text for the s= pin bit and hope that the expectation will be reasonable comparing to the r= equirements from other features in the protocol. This is why I ask the ch= airs not to wait for IETF 101 if the interested parties will provide text. = Even though you can add this text at any stage towards V1 I would not like = to get it blocked because it did not get enough discussion since it came la= te and people need more time. Based on the interest I expect to discuss it = also in the Interim if we have enough text. I was not aware that the decis= ion on what to discuss is based on the onsite participants >=20 > For *other* proposals that intend to address manageability by adding > information to the cleartext wire image, we're asking for a similarly > comprehensive description, so that the WG can begin discussing a concrete > contribution. >=20 > > My product development experience is that lack of tools to manage and > > maintain a product will prevent its distribution. I understand that > > the developer of the protocol care only about the protocol and not > > about making it easy to support in the field. Yet the network product > > manufacturers and the service providers gave a clear message that RTT > > is crucial for deployment. I provided use cases from TCP in service > > providers networks in > > https://tools.ietf.org/id/draft-even-quic-troubleshooting-video-delive > > ry-00.txt I expect that the WG chair and AD will treat protocol > > maintenance and management the same as the protocol itself. What > > emphasis my point is the effort the WG does on > > https://tools.ietf.org/html/draft-ietf-quic-manageability-01 >=20 > Lars From nobody Wed Nov 22 06:22: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 B008D12421A for ; Wed, 22 Nov 2017 06:22:34 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mv6_HqRacVGs for ; Wed, 22 Nov 2017 06:22:33 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A2F61200FC for ; Wed, 22 Nov 2017 06:22:33 -0800 (PST) Received: from lhreml702-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id EF8124D1F95D3; Wed, 22 Nov 2017 14:22:29 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 22 Nov 2017 14:22:31 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.96]) by DGGEMM406-HUB.china.huawei.com ([10.3.20.214]) with mapi id 14.03.0361.001; Wed, 22 Nov 2017 22:22:28 +0800 From: Roni Even To: "Eggert, Lars" , Salvatore Loreto CC: Brian Trammell , Mark Nottingham , "QUIC WG" Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAAyYACAAAWjAP//iaKAgAAGuACAAIyeUA== Date: Wed, 22 Nov 2017 14:22:27 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8461C0@DGGEMM506-MBX.china.huawei.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> <9F6AAAF0-02BE-4538-8D4A-1C5B58841104@netapp.com> In-Reply-To: <9F6AAAF0-02BE-4538-8D4A-1C5B58841104@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:22:35 -0000 > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: =E9=E5=ED=A0=E3 22 =F0=E5=E1=EE=E1=F8 2017 15:56 > To: Salvatore Loreto > Cc: Roni Even; Brian Trammell; Mark Nottingham; QUIC WG > Subject: Re: Spin bit discussion - where we're at >=20 > Hi, >=20 > On 2017-11-22, at 14:31, Salvatore Loreto > wrote: > > Indeed in the original mail Mark is on one side proposing to discuss > > it in London (instead that into the next interim) but at same time is > > leaving open the possibility to postpone the final decision until > > right before shipping the protocol to the IESG >=20 > I think the decision to not discuss it at the interim is based on the obs= ervation > that the registered attendees at the interim are probably not representat= ive > of the overall WG constituency - we want to give all sides an ability to > participate equally in the discussion. [Roni Even] This is why we have remote participants at IETF meetings !!!!!!= !! You do not have to be in person to discuss!!!! >=20 > > While I agree with Mark assessment that we can tip this into the short > > header relatively late in the game, I am concerned for this huge potent= ial > delay for a proposal that I would argue is already clear to all people ac= tively > involved in the QUIC design. > > > > Can you please which are the next steps you are going to follow here? >=20 > I think what Mark tried to express is that the discussion on the Spin Bit= can be > mostly decoupled from the (large amount of) work remaining on the base > spec. That is, we don't have to conclude the Spin Bit discussion signific= antly > prior to the conclusion of the overall work (although we can), since it s= hould > be easy to merge at the later stages before handing things to the IESG. [Roni Even] delaying the discussion may prevent the acceptance. If people = will put effort at submitting text then the chairs should allow for discuss= ion and not delay the work.=20 >=20 > Lars From nobody Wed Nov 22 06:43: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 DCBD212783A for ; Wed, 22 Nov 2017 06:42: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, 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=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 v8QVjsh8oF0Q for ; Wed, 22 Nov 2017 06:42:57 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8E001200FC for ; Wed, 22 Nov 2017 06:42:57 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,436,1505804400"; d="asc'?scan'208,217";a="241286227" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx141-out.netapp.com with ESMTP; 22 Nov 2017 06:42:57 -0800 Received: from VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 22 Nov 2017 06:42:57 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS07-PRD.hq.netapp.com (10.122.105.25) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 22 Nov 2017 06:42:56 -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=8GYlQrOr+hGjbRvsKdPHa2p4NdmNDaC2rIarTSkc3Pc=; b=JaHXDEDb45Uh5CALHyCHJBCxZ0ykRUeHnEjewwS8oq7R+vhSiLA2fwXy+gr+rIwIiYqKLicrOmNgRy40ii2DSmmogJma48IHXKJAc3ENqbrDTHmisutz6Oe69A4N1g+E5+ff1Y8AmD5ypvxkcyeS7ijrbSINsmd0ttaufOHrKSI= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 22 Nov 2017 14:42:54 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.004; Wed, 22 Nov 2017 14:42:54 +0000 From: "Eggert, Lars" To: Roni Even CC: Brian Trammell , Mark Nottingham , "QUIC WG" Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAAyYACAAAWjAIAAGSXwgAAKe4A= Date: Wed, 22 Nov 2017 14:42:54 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> <6E58094ECC8D8344914996DAD28F1CCD8461A7@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8461A7@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:Wv6scztTelKBUipDRKkLJwiEtIwSkcbeXiOuYzUzmI5OZ20bbbE1FAQE2iCXwyZHihaIvmuPKO/6ghVD/DUJ0N0xtcah7H960WfsyFI/QmxV+z1UlTj6DwcgpWgHQZ5sCv5GSHUL5LsK75s6Exsb+8xivWoYUHJ9cP7ouIgqxOmZ70ZVkKLHsZuRTEDrGveX2+ipqCaJXeEq1RpKo+I3SJ938FikJdnaFtGoFB7wFJwsqicM5hyxN1RIxCuuTPEU9FiKwYaTOL59MKyh6FHmTF2E9MCG9wBKi9oBwBgFzw9L6KYsbyTXeWTS8rKHwHg89tKtyx95amqMv/2nj9g4usoCXIkaIaJXMTfh6OS0Rcs=; 5:FveAiQr+cYKKsrscs7/DU1H1JQN0sY45YeITYjf9EoysRcjbiloveyBkl6kQ/1EcQS65+7/I2BnNiwv0UnfAc8xcL0yz6zN470xgc7GqpPAxrJDizQK/qOnkuyvvBY3YXE8Z8djn2xuv+r+oDxyax+5A1i7h3NCnqfkJHF6Xg+s=; 24:rTgjlHO8sDRyWaF7OvBAgg8SvQcUJDHDeK8chHs/SG/5mseyJq56qxkXztdj9zskd+AOIeNKYdhIMWYzmxYKn/GCAU5kS25EZnKAPrPH4zM=; 7:D/gFMaAWO7BV7JQGnPXAW7LKzLoDXno+HOZhFSF+r6NLSFxe5UKo4hE6p+4OwQ7DqCydRuqu6ffe49Vrd3lS35HXXuSMvAs2L3E0655opJhFUOSv4dQtZ6s/rP8q3+lXueAdOiJlOzn7ktU58T9Vtxgh6bRoY0/AYX13kRO+S0CI2dpJsOFjgTxHcMus06GtRDpfAjI3u8jMJ72lMjA9x1xIa1PW8v944zxpGPDymv1cvY8k2aRm7POf6S8INf0M x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 21f4e0a4-910b-4fae-0ce5-08d531b75095 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(50582790962513)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3231022)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123558100)(20161123564025)(20161123555025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1761; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(85644002)(24454002)(199003)(377424004)(189002)(33656002)(8936002)(5660300001)(6246003)(6436002)(77096006)(50226002)(4326008)(101416001)(99286004)(99936001)(50986999)(66066001)(76176999)(6506006)(6486002)(7736002)(6116002)(3280700002)(57306001)(189998001)(3660700001)(3846002)(229853002)(81156014)(2906002)(81166006)(105586002)(106356001)(8676002)(102836003)(316002)(53936002)(54906003)(97736004)(68736007)(25786009)(2900100001)(4001150100001)(83716003)(14454004)(36756003)(53546010)(54896002)(236005)(6916009)(6512007)(93886005)(478600001)(82746002)(86362001)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.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=_7C52A79C-2842-47A8-8F24-3C533A1E95BB"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 21f4e0a4-910b-4fae-0ce5-08d531b75095 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 14:42:54.0858 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:42:59 -0000 --Apple-Mail=_7C52A79C-2842-47A8-8F24-3C533A1E95BB Content-Type: multipart/alternative; boundary="Apple-Mail=_B6AD381B-18A9-4BE3-8EAE-51D376B33472" --Apple-Mail=_B6AD381B-18A9-4BE3-8EAE-51D376B33472 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-11-22, at 15:18, Roni Even wrote: > [Roni Even] I agree that there is was no consensus call in Singapore, = there was no text to agree on. exactly. The email Mark sent earlier outlines what the chairs think = would be useful for the WG to see, in terms of text. > So to me it look like that the only good thing that came out from the = DT is that the spin bit does not add any security risks with regards to = the security issues that were presented to them. That seems to have been the main result the DT came to consensus on, and = it is a useful bit of information. > I do not understand why spin bit issues in the github are "parked" I think the editors parked it, because we had the DT chartered. Lars --Apple-Mail=_B6AD381B-18A9-4BE3-8EAE-51D376B33472 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On = 2017-11-22, at 15:18, Roni Even <roni.even@huawei.com> wrote:
[Roni Even]  I = agree that there is was no consensus call in Singapore, there was no = text to agree on.

exactly. The email Mark sent earlier outlines what = the chairs think would be useful for the WG to see, in terms of = text.

So to me it look like = that the only good thing that came out from the DT is that the spin bit = does not add any security risks with regards to the security issues that = were presented to them. 

That seems to have been the main result the DT = came to consensus on, and it is a useful bit of information.

I do not understand = why spin bit issues in the github are "parked" 

I think the = editors parked it, because we had the DT chartered.

Lars
= --Apple-Mail=_B6AD381B-18A9-4BE3-8EAE-51D376B33472-- --Apple-Mail=_7C52A79C-2842-47A8-8F24-3C533A1E95BB 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloVjO0ACgkQVLXDCb9w wVc7/hAA2qooo1Ac/l9n7Fx0loHbBL7Ny8tKez51B6Rd0P6WQba6i35/PTyoeC4W Q3LN9aZnBhnOthsYHwVm0i9ULXQGLlKLk1U6NGyFbr1hCZrKVbCb7GhuUfz/gom/ AuvlKT3+ZGRlODPnqqf3uGmQTZX+f7OYBpjxGRjmGmmXmdLJEMZgRk7j7cd0z6In PdP6vScaFVAgtFnDApqGcDwdxhtYCHFa5Jy7qDNzI9k17KnpynFvinv/W2VasUSO gGmhygbBFzhkTfi9HEDauh2SubELIfrxoRVCqTcIe3GZjaObYPWKEIxgv6zkR11D MrafAsaWvHYaf/Z2fTBNTkA2W3ZhH+sPO7xsYBdOtAGCqTblq521Aokefz+63NZ8 OpJqqBOSCR+34fhSDViZ3Bzbbq0Y9Qq/bov3U+2nby8EMRoztLPaa3C6Y5AYNkYY LGs4ogMFvUKzrwpLqQ5qvL/MMLZEfM4P5Azr8WwfYi2KoDJtd7fZlGdvzLeKnOVo HjEyTFpJ+sVB5ydegOsKoNrw6414R/pwvF9dxF4DcozrSUutZf9So1crT1klvDZK pBOhz1UfX2IAoPs0fpK6ijbEVbGNbjB4OJupMtsYMYKmkNbCrgYh9Fdl0BIYavUu Xwg2nvBTHTCOKdMlZ+amo3Qns8YciMz6ctUCkAN7px8YQmE6BU0= =suJI -----END PGP SIGNATURE----- --Apple-Mail=_7C52A79C-2842-47A8-8F24-3C533A1E95BB-- From nobody Wed Nov 22 06:51: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 93A5012783A for ; Wed, 22 Nov 2017 06:51:14 -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, 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=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 2tUVknMZd6oR for ; Wed, 22 Nov 2017 06:51:13 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00F921200FC for ; Wed, 22 Nov 2017 06:51:12 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,436,1505804400"; d="asc'?scan'208,217";a="224009353" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx142-out.netapp.com with ESMTP; 22 Nov 2017 06:51:12 -0800 Received: from VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 22 Nov 2017 06:51:12 -0800 Received: from NAM03-CO1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS09-PRD.hq.netapp.com (10.122.105.27) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 22 Nov 2017 06:51:12 -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=eDK6IZDk5Z3xJNHFaLVZwDoGgCjvlW9B18s1H8rSyyE=; b=aucJNwTRl3uSAgS/bbkBKt/GHGMm6EWhFGba2BcQVExg0u0p9dld2fU6DyxTYJhWl0O1bestWLXgOA3fzzfr9RhVilaCeOBlIl7f8JURa8HzyOOft5DOUe9lxAbjFMHiTHAe/U54Okz+vnJvM14f9aZxmXMG4Y7flizH9wgTOj4= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1762.namprd06.prod.outlook.com (10.162.224.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 22 Nov 2017 14:51:09 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.004; Wed, 22 Nov 2017 14:51:09 +0000 From: "Eggert, Lars" To: Roni Even CC: Salvatore Loreto , Brian Trammell , Mark Nottingham , QUIC WG Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAAyYACAAAWjAIAAD76AgAAGt4CAAAd2gIAACAKA Date: Wed, 22 Nov 2017 14:51:09 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> <9F6AAAF0-02BE-4538-8D4A-1C5B58841104@netapp.com> <6E58094ECC8D8344914996DAD28F1CCD8461C0@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8461C0@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 6:axDB9pWiiH9xhmzKHSTnebeDPy/qdWWY/ER6tx9MKqraW5PVlqpeEGVrGR+4IDyu5N/4c9EizARgEUKXRd+88svg4fIJu95L58aY+1i3E4Knjtp0ARzN2AXpc7J02sGCIG9/p51uU41/QLUVRbBpeAzHoNrjAMZ3sNeURbIW+MDkS72cHmEzzn7W6lihpzG1bEtynavQ+5YCHmOZ7iWnst/I4GxT74cbCHZ/oO8cHf5+0kDq/KKui+Nw4qrkyfS2MCC/oJuI1RNaOboRd4/XH+t0Ui6gw7HFUHVzUSUcu76wBjC1wodPia1IquRcW05NiZ809v4VL5n++P5liWyq8se/LPwyO79ExmbDsyiRInk=; 5:Ipbo3Zno0MIRDAV2V+NL8VGsVuI4jQYvwL3wLskWSTBd3H1Mgg+wd24R7k9ky6qBdyk/qP05mVWAj9cWjI/kXxqX32TvGhDIsEYdLDvcUpGHY8IDHxw7wcaz2C5/TdEdu8tDiSMuOLv9r3r+E6E0jh/VKeezmxfLpmBjX/rrTOs=; 24:4WAM3d4KjlldyR4d0FGCgYK0r8utRGXLUiJaQZ9J3YwCzMip8ZGA7j/HPS4vKp9mgV9nzlRRg3fGPks9xLo0xWAhFHia7MSQUTeiLeDVfhk=; 7:97E4gyRR1nFPwDeF9Pri5BBa8/AxmGofU/7XKlpY8sLbKFFWWNHLvv+UvRfUj4Xa+H39NO1LSP0JXuSSV7CU09FSBoBRsDnxJOk1JcCN+rEOQO7yphEOe6Ec5rUolnRFVe70qEjDgLu8PktIBYYkHjltBgGnGb21WcGEuKp5EhQSm1aWvyORHzqXiEAyhub1erBHSNWXxX+RTbYbgw7VDQJanfnADpLeACazIVl2D3MbIC8U3iYIxxGHHPcoilnF x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4a8d34e9-6a5f-43eb-2d3c-08d531b87797 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1762; x-ms-traffictypediagnostic: BLUPR06MB1762: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231022)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1762; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1762; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(189002)(199003)(377424004)(24454002)(478600001)(93886005)(102836003)(3846002)(316002)(36756003)(5660300001)(14454004)(6116002)(68736007)(50226002)(53936002)(236005)(6512007)(54896002)(4326008)(86362001)(25786009)(99286004)(8936002)(229853002)(8676002)(105586002)(106356001)(33656002)(3280700002)(53546010)(2900100001)(57306001)(66066001)(2906002)(97736004)(6486002)(6506006)(6436002)(189998001)(7736002)(81166006)(99936001)(76176999)(4001150100001)(50986999)(81156014)(77096006)(82746002)(561944003)(6246003)(54906003)(83716003)(3660700001)(6916009)(2950100002)(101416001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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=_D54BA4C3-77CD-426B-80C9-37267C3A02AA"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4a8d34e9-6a5f-43eb-2d3c-08d531b87797 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 14:51:09.0276 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1762 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:51:14 -0000 --Apple-Mail=_D54BA4C3-77CD-426B-80C9-37267C3A02AA Content-Type: multipart/alternative; boundary="Apple-Mail=_9E1C4B54-200D-48C2-A6C4-454AFD2BD23B" --Apple-Mail=_9E1C4B54-200D-48C2-A6C4-454AFD2BD23B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-11-22, at 15:22, Roni Even wrote: >> I think the decision to not discuss it at the interim is based on the = observation >> that the registered attendees at the interim are probably not = representative >> of the overall WG constituency - we want to give all sides an ability = to >> participate equally in the discussion. > [Roni Even] This is why we have remote participants at IETF meetings = !!!!!!!! > You do not have to be in person to discuss!!!! the IETF (vie MeetEcho) provides remote participation at the main = meetings. At the interims, it's Mark. It seems to have mostly worked OK = for passive participation during two out of the last three interims, but = we haven't tried to hold a discussion with many active remote = participants. >> I think what Mark tried to express is that the discussion on the Spin = Bit can be >> mostly decoupled from the (large amount of) work remaining on the = base >> spec. That is, we don't have to conclude the Spin Bit discussion = significantly >> prior to the conclusion of the overall work (although we can), since = it should >> be easy to merge at the later stages before handing things to the = IESG. > [Roni Even] delaying the discussion may prevent the acceptance. If = people will put effort at submitting text then the chairs should allow = for discussion and not delay the work. I disagree with this characterization. What I said above in the paragraph you quote is that we do not *have to* = conclude the Spin Bit discussion urgently *although we can*. = Specifically, we can begin (and conclude) the discussion once there is = an actual proposal that addresses what Mark's original email outlined. Lars --Apple-Mail=_9E1C4B54-200D-48C2-A6C4-454AFD2BD23B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On = 2017-11-22, at 15:22, Roni Even <roni.even@huawei.com> wrote:
I think the decision to not = discuss it at the interim is based on the observation
that = the registered attendees at the interim are probably not = representative
of the overall WG constituency - we want to = give all sides an ability to
participate equally in the = discussion.
[Roni Even] This is why we have remote = participants at IETF meetings !!!!!!!!
You do not have to = be in person to discuss!!!!

the IETF = (vie MeetEcho) provides remote participation at the main meetings. At = the interims, it's Mark. It seems to have mostly worked OK for passive = participation during two out of the last three interims, but we haven't = tried to hold a discussion with many active remote = participants.

I think what Mark tried to = express is that the discussion on the Spin Bit can be
mostly= decoupled from the (large amount of) work remaining on the base
spec. That is, we don't have to conclude the Spin Bit = discussion significantly
prior to the conclusion of the = overall work (although we can), since it should
be easy to = merge at the later stages before handing things to the IESG.
[Roni Even] delaying the discussion may = prevent the acceptance.  If people will put effort at submitting = text then the chairs should allow for discussion and not delay the = work. 
I disagree with this = characterization.

What I said above = in the paragraph you quote is that we do not *have to* conclude the Spin = Bit discussion urgently *although we can*. Specifically, we can begin = (and conclude) the discussion once there is an actual proposal that = addresses what Mark's original email outlined.

Lars
= --Apple-Mail=_9E1C4B54-200D-48C2-A6C4-454AFD2BD23B-- --Apple-Mail=_D54BA4C3-77CD-426B-80C9-37267C3A02AA 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloVjtwACgkQVLXDCb9w wVe8Dw//Y/0HtiE1KbKfUxQJDwliIimrttyKaxbvqKNeJn5vOgcCoZbA4dnOXQoA tn/hThUGE5OwJgpu89xGD8CqABxF/I0yemU6Vf0qs5yAMqXNknF5P//PpaKRMbA0 n96lKcgXvHUUtLUE0Y6QUuhmzzHd/wQ4l9i9fD3FxxD7IAFb2SZ1pOaiBRzTnBSl wXpJDHqYh2QvpZxCAKViFWOUv84FmY0ss7+oQEGE9DhCh9xGJPh1JdsBUd57OXcl xr7AzOCU7UDjy7wVqmAsMcR4eo09tBdGxBfT12gscdzp+h61YzOBiUs3XQ5JwJeK PGEpqDhrnNt2TWc69ZtY0QIsbaxdN2SWeHOdEELXfhZAbyGo7PQ2MeFyIn1h5yGG 5Aj69uW6C8SfyEojajD9IkcBDishvycnuk/+odSBfWR5SZfwMtSID8S+8JeKkmeJ MvVLxJ1OEXmA8xdMNsQHPOCZ4ylycx3Cy4plRRr0XWdwROX9SW3rEJoPJ3JMYF/T s1AVWUcA/dqoN/fKN+fYuVffST6CihxpC4Las/NLGyhQ+ku7Kq4uS7PsAEYY54OW +gjwTk8KZW3QHgrhRBLE7Zm7v5/aAJIk4aSaMREDIYGre1NiF1FQIr1sluMF3NdH JPy2TBo343F++QPDXXCoaF8ujWUd6545lUs/tvZH2c5PpeteW5M= =2sVU -----END PGP SIGNATURE----- --Apple-Mail=_D54BA4C3-77CD-426B-80C9-37267C3A02AA-- From nobody Wed Nov 22 07:57: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 D236212945E for ; Wed, 22 Nov 2017 07:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.219 X-Spam-Level: X-Spam-Status: No, score=-4.219 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, 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 VuuLL9my15S0 for ; Wed, 22 Nov 2017 07:57:50 -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 9641612940E for ; Wed, 22 Nov 2017 07:57:49 -0800 (PST) X-AuditID: c1b4fb30-a25ff70000002554-27-5a159e7ba1e9 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id B0.A3.09556.B7E951A5; Wed, 22 Nov 2017 16:57:47 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Wed, 22 Nov 2017 16:57:46 +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=URmg2DvqQp0IurfVs7Wz0rgn2CFyWbP3Bt8Wjbs9wxY=; b=EjYbSvU7GPsokrK5n944g/LYVX1/LQ2COtUCrUfqiLoYFIFPJQcHINthmA95RBemg4wvjLNVtUU6uFmWRWMdnPc8gzJ9uE8aZ1Bv4DHz7XMiz5xXYWQ5O33tnKrvoiuQSg90uHVVNBwO4WykFiIYaPoZStQ6Mcbv0HfmpUIjOWk= Received: from HE1PR07MB3242.eurprd07.prod.outlook.com (10.170.246.21) by AM3PR07MB0566.eurprd07.prod.outlook.com (10.255.133.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.2; Wed, 22 Nov 2017 15:57:46 +0000 Received: from HE1PR07MB3242.eurprd07.prod.outlook.com ([fe80::6de1:acc:af2d:b555]) by HE1PR07MB3242.eurprd07.prod.outlook.com ([fe80::6de1:acc:af2d:b555%13]) with mapi id 15.20.0260.004; Wed, 22 Nov 2017 15:57:45 +0000 From: Marcus Ihlar To: "Eggert, Lars" CC: Roni Even , Salvatore Loreto , Brian Trammell , "Mark Nottingham" , QUIC WG Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2j1m9xu27oYAUmNiWpCJi3ztaMgHeUAgAAyYACAAAWkgIAAD72AgAAGuACAAAd1gIAACASAgAASlYA= Date: Wed, 22 Nov 2017 15:57:44 +0000 Message-ID: <6FA87C43-D639-4700-9B97-5901237BA5F1@ericsson.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> <9F6AAAF0-02BE-4538-8D4A-1C5B58841104@netapp.com> <6E58094ECC8D8344914996DAD28F1CCD8461C0@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [78.78.35.215] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM3PR07MB0566; 6:0aeC2pFeF6Vkx/seBMKmuG1TamJLelB5QXsHpK43r9r8jJmiay0kWSba4z2oUnGhX/MWE32lc1L0/Z0kETdaD0/2CdbxHZ+sib6dj1/2/HVe+Hdrwi1orWIvPdDfqp/QcYscyRcnplHOBCZA9z4RDvxc2LMEleLofrkyX3V06tzFi73mtlZgnTAFLszfyfwEUsVV6yDE6xVGuwQsNOcrc1wy3DWovG8bi8i9H2fMwMhy/kKyIc9gUQ0dQkltlXpGVeLScRfWEXUrVoW6zX2Z/e+QGQJchpsrUOcpWcJ8uTGokrja7N0B8t4OFZNP6ZR/NMW6O38pTxzKDj7UzgM5E7NNXwg1BAF1JLbjC/yqsQM=; 5:u3DRyjAfgTx3k5Cv5SZDrl4B5c9e7zhjAW9GPkcgg0xuRHsVDwBd0OiFcORoMK3T3818ubLBNVXenS1DzMEJyI0zby3M4lGidOP8yt87PiIEYRNR9Ha4VUxsaWbl7kR6FoGvA+fBu8Pi5xUYmy2hgb4xfom6cvXuxzanbXWPKyc=; 24:09C1BtHyj87DewwXtuYnKwPlenjyF/EimNJRrBtaIz0jNEi+EVz7TT1yUM5spbFspBD/TMvcyTE5jsuKtLSmYMlIJMq2vljzmwdvQ2ur72Q=; 7:6uHT3DbGfjGwkNLccV81DKDPZWTUnvLk69k6EvT+PrzR+/TJwsZOQxvYmhwhtG0yf4wLLmMXebFkAmbehBrBumVZfTGIJ+RxUai/VhBmK9kBq5uqhlqJs62AdFl1Vgnfwyii8C+G/LWXQR0NrcvR/WkCRKBF7/Gc4aqpVSdfivdx6Spf9y2KN9slVtSZR5Tyt+FxtBj3OihqSWxlU2XW2VR2gYe8xhyTKoRAKE1G4j3bpOc6ityBfbjBdETISGIW x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(199003)(24454002)(189002)(377424004)(81156014)(189998001)(33656002)(53546010)(236005)(6512007)(478600001)(83716003)(54896002)(68736007)(53936002)(6916009)(316002)(5660300001)(82746002)(6246003)(14454004)(4001150100001)(101416001)(6436002)(76176999)(106356001)(97736004)(105586002)(6486002)(99936001)(25786009)(99286004)(6506006)(102836003)(2900100001)(3846002)(8936002)(86362001)(54906003)(6116002)(50986999)(7736002)(561944003)(2906002)(229853002)(36756003)(93886005)(3280700002)(2950100002)(81166006)(8676002)(5250100002)(66066001)(4326008)(3660700001)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB0566; H:HE1PR07MB3242.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: dccf14e6-fd9f-4afd-51ed-08d531c1c54a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600022)(4604075)(2017052603258)(49563074); SRVR:AM3PR07MB0566; x-ms-traffictypediagnostic: AM3PR07MB0566: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(50582790962513); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3231022)(3002001)(10201501046)(100000703101)(100105400095)(93006095)(93001095)(6041248)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM3PR07MB0566; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM3PR07MB0566; x-forefront-prvs: 0499DAF22A received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=marcus.ihlar@ericsson.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/signed; boundary="Apple-Mail-FB2F6F2B-9D55-434C-9CAD-AF25B9C4BD68"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: dccf14e6-fd9f-4afd-51ed-08d531c1c54a X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 15:57:44.9662 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB0566 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA2WSe0hTYRiH+3YuO05HJ93yxbJsTLpqZirDym4QiwoSjMKE3PKkos3adGRR DBqZm4lmhVvWlFViwyyzzG7qstIsK5OI0kQdqKizluhKk9zOCqH/nvd7n9/vnPNxKMy3gAyg UhWZjFIhSxeRPNywrzY25MRVYXxYbmek5I7WTkoGhvJwSZWjD0nySr0ljhdv8U2EVNs0Qkiv XfvJkd4xTxDSYscYKbXVG/DdRDxvfRKTnqpmlKtjEnkpbY5qzpHq48fyjLUcDRpW65AXBXQE tOTfxnWIR/nSzxD0/xuaEfyu6+K6Bpw+h4HhkgNjN5c4cKO80jP0IHj0zYhcZSQdCq+79KSL BbQY7ppa3XGMrkPQ8P2xW/Kj18AFw2sOK4XDGftZT0AO084K3MU4HQztzwq5LubTG+Fp/jku +7QfGExPmdwLLzoGch4Z3AFEB0L3xFc3Y7Q/fLaZOOznCaDnfSvJshAG+6YJHaJmOAiaxxLY 40BoN+mRqx9oKxfGP173+GtBV/CYYPkyCQ/vy9nsLqjtmM/6txA47c0Y66yAzzkTOMtpYKtp 8/REQ6XW1eMKdBMwfvoLYosWQmFVQgEKMc56baP7wooQTJrvYUb3BcyDFoMNZ6UDMPzmLJfl xVA7UoKxvBzq9eUeZwlc0Pd4nGWQO15I/H++Dop/NZIsR8LQ8+9otlOKfG4ioYpRyQ8nh4eH MsrUgypVhiJUwWRWo5l/s7FmMuwBGuzfbEU0hUQ+fO8iYbwvIVOrsg9bkXimp/e25R0KwBUZ CkYk4J/Xz6z5SbLs44wy44AyK51RWdECChf581u28+N96WRZJpPGMEcY5d8th/IK0KDK/dYr yyyJ2uchasvLujLH3kXZuim1WWZ5FdofURa51DleN+nH35i8++KroMVzy4pWMR1RxaWmzq1H ewdKslrlL2q2nbQHFlvKDzU5Ow+K2yNig6MbnqTtFNs/jH512k6hvfo5moEtzmzNntEK7wpB HDUQtLIvLuH9hk+0uStqhwhXpcjWrMCUKtkfd+J2BaMDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 15:57:52 -0000 --Apple-Mail-FB2F6F2B-9D55-434C-9CAD-AF25B9C4BD68 Content-Type: multipart/alternative; boundary=Apple-Mail-26D6D5FF-4BC3-43FB-9B66-DC9B5E16638A Content-Transfer-Encoding: 7bit --Apple-Mail-26D6D5FF-4BC3-43FB-9B66-DC9B5E16638A Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGksDQpKdXN0IGNoaXBwaW5nIGluIHRvIHNheSB0aGF0IEnigJltIGhhcHB5IHRvIHdvcmsgd2l0 aCBCcmlhbiBvbiB0aGlzIGRyYWZ0Lg0KDQovTWFyY3VzDQoNCj4gT24gMjIgTm92IDIwMTcsIGF0 IDIyOjUxLCBFZ2dlcnQsIExhcnMgPGxhcnNAbmV0YXBwLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSwN Cj4gDQo+IE9uIDIwMTctMTEtMjIsIGF0IDE1OjIyLCBSb25pIEV2ZW4gPHJvbmkuZXZlbkBodWF3 ZWkuY29tPiB3cm90ZToNCj4+PiBJIHRoaW5rIHRoZSBkZWNpc2lvbiB0byBub3QgZGlzY3VzcyBp dCBhdCB0aGUgaW50ZXJpbSBpcyBiYXNlZCBvbiB0aGUgb2JzZXJ2YXRpb24NCj4+PiB0aGF0IHRo ZSByZWdpc3RlcmVkIGF0dGVuZGVlcyBhdCB0aGUgaW50ZXJpbSBhcmUgcHJvYmFibHkgbm90IHJl cHJlc2VudGF0aXZlDQo+Pj4gb2YgdGhlIG92ZXJhbGwgV0cgY29uc3RpdHVlbmN5IC0gd2Ugd2Fu dCB0byBnaXZlIGFsbCBzaWRlcyBhbiBhYmlsaXR5IHRvDQo+Pj4gcGFydGljaXBhdGUgZXF1YWxs eSBpbiB0aGUgZGlzY3Vzc2lvbi4NCj4+IFtSb25pIEV2ZW5dIFRoaXMgaXMgd2h5IHdlIGhhdmUg cmVtb3RlIHBhcnRpY2lwYW50cyBhdCBJRVRGIG1lZXRpbmdzICEhISEhISEhDQo+PiBZb3UgZG8g bm90IGhhdmUgdG8gYmUgaW4gcGVyc29uIHRvIGRpc2N1c3MhISEhDQo+IA0KPiB0aGUgSUVURiAo dmllIE1lZXRFY2hvKSBwcm92aWRlcyByZW1vdGUgcGFydGljaXBhdGlvbiBhdCB0aGUgbWFpbiBt ZWV0aW5ncy4gQXQgdGhlIGludGVyaW1zLCBpdCdzIE1hcmsuIEl0IHNlZW1zIHRvIGhhdmUgbW9z dGx5IHdvcmtlZCBPSyBmb3IgcGFzc2l2ZSBwYXJ0aWNpcGF0aW9uIGR1cmluZyB0d28gb3V0IG9m IHRoZSBsYXN0IHRocmVlIGludGVyaW1zLCBidXQgd2UgaGF2ZW4ndCB0cmllZCB0byBob2xkIGEg ZGlzY3Vzc2lvbiB3aXRoIG1hbnkgYWN0aXZlIHJlbW90ZSBwYXJ0aWNpcGFudHMuDQo+IA0KPj4+ IEkgdGhpbmsgd2hhdCBNYXJrIHRyaWVkIHRvIGV4cHJlc3MgaXMgdGhhdCB0aGUgZGlzY3Vzc2lv biBvbiB0aGUgU3BpbiBCaXQgY2FuIGJlDQo+Pj4gbW9zdGx5IGRlY291cGxlZCBmcm9tIHRoZSAo bGFyZ2UgYW1vdW50IG9mKSB3b3JrIHJlbWFpbmluZyBvbiB0aGUgYmFzZQ0KPj4+IHNwZWMuIFRo YXQgaXMsIHdlIGRvbid0IGhhdmUgdG8gY29uY2x1ZGUgdGhlIFNwaW4gQml0IGRpc2N1c3Npb24g c2lnbmlmaWNhbnRseQ0KPj4+IHByaW9yIHRvIHRoZSBjb25jbHVzaW9uIG9mIHRoZSBvdmVyYWxs IHdvcmsgKGFsdGhvdWdoIHdlIGNhbiksIHNpbmNlIGl0IHNob3VsZA0KPj4+IGJlIGVhc3kgdG8g bWVyZ2UgYXQgdGhlIGxhdGVyIHN0YWdlcyBiZWZvcmUgaGFuZGluZyB0aGluZ3MgdG8gdGhlIElF U0cuDQo+PiBbUm9uaSBFdmVuXSBkZWxheWluZyB0aGUgZGlzY3Vzc2lvbiBtYXkgcHJldmVudCB0 aGUgYWNjZXB0YW5jZS4gIElmIHBlb3BsZSB3aWxsIHB1dCBlZmZvcnQgYXQgc3VibWl0dGluZyB0 ZXh0IHRoZW4gdGhlIGNoYWlycyBzaG91bGQgYWxsb3cgZm9yIGRpc2N1c3Npb24gYW5kIG5vdCBk ZWxheSB0aGUgd29yay4gDQo+IA0KPiBJIGRpc2FncmVlIHdpdGggdGhpcyBjaGFyYWN0ZXJpemF0 aW9uLg0KPiANCj4gV2hhdCBJIHNhaWQgYWJvdmUgaW4gdGhlIHBhcmFncmFwaCB5b3UgcXVvdGUg aXMgdGhhdCB3ZSBkbyBub3QgKmhhdmUgdG8qIGNvbmNsdWRlIHRoZSBTcGluIEJpdCBkaXNjdXNz aW9uIHVyZ2VudGx5ICphbHRob3VnaCB3ZSBjYW4qLiBTcGVjaWZpY2FsbHksIHdlIGNhbiBiZWdp biAoYW5kIGNvbmNsdWRlKSB0aGUgZGlzY3Vzc2lvbiBvbmNlIHRoZXJlIGlzIGFuIGFjdHVhbCBw cm9wb3NhbCB0aGF0IGFkZHJlc3NlcyB3aGF0IE1hcmsncyBvcmlnaW5hbCBlbWFpbCBvdXRsaW5l ZC4NCj4gDQo+IExhcnMNCg== --Apple-Mail-26D6D5FF-4BC3-43FB-9B66-DC9B5E16638A Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBlIiBjb250ZW50PSJ0ZXh0 L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPjwvaGVhZD48Ym9keSBkaXI9ImF1dG8iPkhpLDxkaXY+SnVz dCBjaGlwcGluZyBpbiB0byBzYXkgdGhhdCBJ4oCZbSBoYXBweSB0byB3b3JrIHdpdGggQnJpYW4g b24gdGhpcyBkcmFmdC48YnI+PGJyPi9NYXJjdXM8ZGl2Pjxicj5PbiAyMiBOb3YgMjAxNywgYXQg MjI6NTEsIEVnZ2VydCwgTGFycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNAbmV0YXBwLmNvbSI+ bGFyc0BuZXRhcHAuY29tPC9hPiZndDsgd3JvdGU6PGJyPjxicj48L2Rpdj48YmxvY2txdW90ZSB0 eXBlPSJjaXRlIj48ZGl2PjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXVzLWFzY2lpIj5IaSw8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0i Ij48L2Rpdj48ZGl2IGNsYXNzPSIiPk9uIDIwMTctMTEtMjIsIGF0IDE1OjIyLCBSb25pIEV2ZW4g Jmx0OzxhIGhyZWY9Im1haWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbSIgY2xhc3M9IiI+cm9uaS5l dmVuQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8YnIgY2xhc3M9IiI+PGRpdj48YmxvY2txdW90 ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48ZGl2IGNsYXNzPSIiPjxibG9ja3F1b3RlIHR5cGU9ImNp dGUiIHN0eWxlPSJmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRvOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBj bGFzcz0iIj5JIHRoaW5rIHRoZSBkZWNpc2lvbiB0byBub3QgZGlzY3VzcyBpdCBhdCB0aGUgaW50 ZXJpbSBpcyBiYXNlZCBvbiB0aGUgb2JzZXJ2YXRpb248YnIgY2xhc3M9IiI+dGhhdCB0aGUgcmVn aXN0ZXJlZCBhdHRlbmRlZXMgYXQgdGhlIGludGVyaW0gYXJlIHByb2JhYmx5IG5vdCByZXByZXNl bnRhdGl2ZTxiciBjbGFzcz0iIj5vZiB0aGUgb3ZlcmFsbCBXRyBjb25zdGl0dWVuY3kgLSB3ZSB3 YW50IHRvIGdpdmUgYWxsIHNpZGVzIGFuIGFiaWxpdHkgdG88YnIgY2xhc3M9IiI+cGFydGljaXBh dGUgZXF1YWxseSBpbiB0aGUgZGlzY3Vzc2lvbi48YnIgY2xhc3M9IiI+PC9ibG9ja3F1b3RlPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxMnB4OyBm b250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0 OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0 LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg d29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6 IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+W1JvbmkgRXZlbl0g VGhpcyBpcyB3aHkgd2UgaGF2ZSByZW1vdGUgcGFydGljaXBhbnRzIGF0IElFVEYgbWVldGluZ3Mg ISEhISEhISE8L3NwYW4+PGJyIHN0eWxlPSJmb250LWZhbWlseTogTWVubG8tUmVndWxhcjsgZm9u dC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRleHQtYWxp Z246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUt c3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDsiIGNsYXNzPSIiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTogTWVubG8tUmVndWxh cjsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHRl eHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsg d2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlubGluZSAhaW1wb3J0YW50OyIg Y2xhc3M9IiI+WW91IGRvIG5vdCBoYXZlIHRvIGJlIGluIHBlcnNvbiB0byBkaXNjdXNzISEhITwv c3Bhbj48YnIgc3R5bGU9ImZvbnQtZmFtaWx5OiBNZW5sby1SZWd1bGFyOyBmb250LXNpemU6IDEy cHg7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDsgZm9udC13 ZWlnaHQ6IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjogc3RhcnQ7 IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9y bWFsOyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyIg Y2xhc3M9IiI+PC9kaXY+PC9ibG9ja3F1b3RlPjxkaXY+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXY+ dGhlIElFVEYgKHZpZSBNZWV0RWNobykgcHJvdmlkZXMgcmVtb3RlIHBhcnRpY2lwYXRpb24gYXQg dGhlIG1haW4gbWVldGluZ3MuIEF0IHRoZSBpbnRlcmltcywgaXQncyBNYXJrLiBJdCBzZWVtcyB0 byBoYXZlIG1vc3RseSB3b3JrZWQgT0sgZm9yIHBhc3NpdmUgcGFydGljaXBhdGlvbiBkdXJpbmcg dHdvIG91dCBvZiB0aGUgbGFzdCB0aHJlZSBpbnRlcmltcywgYnV0IHdlIGhhdmVuJ3QgdHJpZWQg dG8gaG9sZCBhIGRpc2N1c3Npb24gd2l0aCBtYW55IGFjdGl2ZSByZW1vdGUgcGFydGljaXBhbnRz LjwvZGl2PjxiciBjbGFzcz0iIj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj48ZGl2 IGNsYXNzPSIiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIHN0eWxlPSJmb250LWZhbWlseTogTWVu bG8tUmVndWxhcjsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFy aWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1zcGFjaW5nOiBu b3JtYWw7IG9ycGhhbnM6IGF1dG87IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4 OyB0ZXh0LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd2lkb3dzOiBhdXRv OyB3b3JkLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Vi a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7IiBjbGFzcz0iIj5JIHRoaW5rIHdoYXQgTWFyayB0 cmllZCB0byBleHByZXNzIGlzIHRoYXQgdGhlIGRpc2N1c3Npb24gb24gdGhlIFNwaW4gQml0IGNh biBiZTxiciBjbGFzcz0iIj5tb3N0bHkgZGVjb3VwbGVkIGZyb20gdGhlIChsYXJnZSBhbW91bnQg b2YpIHdvcmsgcmVtYWluaW5nIG9uIHRoZSBiYXNlPGJyIGNsYXNzPSIiPnNwZWMuIFRoYXQgaXMs IHdlIGRvbid0IGhhdmUgdG8gY29uY2x1ZGUgdGhlIFNwaW4gQml0IGRpc2N1c3Npb24gc2lnbmlm aWNhbnRseTxiciBjbGFzcz0iIj5wcmlvciB0byB0aGUgY29uY2x1c2lvbiBvZiB0aGUgb3ZlcmFs bCB3b3JrIChhbHRob3VnaCB3ZSBjYW4pLCBzaW5jZSBpdCBzaG91bGQ8YnIgY2xhc3M9IiI+YmUg ZWFzeSB0byBtZXJnZSBhdCB0aGUgbGF0ZXIgc3RhZ2VzIGJlZm9yZSBoYW5kaW5nIHRoaW5ncyB0 byB0aGUgSUVTRy48YnIgY2xhc3M9IiI+PC9ibG9ja3F1b3RlPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTogTWVubG8tUmVndWxhcjsgZm9udC1zaXplOiAxMnB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHRleHQtYWxpZ246IHN0YXJ0OyB0ZXh0LWluZGVudDogMHB4OyB0ZXh0 LXRyYW5zZm9ybTogbm9uZTsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgZmxvYXQ6IG5vbmU7IGRpc3BsYXk6IGlu bGluZSAhaW1wb3J0YW50OyIgY2xhc3M9IiI+W1JvbmkgRXZlbl0gZGVsYXlpbmcgdGhlIGRpc2N1 c3Npb24gbWF5IHByZXZlbnQgdGhlIGFjY2VwdGFuY2UuICZuYnNwO0lmIHBlb3BsZSB3aWxsIHB1 dCBlZmZvcnQgYXQgc3VibWl0dGluZyB0ZXh0IHRoZW4gdGhlIGNoYWlycyBzaG91bGQgYWxsb3cg Zm9yIGRpc2N1c3Npb24gYW5kIG5vdCBkZWxheSB0aGUgd29yay48c3BhbiBjbGFzcz0iQXBwbGUt Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjwvZGl2PjwvYmxvY2txdW90ZT48 YnIgY2xhc3M9IiI+PC9kaXY+PC9kaXY+PGRpdj5JIGRpc2FncmVlIHdpdGggdGhpcyBjaGFyYWN0 ZXJpemF0aW9uLjwvZGl2PjxkaXY+PGJyIGNsYXNzPSIiPjwvZGl2PjxkaXY+V2hhdCBJIHNhaWQg YWJvdmUgaW4gdGhlIHBhcmFncmFwaCB5b3UgcXVvdGUgaXMgdGhhdCB3ZSBkbyBub3QgKmhhdmUg dG8qIGNvbmNsdWRlIHRoZSBTcGluIEJpdCBkaXNjdXNzaW9uIHVyZ2VudGx5ICphbHRob3VnaCB3 ZSBjYW4qLiBTcGVjaWZpY2FsbHksIHdlIGNhbiBiZWdpbiAoYW5kIGNvbmNsdWRlKSB0aGUgZGlz Y3Vzc2lvbiBvbmNlIHRoZXJlIGlzIGFuIGFjdHVhbCBwcm9wb3NhbCB0aGF0IGFkZHJlc3NlcyB3 aGF0IE1hcmsncyBvcmlnaW5hbCBlbWFpbCBvdXRsaW5lZC48L2Rpdj48ZGl2PjxiciBjbGFzcz0i Ij48L2Rpdj48ZGl2PkxhcnM8L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9kaXY+PC9ib2R5Pjwv aHRtbD4= --Apple-Mail-26D6D5FF-4BC3-43FB-9B66-DC9B5E16638A-- --Apple-Mail-FB2F6F2B-9D55-434C-9CAD-AF25B9C4BD68 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMqTCCBesw ggPToAMCAQICEBZmcKQRRjNw1PdSU5JDz7kwDQYJKoZIhvcNAQEFBQAwOjERMA8GA1UECgwIRXJp Y3Nzb24xJTAjBgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjIwHhcNMTQxMjAzMTEx NzUxWhcNMTcxMjAzMTExNzUwWjBmMREwDwYDVQQKDAhFcmljc3NvbjEVMBMGA1UEAwwMTWFyY3Vz IElobGFyMSgwJgYJKoZIhvcNAQkBFhltYXJjdXMuaWhsYXJAZXJpY3Nzb24uY29tMRAwDgYDVQQF EwdlbWFyaWhsMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAloIS4tGTL4vDh7SUI5AL S+lqDSGdmu4x44OOJWxtLD0+WraSlbXlfcdmNBs7jHhvlp2H8QI1mnU16hu4zVlQylS3jdAY74xF mta6U1ZUsw0AprA2ihvRaHqafkLI69Wizv7XDcU67zoD+TTgtgaBI9agmUcex9Qv9WFmhuRub0Jv HZezw+EXRVrznKodEB2UeM+LSkefuxjiIEp3gRSJ5EgLnLjlNPUShPosCffWzOmNALwfq8W4GJdx ZarKLlNrsVQnD1RNGlWwJeSNvqOopCE80suFv3Blac5NPcr3JEQEfgVtbjR0ijLspTbj6j6UGj8J uXIabnI1/alLaNgFrwIDAQABo4IBvzCCAbswSAYDVR0fBEEwPzA9oDugOYY3aHR0cDovL2NybC50 cnVzdC50ZWxpYS5jb20vZXJpY3Nzb25ubGluZGl2aWR1YWxjYXYyLmNybDCBggYIKwYBBQUHAQEE djB0MCgGCCsGAQUFBzABhhxodHRwOi8vb2NzcDIudHJ1c3QudGVsaWEuY29tMEgGCCsGAQUFBzAC hjxodHRwOi8vY2EudHJ1c3QudGVsaWFzb25lcmEuY29tL2VyaWNzc29ubmxpbmRpdmlkdWFsY2F2 Mi5jZXIwJAYDVR0RBB0wG4EZbWFyY3VzLmlobGFyQGVyaWNzc29uLmNvbTBVBgNVHSAETjBMMEoG DCsGAQQBgg8CAwEBEjA6MDgGCCsGAQUFBwIBFixodHRwczovL3JlcG9zaXRvcnkudHJ1c3QudGVs aWFzb25lcmEuY29tL0NQUzAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYE FDM4jO3rLCqOTlXf4FyV++FOTOOKMB8GA1UdIwQYMBaAFLENytRGt6+GAsMvbwbKDnZxf0s3MA4G A1UdDwEB/wQEAwIFoDANBgkqhkiG9w0BAQUFAAOCAgEAGAUhHcBBEaN68sqhHRJQ0iDUGK2NxQIu uvMxc0bnoPaoC8rJcjmokdpqLuujoroTfNwmBvnT4mSVtHWUbj/+B72pD4Vs3LgP5SS2B5kd6O3K VoFpmiJMyVXQwhK6M8N8vLzMweCk2I/fcYxn1sq2M2fotUpZk+a9nzTUuahH9LADow7V8MgqedXz mUjkHDLRCSUKswd2TKB8phT5v6lP87OnraFchXCIwGzf1ykF3CYrLH6yce03jQ8+xN/1Xg+cxpR4 /xcJLFzyWrNFCS4Y4tWUcYjkTCeRNz3MQ3br8OeDtCFGGkivlsPRYbrgqrUQM24hrdHcEAlThFDk jmNuT4xvCOXPtWtjCK6CgmelnLEC/RkcxvHG96lufYw+CYJnGcTgRG9Mhk9b79oEkpeiYRv9oU0E Z6jO2HxsIk1ZP58/n7EWE7bHgnn7l6sDbWqCl8mfAd9qQKyrbewFwXM1lxGR8LpmfLDMaVndFdn2 PEVkSCd+lwCTP12ZLtVgEGTqiiL2xbCB8IyvaKcckjWNj+VUH6rjvapL9Tj8Agi1hRvossxV0Fky t/lK7wPsbpBarR9g+EUEMhHWdy304zdvyGgit0KEEwGyTAJ/N3VvufrjdxTFKehfs53epXaA7hh8 ott5jefG1NYl3ruRX2hk3EacS7bWZjDZda4R38QzgW8wgga2MIIEnqADAgECAhEAoAzLzJuZmOzi OnD0fMHAWTANBgkqhkiG9w0BAQUFADA3MRQwEgYDVQQKDAtUZWxpYVNvbmVyYTEfMB0GA1UEAwwW VGVsaWFTb25lcmEgUm9vdCBDQSB2MTAeFw0xNDA1MjcwNzQ2MjFaFw0yNDA1MjcwNzQ2MjFaMDox ETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENBIHYy MIICIjANBgkqhkiG9w0BAQEFAAOCAg8AMIICCgKCAgEA2rpT619IllOfiTjqo3XceBp5dewyYZJZ KFzoDkgTIVuhcxlbeUUeyj7/q47dmKW8HaKlkmGuFT5Ev+9r7kKFrL89mr1ll4T03Tc6wd87OXCT u7CiMnfi0cuJf/JCiuIj5vkNfF8hhdMU7nOVkt1ojEnCUsRCnSDj/MXoQa2h2Wm6xofTsUBwuIgR 5Mw9GBdyf7wagU6+25Uc2H9Yd4+Wu6lSBwj38/nghNe+ZkXrFw0ESOy7zImbVWqorQZdKACYicng ZrxLowTbCBIFEOiXEBRuZ8tBGsy8sL+3JcG+4s7y4KF3Okha3dA+0xibZHZXVSbTMA2F6chTBgIo 0+rn/IdpLjyMKw4EBTRMiEGeKudmaURsLoAurDMYBxAxowPwsV/WguVYtRDESYjhheoFd0/lechw x0gQXkG1QF5vMEkwwX10MHa6PwF6hE9JhukaXuKthRgWmrhPKhxDuqkd1gBIL41XxVNpOsWcdapr 8IZF2ncYemSDF84G+lqY4ry50dBhCja4Ddg13b6PungLeOQYb5npGtk6yQ8TC1ogcvEGIDXjV2EL LkRJw7I1qOsBdC6mwOe+vaJvZ5/7ic5s8W9509Yh7nuXKPSfd7WtOpMYgEh73CM2cADoyp5pNL0d yE+0G86tqH9xNbNfMaPAzPQ/dQmpNDavkQC7Xb9bmSkCAwEAAaOCAbgwggG0MIGKBggrBgEFBQcB AQR+MHwwLQYIKwYBBQUHMAGGIWh0dHA6Ly9vY3NwLnRydXN0LnRlbGlhc29uZXJhLmNvbTBLBggr BgEFBQcwAoY/aHR0cDovL3JlcG9zaXRvcnkudHJ1c3QudGVsaWFzb25lcmEuY29tL3RlbGlhc29u ZXJhcm9vdGNhdjEuY2VyMBIGA1UdEwEB/wQIMAYBAf8CAQAwVQYDVR0gBE4wTDBKBgwrBgEEAYIP AgMBAQIwOjA4BggrBgEFBQcCARYsaHR0cHM6Ly9yZXBvc2l0b3J5LnRydXN0LnRlbGlhc29uZXJh LmNvbS9DUFMwSwYDVR0fBEQwQjBAoD6gPIY6aHR0cDovL2NybC0zLnRydXN0LnRlbGlhc29uZXJh LmNvbS90ZWxpYXNvbmVyYXJvb3RjYXYxLmNybDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwDgYDVR0PAQH/BAQDAgEGMB0GA1UdDgQWBBSxDcrURrevhgLDL28Gyg52cX9LNzAfBgNVHSME GDAWgBTwj1k4ALP1j5qWDNXr+nuqF+gTEjANBgkqhkiG9w0BAQUFAAOCAgEAbgcgbK+sdz2QQrJh m3Emf1y/tLZ1TG5SJ6CYC9QYdz4kYnIHaPJfunL1qfwKwcDGDcEjcq72PSHsMmlfJ+uXOaDfpdiQ 1Ls63QDVSp2MYWu2cghIj5mPfLAdm52YMXyS10GKEcCO6TjsH8qD9nwmFQnfsYbH8rGIiJeDkcxN 06XqaUNslpMgQZqB1FyYfe7nuvmydn6p1VKDlTFZ2GBLb7M+u7+8Ns9373XMtOP0Z6MpcUnp8QA4 tbWPYiMnRzIMjrt3X87MVPAIrzBhuGikrbAn1BMoNC5ZG4ajK3Z3rLN3tagBLnkkTQEi36RcMkZs 5orjYfaJ87oREdsmISv+iHgrOB0B6z4ZGPCVJobZnS9rhKzmVjrN/BUIRlh1lyNIOkoHQzm1NBhB 47tDJA84joZvgVcD2Sjewe8A+zj4+r5S1aOnfLyxivW8sIRH148SyAt0IbbuZST04CKOQbqfmgQY 4if7vQX6q8qmabnZ1nxvsMQt9u66TQKtjinRbEfdsG3oUmQ95kkgHpg1cBgdmLtFx0GMsmH6VrBs hhMkUhyhYUcCXSDT81iyPPcMuFnPj4KsnpJBJianuoOF0kBY+JqrcL6oT+HYNkAnCjP24etkcHzO xnkkvyxRnvOCpiY0w370/HNqyvJxMmf3pjrcAhl0OrWQgcjDS8Xg8FNUxm0xggKWMIICkgIBATBO MDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBOTCBJbmRpdmlkdWFsIENB IHYyAhAWZnCkEUYzcNT3UlOSQ8+5MAkGBSsOAwIaBQCgggEdMBgGCSqGSIb3DQEJAzELBgkqhkiG 9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE3MTEyMjE1NTc0MFowIwYJKoZIhvcNAQkEMRYEFMtoQ+8X Z2i8rx6uxZCBijB7N+DiMF0GCSsGAQQBgjcQBDFQME4wOjERMA8GA1UECgwIRXJpY3Nzb24xJTAj BgNVBAMMHEVyaWNzc29uIE5MIEluZGl2aWR1YWwgQ0EgdjICEBZmcKQRRjNw1PdSU5JDz7kwXwYL KoZIhvcNAQkQAgsxUKBOMDoxETAPBgNVBAoMCEVyaWNzc29uMSUwIwYDVQQDDBxFcmljc3NvbiBO TCBJbmRpdmlkdWFsIENBIHYyAhAWZnCkEUYzcNT3UlOSQ8+5MA0GCSqGSIb3DQEBAQUABIIBAG28 12xZ3m2i+KThY9td8Sc2fpdHUTg1k3+ZeLvuXaPA1Ql8aSIGX9KlSSanch6D4Zugd/arIcWi2J3a Jo33E4B2eFLy4sK14/BULPdiRegj4XdCilaHZESDdlIR1aUEP4jonlfdOqRs/bzURyVJXgYvBa3j 5VT8aXlpCDRvmWpM+E1ABYTLp6SjCZlScpnPnuvl+0PkSOc9tkR0MpoHgIJfhyTyLl32OA8qPaiK Ax9Ujc26AbcHsOBVJfY5IcVEm04uheJqiIsDJByoWgtnh8iagfqWc69NXsu4aIYuPYfK7czXBBk6 aKrMz0ypZkhHcf+6RzB1ngMqoqfwfewbmCIAAAAAAAA= --Apple-Mail-FB2F6F2B-9D55-434C-9CAD-AF25B9C4BD68-- From nobody Wed Nov 22 08:25: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 0CB00129466 for ; Wed, 22 Nov 2017 08:25:19 -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 06Ah6sUtxsfS for ; Wed, 22 Nov 2017 08:25:17 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id DB4D31270A3 for ; Wed, 22 Nov 2017 08:25:16 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 9D23E340EE5; Wed, 22 Nov 2017 17:25:15 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.27386); Wed, 22 Nov 2017 17:25:15 +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; Wed, 22 Nov 2017 17:25:15 +0100 (CET) Received: from [145.14.214.39] (account ietf@trammell.ch HELO [10.11.33.5]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 36889649; Wed, 22 Nov 2017 17:25:06 +0100 From: "Brian Trammell (IETF)" Message-Id: <840EB9F8-7646-426E-AEB5-6FFFCEE4D89D@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_FFEE8E37-63A7-4300-A201-06237B6CF25A"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Spin bit discussion - where we're at Date: Wed, 22 Nov 2017 17:25:06 +0100 In-Reply-To: <9F6AAAF0-02BE-4538-8D4A-1C5B58841104@netapp.com> Cc: Salvatore Loreto , Roni Even , QUIC WG , Mark Nottingham To: "Eggert, Lars" References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> <9F6AAAF0-02BE-4538-8D4A-1C5B58841104@netapp.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 16:25:19 -0000 --Apple-Mail=_FFEE8E37-63A7-4300-A201-06237B6CF25A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 22 Nov 2017, at 14:55, Eggert, Lars wrote: >=20 > Hi, >=20 > On 2017-11-22, at 14:31, Salvatore Loreto = wrote: >> Indeed in the original mail Mark is on one side proposing to discuss = it in London (instead that into the next interim) >> but at same time is leaving open the possibility to postpone the = final decision until right before shipping the protocol to the IESG >=20 > I think the decision to not discuss it at the interim is based on the = observation that the registered attendees at the interim are probably = not representative of the overall WG constituency - we want to give all = sides an ability to participate equally in the discussion. >=20 >> While I agree with Mark assessment that we can tip this into the = short header relatively late in the game, >> I am concerned for this huge potential delay for a proposal that I = would argue is already clear to all people actively involved in the QUIC = design. >>=20 >> Can you please which are the next steps you are going to follow here? >=20 > I think what Mark tried to express is that the discussion on the Spin = Bit can be mostly decoupled from the (large amount of) work remaining on = the base spec. That is, we don't have to conclude the Spin Bit = discussion significantly prior to the conclusion of the overall work = (although we can), since it should be easy to merge at the later stages = before handing things to the IESG. Quoting this for truth, and agreement. One of the nice properties of = this particular proposal is that it can be implemented (almost) = completely independently of the rest of the transport protocol, and as = such can be developed independently as well. However, this is probably not the case for the other proposals I'm aware = of: a simple loss/ECN re-feedback mechanism as in conex impacts ack = handling, for instance, and some of the debug bits signaling whether a = flow is flow control or congestion control limited (see 279 / 418) also = require slightly deeper integration with the transport mechanics. We = already pretty much knew that discussion on these was a topic for v2, = though, so the additional process doesn't actually change anything = there. Cheers, Brian --Apple-Mail=_FFEE8E37-63A7-4300-A201-06237B6CF25A 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloVpOIACgkQihK3vwvq RqN84hAAnxrS/OXaHR0Y35EzPizT5qPlcCEjCqd5pvun3+4UbBdlaykJKOa49ALJ wNQpoL0DW8GWpR29qmH0KO9Rs1W5xmEE2PpxUpYhtu/DSVEjp5XNFrDI1Y1i062O RKSGytbyDPfK5Rj73h8z8ki0nZoPMazyzmy7QOWqU7SkuCrjPPue556P910xeRPr 1yWbJtSIB0kcGTDdc8sLBuU0UwDZXHlGDnUOt22OYvjBDhNkudPWtfEpRNKRKI83 NV6ZxFrfBfTVRqsWwXlYXZAOykunr8tUKvxl9e1OsVxnE0XtfeDsY5/PYc0cHjIJ 1QzsBVcgD2gE9p4J1Uux3BvihozIlzkW20qZFDYQ7itkdt5PW6TgHKX1rwpf3mRQ x3sldelX7lva86RweR26+1QJL9syDchYzRWLjOgv4A5JXgXtT7brjEa467A/RiWL qEjPmzXbR149pzlwrFGoHrClCyDf2cn9yQWnmh1w6XeriIkZ8xht0Cc/gAInpSM1 0llXosB9esv3YeV7GULW6d8WfEBl3w6DoBSrcNrh+wbH1WqYgbcNgKGkAYl7GPin EO24qySL8s2aIuv2wmHf73Qk0K2G8krG36fcvjh418y6hZA/r3t12Bp9joH4ChYC OX5j7ZZLONVKyCEd+9Rl4cwPrOndjQ/5CWUKVc8qfzO/zofCPn8= =Mo9F -----END PGP SIGNATURE----- --Apple-Mail=_FFEE8E37-63A7-4300-A201-06237B6CF25A-- From nobody Wed Nov 22 10:51: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 B463A129B45 for ; Wed, 22 Nov 2017 10:51:03 -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_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 mJMEVCpwlmDe for ; Wed, 22 Nov 2017 10:51:02 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 F0762129B4D for ; Wed, 22 Nov 2017 10:51:00 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx18.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eHa6r-0000sI-3U for quic@ietf.org; Wed, 22 Nov 2017 19:50:58 +0100 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eHa6n-0004FF-LI for quic@ietf.org; Wed, 22 Nov 2017 13:50:54 -0500 Received: (qmail 16882 invoked from network); 22 Nov 2017 18:50:52 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.55]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Nov 2017 18:50:52 -0000 To: "quic@ietf.org" From: Christian Huitema Message-ID: Date: Wed, 22 Nov 2017 10:50:47 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: reserved bits for spin bit, etc. X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.49) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5nPkp0WzxZFWSYEse4pYkY4Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fuZpi0zqiZh4VF/D/PZBj7cB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYc8zYOZy1SS6ohN09nxrcu5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XIx4AXarfh1O38bAuuIRigglQLLoevXSDb45gXomrF uMXyXqh7fEZkCDeC36EEW2nGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kA1kWiicstEyxcSXS3gzmQ6EONoJfh+XjGSeeT90H/uIES pBSRMZR7kr9RDUZOaysXh8yc9fWih9YiO+Fc6sG4d2bjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW7i647gVHMYTji4wyoFXFDffFcHV2tQAVqGdj/zM7G/F/kBR/WQICwWa5uPAEZIkV5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 18:51:04 -0000 We cannot quite agree on the spin bit, let alone further management bits. On the other hand, we see that there is clear interest from something like that with at least part of the WG, we want to see some experimentation, and we understand that the specification can proceed independently from the base protocol development. Hence, I would like to make a modest proposal. Can we mark one or possibly two bits as reserved in the first byte of the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be ignored when receiving, MAY be used for experiments between consenting nodes? -- Christian Huitema From nobody Wed Nov 22 11:23: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 2AD17129BA4 for ; Wed, 22 Nov 2017 11:23:06 -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 qDvFNuKVk_QY for ; Wed, 22 Nov 2017 11:23:04 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DFF1129C07 for ; Wed, 22 Nov 2017 11:22:50 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id q13so13737309qtb.5 for ; Wed, 22 Nov 2017 11:22: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; bh=UnstsySVpZV4LZFBKHvOfLh3xHasGzrpeQOFW3HTPNM=; b=HZDMS7QDOQpI4Lt0LDMg8E44NAk0VuNeTHeozjkfpx3ldOQb+nj0/eUbLo6djiIkWh B70EcPcceKlWtJuc+G4aREd5gj7iQiwqdU5IozqJZh7MZFVNTILm8fZvjOEoY9hJKlRU XZtiBScVAH/l/alsXCfZ9FxJq+if4O482na2ULt1Qa9XNikTZabfWq6lZT+gh1fYHhkA 4QMh5zNJIe5RJg/01WaNMZJW3bmAIn7U9j423/f3R9Chcv3EApbtZrhTR7CAGM0MxXw7 dpj4/Z8VGuBU0wwt/UpIfeya+t6Y2BMi/GhlZDh43jfXAjjuD83WyJxnNXTCuXA7yFhG UP7w== 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=UnstsySVpZV4LZFBKHvOfLh3xHasGzrpeQOFW3HTPNM=; b=dCoFTVms7n3FtODxajSKTqR//wI9CucPNfChIKYXteJX6UUzfhAtk6u05duR8OXVx5 QYCuxm7lpqnKnCQi1RXwptf9B/VPI6F1F9IgPJ2NByPB3rsKcIJHRFcjLkryK8FXORXq uVDXDespEI04MEdxLy/jcQsL3rm5ckjZDa4lgenWHsVR+L6Axz/OPL7oG+GT3VKTE8hr NRJajphWZAFpBnZn/AdL4RmLBXkXzqqe6soTjr4eHAmMpVqvjv8f7Sq5wZ3uBwTyLEAW ivrF53TOwwgBqmS44vUAHa02I65h+EjndHvUiXSxCPGQ1fxRtARehPkTPMq9WybE1FyQ XUeA== X-Gm-Message-State: AJaThX4WiHr5Jt5hBg+b+g6DX0fNTmcNPppiwi432dOa1eFhI8NE+wFy HsQdfBpZmuoyJUvE1lLd2ZIA+g2EUomkfFBu+AM= X-Google-Smtp-Source: AGs4zMYo8Lik8m8GByTlmrv+VJp7WIcZNcBkMHwclGind3GKbAjCLVFkL7eJ4TMUHnD1bneanHmg6RDOy5xJzOsjDrc= X-Received: by 10.200.37.253 with SMTP id f58mr31019929qtf.60.1511378568953; Wed, 22 Nov 2017 11:22:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.169 with HTTP; Wed, 22 Nov 2017 11:22:18 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Wed, 22 Nov 2017 11:22:18 -0800 Message-ID: Subject: Re: reserved bits for spin bit, etc. To: Christian Huitema Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a11410d50b94d12055e973e8a" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 19:23:06 -0000 --001a11410d50b94d12055e973e8a Content-Type: text/plain; charset="UTF-8" On Wed, Nov 22, 2017 at 10:50 AM, Christian Huitema wrote: > We cannot quite agree on the spin bit, let alone further management > bits. On the other hand, we see that there is clear interest from > something like that with at least part of the WG, we want to see some > experimentation, and we understand that the specification can proceed > independently from the base protocol development. Hence, I would like to > make a modest proposal. > > Can we mark one or possibly two bits as reserved in the first byte of > the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be > ignored when receiving, MAY be used for experiments between consenting > nodes? > > While I'd personally be happy with reserving some bits for this now, I think marking them as experimental is worse than setting them aside as "reserved" (or whatever the shorthand is for "still under discussion"). If folks start running multiple different experiments across full-path connections, interpreting the data you get will be much harder. Unless there is some way to connect the experiment's semantics with the bit, it seems to make a garbage bit likely. Possibly I am too pessimistic, but that's my initial reaction. Ted > -- Christian Huitema > > > --001a11410d50b94d12055e973e8a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Nov 22, 2017 at 10:50 AM, Christian Huitema <hu= itema@huitema.net> wrote:
We cannot quite agree = on the spin bit, let alone further management
bits. On the other hand, we see that there is clear interest from
something like that with at least part of the WG, we want to see some
experimentation, and we understand that the specification can proceed
independently from the base protocol development. Hence, I would like to make a modest proposal.

Can we mark one or possibly two bits as reserved in the first byte of
the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be
ignored when receiving, MAY be used for experiments between consenting
nodes?


While I'd personally be happy with reserving som= e bits for this now, I think marking them as experimental is worse than set= ting them aside as "reserved" (or whatever the shorthand is for &= quot;still under discussion").=C2=A0 If folks start running multiple d= ifferent experiments across full-path connections, interpreting the data yo= u get will be much harder.=C2=A0 Unless there is some way to connect the ex= periment's semantics with the bit, it seems to make a garbage bit likel= y.

Possibly I am too pessimistic, but that's m= y initial reaction.

Ted


=C2=A0
-- Christian Huitema



--001a11410d50b94d12055e973e8a-- From nobody Wed Nov 22 11:57: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 E95A0129B98 for ; Wed, 22 Nov 2017 11:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 CBs4MCgy121w for ; Wed, 22 Nov 2017 11:57:49 -0800 (PST) Received: from mx144.netapp.com (mx144.netapp.com [IPv6:2620:10a:4005:8000:2306::d]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AA90129B35 for ; Wed, 22 Nov 2017 11:57:49 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,436,1505804400"; d="asc'?scan'208,217";a="228263283" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx144-out.netapp.com with ESMTP; 22 Nov 2017 11:57:48 -0800 Received: from VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 22 Nov 2017 11:57:48 -0800 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS01-PRD.hq.netapp.com (10.122.105.11) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Wed, 22 Nov 2017 11:57:48 -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=+tJPPhhCR+XeRd0+1uf5lurvtGx6Fnu9Ubq6toGJ3pg=; b=cl+VkBiYnAlHXBoM+Am7eJ/PtEE15KFdjGt1iAXKh61AQ0p2+cnsOxfEHTOdwIqIQZZGv3J+UuI6mNp0MrSsNJQnY9AYBf1LLtFz2shZBOSk61Ue82nPkFaOxc6i8LNRoAR1YQCj7K0l14xjfJlIqs9tP07r4FSjPiRi7PpmZ7Y= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 22 Nov 2017 19:57:46 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.004; Wed, 22 Nov 2017 19:57:46 +0000 From: "Eggert, Lars" To: Ted Hardie CC: Christian Huitema , "quic@ietf.org" Subject: Re: reserved bits for spin bit, etc. Thread-Topic: reserved bits for spin bit, etc. Thread-Index: AQHTY8LmMH8TuCBeoUmvfHne6YE6vqMgxuYAgAAJ54A= Date: Wed, 22 Nov 2017 19:57:46 +0000 Message-ID: <2EEF8E08-4C73-454D-9F90-83B8072520B9@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:3614:8001:9424:9b7:6367:85e9] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:lTN4MbhN3nFojvG5n6j2Paq1uPlIEAAoEfU2FH+rB1hNnLBXhHBclGBiz85mV1OHEqokYnmSZCc+CzL0LGR2TQa+XlQg9UPYKeK9ZUzTVJxY/Rs6mIseTFyXbEeGqgC54Idee3OujK7ARhmoGmdA+mFAAWGlKgPIjs4ctTosGQwdTR/1eKmTktVI51ewx6jcQ+inEd+gUampdW6l7uVo4nFZmSdBG0T4iGHt6s/tCVQE4ffI/GFeun46lGfNAsDOfWXIfP0TspFcff4gYqwmnTZslHkacuC/5vkGwku2WijEudbL1xqP/IO6a/MctXSIPQEz3nA7bv85hJBdq7MJMbTutFYgQYEnFwNBiWIZjN4=; 5:O187mXqfB3EGWC8RaPKeWS9lQAgbSUqbXjKLZ8ViZSKs75s4n9we5c7cUcxDkxbViETlzRvZPvbxIBRtm0ihsqy3hR/LFc8PUMqjJy/Za8uSRWfOmLccPMEC/OEqyVOWCTjokBAuCncvNEsS5EyNUb5NJXlGpkinAC1vbNI+J9o=; 24:YyByYhvVmwmD25dJ/m+gQqqySupQYFus7GE3U+skhKH9EQkPxyH4SjZLWTEMfDC6956DKxe4crYgjnI8j4FBNl9PUrjL0/sLKdWguY+QIWU=; 7:3c+Zm1umiLFUkkZo9ocwYzqeVgdqnsxOzsr+pgGftgTA6kzphgSs2EQ7aorZlG94z7SNhngTXpuZ1AdGx1qKoTyMfV2IlK0ciER5nnib37UlaXbRUsmVJbZhxUXQ8HEmgtirDjMMyibdku4JEeF4Gd85cRYfmk7sMrgqKqnsTgzfXQHIXoJCaN4FtMzehrIKsQY4oFq7+4f3LPO1p7t9SFrI8DnzeygVimsb2PFG2NbsUx7o/R/0vMyvARtnetrr x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 812dce3f-0fcd-4ec2-e58a-08d531e34d33 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21532816269658); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3231022)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6055026)(6041248)(20161123562025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:BLUPR06MB1763; x-forefront-prvs: 0499DAF22A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(346002)(377424004)(199003)(189002)(24454002)(54906003)(3660700001)(3280700002)(4001150100001)(316002)(57306001)(86362001)(83716003)(25786009)(2906002)(97736004)(81166006)(6116002)(54896002)(6512007)(81156014)(8676002)(7736002)(6436002)(2900100001)(53546010)(236005)(53936002)(102836003)(39060400002)(76176999)(8936002)(4326008)(50226002)(99936001)(6486002)(68736007)(50986999)(77096006)(106356001)(99286004)(82746002)(229853002)(6246003)(6506006)(33656002)(2950100002)(6916009)(105586002)(14454004)(101416001)(36756003)(5660300001)(189998001)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.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=_B60675D1-D6FB-4948-AF5F-33F2994EE958"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 812dce3f-0fcd-4ec2-e58a-08d531e34d33 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Nov 2017 19:57:46.4439 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 19:57:51 -0000 --Apple-Mail=_B60675D1-D6FB-4948-AF5F-33F2994EE958 Content-Type: multipart/alternative; boundary="Apple-Mail=_8335E7D4-EF72-4206-96E2-C4A319AA3ADA" --Apple-Mail=_8335E7D4-EF72-4206-96E2-C4A319AA3ADA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-11-22, at 20:22, Ted Hardie wrote: >=20 > While I'd personally be happy with reserving some bits for this now, I = think marking them as experimental is worse than setting them aside as = "reserved" (or whatever the shorthand is for "still under discussion"). = If folks start running multiple different experiments across full-path = connections, interpreting the data you get will be much harder. Unless = there is some way to connect the experiment's semantics with the bit, it = seems to make a garbage bit likely. (chair hat off) Agree with Ted. Am OK with reserving, but we'd need to grease them while = they remain reserved, so they remain useable upon assignment. Lars --Apple-Mail=_8335E7D4-EF72-4206-96E2-C4A319AA3ADA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii On = 2017-11-22, at 20:22, Ted Hardie <ted.ietf@gmail.com> wrote:

While I'd personally be happy with reserving some bits for = this now, I think marking them as experimental is worse than setting = them aside as "reserved" (or whatever the shorthand is for "still under = discussion").  If folks start running multiple different = experiments across full-path connections, interpreting the data you get = will be much harder.  Unless there is some way to connect the = experiment's semantics with the bit, it seems to make a garbage bit = likely.

(chair hat off)

Agree with Ted. Am OK with reserving, but we'd need to grease = them while they remain reserved, so they remain useable upon = assignment.

Lars
= --Apple-Mail=_8335E7D4-EF72-4206-96E2-C4A319AA3ADA-- --Apple-Mail=_B60675D1-D6FB-4948-AF5F-33F2994EE958 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloV1rkACgkQVLXDCb9w wVe0ohAAkiONwycib3yvLbEQD/VIhsVcTkV8tvDaMg2uMYcp+nwtjH+nRIZTzhat +YjjeG7L6FrftHLGgFSMfm256EuXHsaFmwg+5dOVvhP/s8Ri4KPghN4Nr8GumdGz wtwl/p6AtmW5lpMgOWJ3XKVMF7lGr0+yszGZj5p22ZX+4UXfe1VMXmcE8cWaMRdW cubkF4Zf8fnxszHhm8juKWFwS12SKst3ldgl5jblGdysUpNX5tJ3k2ne7z0FYt7k CIXd3vixsIf5908P046U34/wcd7k/JgnOZckBfGKDA3r68EsBKTPJwjN0ct13LqC bOZoILCEH/OQHuEODdX/0RXsnllutX8UzurRyfhl7oq9c8aN5HO2RBpk4asnAcI5 l3XAs60lIGNrAOLzsIrMoKWYCotZ53c29IDsaskbCtCF0GgWvCSLbtF+GUfDGRSe Grjsn2iMOzIXSCz99K22jGw86F6nSeZMeCGt6ooMTooXAZe6EYH7r2d0/PchCO5H CzoX//2psPaYQCsoWW7B2wK3lslB9esh4e1FLlzXcDPwVn6wjZudOaXAwA4dIlQ0 L8jFyJ6HKQLoe5UOfBuPIh6Bpjo9epwIl1EzqUsnoF6kzKn92nmfIgkQio6CO2xV 8V4UYu8SsgAbEUmXa0baoiY9NFjSaDkkNdDSQF7zmGnkFXWme+M= =2Slu -----END PGP SIGNATURE----- --Apple-Mail=_B60675D1-D6FB-4948-AF5F-33F2994EE958-- From nobody Wed Nov 22 12:02: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 1391B129B9C for ; Wed, 22 Nov 2017 12:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.997 X-Spam-Level: X-Spam-Status: No, score=-0.997 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9W-w8Si0GCZ for ; Wed, 22 Nov 2017 12:02:01 -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 227E212EB5F for ; Wed, 22 Nov 2017 12:01:27 -0800 (PST) Received: by mail-ua0-x22f.google.com with SMTP id s28so11413020uag.4 for ; Wed, 22 Nov 2017 12:01:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=5Pb/Q/ax79jlGQG7jkyxSBov/Xnv7GZ2ZQDU9xkF/BU=; b=dGxmKi7IH+/pQ5MyPiSZMU05V86Ayn9kpWTw1k5mjsPJ6kJTj1fDuWBqQoff+RKMHR yQ8gMtJaZGYYm/ZLcK0sPS8/nMr4R0R3+RrVj0oHGsi995E7N4Lok91jCc3hPGBMF22U onsOknsbRef1HkFdGkG9Pl/EscmOBSaUf+6oGz9tl2XFR/Cy8q/xo9w/LzMdP+8AASoM 9HIInz9Wy3x6K6dhiqS0tbfy/HSkRtnLvuSW5I7GmBjzha90tzDc9F/jR3Q/rQZtdbqv 1JsULxvWgB4V0e5cA9Oha3ZW5AwjNy1LGBh5l1G+noyK6G718MlYUYgOBVYXH7Pg9jsa 7aqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=5Pb/Q/ax79jlGQG7jkyxSBov/Xnv7GZ2ZQDU9xkF/BU=; b=PpK+icllXDYEHsqutB4f+oTc6vQHKYoJQMfjllgU8a1kBO38hSpTxzPtypx579BFLT MF53xhrUirwZso4fArlL76rorT1j+aXm7x6x0lmlF5yw2CS9pOe8C0tccUmFxA4Rysk2 AakxE9W1vfp02rgAwfXtnr//VWL9ZNdB2m+baCRrSg0pZyx2oBPoykzW1Ew5SsGzzTSL Paig84vRzede39AoXxqwAbu2L4t0farFY1tGTlAhD7rxXOU2/4wqNyy4QyXsRYF7Ow3v QLY+dPxA6LM8RwxH4XKd/eqZjAU3GPI71/434xWCxM3/xOWFwbfXraHXE0Hzo3VjMQIB oDbg== X-Gm-Message-State: AJaThX7bAqw5CRTN6npnR0j7D6M7otFAtqjzChi5Gv36FFKQlenWQN7D jnf7Gj5/Gk0d2HSNFpi0Yv6AtallEOXACy5tumM= X-Google-Smtp-Source: AGs4zMb6jCNjdd9r0aRqs46dK0J8WoeDSK4b2ISn3e+HQsRIi6oHA6pnhNDgj1O4fMbJWlH1Ca7lWfPLIqCoQxUkB1M= X-Received: by 10.176.7.5 with SMTP id h5mr5368331uah.141.1511380885945; Wed, 22 Nov 2017 12:01:25 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 22 Nov 2017 15:01:24 -0500 From: Marten Seemann In-Reply-To: References: X-Mailer: Airmail (461) MIME-Version: 1.0 Date: Wed, 22 Nov 2017 15:01:24 -0500 Message-ID: Subject: Re: reserved bits for spin bit, etc. To: Ted Hardie , Christian Huitema Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c123fa4d3c1f9055e97c861" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 20:02:02 -0000 --94eb2c123fa4d3c1f9055e97c861 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I like the idea to get some real-world data on the impact of exposing further information. The problem with reserving a couple of bits in the packet header for this purpose is that it=E2=80=99s not sufficient for the = two end points to agree on the meaning of those bits, the middle boxes must be aware of it as well. Maybe I=E2=80=99m missing an option here, but it seems that in order to per= form such an experiment, both endpoints as well as the middle boxes have to be controlled by the same operator. In this case, it wouldn=E2=80=99t be neces= sary to reserve any bits, since the end points are free to expose additional information in any way they see fit. On 22. November 2017 at 11:23:09, Ted Hardie (ted.ietf@gmail.com) wrote: On Wed, Nov 22, 2017 at 10:50 AM, Christian Huitema wrote: > We cannot quite agree on the spin bit, let alone further management > bits. On the other hand, we see that there is clear interest from > something like that with at least part of the WG, we want to see some > experimentation, and we understand that the specification can proceed > independently from the base protocol development. Hence, I would like to > make a modest proposal. > > Can we mark one or possibly two bits as reserved in the first byte of > the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be > ignored when receiving, MAY be used for experiments between consenting > nodes? > > While I'd personally be happy with reserving some bits for this now, I think marking them as experimental is worse than setting them aside as "reserved" (or whatever the shorthand is for "still under discussion"). If folks start running multiple different experiments across full-path connections, interpreting the data you get will be much harder. Unless there is some way to connect the experiment's semantics with the bit, it seems to make a garbage bit likely. Possibly I am too pessimistic, but that's my initial reaction. Ted > -- Christian Huitema > > > --94eb2c123fa4d3c1f9055e97c861 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I like the idea to g= et some real-world data on the impact of exposing further information. The = problem with reserving a couple of bits in the packet header for this purpo= se is that it=E2=80=99s not sufficient for the two end points to agree on t= he meaning of those bits, the middle boxes must be aware of it as well.
Maybe I=E2=80=99= m missing an option here, but it seems that in order to perform such an exp= eriment, both endpoints as well as the middle boxes have to be controlled b= y the same operator. In this case, it wouldn=E2=80=99t be necessary to rese= rve any bits, since the end points are free to expose additional informatio= n in any way they see fit.


On 22. Novemb= er 2017 at 11:23:09, Ted Hardie (ted.= ietf@gmail.com) wrote:

On Wed, Nov 22, 2017 at 10:50 AM, Christian Huitema <huitema@huitema.net> wrote:
We cannot quite agree on the spin bit, let alone further management
bits. On the other hand, we see that there is clear interest from
something like that with at least part of the WG, we want to see some
experimentation, and we understand that the specification can proceed
independently from the base protocol development. Hence, I would like to
make a modest proposal.

Can we mark one or possibly two bits as reserved in the first byte of
the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be
ignored when receiving, MAY be used for experiments between consenting
nodes?


While I'd personally be happy with reserving some bits for this now, I think marking them as experimental is worse than setting them aside as "reserved" (or whatever the shorthand is fo= r "still under discussion").=C2=A0 If folks start running multiple different experiments across full-path connections, interpreting the data you get will be much harder.=C2=A0 Unless there is some way to connect the experiment's semantics with the bit, it seems to make a garbage bit likely.

Possibly I am too pessimistic, but that's my initial reaction.

Ted


=C2=A0
-- Christian Huitema



--94eb2c123fa4d3c1f9055e97c861-- From nobody Wed Nov 22 14:51: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 03095129510 for ; Wed, 22 Nov 2017 14:51:23 -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 KSAj5A3KNJ4v for ; Wed, 22 Nov 2017 14:51:21 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AFAB126D05 for ; Wed, 22 Nov 2017 14:51:21 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id h6so12012834oia.10 for ; Wed, 22 Nov 2017 14:51: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=t6szp1i9bSOrXZ544KjbxQm09qsWv5iqOO58ONbZgrw=; b=K08nYakFtJNDF7T1NlSGiITI4YQASRJGbnbP56WhAmYPVl5fHgjoI+7elvCk24bNE1 fmluquHF7lCsQiW/3YgR2n2rB+KxzPPVECMnAB021VfRR/C6i2rkrv/7KejEBPObIRBr gGDvXI3Jsilv0CX5Y9/NKnN/k2gCvGP6iOPR7Ny/svmLxWNWzboT4vKzE5Z3i4GWGteD k6Dz3OMmvuoQ86F2rX9jGNIcs5wZC+Ld+bO9v4EF3Wb44Hk7MZCE1Yb2lFKYDWh5UDGA dZPLUzUdd+yDn8qi/ZfjhJRY0wnJlc1gxk8mk5e3MKCLi6CR4qYo/cwssDD5I8bHOQgm XZ6A== 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=t6szp1i9bSOrXZ544KjbxQm09qsWv5iqOO58ONbZgrw=; b=Y1m0h7Oybp0KRFrcO4BSK4PZgpENa/bjYDvBJYwsXg8oKGz6bHMMQJRuynDX+6ZNN7 ILUZgJ7wzo1VewpE8+I4+HGCubhWxEvYGtwiVH9jTIisqdX5Y7aaqtKUyux61vd12jJy mB6lHqID28WNhawM0OEb7L6c10tEffn1L/Rr9A7d4UrXSKqcHFp4gJ4ZKBsdHrzqfd6O wr1OmgTYSmMU5xo/HEbAz1UbBvbkJXJtaaQT3lVuv46YjY7ZiTBCoKuKiOEQBOaqtgvN MoogpOWM4+eI64je8gseHq8DAzwfi7mdPEHoiiTFJ4jzesH7ji4Zx643U//aDwo52PXg UZWQ== X-Gm-Message-State: AJaThX7/U8oG6X+jHXmdSXhmfoxh3WN3A9M7MJ+4r4j59/H0bNUsV9kr yBUJM5ErlNFAL4yunCy9ezgWCZBZFKDm2890HcTZgw== X-Google-Smtp-Source: AGs4zMZ7GDFBjz4QlL7Nz/Mmc9X+oIlrfmxsbnL70/dpmkAQ58IRkfhQ0y3Vvq+Avei9WryI/g4QEwYMAtsdeXiL/VI= X-Received: by 10.202.166.206 with SMTP id t75mr5169871oij.28.1511391080598; Wed, 22 Nov 2017 14:51:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Wed, 22 Nov 2017 14:51:19 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 23 Nov 2017 09:51:19 +1100 Message-ID: Subject: Re: reserved bits for spin bit, etc. To: Christian Huitema Cc: "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 22:51:23 -0000 Would you propose making this reservation in QUICv1 or QUICvAll? On Thu, Nov 23, 2017 at 5:50 AM, Christian Huitema wrote: > We cannot quite agree on the spin bit, let alone further management > bits. On the other hand, we see that there is clear interest from > something like that with at least part of the WG, we want to see some > experimentation, and we understand that the specification can proceed > independently from the base protocol development. Hence, I would like to > make a modest proposal. > > Can we mark one or possibly two bits as reserved in the first byte of > the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be > ignored when receiving, MAY be used for experiments between consenting > nodes? > > -- Christian Huitema > > From nobody Wed Nov 22 16:13: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 B405F12704A for ; Wed, 22 Nov 2017 16:13:45 -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, 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 2vPrIc3T9_v2 for ; Wed, 22 Nov 2017 16:13:44 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 E0FC1126B6E for ; Wed, 22 Nov 2017 16:13:43 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx44.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eHf9B-0000Cl-6t for quic@ietf.org; Thu, 23 Nov 2017 01:13:41 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eHf94-00064s-Q4 for quic@ietf.org; Wed, 22 Nov 2017 19:13:38 -0500 Received: (qmail 20765 invoked from network); 23 Nov 2017 00:13:34 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.55]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Nov 2017 00:13:33 -0000 To: Martin Thomson Cc: "quic@ietf.org" References: From: Christian Huitema Message-ID: <18c32623-343f-ac12-9167-a68eb3fb8fc3@huitema.net> Date: Wed, 22 Nov 2017 16:13:28 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: reserved bits for spin bit, etc. X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5v8ChyMMhjaH0fWhnDl3CQgXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftHSiafiFnFwCViC0CwvxtuB98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUzVo6xqsY8KGF50vY/LmgeTZsQEbaxxISMHgJxrdMdSS+C+me6dA6yBk+me OMe0W22n/kFi61SvDQh5XsjlapMvoZNAifNUgo2DcM4YtKVx9MMCOkgYBX58rqmjkeHDbS4kHaox hC4vjXqQZhHVp33bdA4PSvr8BodmIS11My0yWMx0Hcdm1lHSqdVK8QtbVazR2PDNKbWhLn7g2aSz CwEE5YE5enyccp7RH4WQio3uGTAwyjhRzXq9E3eaUXDCvLdWBb39uS1TjWG2Inx+Ts2Q6HPPLuOV zXiNlBYhGfdaOhRAKfWK48mqxd1pWN6R4o3z50cmrxk2XyWyKbYaN8YjUu+PlL2Pwe+CIbwUumpf R/1pKmzs+I20BPr8KEuylTNz1M+AgIIvNSTpo/jx+MlpdfaR8ARqVa5tfm0ESx08oKIkIws8xgO4 5Qj9Q/+VAExAvw//PryZ890QnJdejDmLZa0NFKy/WAnCjPUBzcK/M/MvRmuYgpnSRSLwxCW/qSml FrMZ4EPj24bdhPGwUMEhSj5AXD+LZeOcwmj8dr5+uBxwEiTVJqDh0qKoKsXx5lkGdpGDA4fhZ99L JYm63JqjgYKYztFCTu1V7xd99RWj3yhpindLe2+BHTMlUatSCe6F9RF3R7hA9cWKnIAta1ssvpdo GFJ6qBcRWcjN493Nswe97YSKSwCH1H5zy9BQrsIhEWyJzIkwSFAW0Pw8uiKeojllUucwQGx22nUH XOWsr7LBAEPzQAx6vR2vefJRFpjWYvRUw8toG6ja2PgsuUGm X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 00:13:46 -0000 On 11/22/2017 2:51 PM, Martin Thomson wrote: > Would you propose making this reservation in QUICv1 or QUICvAll? Do you mean, just for the current version, or invariant across all versions? My idea is to reserve them for the current version. If the experiments let us firmly conclude one way or the other by the time we publish V1, the bits will cease to be reserved, and will have an explicit specification instead. In any case, "reserved" means that it is available for use in a further version. -- Christian Huitema > > On Thu, Nov 23, 2017 at 5:50 AM, Christian Huitema wrote: >> We cannot quite agree on the spin bit, let alone further management >> bits. On the other hand, we see that there is clear interest from >> something like that with at least part of the WG, we want to see some >> experimentation, and we understand that the specification can proceed >> independently from the base protocol development. Hence, I would like to >> make a modest proposal. >> >> Can we mark one or possibly two bits as reserved in the first byte of >> the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be >> ignored when receiving, MAY be used for experiments between consenting >> nodes? >> >> -- Christian Huitema >> >> From nobody Wed Nov 22 16:16: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 5948B126C22 for ; Wed, 22 Nov 2017 16:16:13 -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, HTML_MESSAGE=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 PUcMKTypa0o4 for ; Wed, 22 Nov 2017 16:16:12 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 50219126B6E for ; Wed, 22 Nov 2017 16:16:12 -0800 (PST) Received: from xsmtp31.mail2web.com ([168.144.250.234] helo=xsmtp11.mail2web.com) by mx42.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eHfBa-00034u-83 for quic@ietf.org; Thu, 23 Nov 2017 01:16:10 +0100 Received: from [10.5.2.18] (helo=xmail08.myhosting.com) by xsmtp11.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eHfBX-0001k6-5Y for quic@ietf.org; Wed, 22 Nov 2017 19:16:07 -0500 Received: (qmail 571 invoked from network); 23 Nov 2017 00:16:05 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.55]) (envelope-sender ) by xmail08.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Nov 2017 00:16:04 -0000 To: "Eggert, Lars" , Ted Hardie Cc: "quic@ietf.org" References: <2EEF8E08-4C73-454D-9F90-83B8072520B9@netapp.com> From: Christian Huitema Message-ID: Date: Wed, 22 Nov 2017 16:15:51 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <2EEF8E08-4C73-454D-9F90-83B8072520B9@netapp.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="UrpFaF2WfLjo568MnsMJReRHCbHdFqi1G" Subject: Re: reserved bits for spin bit, etc. X-Originating-IP: 168.144.250.234 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: ham X-AntiSpamCloud-Outgoing-Evidence: Combined (0.04) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5mEjMcyw+gU+GzJX2UlRdD4Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ft1eMePdA0TuFAEaxZk6HQzB98yDTitFWvbHwz9vKZpmxBf ggn8Frespz1KxArpwUx851TaRAUkTN+SrghOjOYzZsQEbaxxISMHgJxrdMdSS+C+me6dA6yBk+me OMe0W22n/kFi61SvDQh5XsjlapMvoZNAifNUgo2DcM4YtKVx9MMCOkgYBX58rqmjkeHDbS4kHaox hC4vjXqQZhHVp33bdA4PSvr8BodmIS11My0yWMx0Hcdm1lHSqdVK8QtbVazR2PDNKbWhLn7g2aSz CwEE5YE5enyccp7RH4WQio3uGTAwyjhRzXq9E3eaUXDCvLdWBb39uS1TjWG2Inx+Ts2Q6HPPLuOV zXiNlBYhGfdaOhRAKfWK48mqxd1pWN6R4o3z50cmrxk2XyWyKbYaN8Yj6/Krl85w35zL7LX2ZGXh b8JTlR3yQ34Fcld1+mzauC5fiXEzp8itLnrce8EbVulxdfaR8ARqVa5tfm0ESx08oKIkIws8xgO4 5Qj9Q/+VAExAvw//PryZ890QnJdejDmLZa0NFKy/WAnCjPUBzcK/M3/MCYJ2LkstpnQfuYJ0Y9Gl FrMZ4EPj24bdhPGwUMEhXz9h5i3OECdV6ydDYlgzdRxwEiTVJqDh0qKoKsXx5lkGdpGDA4fhZ99L JYm63JqjRbjaLCLwRU9ZCJtMwQAWdChpindLe2+BHTMlUatSCe60BV1cz9f00p8Iue/Bb/j6vpdo GFJ6qBcRWcjN493Nswe97YSKSwCH1H5zy9BQrsIhEWyJzIkwSFAW0Pw8uiKeojllUucwQGx22nUH XOWsr7LBAEPzQAx6vR2vefJRFpjWYvRUw8toG6ja2PgsuUGm X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 00:16:13 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --UrpFaF2WfLjo568MnsMJReRHCbHdFqi1G Content-Type: multipart/mixed; boundary="TploVsh5lmCvTSbEiBbCe3RxktLuRCOxN"; protected-headers="v1" From: Christian Huitema To: "Eggert, Lars" , Ted Hardie Cc: "quic@ietf.org" Message-ID: Subject: Re: reserved bits for spin bit, etc. References: <2EEF8E08-4C73-454D-9F90-83B8072520B9@netapp.com> In-Reply-To: <2EEF8E08-4C73-454D-9F90-83B8072520B9@netapp.com> --TploVsh5lmCvTSbEiBbCe3RxktLuRCOxN Content-Type: multipart/alternative; boundary="------------E04537B292A0FFF1DC8D08A6" Content-Language: en-US This is a multi-part message in MIME format. --------------E04537B292A0FFF1DC8D08A6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/22/2017 11:57 AM, Eggert, Lars wrote: > On 2017-11-22, at 20:22, Ted Hardie > wrote: >> >> While I'd personally be happy with reserving some bits for this now, >> I think marking them as experimental is worse than setting them aside >> as "reserved" (or whatever the shorthand is for "still under >> discussion").=A0 If folks start running multiple different experiments= >> across full-path connections, interpreting the data you get will be >> much harder.=A0 Unless there is some way to connect the experiment's >> semantics with the bit, it seems to make a garbage bit likely. > > (chair hat off) > > Agree with Ted. Am OK with reserving, but we'd need to grease them > while they remain reserved, so they remain useable upon assignment. Fair point. So the first bit should be defined as "reserved for the spin bit experiment". The second bit, if we decide to have a second one, should be strictly designed as "reserved" for now. -- Christian Huitema --------------E04537B292A0FFF1DC8D08A6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

On 11/22/2017 11:57 AM, Eggert, Lars wrote:

On 2017-11-22, at 20:22, Ted Hardie <ted.ietf@gmail.com> wrote:

While I'd personally be happy with reserving some bits for this now, I think marking them as experimental is worse than setting them aside as "reserved" (or whatever the shorthand is for "still under discussion").=A0 If folks start running multiple different experiments across full-path connections, interpreting the data you get will be much harder.=A0 Unless there is some way to connect the experiment's semantics with the bit, it seems to make a garbage bit likely.

(chair hat off)

Agree with Ted. Am OK with reserving, but we'd need= to grease them while they remain reserved, so they remain useable upon assignment.

Fair point. So the first bit should be defined as "reserved for the spin bit experiment". The second bit, if we decide to have a second one, should be strictly designed as "reserved" for now.

-- Christian Huitema
--------------E04537B292A0FFF1DC8D08A6-- --TploVsh5lmCvTSbEiBbCe3RxktLuRCOxN-- --UrpFaF2WfLjo568MnsMJReRHCbHdFqi1G Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJaFhM/AAoJELba05IUOHVQ+MsH/208yrERA2vHkmzZ4UN8ZwvK nRuS0OQX+eYeCpftlW7WPLaVgrWlZJYIeaMp49nPcdpbNPkAVxlZ/BAMh5iiva88 ga4SrHXc0Q4TQ3kZ5HfgBHzlHFj+lhT3fA7ZCdL/XUfHDIct8k7eNBw+hhkXY9wd ADVgmbyB7+RGNEx3UYVOhQC5c549MEwmJw8B+IydzfchM0aZmM8FXQ9tSrv1bp2i +RfM4OsW7Inoum0rinLpI7mn6jj6xLkFNyOjyVLBdOS3pB/hWUX3srEJZQYH8X2Q lw89uK2l+s6XFN2X290OJm8yRD6TIuA7Ayt48uK+Z8aTxzSgqnucHwEgupTCTtg= =ZzaE -----END PGP SIGNATURE----- --UrpFaF2WfLjo568MnsMJReRHCbHdFqi1G-- From nobody Wed Nov 22 16:22: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 437A7126C22 for ; Wed, 22 Nov 2017 16:22:12 -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_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 1gurLCQi6_ge for ; Wed, 22 Nov 2017 16:22:11 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 206CD126B6E for ; Wed, 22 Nov 2017 16:22:11 -0800 (PST) Received: from xsmtp05.mail2web.com ([168.144.250.245]) by mx1.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eHfHM-0003Uq-C9 for quic@ietf.org; Thu, 23 Nov 2017 01:22:09 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp05.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eHfHJ-0006kC-6L for quic@ietf.org; Wed, 22 Nov 2017 19:22:05 -0500 Received: (qmail 31701 invoked from network); 23 Nov 2017 00:22:04 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.55]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Nov 2017 00:22:03 -0000 To: "quic@ietf.org" From: Christian Huitema Message-ID: <00728e49-b01f-5a82-6616-976dd97bdb10@huitema.net> Date: Wed, 22 Nov 2017 16:21:58 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Multi-homed server X-Originating-IP: 168.144.250.245 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.35) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5m98SmL+4xxthCU44zYgtM8Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59furL+2terxgnU5RQIV1lkjXB98yDTitFWvbHwz9vKZpm3I5 mq5AFk9iXeoOoZGPBgSZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyZFjIToX6GLbbHCBsyyfoCLFQwbgMCItJaYYOhQRv6/ UCGqo/R9e8g7aiTdDzHYmQvh9PobrbwB1Jj4vRnvuFdQKx3Zprq3ZEpafGy+zLjUntilh9dvYvV/ 5Pg3UZt3l4cobM5+AwD0A5qDgSPsXJ3GtlU9Sx4c4OycrwO9wG8u65nHEeB4hpRrmo/duzUUp/Jj s8OSZ4uKCsT0S3SoR01s0FYWZxDrledaP8Grb+7ozHLYM3A6BXfvel8OEFDbU529jj6VuEkkQiOd 2CLFCAI+I5H9kml+5WbFWXP46fIup4j2lB9TLiDMfXuvSrucRXqq613YX/JpkaqfAljBKlD3psib JQz6bCR19sO/++nnSqCDBedeB75TJ0VuxRY+unEnaeycva4NRXu2m3j3Y8zB9xGo0bndvIE+SDBs cm+vLiZuZ5OAUoGBziSYFLZuu6wTRhJez+ibxiREoUwadL3g X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 00:22:12 -0000 Many servers are multi-homed, can get packets from multiple addresses. What should happen if a server gets an initial packet delivered on address A, and later some packets delivered on address B? -- Christian Huitema From nobody Wed Nov 22 22:08: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 4845A120721 for ; Wed, 22 Nov 2017 22:08:54 -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, 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 Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iVoyldql9Tpj for ; Wed, 22 Nov 2017 22:08:52 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285DC1205F1 for ; Wed, 22 Nov 2017 22:08:52 -0800 (PST) Received: from LHREML713-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 7D2CBFE76EA61; Thu, 23 Nov 2017 06:08:48 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 23 Nov 2017 06:08:49 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.96]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0361.001; Thu, 23 Nov 2017 14:08:41 +0800 From: Roni Even To: Marcus Ihlar , "Eggert, Lars" CC: Salvatore Loreto , Brian Trammell , QUIC WG , Mark Nottingham Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAAyYACAAAWjAIAAD76AgAAGt4CAAAd2gIAACAKA//+MgQCAAXOuAA== Date: Thu, 23 Nov 2017 06:08:41 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8464B8@DGGEMM506-MBX.china.huawei.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> <9F6AAAF0-02BE-4538-8D4A-1C5B58841104@netapp.com> <6E58094ECC8D8344914996DAD28F1CCD8461C0@DGGEMM506-MBX.china.huawei.com> <6FA87C43-D639-4700-9B97-5901237BA5F1@ericsson.com> In-Reply-To: <6FA87C43-D639-4700-9B97-5901237BA5F1@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD8464B8DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:08:54 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD8464B8DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpJIHdpbGwgd29yayB3aXRoIEJyaWFuIGFuZCBNYXJjdXMgb24gdGhpcyBkcmFmdA0KUm9u aQ0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgTWFyY3VzIElobGFyDQpTZW50OiDXmdeV150g15MgMjIg16DXldeR157XkdeoIDIwMTcgMTc6 NTgNClRvOiBFZ2dlcnQsIExhcnMNCkNjOiBTYWx2YXRvcmUgTG9yZXRvOyBCcmlhbiBUcmFtbWVs bDsgUm9uaSBFdmVuOyBRVUlDIFdHOyBNYXJrIE5vdHRpbmdoYW0NClN1YmplY3Q6IFJlOiBTcGlu IGJpdCBkaXNjdXNzaW9uIC0gd2hlcmUgd2UncmUgYXQNCg0KSGksDQpKdXN0IGNoaXBwaW5nIGlu IHRvIHNheSB0aGF0IEnigJltIGhhcHB5IHRvIHdvcmsgd2l0aCBCcmlhbiBvbiB0aGlzIGRyYWZ0 Lg0KDQovTWFyY3VzDQoNCk9uIDIyIE5vdiAyMDE3LCBhdCAyMjo1MSwgRWdnZXJ0LCBMYXJzIDxs YXJzQG5ldGFwcC5jb208bWFpbHRvOmxhcnNAbmV0YXBwLmNvbT4+IHdyb3RlOg0KSGksDQoNCk9u IDIwMTctMTEtMjIsIGF0IDE1OjIyLCBSb25pIEV2ZW4gPHJvbmkuZXZlbkBodWF3ZWkuY29tPG1h aWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KSSB0aGluayB0aGUgZGVjaXNpb24g dG8gbm90IGRpc2N1c3MgaXQgYXQgdGhlIGludGVyaW0gaXMgYmFzZWQgb24gdGhlIG9ic2VydmF0 aW9uDQp0aGF0IHRoZSByZWdpc3RlcmVkIGF0dGVuZGVlcyBhdCB0aGUgaW50ZXJpbSBhcmUgcHJv YmFibHkgbm90IHJlcHJlc2VudGF0aXZlDQpvZiB0aGUgb3ZlcmFsbCBXRyBjb25zdGl0dWVuY3kg LSB3ZSB3YW50IHRvIGdpdmUgYWxsIHNpZGVzIGFuIGFiaWxpdHkgdG8NCnBhcnRpY2lwYXRlIGVx dWFsbHkgaW4gdGhlIGRpc2N1c3Npb24uDQpbUm9uaSBFdmVuXSBUaGlzIGlzIHdoeSB3ZSBoYXZl IHJlbW90ZSBwYXJ0aWNpcGFudHMgYXQgSUVURiBtZWV0aW5ncyAhISEhISEhIQ0KWW91IGRvIG5v dCBoYXZlIHRvIGJlIGluIHBlcnNvbiB0byBkaXNjdXNzISEhIQ0KDQp0aGUgSUVURiAodmllIE1l ZXRFY2hvKSBwcm92aWRlcyByZW1vdGUgcGFydGljaXBhdGlvbiBhdCB0aGUgbWFpbiBtZWV0aW5n cy4gQXQgdGhlIGludGVyaW1zLCBpdCdzIE1hcmsuIEl0IHNlZW1zIHRvIGhhdmUgbW9zdGx5IHdv cmtlZCBPSyBmb3IgcGFzc2l2ZSBwYXJ0aWNpcGF0aW9uIGR1cmluZyB0d28gb3V0IG9mIHRoZSBs YXN0IHRocmVlIGludGVyaW1zLCBidXQgd2UgaGF2ZW4ndCB0cmllZCB0byBob2xkIGEgZGlzY3Vz c2lvbiB3aXRoIG1hbnkgYWN0aXZlIHJlbW90ZSBwYXJ0aWNpcGFudHMuDQoNCg0KSSB0aGluayB3 aGF0IE1hcmsgdHJpZWQgdG8gZXhwcmVzcyBpcyB0aGF0IHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBT cGluIEJpdCBjYW4gYmUNCm1vc3RseSBkZWNvdXBsZWQgZnJvbSB0aGUgKGxhcmdlIGFtb3VudCBv Zikgd29yayByZW1haW5pbmcgb24gdGhlIGJhc2UNCnNwZWMuIFRoYXQgaXMsIHdlIGRvbid0IGhh dmUgdG8gY29uY2x1ZGUgdGhlIFNwaW4gQml0IGRpc2N1c3Npb24gc2lnbmlmaWNhbnRseQ0KcHJp b3IgdG8gdGhlIGNvbmNsdXNpb24gb2YgdGhlIG92ZXJhbGwgd29yayAoYWx0aG91Z2ggd2UgY2Fu KSwgc2luY2UgaXQgc2hvdWxkDQpiZSBlYXN5IHRvIG1lcmdlIGF0IHRoZSBsYXRlciBzdGFnZXMg YmVmb3JlIGhhbmRpbmcgdGhpbmdzIHRvIHRoZSBJRVNHLg0KW1JvbmkgRXZlbl0gZGVsYXlpbmcg dGhlIGRpc2N1c3Npb24gbWF5IHByZXZlbnQgdGhlIGFjY2VwdGFuY2UuICBJZiBwZW9wbGUgd2ls bCBwdXQgZWZmb3J0IGF0IHN1Ym1pdHRpbmcgdGV4dCB0aGVuIHRoZSBjaGFpcnMgc2hvdWxkIGFs bG93IGZvciBkaXNjdXNzaW9uIGFuZCBub3QgZGVsYXkgdGhlIHdvcmsuDQoNCkkgZGlzYWdyZWUg d2l0aCB0aGlzIGNoYXJhY3Rlcml6YXRpb24uDQoNCldoYXQgSSBzYWlkIGFib3ZlIGluIHRoZSBw YXJhZ3JhcGggeW91IHF1b3RlIGlzIHRoYXQgd2UgZG8gbm90ICpoYXZlIHRvKiBjb25jbHVkZSB0 aGUgU3BpbiBCaXQgZGlzY3Vzc2lvbiB1cmdlbnRseSAqYWx0aG91Z2ggd2UgY2FuKi4gU3BlY2lm aWNhbGx5LCB3ZSBjYW4gYmVnaW4gKGFuZCBjb25jbHVkZSkgdGhlIGRpc2N1c3Npb24gb25jZSB0 aGVyZSBpcyBhbiBhY3R1YWwgcHJvcG9zYWwgdGhhdCBhZGRyZXNzZXMgd2hhdCBNYXJrJ3Mgb3Jp Z2luYWwgZW1haWwgb3V0bGluZWQuDQoNCkxhcnMNCg== --_000_6E58094ECC8D8344914996DAD28F1CCD8464B8DGGEMM506MBXchina_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXI7DQoJcGFub3NlLTE6MCAwIDAg MCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5h cHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNw YWNlO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNp emU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsN CgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3ht bD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6 ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBl bGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxp bms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0 OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSB3aWxsIHdvcmsgd2l0aCBC cmlhbiBhbmQgTWFyY3VzIG9uIHRoaXMgZHJhZnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+Um9uaTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss JnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVl IDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBj bSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBRVUlD IFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NYXJj dXMgSWhsYXI8YnI+DQo8Yj5TZW50OjwvYj4gPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV 150mbmJzcDvXkyAyMiDXoNeV15HXnteR16ggMjAxNyAxNzo1ODwvc3Bhbj48YnI+DQo8Yj5Ubzo8 L2I+IEVnZ2VydCwgTGFyczxicj4NCjxiPkNjOjwvYj4gU2FsdmF0b3JlIExvcmV0bzsgQnJpYW4g VHJhbW1lbGw7IFJvbmkgRXZlbjsgUVVJQyBXRzsgTWFyayBOb3R0aW5naGFtPGJyPg0KPGI+U3Vi amVjdDo8L2I+IFJlOiBTcGluIGJpdCBkaXNjdXNzaW9uIC0gd2hlcmUgd2UncmUgYXQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IaSw8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5KdXN0IGNoaXBwaW5nIGluIHRvIHNheSB0 aGF0IEnigJltIGhhcHB5IHRvIHdvcmsgd2l0aCBCcmlhbiBvbiB0aGlzIGRyYWZ0Ljxicj4NCjxi cj4NCi9NYXJjdXM8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCk9uIDIyIE5vdiAyMDE3LCBhdCAyMjo1 MSwgRWdnZXJ0LCBMYXJzICZsdDs8YSBocmVmPSJtYWlsdG86bGFyc0BuZXRhcHAuY29tIj5sYXJz QG5ldGFwcC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiAyMDE3LTExLTIyLCBhdCAxNToyMiwgUm9uaSBFdmVuICZsdDs8 YSBocmVmPSJtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20iPnJvbmkuZXZlbkBodWF3ZWkuY29t PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtmb250LXZhcmlh bnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1 dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lk dGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90 OywmcXVvdDtzZXJpZiZxdW90OyI+SSB0aGluayB0aGUgZGVjaXNpb24gdG8gbm90IGRpc2N1c3Mg aXQgYXQgdGhlIGludGVyaW0gaXMgYmFzZWQgb24gdGhlIG9ic2VydmF0aW9uPGJyPg0KdGhhdCB0 aGUgcmVnaXN0ZXJlZCBhdHRlbmRlZXMgYXQgdGhlIGludGVyaW0gYXJlIHByb2JhYmx5IG5vdCBy ZXByZXNlbnRhdGl2ZTxicj4NCm9mIHRoZSBvdmVyYWxsIFdHIGNvbnN0aXR1ZW5jeSAtIHdlIHdh bnQgdG8gZ2l2ZSBhbGwgc2lkZXMgYW4gYWJpbGl0eSB0bzxicj4NCnBhcnRpY2lwYXRlIGVxdWFs bHkgaW4gdGhlIGRpc2N1c3Npb24uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5bUm9u aSBFdmVuXSBUaGlzIGlzIHdoeSB3ZSBoYXZlIHJlbW90ZSBwYXJ0aWNpcGFudHMgYXQgSUVURiBt ZWV0aW5ncyAhISEhISEhITxicj4NCllvdSBkbyBub3QgaGF2ZSB0byBiZSBpbiBwZXJzb24gdG8g ZGlzY3VzcyEhISE8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZSBJRVRGICh2aWUgTWVldEVjaG8pIHBy b3ZpZGVzIHJlbW90ZSBwYXJ0aWNpcGF0aW9uIGF0IHRoZSBtYWluIG1lZXRpbmdzLiBBdCB0aGUg aW50ZXJpbXMsIGl0J3MgTWFyay4gSXQgc2VlbXMgdG8gaGF2ZSBtb3N0bHkgd29ya2VkIE9LIGZv ciBwYXNzaXZlIHBhcnRpY2lwYXRpb24gZHVyaW5nIHR3byBvdXQgb2YgdGhlIGxhc3QgdGhyZWUg aW50ZXJpbXMsIGJ1dCB3ZSBoYXZlbid0IHRyaWVkIHRvIGhvbGQNCiBhIGRpc2N1c3Npb24gd2l0 aCBtYW55IGFjdGl2ZSByZW1vdGUgcGFydGljaXBhbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0 O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTomcXVvdDtNZW5sby1S ZWd1bGFyJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7Ij5JIHRoaW5rIHdoYXQgTWFyayB0cmllZCB0 byBleHByZXNzIGlzIHRoYXQgdGhlIGRpc2N1c3Npb24gb24gdGhlIFNwaW4gQml0IGNhbiBiZTxi cj4NCm1vc3RseSBkZWNvdXBsZWQgZnJvbSB0aGUgKGxhcmdlIGFtb3VudCBvZikgd29yayByZW1h aW5pbmcgb24gdGhlIGJhc2U8YnI+DQpzcGVjLiBUaGF0IGlzLCB3ZSBkb24ndCBoYXZlIHRvIGNv bmNsdWRlIHRoZSBTcGluIEJpdCBkaXNjdXNzaW9uIHNpZ25pZmljYW50bHk8YnI+DQpwcmlvciB0 byB0aGUgY29uY2x1c2lvbiBvZiB0aGUgb3ZlcmFsbCB3b3JrIChhbHRob3VnaCB3ZSBjYW4pLCBz aW5jZSBpdCBzaG91bGQ8YnI+DQpiZSBlYXN5IHRvIG1lcmdlIGF0IHRoZSBsYXRlciBzdGFnZXMg YmVmb3JlIGhhbmRpbmcgdGhpbmdzIHRvIHRoZSBJRVNHLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OywmcXVvdDtzZXJp ZiZxdW90OyI+W1JvbmkgRXZlbl0gZGVsYXlpbmcgdGhlIGRpc2N1c3Npb24gbWF5IHByZXZlbnQg dGhlIGFjY2VwdGFuY2UuICZuYnNwO0lmIHBlb3BsZSB3aWxsIHB1dCBlZmZvcnQgYXQgc3VibWl0 dGluZyB0ZXh0IHRoZW4gdGhlIGNoYWlycyBzaG91bGQgYWxsb3cgZm9yIGRpc2N1c3Npb24gYW5k IG5vdCBkZWxheSB0aGUNCiB3b3JrLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRpc2FncmVlIHdpdGggdGhpcyBjaGFyYWN0ZXJpemF0aW9u LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5X aGF0IEkgc2FpZCBhYm92ZSBpbiB0aGUgcGFyYWdyYXBoIHlvdSBxdW90ZSBpcyB0aGF0IHdlIGRv IG5vdCAqaGF2ZSB0byogY29uY2x1ZGUgdGhlIFNwaW4gQml0IGRpc2N1c3Npb24gdXJnZW50bHkg KmFsdGhvdWdoIHdlIGNhbiouIFNwZWNpZmljYWxseSwgd2UgY2FuIGJlZ2luIChhbmQgY29uY2x1 ZGUpIHRoZSBkaXNjdXNzaW9uIG9uY2UgdGhlcmUgaXMgYW4gYWN0dWFsIHByb3Bvc2FsIHRoYXQg YWRkcmVzc2VzDQogd2hhdCBNYXJrJ3Mgb3JpZ2luYWwgZW1haWwgb3V0bGluZWQuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkxhcnM8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E58094ECC8D8344914996DAD28F1CCD8464B8DGGEMM506MBXchina_-- From nobody Wed Nov 22 22:13: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 4F7F4120721 for ; Wed, 22 Nov 2017 22:13:33 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G-4kBeZEQw-2 for ; Wed, 22 Nov 2017 22:13:32 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 178ED1205F1 for ; Wed, 22 Nov 2017 22:13:32 -0800 (PST) Received: from LHREML712-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 2B5604888C527 for ; Thu, 23 Nov 2017 06:13:29 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 23 Nov 2017 06:13:29 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.96]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Thu, 23 Nov 2017 14:13:26 +0800 From: Roni Even To: Mark Nottingham , QUIC WG CC: Lars Eggert Subject: RE: Spin bit discussion - where we're at - use case exsist!!! Thread-Topic: Spin bit discussion - where we're at - use case exsist!!! Thread-Index: AdNkIisC9xIKNWiHQVCTDxaJDE0Wug== Date: Thu, 23 Nov 2017 06:13:25 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8464CB@DGGEMM506-MBX.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:13:33 -0000 >=20 > 1) A description of the use case(s) that motivate this proposal. We > understand that the goal is to measure RTT, but some people are still unc= lear > as to why that's necessary to operate a network. Detailed scenarios and > ideally real-world examples (e.g., from TCP) would help tremendously. > Saying "I need to debug the network" is not enough detail. >=20 [Roni Even] I submitted such a document but I assume that nobody read it si= nce I would expect that this bullet will at least mention it !!! See https://tools.ietf.org/id/draft-even-quic-troubleshooting-video-deliver= y-00.tx=20 Please read the document=20 Roni From nobody Wed Nov 22 22:41: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 C97EF129C49 for ; Wed, 22 Nov 2017 22:41: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] 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 gV7gTUXCW3qm for ; Wed, 22 Nov 2017 22:41:08 -0800 (PST) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:241:204::f0f0]) by ietfa.amsl.com (Postfix) with ESMTP id 2E72A129C47 for ; Wed, 22 Nov 2017 22:41:08 -0800 (PST) Received: from Gs-MacBook-Pro.local (at-zeroshell-1.erg.abdn.ac.uk [139.133.217.68]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id B70C41B0020A; Thu, 23 Nov 2017 06:41:01 +0000 (GMT) Message-ID: <5A166D7E.4060401@erg.abdn.ac.uk> Date: Thu, 23 Nov 2017 06:41:02 +0000 From: Gorry Fairhurst Reply-To: gorry@erg.abdn.ac.uk Organization: University of Aberdeen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:12.0) Gecko/20120428 Thunderbird/12.0.1 MIME-Version: 1.0 To: Christian Huitema CC: "Eggert, Lars" , Ted Hardie , "quic@ietf.org" Subject: Re: reserved bits for spin bit, etc. References: <2EEF8E08-4C73-454D-9F90-83B8072520B9@netapp.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:41:12 -0000 On 23/11/2017, 00:15, Christian Huitema wrote: > > On 11/22/2017 11:57 AM, Eggert, Lars wrote: > >> On 2017-11-22, at 20:22, Ted Hardie > > wrote: >>> >>> While I'd personally be happy with reserving some bits for this now, >>> I think marking them as experimental is worse than setting them >>> aside as "reserved" (or whatever the shorthand is for "still under >>> discussion"). If folks start running multiple different experiments >>> across full-path connections, interpreting the data you get will be >>> much harder. Unless there is some way to connect the experiment's >>> semantics with the bit, it seems to make a garbage bit likely. >> >> (chair hat off) >> >> Agree with Ted. Am OK with reserving, but we'd need to grease them >> while they remain reserved, so they remain useable upon assignment. > > Fair point. So the first bit should be defined as "reserved for the > spin bit experiment". The second bit, if we decide to have a second > one, should be strictly designed as "reserved" for now. > > -- Christian Huitema I'm preetty sure that if we had a set of bits that were declared in the header, the IETF could define a mechanism that offers the features we want. I think the IETF transport people are quite capable of proposing a mechanism(s) if we spend the time discussing the mechanisms, rather than whether the bit field can be present. Sure, I'd agree the choice of which to use could be experimental in the first release - and become "standardised" in later releases. I do suggest we consider two bits for the "spin", rather than one, because of the ability to robustly measure in the presence of loss/reordering - the greatest value is a system that continues to offer useful data when the path is under stress, so that the mechanisms can be used to figure out how to fix/analyse problems. Maybe it may be useful to also be able to quantify loss/congestion/reodering (even when on the return path) ... but I do think we need to first look at robust latency measurement. Gorry From nobody Thu Nov 23 00:02: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 B88D012726E for ; Thu, 23 Nov 2017 00:02: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 xONkPpdm3pQY for ; Thu, 23 Nov 2017 00:02:22 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id CB8C8127419 for ; Thu, 23 Nov 2017 00:02:20 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id BD4AC340F0C; Thu, 23 Nov 2017 09:02:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.2768); Thu, 23 Nov 2017 09:02:18 +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, 23 Nov 2017 09:02:16 +0100 (CET) Received: from [213.55.184.169] (account ietf@trammell.ch HELO [10.184.74.169]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 36950088; Thu, 23 Nov 2017 09:02:16 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: reserved bits for spin bit, etc. From: "Brian Trammell (IETF)" X-Mailer: iPhone Mail (15B202) In-Reply-To: <5A166D7E.4060401@erg.abdn.ac.uk> Date: Thu, 23 Nov 2017 09:02:14 +0100 Cc: Christian Huitema , Ted Hardie , "quic@ietf.org" , "Eggert, Lars" Content-Transfer-Encoding: quoted-printable Message-Id: <59244734-960F-4F2F-A44E-497A0844E429@trammell.ch> References: <2EEF8E08-4C73-454D-9F90-83B8072520B9@netapp.com> <5A166D7E.4060401@erg.abdn.ac.uk> To: gorry@erg.abdn.ac.uk Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:02:25 -0000 +1 to Gorry.=20 I can think of good uses off the top of my head for three bits in the short h= eader simultaneously, even four if we can have them, and as it looks like sh= ort header packet number varints are a good idea, we=E2=80=99ll get the whol= e type field (5bits) back.=20 However, two bits provides us enough to experiment with a two-bit spin versu= s spin-and-loss versus spin-and-block, and leaves us with three bits for fut= ure type signaling on the short header. It=E2=80=99s a good compromise. As to whether these are reserved in v1 versus reserved forever, I note that o= nce these deploy in v1 they are probably effectively reserved forever, but w= e don=E2=80=99t have to make that choice until they deploy. So reserved in v= 1 is fine for now and would indeed help with experimentation: Piet=E2=80=99s= minq fork does all this in a measurement byte prepended to the header for n= ow. As to marten=E2=80=99s point: yes, for the time being experiments will have t= o synchronize the meaning among the endpoints and observers. We could use ve= rsion negotiation to do this (indeed, Piet already blocked out 16 version nu= mbers for our own experiments in the wiki for exactly this purpose), but I e= xpect v1 to have a single meaning for these bits. Consider this an opportuni= ty to exercise version negotiation (and, for observers, version tracking) du= ring interop. Cheers,=20 Brian Sent from my iPhone > On 23 Nov 2017, at 07:41, Gorry Fairhurst wrote: >=20 >> On 23/11/2017, 00:15, Christian Huitema wrote: >>=20 >>> On 11/22/2017 11:57 AM, Eggert, Lars wrote: >>>=20 >>>> On 2017-11-22, at 20:22, Ted Hardie > wrote: >>>>=20 >>>> While I'd personally be happy with reserving some bits for this now, I t= hink marking them as experimental is worse than setting them aside as "reser= ved" (or whatever the shorthand is for "still under discussion"). If folks s= tart running multiple different experiments across full-path connections, in= terpreting the data you get will be much harder. Unless there is some way t= o connect the experiment's semantics with the bit, it seems to make a garbag= e bit likely. >>>=20 >>> (chair hat off) >>>=20 >>> Agree with Ted. Am OK with reserving, but we'd need to grease them while= they remain reserved, so they remain useable upon assignment. >>=20 >> Fair point. So the first bit should be defined as "reserved for the spin b= it experiment". The second bit, if we decide to have a second one, should be= strictly designed as "reserved" for now. >>=20 >> -- Christian Huitema > I'm preetty sure that if we had a set of bits that were declared in the he= ader, the IETF could define a mechanism that offers the features we want. I t= hink the IETF transport people are quite capable of proposing a mechanism(s)= if we spend the time discussing the mechanisms, rather than whether the bit= field can be present. Sure, I'd agree the choice of which to use could be e= xperimental in the first release - and become "standardised" in later releas= es. >=20 > I do suggest we consider two bits for the "spin", rather than one, because= of the ability to robustly measure in the presence of loss/reordering - the= greatest value is a system that continues to offer useful data when the pat= h is under stress, so that the mechanisms can be used to figure out how to f= ix/analyse problems. Maybe it may be useful to also be able to quantify loss= /congestion/reodering (even when on the return path) ... but I do think we n= eed to first look at robust latency measurement. >=20 > Gorry >=20 >=20 From nobody Thu Nov 23 01:45: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 85F851275F4 for ; Thu, 23 Nov 2017 01:45:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CiTs3y6Ehy9r for ; Thu, 23 Nov 2017 01:45:39 -0800 (PST) Received: from orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8E87124207 for ; Thu, 23 Nov 2017 01:45:38 -0800 (PST) Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar21.francetelecom.fr (ESMTP service) with ESMTP id 09FD4100DA3; Thu, 23 Nov 2017 10:45:37 +0100 (CET) Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.42]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id DA4AF40090; Thu, 23 Nov 2017 10:45:36 +0100 (CET) Received: from OPEXCLILM44.corporate.adroot.infra.ftgroup ([fe80::b08d:5b75:e92c:a45f]) by OPEXCLILM41.corporate.adroot.infra.ftgroup ([fe80::c845:f762:8997:ec86%19]) with mapi id 14.03.0361.001; Thu, 23 Nov 2017 10:45:36 +0100 From: To: Roni Even , Marcus Ihlar , "Eggert, Lars" CC: Salvatore Loreto , Brian Trammell , Mark Nottingham , QUIC WG Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jgLJ4dZfGUakC4emhuNG4GQqMgDSIAgAAyYACAAAWjgIAAD76AgAAGuACAAAd0gIAACAWAgAASmwCAAO3AgIAATDNg Date: Thu, 23 Nov 2017 09:45:36 +0000 Message-ID: <21183_1511430336_5A1698C0_21183_123_1_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E8472D@OPEXCLILM44.corporate.adroot.infra.ftgroup> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> <9F6AAAF0-02BE-4538-8D4A-1C5B58841104@netapp.com> <6E58094ECC8D8344914996DAD28F1CCD8461C0@DGGEMM506-MBX.china.huawei.com> <6FA87C43-D639-4700-9B97-5901237BA5F1@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD8464B8@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8464B8@DGGEMM506-MBX.china.huawei.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.2] Content-Type: multipart/alternative; boundary="_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E8472DOPEXCLILM44corp_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:45:45 -0000 --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E8472DOPEXCLILM44corp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KSSBwcm9wb3NlIHRvIGNvbnRyaWJ1dGUgYXMgYSB0ZWxjbyByZXByZXNlbnRhdGl2ZS4g V2UgYWxyZWFkeSBkZXNjcmliZWQgdHJvdWJsZXNob290aW5nIHVzZSBjYXNlcyBpbiBodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtc3RlcGhhbi1xdWljLWludGVyZG9tYWluLXRyb3Vi bGVzaG9vdGluZy0wMC4NCg0KUmVnYXJkcw0KRW1pbGUNCg0KRGUgOiBRVUlDIFttYWlsdG86cXVp Yy1ib3VuY2VzQGlldGYub3JnXSBEZSBsYSBwYXJ0IGRlIFJvbmkgRXZlbg0KRW52b3nDqSA6IGpl dWRpIDIzIG5vdmVtYnJlIDIwMTcgMDc6MDkNCsOAIDogTWFyY3VzIElobGFyOyBFZ2dlcnQsIExh cnMNCkNjIDogU2FsdmF0b3JlIExvcmV0bzsgQnJpYW4gVHJhbW1lbGw7IE1hcmsgTm90dGluZ2hh bTsgUVVJQyBXRw0KT2JqZXQgOiBSRTogU3BpbiBiaXQgZGlzY3Vzc2lvbiAtIHdoZXJlIHdlJ3Jl IGF0DQoNCkhpLA0KSSB3aWxsIHdvcmsgd2l0aCBCcmlhbiBhbmQgTWFyY3VzIG9uIHRoaXMgZHJh ZnQNClJvbmkNCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIE1hcmN1cyBJaGxhcg0KU2VudDog15nXldedINeTIDIyINeg15XXkdee15HXqCAy MDE3IDE3OjU4DQpUbzogRWdnZXJ0LCBMYXJzDQpDYzogU2FsdmF0b3JlIExvcmV0bzsgQnJpYW4g VHJhbW1lbGw7IFJvbmkgRXZlbjsgUVVJQyBXRzsgTWFyayBOb3R0aW5naGFtDQpTdWJqZWN0OiBS ZTogU3BpbiBiaXQgZGlzY3Vzc2lvbiAtIHdoZXJlIHdlJ3JlIGF0DQoNCkhpLA0KSnVzdCBjaGlw cGluZyBpbiB0byBzYXkgdGhhdCBJ4oCZbSBoYXBweSB0byB3b3JrIHdpdGggQnJpYW4gb24gdGhp cyBkcmFmdC4NCg0KL01hcmN1cw0KDQpPbiAyMiBOb3YgMjAxNywgYXQgMjI6NTEsIEVnZ2VydCwg TGFycyA8bGFyc0BuZXRhcHAuY29tPG1haWx0bzpsYXJzQG5ldGFwcC5jb20+PiB3cm90ZToNCkhp LA0KDQpPbiAyMDE3LTExLTIyLCBhdCAxNToyMiwgUm9uaSBFdmVuIDxyb25pLmV2ZW5AaHVhd2Vp LmNvbTxtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20+PiB3cm90ZToNCkkgdGhpbmsgdGhlIGRl Y2lzaW9uIHRvIG5vdCBkaXNjdXNzIGl0IGF0IHRoZSBpbnRlcmltIGlzIGJhc2VkIG9uIHRoZSBv YnNlcnZhdGlvbg0KdGhhdCB0aGUgcmVnaXN0ZXJlZCBhdHRlbmRlZXMgYXQgdGhlIGludGVyaW0g YXJlIHByb2JhYmx5IG5vdCByZXByZXNlbnRhdGl2ZQ0Kb2YgdGhlIG92ZXJhbGwgV0cgY29uc3Rp dHVlbmN5IC0gd2Ugd2FudCB0byBnaXZlIGFsbCBzaWRlcyBhbiBhYmlsaXR5IHRvDQpwYXJ0aWNp cGF0ZSBlcXVhbGx5IGluIHRoZSBkaXNjdXNzaW9uLg0KW1JvbmkgRXZlbl0gVGhpcyBpcyB3aHkg d2UgaGF2ZSByZW1vdGUgcGFydGljaXBhbnRzIGF0IElFVEYgbWVldGluZ3MgISEhISEhISENCllv dSBkbyBub3QgaGF2ZSB0byBiZSBpbiBwZXJzb24gdG8gZGlzY3VzcyEhISENCg0KdGhlIElFVEYg KHZpZSBNZWV0RWNobykgcHJvdmlkZXMgcmVtb3RlIHBhcnRpY2lwYXRpb24gYXQgdGhlIG1haW4g bWVldGluZ3MuIEF0IHRoZSBpbnRlcmltcywgaXQncyBNYXJrLiBJdCBzZWVtcyB0byBoYXZlIG1v c3RseSB3b3JrZWQgT0sgZm9yIHBhc3NpdmUgcGFydGljaXBhdGlvbiBkdXJpbmcgdHdvIG91dCBv ZiB0aGUgbGFzdCB0aHJlZSBpbnRlcmltcywgYnV0IHdlIGhhdmVuJ3QgdHJpZWQgdG8gaG9sZCBh IGRpc2N1c3Npb24gd2l0aCBtYW55IGFjdGl2ZSByZW1vdGUgcGFydGljaXBhbnRzLg0KDQpJIHRo aW5rIHdoYXQgTWFyayB0cmllZCB0byBleHByZXNzIGlzIHRoYXQgdGhlIGRpc2N1c3Npb24gb24g dGhlIFNwaW4gQml0IGNhbiBiZQ0KbW9zdGx5IGRlY291cGxlZCBmcm9tIHRoZSAobGFyZ2UgYW1v dW50IG9mKSB3b3JrIHJlbWFpbmluZyBvbiB0aGUgYmFzZQ0Kc3BlYy4gVGhhdCBpcywgd2UgZG9u J3QgaGF2ZSB0byBjb25jbHVkZSB0aGUgU3BpbiBCaXQgZGlzY3Vzc2lvbiBzaWduaWZpY2FudGx5 DQpwcmlvciB0byB0aGUgY29uY2x1c2lvbiBvZiB0aGUgb3ZlcmFsbCB3b3JrIChhbHRob3VnaCB3 ZSBjYW4pLCBzaW5jZSBpdCBzaG91bGQNCmJlIGVhc3kgdG8gbWVyZ2UgYXQgdGhlIGxhdGVyIHN0 YWdlcyBiZWZvcmUgaGFuZGluZyB0aGluZ3MgdG8gdGhlIElFU0cuDQpbUm9uaSBFdmVuXSBkZWxh eWluZyB0aGUgZGlzY3Vzc2lvbiBtYXkgcHJldmVudCB0aGUgYWNjZXB0YW5jZS4gIElmIHBlb3Bs ZSB3aWxsIHB1dCBlZmZvcnQgYXQgc3VibWl0dGluZyB0ZXh0IHRoZW4gdGhlIGNoYWlycyBzaG91 bGQgYWxsb3cgZm9yIGRpc2N1c3Npb24gYW5kIG5vdCBkZWxheSB0aGUgd29yay4NCg0KSSBkaXNh Z3JlZSB3aXRoIHRoaXMgY2hhcmFjdGVyaXphdGlvbi4NCg0KV2hhdCBJIHNhaWQgYWJvdmUgaW4g dGhlIHBhcmFncmFwaCB5b3UgcXVvdGUgaXMgdGhhdCB3ZSBkbyBub3QgKmhhdmUgdG8qIGNvbmNs dWRlIHRoZSBTcGluIEJpdCBkaXNjdXNzaW9uIHVyZ2VudGx5ICphbHRob3VnaCB3ZSBjYW4qLiBT cGVjaWZpY2FsbHksIHdlIGNhbiBiZWdpbiAoYW5kIGNvbmNsdWRlKSB0aGUgZGlzY3Vzc2lvbiBv bmNlIHRoZXJlIGlzIGFuIGFjdHVhbCBwcm9wb3NhbCB0aGF0IGFkZHJlc3NlcyB3aGF0IE1hcmsn cyBvcmlnaW5hbCBlbWFpbCBvdXRsaW5lZC4NCg0KTGFycw0KCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KCkNlIG1lc3NhZ2Ug ZXQgc2VzIHBpZWNlcyBqb2ludGVzIHBldXZlbnQgY29udGVuaXIgZGVzIGluZm9ybWF0aW9ucyBj b25maWRlbnRpZWxsZXMgb3UgcHJpdmlsZWdpZWVzIGV0IG5lIGRvaXZlbnQgZG9uYwpwYXMgZXRy ZSBkaWZmdXNlcywgZXhwbG9pdGVzIG91IGNvcGllcyBzYW5zIGF1dG9yaXNhdGlvbi4gU2kgdm91 cyBhdmV6IHJlY3UgY2UgbWVzc2FnZSBwYXIgZXJyZXVyLCB2ZXVpbGxleiBsZSBzaWduYWxlcgph IGwnZXhwZWRpdGV1ciBldCBsZSBkZXRydWlyZSBhaW5zaSBxdWUgbGVzIHBpZWNlcyBqb2ludGVz LiBMZXMgbWVzc2FnZXMgZWxlY3Ryb25pcXVlcyBldGFudCBzdXNjZXB0aWJsZXMgZCdhbHRlcmF0 aW9uLApPcmFuZ2UgZGVjbGluZSB0b3V0ZSByZXNwb25zYWJpbGl0ZSBzaSBjZSBtZXNzYWdlIGEg ZXRlIGFsdGVyZSwgZGVmb3JtZSBvdSBmYWxzaWZpZS4gTWVyY2kuCgpUaGlzIG1lc3NhZ2UgYW5k IGl0cyBhdHRhY2htZW50cyBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgb3IgcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiB0aGF0IG1heSBiZSBwcm90ZWN0ZWQgYnkgbGF3Owp0aGV5IHNob3VsZCBub3Qg YmUgZGlzdHJpYnV0ZWQsIHVzZWQgb3IgY29waWVkIHdpdGhvdXQgYXV0aG9yaXNhdGlvbi4KSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciwgcGxlYXNlIG5vdGlmeSB0aGUg c2VuZGVyIGFuZCBkZWxldGUgdGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMuCkFzIGVt YWlscyBtYXkgYmUgYWx0ZXJlZCwgT3JhbmdlIGlzIG5vdCBsaWFibGUgZm9yIG1lc3NhZ2VzIHRo YXQgaGF2ZSBiZWVuIG1vZGlmaWVkLCBjaGFuZ2VkIG9yIGZhbHNpZmllZC4KVGhhbmsgeW91LgoK --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E8472DOPEXCLILM44corp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXI7DQoJcGFub3NlLTE6MCAwIDAg MCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206 LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29B Y2V0YXRlLCBsaS5Nc29BY2V0YXRlLCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1hcmdpbjow Y207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UN Cgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uRW1haWxTdHls ZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlRleHRlZGVidWxsZXNDYXINCgl7 bXNvLXN0eWxlLW5hbWU6IlRleHRlIGRlIGJ1bGxlcyBDYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGV4dGUgZGUgYnVsbGVzIjsNCglmb250LWZhbWlseToi VGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjENCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJ Y29sb3I6YmxhY2s7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJGUiIgbGluaz0i Ymx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+SGk8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjpibGFjayI+SSBwcm9wb3NlIHRvIGNvbnRyaWJ1dGUgYXMgYSB0ZWxjbyByZXByZXNl bnRhdGl2ZS4gV2UgYWxyZWFkeSBkZXNjcmliZWQgdHJvdWJsZXNob290aW5nIHVzZSBjYXNlcyBp bg0KPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LXN0ZXBoYW4tcXVp Yy1pbnRlcmRvbWFpbi10cm91Ymxlc2hvb3RpbmctMDAiPg0KaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXN0ZXBoYW4tcXVpYy1pbnRlcmRvbWFpbi10cm91Ymxlc2hvb3RpbmctMDA8 L2E+LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibGFjayI+UmVnYXJkczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsYWNrIj5FbWlsZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOmJsYWNrIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4w cHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkRlJm5ic3A7Ojwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+RGUgbGEgcGFydCBk ZTwvYj4gUm9uaSBFdmVuPGJyPg0KPGI+RW52b3nDqSZuYnNwOzo8L2I+IGpldWRpIDIzIG5vdmVt YnJlIDIwMTcgMDc6MDk8YnI+DQo8Yj7DgCZuYnNwOzo8L2I+IE1hcmN1cyBJaGxhcjsgRWdnZXJ0 LCBMYXJzPGJyPg0KPGI+Q2MmbmJzcDs6PC9iPiBTYWx2YXRvcmUgTG9yZXRvOyBCcmlhbiBUcmFt bWVsbDsgTWFyayBOb3R0aW5naGFtOyBRVUlDIFdHPGJyPg0KPGI+T2JqZXQmbmJzcDs6PC9iPiBS RTogU3BpbiBiaXQgZGlzY3Vzc2lvbiAtIHdoZXJlIHdlJ3JlIGF0PG86cD48L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd2lsbCB3b3JrIHdpdGggQnJpYW4gYW5kIE1hcmN1cyBvbiB0 aGlzIGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5Sb25p PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xp ZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IFFVSUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJv dW5jZXNAaWV0Zi5vcmciPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24g QmVoYWxmIE9mIDwvYj5NYXJjdXMgSWhsYXI8YnI+DQo8Yj5TZW50OjwvYj4gPC9zcGFuPjxzcGFu IGxhbmc9IkhFIiBkaXI9IlJUTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPteZ15XXnSZuYnNwO9eT IDIyINeg15XXkdee15HXqCAyMDE3IDE3OjU4PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+VG86PC9iPiBFZ2dlcnQsIExhcnM8YnI+DQo8Yj5D Yzo8L2I+IFNhbHZhdG9yZSBMb3JldG87IEJyaWFuIFRyYW1tZWxsOyBSb25pIEV2ZW47IFFVSUMg V0c7IE1hcmsgTm90dGluZ2hhbTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogU3BpbiBiaXQgZGlz Y3Vzc2lvbiAtIHdoZXJlIHdlJ3JlIGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1V UyI+SGksPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5KdXN0IGNoaXBwaW5nIGluIHRvIHNheSB0aGF0IEnigJltIGhh cHB5IHRvIHdvcmsgd2l0aCBCcmlhbiBvbiB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NCi9NYXJjdXM8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KT24gMjIgTm92 IDIwMTcsIGF0IDIyOjUxLCBFZ2dlcnQsIExhcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpsYXJzQG5l dGFwcC5jb20iPmxhcnNAbmV0YXBwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPk9uIDIw MTctMTEtMjIsIGF0IDE1OjIyLCBSb25pIEV2ZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpyb25pLmV2 ZW5AaHVhd2VpLmNvbSI+cm9uaS5ldmVuQGh1YXdlaS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6 IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1dG87LXdlYmtpdC10ZXh0LXNpemUtYWRq dXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4 Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDss JnF1b3Q7c2VyaWYmcXVvdDsiPkkgdGhpbmsgdGhlIGRlY2lzaW9uIHRvIG5vdCBkaXNjdXNzIGl0 IGF0IHRoZSBpbnRlcmltIGlzIGJhc2VkIG9uIHRoZSBvYnNlcnZhdGlvbjxicj4NCnRoYXQgdGhl IHJlZ2lzdGVyZWQgYXR0ZW5kZWVzIGF0IHRoZSBpbnRlcmltIGFyZSBwcm9iYWJseSBub3QgcmVw cmVzZW50YXRpdmU8YnI+DQpvZiB0aGUgb3ZlcmFsbCBXRyBjb25zdGl0dWVuY3kgLSB3ZSB3YW50 IHRvIGdpdmUgYWxsIHNpZGVzIGFuIGFiaWxpdHkgdG88YnI+DQpwYXJ0aWNpcGF0ZSBlcXVhbGx5 IGluIHRoZSBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssJnF1b3Q7c2VyaWYm cXVvdDsiPltSb25pIEV2ZW5dIFRoaXMgaXMgd2h5IHdlIGhhdmUgcmVtb3RlIHBhcnRpY2lwYW50 cyBhdCBJRVRGIG1lZXRpbmdzICEhISEhISEhPGJyPg0KWW91IGRvIG5vdCBoYXZlIHRvIGJlIGlu IHBlcnNvbiB0byBkaXNjdXNzISEhITwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj50 aGUgSUVURiAodmllIE1lZXRFY2hvKSBwcm92aWRlcyByZW1vdGUgcGFydGljaXBhdGlvbiBhdCB0 aGUgbWFpbiBtZWV0aW5ncy4gQXQgdGhlIGludGVyaW1zLCBpdCdzIE1hcmsuIEl0IHNlZW1zIHRv IGhhdmUgbW9zdGx5IHdvcmtlZCBPSyBmb3IgcGFzc2l2ZSBwYXJ0aWNpcGF0aW9uIGR1cmluZyB0 d28gb3V0IG9mIHRoZSBsYXN0IHRocmVlIGludGVyaW1zLCBidXQgd2UgaGF2ZW4ndA0KIHRyaWVk IHRvIGhvbGQgYSBkaXNjdXNzaW9uIHdpdGggbWFueSBhY3RpdmUgcmVtb3RlIHBhcnRpY2lwYW50 cy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1 LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFu czogYXV0bzt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1h ZGp1c3Q6IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow cHgiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWVubG8tUmVndWxhciZxdW90OywmcXVvdDtz ZXJpZiZxdW90OyI+SSB0aGluayB3aGF0IE1hcmsgdHJpZWQgdG8gZXhwcmVzcyBpcyB0aGF0IHRo ZSBkaXNjdXNzaW9uIG9uIHRoZSBTcGluIEJpdCBjYW4gYmU8YnI+DQptb3N0bHkgZGVjb3VwbGVk IGZyb20gdGhlIChsYXJnZSBhbW91bnQgb2YpIHdvcmsgcmVtYWluaW5nIG9uIHRoZSBiYXNlPGJy Pg0Kc3BlYy4gVGhhdCBpcywgd2UgZG9uJ3QgaGF2ZSB0byBjb25jbHVkZSB0aGUgU3BpbiBCaXQg ZGlzY3Vzc2lvbiBzaWduaWZpY2FudGx5PGJyPg0KcHJpb3IgdG8gdGhlIGNvbmNsdXNpb24gb2Yg dGhlIG92ZXJhbGwgd29yayAoYWx0aG91Z2ggd2UgY2FuKSwgc2luY2UgaXQgc2hvdWxkPGJyPg0K YmUgZWFzeSB0byBtZXJnZSBhdCB0aGUgbGF0ZXIgc3RhZ2VzIGJlZm9yZSBoYW5kaW5nIHRoaW5n cyB0byB0aGUgSUVTRy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtNZW5sby1SZWd1bGFyJnF1b3Q7LCZxdW90O3NlcmlmJnF1b3Q7 Ij5bUm9uaSBFdmVuXSBkZWxheWluZyB0aGUgZGlzY3Vzc2lvbiBtYXkgcHJldmVudCB0aGUgYWNj ZXB0YW5jZS4gJm5ic3A7SWYgcGVvcGxlIHdpbGwgcHV0IGVmZm9ydCBhdCBzdWJtaXR0aW5nIHRl eHQgdGhlbiB0aGUgY2hhaXJzIHNob3VsZCBhbGxvdyBmb3IgZGlzY3Vzc2lvbiBhbmQNCiBub3Qg ZGVsYXkgdGhlIHdvcmsuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SSBkaXNhZ3JlZSB3aXRoIHRoaXMgY2hhcmFjdGVy aXphdGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi PldoYXQgSSBzYWlkIGFib3ZlIGluIHRoZSBwYXJhZ3JhcGggeW91IHF1b3RlIGlzIHRoYXQgd2Ug ZG8gbm90ICpoYXZlIHRvKiBjb25jbHVkZSB0aGUgU3BpbiBCaXQgZGlzY3Vzc2lvbiB1cmdlbnRs eSAqYWx0aG91Z2ggd2UgY2FuKi4gU3BlY2lmaWNhbGx5LCB3ZSBjYW4gYmVnaW4gKGFuZCBjb25j bHVkZSkgdGhlIGRpc2N1c3Npb24gb25jZSB0aGVyZSBpcyBhbiBhY3R1YWwgcHJvcG9zYWwNCiB0 aGF0IGFkZHJlc3NlcyB3aGF0IE1hcmsncyBvcmlnaW5hbCBlbWFpbCBvdXRsaW5lZC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkxhcnM8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRl cyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHBy aXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRl cyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3Nh Z2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUg ZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0 cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUg dG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUg b3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkg YmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2Vk IG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRo aXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQs IE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmll ZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1s Pg0K --_000_5AE9CCAA1B4A2248AB61B4C7F0AD5FB924E8472DOPEXCLILM44corp_-- From nobody Thu Nov 23 03:11: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 C88A9128792 for ; Thu, 23 Nov 2017 03:11:02 -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, HTML_MESSAGE=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 LO5E1CsVZgCD for ; Thu, 23 Nov 2017 03:11:00 -0800 (PST) Received: from mx04.telecomitalia.it (mx04.telecomitalia.it [217.169.121.24]) (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 CAA681277BB for ; Thu, 23 Nov 2017 03:10:59 -0800 (PST) X-AuditID: d9a97918-07fff70000003d1a-2e-5a16acc1ce8b Received: from TELMBXA06RM001.telecomitalia.local ( [10.14.252.34]) (using TLS with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client did not present a certificate) by mx04.telecomitalia.it () with SMTP id B2.29.15642.1CCA61A5; Thu, 23 Nov 2017 12:10:57 +0100 (CET) From: Fioccola Giuseppe To: Roni Even , Marcus Ihlar , "Eggert, Lars" CC: Salvatore Loreto , Brian Trammell , Mark Nottingham , QUIC WG Subject: R: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jibGVUdbbGAUuUkAWecsVbsKMgDSIAgAAyYACAAAWjgIAAD76AgAAGuACAAAd0gIAACAWAgAASmwCAAO3AgIAAYgJw Date: Thu, 23 Nov 2017 11:10:56 +0000 Message-ID: <9a76a02ed7c34f0e922a33fac96eff4b@TELMBXB02RM001.telecomitalia.local> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <6E58094ECC8D8344914996DAD28F1CCD846139@DGGEMM506-MBX.china.huawei.com> <9F6AAAF0-02BE-4538-8D4A-1C5B58841104@netapp.com> <6E58094ECC8D8344914996DAD28F1CCD8461C0@DGGEMM506-MBX.china.huawei.com> <6FA87C43-D639-4700-9B97-5901237BA5F1@ericsson.com> <6E58094ECC8D8344914996DAD28F1CCD8464B8@DGGEMM506-MBX.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8464B8@DGGEMM506-MBX.china.huawei.com> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.14.252.254] x-ti-disclaimer: Disclaimer1 Content-Type: multipart/alternative; boundary="_000_9a76a02ed7c34f0e922a33fac96eff4bTELMBXB02RM001telecomit_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOKsWRmVeSWpSXmKPExsXCxfdHSffgGrEogwMbFC02trxjs3jxuofF 4uDLV6wW6z89ZrToWcBt8enYeRaLu3+3MTuwe/z6epXNo+XIW1aPJUt+MnlsXPyd1WPGpy9s Hk/2z2QJYItqYLRJzMvLL0ksSVVISS1OtlVyySxOzknMzE0tUghJzUlNzs9VUshMsVUyVlIo yElMTs1NzSuxVUosKEjNS1Gy41LAADZAZZl5Cql5yfkpmXnptkqewf66FhamlrqGSnaBpanF JfkKuanFxYnp6Zn5CqkJ6wUzJrTvZym40c1YMfH2UbYGxh/tjF2MnBwSAiYSa35fYe1i5OIQ EpjCJLH85CUWkASbgI3EwVcn2EBsEYEiidv/LzKBFDELTGaU2HJ6LztIQljAQOLTrjnsEEVG Em3vOqAa8iRO/N0KFmcRUJXY+HcrWJxXIFDi9YNfLBDbPrNI7Jv/BGgqBwenQIjE+zcBIDWM ArISE3YvAruOWUBc4sX0E+wQlwpILNlznhnCFpV4+fgfK4RtILF16T4WCFtR4sLyo1C2jMTC I5NZIebkS5xtO80CcYOgxMmZT1gmMIrOQrJiFpKyWUjKZgFdxyygKbF+lz5EiaLElO6HUOUa Eq1z5rIjiy9gZF/FKJpbYWCiVwKJ2cySxJzMRL3Mkk2MwNR1c2WlxA7G7rXOhxgFOBiVeHjj lohFCbEmlhVX5h5ilOBgVhLhFW8HCvGmJFZWpRblxxeV5qQWH2L0AQbkRGYp0eR8YFrNK4k3 NLGwNDS2sDAytDAzxSGsJM77J000SkggHZj0slNTC1KLYMYxcXBKNTBK/1spG7Ir+NyhrutX pp37Gs++aMKmz6+vx/H8/S/M1h12PUJM89bVO/PjvNa4JzS/+hPhcMGNdd3Tf3dEZD4eWqB3 8lRb2pcjK89yXJCYLN57V1O5MrnpaK2x5tn4pn8Fnr8maYX1d/OFdJ10eHr5zN9dAStzWxVC Tv/a5xB1+e6zIrFyw4WxSizFGYmGWsxFxYkARPqNwIoDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 11:11:03 -0000 --_000_9a76a02ed7c34f0e922a33fac96eff4bTELMBXB02RM001telecomit_ Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 SGksDQpJIGNhbiBhbHNvIGhlbHAgb24gdGhpcyB0b3BpYywgc2VlbiBteSBleHBlcmllbmNl IHdpdGggSVBQTSBtYXJraW5nIG1ldGhvZG9sb2dpZXMgYW5kIGFzIGEgdGVsY28gZGVsZWdh dGUuDQpUaGFua3MsDQoNCkdpdXNlcHBlDQoNCkRhOiBRVUlDIFttYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnXSBQZXIgY29udG8gZGkgUm9uaSBFdmVuDQpJbnZpYXRvOiBnaW92ZWTD rCAyMyBub3ZlbWJyZSAyMDE3IDA3OjA5DQpBOiBNYXJjdXMgSWhsYXI7IEVnZ2VydCwgTGFy cw0KQ2M6IFNhbHZhdG9yZSBMb3JldG87IEJyaWFuIFRyYW1tZWxsOyBNYXJrIE5vdHRpbmdo YW07IFFVSUMgV0cNCk9nZ2V0dG86IFJFOiBTcGluIGJpdCBkaXNjdXNzaW9uIC0gd2hlcmUg d2UncmUgYXQNCg0KSGksDQpJIHdpbGwgd29yayB3aXRoIEJyaWFuIGFuZCBNYXJjdXMgb24g dGhpcyBkcmFmdA0KUm9uaQ0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgTWFyY3VzIElobGFyDQpTZW50OiDXmdeV150g15MgMjIg 16DXldeR157XkdeoIDIwMTcgMTc6NTgNClRvOiBFZ2dlcnQsIExhcnMNCkNjOiBTYWx2YXRv cmUgTG9yZXRvOyBCcmlhbiBUcmFtbWVsbDsgUm9uaSBFdmVuOyBRVUlDIFdHOyBNYXJrIE5v dHRpbmdoYW0NClN1YmplY3Q6IFJlOiBTcGluIGJpdCBkaXNjdXNzaW9uIC0gd2hlcmUgd2Un cmUgYXQNCg0KSGksDQpKdXN0IGNoaXBwaW5nIGluIHRvIHNheSB0aGF0IEnigJltIGhhcHB5 IHRvIHdvcmsgd2l0aCBCcmlhbiBvbiB0aGlzIGRyYWZ0Lg0KDQovTWFyY3VzDQoNCk9uIDIy IE5vdiAyMDE3LCBhdCAyMjo1MSwgRWdnZXJ0LCBMYXJzIDxsYXJzQG5ldGFwcC5jb208bWFp bHRvOmxhcnNAbmV0YXBwLmNvbT4+IHdyb3RlOg0KSGksDQoNCk9uIDIwMTctMTEtMjIsIGF0 IDE1OjIyLCBSb25pIEV2ZW4gPHJvbmkuZXZlbkBodWF3ZWkuY29tPG1haWx0bzpyb25pLmV2 ZW5AaHVhd2VpLmNvbT4+IHdyb3RlOg0KSSB0aGluayB0aGUgZGVjaXNpb24gdG8gbm90IGRp c2N1c3MgaXQgYXQgdGhlIGludGVyaW0gaXMgYmFzZWQgb24gdGhlIG9ic2VydmF0aW9uDQp0 aGF0IHRoZSByZWdpc3RlcmVkIGF0dGVuZGVlcyBhdCB0aGUgaW50ZXJpbSBhcmUgcHJvYmFi bHkgbm90IHJlcHJlc2VudGF0aXZlDQpvZiB0aGUgb3ZlcmFsbCBXRyBjb25zdGl0dWVuY3kg LSB3ZSB3YW50IHRvIGdpdmUgYWxsIHNpZGVzIGFuIGFiaWxpdHkgdG8NCnBhcnRpY2lwYXRl IGVxdWFsbHkgaW4gdGhlIGRpc2N1c3Npb24uDQpbUm9uaSBFdmVuXSBUaGlzIGlzIHdoeSB3 ZSBoYXZlIHJlbW90ZSBwYXJ0aWNpcGFudHMgYXQgSUVURiBtZWV0aW5ncyAhISEhISEhIQ0K WW91IGRvIG5vdCBoYXZlIHRvIGJlIGluIHBlcnNvbiB0byBkaXNjdXNzISEhIQ0KDQp0aGUg SUVURiAodmllIE1lZXRFY2hvKSBwcm92aWRlcyByZW1vdGUgcGFydGljaXBhdGlvbiBhdCB0 aGUgbWFpbiBtZWV0aW5ncy4gQXQgdGhlIGludGVyaW1zLCBpdCdzIE1hcmsuIEl0IHNlZW1z IHRvIGhhdmUgbW9zdGx5IHdvcmtlZCBPSyBmb3IgcGFzc2l2ZSBwYXJ0aWNpcGF0aW9uIGR1 cmluZyB0d28gb3V0IG9mIHRoZSBsYXN0IHRocmVlIGludGVyaW1zLCBidXQgd2UgaGF2ZW4n dCB0cmllZCB0byBob2xkIGEgZGlzY3Vzc2lvbiB3aXRoIG1hbnkgYWN0aXZlIHJlbW90ZSBw YXJ0aWNpcGFudHMuDQoNCkkgdGhpbmsgd2hhdCBNYXJrIHRyaWVkIHRvIGV4cHJlc3MgaXMg dGhhdCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGUgU3BpbiBCaXQgY2FuIGJlDQptb3N0bHkgZGVj b3VwbGVkIGZyb20gdGhlIChsYXJnZSBhbW91bnQgb2YpIHdvcmsgcmVtYWluaW5nIG9uIHRo ZSBiYXNlDQpzcGVjLiBUaGF0IGlzLCB3ZSBkb24ndCBoYXZlIHRvIGNvbmNsdWRlIHRoZSBT cGluIEJpdCBkaXNjdXNzaW9uIHNpZ25pZmljYW50bHkNCnByaW9yIHRvIHRoZSBjb25jbHVz aW9uIG9mIHRoZSBvdmVyYWxsIHdvcmsgKGFsdGhvdWdoIHdlIGNhbiksIHNpbmNlIGl0IHNo b3VsZA0KYmUgZWFzeSB0byBtZXJnZSBhdCB0aGUgbGF0ZXIgc3RhZ2VzIGJlZm9yZSBoYW5k aW5nIHRoaW5ncyB0byB0aGUgSUVTRy4NCltSb25pIEV2ZW5dIGRlbGF5aW5nIHRoZSBkaXNj dXNzaW9uIG1heSBwcmV2ZW50IHRoZSBhY2NlcHRhbmNlLiAgSWYgcGVvcGxlIHdpbGwgcHV0 IGVmZm9ydCBhdCBzdWJtaXR0aW5nIHRleHQgdGhlbiB0aGUgY2hhaXJzIHNob3VsZCBhbGxv dyBmb3IgZGlzY3Vzc2lvbiBhbmQgbm90IGRlbGF5IHRoZSB3b3JrLg0KDQpJIGRpc2FncmVl IHdpdGggdGhpcyBjaGFyYWN0ZXJpemF0aW9uLg0KDQpXaGF0IEkgc2FpZCBhYm92ZSBpbiB0 aGUgcGFyYWdyYXBoIHlvdSBxdW90ZSBpcyB0aGF0IHdlIGRvIG5vdCAqaGF2ZSB0byogY29u Y2x1ZGUgdGhlIFNwaW4gQml0IGRpc2N1c3Npb24gdXJnZW50bHkgKmFsdGhvdWdoIHdlIGNh biouIFNwZWNpZmljYWxseSwgd2UgY2FuIGJlZ2luIChhbmQgY29uY2x1ZGUpIHRoZSBkaXNj dXNzaW9uIG9uY2UgdGhlcmUgaXMgYW4gYWN0dWFsIHByb3Bvc2FsIHRoYXQgYWRkcmVzc2Vz IHdoYXQgTWFyaydzIG9yaWdpbmFsIGVtYWlsIG91dGxpbmVkLg0KDQpMYXJzDQoNClF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNp dmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8g cXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBx dWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3Jh IGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNv cnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFs IG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jhemll LiANCg0KVGhpcyBlLW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBpcyBjb25maWRlbnRpYWwg YW5kIG1heSBjb250YWluIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gaW50ZW5kZWQgZm9yIHRo ZSBhZGRyZXNzZWUocykgb25seS4gRGlzc2VtaW5hdGlvbiwgY29weWluZywgcHJpbnRpbmcg b3IgdXNlIGJ5IGFueWJvZHkgZWxzZSBpcyB1bmF1dGhvcmlzZWQuIElmIHlvdSBhcmUgbm90 IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIHBsZWFzZSBkZWxldGUgdGhpcyBtZXNzYWdlIGFu ZCBhbnkgYXR0YWNobWVudHMgYW5kIGFkdmlzZSB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1h aWwsIFRoYW5rcy4gDQoNClJpc3BldHRhIGwnYW1iaWVudGUuIE5vbiBzdGFtcGFyZSBxdWVz dGEgbWFpbCBzZSBub24gw6ggbmVjZXNzYXJpby4NCg== --_000_9a76a02ed7c34f0e922a33fac96eff4bTELMBXB02RM001telecomit_ Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3Nj aGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9 IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxt ZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRl cmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAy IDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OiJTZWdvZSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyO30NCi8qIFN0eWxlIERlZmluaXRp b25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21h cmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlmIjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVl Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5 cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb0FjZXRhdGUsIGxpLk1z b0FjZXRhdGUsIGRpdi5Nc29BY2V0YXRlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiVGVzdG8gZnVtZXR0byBDYXJhdHRlcmUiOw0KCW1hcmdpbjowY207 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTo4LjBwdDsNCglmb250LWZh bWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNwYWNlO30NCnNwYW4uU3Rp bGVNZXNzYWdnaW9EaVBvc3RhRWxldHRyb25pY2ExOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMx RjQ5N0Q7fQ0Kc3Bhbi5TdGlsZU1lc3NhZ2dpb0RpUG9zdGFFbGV0dHJvbmljYTE5DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLlRlc3RvZnVtZXR0b0NhcmF0 dGVyZQ0KCXttc28tc3R5bGUtbmFtZToiVGVzdG8gZnVtZXR0byBDYXJhdHRlcmUiOw0KCW1z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiVGVzdG8gZnVtZXR0byI7 DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJJ VCIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgY2FuIGFsc28gaGVscCBvbiB0aGlz IHRvcGljLCBzZWVuIG15IGV4cGVyaWVuY2Ugd2l0aCBJUFBNIG1hcmtpbmcgbWV0aG9kb2xv Z2llcyBhbmQgYXMgYSB0ZWxjbyBkZWxlZ2F0ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+R2l1c2VwcGU8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNv bGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtTZWdvZSBVSSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5EYTo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBRVUlDIFttYWls dG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+UGVyIGNvbnRvIGRpIDwvYj5Sb25pIEV2 ZW48YnI+DQo8Yj5JbnZpYXRvOjwvYj4gZ2lvdmVkw6wgMjMgbm92ZW1icmUgMjAxNyAwNzow OTxicj4NCjxiPkE6PC9iPiBNYXJjdXMgSWhsYXI7IEVnZ2VydCwgTGFyczxicj4NCjxiPkNj OjwvYj4gU2FsdmF0b3JlIExvcmV0bzsgQnJpYW4gVHJhbW1lbGw7IE1hcmsgTm90dGluZ2hh bTsgUVVJQyBXRzxicj4NCjxiPk9nZ2V0dG86PC9iPiBSRTogU3BpbiBiaXQgZGlzY3Vzc2lv biAtIHdoZXJlIHdlJ3JlIGF0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPkkgd2lsbCB3b3JrIHdpdGggQnJpYW4gYW5kIE1hcmN1cyBv biB0aGlzIGRyYWZ0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj5Sb25pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAw Y20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6 c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+IFFVSUMgWzxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0 Zi5vcmciPm1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxm IE9mIDwvYj5NYXJjdXMgSWhsYXI8YnI+DQo8Yj5TZW50OjwvYj4gPC9zcGFuPjxzcGFuIGxh bmc9IkhFIiBkaXI9IlJUTCIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPteZ15XXnSZuYnNw O9eTIDIyINeg15XXkdee15HXqCAyMDE3IDE3OjU4PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PGJyPg0KPGI+VG86PC9iPiBFZ2dlcnQsIExh cnM8YnI+DQo8Yj5DYzo8L2I+IFNhbHZhdG9yZSBMb3JldG87IEJyaWFuIFRyYW1tZWxsOyBS b25pIEV2ZW47IFFVSUMgV0c7IE1hcmsgTm90dGluZ2hhbTxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogU3BpbiBiaXQgZGlzY3Vzc2lvbiAtIHdoZXJlIHdlJ3JlIGF0PG86cD48L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGksPG86cD48L286cD48L3NwYW4+PC9w Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5KdXN0 IGNoaXBwaW5nIGluIHRvIHNheSB0aGF0IEnigJltIGhhcHB5IHRvIHdvcmsgd2l0aCBCcmlh biBvbiB0aGlzIGRyYWZ0Ljxicj4NCjxicj4NCi9NYXJjdXM8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPg0KT24gMjIgTm92IDIwMTcsIGF0IDIy OjUxLCBFZ2dlcnQsIExhcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpsYXJzQG5ldGFwcC5jb20i PmxhcnNAbmV0YXBwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiPk9uIDIwMTctMTEtMjIsIGF0IDE1OjIyLCBSb25pIEV2ZW4gJmx0OzxhIGhyZWY9Im1h aWx0bzpyb25pLmV2ZW5AaHVhd2VpLmNvbSI+cm9uaS5ldmVuQGh1YXdlaS5jb208L2E+Jmd0 OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtmb250LXZhcmlhbnQt Y2Fwczogbm9ybWFsO29ycGhhbnM6IGF1dG87dGV4dC1hbGlnbjpzdGFydDt3aWRvd3M6IGF1 dG87LXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOy13ZWJraXQtdGV4dC1zdHJva2Ut d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHls ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv bnQtZmFtaWx5Ok1lbmxvLVJlZ3VsYXIiPkkgdGhpbmsgdGhlIGRlY2lzaW9uIHRvIG5vdCBk aXNjdXNzIGl0IGF0IHRoZSBpbnRlcmltIGlzIGJhc2VkIG9uIHRoZSBvYnNlcnZhdGlvbjxi cj4NCnRoYXQgdGhlIHJlZ2lzdGVyZWQgYXR0ZW5kZWVzIGF0IHRoZSBpbnRlcmltIGFyZSBw cm9iYWJseSBub3QgcmVwcmVzZW50YXRpdmU8YnI+DQpvZiB0aGUgb3ZlcmFsbCBXRyBjb25z dGl0dWVuY3kgLSB3ZSB3YW50IHRvIGdpdmUgYWxsIHNpZGVzIGFuIGFiaWxpdHkgdG88YnI+ DQpwYXJ0aWNpcGF0ZSBlcXVhbGx5IGluIHRoZSBkaXNjdXNzaW9uLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Ok1lbmxvLVJl Z3VsYXIiPltSb25pIEV2ZW5dIFRoaXMgaXMgd2h5IHdlIGhhdmUgcmVtb3RlIHBhcnRpY2lw YW50cyBhdCBJRVRGIG1lZXRpbmdzICEhISEhISEhPGJyPg0KWW91IGRvIG5vdCBoYXZlIHRv IGJlIGluIHBlcnNvbiB0byBkaXNjdXNzISEhITwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj50aGUgSUVURiAodmllIE1lZXRFY2hvKSBwcm92aWRlcyByZW1v dGUgcGFydGljaXBhdGlvbiBhdCB0aGUgbWFpbiBtZWV0aW5ncy4gQXQgdGhlIGludGVyaW1z LCBpdCdzIE1hcmsuIEl0IHNlZW1zIHRvIGhhdmUgbW9zdGx5IHdvcmtlZCBPSyBmb3IgcGFz c2l2ZSBwYXJ0aWNpcGF0aW9uIGR1cmluZyB0d28gb3V0IG9mIHRoZSBsYXN0IHRocmVlIGlu dGVyaW1zLCBidXQgd2UgaGF2ZW4ndA0KIHRyaWVkIHRvIGhvbGQgYSBkaXNjdXNzaW9uIHdp dGggbWFueSBhY3RpdmUgcmVtb3RlIHBhcnRpY2lwYW50cy48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogYXV0bzt0 ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogYXV0bzstd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6 IGF1dG87LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6TWVubG8tUmVndWxhciI+SSB0aGluayB3aGF0IE1h cmsgdHJpZWQgdG8gZXhwcmVzcyBpcyB0aGF0IHRoZSBkaXNjdXNzaW9uIG9uIHRoZSBTcGlu IEJpdCBjYW4gYmU8YnI+DQptb3N0bHkgZGVjb3VwbGVkIGZyb20gdGhlIChsYXJnZSBhbW91 bnQgb2YpIHdvcmsgcmVtYWluaW5nIG9uIHRoZSBiYXNlPGJyPg0Kc3BlYy4gVGhhdCBpcywg d2UgZG9uJ3QgaGF2ZSB0byBjb25jbHVkZSB0aGUgU3BpbiBCaXQgZGlzY3Vzc2lvbiBzaWdu aWZpY2FudGx5PGJyPg0KcHJpb3IgdG8gdGhlIGNvbmNsdXNpb24gb2YgdGhlIG92ZXJhbGwg d29yayAoYWx0aG91Z2ggd2UgY2FuKSwgc2luY2UgaXQgc2hvdWxkPGJyPg0KYmUgZWFzeSB0 byBtZXJnZSBhdCB0aGUgbGF0ZXIgc3RhZ2VzIGJlZm9yZSBoYW5kaW5nIHRoaW5ncyB0byB0 aGUgSUVTRy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTpNZW5sby1SZWd1bGFyIj5bUm9uaSBFdmVuXSBkZWxheWluZyB0aGUg ZGlzY3Vzc2lvbiBtYXkgcHJldmVudCB0aGUgYWNjZXB0YW5jZS4gJm5ic3A7SWYgcGVvcGxl IHdpbGwgcHV0IGVmZm9ydCBhdCBzdWJtaXR0aW5nIHRleHQgdGhlbiB0aGUgY2hhaXJzIHNo b3VsZCBhbGxvdyBmb3IgZGlzY3Vzc2lvbiBhbmQgbm90IGRlbGF5DQogdGhlIHdvcmsuPHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+SSBkaXNhZ3JlZSB3aXRoIHRoaXMgY2hhcmFjdGVyaXph dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPldoYXQgSSBzYWlkIGFib3ZlIGluIHRoZSBwYXJhZ3JhcGggeW91IHF1b3RlIGlz IHRoYXQgd2UgZG8gbm90ICpoYXZlIHRvKiBjb25jbHVkZSB0aGUgU3BpbiBCaXQgZGlzY3Vz c2lvbiB1cmdlbnRseSAqYWx0aG91Z2ggd2UgY2FuKi4gU3BlY2lmaWNhbGx5LCB3ZSBjYW4g YmVnaW4gKGFuZCBjb25jbHVkZSkgdGhlIGRpc2N1c3Npb24gb25jZSB0aGVyZSBpcyBhbiBh Y3R1YWwgcHJvcG9zYWwNCiB0aGF0IGFkZHJlc3NlcyB3aGF0IE1hcmsncyBvcmlnaW5hbCBl bWFpbCBvdXRsaW5lZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gbGFuZz0iRU4tVVMiPkxhcnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGh0bWw+DQoJ PGJvZHk+DQoJCTx0YWJsZSBzdHlsZT0id2lkdGg6NjAwcHg7Ij4NCgkJCTx0ZCBzdHlsZT0i d2lkdGg6NTg1cHg7IGZvbnQtZmFtaWx5OiBWZXJkYW5hOyBmb250LXNpemU6Ny41cHQ7IGNv bG9yOiMwMDA7IHRleHQtYWxpZ246IGp1c3RpZnkiIHdpZHRoPSIzOTUiPg0KCQkJCVF1ZXN0 byBtZXNzYWdnaW8gZSBpIHN1b2kgYWxsZWdhdGkgc29ubyBpbmRpcml6emF0aSBlc2NsdXNp dmFtZW50ZSBhbGxlIHBlcnNvbmUgaW5kaWNhdGUuIExhIGRpZmZ1c2lvbmUsIGNvcGlhIG8g cXVhbHNpYXNpIGFsdHJhIGF6aW9uZSBkZXJpdmFudGUgZGFsbGEgY29ub3NjZW56YSBkaSBx dWVzdGUgaW5mb3JtYXppb25pIHNvbm8gcmlnb3Jvc2FtZW50ZSB2aWV0YXRlLiBRdWFsb3Jh IGFiYmlhdGUgcmljZXZ1dG8gcXVlc3RvIGRvY3VtZW50byBwZXIgZXJyb3JlIHNpZXRlIGNv cnRlc2VtZW50ZSBwcmVnYXRpIGRpIGRhcm5lIGltbWVkaWF0YSBjb211bmljYXppb25lIGFs IG1pdHRlbnRlIGUgZGkgcHJvdnZlZGVyZSBhbGxhIHN1YSBkaXN0cnV6aW9uZSwgR3Jhemll Lg0KCQkJCTxicj48YnI+DQoJCQkJPGk+DQoJCQkJCVRoaXMgZS1tYWlsIGFuZCBhbnkgYXR0 YWNobWVudHMgaXMgY29uZmlkZW50aWFsIGFuZCBtYXkgIGNvbnRhaW4gcHJpdmlsZWdlZCBp bmZvcm1hdGlvbiBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBvbmx5LiBEaXNzZW1p bmF0aW9uLCBjb3B5aW5nLCBwcmludGluZyBvciB1c2UgYnkgYW55Ym9keSBlbHNlIGlzIHVu YXV0aG9yaXNlZC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGRlbGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGFueSBhdHRhY2htZW50cyBhbmQgYWR2aXNl IHRoZSBzZW5kZXIgYnkgcmV0dXJuICBlLW1haWwsIFRoYW5rcy4NCgkJCQk8L2k+DQoJCQkJ PGJyPjxicj4NCgkJCQk8Yj5SaXNwZXR0YSBsJ2FtYmllbnRlLiBOb24gc3RhbXBhcmUgcXVl c3RhIG1haWwgc2Ugbm9uICZlZ3JhdmU7IG5lY2Vzc2FyaW8uPC9iPg0KCQkJPC90ZD4NCgkJ PC90YWJsZT4NCgk8L2JvZHk+DQo8L2h0bWw+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_9a76a02ed7c34f0e922a33fac96eff4bTELMBXB02RM001telecomit_-- From nobody Thu Nov 23 07:40: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 ED7101293DA for ; Thu, 23 Nov 2017 07:40:41 -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=tessares-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pa_UFVWFdhCf for ; Thu, 23 Nov 2017 07:40:40 -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 0947712EAD5 for ; Thu, 23 Nov 2017 07:40:39 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id v186so17365299wma.2 for ; Thu, 23 Nov 2017 07:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=VkPD6Kk1bm1mUcrxQnKjVPYVb0GiqJoAWFZvIf/dyp8=; b=YJPYL3RXVKcLBgNEVsngp1CV6hIqHZoERqAn06LcYs0Q0y2BQ9Sp88yuFRJwUNs4yu dxtoVzbZCjk1fuk2wjSEFSF8wDrwL5r6Y5cEUBMDTYkmnvaT9/tG/lClwzI4Pa4lqgdi 3aXY182Ut8WlzEzkFzIJoFHPZLlV5D2f7G6engYmdi8bN4fLlittEbPPLbuwvaFCAVq7 UA3/DQLFiuGUDfQGu2B21smsnGw0z9J2Kre5jDAAiH/XZpm2Uzjvua7ymNJhMyhyoNC0 tYm+DjBzm156e7JbtUPu7CZPV9NuIe2bkJHdp4N2xLXPNeIlXLiZ3tPCSonDnXXE7DKz TB9Q== 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-language; bh=VkPD6Kk1bm1mUcrxQnKjVPYVb0GiqJoAWFZvIf/dyp8=; b=YrYCvLJAXbmv+zG8v5bhbTFfLlXrEwYY7cYXI3ZcJm4evi0Ek2AVkD/uc20HDa6PYe GImLFeDAJi5SZq9nn9PIbjuxvilbNNuzoTgtxXj3AhL0ASfGbSfFa1+fzRYjkHnxyihy a5XABETAXknit2D8DEKKEwi7GhNFQABtDrVX8Wod+BknuME1J/aVjlD/2DmSkvIBBv68 JcjceAerGBQ9fN+UstNxM4EeSULKSdat7r9L+zVuX2xUJm373adFG8yjGZDM4LuiXsmN hY9G7XWW7PE6p50fpOEVsuDzuELMJWn8FdNhoBFWAZQqgGsth1d4O+PZXOSYjM4dE1vw czyA== X-Gm-Message-State: AJaThX7vY7VYazrfbykmvtKmznJHa86W+KU2WdfbsX5gs2R5yINF1nbz D8Qif0X4D3jjDlBTyYRaM38sG42mxjc0vcX5zqNJG2FAJMeOywYBoJrwQElqMogOTGU7VrlJ63W Zvw== X-Google-Smtp-Source: AGs4zMbXPdvSvzw8F1evACLXyALLmb1FIJK/ZGkcIk1mCdUwWza3G9P/7KDe8Q7HyoCa39BBn8hoHw== X-Received: by 10.80.179.17 with SMTP id q17mr35377584edd.270.1511451638299; Thu, 23 Nov 2017 07:40:38 -0800 (PST) Received: from mbpobo.local ([2001:6a8:308f:2:d45a:9dfc:b3b7:44f9]) by smtp.gmail.com with ESMTPSA id p37sm13146652eda.96.2017.11.23.07.40.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 23 Nov 2017 07:40:37 -0800 (PST) Subject: Re: Multi-homed server To: Christian Huitema , "quic@ietf.org" References: <00728e49-b01f-5a82-6616-976dd97bdb10@huitema.net> From: Olivier Bonaventure Message-ID: Date: Thu, 23 Nov 2017 16:40:36 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <00728e49-b01f-5a82-6616-976dd97bdb10@huitema.net> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 15:40:42 -0000 Christian, > Many servers are multi-homed, can get packets from multiple addresses. > What should happen if a server gets an initial packet delivered on > address A, and later some packets delivered on address B? I don't think that servers should accept packets coming from clients on any of their addresses for a given connectionid. It would be better to have a specific exchange between the client and the server to use another server address, whatever the reason. This is one of the many use cases of the multipath draft : https://tools.ietf.org/html/draft-deconinck-multipath-quic-00 Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Thu Nov 23 23: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 708DB1201FA for ; Thu, 23 Nov 2017 23:55:48 -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 (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 nr5n4Q-9oDwk for ; Thu, 23 Nov 2017 23:55:46 -0800 (PST) Received: from JPN01-TY1-obe.outbound.protection.outlook.com (mail-ty1jpn01on0135.outbound.protection.outlook.com [104.47.93.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EC4D129B1D for ; Thu, 23 Nov 2017 23:55:46 -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=myaZDfxLugAGTQl+3GzZjzB7wJA54crMh9YW/5qFL48=; b=cmKvY5zvw/YS4P7rMHmHkADLNcojM78KXqo8IdFcpdxio3N/YpL9+H+Nu6xmA6y3394qpadXBurZETr3dx0o6rrgvD4DHdCxpqTTmvDHoZRmfNbU7jbSvur8mAdu9H5koDvuLQ+Zx8zoDsd/cdrDoKGRofo1LTt0EAfoWgki68A= Received: from [133.2.210.64] (133.2.210.64) by KAWPR01MB0243.jpnprd01.prod.outlook.com (10.161.28.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Fri, 24 Nov 2017 07:55:42 +0000 Subject: OT (was: Re: Spin bit discussion - where we're at) To: "Brian Trammell (IETF)" , Eliot Lear Cc: Mark Nottingham , QUIC WG , Lars Eggert , Stephen Farrell References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <253F0249-3FCB-4543-9DB6-BA4F5ABA84CA@mnot.net> <918BF809-338D-4FE9-A7B8-887E532C7FA8@trammell.ch> From: =?UTF-8?Q?Martin_J._D=c3=bcrst?= Organization: Aoyama Gakuin University Message-ID: <99b87d26-93e5-a871-8499-312143c3a3a7@it.aoyama.ac.jp> Date: Fri, 24 Nov 2017 16:55:40 +0900 User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [133.2.210.64] X-ClientProxiedBy: TYXPR0101CA0009.jpnprd01.prod.outlook.com (10.168.40.147) To KAWPR01MB0243.jpnprd01.prod.outlook.com (10.161.28.142) X-MS-PublicTrafficType: Email X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:KAWPR01MB0243; X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0243; 3:/1tY59OhdxNILoGpjVNeQL4Hf00GjD9Cn9hzgterqV5IbMfNgB9PhrlIEOkt+Tud7GaN5PhaRJZYdQjxkJrvO/1/yjuiloHPR3YMyXJHigpvvqr1HKKyLsU3bvc6SWWOEf2/U7OCf0psrJMOhAo1Xw7SfmU70GNkmeN7H+xfMsyqHOq4XCMB6afiWqbNJ+5cfV2S0e8cXTCKsUDL7//63UMVPM34ch+8FrLeCmpoh/yzVbBp5GkU120UzK3Q60gS; 25:ViGanqxgohWkG4E/t9lhPm/uggOrUpISncvuwQ0ZfE+T5dnqJ82qIeij8+lh1mpEiQZiuC8RS0dJLgVn5nXONeuv6hIMsgajJ0ONGF3vOuXgFXsGQedvWvGo5hZDfQS4lr//9lanXHOTX44Hv8tAJ3+hL34j7coOnCVI8vhCLCfc8DVf5muFt0dQaj0so2Z5x8QktALAIiDHTUOlLRJ2hGhrsMGcH6N4AeI1JMpXj7CcVrsJxAAmTKEAMvsGxbqxdOJmvMSSo9+cjchmRkOro/44spOB4Y4CknxM6PZzy/hGZMf/65rPFq6dugoZufFmlGeS1wf7vfM+vpyP99G7ZewEh/Yx31gkfeUxW95zoVg=; 31:HhOrgupqjxnjSH6G3RDFE+D5NL9I9BVLFVHq+wSZP5sDQkFuXHG3un6pKOJB8YLOfQI0M1WkBc5dOnw8/kF8HlceWHu8XYgCUBqxr2W5whF2rZFR2mlhxCKaewMzZn3TgoWAs8uKssMGvuuTkWdVXChAtyaEpIGgNuY70eYKNe9HuB2LnzyVcBW8xieJ3bTAMowNziYJ2jj0gX1ERrTj4GRFgV6KURYM387HJfcyf/s= X-MS-TrafficTypeDiagnostic: KAWPR01MB0243: X-MS-Office365-Filtering-Correlation-Id: 48c99491-84c6-4e1b-d652-08d53310c36b X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(5005006)(8121501046)(10201501046)(3002001)(3231022)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201702281529075)(201703061421075)(20161123564025)(20161123555025)(20161123562025)(20161123560025)(6072148)(201708071742011); SRVR:KAWPR01MB0243; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:KAWPR01MB0243; X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0243; 4:MBEK3US6DSAD4lKZybvBt2+cvut8R9bBGyEsBObNNkFyBZbwfy8ICs8cmJqzwN8AQq428XagEBr3kFysJX8ucvj0FJzPz1/40S3dTEZuh9wAN/fcB/0t3lgG4pRjsbIOiI6UWxsXe1NOvgpo75EkQ1uHYYTfQ6j7syyMj4+Mw5XYhyV6LdEDsZMSZGBTVCMPaFu7yaAarJ/GelNRf8RVyc5e0MdI/go8lzVnW7//A3tcuog6bjD21ofYagHP8PgKYiWBDwRNaNqGGi7LrhUVNQ== X-Forefront-PRVS: 05015EB482 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(6049001)(6009001)(376002)(346002)(366004)(24454002)(189002)(199003)(2906002)(74482002)(3846002)(25786009)(6116002)(93886005)(4326008)(2870700001)(106356001)(53546010)(31686004)(64126003)(68736007)(53936002)(8936002)(105586002)(101416001)(54356999)(50986999)(65956001)(65806001)(66066001)(76176999)(110136005)(33646002)(47776003)(189998001)(508600001)(54906003)(81166006)(16576012)(305945005)(49976008)(16526018)(65826007)(7736002)(50466002)(67846002)(90366009)(6486002)(42882006)(31696002)(36916002)(5660300001)(23676004)(2486003)(83506002)(81156014)(52146003)(58126008)(86362001)(8676002)(52116002)(786003)(97736004)(2950100002)(3940600001); DIR:OUT; SFP:1102; SCL:1; SRVR:KAWPR01MB0243; H:[133.2.210.64]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: it.aoyama.ac.jp does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=duerst@it.aoyama.ac.jp; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtLQVdQUjAxTUIwMjQzOzIzOlpYZzU4ako5OG1rTjluVEdtREpuZ1VqYWVC?= =?utf-8?B?eFpCMzhBZmJaSDVGaHYyekZRUlFGczliVUZJY1pPYURubitDV1lXSkhsRDRL?= =?utf-8?B?U2o0TXB0UHJLZkk3MGgxWHBNNngvSHR1a3N1SFg3Y3BNN3RMT1FSb3Z2VDVk?= =?utf-8?B?OEoybDBCUHZHeklKZXpjV2dCVUlXenhRMGVleXEyYnduWUg3R3dKV2JxdWV0?= =?utf-8?B?WjR3T0tIYzRCbWYzSGMySjI4MUdZL3JaOWFFUzNGRjhHbWFERUNrUno0cmsz?= =?utf-8?B?WVJYSU5LWUVKUFdFNWNmWUJtNzhqY1laM1dNWnFOOUFZbXFSOGF1c1NMU0Ju?= =?utf-8?B?aFc5U3JUUVZ5aXVDYXAvWVpUOVRCVmNKcnR1NjdidVNaN2ZFajJ4Skl1ak5U?= =?utf-8?B?REFEL2FCK2lvM2JQSFhGdEJVaGIzUXhHQTVqZHFJS05DcmwyVDIybWNpUW54?= =?utf-8?B?L3JGVlZhOGxLUHg0bTJOTnc5OTh4ckRTVVp4NW5EaXBQTEZGWmM4Q3cxZDdP?= =?utf-8?B?OFBiT0NEZTNQdjlsTGtQZklmTlRnSk5FZEtHNk9hOXZTY055TkkrdHArVCtp?= =?utf-8?B?QWVtYW1OUmpkSUJvekgxc0NrQ0NnN291dDF0UUFCaGFQYVNVV2p1dXpQYllD?= =?utf-8?B?NXExa1QyRGc3RFVtMW15QzBxNkt5UVVaeFM1eVRTemJFY0RReXhPUUFMRThX?= =?utf-8?B?QlE5Z01YdmdkYUpZV0ZYRkdsc0ZsbERLOEc0TU9rS1F1ejZUTlQzekxLZUk2?= =?utf-8?B?RkZ0OUgyVUkrNmdubjFPMVl0QnI3bTYvUnhsUldzOTU4M0F0bm9ZWE5iK2xF?= =?utf-8?B?aVptTkUwTURwZlFhTlF2V3hHc0tGOU9tNVgrcEdsMEpWK2pLOVlyUWp1aXMx?= =?utf-8?B?Q01vQVQ3RFNNMUVqSytYZlJUUXd1QkhzdnIzQmdjdFIxM1pHbnoyZmVJamtK?= =?utf-8?B?aU5pYmNkRmNxZ3BiOWFaRDBkbE5hNEd0R2ZjUFZIdEdqNk45WDZ6cFd2MFUx?= =?utf-8?B?WEw0SG1vTVpyKzE3d3UxQzBCNkhDbFVhbnVOTDhpY2V0TWJnQkFtanJ1Q1pH?= =?utf-8?B?eHl1amRTVUQyVVplK0lvL1pFZkdrcVpqN1J5YVMwZEtTVkRha29WM1ZJd1NW?= =?utf-8?B?MWZiZnV5K3R4ZDJSaTJxUjR0SklnNTU1YlJtM1ErM1hxUnZMakNlc0Vwd0ZU?= =?utf-8?B?UW5qc1lTZkVoQXF1NEtqeDdNNGg1RW5qaTIyMENtQUpiM3IveU1YT3RDTENJ?= =?utf-8?B?cEZWMERHdW9qb2N2OURTWVkyVDlvc21LVFJGT21ITHNiOFpMSUw4RmpFZmkw?= =?utf-8?B?cG5YL2s2K2VMWld3RTJYWnd0Rzg3ampxL2sybFo0V3diKzlhb3pITGRmeVky?= =?utf-8?B?djhYRlU3RTRiWFp5Rzg0UWdhdG5Eakx1Vll1TGhOaU0vdUV4dmEzSnBqWHZH?= =?utf-8?B?bU5lNHQ2WElDb280SmJjZHhpd1pMNnVFS2JGOU85VmplcU1jamRGWHVNR3E1?= =?utf-8?B?Y2sxeGZVOWdsamJnTzR0bXQ2N0pJMU83NDNLMlpmajBLRXZsU0w4YkxMQTYz?= =?utf-8?B?dllTV0RjUjMrOThmbURISHBHNWM4QW0xcTEzVXQ5OGlRbm1XK3JRNkZTaTk2?= =?utf-8?B?eDJuaENBdUlRWStVU2tKSEpJZ0MweTNQdTNaWVhJci81MlN4SFpWdU5GeGJI?= =?utf-8?B?N1JTWGRQL0pTM0hucVJvV2tyazAwYmh4SkRUS2lMYi9Bck9lWGJERUVpeDlm?= =?utf-8?B?eUZHREt0djlXVUYzRXNhd0MrcTIxY2o5d0ZrWWNXYUxhVG0wWVpISHhCNUNE?= =?utf-8?B?SFpYSlJBRFprTjFkeTNkTXcxaVlkUGdMR3E4dnJLS2lSY0thZTlJUVlzaTAw?= =?utf-8?B?OGdmbVdaZmpaSVQ5ZG5xV2Y0YzNEaUZDeHVJSFdmd2NUWkJsSndDR1JDdU1N?= =?utf-8?B?WkpKcTYxdHU3Ti80TmMxUkxOUkgyUDl3RGQzL2F0L1BTWU5wRFNSbGdNS2Nm?= =?utf-8?B?d0diOGRoZldjdmNpdTE1dWZWeFVnQVB5cytMQT09?= X-Microsoft-Exchange-Diagnostics: 1; KAWPR01MB0243; 6:CIskF8vNIzGr0UNqLspohYc1dxDt6j3yHOkg5gISF/18x24I5MUGJn7yBLJUzAVUNS0WI/cK0tE5RXdD0srP8eK5SHDrn7r9uhbs1YjUSFl10yOp0Y39LV/XbCz+QTLimSYm/2HLhdeB8kYQs/5EJ7AYaycJELYlDaQdBkUbe7ffrlXblagbER/E0ZNmjh9/TpRN2hJHOK1TC9MV/pROxkzzXvV6vUnT9pRj9okKKW9fS7YFnel2fyMXjF2LaXuxyMIRHJjqbMoshwISlI1coanmCjhzPSZjjIJ49svhlKqzgZm1ZsP5ZlS/C4cAK7qAWzsWvWgrzFyDGXvUCNRRIOdDfjhggLkiWtyQr6jsfVY=; 5:iM/hjhWcmpOJnO88Y1p/Uu8zaPKp84ciUrjyY9EbIg8givs3CWMlF6pogRwUxcCJFyOtwNHyqFq93sxjRDyv/cjV6W5zcpzXgqA1b23LcNJxWsqDnXo7qv9cImvHGYX6qQwprc/igXx3kgUI3LDltVpWHvtJG6Rkb4vjC/4JQGk=; 24:1xt/jerGYOyxoJg167+6ySqDj73XZ7cZ1QSe3M1MFesXQEeNK7sv0FgQ3YLoARkBaw/TNmXxzGKFTkIhEC46k+9trib1P7y+0diaYuqv8YY=; 7:uqdajELwmMj1tWE2prv9ltuES/+LtUXLs7FShvqdG1OOLHSxVCzsLY7zMJYDsovUP6k9yF44fQT+OHnzx2UysRtYeDz6mTxQzPMutt7qdZ4+IFHUHMgsJnN19/JevRMRiV1cbQ2n172ZaGWTbm5XWTz+Cj58fCAO2zhZRm3Qx/3M5q1YuPji/VoRJcqpD39XYisWAchCe6ZzhQ3EscI4CYgMwr6vUVCwp1adZZlYHpi6odaJgezs0R+QObIWQreF SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: it.aoyama.ac.jp X-MS-Exchange-CrossTenant-OriginalArrivalTime: 24 Nov 2017 07:55:42.7660 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 48c99491-84c6-4e1b-d652-08d53310c36b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: e02030e7-4d45-463e-a968-0290e738c18e X-MS-Exchange-Transport-CrossTenantHeadersStamped: KAWPR01MB0243 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:55:48 -0000 On 2017/11/22 21:21, Brian Trammell (IETF) wrote: >>> 'Night. I'm off to enjoy the last nice day in Zürich. >> >> Is Armageddon coming? I missed the memo. > > It's twelve degrees and the sun is shining. in November! GO OUTSIDE! he yells to himself... As a native and long-time resident of Zürich, and for the benefits of those not familiar with its weather, I'd like to add that for Zürich, November means fog, lots of it. After that, for the following few months, usually until somewhere in March, the fog moves higher so that it's observable as a permanent cloud cover. So if there's sun in November, I agree with Brian that going outside is the only reasonable choice. Regards, Martin. P.S.: There are two main ways to escape the above predicament: a) Go above the clouds, e.g. skiing on weekends (that's one of the reasons Switzerland has mountains :-). b) Move somewhere else, (such as Tokyo, where I'm now) where winters are mostly sunny. From nobody Fri Nov 24 13:06: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 3731C1267BB for ; Fri, 24 Nov 2017 13:06:47 -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=tessares-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OJyq_TSrfy5Z for ; Fri, 24 Nov 2017 13:06:45 -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 7639D124205 for ; Fri, 24 Nov 2017 13:06:45 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id b189so24402373wmd.0 for ; Fri, 24 Nov 2017 13:06:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language; bh=ebMWFGBIPH4KVzYwt0eyxuXHMIEDM7wExLECmHk0HuM=; b=WmoP96UAd8FkHoiJMTNJq/O2bzFdNkrlcfsDm9hYQp45YZ0BjY/P1ulFDMDq6R7SAh UJTDZ6u0CgcbHiYJndnve/uXgwr+fLnIOU3D/OjqW7RpQGvKZfyPEntiX5md0gWEX66F mvv8TrqzPEUEyQM+7eTyuBo2GH+dptAjfEZYQMHW5L6MGBnalQqxKa+M1RymvuAYa2HO 8+UA8wxT9CE0tUUlenRKFteskL9obF8Ps55uQED1I2kd7o0yIeC/0gGpxZ439OWQbYUm HsQomN6eVoOMgon3QNB1nvFkccHW+1+3dw3ElI5HeQVsfyJLmV091b/KmU56VtWViLZU 6KyA== 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-language; bh=ebMWFGBIPH4KVzYwt0eyxuXHMIEDM7wExLECmHk0HuM=; b=rtpx+LSYSFmWv1QPGTuhG2bbrQlYUWIN2aW8bsUG6WRoReC0rwQZs04QIw7ORiiJDu bQsXaAb1poj1At5JnQy4oD5sDkOW9rSa6n1b1nhRV7B4EtMwjeuOena/0RyxMbO11AP/ AJisRy3bIjo2JHDfHYGVmMSQ4e1fQApVRsYPaTxMyVph9pWpChwZqRpodEMdAGKhiTrZ 5mAHW/dTD7JYrN7r/6NOdtjBfmD+3oPwdJ06/WYvaJA/9QR7NjvrCxIUWTcG+sUrJg3P ObEI3J/gSvzjwnjN0G3Wyv4x+Or+8qK2m9LhUCQRttdL4ap9yjrA8uLF3W6Je9cmy7dV OJ0g== X-Gm-Message-State: AJaThX6UAqMWBKI4LijpxA1i0sNwuJaPshGEASJWt/3IRTScFlXdem+q i7CNxcXi3nc8Kxraky6zQ7oqq+5BVgXq2z/VtPphPRkZ7u76tsnCrs7+oVs+ZRG84708YKZZckO 9Hw== X-Google-Smtp-Source: AGs4zMY1I+15AEo9nDu4ZPGsegRiVuCddx7wJishknPgHZtNrmJdGVuPEArIzjL0tHn+lQvd0VlkQQ== X-Received: by 10.80.142.88 with SMTP id 24mr42376277edx.153.1511557603702; Fri, 24 Nov 2017 13:06:43 -0800 (PST) Received: from [192.168.1.32] ([87.66.240.203]) by smtp.gmail.com with ESMTPSA id m31sm15391969ede.27.2017.11.24.13.06.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 24 Nov 2017 13:06:43 -0800 (PST) Subject: Re: reserved bits for spin bit, etc. To: Christian Huitema , "quic@ietf.org" References: From: Olivier Bonaventure Message-ID: <5108b3b9-d374-0709-3e6f-57c3192469b8@tessares.net> Date: Fri, 24 Nov 2017 22:06:42 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 21:06:47 -0000 Christian, > We cannot quite agree on the spin bit, let alone further management > bits. On the other hand, we see that there is clear interest from > something like that with at least part of the WG, we want to see some > experimentation, and we understand that the specification can proceed > independently from the base protocol development. Hence, I would like to > make a modest proposal. > > Can we mark one or possibly two bits as reserved in the first byte of > the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be > ignored when receiving, MAY be used for experiments between consenting > nodes? Having some spare bits in the base header will clearly be useful. In addition to the discussion on the spin bit, let me also point that a proposed design for multipath quic also uses one of the spare bits in the public header https://tools.ietf.org/html/draft-deconinck-multipath-quic-00 Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Fri Nov 24 21:49: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 77087127201 for ; Fri, 24 Nov 2017 21:49:01 -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_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 daONSSM_-xGv for ; Fri, 24 Nov 2017 21:49:00 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 06DE11270A7 for ; Fri, 24 Nov 2017 21:48:59 -0800 (PST) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx16.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eITKT-0007oa-J4 for quic@ietf.org; Sat, 25 Nov 2017 06:48:56 +0100 Received: from [10.5.2.12] (helo=xmail02.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eITKQ-0005YK-OH for quic@ietf.org; Sat, 25 Nov 2017 00:48:39 -0500 Received: (qmail 20612 invoked from network); 25 Nov 2017 05:48:36 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.55]) (envelope-sender ) by xmail02.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Nov 2017 05:48:36 -0000 To: "quic@ietf.org" From: Christian Huitema Message-ID: Date: Fri, 24 Nov 2017 21:48:33 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: How many pongs can a pinger queue? X-Originating-IP: 168.144.250.190 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.50) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5vGTmcf7HP9ioSMou1TCSgYXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fvLFV52DoWOlibvc8JBzICgB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYdfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XIKcwsOsYjBjCZN249H7KzSqpR+WsWEoFdiO1WLSqm BLU7/VVsFmL0c8QpjXl23RbGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kA/d90Ehtjr2Rr9EnHIEiQBkONoJfh+XjGSeeT90H/uIGK BDhzwRiPjeK9enSUyuKbB9GOtUnHgtfUKhe6TEKMfWbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlWnDLQOyxbLULlVOPz78QcU/fFcHV2tQAVqGdj/zM7G/GArVPZLiHwNOHBLhYro6nu5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 05:49:01 -0000 The new PING frames can carry a byte string that shall be echoed by the recipient. Is there a limit to how many PING frames can be sent concurrently, or are recipients supposed to just queue them all before transmitting the corresponding PONG? By the way, the new PONG frame should be listed in the changes since draft 07, as well as the new BIDIR/UNIDIR stream ID. -- Christian Huitema From nobody Sun Nov 26 11:27: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 D42F71276AF for ; Sun, 26 Nov 2017 11:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.401 X-Spam-Level: X-Spam-Status: No, score=-5.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-2.8, 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 p1eUYffm6QFJ for ; Sun, 26 Nov 2017 11:27:27 -0800 (PST) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 BB3221201F8 for ; Sun, 26 Nov 2017 11:27:27 -0800 (PST) Received: from pps.filterd (m0049459.ppops.net [127.0.0.1]) by m0049459.ppops.net-00191d01. (8.16.0.21/8.16.0.21) with SMTP id vAQJPCXS026634; Sun, 26 Nov 2017 14:27:22 -0500 Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0049459.ppops.net-00191d01. with ESMTP id 2efwxq4yar-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 26 Nov 2017 14:27:22 -0500 Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id vAQJRLVd125751; Sun, 26 Nov 2017 13:27:21 -0600 Received: from dalint02.pst.cso.att.com (dalint02.pst.cso.att.com [135.31.133.160]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id vAQJRHbk125700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 26 Nov 2017 13:27:18 -0600 Received: from clpi183.sldc.sbc.com (clpi183.sldc.sbc.com [135.41.1.46]) by dalint02.pst.cso.att.com (RSA Interceptor); Sun, 26 Nov 2017 19:27:08 GMT Received: from sldc.sbc.com (localhost [127.0.0.1]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id vAQJR8pn016366; Sun, 26 Nov 2017 13:27:08 -0600 Received: from mail-green.research.att.com (mail-green.research.att.com [135.207.255.15]) by clpi183.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id vAQJQut9015831; Sun, 26 Nov 2017 13:26:57 -0600 Received: from exchange.research.att.com (njmtcas2.research.att.com [135.207.255.47]) by mail-green.research.att.com (Postfix) with ESMTP id 808DCE4897; Sun, 26 Nov 2017 14:25:47 -0500 (EST) Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njmtcas2.research.att.com ([fe80::d550:ec84:f872:cad9%15]) with mapi id 14.03.0361.001; Sun, 26 Nov 2017 14:26:55 -0500 From: "MORTON, ALFRED C (AL)" To: "Brian Trammell (IETF)" , "Eggert, Lars" CC: Mark Nottingham , QUIC WG , Stephen Farrell Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2ji92hnToyc90Kkv3NgVkreT6MgcbcAgAANHICAAAmFAIAABmyAgAZ8E+A= Date: Sun, 26 Nov 2017 19:26:54 +0000 Message-ID: <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [73.178.187.36] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-26_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711260271 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 26 Nov 2017 19:27:30 -0000 Hi Brian, Stephen, Lars, Mark and all, one join, one suggestion, and one question below. see [ACM] > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell > (IETF) > Sent: Wednesday, November 22, 2017 5:59 AM > To: Eggert, Lars > Cc: Mark Nottingham; QUIC WG; Stephen Farrell > Subject: Re: Spin bit discussion - where we're at >=20 > hi Lars, >=20 > > On 22 Nov 2017, at 11:35, Eggert, Lars wrote: > > > > Hi, > > > > On 2017-11-22, at 11:01, Stephen Farrell > wrote: > >> What I thought was being requested and what I do think is reasonable > >> is to document a privacy analysis for any quic protocol bits that are > >> visible to the path. Whether or not some or all of that text ends up > >> in some RFC is another day's work. > > Lars wrote: > > for the Spin Bit specifically, the intent was to permanently capture > the analysis the DT has done, so that when others review the proposed > Spin Bit specification, they can take that as a given and direct any > further analysis to other aspects. It made sense to the chairs that that > specific analysis should become part of the Spin Bit specification. I > think we'd be open to a discussion on whether a broader document > analyzing the QUIC wire image would be a better home for this. The main > point is for the work that the DT has done to be documented. > Brian wrote: > Okay. That's somewhat more reasonable than what I read the ask to be > ("we're going to gate this on the people who care about this doing some > non-trivial amount of work"). Those of us who volunteer (help, please, > anyone? :) ) can certainly pull together what we have in a single I-D > and ask the WG what more it thinks it needs. To me all this seems pretty > clear, but I've been working on this topic for a while. [ACM]=20 Having reached the end of the "Thanksgiving thread", I'm scrolling back a few pages to join the task of=20 permanently capturing the work of the DT in an I-D (at least): There should be lasting value in some of our findings and IMO they are worthy of a persistent reference. > Lars wrote: > > For proposals other than the Spin Bit (I think I have seen individual > contributors at least mention "loss" and "congestion" bits, but without > much detail), we wanted to clarify that we'd like to see an analysis and > discussion of their privacy aspects to roughly the same degree as the DT > has performed for the Spin Bit proposal. >=20 [ACM]=20 I suggest that this might be a different I-D, at least to start. Question: Is there a privacy analysis of present ECN available? (a search yielded many results with Missing: privacy) regards, Al From nobody Sun Nov 26 15:34:01 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 88B0412025C for ; Sun, 26 Nov 2017 15:33: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, 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 fPY5XSsr6moL for ; Sun, 26 Nov 2017 15:33:58 -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 291B71200C1 for ; Sun, 26 Nov 2017 15:33:58 -0800 (PST) Received: by mail-ot0-x22d.google.com with SMTP id d27so22740276ote.11 for ; Sun, 26 Nov 2017 15:33:58 -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=YXxitwjty6ATydDcQRBKfcu1WUCb4P6QTckVkQ4QRg8=; b=L5WsJxg2/YLGVOgll91ORhe3bMqf2xZoLSded69B3gc0B6Cb4bQNtHqfml2lrrR7q7 oOQCi/cFJ6J8gQ+89pRWt4qeXQlH5zEh4bP1XahFCtUqR6x/1VQsmz/9GG8K9dVn7NcQ wEJgCyTLdUIsNXSHu7DvZBN2At5VPVA6ii+fcs2YXslVvfnFu900pEyovy+oicixbOwe XijV6Ck3SE5GIGYLErh7+DEuyKxPJMlTvHWSlDdX+293WNX/7w8FHhlU0rWFicutD1DM 0Z4mA1B0O7GGG3QSstprj1cx8Gdj5JrtV/KLsxIvg4HDgmZTwS/OTVQd38heZtsm/xkV Uzqw== 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=YXxitwjty6ATydDcQRBKfcu1WUCb4P6QTckVkQ4QRg8=; b=LzRzW8cd3uS1OuVrV0ZJgdk63537lObYWZp8rOwx9OXq/ad/KDpTY8kf7y+VZOMbyo qtkJkAc4KXfMMyJA2HabfmvFhxzprZL/8qqHTErGNZgJWGh25YkDzRzV5qNZoy9g2kBc BJi5LuRo62pjrxO8JkY/N5TW+0SQyrYrPeR7+zGNeG4F+6623yxt/q+u/P+en6dL0Emc RmfHd7bj6m/C1vUvolGZ06IAhTMQWaf/L3/UAfwsJZb8/xvjXc9P66pX+u+wGSv0JZZ3 1U5alo71MAwOqvVoxk2myA0ZAK2oZvjSmqSAryxVfVqkk1/FlYy6LKw/iCW9mVA0I8T4 pGww== X-Gm-Message-State: AJaThX4VkC9djvPP7T4biSasc2XOA0r+Fz+UIjJQGcU/gb18ZBj7CsFw oYI0L/M+dt/lvOGnt/NMAwaVxtyuYuqLVqrafHZeZA== X-Google-Smtp-Source: AGs4zMZEAp1J+eJrQklnwRyv3aj8ojl4dUQyKkm8/GP/fV2rpY1inf2R+UxezJ/Us9mQqpDlCSpI+TgUYDCHUx7R1Yk= X-Received: by 10.157.67.146 with SMTP id t18mr26082414ote.103.1511739237460; Sun, 26 Nov 2017 15:33:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Sun, 26 Nov 2017 15:33:57 -0800 (PST) In-Reply-To: <5108b3b9-d374-0709-3e6f-57c3192469b8@tessares.net> References: <5108b3b9-d374-0709-3e6f-57c3192469b8@tessares.net> From: Martin Thomson Date: Mon, 27 Nov 2017 10:33:57 +1100 Message-ID: Subject: Re: reserved bits for spin bit, etc. To: Olivier Bonaventure Cc: Christian Huitema , "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 26 Nov 2017 23:33:59 -0000 On Sat, Nov 25, 2017 at 8:06 AM, Olivier Bonaventure wrote: > Christian, > >> We cannot quite agree on the spin bit, let alone further management >> bits. On the other hand, we see that there is clear interest from >> something like that with at least part of the WG, we want to see some >> experimentation, and we understand that the specification can proceed >> independently from the base protocol development. Hence, I would like to >> make a modest proposal. >> >> Can we mark one or possibly two bits as reserved in the first byte of >> the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be >> ignored when receiving, MAY be used for experiments between consenting >> nodes? > > > Having some spare bits in the base header will clearly be useful. In > addition to the discussion on the spin bit, let me also point that a > proposed design for multipath quic also uses one of the spare bits in the > public header > > https://tools.ietf.org/html/draft-deconinck-multipath-quic-00 I don't think that this is a good design. I think that we definitely need to discuss the separation of the packet number space when it comes to multipath, using the connection ID is superior to adding another byte to the header. For one, it's something we want to change anyway. From nobody Sun Nov 26 15:36: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 8F11412025C for ; Sun, 26 Nov 2017 15:36:26 -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 ds9V6xb9y7xb for ; Sun, 26 Nov 2017 15:36:25 -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 63A601200C1 for ; Sun, 26 Nov 2017 15:36:25 -0800 (PST) Received: by mail-oi0-x234.google.com with SMTP id h81so18237668oib.8 for ; Sun, 26 Nov 2017 15:36:25 -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=o0Ao4kZQgeekiciLGSOSETMuNzzbUD/WgBCYY/DqjEk=; b=eP6R2XQVljpSi4DheUIWAy5ka5Ju2MirRehR47spNx4xA6LWaQ/2kTRtEZGV7GM6lp 18zOheQ6za+0lTjwmix28o4lBM3fdejlCjJ4zNVsks/9f7kPTZk9Im9ArFlWoz76q/qZ be31e+hjNqHxOSGh9JWs43q+MrfHxdx21IdgWAOh4xC3WhwC+JDf9lNI8XP0Kpdv4v4v NKwclXXiDSctuiq3Puy+HSTigoNgPRncMYSbyIehQiBAwNNNVNMUsuBCK6+m+hr3EuZF IvHlbQrc9FOHoPkzgk0hrjNZyj3O0hIxvHO8MKYJ29jIMN35lEog4EWXC5vMnXpePc/S nTlQ== 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=o0Ao4kZQgeekiciLGSOSETMuNzzbUD/WgBCYY/DqjEk=; b=PW0VqZU5uTb7njkuJky8MSwIxVbKsS/6zpKRhvfT4xMH7yaV3Qu6295tICueroFF6d ApiR00eurKdCnYzzYr+AbDWXTjhMFtFVDCraZ2oQHopaD3c1s0BHL1ZJnQQ3vOrj4u1j OJb+XgrJ0evbWc+uc/jsJg9GB1ITvgtOzvmxpNGdagy0VFRNEj6YPFgRp88DknVwoDsm 64qr90I5lwmaVRjAOaDPhz8HmSS5CCBX+F32OY/xNpcQzmefFejO1aTHehYVspl2mrGX m5Tt45V9rTKnLiz1v/kPbg6QUHhA6hwGw0DPocfFcpvhoCZocgHolxEO8DlHgQzrwOOb Caig== X-Gm-Message-State: AJaThX46zfCTm6O1R3KZzORvbjMrFnneKxXkUfdqb8pW+sOpjuJvOnCR pQnlr/qWgRldRbrJnKuRx0zR2btAGgI7HW5KSSF/PA== X-Google-Smtp-Source: AGs4zMbSCyeD1rSTKsYclytKN29o7vDGVculzNltSEw6ffxXuDRANFc0Q9dai2JzUt/kY7DHBtr5uOvjMA3dA0g1jR0= X-Received: by 10.202.10.68 with SMTP id 65mr14745263oik.84.1511739384713; Sun, 26 Nov 2017 15:36:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Sun, 26 Nov 2017 15:36:24 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 27 Nov 2017 10:36:24 +1100 Message-ID: Subject: Re: How many pongs can a pinger queue? To: Christian Huitema Cc: "quic@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 26 Nov 2017 23:36:26 -0000 I would say respond to every one. If this gets too much, that is what we have ENHANCE_YOUR_CALM for. Oh, wait, we don't have that. In any case, if this is too much, like anything else where your peer starts abusing mechanisms in ways that indicate that they want you to do unreasonable things, use an error code. On Sat, Nov 25, 2017 at 4:48 PM, Christian Huitema wrote: > The new PING frames can carry a byte string that shall be echoed by the > recipient. Is there a limit to how many PING frames can be sent > concurrently, or are recipients supposed to just queue them all before > transmitting the corresponding PONG? > > By the way, the new PONG frame should be listed in the changes since > draft 07, as well as the new BIDIR/UNIDIR stream ID. > > -- Christian Huitema > > From nobody Sun Nov 26 22:05: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 9F0CF1277BB for ; Sun, 26 Nov 2017 22:05:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Cv9CGREpwane for ; Sun, 26 Nov 2017 22:05:27 -0800 (PST) Received: from mail-yb0-x22f.google.com (mail-yb0-x22f.google.com [IPv6:2607:f8b0:4002: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 69B2C126D05 for ; Sun, 26 Nov 2017 22:05:27 -0800 (PST) Received: by mail-yb0-x22f.google.com with SMTP id e83so10155449yba.4 for ; Sun, 26 Nov 2017 22:05:27 -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=OkcqoGsUb9nKPzTjvBBYMFWPqpivW3GYnxjN7sCRUeA=; b=b/7DJkjQXDJaWnBR0B5gko6Jum1Iyq/15Y11a2SRDeirva/xtIHBz+wTE3teAOemMa jQQomFgmi1+lNBitarQl4EKDJ1jVEaSv4xJktSBHSvycK26OYHpdurog1PBOsGIGh5Kk Ou8L78SeOkpfJsuK/+F9Kqk1ucB2avh+zd6vQPuulZ1Sl2HK1X6AY2/qShxPBYw+A461 Pr7Kex8IWl1Sg98I5iiEG8uFmYfv/cQO1RHsu/CTw2mnEycYqykRnXOpAjtKbiX5Ku67 r8es15GMGc+BSnuWmur+8CL8CuTk4S3NqtAsRp58upbTBHhWQozyBs2JYI13nInk9bdN EuTA== 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=OkcqoGsUb9nKPzTjvBBYMFWPqpivW3GYnxjN7sCRUeA=; b=Zsi8KWjLZiDa0UifwopUvQ4y3KZn4ByJLZGO3R/CiREbwIP5zBxRTVCr/J98NtfWH1 VxbQD8Hgg3+IXGkW5tR7uCZznIg9nEvK0idDWb5zyUD1nWvxU7+nRuJFrJJU8issIXvx CjrftsMrpAk4uNme+exA2YetArGh/idhiO32aAs1XUwWTVSafM3YCEQDjm/Vqbktdml1 tgdWTjb5NxQ7VUgoQo3sQWMQ9ggm2zVXSX0m7Y76gR1yVUV3t+YCkl8wPq5lKyl9pykO tkIMYE5O4xhRLdiEEOFTT1G16U68eB71R9ZMcSlP+UnvsyXR7WAv2cq0qIg5ypin9C0A q1Cg== X-Gm-Message-State: AJaThX5/7XrgRLWpiBP45LB7J9TycvbQY4nT0+sKH9ySxq9JNMV41ADn pqeJ33wFF0lX6YNmG0yHcH3lQbHFVzE3F3asw05AjA== X-Google-Smtp-Source: AGs4zMbL168Fvh+75uiR1mTXBnM1MqjjXPRFAN1q3WRpnMdEOp3NWZrsVbp1NDRoKdHqfG8PDf5JuCw/8m+mDWy2SVQ= X-Received: by 10.37.180.129 with SMTP id o1mr22206596ybj.398.1511762726240; Sun, 26 Nov 2017 22:05:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.90.134 with HTTP; Sun, 26 Nov 2017 22:05:25 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Sun, 26 Nov 2017 22:05:25 -0800 Message-ID: Subject: Re: How many pongs can a pinger queue? To: Martin Thomson Cc: Christian Huitema , "quic@ietf.org" Content-Type: multipart/alternative; boundary="f403045e6ee048c5b4055ef0b08f" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:05:28 -0000 --f403045e6ee048c5b4055ef0b08f Content-Type: text/plain; charset="UTF-8" Yup, I agree that the receiver should respond to every one. On Sun, Nov 26, 2017 at 3:36 PM, Martin Thomson wrote: > I would say respond to every one. If this gets too much, that is what > we have ENHANCE_YOUR_CALM for. Oh, wait, we don't have that. In any > case, if this is too much, like anything else where your peer starts > abusing mechanisms in ways that indicate that they want you to do > unreasonable things, use an error code. > > On Sat, Nov 25, 2017 at 4:48 PM, Christian Huitema > wrote: > > The new PING frames can carry a byte string that shall be echoed by the > > recipient. Is there a limit to how many PING frames can be sent > > concurrently, or are recipients supposed to just queue them all before > > transmitting the corresponding PONG? > > > > By the way, the new PONG frame should be listed in the changes since > > draft 07, as well as the new BIDIR/UNIDIR stream ID. > > > > -- Christian Huitema > > > > > > --f403045e6ee048c5b4055ef0b08f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yup, I agree that the receiver should respond to every one= .

On Sun, No= v 26, 2017 at 3:36 PM, Martin Thomson <martin.thomson@gmail.com= > wrote:
I would say respond to= every one.=C2=A0 If this gets too much, that is what
we have ENHANCE_YOUR_CALM for.=C2=A0 Oh, wait, we don't have that.=C2= =A0 In any
case, if this is too much, like anything else where your peer starts
abusing mechanisms in ways that indicate that they want you to do
unreasonable things, use an error code.

On Sat, Nov 25, 2017 at 4:48 PM, Christian Huitema <huitema@huitema.net> wrote:
> The new PING frames can carry a byte string that shall be echoed by th= e
> recipient. Is there a limit to how many PING frames can be sent
> concurrently, or are recipients supposed to just queue them all before=
> transmitting the corresponding PONG?
>
> By the way, the new PONG frame should be listed in the changes since > draft 07, as well as the new BIDIR/UNIDIR stream ID.
>
> -- Christian Huitema
>
>


--f403045e6ee048c5b4055ef0b08f-- From nobody Sun Nov 26 22:37: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 72FC5126C25 for ; Sun, 26 Nov 2017 22:37:04 -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 (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 MRS3xgqloExP for ; Sun, 26 Nov 2017 22:37:02 -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 843F8124B18 for ; Sun, 26 Nov 2017 22:37:02 -0800 (PST) Received: by mail-yw0-x234.google.com with SMTP id z125so10039952ywb.0 for ; Sun, 26 Nov 2017 22:37:02 -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=L1wQcryXqGvXgoJL+kgQAgfzgWUuxhldCh5dBLWga3Y=; b=ujH47cgeJVtKGGZM7peUOHn6EQXOaCFLnXscPvNvILg0Z2zoLV6BwI5YLtCmLyWSZD gyqBeqoxx5I2mFgrwPE5uyQbM5tkr7uR8xGtYKvSbVuhAl/5txFNgW8TJxfbz3qvCVOh Q/OEK5p6h8tG5Ufl56/4e38E7M416SYMFH68A36BaAxz2Qlj9dR76rxE3NM4ilt9PBYJ SniTXIbOc3QvTPfy6yda2VcIJ9GnVn+84Mtt69tsUnUQ2mx5zMiljRxvDPwOCwDAOAb7 iKuu1lZqz/fptJfCmcSjvo7xT1seNpFodIMIX0+sT8DY83Y4lyJqGqTRJhX8B+ReKDg8 oelQ== 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=L1wQcryXqGvXgoJL+kgQAgfzgWUuxhldCh5dBLWga3Y=; b=q90mf/7kCx8xHujs4vMtpAL/wR0M1LzCTReE8ELrx1kGTwJlghPgjK/7V7ZfwzOaXS M3U2COAbuseVwPBza7ZPdLIykwLU9pe/39TH5yBlAxZas6HC8TFb2iCgeS84QBOEpy5L F1pox+pAtJQbBfeY6NCckURCj/kZ0hV6fq0TMzenNt22fL1Az3ev3WJETxcgAerPG3PJ v4t86lqUgFztBs+XvuXbwxAIlSxFnxnIzCr1VWn3GgFro5Ec6z61shNzl9ANvbopYXwP kI/6TQo5ZABIWVRXFWCY0yj2cdXR73/3SKnS4/39tj445NWf8twGFX8sJc/xTqU0TYV8 F35A== X-Gm-Message-State: AJaThX72Eqkb4i26Y6EAAgZOBSDrTaReXbPyS0xkNArgTwJeJg34GbpU EHiAPYnvI260Q5AR3SWUo76OgvLDNk+nUu0hhcuWbQ== X-Google-Smtp-Source: AGs4zMaRig2R0l5HQ9/WBXlxsnTpdoOHOHxCBDUzM+cGghu5CQwS+TACNGZiHIiVyILpT7e5YtmJhTSDv1MktSe5trQ= X-Received: by 10.13.229.193 with SMTP id o184mr3453679ywe.256.1511764621138; Sun, 26 Nov 2017 22:37:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.90.134 with HTTP; Sun, 26 Nov 2017 22:37:00 -0800 (PST) In-Reply-To: References: <5108b3b9-d374-0709-3e6f-57c3192469b8@tessares.net> From: Jana Iyengar Date: Sun, 26 Nov 2017 22:37:00 -0800 Message-ID: Subject: Re: reserved bits for spin bit, etc. To: Martin Thomson Cc: Olivier Bonaventure , "quic@ietf.org" , Christian Huitema Content-Type: multipart/alternative; boundary="94eb2c081d743b207f055ef12171" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 06:37:04 -0000 --94eb2c081d743b207f055ef12171 Content-Type: text/plain; charset="UTF-8" +1 to what Lars said -- we can reserve a bit but if we do, we must GREASE to ensure that this bit remains usable in the future. That said ... If this is for experimental use, what precisely is the experiment that we expect to get conducted? Bits if offered can and will be used, so what potential outcomes are we expecting? Specifically, are we trying to figure out how to use these bits, whether to use these bits, or how many bits are needed? The answers to these questions will have bearing on what it means to reserve one or more bits. If the answer is "all of the above", then I'd like some more clarity on the framing of the problem before reserving anything. On Sun, Nov 26, 2017 at 3:33 PM, Martin Thomson wrote: > On Sat, Nov 25, 2017 at 8:06 AM, Olivier Bonaventure > wrote: > > Christian, > > > >> We cannot quite agree on the spin bit, let alone further management > >> bits. On the other hand, we see that there is clear interest from > >> something like that with at least part of the WG, we want to see some > >> experimentation, and we understand that the specification can proceed > >> independently from the base protocol development. Hence, I would like to > >> make a modest proposal. > >> > >> Can we mark one or possibly two bits as reserved in the first byte of > >> the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be > >> ignored when receiving, MAY be used for experiments between consenting > >> nodes? > > > > > > Having some spare bits in the base header will clearly be useful. In > > addition to the discussion on the spin bit, let me also point that a > > proposed design for multipath quic also uses one of the spare bits in the > > public header > > > > https://tools.ietf.org/html/draft-deconinck-multipath-quic-00 > > I don't think that this is a good design. I think that we definitely > need to discuss the separation of the packet number space when it > comes to multipath, using the connection ID is superior to adding > another byte to the header. For one, it's something we want to change > anyway. > > --94eb2c081d743b207f055ef12171 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1 to what Lars said -- we can reserve a bit but if we do,= we must GREASE to ensure that this bit remains usable in the future. That = said ...

If this is for experimental use, what precisely= is the experiment that we expect to get conducted? Bits if offered can and= will be used, so what potential outcomes are we expecting? Specifically, a= re we trying to figure out how to use these bits, whether to use these bits= , or how many bits are needed? The answers to these questions will have bea= ring on what it means to reserve one or more bits.

=
If the answer is "all of the above", then I'd like some = more clarity on the framing of the problem before reserving anything.
=


On Sun, Nov 26, 2017 at 3:33 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On Sat, Nov 25, 2017 at 8:06 AM, Olivier Bonaventure
<olivier.bonaventure= @tessares.net> wrote:
> Christian,
>
>> We cannot quite agree on the spin bit, let alone further managemen= t
>> bits. On the other hand, we see that there is clear interest from<= br> >> something like that with at least part of the WG, we want to see s= ome
>> experimentation, and we understand that the specification can proc= eed
>> independently from the base protocol development. Hence, I would l= ike to
>> make a modest proposal.
>>
>> Can we mark one or possibly two bits as reserved in the first byte= of
>> the QUIC header? Specify them as SHOULD be zero when sending, SHOU= LD be
>> ignored when receiving, MAY be used for experiments between consen= ting
>> nodes?
>
>
> Having some spare bits in the base header will clearly be useful. In > addition to the discussion on the spin bit, let me also point that a > proposed design for multipath quic also uses one of the spare bits in = the
> public header
>
> https://tools.ietf.org/html/d= raft-deconinck-multipath-quic-00

I don't think that this is a good design.=C2=A0 I think that we = definitely
need to discuss the separation of the packet number space when it
comes to multipath, using the connection ID is superior to adding
another byte to the header.=C2=A0 For one, it's something we want to ch= ange
anyway.


--94eb2c081d743b207f055ef12171-- From nobody Sun Nov 26 23:03: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 59D76126E3A for ; Sun, 26 Nov 2017 23:03: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 JFSzemyZys7q for ; Sun, 26 Nov 2017 23:03:21 -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 F0BB5124217 for ; Sun, 26 Nov 2017 23:03:20 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id EEB76340E2B; Mon, 27 Nov 2017 08:03:18 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.1700); Mon, 27 Nov 2017 08:03:18 +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, 27 Nov 2017 08:03:18 +0100 (CET) Received: from [122.29.177.43] (account ietf@trammell.ch HELO [192.168.11.19]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 37323273; Mon, 27 Nov 2017 08:03:17 +0100 From: "Brian Trammell (IETF)" Message-Id: <55F677B1-E18B-4F40-9A8E-28E4A24C562E@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_805B9938-3689-47E9-85E6-54E3313095E8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: reserved bits for spin bit, etc. Date: Mon, 27 Nov 2017 16:03:10 +0900 In-Reply-To: Cc: Martin Thomson , Olivier Bonaventure , "quic@ietf.org" , Christian Huitema To: Jana Iyengar References: <5108b3b9-d374-0709-3e6f-57c3192469b8@tessares.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:03:24 -0000 --Apple-Mail=_805B9938-3689-47E9-85E6-54E3313095E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, My take on this: > On 27 Nov 2017, at 15:37, Jana Iyengar wrote: >=20 > +1 to what Lars said -- we can reserve a bit but if we do, we must = GREASE to ensure that this bit remains usable in the future. That said = ... >=20 > If this is for experimental use, what precisely is the experiment that = we expect to get conducted? Bits if offered can and will be used, so = what potential outcomes are we expecting? Specifically, are we trying to = figure out how to use these bits, whether to use these bits, or how many = bits are needed? The answers to these questions will have bearing on = what it means to reserve one or more bits. >=20 > If the answer is "all of the above", then I'd like some more clarity = on the framing of the problem before reserving anything. It seems to me we have a concrete proposal on the table for exposing = latency information, a privacy analysis showing negligible marginal = risk, pretty clear indication of its utility in the Singapore and = post-Singapore discussion, and initial experimental indications from at = least one implementation that show that it does what it's supposed to. = The single implementation we have (Piet's) hacks a "measurement byte" to = the back of every header, short or long, which is not great for interop. = It would be nice to be able to interop implementations of the spin bit = (and spin-bit-consuming measurement tools) with some agreement as to = which bit we're flipping, so we can do more exploration of the corner = cases at a larger scale than is possible with a single forked = implementation. There's a higher bar for wire-image-impacting changes, = now, and it would be nice to collect larger-scale data on how the spin = bit works concurrent with the work we're doing to pull together the = requested document (the appearing-real-soon-now = draft-trammell-quic-spin), and subsequent discussion thereof. It also seems to me that there are several candidates for a second (or = even third) measurement bit: some form of ConEx-like refeedback, some = indication as to whether a sender is blocked (diagnostically useful in = its own right, as well as fixing one of the spin bit corner cases), = perhaps a second spin bit (though Piet's work to date indicates that = looking at the bottom N bits of the packet number is better for = correcting reordering error in spin bit measurement than a second = bit)... here there is less clarity, so having reserved measurement bits = for future experiments would be useful too. There's a question as to how many bits: I'll note that if we go to = varints for packet numbers -- which we really should -- then there are = five bits free in the short header now. We'll probably want to reserve = all of those for the future, regardless of how many of them eventually = get used for measurability, so they'll need to be greased somehow = anyway. Mark and Lars also pointed out that we can define one or more of these = bits for v1 fairly late in the game, especially for something like the = spin bit which is specifically designed to integrate with none of the = transport's machinery. Cheers, Brian >=20 > On Sun, Nov 26, 2017 at 3:33 PM, Martin Thomson = wrote: > On Sat, Nov 25, 2017 at 8:06 AM, Olivier Bonaventure > wrote: > > Christian, > > > >> We cannot quite agree on the spin bit, let alone further management > >> bits. On the other hand, we see that there is clear interest from > >> something like that with at least part of the WG, we want to see = some > >> experimentation, and we understand that the specification can = proceed > >> independently from the base protocol development. Hence, I would = like to > >> make a modest proposal. > >> > >> Can we mark one or possibly two bits as reserved in the first byte = of > >> the QUIC header? Specify them as SHOULD be zero when sending, = SHOULD be > >> ignored when receiving, MAY be used for experiments between = consenting > >> nodes? > > > > > > Having some spare bits in the base header will clearly be useful. In > > addition to the discussion on the spin bit, let me also point that a > > proposed design for multipath quic also uses one of the spare bits = in the > > public header > > > > https://tools.ietf.org/html/draft-deconinck-multipath-quic-00 >=20 > I don't think that this is a good design. I think that we definitely > need to discuss the separation of the packet number space when it > comes to multipath, using the connection ID is superior to adding > another byte to the header. For one, it's something we want to change > anyway. >=20 >=20 --Apple-Mail=_805B9938-3689-47E9-85E6-54E3313095E8 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlobuK4ACgkQihK3vwvq RqNEng//YuGd4zN2XpPwj97GNs691JZ9yNo4eR7x1rFLxoZKqa9rHzkQvHik2ZgG vqfmlgqzJe6yvchdsmBDyFiwyVC96psqXgoxXuhCo7VPLvZtkkAWilwcUkxkDLB9 eitYU3ZVjwzJ2hMUIYazGvytPof6Nh2xK0vaCN0j4vlws7Hw+VZ7Bo6kYhq3MbAj IGfBtdnwOvoFaTSDMdvr1sPDgG2zqkqBo8s3NbO9LyAXixQO24hxULSB1KDB7R4K pUf9uc2CYtlSaI4G7kDfMiJgpZAErqZuHJF+hJdZsSLKb5u6GojBAhkyHfP32DXM ITAbE/xhH2fcKoltu31ME8Kfmi1B2cUpodkLmtrfKR5h8eKHnF+CrnNarK/+SuL5 NMu5K3D/zffYDnIUJoJnJ2PqD+6xIFfrc1GrgC2uWCsjSf5ZbmiHEwqifMeCAAOj rkxOpSfF4cIAwsRaVL1A8GxlSGScbHIFPXGy7p4tYppuG+4xXdd6F+XsNzDz1wiB TsXKTPtOXP7c0gPkR4ihI3mzn5Ns3I79fDsbg9h8AxxZljUzEiuJ4GBje3f4xxb2 HrCd/8mEzw11qT4MxavADoval7ax3IXjHDssVDZ64/Z0jHWbZTRTXFr1eQqVpkpF AC4vcPCBxGDiX0xDhvhSiGRTgK23iX4KLH/LruuKgWeM/dMVYgk= =uREM -----END PGP SIGNATURE----- --Apple-Mail=_805B9938-3689-47E9-85E6-54E3313095E8-- From nobody Sun Nov 26 23:03: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 16156127B52 for ; Sun, 26 Nov 2017 23:03: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, 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 CMWDkrWZCj_X for ; Sun, 26 Nov 2017 23:03:44 -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 A2B5F124217 for ; Sun, 26 Nov 2017 23:03:44 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id x72so10181636ybg.11 for ; Sun, 26 Nov 2017 23:03: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=YmBG0v1fSR1ieEypstwRyHhSWK11yDA8Nr24ILZuNtY=; b=tbSTrthHWAT7zpmmfLVVoUZR131EHJT56v7us3HL/eAeTIq0KzLxYV5Y0ag1sMG2e/ cSBD2jwbOoiEKknzGYxyD8KCw9hwfdQa8/Hzmcd69u0jHpc3oZxvo9dDWD/o55qEQhmh kYjUOK2n06JQrKZp7o9YfHagrfc7xc8vnisj/jRi1cWDbgIw8xNuSabZUECkQlfLFm3k kHQ/2OWs19qjM6tZFJc7scGkFp+iFdeMvyowvqzBejkceU3/tAZWQmZGTBOm1xOTkY4d 0rHlkwEUAnkQkQGbRnoYmxIKQ77R96Z9/klXP4wOy4DDshrV0R1N6TbbMAitp1t7KpdR 5TzA== 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=YmBG0v1fSR1ieEypstwRyHhSWK11yDA8Nr24ILZuNtY=; b=ZbjCJiMTt7BnvkN4zU3Jm3seTJOFVdDLOdc+b76ArPfqNTqJXW3E9PMdS/tLxTKNgV ul0ZXQSuXLA9dAhWdsoguIl96CDGyjNC0aWxoFI7gwssTf8br+556UQPkNmpZdVBYPPk MObM4aSpn2C0HcZMC7loDwxQeXyP1wXfxkRi+Fax4guNZGfDgG9etqZde3R0ughL1Mv1 G9+Z+yDJ3im5TLY77GcvIuWErl3UKDxBku0R0hjnWy56N+s66aMaK8deCd+5ULCPHtRz 7jb3RI/lyws4omxjXXiYLD4yxULA1iujXlS76GmiKjZlSd5hpUWDLkwtnYI1sYLWAiEu mfOg== X-Gm-Message-State: AJaThX4nMjHqpT7E+hNSOKCNmeUhCj/a+i6atjlDAyZJ7jX5vq4tXXiD UXlYE5uB3kJ+bfz+OWEitn18tTiGp/ZzGD+pZ7cs4Q== X-Google-Smtp-Source: AGs4zMa7vQGzGmm/U9o3iDEOGEnfnUmIjUAxxvFzEGfAZV/oGxOEsK5kVUYbv7KExUj3jkXhLkKLHBthEwHXrnPqblU= X-Received: by 10.37.90.196 with SMTP id o187mr12302763ybb.290.1511766223220; Sun, 26 Nov 2017 23:03:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.90.134 with HTTP; Sun, 26 Nov 2017 23:03:42 -0800 (PST) In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> From: Jana Iyengar Date: Sun, 26 Nov 2017 23:03:42 -0800 Message-ID: Subject: Re: Spin bit discussion - where we're at To: "MORTON, ALFRED C (AL)" Cc: "Brian Trammell (IETF)" , "Eggert, Lars" , Mark Nottingham , QUIC WG , Stephen Farrell Content-Type: multipart/alternative; boundary="001a1140f596b8c0c5055ef18002" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:03:47 -0000 --001a1140f596b8c0c5055ef18002 Content-Type: text/plain; charset="UTF-8" In addition to how the spin bit can be designed and used, I'd like those taking on this effort to consider this question: Whatever network management problem you're considering solving with a bit, what does it take to solve this problem without the bit exposed? I'm asking you to consider "zero-bit" solutions, or at least for a cost/benefit analysis of developing solutions with and without the spin bit for specific network management functions. Specifically, (i) What's impossible or very difficult to do, from a network management perspective, of not having the spin bit? Note that I'm not asking for what is and is not measurable -- not everything measurable is useful. I'm specifically asking in terms of network management functions, in practice, as used by operators. Some of this has been addressed in the discussions/drafts I've seen, but I think it's most useful when framed in terms of network management functions. (ii) What are the alternatives for building the same functions without the spin bit? Let's consider for a moment that the spin bit isn't actually available in practice. What will operators do to continue managing their networks? This might be expensive, but that's precisely what I'm looking for -- the cost to operators of not having the spin bit. For instance, active probes are a fine way to measure network RTT within operator networks, and that is an alternative. There are surely others too. Their costs and limitations are important to know about in order to reason about their viability, so I'd like to see alternatives considered. I don't mean to start the discussion on this thread, but I'd like to urge those going off to do the writing to consider these questions. - jana On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) wrote: > Hi Brian, Stephen, Lars, Mark and all, > > one join, one suggestion, and one question below. > see [ACM] > > -----Original Message----- > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell > > (IETF) > > Sent: Wednesday, November 22, 2017 5:59 AM > > To: Eggert, Lars > > Cc: Mark Nottingham; QUIC WG; Stephen Farrell > > Subject: Re: Spin bit discussion - where we're at > > > > hi Lars, > > > > > On 22 Nov 2017, at 11:35, Eggert, Lars wrote: > > > > > > Hi, > > > > > > On 2017-11-22, at 11:01, Stephen Farrell > > wrote: > > >> What I thought was being requested and what I do think is reasonable > > >> is to document a privacy analysis for any quic protocol bits that are > > >> visible to the path. Whether or not some or all of that text ends up > > >> in some RFC is another day's work. > > > Lars wrote: > > > for the Spin Bit specifically, the intent was to permanently capture > > the analysis the DT has done, so that when others review the proposed > > Spin Bit specification, they can take that as a given and direct any > > further analysis to other aspects. It made sense to the chairs that that > > specific analysis should become part of the Spin Bit specification. I > > think we'd be open to a discussion on whether a broader document > > analyzing the QUIC wire image would be a better home for this. The main > > point is for the work that the DT has done to be documented. > > > Brian wrote: > > Okay. That's somewhat more reasonable than what I read the ask to be > > ("we're going to gate this on the people who care about this doing some > > non-trivial amount of work"). Those of us who volunteer (help, please, > > anyone? :) ) can certainly pull together what we have in a single I-D > > and ask the WG what more it thinks it needs. To me all this seems pretty > > clear, but I've been working on this topic for a while. > [ACM] > Having reached the end of the "Thanksgiving thread", > I'm scrolling back a few pages to join the task of > permanently capturing the work of the DT in an I-D (at least): > There should be lasting value in some of our findings > and IMO they are worthy of a persistent reference. > > > Lars wrote: > > > For proposals other than the Spin Bit (I think I have seen individual > > contributors at least mention "loss" and "congestion" bits, but without > > much detail), we wanted to clarify that we'd like to see an analysis and > > discussion of their privacy aspects to roughly the same degree as the DT > > has performed for the Spin Bit proposal. > > > [ACM] > I suggest that this might be a different I-D, at least to start. > Question: Is there a privacy analysis of present ECN available? > (a search yielded many results with Missing: privacy) > > regards, > Al > > --001a1140f596b8c0c5055ef18002 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In addition to how the spin bit can be designed and used, = I'd like those taking on this effort to consider this question: Whateve= r network management problem you're considering solving with a bit, wha= t does it take to solve this problem without the bit exposed? I'm askin= g you to consider "zero-bit" solutions, or at least for a cost/be= nefit analysis of developing solutions with and without the spin bit for sp= ecific network management functions. Specifically,

(i) W= hat's impossible or very difficult to do, from a network management per= spective, of not having the spin bit? Note that I'm not asking for what= is and is not measurable -- not everything measurable is useful. I'm s= pecifically asking in terms of network management functions, in practice, a= s used by operators. Some of this has been addressed in the discussions/dra= fts I've seen, but I think it's most useful when framed in terms of= network management functions.

(ii) What are the a= lternatives for building the same functions without the spin bit? Let's= consider for a moment that the spin bit isn't actually available in pr= actice. What will operators do to continue managing their networks? This mi= ght be expensive, but that's precisely what I'm looking for -- the = cost to operators of not having the spin bit. For instance, active probes a= re a fine way to measure network RTT within operator networks, and that is = an alternative. There are surely others too. Their costs and limitations ar= e important to know about in order to reason about their viability, so I= 9;d like to see alternatives considered.

I don'= ;t mean to start the discussion on this thread, but I'd like to urge th= ose going off to do the writing to consider these questions.

=
- jana


=
On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED= C (AL) <acmorton@att.com> wrote:
Hi Brian, Stephen, Lars, Mark and all,

one join, one suggestion, and one question below.
see [ACM]
> -----Original Message-----
> From: QUIC [mailto:quic-bounc= es@ietf.org] On Behalf Of Brian Trammell
> (IETF)
> Sent: Wednesday, November 22, 2017 5:59 AM
> To: Eggert, Lars
> Cc: Mark Nottingham; QUIC WG; Stephen Farrell
> Subject: Re: Spin bit discussion - where we're at
>
> hi Lars,
>
> > On 22 Nov 2017, at 11:35, Eggert, Lars <lars@netapp.com> wrote:
> >
> > Hi,
> >
> > On 2017-11-22, at 11:01, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> >> What I thought was being requested and what I do think is rea= sonable
> >> is to document a privacy analysis for any quic protocol bits = that are
> >> visible to the path. Whether or not some or all of that text = ends up
> >> in some RFC is another day's work.
> > Lars wrote:
> > for the Spin Bit specifically, the intent was to permanently capt= ure
> the analysis the DT has done, so that when others review the proposed<= br> > Spin Bit specification, they can take that as a given and direct any > further analysis to other aspects. It made sense to the chairs that th= at
> specific analysis should become part of the Spin Bit specification. I<= br> > think we'd be open to a discussion on whether a broader document > analyzing the QUIC wire image would be a better home for this. The mai= n
> point is for the work that the DT has done to be documented.

> Brian wrote:
> Okay. That's somewhat more reasonable than what I read the ask to = be
> ("we're going to gate this on the people who care about this = doing some
> non-trivial amount of work"). Those of us who volunteer (help, pl= ease,
> anyone? :) ) can certainly pull together what we have in a single I-D<= br> > and ask the WG what more it thinks it needs. To me all this seems pret= ty
> clear, but I've been working on this topic for a while.
[ACM]
Having reached the end of the "Thanksgiving thread",
I'm scrolling back a few pages to join the task of
permanently capturing the work of the DT in an I-D (at least):
There should be lasting value in some of our findings
and IMO they are worthy of a persistent reference.

> Lars wrote:
> > For proposals other than the Spin Bit (I think I have seen indivi= dual
> contributors at least mention "loss" and "congestion&qu= ot; bits, but without
> much detail), we wanted to clarify that we'd like to see an analys= is and
> discussion of their privacy aspects to roughly the same degree as the = DT
> has performed for the Spin Bit proposal.
>
[ACM]
I suggest that this might be a different I-D, at least to start.
Question: Is there a privacy analysis of present ECN available?
(a search yielded many results with Missing: privacy)

regards,
Al


--001a1140f596b8c0c5055ef18002-- From nobody Sun Nov 26 23:27: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 947551277BB for ; Sun, 26 Nov 2017 23:27:50 -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 1ZcOzGKHCwH0 for ; Sun, 26 Nov 2017 23:27:48 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id 3C14C1270A7 for ; Sun, 26 Nov 2017 23:27:48 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 0AAC6340E26; Mon, 27 Nov 2017 08:27:47 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.7665); Mon, 27 Nov 2017 08:27:44 +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, 27 Nov 2017 08:27:44 +0100 (CET) Received: from [122.29.177.43] (account ietf@trammell.ch HELO [192.168.11.19]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 37326367; Mon, 27 Nov 2017 08:27:43 +0100 From: "Brian Trammell (IETF)" Message-Id: <032229DF-0004-4A4C-BFF5-83B78A58D180@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_A61BAE7A-7D55-4A21-8BFE-F0AA13A669E8"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Spin bit discussion - where we're at Date: Mon, 27 Nov 2017 16:27:37 +0900 In-Reply-To: Cc: Al Morton , "Eggert, Lars" , Mark Nottingham , QUIC WG , Stephen Farrell To: Jana Iyengar References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:27:50 -0000 --Apple-Mail=_A61BAE7A-7D55-4A21-8BFE-F0AA13A669E8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Jana, Thanks for these questions. A couple of points inline. > On 27 Nov 2017, at 16:03, Jana Iyengar wrote: >=20 > In addition to how the spin bit can be designed and used, I'd like = those taking on this effort to consider this question: Whatever network = management problem you're considering solving with a bit, what does it = take to solve this problem without the bit exposed? I'm asking you to = consider "zero-bit" solutions, or at least for a cost/benefit analysis = of developing solutions with and without the spin bit for specific = network management functions. Specifically, > (i) What's impossible or very difficult to do, from a network = management perspective, of not having the spin bit? Note that I'm not = asking for what is and is not measurable -- not everything measurable is = useful. ...while I agree with you here, in principle, I'll point out that we're = not talking about some obscure metric you need two pages of latex = mathmode to describe... latency measurement is pretty basic stuff, from = which you can derive most everything else you need, which is why this is = the proposal we'd go with if we only had one bit... > I'm specifically asking in terms of network management functions, in = practice, as used by operators. Some of this has been addressed in the = discussions/drafts I've seen, but I think it's most useful when framed = in terms of network management functions. For the most part this is what you think it is: "detecting, localizing, = and troubleshooting latency issues". For access providers, specifically, = this is a matter of having an answer as to what the provider is doing = wrong and/or why it's not the provider's fault when customers call to = complain. > (ii) What are the alternatives for building the same functions without = the spin bit? Let's consider for a moment that the spin bit isn't = actually available in practice. What will operators do to continue = managing their networks? > This might be expensive, but that's precisely what I'm looking for -- = the cost to operators of not having the spin bit. For instance, active = probes are a fine way to measure network RTT within operator networks, = and that is an alternative. ...for some values of "fine", yes. > There are surely others too. Handshake RTT is the other one that'll almost certainly work, at the = cost of drastically reduced sample rate and bias toward differential = treatment of first packets / additional compute delay for crypto = bootstrapping on endpoints small enough that that matters. Next up is a two-stage approach that leverages peculiarities in = implementations / CC algorithms to classify senders in order to = probabilistically match packets to get component RTTs as with TCP. But = that is, as you say, kind of expensive. Third, if a provider needs passive RTT measurement at higher than = handshake RTT resolution, and QUIC won't expose it, TCP still will. So = one could always selectively/probabilistically block udp/443 to force = fallback and get enough samples. Since the TCP and QUIC stacks are (for = now) completely separate codepaths, there will be a bias on the endpoint = delay side. It's also kind of expensive. The latter two are speculative enough that I'd prefer to leave them out = of the draft, though. > Their costs and limitations are important to know about in order to = reason about their viability, so I'd like to see alternatives = considered. >=20 > I don't mean to start the discussion on this thread, but I'd like to = urge those going off to do the writing to consider these questions. Fortunately, I just wrote a first draft of that section :). Al signed up = to add some text to it shortly. Hope to get a complete draft out in the = next couple of weeks, travel and other deadlines permitting. Cheers, Brian > - jana >=20 >=20 > On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) = wrote: > Hi Brian, Stephen, Lars, Mark and all, >=20 > one join, one suggestion, and one question below. > see [ACM] > > -----Original Message----- > > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian = Trammell > > (IETF) > > Sent: Wednesday, November 22, 2017 5:59 AM > > To: Eggert, Lars > > Cc: Mark Nottingham; QUIC WG; Stephen Farrell > > Subject: Re: Spin bit discussion - where we're at > > > > hi Lars, > > > > > On 22 Nov 2017, at 11:35, Eggert, Lars wrote: > > > > > > Hi, > > > > > > On 2017-11-22, at 11:01, Stephen Farrell = > > wrote: > > >> What I thought was being requested and what I do think is = reasonable > > >> is to document a privacy analysis for any quic protocol bits that = are > > >> visible to the path. Whether or not some or all of that text ends = up > > >> in some RFC is another day's work. > > > Lars wrote: > > > for the Spin Bit specifically, the intent was to permanently = capture > > the analysis the DT has done, so that when others review the = proposed > > Spin Bit specification, they can take that as a given and direct any > > further analysis to other aspects. It made sense to the chairs that = that > > specific analysis should become part of the Spin Bit specification. = I > > think we'd be open to a discussion on whether a broader document > > analyzing the QUIC wire image would be a better home for this. The = main > > point is for the work that the DT has done to be documented. >=20 > > Brian wrote: > > Okay. That's somewhat more reasonable than what I read the ask to be > > ("we're going to gate this on the people who care about this doing = some > > non-trivial amount of work"). Those of us who volunteer (help, = please, > > anyone? :) ) can certainly pull together what we have in a single = I-D > > and ask the WG what more it thinks it needs. To me all this seems = pretty > > clear, but I've been working on this topic for a while. > [ACM] > Having reached the end of the "Thanksgiving thread", > I'm scrolling back a few pages to join the task of > permanently capturing the work of the DT in an I-D (at least): > There should be lasting value in some of our findings > and IMO they are worthy of a persistent reference. >=20 > > Lars wrote: > > > For proposals other than the Spin Bit (I think I have seen = individual > > contributors at least mention "loss" and "congestion" bits, but = without > > much detail), we wanted to clarify that we'd like to see an analysis = and > > discussion of their privacy aspects to roughly the same degree as = the DT > > has performed for the Spin Bit proposal. > > > [ACM] > I suggest that this might be a different I-D, at least to start. > Question: Is there a privacy analysis of present ECN available? > (a search yielded many results with Missing: privacy) >=20 > regards, > Al >=20 >=20 --Apple-Mail=_A61BAE7A-7D55-4A21-8BFE-F0AA13A669E8 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlobvmkACgkQihK3vwvq RqNfSxAAwr8u3UAOyRTSFKcxWEwiLbCRXPCWDjbcthjZYYTquimhRzg2ro4hq0Hx UvPItOeTKHV1symtXnvdgCNihpEHGrR4sQjmfApPfTXD76LrcF2/qYjK5XL8a1Iu g2kzXzPIu2/KyaX/Whe8aD2fPwpTOMyApOTBvVbj/2t1EayLu5jKzbwVwcEI9xff SXHgZx8j2gNN84nJdrVsLdEIMGYm49HFDbsWaxQ4JV37UZE6aRNOI8+Ck20asjCx g1XGjH1MZ4KZuuqQZwD5zClXkiPqAg0Wes7BRzWJwL2rux4i72xQZlsGMrq1GHJt PF6z6mjxBbMDaCBivaM+27DxYpt2F+G/oSffFAbZQmyQyuQ8Su7HgdSzKba+D0J4 pj/3pokDYyK/Ep5KejeOUB/MmXaDOgR63yFM4FQM1l8i7hCDtH0l4v6/ISRWLvaY fwstKcWtSbiGFoWQ+NtNCUHsIQR9BXej5eCFKm+o+FhvoiEZ4yMNSlQpcobyUmxM 12fR2Ad5wNWWrO3HWZDT88ClRn3wNUCOYslxDk9vvxdNLM+uSdoxOnXlz3Ue6ko8 qe884jfyzaIEQmy2FkKzdlP8+moTDb6jLpXbpeHyQcK0kY4H52yfo78pIkXtpvwH otaazafPWWrf8FAwpsUP77mV8tDAvRF7fUpiJjWQk8mvma1EwbY= =R8hJ -----END PGP SIGNATURE----- --Apple-Mail=_A61BAE7A-7D55-4A21-8BFE-F0AA13A669E8-- From nobody Sun Nov 26 23:37: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 1EAAA127B31 for ; Sun, 26 Nov 2017 23:37:28 -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=tessares-net.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sZLPtnU-NVl for ; Sun, 26 Nov 2017 23:37:26 -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 C2A2B127201 for ; Sun, 26 Nov 2017 23:37:25 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id b189so31983237wmd.0 for ; Sun, 26 Nov 2017 23:37:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=UPj/k8DmSiaJts7yoesxZL1gkKVvFCycThwrtBEvS0w=; b=W1HnaLNIWR9ztcMROCb8hPviLpfz70rzvb0NdsbH4Re0Oax++QCbDeROxQW3O/qsHk Pca3bsGD+gPNv/JDxlV2IoaOEyRTZLAHitwQi14VrEOn/E7NQeujdrG6WwJP3B9h3TTk aDZRip3Xi2ET4OnwScM+83VRv40RZ0yLvgALlz1xAI+ZqSBVQOaF8y6/iyXqYe44ZCsK vYKNXd2leqc1in2LydkJbhphLh8fNSwA7mNZLh+FnP53jblrSxh3NK4/Nnt/6mKQ/vHa N3NPwmDWR7BEUdKVGZoljPRxcGV88lbpwb4Z4cC60pVg0j/eyvQ0cW9anoOQGuYeDxbY 3p8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=UPj/k8DmSiaJts7yoesxZL1gkKVvFCycThwrtBEvS0w=; b=mTlVnOnHWs4GuMXdypgE3X72d8Ttg8VNeFDMvD0i/Yk0a6rlAxRg6Gyj2zmRnyTQUI 3XAGXslbMlDcdDlhT1QW4MidbgqQOgICPLS1MJNbFEEUU6nwq6qqMfjakfIIZVeYsfu7 rCrKpoijTAZLgVVv6AVbtB7dzUo8CFtZuQRLGpWJuDjX/RMq1CRCPpllfjjkEN1vRIBF +0lVMgf2r1bp55hdFBTAg59vZYH4K+DIp+Ry2nCKTTL2DpSrZumxg32DiN1WUEV0wdgd Fr3o/71J0prJjmKGp3WuKLunw9fatW3lh2MmOHZ6UpsjHmsCjrm3EG9o4ZEOKJFmBgD7 n9ww== X-Gm-Message-State: AJaThX4ILPq1WyqJ1GBlPtrnOD7qdRbXFIl79sVb3ZJqv1EeX8dX6/AH ckz1nsSB9+Rg2+NG2mVdQhhQacXI8HU1gtMObywVJSHlgourPnDTwRj6aerNmnmTvdykABHqYht Zrg== X-Google-Smtp-Source: AGs4zMZppyT3pFBl87apeaefZNdE/rFcAzPKKyy8cLHdpJ4usUPsvygAB4n57Kxz2LNKD2elK0myhw== X-Received: by 10.80.177.153 with SMTP id m25mr51957343edd.181.1511768243822; Sun, 26 Nov 2017 23:37:23 -0800 (PST) Received: from mbpobo.local ([2001:6a8:308f:2:e1c6:ea8a:fccf:8ab4]) by smtp.gmail.com with ESMTPSA id x7sm18536995edi.6.2017.11.26.23.37.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Nov 2017 23:37:23 -0800 (PST) Subject: Re: reserved bits for spin bit, etc. To: Martin Thomson Cc: Christian Huitema , "quic@ietf.org" References: <5108b3b9-d374-0709-3e6f-57c3192469b8@tessares.net> From: Olivier Bonaventure Message-ID: Date: Mon, 27 Nov 2017 08:37:23 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:37:28 -0000 Martin, >> >>> We cannot quite agree on the spin bit, let alone further management >>> bits. On the other hand, we see that there is clear interest from >>> something like that with at least part of the WG, we want to see some >>> experimentation, and we understand that the specification can proceed >>> independently from the base protocol development. Hence, I would like to >>> make a modest proposal. >>> >>> Can we mark one or possibly two bits as reserved in the first byte of >>> the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be >>> ignored when receiving, MAY be used for experiments between consenting >>> nodes? >> >> >> Having some spare bits in the base header will clearly be useful. In >> addition to the discussion on the spin bit, let me also point that a >> proposed design for multipath quic also uses one of the spare bits in the >> public header >> >> https://tools.ietf.org/html/draft-deconinck-multipath-quic-00 > > I don't think that this is a good design. I think that we definitely > need to discuss the separation of the packet number space when it > comes to multipath, using the connection ID is superior to adding > another byte to the header. For one, it's something we want to change > anyway. > The important point is to have different packet number spaces on the different paths. There are different ways to signal those number spaces. The draft proposes an explicit signal which is present in the publich header of each packet. One benefit of this approach is that a load-balancing router could use this information to forward the packets belonging to different paths of a single QUIC session over different paths. Using the connection id is a different way to distinguish different packet number spaces. In this case, there is no need for using space in the public header but we need to define QUIC frames to associate different connection ids to the same QUIC session. This seems possible as well, but in contrast with the above approach, a load-balancing router would not be able to easily load-balance the packets of a single QUIC session to different paths since there is no structure in the connection id. There are tradeoffs in any multipath design. I'd suggest that when the WG starts to work on multipath we look at detailed proposals. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Mon Nov 27 00:12: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 C3678126D85; Mon, 27 Nov 2017 00:12: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=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=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 NDQp_B8bgmgz; Mon, 27 Nov 2017 00:12:03 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AE921200F3; Mon, 27 Nov 2017 00:12:03 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,463,1505804400"; d="asc'?scan'208,217";a="224698798" Received: from hioexcmbx01-prd.hq.netapp.com ([10.122.105.34]) by mx142-out.netapp.com with ESMTP; 27 Nov 2017 00:12:02 -0800 Received: from VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) by hioexcmbx01-prd.hq.netapp.com (10.122.105.34) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 27 Nov 2017 00:12:02 -0800 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS08-PRD.hq.netapp.com (10.122.105.26) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Mon, 27 Nov 2017 00:12:02 -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=FCskL6NEOWTuAih90lUHjD0DyKPDTvfQKIeco/Z9Hgo=; b=UHeYXCy2n71ieJum/TCE9s3RBTN3Lm5HCWx/fXIJRmAcHmwOdMs2fx+6bZvfEvJhBNBxPP5rYJr0o1A0FfJ/BrmiXHFLLc1EXlleoVySkkvhszxWTmQAAFBLv0OiZKt6aVkpEVdEUJ/eHDdngjcYOVMtSURdowBbAHGqx92oy+U= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1761.namprd06.prod.outlook.com (10.162.224.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Mon, 27 Nov 2017 08:12:00 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.006; Mon, 27 Nov 2017 08:12:00 +0000 From: "Eggert, Lars" To: "MORTON, ALFRED C (AL)" CC: QUIC WG , "tsv-area@ietf.org" Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAANHICAAAmEgIAABm6AgAbXQwCAANXCAA== Date: Mon, 27 Nov 2017 08:11:59 +0000 Message-ID: <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [217.70.211.15] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1761; 6:dkAdqvG2ODZatG2XvDoxzysB494k2MZ7rpwMjf+AFP+5v2JUP3DVyQMHZTb1LmC+zieYwlHA2EI+JCtPDcq8JcdY0SuVxHx4+GoL0aFS9FQsAoeuX4+hGgSwPTXO1PDL8BEGfhgXfP3UHhzdKavxtFIfWbX7PyCdW+npbPBdaagaMuCoR/VNQuox1MT+1Tbt0Pv/qQJXnWIgqDhpATZM9IxaXCPo6QLUUkHcj2sFIAM0I9laS1dI5bSpwW7RbgmJgeBLey+BQQV8CxZO2CeBoJe/EkZSu8tgp4LDbxaVZiHko0qhZacxDttrnY1qxhMkD8jqEZejJiaQ0PyYX7vkkd//16+chCu8QgGl5xvF0tM=; 5:BCUoDNoZ6Kv/xdFKwj2jkAIROWauDEZKv7gPu0WVAO1sN0U7zt36Gr9iXzWhZLwHVWNNOaTi8PohIRFkq43RWSsFPHKdk9cRAvOFQ5ev2kKgYjvpGgvrP8wDx+QdDbi2W1JPNZNdYX0AgkNCuMO0EfQBi5POCvtKEOctQ5fcSvM=; 24:C9OhhOJOrlIhK/vcZWQqrY5Sj/CBH/vOmoqZ6V18Tgt6IsFUm635m1kU1zy4k8FYKs/nn51B6tuPFfMcJ9oh54y//3nwep2WMTl8YAJy784=; 7:Jp+s99vtzNNdcCMUO47KnVD/4/RCXJ1kFpOr5Hje+PT4rhE21t15vuk+0uXMMeMSJOfmmkkS5SzYJkKjPQyvlmYfyQ+3O2j4WHUIKMWxrD7dXzOrt69F3PiRjKb3VmkIdbEUOGERvv7y8NMNktMGxHuFwdjExA/lLLnx7ZUjwfKLlQN9oduq0bHAvuut3bgzSeSLEI0QzU8r6r+NbtyurSfQhEqHxiEQMbbaKPou8OLqvOTgtRN21dcMvhiwat7p x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 96165ea6-394d-4470-b27b-08d5356e88e2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1761; x-ms-traffictypediagnostic: BLUPR06MB1761: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(97927398514766); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(3231022)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123562025)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011); SRVR:BLUPR06MB1761; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1761; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(366004)(377424004)(199003)(189002)(24454002)(2900100001)(101416001)(66066001)(86362001)(53546010)(81156014)(81166006)(229853002)(82746002)(5660300001)(6486002)(77096006)(76176999)(105586002)(97736004)(68736007)(102836003)(6116002)(2950100002)(50986999)(99936001)(33656002)(189998001)(3846002)(25786009)(4001150100001)(478600001)(8936002)(3280700002)(2906002)(6916009)(6246003)(36756003)(54906003)(316002)(6512007)(99286004)(54896002)(236005)(93886005)(14454004)(53936002)(7736002)(8676002)(3660700001)(106356001)(50226002)(6506006)(4326008)(83716003)(6436002)(57306001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1761; H:BLUPR06MB1764.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=_A610358F-2280-402B-BF2A-FF6BCABA982E"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 96165ea6-394d-4470-b27b-08d5356e88e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2017 08:11:59.9213 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1761 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 08:12:05 -0000 --Apple-Mail=_A610358F-2280-402B-BF2A-FF6BCABA982E Content-Type: multipart/alternative; boundary="Apple-Mail=_96F5E68A-9231-4952-95C5-330A01141798" --Apple-Mail=_96F5E68A-9231-4952-95C5-330A01141798 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) wrote: > Question: Is there a privacy analysis of present ECN available? > (a search yielded many results with Missing: privacy) not that I'm aware of; CC'ing tsv-area@ for some broader input. (On first glance, the - user - privacy aspects here seem to be much more = contained, since ECN is mostly about the network exposing information to = the end systems, and not vice versa.) Lars --Apple-Mail=_96F5E68A-9231-4952-95C5-330A01141798 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On = 2017-11-26, at 20:26, MORTON, ALFRED C (AL) <acmorton@att.com> = wrote:
Question: Is there a = privacy analysis of present ECN available?
(a search yielded many results with Missing: = privacy)

not that I'm aware of; CC'ing tsv-area@ for = some broader input.

(On first glance, the - user - privacy aspects here seem to = be much more contained, since ECN is mostly about the network exposing = information to the end systems, and not vice versa.)

Lars
= --Apple-Mail=_96F5E68A-9231-4952-95C5-330A01141798-- --Apple-Mail=_A610358F-2280-402B-BF2A-FF6BCABA982E 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlobyM8ACgkQVLXDCb9w wVeQhw/9GlQlE/Rn1Gl9lg8IOCP11k/pjEW/0Q1KLL9ENfTgO409ejsssIOzNbsK X9G/ZPiTpPtTtiu/UrU7G+W1kLsbXf8wl6dae0897oOlMT5J/qhih7yLJeljXkdC kMNwb7srx1HW77AhPifA+QL/0WONOS3HeRGPOO/8eWzA9InkD86iM06fIeSVQsMe ylGPf6PNmJSgyA2jZCjsff0ReIHQsGfA4OnC5QkJsqCoAbaDISp39oiCbvw7uly5 bs1XvekCedGQxpHMboKBsftGQcQIHwZT1a2fM/zAInzxMENfxXuDiIqwcKKnOMnr oRyzEtZ8bdLfJ75Nd1IkHkZ3dYeH7fYD1T9MmgZnaSlZ9FVohJzwWuXtX3+weFQi hn3xec4fWcRQ/xkLXSNaL39Vaw2B4RJBImo+oxg2BPpzuL1q0oLRBjHRsIISlIWt sp/UJXO5ORGBzL9+C6B1fat1pCsfh046EO3GkRWWQ7z4he3+rJe2a/mLWSfY0Zf3 YCp2A82FiCZEexmv+sWJxysEm2P/+mwlnGGc/HoZAoGdnRkV/wE96FPRPpVKaPeJ zGJ5ovEIFpYC0XbJmgQZUpastuJgSegk3N3JmA/UYXC4r7Aa7QgNhJZiMJd0KOob Nl9JmOZpTQCmBsLO7E7lYASycssUrt/MfHuywbou287v9sKpy3E= =qseS -----END PGP SIGNATURE----- --Apple-Mail=_A610358F-2280-402B-BF2A-FF6BCABA982E-- From nobody Mon Nov 27 01:18: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 ABB301242F7 for ; Mon, 27 Nov 2017 01:18:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HMJrFEiGitV for ; Mon, 27 Nov 2017 01:18:47 -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 AE7031200F3 for ; Mon, 27 Nov 2017 01:18:46 -0800 (PST) Received: from [10.213.207.254] (unknown [85.255.233.33]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 939121B0111A; Mon, 27 Nov 2017 09:18:45 +0000 (GMT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Spin bit discussion - where we're at From: "Gorry (erg)" X-Mailer: iPhone Mail (15B202) In-Reply-To: <032229DF-0004-4A4C-BFF5-83B78A58D180@trammell.ch> Date: Mon, 27 Nov 2017 09:08:58 +0000 Cc: Jana Iyengar , Mark Nottingham , QUIC WG , "Eggert, Lars" , Al Morton , Stephen Farrell Content-Transfer-Encoding: quoted-printable Message-Id: <5B2A1A19-EFD2-443A-B822-88B45A4AEFD0@erg.abdn.ac.uk> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <032229DF-0004-4A4C-BFF5-83B78A58D180@trammell.ch> To: "Brian Trammell (IETF)" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 09:18:49 -0000 Hi Jana=20 So... +1 to Brian=E2=80=99s reply. We need to decide as a WG whether manageability is needed: Do we really need= more operations and measurement people to speak up?=20 =E2=80=9CHandshake RTT=E2=80=9D - turns out to be a rather poor tool in many= radio-based networks (eg mobile)... quite simply the need us to measure lat= ency (reordering,loss) as the session progresses ... I think this is already= clear.=20 Gorry=20 > On 27 Nov 2017, at 07:27, Brian Trammell (IETF) wrote: >=20 > hi Jana, >=20 > Thanks for these questions. A couple of points inline. >=20 >> On 27 Nov 2017, at 16:03, Jana Iyengar wrote: >>=20 >> In addition to how the spin bit can be designed and used, I'd like those t= aking on this effort to consider this question: Whatever network management p= roblem you're considering solving with a bit, what does it take to solve thi= s problem without the bit exposed? I'm asking you to consider "zero-bit" sol= utions, or at least for a cost/benefit analysis of developing solutions with= and without the spin bit for specific network management functions. Specifi= cally, >=20 >> (i) What's impossible or very difficult to do, from a network management p= erspective, of not having the spin bit? Note that I'm not asking for what is= and is not measurable -- not everything measurable is useful. >=20 > ...while I agree with you here, in principle, I'll point out that we're no= t talking about some obscure metric you need two pages of latex mathmode to d= escribe... latency measurement is pretty basic stuff, from which you can der= ive most everything else you need, which is why this is the proposal we'd go= with if we only had one bit... >=20 >> I'm specifically asking in terms of network management functions, in prac= tice, as used by operators. Some of this has been addressed in the discussio= ns/drafts I've seen, but I think it's most useful when framed in terms of ne= twork management functions. >=20 > For the most part this is what you think it is: "detecting, localizing, an= d troubleshooting latency issues". For access providers, specifically, this i= s a matter of having an answer as to what the provider is doing wrong and/or= why it's not the provider's fault when customers call to complain. >=20 >> (ii) What are the alternatives for building the same functions without th= e spin bit? Let's consider for a moment that the spin bit isn't actually ava= ilable in practice. What will operators do to continue managing their networ= ks? >> This might be expensive, but that's precisely what I'm looking for -- the= cost to operators of not having the spin bit. For instance, active probes a= re a fine way to measure network RTT within operator networks, and that is a= n alternative. >=20 > ...for some values of "fine", yes. >=20 >> There are surely others too. >=20 > Handshake RTT is the other one that'll almost certainly work, at the cost o= f drastically reduced sample rate and bias toward differential treatment of f= irst packets / additional compute delay for crypto bootstrapping on endpoint= s small enough that that matters. >=20 > Next up is a two-stage approach that leverages peculiarities in implementa= tions / CC algorithms to classify senders in order to probabilistically matc= h packets to get component RTTs as with TCP. But that is, as you say, kind o= f expensive. >=20 > Third, if a provider needs passive RTT measurement at higher than handshak= e RTT resolution, and QUIC won't expose it, TCP still will. So one could alw= ays selectively/probabilistically block udp/443 to force fallback and get en= ough samples. Since the TCP and QUIC stacks are (for now) completely separat= e codepaths, there will be a bias on the endpoint delay side. It's also kind= of expensive. >=20 > The latter two are speculative enough that I'd prefer to leave them out of= the draft, though. >=20 >> Their costs and limitations are important to know about in order to reaso= n about their viability, so I'd like to see alternatives considered. >>=20 >> I don't mean to start the discussion on this thread, but I'd like to urge= those going off to do the writing to consider these questions. >=20 > Fortunately, I just wrote a first draft of that section :). Al signed up t= o add some text to it shortly. Hope to get a complete draft out in the next c= ouple of weeks, travel and other deadlines permitting. >=20 > Cheers, >=20 > Brian >=20 >> - jana >>=20 >>=20 >> On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) wrote: >> Hi Brian, Stephen, Lars, Mark and all, >>=20 >> one join, one suggestion, and one question below. >> see [ACM] >>> -----Original Message----- >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell >>> (IETF) >>> Sent: Wednesday, November 22, 2017 5:59 AM >>> To: Eggert, Lars >>> Cc: Mark Nottingham; QUIC WG; Stephen Farrell >>> Subject: Re: Spin bit discussion - where we're at >>>=20 >>> hi Lars, >>>=20 >>>> On 22 Nov 2017, at 11:35, Eggert, Lars wrote: >>>>=20 >>>> Hi, >>>>=20 >>>> On 2017-11-22, at 11:01, Stephen Farrell >>> wrote: >>>>> What I thought was being requested and what I do think is reasonable >>>>> is to document a privacy analysis for any quic protocol bits that are >>>>> visible to the path. Whether or not some or all of that text ends up >>>>> in some RFC is another day's work. >>>> Lars wrote: >>>> for the Spin Bit specifically, the intent was to permanently capture >>> the analysis the DT has done, so that when others review the proposed >>> Spin Bit specification, they can take that as a given and direct any >>> further analysis to other aspects. It made sense to the chairs that that= >>> specific analysis should become part of the Spin Bit specification. I >>> think we'd be open to a discussion on whether a broader document >>> analyzing the QUIC wire image would be a better home for this. The main >>> point is for the work that the DT has done to be documented. >>=20 >>> Brian wrote: >>> Okay. That's somewhat more reasonable than what I read the ask to be >>> ("we're going to gate this on the people who care about this doing some >>> non-trivial amount of work"). Those of us who volunteer (help, please, >>> anyone? :) ) can certainly pull together what we have in a single I-D >>> and ask the WG what more it thinks it needs. To me all this seems pretty= >>> clear, but I've been working on this topic for a while. >> [ACM] >> Having reached the end of the "Thanksgiving thread", >> I'm scrolling back a few pages to join the task of >> permanently capturing the work of the DT in an I-D (at least): >> There should be lasting value in some of our findings >> and IMO they are worthy of a persistent reference. >>=20 >>> Lars wrote: >>>> For proposals other than the Spin Bit (I think I have seen individual >>> contributors at least mention "loss" and "congestion" bits, but without >>> much detail), we wanted to clarify that we'd like to see an analysis and= >>> discussion of their privacy aspects to roughly the same degree as the DT= >>> has performed for the Spin Bit proposal. >>>=20 >> [ACM] >> I suggest that this might be a different I-D, at least to start. >> Question: Is there a privacy analysis of present ECN available? >> (a search yielded many results with Missing: privacy) >>=20 >> regards, >> Al >>=20 >>=20 >=20 From nobody Mon Nov 27 03:32: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 377CF128959 for ; Mon, 27 Nov 2017 03:32:47 -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 WBBvpVEKBfzI for ; Mon, 27 Nov 2017 03:32:43 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (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 48F9012711E for ; Mon, 27 Nov 2017 03:32:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1511782361; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:To:Subject:X-RZG-CLASS-ID:X-RZG-AUTH:Accept-Language: Auto-Submitted:Cc:Date:From:Message-ID:References:Reply-To:Resent-Cc: Resent-Date:Resent-From:Resent-To:Sender:Subject:To: Content-Alternative:Content-Description:Content-Disposition: Content-Duration:Content-Features:Content-ID:Content-Language: Content-Location:Content-MD5:Content-Transfer-Encoding:Content-Type: MIME-Version; bh=X8hZgnxlpGZyY9q7UEXo83a+so3qkHOXrW4rzHjZDEA=; b=c75jLUpioj87mAdKDWQLLvLe4CJMOwjWrSgwi29YVarutAqli096CWNzSSE9mv5HlA yx63keT6P5SIPnOjrP2B0gkYTVJPaECalrk+kiX8+TTzHM+EDGAm1ZG/Ngd365fQMnGn l09QGh2HfzzaTqEtf/CSAOhol6ZzcIu300Dd0= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1oaZ1h8oElTTgmJ6Fg== X-RZG-CLASS-ID: mo00 Received: from [10.10.10.80] (p57B96C2D.dip0.t-ipconnect.de [87.185.108.45]) by smtp.strato.de (RZmta 42.10 DYNA|AUTH) with ESMTPSA id i09dc0tARBWf0Gw (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate) for ; Mon, 27 Nov 2017 12:32:41 +0100 (CET) Subject: Re: Spin bit discussion - where we're at To: quic@ietf.org References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> From: Roland Zink Message-ID: <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> Date: Mon, 27 Nov 2017 12:32:40 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------3B099DC9C7BAA5AF3AB32142" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 11:32:47 -0000 This is a multi-part message in MIME format. --------------3B099DC9C7BAA5AF3AB32142 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Am 27.11.2017 um 08:03 schrieb Jana Iyengar: > In addition to how the spin bit can be designed and used, I'd like > those taking on this effort to consider this question: Whatever > network management problem you're considering solving with a bit, what > does it take to solve this problem without the bit exposed? I'm asking > you to consider "zero-bit" solutions, or at least for a cost/benefit > analysis of developing solutions with and without the spin bit for > specific network management functions. Specifically, > > (i) What's impossible or very difficult to do, from a network > management perspective, of not having the spin bit? Note that I'm not > asking for what is and is not measurable -- not everything measurable > is useful. I'm specifically asking in terms of network management > functions, in practice, as used by operators. Some of this has been > addressed in the discussions/drafts I've seen, but I think it's most > useful when framed in terms of network management functions. I want to express the question about manageability from a different angle. QUIC moves the congestion control from being a common functionality in the kernel to application functionality. It also hides the protocol handling of congestion from the network. This gives incentives for application developers to change congestion control to give their application an advantage over others. No special rights are necessary. Now the question is does QUIC provide enough manageability to avoid an Internet (or some part of it) breakdown when it is misused? Can it be shown that this can't happen? > (ii) What are the alternatives for building the same functions without > the spin bit? Let's consider for a moment that the spin bit isn't > actually available in practice. What will operators do to continue > managing their networks? This might be expensive, but that's precisely > what I'm looking for -- the cost to operators of not having the spin > bit. For instance, active probes are a fine way to measure network RTT > within operator networks, and that is an alternative. There are surely > others too. Their costs and limitations are important to know about in > order to reason about their viability, so I'd like to see alternatives > considered. Solutions that only work within an operators network are not enough when more than one operator is involved. > > I don't mean to start the discussion on this thread, but I'd like to > urge those going off to do the writing to consider these questions. > > - jana > > > On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) > > wrote: > > Hi Brian, Stephen, Lars, Mark and all, > > one join, one suggestion, and one question below. > see [ACM] > > -----Original Message----- > > From: QUIC [mailto:quic-bounces@ietf.org > ] On Behalf Of Brian Trammell > > (IETF) > > Sent: Wednesday, November 22, 2017 5:59 AM > > To: Eggert, Lars > > Cc: Mark Nottingham; QUIC WG; Stephen Farrell > > Subject: Re: Spin bit discussion - where we're at > > > > hi Lars, > > > > > On 22 Nov 2017, at 11:35, Eggert, Lars > wrote: > > > > > > Hi, > > > > > > On 2017-11-22, at 11:01, Stephen Farrell > > > > wrote: > > >> What I thought was being requested and what I do think is > reasonable > > >> is to document a privacy analysis for any quic protocol bits > that are > > >> visible to the path. Whether or not some or all of that text > ends up > > >> in some RFC is another day's work. > > > Lars wrote: > > > for the Spin Bit specifically, the intent was to permanently > capture > > the analysis the DT has done, so that when others review the > proposed > > Spin Bit specification, they can take that as a given and direct any > > further analysis to other aspects. It made sense to the chairs > that that > > specific analysis should become part of the Spin Bit > specification. I > > think we'd be open to a discussion on whether a broader document > > analyzing the QUIC wire image would be a better home for this. > The main > > point is for the work that the DT has done to be documented. > > > Brian wrote: > > Okay. That's somewhat more reasonable than what I read the ask to be > > ("we're going to gate this on the people who care about this > doing some > > non-trivial amount of work"). Those of us who volunteer (help, > please, > > anyone? :) ) can certainly pull together what we have in a > single I-D > > and ask the WG what more it thinks it needs. To me all this > seems pretty > > clear, but I've been working on this topic for a while. > [ACM] > Having reached the end of the "Thanksgiving thread", > I'm scrolling back a few pages to join the task of > permanently capturing the work of the DT in an I-D (at least): > There should be lasting value in some of our findings > and IMO they are worthy of a persistent reference. > > > Lars wrote: > > > For proposals other than the Spin Bit (I think I have seen > individual > > contributors at least mention "loss" and "congestion" bits, but > without > > much detail), we wanted to clarify that we'd like to see an > analysis and > > discussion of their privacy aspects to roughly the same degree > as the DT > > has performed for the Spin Bit proposal. > > > [ACM] > I suggest that this might be a different I-D, at least to start. > Question: Is there a privacy analysis of present ECN available? > (a search yielded many results with Missing: privacy) > > regards, > Al > > --------------3B099DC9C7BAA5AF3AB32142 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
Am 27.11.2017 um 08:03 schrieb Jana Iyengar:
In addition to how the spin bit can be designed and used, I'd like those taking on this effort to consider this question: Whatever network management problem you're considering solving with a bit, what does it take to solve this problem without the bit exposed? I'm asking you to consider "zero-bit" solutions, or at least for a cost/benefit analysis of developing solutions with and without the spin bit for specific network management functions. Specifically,

(i) What's impossible or very difficult to do, from a network management perspective, of not having the spin bit? Note that I'm not asking for what is and is not measurable -- not everything measurable is useful. I'm specifically asking in terms of network management functions, in practice, as used by operators. Some of this has been addressed in the discussions/drafts I've seen, but I think it's most useful when framed in terms of network management functions.
I want to express the question about manageability from a different angle. QUIC moves the congestion control from being a common functionality in the kernel to application functionality. It also hides the protocol handling of congestion from the network. This gives incentives for application developers to change congestion control to give their application an advantage over others. No special rights are necessary. Now the question is does QUIC provide enough manageability to avoid an Internet (or some part of it) breakdown when it is misused? Can it be shown that this can't happen?

(ii) What are the alternatives for building the same functions without the spin bit? Let's consider for a moment that the spin bit isn't actually available in practice. What will operators do to continue managing their networks? This might be expensive, but that's precisely what I'm looking for -- the cost to operators of not having the spin bit. For instance, active probes are a fine way to measure network RTT within operator networks, and that is an alternative. There are surely others too. Their costs and limitations are important to know about in order to reason about their viability, so I'd like to see alternatives considered.
Solutions that only work within an operators network are not enough when more than one operator is involved.


I don't mean to start the discussion on this thread, but I'd like to urge those going off to do the writing to consider these questions.

- jana


On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:
Hi Brian, Stephen, Lars, Mark and all,

one join, one suggestion, and one question below.
see [ACM]
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell
> (IETF)
> Sent: Wednesday, November 22, 2017 5:59 AM
> To: Eggert, Lars
> Cc: Mark Nottingham; QUIC WG; Stephen Farrell
> Subject: Re: Spin bit discussion - where we're at
>
> hi Lars,
>
> > On 22 Nov 2017, at 11:35, Eggert, Lars <lars@netapp.com> wrote:
> >
> > Hi,
> >
> > On 2017-11-22, at 11:01, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> >> What I thought was being requested and what I do think is reasonable
> >> is to document a privacy analysis for any quic protocol bits that are
> >> visible to the path. Whether or not some or all of that text ends up
> >> in some RFC is another day's work.
> > Lars wrote:
> > for the Spin Bit specifically, the intent was to permanently capture
> the analysis the DT has done, so that when others review the proposed
> Spin Bit specification, they can take that as a given and direct any
> further analysis to other aspects. It made sense to the chairs that that
> specific analysis should become part of the Spin Bit specification. I
> think we'd be open to a discussion on whether a broader document
> analyzing the QUIC wire image would be a better home for this. The main
> point is for the work that the DT has done to be documented.

> Brian wrote:
> Okay. That's somewhat more reasonable than what I read the ask to be
> ("we're going to gate this on the people who care about this doing some
> non-trivial amount of work"). Those of us who volunteer (help, please,
> anyone? :) ) can certainly pull together what we have in a single I-D
> and ask the WG what more it thinks it needs. To me all this seems pretty
> clear, but I've been working on this topic for a while.
[ACM]
Having reached the end of the "Thanksgiving thread",
I'm scrolling back a few pages to join the task of
permanently capturing the work of the DT in an I-D (at least):
There should be lasting value in some of our findings
and IMO they are worthy of a persistent reference.

> Lars wrote:
> > For proposals other than the Spin Bit (I think I have seen individual
> contributors at least mention "loss" and "congestion" bits, but without
> much detail), we wanted to clarify that we'd like to see an analysis and
> discussion of their privacy aspects to roughly the same degree as the DT
> has performed for the Spin Bit proposal.
>
[ACM]
I suggest that this might be a different I-D, at least to start.
Question: Is there a privacy analysis of present ECN available?
(a search yielded many results with Missing: privacy)

regards,
Al



--------------3B099DC9C7BAA5AF3AB32142-- From nobody Mon Nov 27 05: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 82E73127A90 for ; Mon, 27 Nov 2017 05:14:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8AMFvnfDTOkY for ; Mon, 27 Nov 2017 05:14:37 -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 74527126C25 for ; Mon, 27 Nov 2017 05:14:37 -0800 (PST) Received: from [10.5.249.159] (unknown [185.69.144.98]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 1A10E1B002D8; Mon, 27 Nov 2017 13:14:36 +0000 (GMT) Content-Type: multipart/alternative; boundary=Apple-Mail-A9DFFFAC-8C76-4DF1-AC0D-D01FD9D66EC4 Mime-Version: 1.0 (1.0) Subject: Re: Spin bit discussion - where we're at From: "Gorry (erg)" X-Mailer: iPhone Mail (15B202) In-Reply-To: <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> Date: Mon, 27 Nov 2017 14:14:33 +0100 Cc: quic@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@erg.abdn.ac.uk> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> To: Roland Zink Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 13:14:40 -0000 --Apple-Mail-A9DFFFAC-8C76-4DF1-AC0D-D01FD9D66EC4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable See below: > On 27 Nov 2017, at 12:32, Roland Zink wrote: >=20 >> Am 27.11.2017 um 08:03 schrieb Jana Iyengar: >> In addition to how the spin bit can be designed and used, I'd like those t= aking on this effort to consider this question: Whatever network management p= roblem you're considering solving with a bit, what does it take to solve thi= s problem without the bit exposed? I'm asking you to consider "zero-bit" sol= utions, or at least for a cost/benefit analysis of developing solutions with= and without the spin bit for specific network management functions. Specifi= cally, >>=20 >> (i) What's impossible or very difficult to do, from a network management p= erspective, of not having the spin bit? Note that I'm not asking for what is= and is not measurable -- not everything measurable is useful. I'm specifica= lly asking in terms of network management functions, in practice, as used by= operators. Some of this has been addressed in the discussions/drafts I've s= een, but I think it's most useful when framed in terms of network management= functions. > I want to express the question about manageability from a different angle.= QUIC moves the congestion control from being a common functionality in the k= ernel to application functionality. It also hides the protocol handling of c= ongestion from the network. This gives incentives for application developers= to change congestion control to give their application an advantage over ot= hers. No special rights are necessary. Now the question is does QUIC provide= enough manageability to avoid an Internet (or some part of it) breakdown wh= en it is misused? Can it be shown that this can't happen? >=20 I think this may touch on some of the topics in: https://tools.ietf.org/html/draft-fairhurst-tsvwg-transport-encrypt-04 Although this is focussed on issues wider than Quic, I think the points you r= aise are relevant. This was presented last IETF-100 in TSVWG and INTAREA. We= would appreciate insight, and comments on this. (I am just about to push n= ew version to correct typos!) >> (ii) What are the alternatives for building the same functions without th= e spin bit? Let's consider for a moment that the spin bit isn't actually ava= ilable in practice. What will operators do to continue managing their networ= ks? This might be expensive, but that's precisely what I'm looking for -- th= e cost to operators of not having the spin bit. For instance, active probes a= re a fine way to measure network RTT within operator networks, and that is a= n alternative. There are surely others too. Their costs and limitations are i= mportant to know about in order to reason about their viability, so I'd like= to see alternatives considered. > Solutions that only work within an operators network are not enough when m= ore than one operator is involved. >=20 Yes, also true. Gorry >>=20 >> I don't mean to start the discussion on this thread, but I'd like to urge= those going off to do the writing to consider these questions. >>=20 >> - jana >>=20 >>=20 >> On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) wrote: >>> Hi Brian, Stephen, Lars, Mark and all, >>>=20 >>> one join, one suggestion, and one question below. >>> see [ACM] >>> > -----Original Message----- >>> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell >>> > (IETF) >>> > Sent: Wednesday, November 22, 2017 5:59 AM >>> > To: Eggert, Lars >>> > Cc: Mark Nottingham; QUIC WG; Stephen Farrell >>> > Subject: Re: Spin bit discussion - where we're at >>> > >>> > hi Lars, >>> > >>> > > On 22 Nov 2017, at 11:35, Eggert, Lars wrote: >>> > > >>> > > Hi, >>> > > >>> > > On 2017-11-22, at 11:01, Stephen Farrell = >>> > wrote: >>> > >> What I thought was being requested and what I do think is reasonabl= e >>> > >> is to document a privacy analysis for any quic protocol bits that a= re >>> > >> visible to the path. Whether or not some or all of that text ends u= p >>> > >> in some RFC is another day's work. >>> > > Lars wrote: >>> > > for the Spin Bit specifically, the intent was to permanently capture= >>> > the analysis the DT has done, so that when others review the proposed >>> > Spin Bit specification, they can take that as a given and direct any >>> > further analysis to other aspects. It made sense to the chairs that th= at >>> > specific analysis should become part of the Spin Bit spe= cification. I >>> > think we'd be open to a discussion on whether a broader document >>> > analyzing the QUIC wire image would be a better home for this. The mai= n >>> > point is for the work that the DT has done to be documented. >>>=20 >>> > Brian wrote: >>> > Okay. That's somewhat more reasonable than what I read the ask to be >>> > ("we're going to gate this on the people who care about this doing som= e >>> > non-trivial amount of work"). Those of us who volunteer (help, please,= >>> > anyone? :) ) can certainly pull together what we have in= a single I-D >>> > and ask the WG what more it thinks it needs. To me all this seems pret= ty >>> > clear, but I've been working on this topic for a while. >>> [ACM] >>> Having reached the end of the "Thanksgiving thread", >>> I'm scrolling back a few pages to join the task of >>> permanently capturing the work of the DT in an I-D (at least): >>> There should be lasting value in some of our findings >>> and IMO they are worthy of a persistent reference. >>>=20 >>> > Lars wrote: >>> > > For proposals other than the Spin Bit (I think I have seen individua= l >>> > contributors at least mention "loss" and "congestion" bits, but withou= t >>> > much detail), we wanted to clarify that we'd like to see an analysis a= nd >>> > discussion of their privacy aspects to roughly the same degree as the D= T >>> > has performed for the Spin Bit proposal. >>> > >>> [ACM] >>> I suggest that this might be a different I-D, at least to start. >>> Question: Is there a privacy analysis of present ECN available? >>> (a search yielded many results with Missing: privacy) >>>=20 >>> regards, >>> Al >>>=20 >>=20 >=20 --Apple-Mail-A9DFFFAC-8C76-4DF1-AC0D-D01FD9D66EC4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
See below:

On 27 Nov 2017, at 12:32, Roland Zink <roland@zinks.de> wrote:

Am 27.11.2017 um 08:03 schrieb Jana Iyengar:
In addition to how the spin bit can be designed and used, I'd like those taking on this effort to consider this question: Whatever network management problem you're considering solving with a bit, what does it take to solve this problem without the bit exposed? I'm asking you to consider "zero-bit" solutions, or at least for a cost/benefit analysis of developing solutions with and without the spin bit for specific network management functions. Specifically,

(i) What's impossible or very difficult to do, from a network management perspective, of not having the spin bit? Note that I'm not asking for what is and is not measurable -- not everything measurable is useful. I'm specifically asking in terms of network management functions, in practice, as used by operators. Some of this has been addressed in the discussions/drafts I've seen, but I think it's most useful when framed in terms of network management functions.
I want to express the question about manageability from a different angle. QUIC moves the congestion control from being a common functionality in the kernel to application functionality. It also hides the protocol handling of congestion from the network. This gives incentives for application developers to change congestion control to give their application an advantage over others. No special rights are necessary. Now the question is does QUIC provide enough manageability to avoid an Internet (or some part of it) breakdown when it is misused? Can it be shown that this can't happen?

I think this may touch on some of the topics in:

Although this is focussed on issues wider than Quic, I think the points you raise are relevant. This was presented last IETF-100 in TSVWG and INTAREA. We would appreciate insight, and comments on this.  (I am just about to push new version to correct typos!)

(ii) What are the alternatives for building the same functions without the spin bit? Let's consider for a moment that the spin bit isn't actually available in practice. What will operators do to continue managing their networks? This might be expensive, but that's precisely what I'm looking for -- the cost to operators of not having the spin bit. For instance, active probes are a fine way to measure network RTT within operator networks, and that is an alternative. There are surely others too. Their costs and limitations are important to know about in order to reason about their viability, so I'd like to see alternatives considered.
Solutions that only work within an operators network are not enough when more than one operator is involved.

Yes, also true.

Gorry

I don't mean to start the discussion on this thread, but I'd like to urge those going off to do the writing to consider these questions.

- jana


On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:
Hi Brian, Stephen, Lars, Mark and all,

one join, one suggestion, and one question below.
see [ACM]
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell
> (IETF)
> Sent: Wednesday, November 22, 2017 5:59 AM
> To: Eggert, Lars
> Cc: Mark Nottingham; QUIC WG; Stephen Farrell
> Subject: Re: Spin bit discussion - where we're at
>
> hi Lars,
>
> > On 22 Nov 2017, at 11:35, Eggert, Lars <lars@netapp.com> wrote:
> >
> > Hi,
> >
> > On 2017-11-22, at 11:01, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> >> What I thought was being requested and what I do think is reasonable
> >> is to document a privacy analysis for any quic protocol bits that are
> >> visible to the path. Whether or not some or all of that text ends up
> >> in some RFC is another day's work.
> > Lars wrote:
> > for the Spin Bit specifically, the intent was to permanently capture
> the analysis the DT has done, so that when others review the proposed
> Spin Bit specification, they can take that as a given and direct any
> further analysis to other aspects. It made sense to the chairs that that
> specific analysis should become part of the Spin Bit specification. I
> think we'd be open to a discussion on whether a broader document
> analyzing the QUIC wire image would be a better home for this. The main
> point is for the work that the DT has done to be documented.

> Brian wrote:
> Okay. That's somewhat more reasonable than what I read the ask to be
> ("we're going to gate this on the people who care about this doing some
> non-trivial amount of work"). Those of us who volunteer (help, please,
> anyone? :) ) can certainly pull together what we have in a single I-D
> and ask the WG what more it thinks it needs. To me all this seems pretty
> clear, but I've been working on this topic for a while.
[ACM]
Having reached the end of the "Thanksgiving thread",
I'm scrolling back a few pages to join the task of
permanently capturing the work of the DT in an I-D (at least):
There should be lasting value in some of our findings
and IMO they are worthy of a persistent reference.

> Lars wrote:
> > For proposals other than the Spin Bit (I think I have seen individual
> contributors at least mention "loss" and "congestion" bits, but without
> much detail), we wanted to clarify that we'd like to see an analysis and
> discussion of their privacy aspects to roughly the same degree as the DT
> has performed for the Spin Bit proposal.
>
[ACM]
I suggest that this might be a different I-D, at least to start.
Question: Is there a privacy analysis of present ECN available?
(a search yielded many results with Missing: privacy)

regards,
Al



--Apple-Mail-A9DFFFAC-8C76-4DF1-AC0D-D01FD9D66EC4-- From nobody Mon Nov 27 06: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 79E1F120727 for ; Mon, 27 Nov 2017 06:15:11 -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 c9odGt_6TyuH for ; Mon, 27 Nov 2017 06:15:05 -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 4FE551200B9 for ; Mon, 27 Nov 2017 06:15:04 -0800 (PST) X-AuditID: c1b4fb2d-139999c0000036aa-e8-5a1c1de60167 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0D.2B.13994.6ED1C1A5; Mon, 27 Nov 2017 15:15:02 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.42) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 27 Nov 2017 15:14:56 +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=M2b4+WBfCSXv7FHFQnDalxJhPEuz3tW33C+Yr9yjbjs=; b=WnvS0mz+4K7++yAjGv9Gi4cRMPOLFkreO//S5eeyccf73/2luqqILqbCIxaaUNcn1MO0cIPHz/CU8LPqoI5/pPrfKPXcwpfUY5QmD5HQHR44p1agPXPBnVUuo/Oip1ZOBfQUF0IvVWkoiIjkoUyEuMyEuJDFgPIyMZSCQYZXbkk= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB347.eurprd07.prod.outlook.com (10.141.234.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.282.3; Mon, 27 Nov 2017 14:14:54 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::e0fd:9f9f:e232:b301]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::e0fd:9f9f:e232:b301%16]) with mapi id 15.20.0282.002; Mon, 27 Nov 2017 14:14:54 +0000 From: Ingemar Johansson S To: "Gorry (erg)" , Roland Zink CC: "quic@ietf.org" Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTZ4HIwy7AvHmC906Tq5O1smuWkqMoQU8w Date: Mon, 27 Nov 2017 14:14:53 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@erg.abdn.ac.uk> In-Reply-To: <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@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.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB347; 6:s23euOqfMsgrSPnR35XgmDjW84+ULu2l7R6Dwt5GMCW85973d0lIE/GldSlazyeQy2P5KZaLrc5eujbqsr61Q3RnbZqdA6Od+T12FH5Gowk1PMGay9iLGNzkY8wAcK3rSatsa0Y6xNdb9ELv1B/UkIq+wv1+17xHDFSwl5bE3I/YgOQ4SXA+sHPyJ8KC55vkMnAAusrCldOxg2ay517D4QSwxGEDIDTujt4HRBgezF22ARgUo9Lv/aBWKreTfYnUkQKFsniROXZ+neDcxrKydc8spa230YQ+84HYUU0OriVzMBO+F9XPLJ0/07cFNLjx6nzeEP0zVv+5aNjDbwmd34guW2Ggm0G4D+kjQNIcCxU=; 5:1f3GwXvFXqLqnzksofEs356QAbXypS0zUeAc8aXoCpwNmkobTMqDG/XXiQ+SEvE03BqSayspgffUSufKznAu63Qa6hnQSTWX2XpT3br0L36kVePl/dizUD/yrLgEBaXmjuM+dAMqirar7+ego8aLsHEl6N6UKxaaYh6bd6aXrdg=; 24:ZtCR6/axCRK32OaSY+NuggNvW9bujCDVofGooeQIH8gpwRTWGJNI+OXRxwZoC44qlZuzUG5vQodzhoeplbCoN66bqw9x63T9quZ2ICIUbvk=; 7:FzmAVRVa63Eg3JFrPsB+RfE9vnwRSnvnOgfZFhJAHLMYsSpdNcDlzADnrAIL0cI6sXfPpQJGL6vCB1mo5i9qAqwa5DxMurFkj3SMkCNr2HWYJwvSdDqjCHSPWjc6zDx1ucjBu6gVgYuJdhvCAdBSU/xCmEzM2WHJsp3YkMuBTmfkvMDCAmpvcFSswyvBfMIHQ98E/aQYizsT9WVMhKmfGxRfKqcx1p6P+tV6BHyfm5bQsQ8OOLXlhRvaznbjuqxf x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4953896b-2f64-4967-a323-08d535a13b35 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:DB4PR07MB347; x-ms-traffictypediagnostic: DB4PR07MB347: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(97927398514766)(58145275503218)(227612066756510)(155532106045638)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231022)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(6072148)(201708071742011); SRVR:DB4PR07MB347; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB4PR07MB347; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39860400002)(376002)(346002)(199003)(13464003)(189002)(377424004)(24454002)(81166006)(81156014)(50986999)(54356999)(76176999)(478600001)(53546010)(606006)(4326008)(9326002)(8936002)(14454004)(101416001)(68736007)(966005)(66066001)(93886005)(74316002)(316002)(25786009)(86362001)(3660700001)(3280700002)(33656002)(2906002)(105586002)(110136005)(106356001)(7736002)(8676002)(19609705001)(561944003)(6436002)(2900100001)(4001150100001)(6246003)(2950100002)(6506006)(3846002)(5250100002)(229853002)(5660300001)(53936002)(236005)(7696005)(55016002)(189998001)(99286004)(97736004)(6116002)(54896002)(9686003)(6306002)(790700001)(102836003); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB347; 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: multipart/alternative; boundary="_000_DB4PR07MB348CAF067401CD277485464C2250DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4953896b-2f64-4967-a323-08d535a13b35 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2017 14:14:54.0295 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB347 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGKsWRmVeSWpSXmKPExsUyM2K7lu4zWZkog4sbxSxet81mtOhZwG2x 7O4FFgdmj57PL5g8liz5yeTxd/EH9gDmKC6blNSczLLUIn27BK6Me8c72QoOrWCqODbtD2MD 44MFTF2MnBwSAiYSr789ZOti5OIQEjjMKLG7uY0RwjnBKDF18j5WEIdFoJdZYsLh/UwQmWlM ElcnrGOHcB4yShw++pMZZBibgI3EykPfGUFsEQF3iT83V7CD2MwCyhJTTjewgtjCAoYSTQ9e s0DUGEm0vetgg7FPnW8CquEAWqcqceZmMEiYVyBK4tQBkHKQXS0sEisnPQWbzyngJLF7yU2w mYwCshL3v99jgdglLnHryXyo5wQkluw5zwxhi0q8fPwPqj5Z4tPNXlaIuILEn0uP2CBsWYlL 87vB/pcQOMgucej9SkaIhJ7E1olvoWxfid//jkEVLWaU6F/5CqpbU6L73g4WCDtTYt+v36wQ RT2MEpt3/WKGcOYxSzz99xCqSkbieOdllgmMurOQnA5h50s8vb2KZRY4DAQlTs58AmRzAMU1 Jdbv0ocoUZSY0v2QHcLWkGidM5cdWXwBI/sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMDU dHDLb90djKtfOx5iFOBgVOLhXcglEyXEmlhWXJl7iFGCg1lJhFf2oXSUEG9KYmVValF+fFFp TmrxIUZpDhYlcd6TnrxRQgLpiSWp2ampBalFMFkmDk6pBkamadezLl3U1/Npl1ww4YdbzzvT /89SIxnX3hP4fcTH+bBK2DUO8xRpxYV3TWPdxDo2Rq1pXXLlbFqe3OEXXmdv9UfM75gs3mgi fPzir8cPP6Q29CxR1v/3cn5VYp7AcecTMVwdt6fInoy6ad33tfuu03qx1QwPbi+zvL7eo6Zr yUr5wuk1TFVKLMUZiYZazEXFiQAwEwOaSQMAAA== Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:15:11 -0000 --_000_DB4PR07MB348CAF067401CD277485464C2250DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KSSB3b3VsZCBzYXkgdGhhdCBpdCBpcyBwZXJmZWN0bHkgcG9zc2libGUgdG8gdHJpY2sg ZS5nLiB0aGUgTGludXggVENQIHN0YWNrIHRvIHNvbWV0aGluZyBsaWtlIHdoYXQgaXMgZGVzY3Jp YmVkIGJlbG93LiBKdXN0IGNsb25lIHRjcF9jb25nLmMgLA0KQ2hhbmdlIHRoZSBmb2xsb3dpbmcg bGluZXMNCnUzMiB0Y3BfcmVub19zc3RocmVzaDxodHRwczovL2VsaXhpci5mcmVlLWVsZWN0cm9u cy5jb20vbGludXgvdjMuMTIvaWRlbnQvdGNwX3Jlbm9fc3N0aHJlc2g+KHN0cnVjdCBzb2NrPGh0 dHBzOi8vZWxpeGlyLmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4xMi9pZGVudC9zb2NrPiAq c2spDQp7DQogICAgICAgIGNvbnN0IHN0cnVjdCB0Y3Bfc29jazxodHRwczovL2VsaXhpci5mcmVl LWVsZWN0cm9ucy5jb20vbGludXgvdjMuMTIvaWRlbnQvdGNwX3NvY2s+ICp0cCA9IHRjcF9zazxo dHRwczovL2VsaXhpci5mcmVlLWVsZWN0cm9ucy5jb20vbGludXgvdjMuMTIvaWRlbnQvdGNwX3Nr Pihzayk7DQogICAgICAgIHJldHVybiBtYXg8aHR0cHM6Ly9lbGl4aXIuZnJlZS1lbGVjdHJvbnMu Y29tL2xpbnV4L3YzLjEyL2lkZW50L21heD4odHAtPnNuZF9jd25kID4+IDFVLCAyVSk7DQp9DQpU byBzb21ldGhpbmcgbGlrZQ0KDQp1MzIgdGNwX2Jsb2F0X3NzdGhyZXNoPGh0dHBzOi8vZWxpeGly LmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4xMi9pZGVudC90Y3BfcmVub19zc3RocmVzaD4o c3RydWN0IHNvY2s8aHR0cHM6Ly9lbGl4aXIuZnJlZS1lbGVjdHJvbnMuY29tL2xpbnV4L3YzLjEy L2lkZW50L3NvY2s+ICpzaykNCg0Kew0KDQogICAgICAgIGNvbnN0IHN0cnVjdCB0Y3Bfc29jazxo dHRwczovL2VsaXhpci5mcmVlLWVsZWN0cm9ucy5jb20vbGludXgvdjMuMTIvaWRlbnQvdGNwX3Nv Y2s+ICp0cCA9IHRjcF9zazxodHRwczovL2VsaXhpci5mcmVlLWVsZWN0cm9ucy5jb20vbGludXgv djMuMTIvaWRlbnQvdGNwX3NrPihzayk7DQoNCiAgICAgICAgcmV0dXJuIHRwLT5zbmRfY3duZDsN Cg0KfQ0KQnVpbGQgaXQgYW5kIG1ha2UgaXQgYSBsb2FkYWJsZSBrZXJuZWwgbW9kdWxlLCB5b3Ug bmVlZCB0byByZW5hbWUgYSBmZXcgb3RoZXIgZnVuY3Rpb25zIGFzIHdlbGwsIGFuZCB5b3UgY2Fu IGNhbGwgaXQgdGNwX2Jsb2F0LmMg8J+Yig0KDQpTby4uIG15IG9waW5pb24gaXMgdGhhdCB5b3Ug Y2FuIHBlcmZlY3RseSB3ZWxsIGNvbGxhcHNlIHRoZSBpbnRlcm5ldCBhbHNvIHdpdGggVENQLiBD b25FeCB3YXMgaW50cm9kdWNlZCBhcyBhIG1lZGljaW5lIGZvciB0aGlzIGJ1dCBpdCBuZXZlciBn YWluZWQgdHJhY3Rpb24uDQoNCi9JbmdlbWFyDQoNCg0KDQoNCkZyb206IEdvcnJ5IChlcmcpIFtt YWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWtdDQpTZW50OiBkZW4gMjcgbm92ZW1iZXIgMjAxNyAx NDoxNQ0KVG86IFJvbGFuZCBaaW5rIDxyb2xhbmRAemlua3MuZGU+DQpDYzogcXVpY0BpZXRmLm9y Zw0KU3ViamVjdDogUmU6IFNwaW4gYml0IGRpc2N1c3Npb24gLSB3aGVyZSB3ZSdyZSBhdA0KDQpT ZWUgYmVsb3c6DQoNCk9uIDI3IE5vdiAyMDE3LCBhdCAxMjozMiwgUm9sYW5kIFppbmsgPHJvbGFu ZEB6aW5rcy5kZTxtYWlsdG86cm9sYW5kQHppbmtzLmRlPj4gd3JvdGU6DQpBbSAyNy4xMS4yMDE3 IHVtIDA4OjAzIHNjaHJpZWIgSmFuYSBJeWVuZ2FyOg0KSW4gYWRkaXRpb24gdG8gaG93IHRoZSBz cGluIGJpdCBjYW4gYmUgZGVzaWduZWQgYW5kIHVzZWQsIEknZCBsaWtlIHRob3NlIHRha2luZyBv biB0aGlzIGVmZm9ydCB0byBjb25zaWRlciB0aGlzIHF1ZXN0aW9uOiBXaGF0ZXZlciBuZXR3b3Jr IG1hbmFnZW1lbnQgcHJvYmxlbSB5b3UncmUgY29uc2lkZXJpbmcgc29sdmluZyB3aXRoIGEgYml0 LCB3aGF0IGRvZXMgaXQgdGFrZSB0byBzb2x2ZSB0aGlzIHByb2JsZW0gd2l0aG91dCB0aGUgYml0 IGV4cG9zZWQ/IEknbSBhc2tpbmcgeW91IHRvIGNvbnNpZGVyICJ6ZXJvLWJpdCIgc29sdXRpb25z LCBvciBhdCBsZWFzdCBmb3IgYSBjb3N0L2JlbmVmaXQgYW5hbHlzaXMgb2YgZGV2ZWxvcGluZyBz b2x1dGlvbnMgd2l0aCBhbmQgd2l0aG91dCB0aGUgc3BpbiBiaXQgZm9yIHNwZWNpZmljIG5ldHdv cmsgbWFuYWdlbWVudCBmdW5jdGlvbnMuIFNwZWNpZmljYWxseSwNCg0KKGkpIFdoYXQncyBpbXBv c3NpYmxlIG9yIHZlcnkgZGlmZmljdWx0IHRvIGRvLCBmcm9tIGEgbmV0d29yayBtYW5hZ2VtZW50 IHBlcnNwZWN0aXZlLCBvZiBub3QgaGF2aW5nIHRoZSBzcGluIGJpdD8gTm90ZSB0aGF0IEknbSBu b3QgYXNraW5nIGZvciB3aGF0IGlzIGFuZCBpcyBub3QgbWVhc3VyYWJsZSAtLSBub3QgZXZlcnl0 aGluZyBtZWFzdXJhYmxlIGlzIHVzZWZ1bC4gSSdtIHNwZWNpZmljYWxseSBhc2tpbmcgaW4gdGVy bXMgb2YgbmV0d29yayBtYW5hZ2VtZW50IGZ1bmN0aW9ucywgaW4gcHJhY3RpY2UsIGFzIHVzZWQg Ynkgb3BlcmF0b3JzLiBTb21lIG9mIHRoaXMgaGFzIGJlZW4gYWRkcmVzc2VkIGluIHRoZSBkaXNj dXNzaW9ucy9kcmFmdHMgSSd2ZSBzZWVuLCBidXQgSSB0aGluayBpdCdzIG1vc3QgdXNlZnVsIHdo ZW4gZnJhbWVkIGluIHRlcm1zIG9mIG5ldHdvcmsgbWFuYWdlbWVudCBmdW5jdGlvbnMuDQpJIHdh bnQgdG8gZXhwcmVzcyB0aGUgcXVlc3Rpb24gYWJvdXQgbWFuYWdlYWJpbGl0eSBmcm9tIGEgZGlm ZmVyZW50IGFuZ2xlLiBRVUlDIG1vdmVzIHRoZSBjb25nZXN0aW9uIGNvbnRyb2wgZnJvbSBiZWlu ZyBhIGNvbW1vbiBmdW5jdGlvbmFsaXR5IGluIHRoZSBrZXJuZWwgdG8gYXBwbGljYXRpb24gZnVu Y3Rpb25hbGl0eS4gSXQgYWxzbyBoaWRlcyB0aGUgcHJvdG9jb2wgaGFuZGxpbmcgb2YgY29uZ2Vz dGlvbiBmcm9tIHRoZSBuZXR3b3JrLiBUaGlzIGdpdmVzIGluY2VudGl2ZXMgZm9yIGFwcGxpY2F0 aW9uIGRldmVsb3BlcnMgdG8gY2hhbmdlIGNvbmdlc3Rpb24gY29udHJvbCB0byBnaXZlIHRoZWly IGFwcGxpY2F0aW9uIGFuIGFkdmFudGFnZSBvdmVyIG90aGVycy4gTm8gc3BlY2lhbCByaWdodHMg YXJlIG5lY2Vzc2FyeS4gTm93IHRoZSBxdWVzdGlvbiBpcyBkb2VzIFFVSUMgcHJvdmlkZSBlbm91 Z2ggbWFuYWdlYWJpbGl0eSB0byBhdm9pZCBhbiBJbnRlcm5ldCAob3Igc29tZSBwYXJ0IG9mIGl0 KSBicmVha2Rvd24gd2hlbiBpdCBpcyBtaXN1c2VkPyBDYW4gaXQgYmUgc2hvd24gdGhhdCB0aGlz IGNhbid0IGhhcHBlbj8NCkkgdGhpbmsgdGhpcyBtYXkgdG91Y2ggb24gc29tZSBvZiB0aGUgdG9w aWNzIGluOg0KaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZhaXJodXJzdC10c3Z3 Zy10cmFuc3BvcnQtZW5jcnlwdC0wNA0KDQpBbHRob3VnaCB0aGlzIGlzIGZvY3Vzc2VkIG9uIGlz c3VlcyB3aWRlciB0aGFuIFF1aWMsIEkgdGhpbmsgdGhlIHBvaW50cyB5b3UgcmFpc2UgYXJlIHJl bGV2YW50LiBUaGlzIHdhcyBwcmVzZW50ZWQgbGFzdCBJRVRGLTEwMCBpbiBUU1ZXRyBhbmQgSU5U QVJFQS4gV2Ugd291bGQgYXBwcmVjaWF0ZSBpbnNpZ2h0LCBhbmQgY29tbWVudHMgb24gdGhpcy4g IChJIGFtIGp1c3QgYWJvdXQgdG8gcHVzaCBuZXcgdmVyc2lvbiB0byBjb3JyZWN0IHR5cG9zISkN Cg0KDQooaWkpIFdoYXQgYXJlIHRoZSBhbHRlcm5hdGl2ZXMgZm9yIGJ1aWxkaW5nIHRoZSBzYW1l IGZ1bmN0aW9ucyB3aXRob3V0IHRoZSBzcGluIGJpdD8gTGV0J3MgY29uc2lkZXIgZm9yIGEgbW9t ZW50IHRoYXQgdGhlIHNwaW4gYml0IGlzbid0IGFjdHVhbGx5IGF2YWlsYWJsZSBpbiBwcmFjdGlj ZS4gV2hhdCB3aWxsIG9wZXJhdG9ycyBkbyB0byBjb250aW51ZSBtYW5hZ2luZyB0aGVpciBuZXR3 b3Jrcz8gVGhpcyBtaWdodCBiZSBleHBlbnNpdmUsIGJ1dCB0aGF0J3MgcHJlY2lzZWx5IHdoYXQg SSdtIGxvb2tpbmcgZm9yIC0tIHRoZSBjb3N0IHRvIG9wZXJhdG9ycyBvZiBub3QgaGF2aW5nIHRo ZSBzcGluIGJpdC4gRm9yIGluc3RhbmNlLCBhY3RpdmUgcHJvYmVzIGFyZSBhIGZpbmUgd2F5IHRv IG1lYXN1cmUgbmV0d29yayBSVFQgd2l0aGluIG9wZXJhdG9yIG5ldHdvcmtzLCBhbmQgdGhhdCBp cyBhbiBhbHRlcm5hdGl2ZS4gVGhlcmUgYXJlIHN1cmVseSBvdGhlcnMgdG9vLiBUaGVpciBjb3N0 cyBhbmQgbGltaXRhdGlvbnMgYXJlIGltcG9ydGFudCB0byBrbm93IGFib3V0IGluIG9yZGVyIHRv IHJlYXNvbiBhYm91dCB0aGVpciB2aWFiaWxpdHksIHNvIEknZCBsaWtlIHRvIHNlZSBhbHRlcm5h dGl2ZXMgY29uc2lkZXJlZC4NClNvbHV0aW9ucyB0aGF0IG9ubHkgd29yayB3aXRoaW4gYW4gb3Bl cmF0b3JzIG5ldHdvcmsgYXJlIG5vdCBlbm91Z2ggd2hlbiBtb3JlIHRoYW4gb25lIG9wZXJhdG9y IGlzIGludm9sdmVkLg0KWWVzLCBhbHNvIHRydWUuDQoNCkdvcnJ5DQoNCg0KSSBkb24ndCBtZWFu IHRvIHN0YXJ0IHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgdGhyZWFkLCBidXQgSSdkIGxpa2UgdG8g dXJnZSB0aG9zZSBnb2luZyBvZmYgdG8gZG8gdGhlIHdyaXRpbmcgdG8gY29uc2lkZXIgdGhlc2Ug cXVlc3Rpb25zLg0KDQotIGphbmENCg0KDQpPbiBTdW4sIE5vdiAyNiwgMjAxNyBhdCAxMToyNiBB TSwgTU9SVE9OLCBBTEZSRUQgQyAoQUwpIDxhY21vcnRvbkBhdHQuY29tPG1haWx0bzphY21vcnRv bkBhdHQuY29tPj4gd3JvdGU6DQpIaSBCcmlhbiwgU3RlcGhlbiwgTGFycywgTWFyayBhbmQgYWxs LA0KDQpvbmUgam9pbiwgb25lIHN1Z2dlc3Rpb24sIGFuZCBvbmUgcXVlc3Rpb24gYmVsb3cuDQpz ZWUgW0FDTV0NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUVVJQyBbbWFp bHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPl0g T24gQmVoYWxmIE9mIEJyaWFuIFRyYW1tZWxsDQo+IChJRVRGKQ0KPiBTZW50OiBXZWRuZXNkYXks IE5vdmVtYmVyIDIyLCAyMDE3IDU6NTkgQU0NCj4gVG86IEVnZ2VydCwgTGFycw0KPiBDYzogTWFy ayBOb3R0aW5naGFtOyBRVUlDIFdHOyBTdGVwaGVuIEZhcnJlbGwNCj4gU3ViamVjdDogUmU6IFNw aW4gYml0IGRpc2N1c3Npb24gLSB3aGVyZSB3ZSdyZSBhdA0KPg0KPiBoaSBMYXJzLA0KPg0KPiA+ IE9uIDIyIE5vdiAyMDE3LCBhdCAxMTozNSwgRWdnZXJ0LCBMYXJzIDxsYXJzQG5ldGFwcC5jb208 bWFpbHRvOmxhcnNAbmV0YXBwLmNvbT4+IHdyb3RlOg0KPiA+DQo+ID4gSGksDQo+ID4NCj4gPiBP biAyMDE3LTExLTIyLCBhdCAxMTowMSwgU3RlcGhlbiBGYXJyZWxsIDxzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllPG1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPj4NCj4gd3JvdGU6DQo+ ID4+IFdoYXQgSSB0aG91Z2h0IHdhcyBiZWluZyByZXF1ZXN0ZWQgYW5kIHdoYXQgSSBkbyB0aGlu ayBpcyByZWFzb25hYmxlDQo+ID4+IGlzIHRvIGRvY3VtZW50IGEgcHJpdmFjeSBhbmFseXNpcyBm b3IgYW55IHF1aWMgcHJvdG9jb2wgYml0cyB0aGF0IGFyZQ0KPiA+PiB2aXNpYmxlIHRvIHRoZSBw YXRoLiBXaGV0aGVyIG9yIG5vdCBzb21lIG9yIGFsbCBvZiB0aGF0IHRleHQgZW5kcyB1cA0KPiA+ PiBpbiBzb21lIFJGQyBpcyBhbm90aGVyIGRheSdzIHdvcmsuDQo+ID4gTGFycyB3cm90ZToNCj4g PiBmb3IgdGhlIFNwaW4gQml0IHNwZWNpZmljYWxseSwgdGhlIGludGVudCB3YXMgdG8gcGVybWFu ZW50bHkgY2FwdHVyZQ0KPiB0aGUgYW5hbHlzaXMgdGhlIERUIGhhcyBkb25lLCBzbyB0aGF0IHdo ZW4gb3RoZXJzIHJldmlldyB0aGUgcHJvcG9zZWQNCj4gU3BpbiBCaXQgc3BlY2lmaWNhdGlvbiwg dGhleSBjYW4gdGFrZSB0aGF0IGFzIGEgZ2l2ZW4gYW5kIGRpcmVjdCBhbnkNCj4gZnVydGhlciBh bmFseXNpcyB0byBvdGhlciBhc3BlY3RzLiBJdCBtYWRlIHNlbnNlIHRvIHRoZSBjaGFpcnMgdGhh dCB0aGF0DQo+IHNwZWNpZmljIGFuYWx5c2lzIHNob3VsZCBiZWNvbWUgcGFydCBvZiB0aGUgU3Bp biBCaXQgc3BlY2lmaWNhdGlvbi4gSQ0KPiB0aGluayB3ZSdkIGJlIG9wZW4gdG8gYSBkaXNjdXNz aW9uIG9uIHdoZXRoZXIgYSBicm9hZGVyIGRvY3VtZW50DQo+IGFuYWx5emluZyB0aGUgUVVJQyB3 aXJlIGltYWdlIHdvdWxkIGJlIGEgYmV0dGVyIGhvbWUgZm9yIHRoaXMuIFRoZSBtYWluDQo+IHBv aW50IGlzIGZvciB0aGUgd29yayB0aGF0IHRoZSBEVCBoYXMgZG9uZSB0byBiZSBkb2N1bWVudGVk Lg0KDQo+IEJyaWFuIHdyb3RlOg0KPiBPa2F5LiBUaGF0J3Mgc29tZXdoYXQgbW9yZSByZWFzb25h YmxlIHRoYW4gd2hhdCBJIHJlYWQgdGhlIGFzayB0byBiZQ0KPiAoIndlJ3JlIGdvaW5nIHRvIGdh dGUgdGhpcyBvbiB0aGUgcGVvcGxlIHdobyBjYXJlIGFib3V0IHRoaXMgZG9pbmcgc29tZQ0KPiBu b24tdHJpdmlhbCBhbW91bnQgb2Ygd29yayIpLiBUaG9zZSBvZiB1cyB3aG8gdm9sdW50ZWVyICho ZWxwLCBwbGVhc2UsDQo+IGFueW9uZT8gOikgKSBjYW4gY2VydGFpbmx5IHB1bGwgdG9nZXRoZXIg d2hhdCB3ZSBoYXZlIGluIGEgc2luZ2xlIEktRA0KPiBhbmQgYXNrIHRoZSBXRyB3aGF0IG1vcmUg aXQgdGhpbmtzIGl0IG5lZWRzLiBUbyBtZSBhbGwgdGhpcyBzZWVtcyBwcmV0dHkNCj4gY2xlYXIs IGJ1dCBJJ3ZlIGJlZW4gd29ya2luZyBvbiB0aGlzIHRvcGljIGZvciBhIHdoaWxlLg0KW0FDTV0N CkhhdmluZyByZWFjaGVkIHRoZSBlbmQgb2YgdGhlICJUaGFua3NnaXZpbmcgdGhyZWFkIiwNCkkn bSBzY3JvbGxpbmcgYmFjayBhIGZldyBwYWdlcyB0byBqb2luIHRoZSB0YXNrIG9mDQpwZXJtYW5l bnRseSBjYXB0dXJpbmcgdGhlIHdvcmsgb2YgdGhlIERUIGluIGFuIEktRCAoYXQgbGVhc3QpOg0K VGhlcmUgc2hvdWxkIGJlIGxhc3RpbmcgdmFsdWUgaW4gc29tZSBvZiBvdXIgZmluZGluZ3MNCmFu ZCBJTU8gdGhleSBhcmUgd29ydGh5IG9mIGEgcGVyc2lzdGVudCByZWZlcmVuY2UuDQoNCj4gTGFy cyB3cm90ZToNCj4gPiBGb3IgcHJvcG9zYWxzIG90aGVyIHRoYW4gdGhlIFNwaW4gQml0IChJIHRo aW5rIEkgaGF2ZSBzZWVuIGluZGl2aWR1YWwNCj4gY29udHJpYnV0b3JzIGF0IGxlYXN0IG1lbnRp b24gImxvc3MiIGFuZCAiY29uZ2VzdGlvbiIgYml0cywgYnV0IHdpdGhvdXQNCj4gbXVjaCBkZXRh aWwpLCB3ZSB3YW50ZWQgdG8gY2xhcmlmeSB0aGF0IHdlJ2QgbGlrZSB0byBzZWUgYW4gYW5hbHlz aXMgYW5kDQo+IGRpc2N1c3Npb24gb2YgdGhlaXIgcHJpdmFjeSBhc3BlY3RzIHRvIHJvdWdobHkg dGhlIHNhbWUgZGVncmVlIGFzIHRoZSBEVA0KPiBoYXMgcGVyZm9ybWVkIGZvciB0aGUgU3BpbiBC aXQgcHJvcG9zYWwuDQo+DQpbQUNNXQ0KSSBzdWdnZXN0IHRoYXQgdGhpcyBtaWdodCBiZSBhIGRp ZmZlcmVudCBJLUQsIGF0IGxlYXN0IHRvIHN0YXJ0Lg0KUXVlc3Rpb246IElzIHRoZXJlIGEgcHJp dmFjeSBhbmFseXNpcyBvZiBwcmVzZW50IEVDTiBhdmFpbGFibGU/DQooYSBzZWFyY2ggeWllbGRl ZCBtYW55IHJlc3VsdHMgd2l0aCBNaXNzaW5nOiBwcml2YWN5KQ0KDQpyZWdhcmRzLA0KQWwNCg0K DQo= --_000_DB4PR07MB348CAF067401CD277485464C2250DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJn aW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBk aXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0 eWxlLW5hbWU6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7fQ0Kc3Bhbi5uDQoJe21zby1zdHlsZS1uYW1lOm47fQ0Kc3Bhbi5uZg0KCXtt c28tc3R5bGUtbmFtZTpuZjt9DQpzcGFuLnANCgl7bXNvLXN0eWxlLW5hbWU6cDt9DQpzcGFuLmsN Cgl7bXNvLXN0eWxlLW5hbWU6azt9DQpzcGFuLm8NCgl7bXNvLXN0eWxlLW5hbWU6bzt9DQpzcGFu Lm1pDQoJe21zby1zdHlsZS1uYW1lOm1pO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10 eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAuODVw dCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+ PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9 ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0 PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0K PC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0K PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgd291bGQgc2F5IHRoYXQgaXQgaXMgcGVyZmVjdGx5IHBvc3Np YmxlIHRvIHRyaWNrIGUuZy4gdGhlIExpbnV4IFRDUCBzdGFjayB0byBzb21ldGhpbmcgbGlrZSB3 aGF0IGlzIGRlc2NyaWJlZCBiZWxvdy4gSnVzdCBjbG9uZSB0Y3BfY29uZy5jICwNCjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhbmdlIHRoZSBmb2xsb3dpbmcgbGluZXMg PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+dTMyDQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwNjZCQiI+PGEgaHJlZj0iaHR0cHM6Ly9l bGl4aXIuZnJlZS1lbGVjdHJvbnMuY29tL2xpbnV4L3YzLjEyL2lkZW50L3RjcF9yZW5vX3NzdGhy ZXNoIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRjRGNkZGIj50Y3BfcmVub19zc3RocmVz aDwvc3Bhbj48L2I+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250 LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNjY2NjY2Ij4oPC9zcGFuPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7O2NvbG9yOiMwMDg4MDAiPnN0cnVjdDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ DQo8YSBocmVmPSJodHRwczovL2VsaXhpci5mcmVlLWVsZWN0cm9ucy5jb20vbGludXgvdjMuMTIv aWRlbnQvc29jayI+PGI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0Y0RjZGRiI+c29jazwvc3Bh bj48L2I+PC9hPg0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPio8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPnNrPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPik8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPns8L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6 YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojMDA4ODAwIj5jb25zdDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztj b2xvcjpibGFjayI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwODgwMCI+c3RydWN0PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxhIGhyZWY9Imh0dHBzOi8vZWxpeGlyLmZyZWUtZWxl Y3Ryb25zLmNvbS9saW51eC92My4xMi9pZGVudC90Y3Bfc29jayI+PGI+PHNwYW4gc3R5bGU9ImJh Y2tncm91bmQ6I0Y0RjZGRiI+dGNwX3NvY2s8L3NwYW4+PC9iPjwvYT4NCjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNjY2NjY2Ij4qPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj50cA0KPC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPj08L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPg0K PGEgaHJlZj0iaHR0cHM6Ly9lbGl4aXIuZnJlZS1lbGVjdHJvbnMuY29tL2xpbnV4L3YzLjEyL2lk ZW50L3RjcF9zayI+PGI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0Y0RjZGRiI+dGNwX3NrPC9z cGFuPjwvYj48L2E+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPig8L3NwYW4+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPnNrPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPik7PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwODgwMCI+cmV0dXJu PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv dXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4NCjxhIGhyZWY9Imh0dHBzOi8vZWxpeGlyLmZy ZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4xMi9pZGVudC9tYXgiPjxiPjxzcGFuIHN0eWxlPSJi YWNrZ3JvdW5kOiNGNEY2RkYiPm1heDwvc3Bhbj48L2I+PC9hPjwvc3Bhbj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xv cjojNjY2NjY2Ij4oPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj50cDwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjojNjY2NjY2Ij4tJmd0Ozwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+c25kX2N3 bmQNCjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjojNjY2NjY2Ij4mZ3Q7Jmd0Ozwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjayI+DQo8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwMDBERCI+MVU8L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+LDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjayI+DQo8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDs7Y29sb3I6IzAwMDBERCI+MlU8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6IzY2 NjY2NiI+KTs8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPn08L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRvIHNvbWV0aGluZyBsaWtlPG86cD48L286cD48L3A+DQo8cHJlPjxzcGFuIGNs YXNzPSJuIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnUzMjwvc3Bhbj48L3NwYW4+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj4gPC9zcGFuPjxzcGFuIGNsYXNzPSJuZiI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDY2QkIiPjxhIGhyZWY9Imh0dHBzOi8vZWxpeGlyLmZyZWUtZWxlY3Ryb25zLmNv bS9saW51eC92My4xMi9pZGVudC90Y3BfcmVub19zc3RocmVzaCI+PGI+PHNwYW4gc3R5bGU9ImJh Y2tncm91bmQ6I0Y0RjZGRiI+dGNwXzwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6I0Y0RjZGRiI+YmxvYXQ8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOiNG NEY2RkYiPl9zc3RocmVzaDwvc3Bhbj48L2I+PC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9 InAiPjxzcGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij4oPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFz cz0iayI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDg4MDAiPnN0cnVjdDwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gPHNwYW4gY2xhc3M9Im4iPjxhIGhyZWY9Imh0dHBzOi8v ZWxpeGlyLmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4xMi9pZGVudC9zb2NrIj48Yj48c3Bh biBzdHlsZT0iYmFja2dyb3VuZDojRjRGNkZGIj5zb2NrPC9zcGFuPjwvYj48L2E+PC9zcGFuPiA8 L3NwYW4+PHNwYW4gY2xhc3M9Im8iPjxzcGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij4qPC9zcGFu Pjwvc3Bhbj48c3BhbiBjbGFzcz0ibiI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5zazwvc3Bh bj48L3NwYW4+PHNwYW4gY2xhc3M9InAiPjxzcGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij4pPC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZT48c3BhbiBjbGFzcz0icCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjY2NjYiPns8 L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj48c3BhbiBjbGFzcz0iayI+PHNwYW4gc3R5 bGU9ImNvbG9yOiMwMDg4MDAiPmNvbnN0PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiA8L3NwYW4+PHNwYW4gY2xhc3M9ImsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA4ODAw Ij5zdHJ1Y3Q8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IDxzcGFuIGNs YXNzPSJuIj48YSBocmVmPSJodHRwczovL2VsaXhpci5mcmVlLWVsZWN0cm9ucy5jb20vbGludXgv djMuMTIvaWRlbnQvdGNwX3NvY2siPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNEY2RkYi PnRjcF9zb2NrPC9zcGFuPjwvYj48L2E+PC9zcGFuPiA8L3NwYW4+PHNwYW4gY2xhc3M9Im8iPjxz cGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij4qPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ibiI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj50cDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj4gPC9zcGFuPjxzcGFuIGNsYXNzPSJvIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2 NjY2NiI+PTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gPHNwYW4gY2xh c3M9Im4iPjxhIGhyZWY9Imh0dHBzOi8vZWxpeGlyLmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92 My4xMi9pZGVudC90Y3Bfc2siPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNEY2RkYiPnRj cF9zazwvc3Bhbj48L2I+PC9hPjwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9InAiPjxzcGFuIHN0 eWxlPSJjb2xvcjojNjY2NjY2Ij4oPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ibiI+PHNwYW4g c3R5bGU9ImNvbG9yOmJsYWNrIj5zazwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9InAiPjxzcGFu IHN0eWxlPSJjb2xvcjojNjY2NjY2Ij4pOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFu PjxzcGFuIGNsYXNzPSJrIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwODgwMCI+cmV0dXJuPC9zcGFu Pjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiA8c3BhbiBjbGFzcz0ibiI+dHA8L3Nw YW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJvIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+LSZn dDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJuIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PnNuZF9jd25kPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0icCI+PHNwYW4gc3R5bGU9ImNvbG9y OiM2NjY2NjYiPjs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48 L286cD48L3NwYW4+PC9wcmU+DQo8cHJlPjxzcGFuIGNsYXNzPSJwIj48c3BhbiBzdHlsZT0iY29s b3I6IzY2NjY2NiI+fTwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1aWxkIGl0IGFuZCBt YWtlIGl0IGEgbG9hZGFibGUga2VybmVsIG1vZHVsZSwgeW91IG5lZWQgdG8gcmVuYW1lIGEgZmV3 IG90aGVyIGZ1bmN0aW9ucyBhcyB3ZWxsLCBhbmQgeW91IGNhbiBjYWxsIGl0IHRjcF9ibG9hdC5j DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fu cy1zZXJpZiI+JiMxMjg1MjI7PC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U28uLiBt eSBvcGluaW9uIGlzIHRoYXQgeW91IGNhbiBwZXJmZWN0bHkgd2VsbCBjb2xsYXBzZSB0aGUgaW50 ZXJuZXQgYWxzbyB3aXRoIFRDUC4gQ29uRXggd2FzIGludHJvZHVjZWQgYXMgYSBtZWRpY2luZSBm b3IgdGhpcyBidXQgaXQgbmV2ZXIgZ2FpbmVkIHRyYWN0aW9uLg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi9JbmdlbWFyPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBw dCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFF MUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+RnJvbTo8L2I+IEdvcnJ5IChlcmcpIFttYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWtd IDxicj4NCjxiPlNlbnQ6PC9iPiBkZW4gMjcgbm92ZW1iZXIgMjAxNyAxNDoxNTxicj4NCjxiPlRv OjwvYj4gUm9sYW5kIFppbmsgJmx0O3JvbGFuZEB6aW5rcy5kZSZndDs8YnI+DQo8Yj5DYzo8L2I+ IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFNwaW4gYml0IGRpc2N1c3Np b24gLSB3aGVyZSB3ZSdyZSBhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNlZSBiZWxvdzo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PGJyPg0KT24gMjcg Tm92IDIwMTcsIGF0IDEyOjMyLCBSb2xhbmQgWmluayAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGFu ZEB6aW5rcy5kZSI+cm9sYW5kQHppbmtzLmRlPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbSAyNy4xMS4y MDE3IHVtIDA4OjAzIHNjaHJpZWIgSmFuYSBJeWVuZ2FyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhZGRpdGlvbiB0byBob3cgdGhlIHNw aW4gYml0IGNhbiBiZSBkZXNpZ25lZCBhbmQgdXNlZCwgSSdkIGxpa2UgdGhvc2UgdGFraW5nIG9u IHRoaXMgZWZmb3J0IHRvIGNvbnNpZGVyIHRoaXMgcXVlc3Rpb246IFdoYXRldmVyIG5ldHdvcmsg bWFuYWdlbWVudCBwcm9ibGVtIHlvdSdyZSBjb25zaWRlcmluZyBzb2x2aW5nIHdpdGggYSBiaXQs IHdoYXQgZG9lcyBpdCB0YWtlIHRvIHNvbHZlIHRoaXMgcHJvYmxlbQ0KIHdpdGhvdXQgdGhlIGJp dCBleHBvc2VkPyBJJ20gYXNraW5nIHlvdSB0byBjb25zaWRlciAmcXVvdDt6ZXJvLWJpdCZxdW90 OyBzb2x1dGlvbnMsIG9yIGF0IGxlYXN0IGZvciBhIGNvc3QvYmVuZWZpdCBhbmFseXNpcyBvZiBk ZXZlbG9waW5nIHNvbHV0aW9ucyB3aXRoIGFuZCB3aXRob3V0IHRoZSBzcGluIGJpdCBmb3Igc3Bl Y2lmaWMgbmV0d29yayBtYW5hZ2VtZW50IGZ1bmN0aW9ucy4gU3BlY2lmaWNhbGx5LA0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oaSkgV2hhdCdzIGltcG9z c2libGUgb3IgdmVyeSBkaWZmaWN1bHQgdG8gZG8sIGZyb20gYSBuZXR3b3JrIG1hbmFnZW1lbnQg cGVyc3BlY3RpdmUsIG9mIG5vdCBoYXZpbmcgdGhlIHNwaW4gYml0PyBOb3RlIHRoYXQgSSdtIG5v dCBhc2tpbmcgZm9yIHdoYXQgaXMgYW5kIGlzIG5vdCBtZWFzdXJhYmxlIC0tIG5vdCBldmVyeXRo aW5nIG1lYXN1cmFibGUgaXMgdXNlZnVsLiBJJ20gc3BlY2lmaWNhbGx5IGFza2luZw0KIGluIHRl cm1zIG9mIG5ldHdvcmsgbWFuYWdlbWVudCBmdW5jdGlvbnMsIGluIHByYWN0aWNlLCBhcyB1c2Vk IGJ5IG9wZXJhdG9ycy4gU29tZSBvZiB0aGlzIGhhcyBiZWVuIGFkZHJlc3NlZCBpbiB0aGUgZGlz Y3Vzc2lvbnMvZHJhZnRzIEkndmUgc2VlbiwgYnV0IEkgdGhpbmsgaXQncyBtb3N0IHVzZWZ1bCB3 aGVuIGZyYW1lZCBpbiB0ZXJtcyBvZiBuZXR3b3JrIG1hbmFnZW1lbnQgZnVuY3Rpb25zLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SSB3YW50IHRvIGV4cHJlc3MgdGhl IHF1ZXN0aW9uIGFib3V0IG1hbmFnZWFiaWxpdHkgZnJvbSBhIGRpZmZlcmVudCBhbmdsZS4gUVVJ QyBtb3ZlcyB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGZyb20gYmVpbmcgYSBjb21tb24gZnVuY3Rp b25hbGl0eSBpbiB0aGUga2VybmVsIHRvIGFwcGxpY2F0aW9uIGZ1bmN0aW9uYWxpdHkuIEl0IGFs c28gaGlkZXMgdGhlIHByb3RvY29sDQogaGFuZGxpbmcgb2YgY29uZ2VzdGlvbiBmcm9tIHRoZSBu ZXR3b3JrLiBUaGlzIGdpdmVzIGluY2VudGl2ZXMgZm9yIGFwcGxpY2F0aW9uIGRldmVsb3BlcnMg dG8gY2hhbmdlIGNvbmdlc3Rpb24gY29udHJvbCB0byBnaXZlIHRoZWlyIGFwcGxpY2F0aW9uIGFu IGFkdmFudGFnZSBvdmVyIG90aGVycy4gTm8gc3BlY2lhbCByaWdodHMgYXJlIG5lY2Vzc2FyeS4g Tm93IHRoZSBxdWVzdGlvbiBpcyBkb2VzIFFVSUMgcHJvdmlkZSBlbm91Z2ggbWFuYWdlYWJpbGl0 eQ0KIHRvIGF2b2lkIGFuIEludGVybmV0IChvciBzb21lIHBhcnQgb2YgaXQpIGJyZWFrZG93biB3 aGVuIGl0IGlzIG1pc3VzZWQ/IENhbiBpdCBiZSBzaG93biB0aGF0IHRoaXMgY2FuJ3QgaGFwcGVu PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIHRoaW5rIHRoaXMgbWF5IHRvdWNoIG9uIHNvbWUgb2YgdGhlIHRvcGljcyBpbjo8bzpw PjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmFpcmh1cnN0LXRzdndnLXRyYW5zcG9ydC1lbmNy eXB0LTA0Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZmFpcmh1cnN0LXRzdndn LXRyYW5zcG9ydC1lbmNyeXB0LTA0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWx0aG91Z2ggdGhpcyBpcyBmb2N1c3NlZCBv biBpc3N1ZXMgd2lkZXIgdGhhbiBRdWljLCBJIHRoaW5rIHRoZSBwb2ludHMgeW91IHJhaXNlIGFy ZSByZWxldmFudC4gVGhpcyB3YXMgcHJlc2VudGVkIGxhc3QgSUVURi0xMDAgaW4gVFNWV0cgYW5k IElOVEFSRUEuIFdlIHdvdWxkIGFwcHJlY2lhdGUgaW5zaWdodCwgYW5kIGNvbW1lbnRzIG9uIHRo aXMuICZuYnNwOyhJIGFtIGp1c3QgYWJvdXQgdG8gcHVzaCBuZXcgdmVyc2lvbg0KIHRvIGNvcnJl Y3QgdHlwb3MhKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KGlpKSBXaGF0IGFyZSB0aGUgYWx0ZXJuYXRpdmVzIGZv ciBidWlsZGluZyB0aGUgc2FtZSBmdW5jdGlvbnMgd2l0aG91dCB0aGUgc3BpbiBiaXQ/IExldCdz IGNvbnNpZGVyIGZvciBhIG1vbWVudCB0aGF0IHRoZSBzcGluIGJpdCBpc24ndCBhY3R1YWxseSBh dmFpbGFibGUgaW4gcHJhY3RpY2UuIFdoYXQgd2lsbCBvcGVyYXRvcnMgZG8gdG8gY29udGludWUg bWFuYWdpbmcgdGhlaXIgbmV0d29ya3M/IFRoaXMgbWlnaHQNCiBiZSBleHBlbnNpdmUsIGJ1dCB0 aGF0J3MgcHJlY2lzZWx5IHdoYXQgSSdtIGxvb2tpbmcgZm9yIC0tIHRoZSBjb3N0IHRvIG9wZXJh dG9ycyBvZiBub3QgaGF2aW5nIHRoZSBzcGluIGJpdC4gRm9yIGluc3RhbmNlLCBhY3RpdmUgcHJv YmVzIGFyZSBhIGZpbmUgd2F5IHRvIG1lYXN1cmUgbmV0d29yayBSVFQgd2l0aGluIG9wZXJhdG9y IG5ldHdvcmtzLCBhbmQgdGhhdCBpcyBhbiBhbHRlcm5hdGl2ZS4gVGhlcmUgYXJlIHN1cmVseSBv dGhlcnMgdG9vLg0KIFRoZWlyIGNvc3RzIGFuZCBsaW1pdGF0aW9ucyBhcmUgaW1wb3J0YW50IHRv IGtub3cgYWJvdXQgaW4gb3JkZXIgdG8gcmVhc29uIGFib3V0IHRoZWlyIHZpYWJpbGl0eSwgc28g SSdkIGxpa2UgdG8gc2VlIGFsdGVybmF0aXZlcyBjb25zaWRlcmVkLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U29sdXRpb25zIHRoYXQgb25seSB3b3JrIHdpdGhpbiBh biBvcGVyYXRvcnMgbmV0d29yayBhcmUgbm90IGVub3VnaCB3aGVuIG1vcmUgdGhhbiBvbmUgb3Bl cmF0b3IgaXMgaW52b2x2ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcywgYWxzbyB0cnVlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb3JyeTxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSBkb24ndCBtZWFuIHRvIHN0YXJ0IHRoZSBkaXNjdXNzaW9uIG9uIHRoaXMgdGhyZWFkLCBi dXQgSSdkIGxpa2UgdG8gdXJnZSB0aG9zZSBnb2luZyBvZmYgdG8gZG8gdGhlIHdyaXRpbmcgdG8g Y29uc2lkZXIgdGhlc2UgcXVlc3Rpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIGphbmE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE5vdiAyNiwgMjAxNyBhdCAxMToy NiBBTSwgTU9SVE9OLCBBTEZSRUQgQyAoQUwpICZsdDs8YSBocmVmPSJtYWlsdG86YWNtb3J0b25A YXR0LmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmFjbW9ydG9uQGF0dC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPkhpIEJyaWFuLCBTdGVwaGVuLCBMYXJzLCBNYXJrIGFuZCBh bGwsPGJyPg0KPGJyPg0Kb25lIGpvaW4sIG9uZSBzdWdnZXN0aW9uLCBhbmQgb25lIHF1ZXN0aW9u IGJlbG93Ljxicj4NCnNlZSBbQUNNXTxicj4NCiZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS08YnI+DQomZ3Q7IEZyb206IFFVSUMgW21haWx0bzo8YSBocmVmPSJtYWlsdG86cXVpYy1ib3Vu Y2VzQGlldGYub3JnIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBPbiBCZWhhbGYgT2YgQnJp YW4gVHJhbW1lbGw8YnI+DQomZ3Q7IChJRVRGKTxicj4NCiZndDsgU2VudDogV2VkbmVzZGF5LCBO b3ZlbWJlciAyMiwgMjAxNyA1OjU5IEFNPGJyPg0KJmd0OyBUbzogRWdnZXJ0LCBMYXJzPGJyPg0K Jmd0OyBDYzogTWFyayBOb3R0aW5naGFtOyBRVUlDIFdHOyBTdGVwaGVuIEZhcnJlbGw8YnI+DQom Z3Q7IFN1YmplY3Q6IFJlOiBTcGluIGJpdCBkaXNjdXNzaW9uIC0gd2hlcmUgd2UncmUgYXQ8YnI+ DQomZ3Q7PGJyPg0KJmd0OyBoaSBMYXJzLDxicj4NCiZndDs8YnI+DQomZ3Q7ICZndDsgT24gMjIg Tm92IDIwMTcsIGF0IDExOjM1LCBFZ2dlcnQsIExhcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpsYXJz QG5ldGFwcC5jb20iPmxhcnNAbmV0YXBwLmNvbTwvYT4mZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gMjAx Ny0xMS0yMiwgYXQgMTE6MDEsIFN0ZXBoZW4gRmFycmVsbCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnN0 ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiPnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWU8L2E+Jmd0 Ozxicj4NCiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBXaGF0IEkgdGhvdWdodCB3YXMg YmVpbmcgcmVxdWVzdGVkIGFuZCB3aGF0IEkgZG8gdGhpbmsgaXMgcmVhc29uYWJsZTxicj4NCiZn dDsgJmd0OyZndDsgaXMgdG8gZG9jdW1lbnQgYSBwcml2YWN5IGFuYWx5c2lzIGZvciBhbnkgcXVp YyBwcm90b2NvbCBiaXRzIHRoYXQgYXJlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyB2aXNpYmxlIHRvIHRo ZSBwYXRoLiBXaGV0aGVyIG9yIG5vdCBzb21lIG9yIGFsbCBvZiB0aGF0IHRleHQgZW5kcyB1cDxi cj4NCiZndDsgJmd0OyZndDsgaW4gc29tZSBSRkMgaXMgYW5vdGhlciBkYXkncyB3b3JrLjxicj4N CiZndDsgJmd0OyBMYXJzIHdyb3RlOjxicj4NCiZndDsgJmd0OyBmb3IgdGhlIFNwaW4gQml0IHNw ZWNpZmljYWxseSwgdGhlIGludGVudCB3YXMgdG8gcGVybWFuZW50bHkgY2FwdHVyZTxicj4NCiZn dDsgdGhlIGFuYWx5c2lzIHRoZSBEVCBoYXMgZG9uZSwgc28gdGhhdCB3aGVuIG90aGVycyByZXZp ZXcgdGhlIHByb3Bvc2VkPGJyPg0KJmd0OyBTcGluIEJpdCBzcGVjaWZpY2F0aW9uLCB0aGV5IGNh biB0YWtlIHRoYXQgYXMgYSBnaXZlbiBhbmQgZGlyZWN0IGFueTxicj4NCiZndDsgZnVydGhlciBh bmFseXNpcyB0byBvdGhlciBhc3BlY3RzLiBJdCBtYWRlIHNlbnNlIHRvIHRoZSBjaGFpcnMgdGhh dCB0aGF0PGJyPg0KJmd0OyBzcGVjaWZpYyBhbmFseXNpcyBzaG91bGQgYmVjb21lIHBhcnQgb2Yg dGhlIFNwaW4gQml0IHNwZWNpZmljYXRpb24uIEk8YnI+DQomZ3Q7IHRoaW5rIHdlJ2QgYmUgb3Bl biB0byBhIGRpc2N1c3Npb24gb24gd2hldGhlciBhIGJyb2FkZXIgZG9jdW1lbnQ8YnI+DQomZ3Q7 IGFuYWx5emluZyB0aGUgUVVJQyB3aXJlIGltYWdlIHdvdWxkIGJlIGEgYmV0dGVyIGhvbWUgZm9y IHRoaXMuIFRoZSBtYWluPGJyPg0KJmd0OyBwb2ludCBpcyBmb3IgdGhlIHdvcmsgdGhhdCB0aGUg RFQgaGFzIGRvbmUgdG8gYmUgZG9jdW1lbnRlZC48YnI+DQo8YnI+DQomZ3Q7IEJyaWFuIHdyb3Rl Ojxicj4NCiZndDsgT2theS4gVGhhdCdzIHNvbWV3aGF0IG1vcmUgcmVhc29uYWJsZSB0aGFuIHdo YXQgSSByZWFkIHRoZSBhc2sgdG8gYmU8YnI+DQomZ3Q7ICgmcXVvdDt3ZSdyZSBnb2luZyB0byBn YXRlIHRoaXMgb24gdGhlIHBlb3BsZSB3aG8gY2FyZSBhYm91dCB0aGlzIGRvaW5nIHNvbWU8YnI+ DQomZ3Q7IG5vbi10cml2aWFsIGFtb3VudCBvZiB3b3JrJnF1b3Q7KS4gVGhvc2Ugb2YgdXMgd2hv IHZvbHVudGVlciAoaGVscCwgcGxlYXNlLDxicj4NCiZndDsgYW55b25lPyA6KSApIGNhbiBjZXJ0 YWlubHkgcHVsbCB0b2dldGhlciB3aGF0IHdlIGhhdmUgaW4gYSBzaW5nbGUgSS1EPGJyPg0KJmd0 OyBhbmQgYXNrIHRoZSBXRyB3aGF0IG1vcmUgaXQgdGhpbmtzIGl0IG5lZWRzLiBUbyBtZSBhbGwg dGhpcyBzZWVtcyBwcmV0dHk8YnI+DQomZ3Q7IGNsZWFyLCBidXQgSSd2ZSBiZWVuIHdvcmtpbmcg b24gdGhpcyB0b3BpYyBmb3IgYSB3aGlsZS48YnI+DQpbQUNNXTxicj4NCkhhdmluZyByZWFjaGVk IHRoZSBlbmQgb2YgdGhlICZxdW90O1RoYW5rc2dpdmluZyB0aHJlYWQmcXVvdDssPGJyPg0KSSdt IHNjcm9sbGluZyBiYWNrIGEgZmV3IHBhZ2VzIHRvIGpvaW4gdGhlIHRhc2sgb2Y8YnI+DQpwZXJt YW5lbnRseSBjYXB0dXJpbmcgdGhlIHdvcmsgb2YgdGhlIERUIGluIGFuIEktRCAoYXQgbGVhc3Qp Ojxicj4NClRoZXJlIHNob3VsZCBiZSBsYXN0aW5nIHZhbHVlIGluIHNvbWUgb2Ygb3VyIGZpbmRp bmdzPGJyPg0KYW5kIElNTyB0aGV5IGFyZSB3b3J0aHkgb2YgYSBwZXJzaXN0ZW50IHJlZmVyZW5j ZS48YnI+DQo8YnI+DQomZ3Q7IExhcnMgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEZvciBwcm9wb3Nh bHMgb3RoZXIgdGhhbiB0aGUgU3BpbiBCaXQgKEkgdGhpbmsgSSBoYXZlIHNlZW4gaW5kaXZpZHVh bDxicj4NCiZndDsgY29udHJpYnV0b3JzIGF0IGxlYXN0IG1lbnRpb24gJnF1b3Q7bG9zcyZxdW90 OyBhbmQgJnF1b3Q7Y29uZ2VzdGlvbiZxdW90OyBiaXRzLCBidXQgd2l0aG91dDxicj4NCiZndDsg bXVjaCBkZXRhaWwpLCB3ZSB3YW50ZWQgdG8gY2xhcmlmeSB0aGF0IHdlJ2QgbGlrZSB0byBzZWUg YW4gYW5hbHlzaXMgYW5kPGJyPg0KJmd0OyBkaXNjdXNzaW9uIG9mIHRoZWlyIHByaXZhY3kgYXNw ZWN0cyB0byByb3VnaGx5IHRoZSBzYW1lIGRlZ3JlZSBhcyB0aGUgRFQ8YnI+DQomZ3Q7IGhhcyBw ZXJmb3JtZWQgZm9yIHRoZSBTcGluIEJpdCBwcm9wb3NhbC48YnI+DQomZ3Q7PGJyPg0KW0FDTV08 YnI+DQpJIHN1Z2dlc3QgdGhhdCB0aGlzIG1pZ2h0IGJlIGEgZGlmZmVyZW50IEktRCwgYXQgbGVh c3QgdG8gc3RhcnQuPGJyPg0KUXVlc3Rpb246IElzIHRoZXJlIGEgcHJpdmFjeSBhbmFseXNpcyBv ZiBwcmVzZW50IEVDTiBhdmFpbGFibGU/PGJyPg0KKGEgc2VhcmNoIHlpZWxkZWQgbWFueSByZXN1 bHRzIHdpdGggTWlzc2luZzogcHJpdmFjeSk8YnI+DQo8YnI+DQpyZWdhcmRzLDxicj4NCkFsPG86 cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DB4PR07MB348CAF067401CD277485464C2250DB4PR07MB348eurprd_-- From nobody Mon Nov 27 06:43: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 DECBD124D37 for ; Mon, 27 Nov 2017 06:43: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, 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=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 CHrDn1tLSR_1 for ; Mon, 27 Nov 2017 06:43:18 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::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 1F00E1242EA for ; Mon, 27 Nov 2017 06:43:18 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id x63so36484074ioe.6 for ; Mon, 27 Nov 2017 06:43: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=Wiz+GC9b55gW62aNfcgYN382du3M8/LrFKLf04zmsL0=; b=BZs7DqFea3YLtTb2X/zDUcO4s9kj3Dd52ZV/MB71b+rBo/xSiTIDKAhv0YQIQd0ciV vyoBhHGQ4k3XTxERRg59J2vnRiGniroh3DmnjFYdN3Z2ejfaAG4DIE9poHv+A4ZyUhRE 3Bhf84eor7USRGoHD4fVoyyKD+gzQYQZ6n71sEXUXTSEnjb2aE5w3ruf3oMBDSZmNZTR woEM2WIb6EebwiZdHDaIZ4/046/TOE0xm0onvMadIIBH1Yx7RrQZB4y01WShpGkl9ztZ d25NQ6D5WspJMnhgxAfONEgLOnKUR+8t27tcAREzHozSXjmy7POkuQm7iu3x1RST63Nu tZ7Q== 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=Wiz+GC9b55gW62aNfcgYN382du3M8/LrFKLf04zmsL0=; b=XbQWuLBoWCd9Xm/Jg1Nr0VG3X0GKi0+ypJPWo0iXgAh7x26EmFZ1oCmmOEYhBxrH94 Ed7YU2vxWdAVzL1m5do8n9x6tkl/7DYm+XT0vsB2bP6AZdV1tR1UTd4ZOlsqs4Hs+VXq 1GnZCUfqbTbY0vjxdEyLnZEcOoIbNuC1W3Tr+S7YTovP+uudE4VfcS6BkvSEq+EWBtoM txGp9tcOaC/HMqGK4bE03Xo38KmHXqEpXdijRw5pUzOAIiCAWqVm6DvowmMVOFZx3jLt EOJQ7mFz4pRs/9fBMBzc/AGgEhjKK1VPyq+dsLfkfTdxcqa0e+LnkLTlNbu2ra0GX63R QsDg== X-Gm-Message-State: AJaThX4M2RShbJKljLBtuoAmJbD7xINcfuL6/xpYirf/eXdkBPwU4w2a Wd8pKo8a4GNQU2x0m+CzePIVljLB4n4936dwTy1drQ== X-Google-Smtp-Source: AGs4zMatEwe6SaCrGj5h0hMfhQ85zCII5/3IyqyzELfNEXJwxiRvjbLWjO7ju1Aup8q/M8vVHcLpaCrbGGmSoX1BLzo= X-Received: by 10.107.183.76 with SMTP id h73mr43257247iof.154.1511793797120; Mon, 27 Nov 2017 06:43:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.101.16 with HTTP; Mon, 27 Nov 2017 06:42:56 -0800 (PST) In-Reply-To: References: <5108b3b9-d374-0709-3e6f-57c3192469b8@tessares.net> From: Ian Swett Date: Mon, 27 Nov 2017 09:42:56 -0500 Message-ID: Subject: Re: reserved bits for spin bit, etc. To: Olivier Bonaventure Cc: Martin Thomson , "quic@ietf.org" , Christian Huitema Content-Type: multipart/alternative; boundary="94eb2c0b9e3a40da29055ef7ece1" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:43:20 -0000 --94eb2c0b9e3a40da29055ef7ece1 Content-Type: text/plain; charset="UTF-8" Sorry to go off-topic, but... I strongly agree with Martin that we want to use connection ID for routing, and not add a path ID. An explicit goal of QUIC multipath should be to look as similar(or ideally be indistinguishable) from single path QUIC. Adding a path ID makes it trivial to link paths, which creates a known privacy issue and I believe is much more risky than any measurement bits we've ever discussed exposing. The details of how to divide up the packet number space can be discussed later, but it's clear to me that's a viable solution, and QUIC already has mechanisms for changing the connection ID mid-connection, so building upon them is the right approach. On Mon, Nov 27, 2017 at 2:37 AM, Olivier Bonaventure < olivier.bonaventure@tessares.net> wrote: > Martin, > >> >>> We cannot quite agree on the spin bit, let alone further management >>>> bits. On the other hand, we see that there is clear interest from >>>> something like that with at least part of the WG, we want to see some >>>> experimentation, and we understand that the specification can proceed >>>> independently from the base protocol development. Hence, I would like to >>>> make a modest proposal. >>>> >>>> Can we mark one or possibly two bits as reserved in the first byte of >>>> the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be >>>> ignored when receiving, MAY be used for experiments between consenting >>>> nodes? >>>> >>> >>> >>> Having some spare bits in the base header will clearly be useful. In >>> addition to the discussion on the spin bit, let me also point that a >>> proposed design for multipath quic also uses one of the spare bits in the >>> public header >>> >>> https://tools.ietf.org/html/draft-deconinck-multipath-quic-00 >>> >> >> I don't think that this is a good design. I think that we definitely >> need to discuss the separation of the packet number space when it >> comes to multipath, using the connection ID is superior to adding >> another byte to the header. For one, it's something we want to change >> anyway. >> >> The important point is to have different packet number spaces on the > different paths. There are different ways to signal those number spaces. > > The draft proposes an explicit signal which is present in the publich > header of each packet. One benefit of this approach is that a > load-balancing router could use this information to forward the packets > belonging to different paths of a single QUIC session over different paths. > > Using the connection id is a different way to distinguish different packet > number spaces. In this case, there is no need for using space in the public > header but we need to define QUIC frames to associate different connection > ids to the same QUIC session. This seems possible as well, but in contrast > with the above approach, a load-balancing router would not be able to > easily load-balance the packets of a single QUIC session to different paths > since there is no structure in the connection id. > > There are tradeoffs in any multipath design. I'd suggest that when the WG > starts to work on multipath we look at detailed proposals. > > > > Olivier > > > -- > > ------------------------------ > DISCLAIMER. > This email and any files transmitted with it are confidential and intended > solely for the use of the individual or entity to whom they are addressed. > If you have received this email in error please notify the system manager. > This message contains confidential information and is intended only for the > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipient > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > > --94eb2c0b9e3a40da29055ef7ece1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sorry to go off-topic, but...

I s= trongly agree with Martin that we want to use connection ID for routing, an= d not add a path ID.=C2=A0 An explicit goal of QUIC multipath should be to = look as similar(or ideally be indistinguishable) from single path QUIC.=C2= =A0 Adding a path ID makes it trivial to link paths, which creates a known = privacy issue and I believe is much more risky than any measurement bits we= 've ever discussed exposing.

The details of how to d= ivide up the packet number space can be discussed later, but it's clear= to me that's a viable solution, and QUIC already has mechanisms for ch= anging the connection ID mid-connection, so building upon them is the right= approach.

On Mon, Nov 27, 2017 at 2:37 AM, Olivier Bonaventure <= olivier.bonaventure@tessares.net> wrote:
Martin,

We cannot quite agree on the spin bit, let alone further management
bits. On the other hand, we see that there is clear interest from
something like that with at least part of the WG, we want to see some
experimentation, and we understand that the specification can proceed
independently from the base protocol development. Hence, I would like to make a modest proposal.

Can we mark one or possibly two bits as reserved in the first byte of
the QUIC header? Specify them as SHOULD be zero when sending, SHOULD be
ignored when receiving, MAY be used for experiments between consenting
nodes?


Having some spare bits in the base header will clearly be useful. In
addition to the discussion on the spin bit, let me also point that a
proposed design for multipath quic also uses one of the spare bits in the public header

https://tools.ietf.org/html/draft-= deconinck-multipath-quic-00

I don't think that this is a good design.=C2=A0 I think that we definit= ely
need to discuss the separation of the packet number space when it
comes to multipath, using the connection ID is superior to adding
another byte to the header.=C2=A0 For one, it's something we want to ch= ange
anyway.

 The important point is to have different packet number spaces on the differ= ent paths. There are different ways to signal those number spaces.

The draft proposes an explicit signal which is present in the publich heade= r of each packet. One benefit of this approach is that a load-balancing rou= ter could use this information to forward the packets belonging to differen= t paths of a single QUIC session over different paths.

Using the connection id is a different way to distinguish different packet = number spaces. In this case, there is no need for using space in the public= header but we need to define QUIC frames to associate different connection= ids to the same QUIC session. This seems possible as well, but in contrast= with the above approach, a load-balancing router would not be able to easi= ly load-balance the packets of a single QUIC session to different paths sin= ce there is no structure in the connection id.

There are tradeoffs in any multipath design. I'd suggest that when the = WG starts to work on multipath we look at detailed proposals.



Olivier


--

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended = solely for the use of the individual or entity to whom they are addressed. = If you have received this email in error please notify the system manager. = This message contains confidential information and is intended only for the= individual named. If you are not the named addressee you should not dissem= inate, distribute or copy this e-mail. Please notify the sender immediately= by e-mail if you have received this e-mail by mistake and delete this e-ma= il from your system. If you are not the intended recipient you are notified= that disclosing, copying, distributing or taking any action in reliance on= the contents of this information is strictly prohibited.


--94eb2c0b9e3a40da29055ef7ece1-- From nobody Mon Nov 27 06:48: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 493AB126D85 for ; Mon, 27 Nov 2017 06:48:06 -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 KP0zYEkP1chM for ; Mon, 27 Nov 2017 06:48:02 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::9]) (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 2D014124D37 for ; Mon, 27 Nov 2017 06:48:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1511794080; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:X-RZG-CLASS-ID:X-RZG-AUTH:Accept-Language: Auto-Submitted:Cc:Date:From:Message-ID:References:Reply-To:Resent-Cc: Resent-Date:Resent-From:Resent-To:Sender:Subject:To: Content-Alternative:Content-Description:Content-Disposition: Content-Duration:Content-Features:Content-ID:Content-Language: Content-Location:Content-MD5:Content-Transfer-Encoding:Content-Type: MIME-Version; bh=ePF/ANCr7GNxiyloTO665nfzXzkVEc8eX9fi2gfRC4I=; b=dWcnSVQUyB9gciD879WMAPeqnr/wEbeGDJcfSnY1Wwt43qGG0aLsDNsRFkRoFlhW6Z Q2yvQNbmWtftPk0JY+GOR/HykKKu5DTULg5vUIHFV/sW6SGvfFOHiyh4UF56gWjYFRsT PuWIY66LlHfZsxiD0rv1QprDfW+N5BAJJcKek= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1oaZ1h8oElTTgmJ6Fg== X-RZG-CLASS-ID: mo00 Received: from [10.10.10.80] (p57B96C2D.dip0.t-ipconnect.de [87.185.108.45]) by smtp.strato.de (RZmta 42.10 DYNA|AUTH) with ESMTPSA id e03071tARElv0fP (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Mon, 27 Nov 2017 15:47:57 +0100 (CET) Subject: Re: Spin bit discussion - where we're at To: Ingemar Johansson S , "Gorry (erg)" Cc: "quic@ietf.org" References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@erg.abdn.ac.uk> From: Roland Zink Message-ID: <74e1c7bd-bd09-3285-db25-db04fe530cbc@zinks.de> Date: Mon, 27 Nov 2017 15:47:57 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------12F2CC8FA2A9C19B1A03D95C" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 14:48:06 -0000 This is a multi-part message in MIME format. --------------12F2CC8FA2A9C19B1A03D95C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I guess the guys which really want to do it will somehow get the necessary rights (like to load a kernel module) and do it although this may be difficult if you want to do it on million of devices. I'm more thinking of a slow process, say app 1 increase the initial window then app 2 thinks it needs to do the same and back out less than the default. Then app 1 is doing something and at some point nobody follows what is (will be) in the RFC. They not necessarily want to break something but at the end it can result into the same. It is no longer a single policy which applies to all apps instead each app comes with its own and the apps often can control both sides. Roland Am 27.11.2017 um 15:14 schrieb Ingemar Johansson S: > > Hi > > I would say that it is perfectly possible to trick e.g. the Linux TCP > stack to something like what is described below. Just clone tcp_cong.c , > > Change the following lines > > u32 *tcp_reno_ssthresh* > (struct*sock* > *sk) > > { > > conststruct*tcp_sock* > *tp > =*tcp_sk* > (sk); > > return*max* > (tp->snd_cwnd > >>1U,2U); > > } > > To something like > > u32*tcp_**bloat**_ssthresh* > (struct*sock* > *sk) > { > conststruct*tcp_sock* > > *tp=*tcp_sk* > (sk); > returntp->snd_cwnd; > } > > Build it and make it a loadable kernel module, you need to rename a > few other functions as well, and you can call it tcp_bloat.c 😊 > > So.. my opinion is that you can perfectly well collapse the internet > also with TCP. ConEx was introduced as a medicine for this but it > never gained traction. > > /Ingemar > > *From:* Gorry (erg) [mailto:gorry@erg.abdn.ac.uk] > *Sent:* den 27 november 2017 14:15 > *To:* Roland Zink > *Cc:* quic@ietf.org > *Subject:* Re: Spin bit discussion - where we're at > > See below: > > > On 27 Nov 2017, at 12:32, Roland Zink > wrote: > > Am 27.11.2017 um 08:03 schrieb Jana Iyengar: > > In addition to how the spin bit can be designed and used, I'd > like those taking on this effort to consider this question: > Whatever network management problem you're considering solving > with a bit, what does it take to solve this problem without > the bit exposed? I'm asking you to consider "zero-bit" > solutions, or at least for a cost/benefit analysis of > developing solutions with and without the spin bit for > specific network management functions. Specifically, > > (i) What's impossible or very difficult to do, from a network > management perspective, of not having the spin bit? Note that > I'm not asking for what is and is not measurable -- not > everything measurable is useful. I'm specifically asking in > terms of network management functions, in practice, as used by > operators. Some of this has been addressed in the > discussions/drafts I've seen, but I think it's most useful > when framed in terms of network management functions. > > I want to express the question about manageability from a > different angle. QUIC moves the congestion control from being a > common functionality in the kernel to application functionality. > It also hides the protocol handling of congestion from the > network. This gives incentives for application developers to > change congestion control to give their application an advantage > over others. No special rights are necessary. Now the question is > does QUIC provide enough manageability to avoid an Internet (or > some part of it) breakdown when it is misused? Can it be shown > that this can't happen? > > I think this may touch on some of the topics in: > > https://tools.ietf.org/html/draft-fairhurst-tsvwg-transport-encrypt-04 > > Although this is focussed on issues wider than Quic, I think the > points you raise are relevant. This was presented last IETF-100 in > TSVWG and INTAREA. We would appreciate insight, and comments on this. >  (I am just about to push new version to correct typos!) > > > > (ii) What are the alternatives for building the same functions > without the spin bit? Let's consider for a moment that the > spin bit isn't actually available in practice. What will > operators do to continue managing their networks? This might > be expensive, but that's precisely what I'm looking for -- the > cost to operators of not having the spin bit. For instance, > active probes are a fine way to measure network RTT within > operator networks, and that is an alternative. There are > surely others too. Their costs and limitations are important > to know about in order to reason about their viability, so I'd > like to see alternatives considered. > > Solutions that only work within an operators network are not > enough when more than one operator is involved. > > Yes, also true. > > Gorry > > I don't mean to start the discussion on this thread, but I'd > like to urge those going off to do the writing to consider > these questions. > > - jana > > On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) > > wrote: > > Hi Brian, Stephen, Lars, Mark and all, > > one join, one suggestion, and one question below. > see [ACM] > > -----Original Message----- > > From: QUIC [mailto:quic-bounces@ietf.org > ] On Behalf Of Brian Trammell > > (IETF) > > Sent: Wednesday, November 22, 2017 5:59 AM > > To: Eggert, Lars > > Cc: Mark Nottingham; QUIC WG; Stephen Farrell > > Subject: Re: Spin bit discussion - where we're at > > > > hi Lars, > > > > > On 22 Nov 2017, at 11:35, Eggert, Lars > > wrote: > > > > > > Hi, > > > > > > On 2017-11-22, at 11:01, Stephen Farrell > > > > wrote: > > >> What I thought was being requested and what I do > think is reasonable > > >> is to document a privacy analysis for any quic > protocol bits that are > > >> visible to the path. Whether or not some or all of > that text ends up > > >> in some RFC is another day's work. > > > Lars wrote: > > > for the Spin Bit specifically, the intent was to > permanently capture > > the analysis the DT has done, so that when others review > the proposed > > Spin Bit specification, they can take that as a given > and direct any > > further analysis to other aspects. It made sense to the > chairs that that > > specific analysis should become part of the Spin Bit > specification. I > > think we'd be open to a discussion on whether a broader > document > > analyzing the QUIC wire image would be a better home for > this. The main > > point is for the work that the DT has done to be documented. > > > Brian wrote: > > Okay. That's somewhat more reasonable than what I read > the ask to be > > ("we're going to gate this on the people who care about > this doing some > > non-trivial amount of work"). Those of us who volunteer > (help, please, > > anyone? :) ) can certainly pull together what we have in > a single I-D > > and ask the WG what more it thinks it needs. To me all > this seems pretty > > clear, but I've been working on this topic for a while. > [ACM] > Having reached the end of the "Thanksgiving thread", > I'm scrolling back a few pages to join the task of > permanently capturing the work of the DT in an I-D (at least): > There should be lasting value in some of our findings > and IMO they are worthy of a persistent reference. > > > Lars wrote: > > > For proposals other than the Spin Bit (I think I have > seen individual > > contributors at least mention "loss" and "congestion" > bits, but without > > much detail), we wanted to clarify that we'd like to see > an analysis and > > discussion of their privacy aspects to roughly the same > degree as the DT > > has performed for the Spin Bit proposal. > > > [ACM] > I suggest that this might be a different I-D, at least to > start. > Question: Is there a privacy analysis of present ECN > available? > (a search yielded many results with Missing: privacy) > > regards, > Al > --------------12F2CC8FA2A9C19B1A03D95C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8cD5JIGd1ZXNzIHRo ZSBndXlzIHdoaWNoIHJlYWxseSB3YW50IHRvIGRvIGl0IHdpbGwgc29tZWhvdyBnZXQgdGhl DQogICAgICBuZWNlc3NhcnkgcmlnaHRzIChsaWtlIHRvIGxvYWQgYSBrZXJuZWwgbW9kdWxl KSBhbmQgZG8gaXQgYWx0aG91Z2gNCiAgICAgIHRoaXMgbWF5IGJlIGRpZmZpY3VsdCBpZiB5 b3Ugd2FudCB0byBkbyBpdCBvbiBtaWxsaW9uIG9mIGRldmljZXMuDQogICAgICBJJ20gbW9y ZSB0aGlua2luZyBvZiBhIHNsb3cgcHJvY2Vzcywgc2F5IGFwcCAxIGluY3JlYXNlIHRoZQ0K ICAgICAgaW5pdGlhbCB3aW5kb3cgdGhlbiBhcHAgMiB0aGlua3MgaXQgbmVlZHMgdG8gZG8g dGhlIHNhbWUgYW5kIGJhY2sNCiAgICAgIG91dCBsZXNzIHRoYW4gdGhlIGRlZmF1bHQuIFRo ZW4gYXBwIDEgaXMgZG9pbmcgc29tZXRoaW5nIGFuZCBhdA0KICAgICAgc29tZSBwb2ludCBu b2JvZHkgZm9sbG93cyB3aGF0IGlzICh3aWxsIGJlKSBpbiB0aGUgUkZDLiBUaGV5IG5vdA0K ICAgICAgbmVjZXNzYXJpbHkgd2FudCB0byBicmVhayBzb21ldGhpbmcgYnV0IGF0IHRoZSBl bmQgaXQgY2FuIHJlc3VsdA0KICAgICAgaW50byB0aGUgc2FtZS4gSXQgaXMgbm8gbG9uZ2Vy IGEgc2luZ2xlIHBvbGljeSB3aGljaCBhcHBsaWVzIHRvDQogICAgICBhbGwgYXBwcyBpbnN0 ZWFkIGVhY2ggYXBwIGNvbWVzIHdpdGggaXRzIG93biBhbmQgdGhlIGFwcHMgb2Z0ZW4NCiAg ICAgIGNhbiBjb250cm9sIGJvdGggc2lkZXMuPGJyPg0KICAgIDwvcD4NCiAgICA8cD48YnI+ DQogICAgPC9wPg0KICAgIDxwPlJvbGFuZDxicj4NCiAgICA8L3A+DQogICAgPGJyPg0KICAg IDxicj4NCiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPkFtIDI3LjExLjIwMTcg dW0gMTU6MTQgc2NocmllYiBJbmdlbWFyDQogICAgICBKb2hhbnNzb24gUzo8YnI+DQogICAg PC9kaXY+DQogICAgPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSINCmNpdGU9Im1pZDpEQjRQUjA3 TUIzNDhDQUYwNjc0MDFDRDI3NzQ4NTQ2NEMyMjUwQERCNFBSMDdNQjM0OC5ldXJwcmQwNy5w cm9kLm91dGxvb2suY29tIj4NCiAgICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlw ZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgICAgIDxtZXRhIG5h bWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkDQog ICAgICAgIG1lZGl1bSkiPg0KICAgICAgPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlv bnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFu b3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUg RGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmss IHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpi bHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFy IjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KcC5tc29ub3JtYWwwLCBs aS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3Jt YWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwgUHJlZm9y bWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5uDQoJe21zby1zdHlsZS1uYW1lOm47fQ0Kc3Bhbi5uZg0KCXttc28tc3R5bGUtbmFt ZTpuZjt9DQpzcGFuLnANCgl7bXNvLXN0eWxlLW5hbWU6cDt9DQpzcGFuLmsNCgl7bXNvLXN0 eWxlLW5hbWU6azt9DQpzcGFuLm8NCgl7bXNvLXN0eWxlLW5hbWU6bzt9DQpzcGFuLm1pDQoJ e21zby1zdHlsZS1uYW1lOm1pO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24x DQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3MC44NXB0IDcwLjg1cHQgNzAu ODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7 fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4N CjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0Pjwv eG1sPjwhW2VuZGlmXS0tPg0KICAgICAgPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCiAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGk8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD7CoDwvbzpwPjwvcD4NCiAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBzYXkgdGhhdCBpdCBpcyBwZXJmZWN0bHkgcG9zc2li bGUNCiAgICAgICAgICB0byB0cmljayBlLmcuIHRoZSBMaW51eCBUQ1Agc3RhY2sgdG8gc29t ZXRoaW5nIGxpa2Ugd2hhdCBpcw0KICAgICAgICAgIGRlc2NyaWJlZCBiZWxvdy4gSnVzdCBj bG9uZSB0Y3BfY29uZy5jICwNCiAgICAgICAgICA8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hhbmdlIHRoZSBmb2xsb3dpbmcgbGluZXMgPG86cD48 L286cD48L3A+DQogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuDQogICAgICAg ICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy DQogICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPnUzMg0KICAgICAgICAgIDwv c3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyDQogICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6IzAwNjZCQiI+PGENCmhyZWY9 Imh0dHBzOi8vZWxpeGlyLmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4xMi9pZGVudC90 Y3BfcmVub19zc3RocmVzaCINCiAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVl Ij48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRjRGNkZGIj50Y3BfcmVub19zc3RocmVz aDwvc3Bhbj48L2I+PC9hPjwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgTmV3 JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPig8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAg ICAgIE5ldyZxdW90Oztjb2xvcjojMDA4ODAwIj5zdHJ1Y3Q8L3NwYW4+PHNwYW4NCiAgICAg ICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXINCiAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjpibGFjayI+DQogICAgICAgICAgICA8 YQ0KICAgICAgICAgICAgICBocmVmPSJodHRwczovL2VsaXhpci5mcmVlLWVsZWN0cm9ucy5j b20vbGludXgvdjMuMTIvaWRlbnQvc29jayINCiAgICAgICAgICAgICAgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRjRGNkZGIj5zb2NrPC9z cGFuPjwvYj48L2E+DQogICAgICAgICAgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgIE5ldyZxdW90 Oztjb2xvcjojNjY2NjY2Ij4qPC9zcGFuPjxzcGFuDQogICAgICAgICAgICBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICBO ZXcmcXVvdDs7Y29sb3I6YmxhY2siPnNrPC9zcGFuPjxzcGFuDQogICAgICAgICAgICBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAg ICAgICBOZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+KTwvc3Bhbj48c3Bhbg0KICAgICAgICAg ICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0K ICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuDQogICAgICAgICAgICBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAg ICAgICAgICBOZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+ezwvc3Bhbj48c3Bhbg0KICAgICAg ICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmll cg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQogICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuDQogICAgICAgICAg ICBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQog ICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPsKgwqDCoMKgwqDCoMKgDQogICAg ICAgICAgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjojMDA4ODAwIj5j b25zdDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9y OmJsYWNrIj4NCiAgICAgICAgICA8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2Nv bG9yOiMwMDg4MDAiPnN0cnVjdDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiAgICAgICAgICAgIDxhDQogICAgICAgICAgICAg IGhyZWY9Imh0dHBzOi8vZWxpeGlyLmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4xMi9p ZGVudC90Y3Bfc29jayINCiAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48 Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRjRGNkZGIj50Y3Bfc29jazwvc3Bhbj48L2I+ PC9hPg0KICAgICAgICAgIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6 IzY2NjY2NiI+Kjwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj50cA0KICAgICAgICAgIDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICBOZXcm cXVvdDs7Y29sb3I6IzY2NjY2NiI+PTwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAg ICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiAgICAgICAgICAgIDxhDQogICAgICAgICAg ICAgIGhyZWY9Imh0dHBzOi8vZWxpeGlyLmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4x Mi9pZGVudC90Y3Bfc2siDQogICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ PGI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0Y0RjZGRiI+dGNwX3NrPC9zcGFuPjwvYj48 L2E+PC9zcGFuPjxzcGFuDQogICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6 IzY2NjY2NiI+KDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7 O2NvbG9yOmJsYWNrIj5zazwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgTmV3 JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPik7PC9zcGFuPjxzcGFuDQogICAgICAgICAgICBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAg ICAgICBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4NCiAgICAgICAgICAgIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAg IE5ldyZxdW90Oztjb2xvcjpibGFjayI+wqDCoMKgwqDCoMKgwqANCiAgICAgICAgICA8L3Nw YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOiMwMDg4MDAiPnJldHVybjwvc3Bh bj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4N CiAgICAgICAgICAgIDxhDQogICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vZWxpeGlyLmZy ZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4xMi9pZGVudC9tYXgiDQogICAgICAgICAgICAg IG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PGI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0Y0 RjZGRiI+bWF4PC9zcGFuPjwvYj48L2E+PC9zcGFuPjxzcGFuDQogICAgICAgICAgICBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAg ICAgICBOZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+KDwvc3Bhbj48c3Bhbg0KICAgICAgICAg ICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0K ICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj50cDwvc3Bhbj48c3Bhbg0KICAg ICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPi0mZ3Q7PC9zcGFu PjxzcGFuDQogICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPnNu ZF9jd25kDQogICAgICAgICAgPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgIE5ldyZxdW90Oztjb2xv cjojNjY2NjY2Ij4mZ3Q7Jmd0Ozwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAg TmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiAgICAgICAgICA8L3NwYW4+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAg ICAgTmV3JnF1b3Q7O2NvbG9yOiMwMDAwREQiPjFVPC9zcGFuPjxzcGFuDQogICAgICAgICAg ICBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQog ICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+LDwvc3Bhbj48c3Bhbg0KICAg ICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj4NCiAgICAgICAgICA8 L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q291cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOiMwMDAwREQiPjJVPC9zcGFu PjxzcGFuDQogICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+ KTs8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KICAgICAgICA8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3Bhbg0KICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2 NjYiPn08L3NwYW4+PHNwYW4NCiAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgIE5ldyZxdW90Oztjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wPg0KICAgICAgICA8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UbyBzb21ldGhpbmcgbGlrZTxvOnA+PC9vOnA+PC9wPg0KICAgICAgICA8cHJl PjxzcGFuIGNsYXNzPSJuIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnUzMjwvc3Bhbj48 L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gPC9zcGFuPjxzcGFuIGNsYXNzPSJu ZiI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDY2QkIiPjxhIGhyZWY9Imh0dHBzOi8vZWxpeGly LmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4xMi9pZGVudC90Y3BfcmVub19zc3RocmVz aCIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDoj RjRGNkZGIj50Y3BfPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRjRG NkZGIj5ibG9hdDwvc3Bhbj48L2I+PGI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0Y0RjZG RiI+X3NzdGhyZXNoPC9zcGFuPjwvYj48L2E+PC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0i cCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjY2NjYiPig8L3NwYW4+PC9zcGFuPjxzcGFuIGNs YXNzPSJrIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwODgwMCI+c3RydWN0PC9zcGFuPjwvc3Bh bj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiA8c3BhbiBjbGFzcz0ibiI+PGEgaHJlZj0i aHR0cHM6Ly9lbGl4aXIuZnJlZS1lbGVjdHJvbnMuY29tL2xpbnV4L3YzLjEyL2lkZW50L3Nv Y2siIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PGI+PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6 I0Y0RjZGRiI+c29jazwvc3Bhbj48L2I+PC9hPjwvc3Bhbj4gPC9zcGFuPjxzcGFuIGNsYXNz PSJvIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+Kjwvc3Bhbj48L3NwYW4+PHNwYW4g Y2xhc3M9Im4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c2s8L3NwYW4+PC9zcGFuPjxz cGFuIGNsYXNzPSJwIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+KTwvc3Bhbj48L3Nw YW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4N CiAgICAgICAgPHByZT48c3BhbiBjbGFzcz0icCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjY2 NjYiPns8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286 cD48L3NwYW4+PC9wcmU+DQogICAgICAgIDxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNr Ij7CoMKgwqDCoMKgwqDCoCA8L3NwYW4+PHNwYW4gY2xhc3M9ImsiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDA4ODAwIj5jb25zdDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4gPC9zcGFuPjxzcGFuIGNsYXNzPSJrIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwODgw MCI+c3RydWN0PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiA8c3Bh biBjbGFzcz0ibiI+PGEgaHJlZj0iaHR0cHM6Ly9lbGl4aXIuZnJlZS1lbGVjdHJvbnMuY29t L2xpbnV4L3YzLjEyL2lkZW50L3RjcF9zb2NrIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPjxi PjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNEY2RkYiPnRjcF9zb2NrPC9zcGFuPjwvYj48 L2E+PC9zcGFuPiA8L3NwYW4+PHNwYW4gY2xhc3M9Im8iPjxzcGFuIHN0eWxlPSJjb2xvcjoj NjY2NjY2Ij4qPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ibiI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj50cDwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4g PC9zcGFuPjxzcGFuIGNsYXNzPSJvIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+PTwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4gPHNwYW4gY2xhc3M9Im4i PjxhIGhyZWY9Imh0dHBzOi8vZWxpeGlyLmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4x Mi9pZGVudC90Y3Bfc2siIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PGI+PHNwYW4gc3R5bGU9 ImJhY2tncm91bmQ6I0Y0RjZGRiI+dGNwX3NrPC9zcGFuPjwvYj48L2E+PC9zcGFuPjwvc3Bh bj48c3BhbiBjbGFzcz0icCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjY2NjYiPig8L3NwYW4+ PC9zcGFuPjxzcGFuIGNsYXNzPSJuIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnNrPC9z cGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0icCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjY2NjYi Pik7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KICAgICAgICA8cHJlPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ wqDCoMKgwqDCoMKgwqAgPC9zcGFuPjxzcGFuIGNsYXNzPSJrIj48c3BhbiBzdHlsZT0iY29s b3I6IzAwODgwMCI+cmV0dXJuPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiA8c3BhbiBjbGFzcz0ibiI+dHA8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJvIj48 c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+LSZndDs8L3NwYW4+PC9zcGFuPjxzcGFuIGNs YXNzPSJuIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPnNuZF9jd25kPC9zcGFuPjwvc3Bh bj48c3BhbiBjbGFzcz0icCI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2NjY2NjYiPjs8L3NwYW4+ PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9w cmU+DQogICAgICAgIDxwcmU+PHNwYW4gY2xhc3M9InAiPjxzcGFuIHN0eWxlPSJjb2xvcjoj NjY2NjY2Ij59PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+ PC9vOnA+PC9zcGFuPjwvcHJlPg0KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5CdWls ZCBpdCBhbmQgbWFrZSBpdCBhIGxvYWRhYmxlIGtlcm5lbA0KICAgICAgICAgIG1vZHVsZSwg eW91IG5lZWQgdG8gcmVuYW1lIGEgZmV3IG90aGVyIGZ1bmN0aW9ucyBhcyB3ZWxsLCBhbmQN CiAgICAgICAgICB5b3UgY2FuIGNhbGwgaXQgdGNwX2Jsb2F0LmMNCiAgICAgICAgICA8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkNCiAgICAgICAgICAgIEVtb2pp JnF1b3Q7LHNhbnMtc2VyaWYiPvCfmIo8L3NwYW4+IDxvOnA+PC9vOnA+PC9wPg0KICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICA8cCBj bGFzcz0iTXNvTm9ybWFsIj5Tby4uIG15IG9waW5pb24gaXMgdGhhdCB5b3UgY2FuIHBlcmZl Y3RseQ0KICAgICAgICAgIHdlbGwgY29sbGFwc2UgdGhlIGludGVybmV0IGFsc28gd2l0aCBU Q1AuIENvbkV4IHdhcyBpbnRyb2R1Y2VkDQogICAgICAgICAgYXMgYSBtZWRpY2luZSBmb3Ig dGhpcyBidXQgaXQgbmV2ZXIgZ2FpbmVkIHRyYWN0aW9uLg0KICAgICAgICAgIDxvOnA+PC9v OnA+PC9wPg0KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9w Pg0KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4vSW5nZW1hcjxvOnA+PC9vOnA+PC9w Pg0KICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICA8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICA8ZGl2IHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtDQog ICAgICAgICAgMGNtIDBjbSA0LjBwdCI+DQogICAgICAgICAgPGRpdj4NCiAgICAgICAgICAg IDxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMQ0KICAg ICAgICAgICAgICAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCiAgICAgICAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEdvcnJ5IChlcmcpDQog ICAgICAgICAgICAgICAgWzxhIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiIGhyZWY9 Im1haWx0bzpnb3JyeUBlcmcuYWJkbi5hYy51ayI+bWFpbHRvOmdvcnJ5QGVyZy5hYmRuLmFj LnVrPC9hPl0gPGJyPg0KICAgICAgICAgICAgICAgIDxiPlNlbnQ6PC9iPiBkZW4gMjcgbm92 ZW1iZXIgMjAxNyAxNDoxNTxicj4NCiAgICAgICAgICAgICAgICA8Yj5Ubzo8L2I+IFJvbGFu ZCBaaW5rIDxhIGNsYXNzPSJtb3otdHh0LWxpbmstcmZjMjM5NkUiIGhyZWY9Im1haWx0bzpy b2xhbmRAemlua3MuZGUiPiZsdDtyb2xhbmRAemlua3MuZGUmZ3Q7PC9hPjxicj4NCiAgICAg ICAgICAgICAgICA8Yj5DYzo8L2I+IDxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0 ZWQiIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPjxicj4N CiAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gUmU6IFNwaW4gYml0IGRpc2N1c3Np b24gLSB3aGVyZSB3ZSdyZSBhdDxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgPC9kaXY+ DQogICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD7CoDwvbzpwPjwvcD4NCiAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U2VlIGJlbG93OjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgIDwvZGl2 Pg0KICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCiAgICAgICAgICAgICAgT24gMjcg Tm92IDIwMTcsIGF0IDEyOjMyLCBSb2xhbmQgWmluayAmbHQ7PGENCiAgICAgICAgICAgICAg ICBocmVmPSJtYWlsdG86cm9sYW5kQHppbmtzLmRlIiBtb3otZG8tbm90LXNlbmQ9InRydWUi PnJvbGFuZEB6aW5rcy5kZTwvYT4mZ3Q7DQogICAgICAgICAgICAgIHdyb3RlOjxvOnA+PC9v OnA+PC9wPg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDxibG9ja3F1b3RlIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KICAgICAgICAgICAg PGRpdj4NCiAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICA8cCBjbGFzcz0i TXNvTm9ybWFsIj5BbSAyNy4xMS4yMDE3IHVtIDA4OjAzIHNjaHJpZWIgSmFuYQ0KICAgICAg ICAgICAgICAgICAgSXllbmdhcjo8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPC9k aXY+DQogICAgICAgICAgICAgIDxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhZGRpdGlvbiB0byBob3cgdGhl IHNwaW4gYml0DQogICAgICAgICAgICAgICAgICAgIGNhbiBiZSBkZXNpZ25lZCBhbmQgdXNl ZCwgSSdkIGxpa2UgdGhvc2UgdGFraW5nIG9uDQogICAgICAgICAgICAgICAgICAgIHRoaXMg ZWZmb3J0IHRvIGNvbnNpZGVyIHRoaXMgcXVlc3Rpb246IFdoYXRldmVyDQogICAgICAgICAg ICAgICAgICAgIG5ldHdvcmsgbWFuYWdlbWVudCBwcm9ibGVtIHlvdSdyZSBjb25zaWRlcmlu Zw0KICAgICAgICAgICAgICAgICAgICBzb2x2aW5nIHdpdGggYSBiaXQsIHdoYXQgZG9lcyBp dCB0YWtlIHRvIHNvbHZlIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgcHJvYmxlbSB3aXRo b3V0IHRoZSBiaXQgZXhwb3NlZD8gSSdtIGFza2luZyB5b3UgdG8NCiAgICAgICAgICAgICAg ICAgICAgY29uc2lkZXIgInplcm8tYml0IiBzb2x1dGlvbnMsIG9yIGF0IGxlYXN0IGZvciBh DQogICAgICAgICAgICAgICAgICAgIGNvc3QvYmVuZWZpdCBhbmFseXNpcyBvZiBkZXZlbG9w aW5nIHNvbHV0aW9ucyB3aXRoDQogICAgICAgICAgICAgICAgICAgIGFuZCB3aXRob3V0IHRo ZSBzcGluIGJpdCBmb3Igc3BlY2lmaWMgbmV0d29yaw0KICAgICAgICAgICAgICAgICAgICBt YW5hZ2VtZW50IGZ1bmN0aW9ucy4gU3BlY2lmaWNhbGx5LA0KICAgICAgICAgICAgICAgICAg ICA8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+wqA8L286cD48L3A+DQogICAg ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAg ICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPihpKSBXaGF0J3MgaW1wb3NzaWJs ZSBvciB2ZXJ5DQogICAgICAgICAgICAgICAgICAgICAgZGlmZmljdWx0IHRvIGRvLCBmcm9t IGEgbmV0d29yayBtYW5hZ2VtZW50DQogICAgICAgICAgICAgICAgICAgICAgcGVyc3BlY3Rp dmUsIG9mIG5vdCBoYXZpbmcgdGhlIHNwaW4gYml0PyBOb3RlIHRoYXQNCiAgICAgICAgICAg ICAgICAgICAgICBJJ20gbm90IGFza2luZyBmb3Igd2hhdCBpcyBhbmQgaXMgbm90IG1lYXN1 cmFibGUNCiAgICAgICAgICAgICAgICAgICAgICAtLSBub3QgZXZlcnl0aGluZyBtZWFzdXJh YmxlIGlzIHVzZWZ1bC4gSSdtDQogICAgICAgICAgICAgICAgICAgICAgc3BlY2lmaWNhbGx5 IGFza2luZyBpbiB0ZXJtcyBvZiBuZXR3b3JrIG1hbmFnZW1lbnQNCiAgICAgICAgICAgICAg ICAgICAgICBmdW5jdGlvbnMsIGluIHByYWN0aWNlLCBhcyB1c2VkIGJ5IG9wZXJhdG9ycy4g U29tZQ0KICAgICAgICAgICAgICAgICAgICAgIG9mIHRoaXMgaGFzIGJlZW4gYWRkcmVzc2Vk IGluIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgIGRpc2N1c3Npb25zL2RyYWZ0cyBJJ3Zl IHNlZW4sIGJ1dCBJIHRoaW5rIGl0J3MNCiAgICAgICAgICAgICAgICAgICAgICBtb3N0IHVz ZWZ1bCB3aGVuIGZyYW1lZCBpbiB0ZXJtcyBvZiBuZXR3b3JrDQogICAgICAgICAgICAgICAg ICAgICAgbWFuYWdlbWVudCBmdW5jdGlvbnMuPG86cD48L286cD48L3A+DQogICAgICAgICAg ICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg PC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPkkgd2FudA0KICAgICAgICAgICAgICAgIHRvIGV4 cHJlc3MgdGhlIHF1ZXN0aW9uIGFib3V0IG1hbmFnZWFiaWxpdHkgZnJvbSBhDQogICAgICAg ICAgICAgICAgZGlmZmVyZW50IGFuZ2xlLiBRVUlDIG1vdmVzIHRoZSBjb25nZXN0aW9uIGNv bnRyb2wgZnJvbQ0KICAgICAgICAgICAgICAgIGJlaW5nIGEgY29tbW9uIGZ1bmN0aW9uYWxp dHkgaW4gdGhlIGtlcm5lbCB0bw0KICAgICAgICAgICAgICAgIGFwcGxpY2F0aW9uIGZ1bmN0 aW9uYWxpdHkuIEl0IGFsc28gaGlkZXMgdGhlIHByb3RvY29sDQogICAgICAgICAgICAgICAg aGFuZGxpbmcgb2YgY29uZ2VzdGlvbiBmcm9tIHRoZSBuZXR3b3JrLiBUaGlzIGdpdmVzDQog ICAgICAgICAgICAgICAgaW5jZW50aXZlcyBmb3IgYXBwbGljYXRpb24gZGV2ZWxvcGVycyB0 byBjaGFuZ2UNCiAgICAgICAgICAgICAgICBjb25nZXN0aW9uIGNvbnRyb2wgdG8gZ2l2ZSB0 aGVpciBhcHBsaWNhdGlvbiBhbg0KICAgICAgICAgICAgICAgIGFkdmFudGFnZSBvdmVyIG90 aGVycy4gTm8gc3BlY2lhbCByaWdodHMgYXJlIG5lY2Vzc2FyeS4NCiAgICAgICAgICAgICAg ICBOb3cgdGhlIHF1ZXN0aW9uIGlzIGRvZXMgUVVJQyBwcm92aWRlIGVub3VnaA0KICAgICAg ICAgICAgICAgIG1hbmFnZWFiaWxpdHkgdG8gYXZvaWQgYW4gSW50ZXJuZXQgKG9yIHNvbWUg cGFydCBvZiBpdCkNCiAgICAgICAgICAgICAgICBicmVha2Rvd24gd2hlbiBpdCBpcyBtaXN1 c2VkPyBDYW4gaXQgYmUgc2hvd24gdGhhdCB0aGlzDQogICAgICAgICAgICAgICAgY2FuJ3Qg aGFwcGVuPzxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg PC9ibG9ja3F1b3RlPg0KICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsg dGhpcyBtYXkgdG91Y2ggb24gc29tZSBvZiB0aGUNCiAgICAgICAgICAgIHRvcGljcyBpbjo8 bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGENCmhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1mYWlyaHVyc3QtdHN2d2ctdHJhbnNwb3J0LWVuY3J5cHQtMDQiDQogICAgICAgICAgICAg ICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZmFpcmh1cnN0LXRzdndnLXRyYW5zcG9ydC1lbmNyeXB0LTA0PC9hPjxvOnA+PC9v OnA+PC9wPg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDxkaXY+DQogICAgICAgICAg ICA8ZGl2Pg0KICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9v OnA+PC9wPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8ZGl2Pg0KICAgICAg ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHRob3VnaCB0aGlzIGlzIGZvY3Vzc2Vk IG9uIGlzc3Vlcw0KICAgICAgICAgICAgICAgIHdpZGVyIHRoYW4gUXVpYywgSSB0aGluayB0 aGUgcG9pbnRzIHlvdSByYWlzZSBhcmUNCiAgICAgICAgICAgICAgICByZWxldmFudC4gVGhp cyB3YXMgcHJlc2VudGVkIGxhc3QgSUVURi0xMDAgaW4gVFNWV0cgYW5kDQogICAgICAgICAg ICAgICAgSU5UQVJFQS4gV2Ugd291bGQgYXBwcmVjaWF0ZSBpbnNpZ2h0LCBhbmQgY29tbWVu dHMgb24NCiAgICAgICAgICAgICAgICB0aGlzLiDCoChJIGFtIGp1c3QgYWJvdXQgdG8gcHVz aCBuZXcgdmVyc2lvbiB0byBjb3JyZWN0DQogICAgICAgICAgICAgICAgdHlwb3MhKTxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICA8ZGl2Pg0KICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQogICAgICAgICAgICAgICAg PGJyPg0KICAgICAgICAgICAgICAgIDxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICA8 YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCiAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgPGJsb2NrcXVv dGUNCiAgICAgICAgICAgICAgICAgICAgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2lu LWJvdHRvbTo1LjBwdCI+DQogICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAg ICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPihpaSkgV2hhdCBhcmUgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAg IGFsdGVybmF0aXZlcyBmb3IgYnVpbGRpbmcgdGhlIHNhbWUgZnVuY3Rpb25zDQogICAgICAg ICAgICAgICAgICAgICAgICAgIHdpdGhvdXQgdGhlIHNwaW4gYml0PyBMZXQncyBjb25zaWRl ciBmb3IgYQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBtb21lbnQgdGhhdCB0aGUgc3Bp biBiaXQgaXNuJ3QgYWN0dWFsbHkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgYXZhaWxh YmxlIGluIHByYWN0aWNlLiBXaGF0IHdpbGwgb3BlcmF0b3JzIGRvDQogICAgICAgICAgICAg ICAgICAgICAgICAgIHRvIGNvbnRpbnVlIG1hbmFnaW5nIHRoZWlyIG5ldHdvcmtzPyBUaGlz DQogICAgICAgICAgICAgICAgICAgICAgICAgIG1pZ2h0IGJlIGV4cGVuc2l2ZSwgYnV0IHRo YXQncyBwcmVjaXNlbHkgd2hhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICBJJ20gbG9v a2luZyBmb3IgLS0gdGhlIGNvc3QgdG8gb3BlcmF0b3JzIG9mDQogICAgICAgICAgICAgICAg ICAgICAgICAgIG5vdCBoYXZpbmcgdGhlIHNwaW4gYml0LiBGb3IgaW5zdGFuY2UsIGFjdGl2 ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICBwcm9iZXMgYXJlIGEgZmluZSB3YXkgdG8g bWVhc3VyZSBuZXR3b3JrIFJUVA0KICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoaW4g b3BlcmF0b3IgbmV0d29ya3MsIGFuZCB0aGF0IGlzIGFuDQogICAgICAgICAgICAgICAgICAg ICAgICAgIGFsdGVybmF0aXZlLiBUaGVyZSBhcmUgc3VyZWx5IG90aGVycyB0b28uDQogICAg ICAgICAgICAgICAgICAgICAgICAgIFRoZWlyIGNvc3RzIGFuZCBsaW1pdGF0aW9ucyBhcmUg aW1wb3J0YW50IHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgIGtub3cgYWJvdXQgaW4g b3JkZXIgdG8gcmVhc29uIGFib3V0IHRoZWlyDQogICAgICAgICAgICAgICAgICAgICAgICAg IHZpYWJpbGl0eSwgc28gSSdkIGxpa2UgdG8gc2VlIGFsdGVybmF0aXZlcw0KICAgICAgICAg ICAgICAgICAgICAgICAgICBjb25zaWRlcmVkLjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAg ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAgICAgICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+U29sdXRpb25zDQog ICAgICAgICAgICAgICAgICAgIHRoYXQgb25seSB3b3JrIHdpdGhpbiBhbiBvcGVyYXRvcnMg bmV0d29yayBhcmUgbm90DQogICAgICAgICAgICAgICAgICAgIGVub3VnaCB3aGVuIG1vcmUg dGhhbiBvbmUgb3BlcmF0b3IgaXMgaW52b2x2ZWQuPG86cD48L286cD48L3A+DQogICAgICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBhbHNvIHRydWUuPG86cD48L286cD48 L3A+DQogICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAg ICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+wqA8L286cD48L3A+DQogICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPkdvcnJ5PGJyPg0KICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAg ICAgICA8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQogICAgICAgICAgICAg ICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlDQogICAgICAgICAgICAg ICAgICAgIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K ICAgICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKg PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGRvbid0IG1lYW4gdG8gc3RhcnQgdGhlDQogICAgICAgICAgICAgICAgICAg ICAgICAgIGRpc2N1c3Npb24gb24gdGhpcyB0aHJlYWQsIGJ1dCBJJ2QgbGlrZSB0bw0KICAg ICAgICAgICAgICAgICAgICAgICAgICB1cmdlIHRob3NlIGdvaW5nIG9mZiB0byBkbyB0aGUg d3JpdGluZyB0bw0KICAgICAgICAgICAgICAgICAgICAgICAgICBjb25zaWRlciB0aGVzZSBx dWVzdGlvbnMuPG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgICAgPC9kaXY+ DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAg IDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+wqA8L286cD48L3A+DQogICAgICAgICAgICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gamFuYTxvOnA+PC9vOnA+ PC9wPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAg ICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+ PC9wPg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE5vdiAyNiwgMjAxNyBhdA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAxMToyNiBBTSwgTU9SVE9OLCBBTEZSRUQgQyAoQUwp ICZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzphY21v cnRvbkBhdHQuY29tIg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRhcmdldD0iX2Js YW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmFjbW9ydG9uQGF0dC5jb208L2E+Jmd0Ow0K ICAgICAgICAgICAgICAgICAgICAgICAgICB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCiAgICAg ICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZA0KICAgICAgICAgICAgICAgICAgICAgICAgICAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGNtIDBjbSAwY20NCiAgICAgICAgICAgICAgICAgICAgICAgICAgNi4wcHQ7 bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBjbSI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5IaSBCcmlhbiwNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBTdGVwaGVuLCBMYXJzLCBNYXJrIGFuZCBhbGwsPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICBvbmUgam9pbiwgb25lIHN1Z2dlc3Rpb24sIGFuZCBvbmUgcXVlc3Rpb24NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBiZWxvdy48YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgc2VlIFtBQ01dPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgJmd0OyBGcm9tOiBRVUlDIFttYWlsdG86PGENCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPnF1 aWMtYm91bmNlc0BpZXRmLm9yZzwvYT5dDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg T24gQmVoYWxmIE9mIEJyaWFuIFRyYW1tZWxsPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZndDsgKElFVEYpPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn dDsgU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyMiwgMjAxNyA1OjU5DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgQU08YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmd0OyBUbzogRWdnZXJ0LCBMYXJzPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZndDsgQ2M6IE1hcmsgTm90dGluZ2hhbTsgUVVJQyBXRzsgU3RlcGhlbg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIEZhcnJlbGw8YnI+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyBTdWJqZWN0OiBSZTogU3BpbiBiaXQgZGlzY3Vzc2lvbiAtDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgd2hlcmUgd2UncmUgYXQ8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAm Z3Q7IGhpIExhcnMsPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDs8YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyAmZ3Q7IE9uIDIyIE5vdiAyMDE3 LCBhdCAxMTozNSwgRWdnZXJ0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIExhcnMg Jmx0OzxhIGhyZWY9Im1haWx0bzpsYXJzQG5ldGFwcC5jb20iDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmxhcnNAbmV0YXBwLmNvbTwv YT4mZ3Q7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgd3JvdGU6PGJyPg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICZndDsgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7ICZndDsgSGksPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZndDsgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7ICZn dDsgT24gMjAxNy0xMS0yMiwgYXQgMTE6MDEsIFN0ZXBoZW4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICBGYXJyZWxsICZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgaHJlZj0ibWFpbHRvOnN0ZXBoZW4uZmFycmVsbEBjcy50Y2QuaWUiDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPnN0ZXBoZW4uZmFy cmVsbEBjcy50Y2QuaWU8L2E+Jmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAmZ3Q7IHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7ICZn dDsmZ3Q7IFdoYXQgSSB0aG91Z2h0IHdhcyBiZWluZw0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHJlcXVlc3RlZCBhbmQgd2hhdCBJIGRvIHRoaW5rIGlzIHJlYXNvbmFibGU8YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyAmZ3Q7Jmd0OyBpcyB0byBkb2N1 bWVudCBhIHByaXZhY3kNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbmFseXNpcyBm b3IgYW55IHF1aWMgcHJvdG9jb2wgYml0cyB0aGF0IGFyZTxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAmZ3Q7ICZndDsmZ3Q7IHZpc2libGUgdG8gdGhlIHBhdGguIFdoZXRo ZXINCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBvciBub3Qgc29tZSBvciBhbGwgb2Yg dGhhdCB0ZXh0IGVuZHMgdXA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0 OyAmZ3Q7Jmd0OyBpbiBzb21lIFJGQyBpcyBhbm90aGVyIGRheSdzDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgd29yay48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg Jmd0OyAmZ3Q7IExhcnMgd3JvdGU6PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZndDsgJmd0OyBmb3IgdGhlIFNwaW4gQml0IHNwZWNpZmljYWxseSwgdGhlDQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgaW50ZW50IHdhcyB0byBwZXJtYW5lbnRseSBjYXB0dXJl PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgdGhlIGFuYWx5c2lzIHRo ZSBEVCBoYXMgZG9uZSwgc28gdGhhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdo ZW4gb3RoZXJzIHJldmlldyB0aGUgcHJvcG9zZWQ8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgJmd0OyBTcGluIEJpdCBzcGVjaWZpY2F0aW9uLCB0aGV5IGNhbiB0YWtlDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhhdCBhcyBhIGdpdmVuIGFuZCBkaXJlY3Qg YW55PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgZnVydGhlciBhbmFs eXNpcyB0byBvdGhlciBhc3BlY3RzLiBJdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IG1hZGUgc2Vuc2UgdG8gdGhlIGNoYWlycyB0aGF0IHRoYXQ8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyBzcGVjaWZpYyBhbmFseXNpcyBzaG91bGQgYmVjb21lIHBh cnQgb2YNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGUgU3BpbiBCaXQgc3BlY2lm aWNhdGlvbi4gSTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IHRoaW5r IHdlJ2QgYmUgb3BlbiB0byBhIGRpc2N1c3Npb24gb24NCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICB3aGV0aGVyIGEgYnJvYWRlciBkb2N1bWVudDxicj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAmZ3Q7IGFuYWx5emluZyB0aGUgUVVJQyB3aXJlIGltYWdlIHdvdWxk IGJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgYSBiZXR0ZXIgaG9tZSBmb3IgdGhp cy4gVGhlIG1haW48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBwb2lu dCBpcyBmb3IgdGhlIHdvcmsgdGhhdCB0aGUgRFQgaGFzDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgZG9uZSB0byBiZSBkb2N1bWVudGVkLjxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBCcmlh biB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBPa2F5LiBU aGF0J3Mgc29tZXdoYXQgbW9yZSByZWFzb25hYmxlDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgdGhhbiB3aGF0IEkgcmVhZCB0aGUgYXNrIHRvIGJlPGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZndDsgKCJ3ZSdyZSBnb2luZyB0byBnYXRlIHRoaXMgb24gdGhl DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVvcGxlIHdobyBjYXJlIGFib3V0IHRo aXMgZG9pbmcgc29tZTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IG5v bi10cml2aWFsIGFtb3VudCBvZiB3b3JrIikuIFRob3NlIG9mDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgdXMgd2hvIHZvbHVudGVlciAoaGVscCwgcGxlYXNlLDxicj4NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IGFueW9uZT8gOikgKSBjYW4gY2VydGFpbmx5 IHB1bGwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB0b2dldGhlciB3aGF0IHdlIGhh dmUgaW4gYSBzaW5nbGUgSS1EPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn dDsgYW5kIGFzayB0aGUgV0cgd2hhdCBtb3JlIGl0IHRoaW5rcyBpdA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG5lZWRzLiBUbyBtZSBhbGwgdGhpcyBzZWVtcyBwcmV0dHk8YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBjbGVhciwgYnV0IEkndmUgYmVl biB3b3JraW5nIG9uIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB0b3BpYyBm b3IgYSB3aGlsZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgW0FDTV08YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgSGF2aW5nIHJlYWNoZWQgdGhlIGVuZCBv ZiB0aGUgIlRoYW5rc2dpdmluZw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRocmVh ZCIsPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIEknbSBzY3JvbGxpbmcgYmFj ayBhIGZldyBwYWdlcyB0byBqb2luIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IHRhc2sgb2Y8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgcGVybWFuZW50bHkg Y2FwdHVyaW5nIHRoZSB3b3JrIG9mIHRoZSBEVCBpbg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGFuIEktRCAoYXQgbGVhc3QpOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICBUaGVyZSBzaG91bGQgYmUgbGFzdGluZyB2YWx1ZSBpbiBzb21lIG9mIG91cg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIGZpbmRpbmdzPGJyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFuZCBJTU8gdGhleSBhcmUgd29ydGh5IG9mIGEgcGVyc2lzdGVudA0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlZmVyZW5jZS48YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICZn dDsgTGFycyB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyAm Z3Q7IEZvciBwcm9wb3NhbHMgb3RoZXIgdGhhbiB0aGUgU3Bpbg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgIEJpdCAoSSB0aGluayBJIGhhdmUgc2VlbiBpbmRpdmlkdWFsPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgY29udHJpYnV0b3JzIGF0IGxlYXN0 IG1lbnRpb24gImxvc3MiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5kICJjb25n ZXN0aW9uIiBiaXRzLCBidXQgd2l0aG91dDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAmZ3Q7IG11Y2ggZGV0YWlsKSwgd2Ugd2FudGVkIHRvIGNsYXJpZnkgdGhhdA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHdlJ2QgbGlrZSB0byBzZWUgYW4gYW5hbHlzaXMg YW5kPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgZGlzY3Vzc2lvbiBv ZiB0aGVpciBwcml2YWN5IGFzcGVjdHMgdG8NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICByb3VnaGx5IHRoZSBzYW1lIGRlZ3JlZSBhcyB0aGUgRFQ8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyBoYXMgcGVyZm9ybWVkIGZvciB0aGUgU3BpbiBCaXQNCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICBwcm9wb3NhbC48YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBb QUNNXTxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBJIHN1Z2dlc3QgdGhhdCB0 aGlzIG1pZ2h0IGJlIGEgZGlmZmVyZW50DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg SS1ELCBhdCBsZWFzdCB0byBzdGFydC48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgUXVlc3Rpb246IElzIHRoZXJlIGEgcHJpdmFjeSBhbmFseXNpcyBvZg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHByZXNlbnQgRUNOIGF2YWlsYWJsZT88YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgKGEgc2VhcmNoIHlpZWxkZWQgbWFueSByZXN1bHRzIHdp dGggTWlzc2luZzoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBwcml2YWN5KTxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgcmVnYXJkcyw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgQWw8 bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4N CiAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICA8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICAgICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAgICAg ICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+wqA8L286cD48L3A+DQogICAg ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgIDwvYmxvY2txdW90ZT4NCiAgICAg ICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiAgICAg IDwvZGl2Pg0KICAgIDwvYmxvY2txdW90ZT4NCiAgICA8YnI+DQogIDwvYm9keT4NCjwvaHRt bD4NCg== --------------12F2CC8FA2A9C19B1A03D95C-- From nobody Mon Nov 27 08:38: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 4D77D128B91 for ; Mon, 27 Nov 2017 08:38:38 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 WozdP6_4NmNe for ; Mon, 27 Nov 2017 08:38:34 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 127A512420B for ; Mon, 27 Nov 2017 08:38:34 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eJMQC-0005gn-J6 for quic@ietf.org; Mon, 27 Nov 2017 17:38:30 +0100 Received: from [10.5.2.17] (helo=xmail07.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eJMQ3-0002Op-9c for quic@ietf.org; Mon, 27 Nov 2017 11:38:12 -0500 Received: (qmail 6863 invoked from network); 27 Nov 2017 16:38:04 -0000 Received: from unknown (HELO [192.168.1.100]) (Authenticated-user:_huitema@huitema.net@[172.56.42.196]) (envelope-sender ) by xmail07.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Nov 2017 16:38:02 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-736F4616-9EF3-493D-B58F-956006561518 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (15B202) In-Reply-To: <74e1c7bd-bd09-3285-db25-db04fe530cbc@zinks.de> Date: Mon, 27 Nov 2017 08:38:00 -0800 Cc: Ingemar Johansson S , "Gorry (erg)" , "quic@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <34BF55EB-8B3E-453C-BAFE-8048B4B94FC5@huitema.net> References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@erg.abdn.ac.uk> <74e1c7bd-bd09-3285-db25-db04fe530cbc@zinks.de> To: Roland Zink Subject: Re: Spin bit discussion - where we're at X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.13) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5vxFBG2yeVEfkqYr4r+sm6kXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fs2/PgQ5qadbqb0NXJcXynvB98yDTitFWvbHwz9vKZpm2Ea bzmM/1VynIZUVImbQiuZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyYW9UNFgzCqKDXesOntN1zD9IUJ5y4fZBwzmfWaECTh P19fvxYARRgJi47cNeeqpyHGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kAN1Mi/5oPXF0IaYXV2I96ukONoJfh+XjGSeeT90H/uIHh ef/StaT8acR/REMAVMDZU7m1espHlaRNKU4/KGGP6WbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW87eqULwgkV+w1Dqc0gmbgvfFcHV2tQAVqGdj/zM7G/FqHXIoSsvffuCdDqwWbJR15ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 16:38:38 -0000 --Apple-Mail-736F4616-9EF3-493D-B58F-956006561518 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable The network cannot control the congestion algorithm in the end points. QUIC d= oes not create the problem, just makes it crystal clear. But the network can= manage queues. So does the kernel. -- Christian Huitema=20 > On Nov 27, 2017, at 6:47 AM, Roland Zink wrote: >=20 > I guess the guys which really want to do it will somehow get the necessary= rights (like to load a kernel module) and do it although this may be diffic= ult if you want to do it on million of devices. I'm more thinking of a slow p= rocess, say app 1 increase the initial window then app 2 thinks it nee= ds to do the same and back out less than the default. Then app 1 is doing so= mething and at some point nobody follows what is (will be) in the RFC. They n= ot necessarily want to break something but at the end it can result into the= same. It is no longer a single policy which applies to all apps instead eac= h app comes with its own and the apps often can control both sides. >=20 > Roland >=20 >=20 >> Am 27.11.2017 um 15:14 schrieb Ingemar Johansson S: >> Hi >> =20 >> I would say that it is perfectly possible to trick e.g. the Linux TCP sta= ck to something like what is described below. Just clone tcp_cong.c , >> Change the following lines >> u32 tcp_reno_ssthresh(struct sock *sk) >> { >> const struct tcp_sock *tp =3D tcp_sk(sk); >> return max(tp->snd_cwnd >> 1U, 2U); >> } >> To something like >> u32 tcp_bloat_ssthresh(struct sock *sk) >> { >> const struct tcp_sock *tp =3D tcp_sk(sk); >> return tp->snd_cwnd; >> } >> Build it and make it a loadable kernel module, you need to rename a few o= ther functions as well, and you can call it tcp_bloat.c =F0=9F=98=8A >> =20 >> So.. my opinion is that you can perfectly well collapse the internet also= with TCP. ConEx was introduced as a medicine for this but it never gained t= raction. >> =20 >> /Ingemar >> =20 >> =20 >> =20 >> =20 >> From: Gorry (erg) [mailto:gorry@erg.abdn.ac.uk]=20 >> Sent: den 27 november 2017 14:15 >> To: Roland Zink >> Cc: quic@ietf.org >> Subject: Re: Spin bit discussion - where we're at >> =20 >> See below: >>=20 >> On 27 Nov 2017, at 12:32, Roland Zink wrote: >>=20 >> Am 27.11.2017 um 08:03 schrieb Jana Iyengar: >> In addition to how the spin bit can be designed and used, I'd like those t= aking on this effort to consider this question: Whatever network management p= roblem you're considering solving with a bit, what does it take to solve thi= s problem without the bit exposed? I'm asking you to consider "zero-bit" sol= utions, or at least for a cost/benefit analysis of developing solutions with= and without the spin bit for specific network management functions. Specifi= cally, >> =20 >> (i) What's impossible or very difficult to do, from a network management p= erspective, of not having the spin bit? Note that I'm not asking for what is= and is not measurable -- not everything measurable is useful. I'm specifica= lly asking in terms of network management functions, in practice, as used by= operators. Some of this has been addressed in the discussions/drafts I've s= een, but I think it's most useful when framed in terms of network management= functions. >> I want to express the question about manageability from a different angle= . QUIC moves the congestion control from being a common functionality in the= kernel to application functionality. It also hides the protocol handling of= congestion from the network. This gives incentives for application develope= rs to change congestion control to give their application an advantage over o= thers. No special rights are necessary. Now the question is does QUIC provid= e enough manageability to avoid an Internet (or some part of it) breakdown w= hen it is misused? Can it be shown that this can't happen? >>=20 >> I think this may touch on some of the topics in: >> https://tools.ietf.org/html/draft-fairhurst-tsvwg-transport-encrypt-04 >> =20 >> Although this is focussed on issues wider than Quic, I think the points y= ou raise are relevant. This was presented last IETF-100 in TSVWG and INTAREA= . We would appreciate insight, and comments on this. (I am just about to pu= sh new version to correct typos!) >>=20 >>=20 >> (ii) What are the alternatives for building the same functions without th= e spin bit? Let's consider for a moment that the spin bit isn't actually ava= ilable in practice. What will operators do to continue managing their networ= ks? This might be expensive, but that's precisely what I'm looking for -- th= e cost to operators of not having the spin bit. For instance, active probes a= re a fine way to measure network RTT within operator networks, and that is a= n alternative. There are surely others too. Their costs and limitations are i= mportant to know about in order to reason about their viability, so I'd like= to see alternatives considered. >> Solutions that only work within an operators network are not enough when m= ore than one operator is involved. >>=20 >> Yes, also true. >> =20 >> Gorry >>=20 >> =20 >> I don't mean to start the discussion on this thread, but I'd like to urge= those going off to do the writing to consider these questions. >> =20 >> - jana >> =20 >> =20 >> On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) wrote: >> Hi Brian, Stephen, Lars, Mark and all, >>=20 >> one join, one suggestion, and one question below. >> see [ACM] >> > -----Original Message----- >> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell >> > (IETF) >> > Sent: Wednesday, November 22, 2017 5:59 AM >> > To: Eggert, Lars >> > Cc: Mark Nottingham; QUIC WG; Stephen Farrell >> > Subject: Re: Spin bit discussion - where we're at >> > >> > hi Lars, >> > >> > > On 22 Nov 2017, at 11:35, Eggert, Lars wrote: >> > > >> > > Hi, >> > > >> > > On 2017-11-22, at 11:01, Stephen Farrell <= stephen.farrell@cs.tcd.ie> >> > wrote: >> > >> What I thought was being requested and what I do think is reasonable= >> > >> is to document a privacy analysis for any quic protocol bits that ar= e >> > >> visible to the path. Whether or not some or all of that text ends up= >> > >> in some RFC is another day's work. >> > > Lars wrote: >> > > for the Spin Bit specifically, the intent was to permanently capture >> > the analysis the DT has done, so that when others review the proposed >> > Spin Bit specification, they can take that a= s a given and direct any >> > further analysis to other aspects. It made sense to the chairs that tha= t >> > specific analysis should become part of the Spin Bit specification. I >> > think we'd be open to a discussion on whether a broader document >> > analyzing the QUIC wire image would be a better home for this. The main= >> > point is for the work that the DT has done t= o be documented. >>=20 >> > Brian wrote: >> > Okay. That's somewhat more reasonable than what I read the ask to be >> > ("we're going to gate this on the people who care about this doing some= >> > non-trivial amount of work"). Those of us who volunteer (help, please, >> > anyone? :) ) can certainly pull together what we have in a single I-D >> > and ask the WG what more it thinks it needs. To me all this seems prett= y >> > clear, but I've been working on this topic for a while. >> [ACM] >> Having reached the end of the "Thanksgiving thread", >> I'm scrolling back a few pages to join the task of >> permanently capturing the work of the DT in an I-D (at least): >> There should be lasting value in some of our findings >> and IMO they are worthy of a persistent reference. >>=20 >> > Lars wrote: >> > > For proposals other than the Spin Bit (I think I have seen individual= >> > contributors at least mention "loss" and "congestion" bits, but without= >> > much detail), we wanted to clarify that we'd like to see an analysis an= d >> > discussion of their privacy aspects to roughly the same degree as the D= T >> > has performed for the Spin Bit proposal. >> > >> [ACM] >> I suggest that this might be a different I-D,= at least to start. >> Question: Is there a privacy analysis of present ECN available? >> (a search yielded many results with Missing: privacy) >>=20 >> regards, >> Al >>=20 >> =20 >> =20 >=20 --Apple-Mail-736F4616-9EF3-493D-B58F-956006561518 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable The network cannot control the congestion a= lgorithm in the end points. QUIC does not create the problem, just makes it c= rystal clear. But the network can manage queues. So does the kernel.

=
-- Christian Huitema 

On N= ov 27, 2017, at 6:47 AM, Roland Zink <= roland@zinks.de> wrote:

=20 =20 =20

I guess the guys which really want to do it will somehow get the necessary rights (like to load a kernel module) and do it although this may be difficult if you want to do it on million of devices. I'm more thinking of a slow process, say app 1 increase the initial window then app 2 thinks it needs to do the same and back out less than the default. Then app 1 is doing something and at some point nobody follows what is (will be) in the RFC. They not necessarily want to break something but at the end it can result into the same. It is no longer a single policy which applies to all apps instead each app comes with its own and the apps often can control both sides.


Roland



Am 27.11.2017 um 15:14 schrieb Ingemar Johansson S:

Hi

 

I would say that it is perfectly possible to trick e.g. the Linux TCP stack to something like what is described below. Just clone tcp_cong.c ,

Change the following lines

u32 tcp_reno_ssthresh(struct sock *sk)

{

       = ; const struct tcp_= sock *tp =3D tcp_sk= (sk);

       = ; return max(tp->snd_cwnd >> 1U, 2U);

}

To something like

u32=
 tcp_bloat_ssthresh(=
struct sock *sk)
{=

      =
;  const<=
/span> struct tcp_sock *<=
/span>tp<=
span style=3D"color:black"> =3D tcp_sk(<=
span class=3D"n">sk);
      =
;  return=
 tp->snd_cwnd;
}=

Build it and make it a loadable kernel module, you need to rename a few other functions as well, and you can call it tcp_bloat.c =F0=9F=98=8A

 

So.. my opinion is that you can perfectly well collapse the internet also with TCP. ConEx was introduced as a medicine for this but it never gained traction.

 

/Ingemar

 

 

 

 

From: Gorry (erg) [mailto:gorry@erg.abdn.ac.uk]
Sent: den 27 november 2017 14:15
To: Roland Zink <roland@zinks.de>
Cc: quic@ietf.org
Subject: Re: Spin bit discussion - where we're at

 

See below:


On 27 Nov 2017, at 12:32, Roland Zink <roland@zinks.de> wrote:

Am 27.11.2017 um 08:03 schrieb Jana Iyengar:

In addition to how the spin bit can be designed and used, I'd like those taking on this effort to consider this question: Whatever network management problem you're considering solving with a bit, what does it take to solve this problem without the bit exposed? I'm asking you to consider "zero-bit" solutions, or at least for a cost/benefit analysis of developing solutions with and without the spin bit for specific network management functions. Specifically,

 

(i) What's impossible or very difficult to do, from a network management perspective, of not having the spin bit? Note that I'm not asking for what is and is not measurable -- not everything measurable is useful. I'm specifically asking in terms of network management functions, in practice, as used by operators. Some of this has been addressed in the discussions/drafts I've seen, but I think it's most useful when framed in terms of network management functions.

I want to express the question about manageability from a different angle. QUIC moves the congestion control from being a common functionality in the kernel to application functionality. It also hides the protocol handling of congestion from the network. This gives incentives for application developers to change congestion control to give their application an advantage over others. No special rights are necessary. Now the question is does QUIC provide enough manageability to avoid an Internet (or some part of it) breakdown when it is misused? Can it be shown that this can't happen?

I think this may touch on some of the topics in:

 

Although this is focussed on issues wider than Quic, I think the points you raise are relevant. This was presented last IETF-100 in TSVWG and INTAREA. We would appreciate insight, and comments on this.  (I am just about to push new version to correct typos!)



(ii) What are the alternatives for building the same functions without the spin bit? Let's consider for a moment that the spin bit isn't actually available in practice. What will operators do to continue managing their networks? This might be expensive, but that's precisely what I'm looking for -- the cost to operators of not having the spin bit. For instance, active probes are a fine way to measure network RTT within operator networks, and that is an alternative. There are surely others too. Their costs and limitations are important to know about in order to reason about their viability, so I'd like to see alternatives considered.

Solu= tions that only work within an operators network are not enough when more than one operator is involved.

Yes, also true.

 

Gorry

 

I don't mean to start the discussion on this thread, but I'd like to urge those going off to do the writing to consider these questions.

 

- jana

 

 

On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) <acmorton@at= t.com> wrote:

Hi Brian, Stephen, Lars, Mark and all,

one join, one suggestion, and one question below.
see [ACM]
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell
> (IETF)
> Sent: Wednesday, November 22, 2017 5:59 AM
> To: Eggert, Lars
> Cc: Mark Nottingham; QUIC WG; Stephen Farrell
> Subject: Re: Spin bit discussion - where we're at
>
> hi Lars,
>
> > On 22 Nov 2017, at 11:35, Eggert, Lars <lars@netapp.com> wrote:
> >
> > Hi,
> >
> > On 2017-11-22, at 11:01, Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> >> What I thought was being requested and what I do think is reasonable
> >> is to document a privacy analysis for any quic protocol bits that are
= > >> visible to the path. Whether or not some or all of that text ends up
> >> in some RFC is another day's work.
> > Lars wrote:
> > for the Spin Bit specifically, the intent was to permanently capture
> the analysis the DT has done, so that when others review the proposed
> Spin Bit specification, they can take that as a given and direct any
> further analysis to other aspects. It made sense to the chairs that that
> specific analysis should become part of the Spin Bit specification. I
> think we'd be open to a discussion on whether a broader document
> analyzing the QUIC wire image would be a better home for this. The main
> point is for the work that the DT has done to be documented.

> Brian wrote:
> Okay. That's somewhat more reasonable than what I read the ask to be
> ("we're going to gate this on the people who care about this doing some
> non-trivial amount of work"). Those of us who volunteer (help, please,
> anyone? :) ) can certainly pull together what we have in a single I-D
> and ask the WG what more it thinks it needs. To me all this seems pretty
> clear, but I've been working on this topic for a while.
[ACM]
Having reached the end of the "Thanksgiving thread",
I'm scrolling back a few pages to join the task of
permanently capturing the work of the DT in an I-D (at least):
There should be lasting value in some of our findings
and IMO they are worthy of a persistent reference.

> Lars wrote:
> > For proposals other than the Spin Bit (I think I have seen individual
> contributors at least mention "loss" and "congestion" bits, but without
> much detail), we wanted to clarify that we'd like to see an analysis and
> discussion of their privacy aspects to roughly the same degree as the DT
> has performed for the Spin Bit proposal.
>
[ACM]
I suggest that this might be a different I-D, at least to start.
Question: Is there a privacy analysis of present ECN available?
(a search yielded many results with Missing: privacy)

regards,
Al

 

 


=20
= --Apple-Mail-736F4616-9EF3-493D-B58F-956006561518-- From nobody Mon Nov 27 09:27: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 4EEA4128BBB for ; Mon, 27 Nov 2017 09:27:08 -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 DYZpExAB-UJZ for ; Mon, 27 Nov 2017 09:27:07 -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 EB0BB12895E for ; Mon, 27 Nov 2017 09:27:06 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id c123so23037536qkf.7 for ; Mon, 27 Nov 2017 09:27: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=WxYr18VoaE1/5ie4U/CTzUxK2fRXQqRg2pidhAG6YRA=; b=Yw72uZP2fazS+A+PO20Pv+l5Tr6vZRlnQHNx5+Z3VhVuJaysjjAyF6bpNpEIvrHmxq vjcj7IMUvLGTykbreCMWxsNYJ01zIddTIzJwdF8lVHNFgBylpKgTqRZgRf1sQK17iNvt GYRTRGTm3PT0U3oc7ujyjExV27wFuOEVkZuhWU2MNoyJahU7WY72+eqF73VwFpugzgL6 DFFpKv8kC11tBRGI/PyXCiRne2npOI/NQ0Fl4cYBIZ+1QzwvG5BElIu/dfmBu2KrdGcw 81Y7dKE/LD5fg21XwJs64ZXcohVM33byePZi7URyJs69P61QocDG2bJnNA6NbBW/0XCy qIww== 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=WxYr18VoaE1/5ie4U/CTzUxK2fRXQqRg2pidhAG6YRA=; b=NMzFCs3psx6TnMXfUUeP7G0fb/zwkvPxZcnd8OufFxl0leItywY7/t0RLwS/djM/j7 JuTxL3ft4EU4SsvqewDD3BSIO797JLZR0IV8VROKB77OxT2SA6MUZ9GDqAPmYmonY8f6 lSaBzixpaZQqCAEpgca6H+rdIDs7AZbcLRQ3rGrzEFWIgZDRATL0kEUtLE3uo17VQtKB AZ+tGixI5hB+XLU2K9ylhSYUgd2UFsAk2rh3CVI0Suq9rr5QQHRugOx+WLuw8fpfRR/p TTSS/SJhUWVQhgKk9W5UeR1rit865cLfbqh6QQrItz03bskZ36McdM2XCXIEgR+yuOWW ZqvQ== X-Gm-Message-State: AJaThX7jx8J1UvUeheaTwhh7UgOMLBytQIeRnbLBH3wQfQyGyMpuvHjG W+kmAMIgnm4kj+Qh+z/xheGAaXHq4lZn1uBs7Ws= X-Google-Smtp-Source: AGs4zMbCbjKC5rmmGxtZfFHiBCk00xp6+mxAQSO12wvK6BjV9hLs3O0wnLhaMPskBRnNBO1zdRvaT+ihi4ig0JoovDI= X-Received: by 10.55.163.17 with SMTP id m17mr61010346qke.304.1511803625780; Mon, 27 Nov 2017 09:27:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.169 with HTTP; Mon, 27 Nov 2017 09:26:35 -0800 (PST) In-Reply-To: <55F677B1-E18B-4F40-9A8E-28E4A24C562E@trammell.ch> References: <5108b3b9-d374-0709-3e6f-57c3192469b8@tessares.net> <55F677B1-E18B-4F40-9A8E-28E4A24C562E@trammell.ch> From: Ted Hardie Date: Mon, 27 Nov 2017 09:26:35 -0800 Message-ID: Subject: Re: reserved bits for spin bit, etc. To: "Brian Trammell (IETF)" Cc: Jana Iyengar , Christian Huitema , Olivier Bonaventure , "quic@ietf.org" , Martin Thomson Content-Type: multipart/alternative; boundary="001a114fb00415b9bd055efa3642" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 17:27:08 -0000 --001a114fb00415b9bd055efa3642 Content-Type: text/plain; charset="UTF-8" Quoting one tiny piece of this for emphasis: On Sun, Nov 26, 2017 at 11:03 PM, Brian Trammell (IETF) wrote: > I'll note that if we go to varints for packet numbers -- which we really > should -- then there are five bits free in the short header now. We'll > probably want to reserve all of those for the future, regardless of how > many of them eventually get used for measurability, so they'll need to be > greased somehow anyway. > I think Brian has this exactly right: if we reclaim these bits, then they need to be greased as soon as possible. Having the greasing algorithms working and the peer behavior confirmed would be something I'd argue for as a test for the first implementation draft after the change is made. We've identified greasing as a strong requirement for avoiding early ossification in QUIC, and I think this is a useful test of *that*, regardless of the eventual use of the bits. regards, Ted --001a114fb00415b9bd055efa3642 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Quoting one tiny piece of this for emphasis:

On Sun, Nov 26, 2017 a= t 11:03 PM, Brian Trammell (IETF) <ietf@trammell.ch> wrote:
=C2=A0
I'll note that if we = go to varints for packet numbers -- which we really should -- then there ar= e five bits free in the short header now. We'll probably want to reserv= e all of those for the future, regardless of how many of them eventually ge= t used for measurability, so they'll need to be greased somehow anyway.=

I think Brian has this exactly right:=C2=A0 if we reclaim= these bits, then they need to be greased as soon as possible.=C2=A0 Having= the greasing algorithms=C2=A0 working and the peer behavior confirmed woul= d be something I'd argue for as a test for the first implementation dra= ft after the change is made.=C2=A0
We've identified greasing as a strong= requirement for avoiding early ossification in QUIC, and I think this is a= useful test of *that*, regardless of the eventual use of the bits.

regards,

Ted
--001a114fb00415b9bd055efa3642-- From nobody Mon Nov 27 09:36: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 7A848128D19 for ; Mon, 27 Nov 2017 09:36: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, 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 qCxb14QK5Ng9 for ; Mon, 27 Nov 2017 09:36:23 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::11]) (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 596A7128BA2 for ; Mon, 27 Nov 2017 09:36:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1511804180; s=domk; d=zinks.de; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:X-RZG-CLASS-ID:X-RZG-AUTH:Accept-Language: Auto-Submitted:Cc:Date:From:Message-ID:References:Reply-To:Resent-Cc: Resent-Date:Resent-From:Resent-To:Sender:Subject:To: Content-Alternative:Content-Description:Content-Disposition: Content-Duration:Content-Features:Content-ID:Content-Language: Content-Location:Content-MD5:Content-Transfer-Encoding:Content-Type: MIME-Version; bh=JufUU5pXPLmV5cyMH+DhRdr628kuFmG/gS9BA7ijNd8=; b=COzLVe0qieXRtyjaXjDwYYCGgACRiy65noYBhHOSQIzHuv1E1sg7T7jb/rZ2N97Ghe 4ha67bHXrDJKlAt0HTh+6dhJo/DLo1M+QVQG+CEJpT9lm3wbogKMuyEbS05q5dEljCkO fTQ8dU421YxU+iHTWF8IdemyaPD6Fql6aWrPI= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1oaZ1h8oElTTgmJ6Fg== X-RZG-CLASS-ID: mo00 Received: from [10.10.10.80] (p57B96C2D.dip0.t-ipconnect.de [87.185.108.45]) by smtp.strato.de (RZmta 42.10 DYNA|AUTH) with ESMTPSA id e03071tARHa8392 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Mon, 27 Nov 2017 18:36:08 +0100 (CET) Subject: Re: Spin bit discussion - where we're at To: Christian Huitema Cc: Ingemar Johansson S , "Gorry (erg)" , "quic@ietf.org" References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@erg.abdn.ac.uk> <74e1c7bd-bd09-3285-db25-db04fe530cbc@zinks.de> <34BF55EB-8B3E-453C-BAFE-8048B4B94FC5@huitema.net> From: Roland Zink Message-ID: <54e419d4-e4c0-2e9e-93ab-6ff7750e483a@zinks.de> Date: Mon, 27 Nov 2017 18:36:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <34BF55EB-8B3E-453C-BAFE-8048B4B94FC5@huitema.net> Content-Type: multipart/alternative; boundary="------------8E591EB1C3F5AC06DF4B4884" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 17:36:26 -0000 This is a multi-part message in MIME format. --------------8E591EB1C3F5AC06DF4B4884 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit If QUIC makes the problem crystal clear then now seems to be a good time to solve or mitigate it before risking it becomes a real world problem. Roland Am 27.11.2017 um 17:38 schrieb Christian Huitema: > The network cannot control the congestion algorithm in the end points. > QUIC does not create the problem, just makes it crystal clear. But the > network can manage queues. So does the kernel. > > -- Christian Huitema > > On Nov 27, 2017, at 6:47 AM, Roland Zink > wrote: > >> I guess the guys which really want to do it will somehow get the >> necessary rights (like to load a kernel module) and do it although >> this may be difficult if you want to do it on million of devices. I'm >> more thinking of a slow process, say app 1 increase the initial >> window then app 2 thinks it needs to do the same and back out less >> than the default. Then app 1 is doing something and at some point >> nobody follows what is (will be) in the RFC. They not necessarily >> want to break something but at the end it can result into the same. >> It is no longer a single policy which applies to all apps instead >> each app comes with its own and the apps often can control both sides. >> >> >> Roland >> >> >> >> Am 27.11.2017 um 15:14 schrieb Ingemar Johansson S: >>> >>> Hi >>> >>> I would say that it is perfectly possible to trick e.g. the Linux >>> TCP stack to something like what is described below. Just clone >>> tcp_cong.c , >>> >>> Change the following lines >>> >>> u32 *tcp_reno_ssthresh* >>> (struct*sock* >>> *sk) >>> >>> { >>> >>> conststruct*tcp_sock* >>> *tp >>> =*tcp_sk* >>> (sk); >>> >>> return*max* >>> (tp->snd_cwnd >>> >>1U,2U); >>> >>> } >>> >>> To something like >>> >>> u32*tcp_**bloat**_ssthresh* >>> (struct*sock* >>> *sk) >>> { >>> conststruct*tcp_sock* >>> >>> *tp=*tcp_sk* >>> (sk); >>> returntp->snd_cwnd; >>> } >>> >>> Build it and make it a loadable kernel module, you need to rename a >>> few other functions as well, and you can call it tcp_bloat.c 😊 >>> >>> So.. my opinion is that you can perfectly well collapse the internet >>> also with TCP. ConEx was introduced as a medicine for this but it >>> never gained traction. >>> >>> /Ingemar >>> >>> *From:* Gorry (erg) [mailto:gorry@erg.abdn.ac.uk] >>> *Sent:* den 27 november 2017 14:15 >>> *To:* Roland Zink >>> *Cc:* quic@ietf.org >>> *Subject:* Re: Spin bit discussion - where we're at >>> >>> See below: >>> >>> >>> On 27 Nov 2017, at 12:32, Roland Zink >> > wrote: >>> >>> Am 27.11.2017 um 08:03 schrieb Jana Iyengar: >>> >>> In addition to how the spin bit can be designed and used, >>> I'd like those taking on this effort to consider this >>> question: Whatever network management problem you're >>> considering solving with a bit, what does it take to solve >>> this problem without the bit exposed? I'm asking you to >>> consider "zero-bit" solutions, or at least for a >>> cost/benefit analysis of developing solutions with and >>> without the spin bit for specific network management >>> functions. Specifically, >>> >>> (i) What's impossible or very difficult to do, from a >>> network management perspective, of not having the spin bit? >>> Note that I'm not asking for what is and is not measurable >>> -- not everything measurable is useful. I'm specifically >>> asking in terms of network management functions, in >>> practice, as used by operators. Some of this has been >>> addressed in the discussions/drafts I've seen, but I think >>> it's most useful when framed in terms of network management >>> functions. >>> >>> I want to express the question about manageability from a >>> different angle. QUIC moves the congestion control from being a >>> common functionality in the kernel to application functionality. >>> It also hides the protocol handling of congestion from the >>> network. This gives incentives for application developers to >>> change congestion control to give their application an advantage >>> over others. No special rights are necessary. Now the question >>> is does QUIC provide enough manageability to avoid an Internet >>> (or some part of it) breakdown when it is misused? Can it be >>> shown that this can't happen? >>> >>> I think this may touch on some of the topics in: >>> >>> https://tools.ietf.org/html/draft-fairhurst-tsvwg-transport-encrypt-04 >>> >>> Although this is focussed on issues wider than Quic, I think the >>> points you raise are relevant. This was presented last IETF-100 in >>> TSVWG and INTAREA. We would appreciate insight, and comments on >>> this.  (I am just about to push new version to correct typos!) >>> >>> >>> >>> (ii) What are the alternatives for building the same >>> functions without the spin bit? Let's consider for a moment >>> that the spin bit isn't actually available in practice. What >>> will operators do to continue managing their networks? This >>> might be expensive, but that's precisely what I'm looking >>> for -- the cost to operators of not having the spin bit. For >>> instance, active probes are a fine way to measure network >>> RTT within operator networks, and that is an alternative. >>> There are surely others too. Their costs and limitations are >>> important to know about in order to reason about their >>> viability, so I'd like to see alternatives considered. >>> >>> Solutions that only work within an operators network are not >>> enough when more than one operator is involved. >>> >>> Yes, also true. >>> >>> Gorry >>> >>> I don't mean to start the discussion on this thread, but I'd >>> like to urge those going off to do the writing to consider >>> these questions. >>> >>> - jana >>> >>> On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) >>> > wrote: >>> >>> Hi Brian, Stephen, Lars, Mark and all, >>> >>> one join, one suggestion, and one question below. >>> see [ACM] >>> > -----Original Message----- >>> > From: QUIC [mailto:quic-bounces@ietf.org >>> ] On Behalf Of Brian Trammell >>> > (IETF) >>> > Sent: Wednesday, November 22, 2017 5:59 AM >>> > To: Eggert, Lars >>> > Cc: Mark Nottingham; QUIC WG; Stephen Farrell >>> > Subject: Re: Spin bit discussion - where we're at >>> > >>> > hi Lars, >>> > >>> > > On 22 Nov 2017, at 11:35, Eggert, Lars >>> > wrote: >>> > > >>> > > Hi, >>> > > >>> > > On 2017-11-22, at 11:01, Stephen Farrell >>> >> > >>> > wrote: >>> > >> What I thought was being requested and what I do >>> think is reasonable >>> > >> is to document a privacy analysis for any quic >>> protocol bits that are >>> > >> visible to the path. Whether or not some or all of >>> that text ends up >>> > >> in some RFC is another day's work. >>> > > Lars wrote: >>> > > for the Spin Bit specifically, the intent was to >>> permanently capture >>> > the analysis the DT has done, so that when others >>> review the proposed >>> > Spin Bit specification, they can take that as a given >>> and direct any >>> > further analysis to other aspects. It made sense to >>> the chairs that that >>> > specific analysis should become part of the Spin Bit >>> specification. I >>> > think we'd be open to a discussion on whether a >>> broader document >>> > analyzing the QUIC wire image would be a better home >>> for this. The main >>> > point is for the work that the DT has done to be >>> documented. >>> >>> > Brian wrote: >>> > Okay. That's somewhat more reasonable than what I read >>> the ask to be >>> > ("we're going to gate this on the people who care >>> about this doing some >>> > non-trivial amount of work"). Those of us who >>> volunteer (help, please, >>> > anyone? :) ) can certainly pull together what we have >>> in a single I-D >>> > and ask the WG what more it thinks it needs. To me all >>> this seems pretty >>> > clear, but I've been working on this topic for a while. >>> [ACM] >>> Having reached the end of the "Thanksgiving thread", >>> I'm scrolling back a few pages to join the task of >>> permanently capturing the work of the DT in an I-D (at >>> least): >>> There should be lasting value in some of our findings >>> and IMO they are worthy of a persistent reference. >>> >>> > Lars wrote: >>> > > For proposals other than the Spin Bit (I think I >>> have seen individual >>> > contributors at least mention "loss" and "congestion" >>> bits, but without >>> > much detail), we wanted to clarify that we'd like to >>> see an analysis and >>> > discussion of their privacy aspects to roughly the >>> same degree as the DT >>> > has performed for the Spin Bit proposal. >>> > >>> [ACM] >>> I suggest that this might be a different I-D, at least >>> to start. >>> Question: Is there a privacy analysis of present ECN >>> available? >>> (a search yielded many results with Missing: privacy) >>> >>> regards, >>> Al >>> >> --------------8E591EB1C3F5AC06DF4B4884 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+DQogIDxoZWFkPg0KICAgIDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgPC9oZWFkPg0KICA8Ym9k eSB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIj4NCiAgICA8cD5JZiBRVUlDIG1h a2VzIHRoZSBwcm9ibGVtIGNyeXN0YWwgY2xlYXIgdGhlbiBub3cgc2VlbXMgdG8gYmUgYQ0K ICAgICAgZ29vZCB0aW1lIHRvIHNvbHZlIG9yIG1pdGlnYXRlIGl0IGJlZm9yZSByaXNraW5n IGl0IGJlY29tZXMgYSByZWFsDQogICAgICB3b3JsZCBwcm9ibGVtLjwvcD4NCiAgICBSb2xh bmQ8YnI+DQogICAgPGJyPg0KICAgIDxicj4NCiAgICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1w cmVmaXgiPkFtIDI3LjExLjIwMTcgdW0gMTc6Mzggc2NocmllYg0KICAgICAgQ2hyaXN0aWFu IEh1aXRlbWE6PGJyPg0KICAgIDwvZGl2Pg0KICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUi DQogICAgICBjaXRlPSJtaWQ6MzRCRjU1RUItOEIzRS00NTNDLUJBRkUtODA0OEI0Qjk0RkM1 QGh1aXRlbWEubmV0Ij4NCiAgICAgIDxtZXRhIGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCiAgICAgIFRoZSBuZXR3b3Jr IGNhbm5vdCBjb250cm9sIHRoZSBjb25nZXN0aW9uIGFsZ29yaXRobSBpbiB0aGUgZW5kDQog ICAgICBwb2ludHMuIFFVSUMgZG9lcyBub3QgY3JlYXRlIHRoZSBwcm9ibGVtLCBqdXN0IG1h a2VzIGl0IGNyeXN0YWwNCiAgICAgIGNsZWFyLiBCdXQgdGhlIG5ldHdvcmsgY2FuIG1hbmFn ZSBxdWV1ZXMuIFNvIGRvZXMgdGhlIGtlcm5lbC48YnI+DQogICAgICA8YnI+DQogICAgICA8 ZGl2IGlkPSJBcHBsZU1haWxTaWduYXR1cmUiPi0tIENocmlzdGlhbiBIdWl0ZW1hwqA8L2Rp dj4NCiAgICAgIDxkaXY+PGJyPg0KICAgICAgICBPbiBOb3YgMjcsIDIwMTcsIGF0IDY6NDcg QU0sIFJvbGFuZCBaaW5rICZsdDs8YQ0KICAgICAgICAgIGhyZWY9Im1haWx0bzpyb2xhbmRA emlua3MuZGUiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+cm9sYW5kQHppbmtzLmRlPC9hPiZn dDsNCiAgICAgICAgd3JvdGU6PGJyPg0KICAgICAgICA8YnI+DQogICAgICA8L2Rpdj4NCiAg ICAgIDxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KICAgICAgICA8ZGl2Pg0KICAgICAgICAg IDxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0idGV4dC9odG1sOw0K ICAgICAgICAgICAgY2hhcnNldD11dGYtOCI+DQogICAgICAgICAgPHA+SSBndWVzcyB0aGUg Z3V5cyB3aGljaCByZWFsbHkgd2FudCB0byBkbyBpdCB3aWxsIHNvbWVob3cNCiAgICAgICAg ICAgIGdldCB0aGUgbmVjZXNzYXJ5IHJpZ2h0cyAobGlrZSB0byBsb2FkIGEga2VybmVsIG1v ZHVsZSkgYW5kDQogICAgICAgICAgICBkbyBpdCBhbHRob3VnaCB0aGlzIG1heSBiZSBkaWZm aWN1bHQgaWYgeW91IHdhbnQgdG8gZG8gaXQgb24NCiAgICAgICAgICAgIG1pbGxpb24gb2Yg ZGV2aWNlcy4gSSdtIG1vcmUgdGhpbmtpbmcgb2YgYSBzbG93IHByb2Nlc3MsIHNheQ0KICAg ICAgICAgICAgYXBwIDEgaW5jcmVhc2UgdGhlIGluaXRpYWwgd2luZG93IHRoZW4gYXBwIDIg dGhpbmtzIGl0IG5lZWRzDQogICAgICAgICAgICB0byBkbyB0aGUgc2FtZSBhbmQgYmFjayBv dXQgbGVzcyB0aGFuIHRoZSBkZWZhdWx0LiBUaGVuIGFwcA0KICAgICAgICAgICAgMSBpcyBk b2luZyBzb21ldGhpbmcgYW5kIGF0IHNvbWUgcG9pbnQgbm9ib2R5IGZvbGxvd3Mgd2hhdA0K ICAgICAgICAgICAgaXMgKHdpbGwgYmUpIGluIHRoZSBSRkMuIFRoZXkgbm90IG5lY2Vzc2Fy aWx5IHdhbnQgdG8gYnJlYWsNCiAgICAgICAgICAgIHNvbWV0aGluZyBidXQgYXQgdGhlIGVu ZCBpdCBjYW4gcmVzdWx0IGludG8gdGhlIHNhbWUuIEl0IGlzDQogICAgICAgICAgICBubyBs b25nZXIgYSBzaW5nbGUgcG9saWN5IHdoaWNoIGFwcGxpZXMgdG8gYWxsIGFwcHMgaW5zdGVh ZA0KICAgICAgICAgICAgZWFjaCBhcHAgY29tZXMgd2l0aCBpdHMgb3duIGFuZCB0aGUgYXBw cyBvZnRlbiBjYW4gY29udHJvbA0KICAgICAgICAgICAgYm90aCBzaWRlcy48YnI+DQogICAg ICAgICAgPC9wPg0KICAgICAgICAgIDxwPjxicj4NCiAgICAgICAgICA8L3A+DQogICAgICAg ICAgPHA+Um9sYW5kPGJyPg0KICAgICAgICAgIDwvcD4NCiAgICAgICAgICA8YnI+DQogICAg ICAgICAgPGJyPg0KICAgICAgICAgIDxkaXYgY2xhc3M9Im1vei1jaXRlLXByZWZpeCI+QW0g MjcuMTEuMjAxNyB1bSAxNToxNCBzY2hyaWViDQogICAgICAgICAgICBJbmdlbWFyIEpvaGFu c3NvbiBTOjxicj4NCiAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICA8YmxvY2txdW90ZSB0 eXBlPSJjaXRlIg0KY2l0ZT0ibWlkOkRCNFBSMDdNQjM0OENBRjA2NzQwMUNEMjc3NDg1NDY0 QzIyNTBAREI0UFIwN01CMzQ4LmV1cnByZDA3LnByb2Qub3V0bG9vay5jb20iPg0KICAgICAg ICAgICAgPG1ldGEgaHR0cC1lcXVpdj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0 bWw7DQogICAgICAgICAgICAgIGNoYXJzZXQ9dXRmLTgiPg0KICAgICAgICAgICAgPG1ldGEg bmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQN CiAgICAgICAgICAgICAgbWVkaXVtKSI+DQogICAgICAgICAgICA8c3R5bGU+PCEtLQ0KLyog Rm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJp YSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIg NDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw dDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnBy ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHls ZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4t cmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndp bmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNv dXJpZXIgTmV3Ijt9DQpzcGFuLm4NCgl7bXNvLXN0eWxlLW5hbWU6bjt9DQpzcGFuLm5mDQoJ e21zby1zdHlsZS1uYW1lOm5mO30NCnNwYW4ucA0KCXttc28tc3R5bGUtbmFtZTpwO30NCnNw YW4uaw0KCXttc28tc3R5bGUtbmFtZTprO30NCnNwYW4ubw0KCXttc28tc3R5bGUtbmFtZTpv O30NCnNwYW4ubWkNCgl7bXNvLXN0eWxlLW5hbWU6bWk7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1 cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0K PG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQogICAgICAgICAgICA8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5I aTxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5J IHdvdWxkIHNheSB0aGF0IGl0IGlzIHBlcmZlY3RseQ0KICAgICAgICAgICAgICAgIHBvc3Np YmxlIHRvIHRyaWNrIGUuZy4gdGhlIExpbnV4IFRDUCBzdGFjayB0byBzb21ldGhpbmcNCiAg ICAgICAgICAgICAgICBsaWtlIHdoYXQgaXMgZGVzY3JpYmVkIGJlbG93LiBKdXN0IGNsb25l IHRjcF9jb25nLmMgLCA8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Q2hhbmdlIHRoZSBmb2xsb3dpbmcgbGluZXMgPG86cD48L286cD48L3A+ DQogICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuDQogICAgICAgICAg ICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3Vy aWVyDQogICAgICAgICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPnUzMiA8L3Nw YW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5ldyZxdW90Oztj b2xvcjojMDA2NkJCIj48YQ0KaHJlZj0iaHR0cHM6Ly9lbGl4aXIuZnJlZS1lbGVjdHJvbnMu Y29tL2xpbnV4L3YzLjEyL2lkZW50L3RjcF9yZW5vX3NzdGhyZXNoIg0KICAgICAgICAgICAg ICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPjxiPjxzcGFuDQogICAgICAgICAgICAg ICAgICAgICAgICBzdHlsZT0iYmFja2dyb3VuZDojRjRGNkZGIj50Y3BfcmVub19zc3RocmVz aDwvc3Bhbj48L2I+PC9hPjwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAgc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAg ICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPig8L3NwYW4+PHNwYW4NCiAgICAg ICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjojMDA4ODAwIj5z dHJ1Y3Q8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5l dyZxdW90Oztjb2xvcjpibGFjayI+IDxhDQogICAgICAgICAgICAgICAgICAgIGhyZWY9Imh0 dHBzOi8vZWxpeGlyLmZyZWUtZWxlY3Ryb25zLmNvbS9saW51eC92My4xMi9pZGVudC9zb2Nr Ig0KICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPjxiPjxzcGFu DQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iYmFja2dyb3VuZDojRjRGNkZGIj5z b2NrPC9zcGFuPjwvYj48L2E+IDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAgc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAg ICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2NjYiPio8L3NwYW4+PHNwYW4NCiAg ICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ c2s8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5ldyZx dW90Oztjb2xvcjojNjY2NjY2Ij4pPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAg ICAgICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCiAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4NCiAgICAg ICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjojNjY2NjY2Ij57 PC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgICAgICAgICAgICAg PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4NCiAgICAgICAgICAgICAgICAgIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAg ICAgICAgIE5ldyZxdW90Oztjb2xvcjpibGFjayI+wqDCoMKgwqDCoMKgwqAgPC9zcGFuPjxz cGFuDQogICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6 IzAwODgwMCI+Y29uc3Q8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAg ICAgICAgIE5ldyZxdW90Oztjb2xvcjpibGFjayI+IDwvc3Bhbj48c3Bhbg0KICAgICAgICAg ICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllcg0KICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOiMwMDg4MDAiPnN0cnVj dDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrIj4gPGENCiAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6 Ly9lbGl4aXIuZnJlZS1lbGVjdHJvbnMuY29tL2xpbnV4L3YzLjEyL2lkZW50L3RjcF9zb2Nr Ig0KICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPjxiPjxzcGFu DQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iYmFja2dyb3VuZDojRjRGNkZGIj50 Y3Bfc29jazwvc3Bhbj48L2I+PC9hPg0KICAgICAgICAgICAgICAgIDwvc3Bhbj48c3Bhbg0K ICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOiM2NjY2 NjYiPio8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5l dyZxdW90Oztjb2xvcjpibGFjayI+dHAgPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAg ICBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQog ICAgICAgICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+PTwvc3Bhbj48c3Bh bg0KICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj4gPGENCiAgICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9lbGl4aXIuZnJl ZS1lbGVjdHJvbnMuY29tL2xpbnV4L3YzLjEyL2lkZW50L3RjcF9zayINCiAgICAgICAgICAg ICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48Yj48c3Bhbg0KICAgICAgICAgICAg ICAgICAgICAgICAgc3R5bGU9ImJhY2tncm91bmQ6I0Y0RjZGRiI+dGNwX3NrPC9zcGFuPjwv Yj48L2E+PC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICBO ZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+KDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAg ICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0K ICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj5zazwvc3Bhbj48c3Bh bg0KICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOiM2 NjY2NjYiPik7PC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAg ICBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCiAgICAg ICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4NCiAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAg ICAgICAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjpibGFjayI+wqDCoMKgwqDCoMKgwqAg PC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICBOZXcmcXVv dDs7Y29sb3I6IzAwODgwMCI+cmV0dXJuPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAg ICBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQog ICAgICAgICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6YmxhY2siPiA8YQ0KICAgICAgICAg ICAgICAgICAgICBocmVmPSJodHRwczovL2VsaXhpci5mcmVlLWVsZWN0cm9ucy5jb20vbGlu dXgvdjMuMTIvaWRlbnQvbWF4Ig0KICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNl bmQ9InRydWUiPjxiPjxzcGFuDQogICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0iYmFj a2dyb3VuZDojRjRGNkZGIj5tYXg8L3NwYW4+PC9iPjwvYT48L3NwYW4+PHNwYW4NCiAgICAg ICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjojNjY2NjY2Ij4o PC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICBOZXcmcXVv dDs7Y29sb3I6YmxhY2siPnRwPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAg ICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+LSZndDs8L3NwYW4+PHNwYW4N CiAgICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjpibGFj ayI+c25kX2N3bmQgPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICBzdHlsZT0iZm9u dC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAg ICAgICBOZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+Jmd0OyZndDs8L3NwYW4+PHNwYW4NCiAg ICAgICAgICAgICAgICAgIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXINCiAgICAgICAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjpibGFjayI+ IDwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgTmV3JnF1 b3Q7O2NvbG9yOiMwMDAwREQiPjFVPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAg ICAgICAgICAgICAgICBOZXcmcXVvdDs7Y29sb3I6IzY2NjY2NiI+LDwvc3Bhbj48c3Bhbg0K ICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNr Ij4gPC9zcGFuPjxzcGFuDQogICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICBOZXcm cXVvdDs7Y29sb3I6IzAwMDBERCI+MlU8L3NwYW4+PHNwYW4NCiAgICAgICAgICAgICAgICAg IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXINCiAg ICAgICAgICAgICAgICAgIE5ldyZxdW90Oztjb2xvcjojNjY2NjY2Ij4pOzwvc3Bhbj48c3Bh bg0KICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllcg0KICAgICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQogICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuDQogICAgICAgICAgICAgICAgICBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyDQogICAgICAgICAgICAgICAgICBOZXcm cXVvdDs7Y29sb3I6IzY2NjY2NiI+fTwvc3Bhbj48c3Bhbg0KICAgICAgICAgICAgICAgICAg c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllcg0KICAg ICAgICAgICAgICAgICAgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQogICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPlRvIHNvbWV0aGlu ZyBsaWtlPG86cD48L286cD48L3A+DQogICAgICAgICAgICAgIDxwcmU+PHNwYW4gY2xhc3M9 Im4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+dTMyPC9zcGFuPjwvc3Bhbj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiA8L3NwYW4+PHNwYW4gY2xhc3M9Im5mIj48c3BhbiBzdHls ZT0iY29sb3I6IzAwNjZCQiI+PGEgaHJlZj0iaHR0cHM6Ly9lbGl4aXIuZnJlZS1lbGVjdHJv bnMuY29tL2xpbnV4L3YzLjEyL2lkZW50L3RjcF9yZW5vX3NzdGhyZXNoIiBtb3otZG8tbm90 LXNlbmQ9InRydWUiPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNEY2RkYiPnRjcF88 L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOiNGNEY2RkYiPmJsb2F0PC9z cGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRjRGNkZGIj5fc3N0aHJlc2g8 L3NwYW4+PC9iPjwvYT48L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJwIj48c3BhbiBzdHls ZT0iY29sb3I6IzY2NjY2NiI+KDwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9ImsiPjxzcGFu IHN0eWxlPSJjb2xvcjojMDA4ODAwIj5zdHJ1Y3Q8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+IDxzcGFuIGNsYXNzPSJuIj48YSBocmVmPSJodHRwczovL2VsaXhp ci5mcmVlLWVsZWN0cm9ucy5jb20vbGludXgvdjMuMTIvaWRlbnQvc29jayIgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIj48Yj48c3BhbiBzdHlsZT0iYmFja2dyb3VuZDojRjRGNkZGIj5zb2Nr PC9zcGFuPjwvYj48L2E+PC9zcGFuPiA8L3NwYW4+PHNwYW4gY2xhc3M9Im8iPjxzcGFuIHN0 eWxlPSJjb2xvcjojNjY2NjY2Ij4qPC9zcGFuPjwvc3Bhbj48c3BhbiBjbGFzcz0ibiI+PHNw YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5zazwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9InAi PjxzcGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij4pPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KICAgICAgICAgICAg ICA8cHJlPjxzcGFuIGNsYXNzPSJwIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+ezwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCiAgICAgICAgICAgICAgPHByZT48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PsKgwqDCoMKgwqDCoMKgIDwvc3Bhbj48c3BhbiBjbGFzcz0iayI+PHNwYW4gc3R5bGU9ImNv bG9yOiMwMDg4MDAiPmNvbnN0PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6Ymxh Y2siPiA8L3NwYW4+PHNwYW4gY2xhc3M9ImsiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA4ODAw Ij5zdHJ1Y3Q8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+IDxzcGFu IGNsYXNzPSJuIj48YSBocmVmPSJodHRwczovL2VsaXhpci5mcmVlLWVsZWN0cm9ucy5jb20v bGludXgvdjMuMTIvaWRlbnQvdGNwX3NvY2siIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+PGI+ PHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6I0Y0RjZGRiI+dGNwX3NvY2s8L3NwYW4+PC9iPjwv YT48L3NwYW4+IDwvc3Bhbj48c3BhbiBjbGFzcz0ibyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM2 NjY2NjYiPio8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJuIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPnRwPC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiA8 L3NwYW4+PHNwYW4gY2xhc3M9Im8iPjxzcGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij49PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiA8c3BhbiBjbGFzcz0ibiI+ PGEgaHJlZj0iaHR0cHM6Ly9lbGl4aXIuZnJlZS1lbGVjdHJvbnMuY29tL2xpbnV4L3YzLjEy L2lkZW50L3RjcF9zayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj48Yj48c3BhbiBzdHlsZT0i YmFja2dyb3VuZDojRjRGNkZGIj50Y3Bfc2s8L3NwYW4+PC9iPjwvYT48L3NwYW4+PC9zcGFu PjxzcGFuIGNsYXNzPSJwIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+KDwvc3Bhbj48 L3NwYW4+PHNwYW4gY2xhc3M9Im4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c2s8L3Nw YW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJwIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+ KTs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQogICAgICAgICAgICAgIDxwcmU+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj7CoMKgwqDCoMKgwqDCoCA8L3NwYW4+PHNwYW4gY2xhc3M9ImsiPjxzcGFuIHN0eWxl PSJjb2xvcjojMDA4ODAwIj5yZXR1cm48L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+IDxzcGFuIGNsYXNzPSJuIj50cDwvc3Bhbj48L3NwYW4+PHNwYW4gY2xhc3M9 Im8iPjxzcGFuIHN0eWxlPSJjb2xvcjojNjY2NjY2Ij4tJmd0Ozwvc3Bhbj48L3NwYW4+PHNw YW4gY2xhc3M9Im4iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+c25kX2N3bmQ8L3NwYW4+ PC9zcGFuPjxzcGFuIGNsYXNzPSJwIj48c3BhbiBzdHlsZT0iY29sb3I6IzY2NjY2NiI+Ozwv c3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCiAgICAgICAgICAgICAgPHByZT48c3BhbiBjbGFzcz0icCI+PHNwYW4gc3R5 bGU9ImNvbG9yOiM2NjY2NjYiPn08L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQogICAgICAgICAgICAgIDxwIGNsYXNz PSJNc29Ob3JtYWwiPkJ1aWxkIGl0IGFuZCBtYWtlIGl0IGEgbG9hZGFibGUNCiAgICAgICAg ICAgICAgICBrZXJuZWwgbW9kdWxlLCB5b3UgbmVlZCB0byByZW5hbWUgYSBmZXcgb3RoZXIg ZnVuY3Rpb25zDQogICAgICAgICAgICAgICAgYXMgd2VsbCwgYW5kIHlvdSBjYW4gY2FsbCBp dCB0Y3BfYmxvYXQuYyA8c3Bhbg0KICAgICAgICAgICAgICAgICAgc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1NlZ29lIFVJDQogICAgICAgICAgICAgICAgICBFbW9qaSZxdW90OyxzYW5z LXNlcmlmIj7wn5iKPC9zcGFuPiA8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD7CoDwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U28uLiBteSBvcGluaW9uIGlzIHRoYXQgeW91IGNhbg0KICAg ICAgICAgICAgICAgIHBlcmZlY3RseSB3ZWxsIGNvbGxhcHNlIHRoZSBpbnRlcm5ldCBhbHNv IHdpdGggVENQLg0KICAgICAgICAgICAgICAgIENvbkV4IHdhcyBpbnRyb2R1Y2VkIGFzIGEg bWVkaWNpbmUgZm9yIHRoaXMgYnV0IGl0IG5ldmVyDQogICAgICAgICAgICAgICAgZ2FpbmVk IHRyYWN0aW9uLiA8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD7CoDwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1z b05vcm1hbCI+L0luZ2VtYXI8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD7CoDwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD7CoDwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD7CoDwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD7CoDwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZQ0KICAgICAgICAgICAg ICAgIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KICAgICAgICAgICAgICAg IDxkaXY+DQogICAgICAgICAgICAgICAgICA8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTENCiAgICAgICAgICAgICAgICAgICAgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPkZyb206PC9iPiBHb3JyeSAoZXJnKSBbPGENCiAgICAgICAgICAgICAg ICAgICAgICAgIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiDQogICAgICAgICAgICAg ICAgICAgICAgICBocmVmPSJtYWlsdG86Z29ycnlAZXJnLmFiZG4uYWMudWsiDQogICAgICAg ICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPm1haWx0bzpnb3JyeUBl cmcuYWJkbi5hYy51azwvYT5dDQogICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAg ICAgICAgICAgICAgICAgIDxiPlNlbnQ6PC9iPiBkZW4gMjcgbm92ZW1iZXIgMjAxNyAxNDox NTxicj4NCiAgICAgICAgICAgICAgICAgICAgICA8Yj5Ubzo8L2I+IFJvbGFuZCBaaW5rIDxh DQogICAgICAgICAgICAgICAgICAgICAgICBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZF Ig0KICAgICAgICAgICAgICAgICAgICAgICAgaHJlZj0ibWFpbHRvOnJvbGFuZEB6aW5rcy5k ZSINCiAgICAgICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+Jmx0 O3JvbGFuZEB6aW5rcy5kZSZndDs8L2E+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgIDxi PkNjOjwvYj4gPGEgY2xhc3M9Im1vei10eHQtbGluay1hYmJyZXZpYXRlZCINCiAgICAgICAg ICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIg0KICAgICAgICAg ICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5xdWljQGlldGYub3JnPC9h Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgICA8Yj5TdWJqZWN0OjwvYj4gUmU6IFNwaW4g Yml0IGRpc2N1c3Npb24gLSB3aGVyZQ0KICAgICAgICAgICAgICAgICAgICAgIHdlJ3JlIGF0 PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg ICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PsKgPC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5TZWUgYmVsb3c6PG86cD48L286cD48L3A+DQogICAg ICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PGJyPg0KICAgICAgICAgICAgICAgICAgICBPbiAyNyBOb3YgMjAxNywgYXQgMTI6MzIs IFJvbGFuZCBaaW5rICZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Im1haWx0 bzpyb2xhbmRAemlua3MuZGUiDQogICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z ZW5kPSJ0cnVlIj5yb2xhbmRAemlua3MuZGU8L2E+Jmd0Ow0KICAgICAgICAgICAgICAgICAg ICB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg ICAgICAgICAgICA8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCiAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAg ICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05vcm1h bCI+QW0gMjcuMTEuMjAxNyB1bSAwODowMw0KICAgICAgICAgICAgICAgICAgICAgICAgc2No cmllYiBKYW5hIEl5ZW5nYXI6PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAg IDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8YmxvY2txdW90ZQ0KICAgICAgICAgICAg ICAgICAgICAgIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAg ICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhZGRpdGlvbiB0byBob3cgdGhlIHNwaW4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgYml0IGNhbiBiZSBkZXNpZ25lZCBhbmQgdXNlZCwg SSdkIGxpa2UgdGhvc2UNCiAgICAgICAgICAgICAgICAgICAgICAgICAgdGFraW5nIG9uIHRo aXMgZWZmb3J0IHRvIGNvbnNpZGVyIHRoaXMNCiAgICAgICAgICAgICAgICAgICAgICAgICAg cXVlc3Rpb246IFdoYXRldmVyIG5ldHdvcmsgbWFuYWdlbWVudCBwcm9ibGVtDQogICAgICAg ICAgICAgICAgICAgICAgICAgIHlvdSdyZSBjb25zaWRlcmluZyBzb2x2aW5nIHdpdGggYSBi aXQsIHdoYXQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgZG9lcyBpdCB0YWtlIHRvIHNv bHZlIHRoaXMgcHJvYmxlbSB3aXRob3V0IHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAg ICBiaXQgZXhwb3NlZD8gSSdtIGFza2luZyB5b3UgdG8gY29uc2lkZXINCiAgICAgICAgICAg ICAgICAgICAgICAgICAgInplcm8tYml0IiBzb2x1dGlvbnMsIG9yIGF0IGxlYXN0IGZvciBh DQogICAgICAgICAgICAgICAgICAgICAgICAgIGNvc3QvYmVuZWZpdCBhbmFseXNpcyBvZiBk ZXZlbG9waW5nIHNvbHV0aW9ucw0KICAgICAgICAgICAgICAgICAgICAgICAgICB3aXRoIGFu ZCB3aXRob3V0IHRoZSBzcGluIGJpdCBmb3Igc3BlY2lmaWMNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgbmV0d29yayBtYW5hZ2VtZW50IGZ1bmN0aW9ucy4gU3BlY2lmaWNhbGx5LCA8 bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAg ICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+wqA8L286cD48 L3A+DQogICAgICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAg ICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29O b3JtYWwiPihpKSBXaGF0J3MgaW1wb3NzaWJsZSBvcg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHZlcnkgZGlmZmljdWx0IHRvIGRvLCBmcm9tIGEgbmV0d29yaw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIG1hbmFnZW1lbnQgcGVyc3BlY3RpdmUsIG9mIG5vdCBoYXZp bmcgdGhlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgc3BpbiBiaXQ/IE5vdGUgdGhh dCBJJ20gbm90IGFza2luZyBmb3Igd2hhdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg IGlzIGFuZCBpcyBub3QgbWVhc3VyYWJsZSAtLSBub3QgZXZlcnl0aGluZw0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIG1lYXN1cmFibGUgaXMgdXNlZnVsLiBJJ20gc3BlY2lmaWNh bGx5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgYXNraW5nIGluIHRlcm1zIG9mIG5l dHdvcmsgbWFuYWdlbWVudA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZ1bmN0aW9u cywgaW4gcHJhY3RpY2UsIGFzIHVzZWQgYnkNCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICBvcGVyYXRvcnMuIFNvbWUgb2YgdGhpcyBoYXMgYmVlbiBhZGRyZXNzZWQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICBpbiB0aGUgZGlzY3Vzc2lvbnMvZHJhZnRzIEkndmUgc2Vl biwgYnV0IEkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGluayBpdCdzIG1vc3Qg dXNlZnVsIHdoZW4gZnJhbWVkIGluIHRlcm1zDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgb2YgbmV0d29yayBtYW5hZ2VtZW50IGZ1bmN0aW9ucy48bzpwPjwvbzpwPjwvcD4NCiAg ICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgIDwv ZGl2Pg0KICAgICAgICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAg ICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+SQ0KICAgICAgICAgICAgICAgICAgICAgIHdhbnQgdG8gZXhwcmVzcyB0aGUgcXVlc3Rp b24gYWJvdXQgbWFuYWdlYWJpbGl0eQ0KICAgICAgICAgICAgICAgICAgICAgIGZyb20gYSBk aWZmZXJlbnQgYW5nbGUuIFFVSUMgbW92ZXMgdGhlIGNvbmdlc3Rpb24NCiAgICAgICAgICAg ICAgICAgICAgICBjb250cm9sIGZyb20gYmVpbmcgYSBjb21tb24gZnVuY3Rpb25hbGl0eSBp biB0aGUNCiAgICAgICAgICAgICAgICAgICAgICBrZXJuZWwgdG8gYXBwbGljYXRpb24gZnVu Y3Rpb25hbGl0eS4gSXQgYWxzbyBoaWRlcw0KICAgICAgICAgICAgICAgICAgICAgIHRoZSBw cm90b2NvbCBoYW5kbGluZyBvZiBjb25nZXN0aW9uIGZyb20gdGhlDQogICAgICAgICAgICAg ICAgICAgICAgbmV0d29yay4gVGhpcyBnaXZlcyBpbmNlbnRpdmVzIGZvciBhcHBsaWNhdGlv bg0KICAgICAgICAgICAgICAgICAgICAgIGRldmVsb3BlcnMgdG8gY2hhbmdlIGNvbmdlc3Rp b24gY29udHJvbCB0byBnaXZlDQogICAgICAgICAgICAgICAgICAgICAgdGhlaXIgYXBwbGlj YXRpb24gYW4gYWR2YW50YWdlIG92ZXIgb3RoZXJzLiBObw0KICAgICAgICAgICAgICAgICAg ICAgIHNwZWNpYWwgcmlnaHRzIGFyZSBuZWNlc3NhcnkuIE5vdyB0aGUgcXVlc3Rpb24gaXMN CiAgICAgICAgICAgICAgICAgICAgICBkb2VzIFFVSUMgcHJvdmlkZSBlbm91Z2ggbWFuYWdl YWJpbGl0eSB0byBhdm9pZCBhbg0KICAgICAgICAgICAgICAgICAgICAgIEludGVybmV0IChv ciBzb21lIHBhcnQgb2YgaXQpIGJyZWFrZG93biB3aGVuIGl0IGlzDQogICAgICAgICAgICAg ICAgICAgICAgbWlzdXNlZD8gQ2FuIGl0IGJlIHNob3duIHRoYXQgdGhpcyBjYW4ndCBoYXBw ZW4/PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAg ICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB0aGluayB0aGlzIG1heSB0b3VjaCBvbiBzb21lIG9mDQogICAgICAgICAgICAg ICAgICB0aGUgdG9waWNzIGluOjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgIDxk aXY+DQogICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48YQ0KaHJlZj0i aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWZhaXJodXJzdC10c3Z3Zy10cmFu c3BvcnQtZW5jcnlwdC0wNCINCiAgICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNl bmQ9InRydWUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mYWlyaHVyc3Qt dHN2d2ctdHJhbnNwb3J0LWVuY3J5cHQtMDQ8L2E+PG86cD48L286cD48L3A+DQogICAgICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+wqA8L286cD48L3A+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAg ICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwi PkFsdGhvdWdoIHRoaXMgaXMgZm9jdXNzZWQgb24NCiAgICAgICAgICAgICAgICAgICAgICBp c3N1ZXMgd2lkZXIgdGhhbiBRdWljLCBJIHRoaW5rIHRoZSBwb2ludHMgeW91DQogICAgICAg ICAgICAgICAgICAgICAgcmFpc2UgYXJlIHJlbGV2YW50LiBUaGlzIHdhcyBwcmVzZW50ZWQg bGFzdA0KICAgICAgICAgICAgICAgICAgICAgIElFVEYtMTAwIGluIFRTVldHIGFuZCBJTlRB UkVBLiBXZSB3b3VsZCBhcHByZWNpYXRlDQogICAgICAgICAgICAgICAgICAgICAgaW5zaWdo dCwgYW5kIGNvbW1lbnRzIG9uIHRoaXMuIMKgKEkgYW0ganVzdCBhYm91dA0KICAgICAgICAg ICAgICAgICAgICAgIHRvIHB1c2ggbmV3IHZlcnNpb24gdG8gY29ycmVjdCB0eXBvcyEpPG86 cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAg ICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAg PG86cD48L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlDQogICAg ICAgICAgICAgICAgICAgICAgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv bTo1LjBwdCI+DQogICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAg ICAgICAgICAgIDxibG9ja3F1b3RlDQogICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxl PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj4o aWkpIFdoYXQgYXJlIHRoZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbHRl cm5hdGl2ZXMgZm9yIGJ1aWxkaW5nIHRoZSBzYW1lDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIGZ1bmN0aW9ucyB3aXRob3V0IHRoZSBzcGluIGJpdD8gTGV0J3MNCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgY29uc2lkZXIgZm9yIGEgbW9tZW50IHRoYXQg dGhlIHNwaW4gYml0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlzbid0IGFj dHVhbGx5IGF2YWlsYWJsZSBpbiBwcmFjdGljZS4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgV2hhdCB3aWxsIG9wZXJhdG9ycyBkbyB0byBjb250aW51ZQ0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBtYW5hZ2luZyB0aGVpciBuZXR3b3Jrcz8gVGhpcyBt aWdodCBiZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBleHBlbnNpdmUsIGJ1 dCB0aGF0J3MgcHJlY2lzZWx5IHdoYXQgSSdtDQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIGxvb2tpbmcgZm9yIC0tIHRoZSBjb3N0IHRvIG9wZXJhdG9ycyBvZg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBub3QgaGF2aW5nIHRoZSBzcGluIGJpdC4gRm9y IGluc3RhbmNlLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhY3RpdmUgcHJv YmVzIGFyZSBhIGZpbmUgd2F5IHRvIG1lYXN1cmUNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgbmV0d29yayBSVFQgd2l0aGluIG9wZXJhdG9yIG5ldHdvcmtzLA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBhbmQgdGhhdCBpcyBhbiBhbHRlcm5hdGl2ZS4g VGhlcmUgYXJlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN1cmVseSBvdGhl cnMgdG9vLiBUaGVpciBjb3N0cyBhbmQNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgbGltaXRhdGlvbnMgYXJlIGltcG9ydGFudCB0byBrbm93IGFib3V0DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIGluIG9yZGVyIHRvIHJlYXNvbiBhYm91dCB0aGVpcg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB2aWFiaWxpdHksIHNvIEknZCBsaWtl IHRvIHNlZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhbHRlcm5hdGl2ZXMg Y29uc2lkZXJlZC48bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAg ICAgICAgICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgICAgICA8 cCBjbGFzcz0iTXNvTm9ybWFsIg0KICAgICAgICAgICAgICAgICAgICAgICAgICBzdHlsZT0i bWFyZ2luLWJvdHRvbToxMi4wcHQiPlNvbHV0aW9ucyB0aGF0DQogICAgICAgICAgICAgICAg ICAgICAgICAgIG9ubHkgd29yayB3aXRoaW4gYW4gb3BlcmF0b3JzIG5ldHdvcmsgYXJlIG5v dA0KICAgICAgICAgICAgICAgICAgICAgICAgICBlbm91Z2ggd2hlbiBtb3JlIHRoYW4gb25l IG9wZXJhdG9yIGlzDQogICAgICAgICAgICAgICAgICAgICAgICAgIGludm9sdmVkLjxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAg ICAgICAgICA8L2Jsb2NrcXVvdGU+DQogICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPlllcywgYWxzbyB0cnVlLjxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAg ICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICAg ICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICA8ZGl2Pg0KICAgICAgICAgICAg ICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5Hb3JyeTxicj4NCiAgICAgICAgICAgICAg ICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgICAgPG86cD48L286cD48L3A+DQog ICAgICAgICAgICAgICAgICAgIDxibG9ja3F1b3RlDQogICAgICAgICAgICAgICAgICAgICAg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQogICAgICAg ICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgIDxibG9ja3F1 b3RlDQogICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8ZGl2 Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIGRvbid0IG1lYW4gdG8gc3RhcnQNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdGhlIGRpc2N1c3Npb24gb24gdGhpcyB0aHJlYWQsIGJ1dCBJJ2QN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgbGlrZSB0byB1cmdlIHRob3NlIGdv aW5nIG9mZiB0byBkbyB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgd3Jp dGluZyB0byBjb25zaWRlciB0aGVzZSBxdWVzdGlvbnMuPG86cD48L286cD48L3A+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgPGRpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+wqA8L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgPC9kaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gamFuYTxvOnA+ PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICA8 L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgPGRpdj4NCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPsKgPC9vOnA+PC9wPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxkaXY+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICA8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE5vdiAyNiwgMjAxNw0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBhdCAxMToyNiBBTSwgTU9SVE9OLCBB TEZSRUQgQyAoQUwpICZsdDs8YQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IGhyZWY9Im1haWx0bzphY21vcnRvbkBhdHQuY29tIg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiPmFj bW9ydG9uQGF0dC5jb208L2E+Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IDxibG9ja3F1b3RlDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBjbSI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJN c29Ob3JtYWwiDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgc3R5bGU9Im1h cmdpbi1ib3R0b206MTIuMHB0Ij5IaSBCcmlhbiwNCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBTdGVwaGVuLCBMYXJzLCBNYXJrIGFuZCBhbGwsPGJyPg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBvbmUgam9pbiwgb25lIHN1Z2dlc3Rpb24sIGFuZCBvbmUNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBxdWVzdGlvbiBiZWxvdy48YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgc2VlIFtBQ01dPGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICZndDsgLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBGcm9tOiBRVUlD IFttYWlsdG86PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9 Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPnF1aWMtYm91bmNlc0BpZXRm Lm9yZzwvYT5dDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgT24gQmVoYWxm IE9mIEJyaWFuIFRyYW1tZWxsPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICZndDsgKElFVEYpPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZndDsgU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyMiwNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAyMDE3IDU6NTkgQU08YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyBUbzogRWdnZXJ0LCBMYXJzPGJyPg0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICZndDsgQ2M6IE1hcmsgTm90dGluZ2hhbTsgUVVJQyBX RzsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTdGVwaGVuIEZhcnJlbGw8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBTdWJqZWN0OiBS ZTogU3BpbiBiaXQgZGlzY3Vzc2lvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIC0gd2hlcmUgd2UncmUgYXQ8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0Ozxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7 IGhpIExhcnMsPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDs8 YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyAmZ3Q7IE9uIDIy IE5vdiAyMDE3LCBhdCAxMTozNSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBFZ2dlcnQsIExhcnMgJmx0OzxhDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBocmVmPSJtYWlsdG86bGFyc0BuZXRhcHAuY29tIg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5sYXJzQG5ldGFwcC5j b208L2E+Jmd0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdyb3RlOjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7ICZndDs8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyAmZ3Q7IEhpLDxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7ICZndDs8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyAmZ3Q7IE9uIDIwMTctMTEtMjIsIGF0 IDExOjAxLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFN0ZXBoZW4gRmFy cmVsbCAmbHQ7PGENCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhyZWY9 Im1haWx0bzpzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllIg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5zdGVwaGVuLmZhcnJl bGxAY3MudGNkLmllPC9hPiZndDs8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgJmd0OyAmZ3Q7Jmd0OyBXaGF0IEkgdGhvdWdodCB3YXMgYmVpbmcNCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICByZXF1ZXN0ZWQgYW5kIHdoYXQgSSBkbyB0aGluayBp cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYXNvbmFibGU8YnI+DQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyAmZ3Q7Jmd0OyBpcyB0byBk b2N1bWVudCBhIHByaXZhY3kNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBh bmFseXNpcyBmb3IgYW55IHF1aWMgcHJvdG9jb2wgYml0cw0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHRoYXQgYXJlPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICZndDsgJmd0OyZndDsgdmlzaWJsZSB0byB0aGUgcGF0aC4NCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBXaGV0aGVyIG9yIG5vdCBzb21lIG9yIGFsbCBv ZiB0aGF0DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGV4dCBlbmRzIHVw PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgJmd0OyZndDsg aW4gc29tZSBSRkMgaXMgYW5vdGhlcg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGRheSdzIHdvcmsuPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICZndDsgJmd0OyBMYXJzIHdyb3RlOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAmZ3Q7ICZndDsgZm9yIHRoZSBTcGluIEJpdA0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHNwZWNpZmljYWxseSwgdGhlIGludGVudCB3YXMgdG8NCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwZXJtYW5lbnRseSBjYXB0dXJlPGJyPg0K ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgdGhlIGFuYWx5c2lzIHRo ZSBEVCBoYXMgZG9uZSwgc28NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0 aGF0IHdoZW4gb3RoZXJzIHJldmlldyB0aGUgcHJvcG9zZWQ8YnI+DQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgJmd0OyBTcGluIEJpdCBzcGVjaWZpY2F0aW9uLCB0aGV5 IGNhbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRha2UgdGhhdCBhcyBh IGdpdmVuIGFuZCBkaXJlY3QgYW55PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICZndDsgZnVydGhlciBhbmFseXNpcyB0byBvdGhlcg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGFzcGVjdHMuIEl0IG1hZGUgc2Vuc2UgdG8gdGhlIGNoYWly cw0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHRoYXQgdGhhdDxicj4NCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IHNwZWNpZmljIGFuYWx5c2lz IHNob3VsZCBiZWNvbWUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBwYXJ0 IG9mIHRoZSBTcGluIEJpdCBzcGVjaWZpY2F0aW9uLiBJPGJyPg0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICZndDsgdGhpbmsgd2UnZCBiZSBvcGVuIHRvIGENCiAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBkaXNjdXNzaW9uIG9uIHdoZXRoZXIgYSBi cm9hZGVyDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZG9jdW1lbnQ8YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBhbmFseXppbmcgdGhl IFFVSUMgd2lyZSBpbWFnZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHdv dWxkIGJlIGEgYmV0dGVyIGhvbWUgZm9yIHRoaXMuIFRoZQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIG1haW48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyBwb2ludCBpcyBmb3IgdGhlIHdvcmsgdGhhdCB0aGUgRFQNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBoYXMgZG9uZSB0byBiZSBkb2N1bWVudGVkLjxi cj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBCcmlhbiB3cm90ZTo8YnI+DQogICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBPa2F5LiBUaGF0J3Mgc29tZXdoYXQg bW9yZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHJlYXNvbmFibGUgdGhh biB3aGF0IEkgcmVhZCB0aGUgYXNrIHRvDQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgYmU8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyAo IndlJ3JlIGdvaW5nIHRvIGdhdGUgdGhpcyBvbiB0aGUNCiAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICBwZW9wbGUgd2hvIGNhcmUgYWJvdXQgdGhpcyBkb2luZyBzb21lPGJy Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgbm9uLXRyaXZpYWwg YW1vdW50IG9mIHdvcmsiKS4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBU aG9zZSBvZiB1cyB3aG8gdm9sdW50ZWVyIChoZWxwLA0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHBsZWFzZSw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJmd0OyBhbnlvbmU/IDopICkgY2FuIGNlcnRhaW5seSBwdWxsDQogICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgdG9nZXRoZXIgd2hhdCB3ZSBoYXZlIGluIGEgc2lu Z2xlIEktRDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7IGFu ZCBhc2sgdGhlIFdHIHdoYXQgbW9yZSBpdA0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHRoaW5rcyBpdCBuZWVkcy4gVG8gbWUgYWxsIHRoaXMgc2VlbXMNCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBwcmV0dHk8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJmd0OyBjbGVhciwgYnV0IEkndmUgYmVlbiB3b3JraW5nIG9u DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdGhpcyB0b3BpYyBmb3IgYSB3 aGlsZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgW0FDTV08YnI+ DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSGF2aW5nIHJlYWNoZWQgdGhl IGVuZCBvZiB0aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAiVGhhbmtz Z2l2aW5nIHRocmVhZCIsPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IEknbSBzY3JvbGxpbmcgYmFjayBhIGZldyBwYWdlcyB0byBqb2luDQogICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgdGhlIHRhc2sgb2Y8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgcGVybWFuZW50bHkgY2FwdHVyaW5nIHRoZSB3b3JrIG9mIHRo ZQ0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIERUIGluIGFuIEktRCAoYXQg bGVhc3QpOjxicj4NCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBUaGVyZSBz aG91bGQgYmUgbGFzdGluZyB2YWx1ZSBpbiBzb21lDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgb2Ygb3VyIGZpbmRpbmdzPGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGFuZCBJTU8gdGhleSBhcmUgd29ydGh5IG9mIGENCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICBwZXJzaXN0ZW50IHJlZmVyZW5jZS48YnI+DQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICZndDsgTGFycyB3cm90ZTo8YnI+DQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgJmd0OyAmZ3Q7IEZvciBwcm9wb3NhbHMgb3RoZXIgdGhhbiB0 aGUNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBTcGluIEJpdCAoSSB0aGlu ayBJIGhhdmUgc2Vlbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGluZGl2 aWR1YWw8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJmd0OyBjb250 cmlidXRvcnMgYXQgbGVhc3QgbWVudGlvbg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICJsb3NzIiBhbmQgImNvbmdlc3Rpb24iIGJpdHMsIGJ1dA0KICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHdpdGhvdXQ8YnI+DQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgJmd0OyBtdWNoIGRldGFpbCksIHdlIHdhbnRlZCB0bw0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNsYXJpZnkgdGhhdCB3ZSdkIGxpa2UgdG8g c2VlIGFuDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYW5hbHlzaXMgYW5k PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZndDsgZGlzY3Vzc2lv biBvZiB0aGVpciBwcml2YWN5DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg YXNwZWN0cyB0byByb3VnaGx5IHRoZSBzYW1lIGRlZ3JlZSBhcw0KICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHRoZSBEVDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAmZ3Q7IGhhcyBwZXJmb3JtZWQgZm9yIHRoZSBTcGluIEJpdA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByb3Bvc2FsLjxicj4NCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAmZ3Q7PGJyPg0KICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIFtBQ01dPGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIEkgc3VnZ2VzdCB0aGF0IHRoaXMgbWlnaHQgYmUgYQ0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIGRpZmZlcmVudCBJLUQsIGF0IGxlYXN0IHRvIHN0YXJ0Ljxicj4N CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBRdWVzdGlvbjogSXMgdGhlcmUg YSBwcml2YWN5IGFuYWx5c2lzDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg b2YgcHJlc2VudCBFQ04gYXZhaWxhYmxlPzxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAoYSBzZWFyY2ggeWllbGRlZCBtYW55IHJlc3VsdHMgd2l0aA0KICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIE1pc3Npbmc6IHByaXZhY3kpPGJyPg0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICByZWdhcmRzLDxicj4NCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICBBbDxvOnA+PC9vOnA+PC9wPg0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2 Pg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgIDxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+wqA8L286cD48L3A+DQogICAgICAgICAgICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAg ICAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3RlPg0KICAgICAgICAgICAgICAgICAg ICAgICAgPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD7CoDwvbzpwPjwvcD4NCiAgICAgICAg ICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAgICAgICAgICAgICAgICAgPC9ibG9ja3F1b3Rl Pg0KICAgICAgICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgICAgICAgPC9kaXY+DQog ICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgPC9kaXY+DQogICAgICAgICAgPC9i bG9ja3F1b3RlPg0KICAgICAgICAgIDxicj4NCiAgICAgICAgPC9kaXY+DQogICAgICA8L2Js b2NrcXVvdGU+DQogICAgPC9ibG9ja3F1b3RlPg0KICAgIDxicj4NCiAgPC9ib2R5Pg0KPC9o dG1sPg0K --------------8E591EB1C3F5AC06DF4B4884-- From nobody Mon Nov 27 10:02: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 C8C851292AE for ; Mon, 27 Nov 2017 10:02:44 -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_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 ohHmpmpaDgZM for ; Mon, 27 Nov 2017 10:02:43 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 22C0D1242F5 for ; Mon, 27 Nov 2017 10:02:43 -0800 (PST) Received: from xsmtp06.mail2web.com ([168.144.250.232]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eJNjn-0005MU-5R for quic@ietf.org; Mon, 27 Nov 2017 19:02:40 +0100 Received: from [10.5.2.31] (helo=xmail09.myhosting.com) by xsmtp06.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eJNjh-0002Sh-PE for quic@ietf.org; Mon, 27 Nov 2017 13:02:30 -0500 Received: (qmail 17137 invoked from network); 27 Nov 2017 18:02:28 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.196]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 27 Nov 2017 18:02:28 -0000 To: Roland Zink Cc: Ingemar Johansson S , "Gorry (erg)" , "quic@ietf.org" References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@erg.abdn.ac.uk> <74e1c7bd-bd09-3285-db25-db04fe530cbc@zinks.de> <34BF55EB-8B3E-453C-BAFE-8048B4B94FC5@huitema.net> <54e419d4-e4c0-2e9e-93ab-6ff7750e483a@zinks.de> From: Christian Huitema Message-ID: Date: Mon, 27 Nov 2017 10:02:27 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <54e419d4-e4c0-2e9e-93ab-6ff7750e483a@zinks.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Spin bit discussion - where we're at X-Originating-IP: 168.144.250.232 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.36) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5ubWwQ2pWfMpO88DUbgSUF4Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftE11/PCFSx1UWGMEEU5QN+B98yDTitFWvbHwz9vKZpm2Ea bzmM/1VynIZUVImbQiuZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA8yXDZ4EHnDt87IyrZAC2/gfn4eyCwIWdDDlFG98+9qd+BFwYDEPnet1tXHsknHYhhwbzpt P1hS4Kj7E/EWE1j8sESBnZ29929fqpFFzBN0ceyPnEGyyfS0ggcDdodDMKpYg9ruAKOoPnwmy4wG 8XtJqWVYNxS4myu1gxnHJBnmumz49PzUWhdE3zEeQF2k5bdHrh2h0Pu50H7NzHw6NK3VYL8jvyeW A9EsRvV6CqjePBKOhcObZXWnkEw+6F9CGyYW9UNFgzCqKDXesOntN1zD9IUJ5y4fZBwzmfWaECTh P09/1ofiVSCviHIcZr6c+k7GvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kATyzYT8K6rd4RA3UMT6Em/UONoJfh+XjGSeeT90H/uIF4 3e4BaCuF1nhDkrEU4J+LSp9pt+SCE2Wdi6aIMChKbmbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW/a7J4lI9dq2HBFg+iT3zKvfFcHV2tQAVqGdj/zM7G/H0fgN5y0tqqfuQuS1mj2Wr5ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 18:02:45 -0000 On 11/27/2017 9:36 AM, Roland Zink wrote: > If QUIC makes the problem crystal clear then now seems to be a good > time to solve or mitigate it before risking it becomes a real world > problem. First, let's start by agreeing that this is not a problem specific QUIC. You could say the same about Bit Torrent, any protocol that sends video over UDP, or any application that opens multiple TCP connection. So, yes, there may well be a problem, but since it is not specific to QUIC the mitigation does not have to be specific to QUIC either. But let's not panic. Practical mitigation has started long ago, with ISPs effectively controlling how much data can be sent through a customer's up-link. Maybe these current mitigations are not sufficient, but if that is the case I would expect more work on better queue management algorithm. -- Christian Huitema From nobody Mon Nov 27 10:30: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 65CE7129353 for ; Mon, 27 Nov 2017 10:30:41 -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 ud3Nut5q2Byx for ; Mon, 27 Nov 2017 10:30:39 -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 671A31272E1 for ; Mon, 27 Nov 2017 10:30:39 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id c123so23317719qkf.7 for ; Mon, 27 Nov 2017 10:30:39 -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=tACeR/e5YOgMCxqlHVAyWTHY9aZFt5TC52txKyBrVZM=; b=C9jvewxU7K3w7O5g5xyxQJBv0sZvrTO8xw6KYQDS6LCP7rkvV/FNCG/ox49RfLhMRS asvz4IK3cAa9u0pWivQCeaHWwN4rgs7p0hnWKVqe5MWbCzAR7v072kAga2Or3V6CZFqC qfVyQhcrXFI33YqSIMt5YHfxsPgxnJY30DDx4laFYE9AJBDIxb7aLl5/pyFwnuWv0eXS AEJ10x9kvSEfPoNxNArW0vtISLCBO/AJuOrXgeYOtdUopkc1aXX+YFH1fSol4bqL2fIo G3GIIWMZWjmvoFOwped0cNID/HcbRRLNcLFWyRkjnBbRo10+n2xnk5r0fvErdKTAXH6Z AzVg== 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=tACeR/e5YOgMCxqlHVAyWTHY9aZFt5TC52txKyBrVZM=; b=lIxJq9ke1Bk90sVLyjpnN4+QnzQJLjCIHZLRRBSmg26TI1O+sSirwDktmXNrMUs5C1 iT1DXtrf/SgsEwpbpC4UE9ooNHACQvy/UCJFKboMdiMkycQt+2i+EfUuypepSKTceaqx UgxTxXd8U2NKVeEOzMKkbI3akGut3rZXx7pYjNl/zPQr2Ks+QvUfW4JkUULd79aScvgT pbsRFjLTsE9XYBG0GBL34f+7kl5gCBStDlFIWpXeD9QWQx3DZXaiX3E/9TnlPzSqnh7d oNJ8SIOa9m7Ct2RV1dRe9B1D9S8DomhQSixhVlpCdcjp8gn0ZRHFg3GPtXEkgESlTFzX 0h6g== X-Gm-Message-State: AJaThX5nxxqSMV7+5G7ecqGcQ7mPJ6Eh3fYEkX9H0/B6AD2f//V7IZ/P DsWaT7kFm+fyylJl/XuuAKHuoAndXPHvu1DXayO1oA== X-Google-Smtp-Source: AGs4zMYIpvZEU4eUfw0dB1HQ3ixItNupEySwCc6Q22SSqIv+kpyvtUpStudPRyIUTugWJr61JIV0KGDXuqGHLZQ61o0= X-Received: by 10.55.60.12 with SMTP id j12mr46759248qka.232.1511807438344; Mon, 27 Nov 2017 10:30:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.169 with HTTP; Mon, 27 Nov 2017 10:30:07 -0800 (PST) In-Reply-To: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> From: Ted Hardie Date: Mon, 27 Nov 2017 10:30:07 -0800 Message-ID: Subject: Re: Spin bit discussion - where we're at To: Jana Iyengar Cc: "MORTON, ALFRED C (AL)" , "Brian Trammell (IETF)" , Mark Nottingham , QUIC WG , "Eggert, Lars" , Stephen Farrell Content-Type: multipart/alternative; boundary="001a114a125654d7e5055efb1950" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 18:30:41 -0000 --001a114a125654d7e5055efb1950 Content-Type: text/plain; charset="UTF-8" Howdy, On Sun, Nov 26, 2017 at 11:03 PM, Jana Iyengar wrote: > In addition to how the spin bit can be designed and used, I'd like those > taking on this effort to consider this question: Whatever network > management problem you're considering solving with a bit, what does it take > to solve this problem without the bit exposed? I'm asking you to consider > "zero-bit" solutions, or at least for a cost/benefit analysis of developing > solutions with and without the spin bit for specific network management > functions. Specifically, > > (i) What's impossible or very difficult to do, from a network management > perspective, of not having the spin bit? Note that I'm not asking for what > is and is not measurable -- not everything measurable is useful. I'm > specifically asking in terms of network management functions, in practice, > as used by operators. Some of this has been addressed in the > discussions/drafts I've seen, but I think it's most useful when framed in > terms of network management functions. > > (ii) What are the alternatives for building the same functions without the > spin bit? Let's consider for a moment that the spin bit isn't actually > available in practice. What will operators do to continue managing their > networks? This might be expensive, but that's precisely what I'm looking > for -- the cost to operators of not having the spin bit. For instance, > active probes are a fine way to measure network RTT within operator > networks, and that is an alternative. There are surely others too. Their > costs and limitations are important to know about in order to reason about > their viability, so I'd like to see alternatives considered. > I think the trade-offs here are harder to assess than this request implies. Let's imagine, for a moment, that the operator chooses to use the coloring methods described in https://datatracker.ietf.org/doc/draft-ietf-ippm-alt-mark . There are clearly expenses required for this and those might be higher than the expenses for analyzing a QUIC-marked spin bit (with some variation, depending on whether you do or don't require synchronization). But the other side of the assessment is the privacy assessment of this method. If an operator begins using this method, the very nature of the packet coloring exposes the same data as the QUIC-marked spin bit does (and a bit more because of the countable packet sets in flights). Unless the replacement measurement uses purely synthetic flows, in other words, it will also have privacy implications and, potentially, performance implications. Asking for a full-field analysis of all the options here is not a reasonable task, at least in my opinion. I think the best we can realistically do is compare this against nothing (no bit and not replacement effort), against synthetic flows (a.k.a. active measurements), and against one or two systems either already deployed or fully described. > I don't mean to start the discussion on this thread, but I'd like to urge > those going off to do the writing to consider these questions. > > While I am happy to consider the questions, I hope you are equally happy to bound the universe of "alternatives for the same function" to be considered. Without doing so now, we run the risks of the goalposts receding ever out of sight. regards, Ted > - jana > > > On Sun, Nov 26, 2017 at 11:26 AM, MORTON, ALFRED C (AL) > wrote: > >> Hi Brian, Stephen, Lars, Mark and all, >> >> one join, one suggestion, and one question below. >> see [ACM] >> > -----Original Message----- >> > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell >> > (IETF) >> > Sent: Wednesday, November 22, 2017 5:59 AM >> > To: Eggert, Lars >> > Cc: Mark Nottingham; QUIC WG; Stephen Farrell >> > Subject: Re: Spin bit discussion - where we're at >> > >> > hi Lars, >> > >> > > On 22 Nov 2017, at 11:35, Eggert, Lars wrote: >> > > >> > > Hi, >> > > >> > > On 2017-11-22, at 11:01, Stephen Farrell >> > wrote: >> > >> What I thought was being requested and what I do think is reasonable >> > >> is to document a privacy analysis for any quic protocol bits that are >> > >> visible to the path. Whether or not some or all of that text ends up >> > >> in some RFC is another day's work. >> > > Lars wrote: >> > > for the Spin Bit specifically, the intent was to permanently capture >> > the analysis the DT has done, so that when others review the proposed >> > Spin Bit specification, they can take that as a given and direct any >> > further analysis to other aspects. It made sense to the chairs that that >> > specific analysis should become part of the Spin Bit specification. I >> > think we'd be open to a discussion on whether a broader document >> > analyzing the QUIC wire image would be a better home for this. The main >> > point is for the work that the DT has done to be documented. >> >> > Brian wrote: >> > Okay. That's somewhat more reasonable than what I read the ask to be >> > ("we're going to gate this on the people who care about this doing some >> > non-trivial amount of work"). Those of us who volunteer (help, please, >> > anyone? :) ) can certainly pull together what we have in a single I-D >> > and ask the WG what more it thinks it needs. To me all this seems pretty >> > clear, but I've been working on this topic for a while. >> [ACM] >> Having reached the end of the "Thanksgiving thread", >> I'm scrolling back a few pages to join the task of >> permanently capturing the work of the DT in an I-D (at least): >> There should be lasting value in some of our findings >> and IMO they are worthy of a persistent reference. >> >> > Lars wrote: >> > > For proposals other than the Spin Bit (I think I have seen individual >> > contributors at least mention "loss" and "congestion" bits, but without >> > much detail), we wanted to clarify that we'd like to see an analysis and >> > discussion of their privacy aspects to roughly the same degree as the DT >> > has performed for the Spin Bit proposal. >> > >> [ACM] >> I suggest that this might be a different I-D, at least to start. >> Question: Is there a privacy analysis of present ECN available? >> (a search yielded many results with Missing: privacy) >> >> regards, >> Al >> >> > --001a114a125654d7e5055efb1950 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Howdy,

On Sun, Nov 26, 2017 at 11:03 PM, Jana Iyengar <jri@google= .com> wrote:
In addition to how the spin bit can be designed and u= sed, I'd like those taking on this effort to consider this question: Wh= atever network management problem you're considering solving with a bit= , what does it take to solve this problem without the bit exposed? I'm = asking you to consider "zero-bit" solutions, or at least for a co= st/benefit analysis of developing solutions with and without the spin bit f= or specific network management functions. Specifically,

= (i) What's impossible or very difficult to do, from a network managemen= t perspective, of not having the spin bit? Note that I'm not asking for= what is and is not measurable -- not everything measurable is useful. I= 9;m specifically asking in terms of network management functions, in practi= ce, as used by operators. Some of this has been addressed in the discussion= s/drafts I've seen, but I think it's most useful when framed in ter= ms of network management functions.

(ii) What are = the alternatives for building the same functions without the spin bit? Let&= #39;s consider for a moment that the spin bit isn't actually available = in practice. What will operators do to continue managing their networks? Th= is might be expensive, but that's precisely what I'm looking for --= the cost to operators of not having the spin bit. For instance, active pro= bes are a fine way to measure network RTT within operator networks, and tha= t is an alternative. There are surely others too. Their costs and limitatio= ns are important to know about in order to reason about their viability, so= I'd like to see alternatives considered.
=
I think the trade-offs here are harder to assess than this r= equest implies.=C2=A0 Let's imagine, for a moment, that the operator ch= ooses to use the coloring methods described in https://datatracker.ietf.org/doc/= draft-ietf-ippm-alt-mark .=C2=A0 There are clearly expenses required fo= r this and those might be higher than the expenses for analyzing a QUIC-mar= ked spin bit (with some variation, depending on whether you do or don't= require synchronization).=C2=A0 But the other side of the assessment is th= e privacy assessment of this method.=C2=A0 If an operator begins using this= method, the very nature of the packet coloring exposes the same data as th= e QUIC-marked spin bit does (and a bit more because of the countable packet= sets in flights).

Unless the replacement measurem= ent uses purely synthetic flows, in other words, it will also have privacy = implications and, potentially, performance implications.=C2=A0=C2=A0=C2=A0 = Asking for a full-field analysis of all the options here is not a reasonabl= e task, at least in my opinion.=C2=A0 I think the best we can realistically= do is compare this against nothing (no bit and not replacement effort), ag= ainst synthetic flows (a.k.a. active measurements), and against one or two = systems either already deployed or fully described.

I don't mean to start the discussion on this thread, but I= 'd like to urge those going off to do the writing to consider these que= stions.


While I am happy to consider the questions, I hope you are equally ha= ppy to bound the universe of "alternatives for the same function"= to be considered.=C2=A0 Without doing so now, we run the risks of the goal= posts receding ever out of sight.

regards,

Ted

=C2=A0
- ja= na


On Sun, Nov 26, 2017 at 11:= 26 AM, MORTON, ALFRED C (AL) <acmorton@att.com> wrote:
Hi Brian, Stephen, Lars, Mar= k and all,

one join, one suggestion, and one question below.
see [ACM]
> -----Original Message-----
> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell
> (IETF)
> Sent: Wednesday, November 22, 2017 5:59 AM
> To: Eggert, Lars
> Cc: Mark Nottingham; QUIC WG; Stephen Farrell
> Subject: Re: Spin bit discussion - where we're at
>
> hi Lars,
>
> > On 22 Nov 2017, at 11:35, Eggert, Lars <lars@netapp.com> wrote:
> >
> > Hi,
> >
> > On 2017-11-22, at 11:01, Stephen Farrell <stephen.farrell@cs.tcd.ie>= ;
> wrote:
> >> What I thought was being requested and what I do think is rea= sonable
> >> is to document a privacy analysis for any quic protocol bits = that are
> >> visible to the path. Whether or not some or all of that text = ends up
> >> in some RFC is another day's work.
> > Lars wrote:
> > for the Spin Bit specifically, the intent was to permanently capt= ure
> the analysis the DT has done, so that when others review the proposed<= br> > Spin Bit specification, they can take that as a given and direct any > further analysis to other aspects. It made sense to the chairs that th= at
> specific analysis should become part of the Spin Bit specification. I<= br> > think we'd be open to a discussion on whether a broader document > analyzing the QUIC wire image would be a better home for this. The mai= n
> point is for the work that the DT has done to be documented.

> Brian wrote:
> Okay. That's somewhat more reasonable than what I read the ask to = be
> ("we're going to gate this on the people who care about this = doing some
> non-trivial amount of work"). Those of us who volunteer (help, pl= ease,
> anyone? :) ) can certainly pull together what we have in a single I-D<= br> > and ask the WG what more it thinks it needs. To me all this seems pret= ty
> clear, but I've been working on this topic for a while.
[ACM]
Having reached the end of the "Thanksgiving thread",
I'm scrolling back a few pages to join the task of
permanently capturing the work of the DT in an I-D (at least):
There should be lasting value in some of our findings
and IMO they are worthy of a persistent reference.

> Lars wrote:
> > For proposals other than the Spin Bit (I think I have seen indivi= dual
> contributors at least mention "loss" and "congestion&qu= ot; bits, but without
> much detail), we wanted to clarify that we'd like to see an analys= is and
> discussion of their privacy aspects to roughly the same degree as the = DT
> has performed for the Spin Bit proposal.
>
[ACM]
I suggest that this might be a different I-D, at least to start.
Question: Is there a privacy analysis of present ECN available?
(a search yielded many results with Missing: privacy)

regards,
Al



--001a114a125654d7e5055efb1950-- From nobody Mon Nov 27 11:22: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 1A4F8126BFD for ; Mon, 27 Nov 2017 11:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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=evequefou.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 9sUkZZLA8Tyg for ; Mon, 27 Nov 2017 11:22:27 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0121.outbound.protection.outlook.com [104.47.38.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 890D51242F5 for ; Mon, 27 Nov 2017 11:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=evequefou.onmicrosoft.com; s=selector1-evequefou-be; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MzPnXP6NZYs9cgF2IlXmu3HwQCGaBrfFF1L3vxhhxsQ=; b=JPNIMybBrM8J6yw94zB6Udxz9MmIpuYyoA27lB3rnxxMyPhK2H8cU4tMlzKBtgUr8wxVk9/7rGP33bdmMi+Bgops5/N9rMtHC9gGB4gRyWjRVk6pSf8F2qHdvJ638slbl0ViuS5H2PpkYfOeCOK544vQ0PMiGicpR0AfrSMMeKA= Received: from MWHPR08MB2432.namprd08.prod.outlook.com (10.169.203.136) by MWHPR08MB2431.namprd08.prod.outlook.com (10.169.203.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Mon, 27 Nov 2017 19:22:21 +0000 Received: from MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) by MWHPR08MB2432.namprd08.prod.outlook.com ([10.169.203.136]) with mapi id 15.20.0260.006; Mon, 27 Nov 2017 19:22:21 +0000 From: Mike Bishop To: fish fish , "quic@ietf.org" Subject: RE: Questions about QUIC server reset issues Thread-Topic: Questions about QUIC server reset issues Thread-Index: AQHTY2NOIuOT5Z2DzEWeZataMujXiKMoonPw Date: Mon, 27 Nov 2017 19:22:21 +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=mbishop@evequefou.be; x-originating-ip: [38.134.241.6] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR08MB2431; 6:Phh0dbMUIom+VzCqrWhcjFsZ9iIUfb0eENBH1ON3jwV16t+foUhndmvfsKtrgBH99Axiffho+HRUJracLGU1HgoUc5PLjd9EA6+61NdbcWfbitfF0ZxMhFKXlKJaqh1lmZfMBa5Gb/zxYLNXf01l/+pC+d7nyK7Ix7H3PquqNApx/GQZKTt/uqTJU05qewsZh1JLOMtZKruh/WNLCBYv0lNBwwbwy+fcODmMyZoDScVMQW2G+jMm3MjP8mAp5dMGIPF3iAxCsXal3Fv/rfrmRxaIK1ezzmME3KyDsTkupTukgfYhJvbNxU4yCY3cYx2xtyvHIg+Ky7CzW8JsW/YIItNoWMIhRZXObuiomIPN8CE=; 5:Wv7wSbMMtvtoMpTZDJAzm9lajuiUhtcCtym3PNYx/QWN4x6R1QWuqaQCtiQPHApi4hxhpjRWtZwCYOzrVbc8bcRJ5JGFR2y4n5yuMyoYjtV+Sspmq9VcQOacSTTCZ3FpeQeQNEZnz7OeRHwrhGNNqipmiQz9UK23wQY2qjjEQv0=; 24:vyI0HCEw2MkULTDG3IxW44pB/W1O0qvVwnnaYuklkAz4VOsMUwkqiIP++ECutLOcK6giEoh8hgy66D5a3QH+CtdRfIchoi4UcbJL1vhuNsk=; 7:FnfRA8aIN0VUI5HnZqO+qSebBiRwyx1QySQPHKxXSR2TNWCJIZLcvxxVLa0PFdlwMluulhDJe25xx6V4Kyll22BvX6q8RrnAdElvc8DiDa08aFyah+EHttPsHi1Ig+VLJtzRx/hVvwSPi4SOueu0FCveVK1CguME91SZi8ACCczkpS0DI7iMJqLglqO3iGjdkw4XYLVQDgPzEDXXRGa99Ja6yUPUDwmh0oUqOdp/E74J5PnyUxEsZjOhp7JZ/Rg7 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1b7807a0-a5c7-4177-525b-08d535cc2ec7 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4603075)(4627115)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:MWHPR08MB2431; x-ms-traffictypediagnostic: MWHPR08MB2431: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(190756311086443)(158342451672863)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(3231022)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123560025)(20161123562025)(20161123564025)(2016111802025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6043046)(6072148)(201708071742011); SRVR:MWHPR08MB2431; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:MWHPR08MB2431; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(39830400002)(366004)(51874003)(199003)(189002)(74316002)(105586002)(7736002)(54356999)(50986999)(101416001)(97736004)(6436002)(76176999)(77096006)(8676002)(81156014)(2906002)(81166006)(2900100001)(229853002)(6506006)(790700001)(53936002)(54896002)(102836003)(9686003)(189998001)(3280700002)(6306002)(3660700001)(3846002)(74482002)(2950100002)(6246003)(55016002)(5660300001)(25786009)(39060400002)(66066001)(2501003)(68736007)(110136005)(53546010)(316002)(33656002)(6116002)(99286004)(106356001)(478600001)(14454004)(4743002)(86362001)(7696005)(8936002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR08MB2431; H:MWHPR08MB2432.namprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: evequefou.be does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR08MB2432BDCBC7552D5B5F741C59DA250MWHPR08MB2432namp_" MIME-Version: 1.0 X-OriginatorOrg: evequefou.be X-MS-Exchange-CrossTenant-Network-Message-Id: 1b7807a0-a5c7-4177-525b-08d535cc2ec7 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2017 19:22:21.5802 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 41eaf50b-882d-47eb-8c4c-0b5b76a9da8f X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR08MB2431 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 19:22:30 -0000 --_000_MWHPR08MB2432BDCBC7552D5B5F741C59DA250MWHPR08MB2432namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think what you're describing is a handoff from one server instance to ano= ther. The intent with the Connection ID is that packets can be routed back= to the server instance that already has the correct state to deal with the= m; if two server instances wanted to hand off that state between them to re= duce their routing load, that seems like an internal decision that would be= transparent to QUIC. If the servers have different IP:port endpoints, how= ever, that would look to the client like a server-side connection migration= . I don't know whether that has been explicitly deemed in or out of scope = at this point. For the Stateless Reset question, you'll need to be more specific: what ar= e you trying to solve? From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of fish fish Sent: Tuesday, November 21, 2017 11:27 PM To: quic@ietf.org Subject: Questions about QUIC server reset issues Respected, I am Siyu Yang from Tsinghua University in Beijing, China. I am a mast= er candidate student interested in the transportation layer of satellite ne= tworks ( LEO/MEO/GEO ) using QUIC. Previously I have done an experiment building QUIC server and clients = in a simulated satellite network environment. It turns out that QUIC/UDP pe= rforms much better than TCP/IP structure because of the reduced handshake R= TTs and congestion control strategies. After reading Google's paper on QUIC in sigcomm 2017, would you please= tell me more about updates of quic's server stateless reset strategies? An= y solution if possible to solve? And I am also interested in QUIC cooperation with CDN in such a workin= g case: mobile clients may apply for another CDN server when they are brows= ing using QUIC, if it is possible that a connection between CDN server A an= d the next CDN server B, the server A would send the related users' authen= tication info in service (users' public key and A's public key so that B = would not reject the clients' requests though it is probably the first time= that these clients seek for connection to B so that one-RTT saved in this = "new" connection) to the server B if A knows that B would take over A to se= rve the clients ? I might not be a very common phenomenon in terrestrial networks ... I could= think out one that: a CDN incremental deployment that the newly establish= ed CDN server might "inherit" users' authentication from its neighbor serve= rs. But it could be a common phenomenon happening every few hours/days in satel= lite networks if we deploy a set of CDN servers for example in a MEO satell= ite networks which could cover the whole world with a couple of satellites.= Some MEO-constellations has a good properties that the relative locations = within these satellites does not change, just like constellations we observ= e in sky. In this time, the CDN servers serve one client in order and the n= ext server coming to serve could be calculated easily. If QUIC could SUPPOR= T servers' authentication transport, it would help a lot in enhancement of = the network flow in satellite networks! And I am also interested that will authentication transport work in QUIC us= ing TLS 1.3. Maybe it would also help a lot in terrestrial networks if mobile users feel= good to use their geolocation information ... Thanks in advance and looking forward to your reply. --_000_MWHPR08MB2432BDCBC7552D5B5F741C59DA250MWHPR08MB2432namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I think what you’r= e describing is a handoff from one server instance to another.  The in= tent with the Connection ID is that packets can be routed back to the server instance that already has the correct state to deal wit= h them; if two server instances wanted to hand off that state between them = to reduce their routing load, that seems like an internal decision that wou= ld be transparent to QUIC.  If the servers have different IP:port endpoints, however, that would look to the = client like a server-side connection migration.  I don’t know wh= ether that has been explicitly deemed in or out of scope at this point.

 =

For the Stateless Reset = question, you’ll need to be more specific:  what are you trying = to solve?

 =

From: QUIC [mailto:quic-bounces@ietf= .org] On Behalf Of fish fish
Sent: Tuesday, November 21, 2017 11:27 PM
To: quic@ietf.org
Subject: Questions about QUIC server reset issues =

 

Respected, 

     I am Siyu Yang from Tsinghua= University in Beijing, China. I am a master candidate student interested i= n the transportation layer of satellite networks ( LEO/MEO/GEO ) using QUIC= .

     Previously I have done an ex= periment building QUIC server and clients in a simulated satellite network = environment. It turns out that QUIC/UDP performs much better than TCP/IP st= ructure because of the reduced handshake RTTs and congestion control strategies.

 

     After reading Google’s= paper on QUIC in sigcomm 2017, would you please tell me more about= updates of quic’s server stateless reset strategies? Any solution if= possible to solve?

 

     And I am also interested = in QUIC cooperation with CDN in such a working case: mobile clients may apply for another CDN server whe= n they are browsing using QUIC, if it is possible that a connection between CDN server A and the next CDN server= B,  the server A would send the related users’ authenticatio= n info in service   (users’ publi= c key and A’s public key so that B would not reject the clients’= requests though it is probably the first time that these clients seek for = connection to B so that one-RTT saved in this “new” connec= tion) to the server B if A knows that B would take over A to serve the clients ?

 

I might not be a ve= ry common phenomenon in terrestrial networks … I could think out= one that:  a CDN incremental deployment that the newly established CD= N server might “inherit” users’ authentication from its neighbor servers. 

 

But it could be a c= ommon phenomenon happening every few hours/days in satellite networks if we= deploy a set of CDN servers for example in a MEO satellite networks which = could cover the whole world with a couple of satellites. Some MEO-constellations has a good properties that the rela= tive locations within these satellites does not change, just like constella= tions we observe in sky. In this time, the CDN servers serve one clien= t in order and the next server coming to serve could be calculated easily. If QUIC could SUPPORT servers= ' authentication transport, it would help a lot in enhancement of the netwo= rk flow in satellite networks!

 

And I am also inter= ested that will authentication transport work in QUIC using TLS 1.3.=

 

Maybe it would also= help a lot in terrestrial networks if mobile users feel good to use their = geolocation information …

 

Thanks in advance a= nd looking forward to your reply.

--_000_MWHPR08MB2432BDCBC7552D5B5F741C59DA250MWHPR08MB2432namp_-- From nobody Mon Nov 27 11: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 296611204DA for ; Mon, 27 Nov 2017 11:46: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, 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 ch6f-dzwX5SL for ; Mon, 27 Nov 2017 11:46:00 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::12]) (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 BD08F120721 for ; Mon, 27 Nov 2017 11:45:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1511811957; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:X-RZG-CLASS-ID: X-RZG-AUTH:Accept-Language:Auto-Submitted:Cc:Date:From:Message-ID: References:Reply-To:Resent-Cc:Resent-Date:Resent-From:Resent-To: Sender:Subject:To:Content-Alternative:Content-Description: Content-Disposition:Content-Duration:Content-Features:Content-ID: Content-Language:Content-Location:Content-MD5: Content-Transfer-Encoding:Content-Type:MIME-Version; bh=knlyto2Ovsnaqg8ahcPFlSgAILveL7Ajn+ydUgL3FQM=; b=OIEzTNNHPHvJERgwqcgzwhSZso81tA6Pa0ABs39LhJwWEjnml7ccE0fOGPMSiMIhwA elzw6aOeLORBLSnOi+qumYV8mLdO3XJuSdc4/Tk+qsuOilPfrUb0YZM4CHl9A/NrRjc8 gw5qTjbxkn9flkDjbm38AHFfIQQdkZTNARq1g= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKn1oaZ1h8oElTTgmJ6Fg== X-RZG-CLASS-ID: mo00 Received: from [10.10.10.80] (p57B96C2D.dip0.t-ipconnect.de [87.185.108.45]) by smtp.strato.de (RZmta 42.10 DYNA|AUTH) with ESMTPSA id e03071tARJjl44h (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Mon, 27 Nov 2017 20:45:47 +0100 (CET) Subject: Re: Spin bit discussion - where we're at To: Christian Huitema Cc: Ingemar Johansson S , "Gorry (erg)" , "quic@ietf.org" References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@erg.abdn.ac.uk> <74e1c7bd-bd09-3285-db25-db04fe530cbc@zinks.de> <34BF55EB-8B3E-453C-BAFE-8048B4B94FC5@huitema.net> <54e419d4-e4c0-2e9e-93ab-6ff7750e483a@zinks.de> From: Roland Zink Message-ID: <118af13a-4aa7-4240-e67a-ba489e524166@zinks.de> Date: Mon, 27 Nov 2017 20:45:46 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 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.22 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 Nov 2017 19:46:02 -0000 I agree it is not only QUIC. I also don't think it is necessary to panic now. We have issue #740 (https://github.com/quicwg/base-drafts/issues/740) about adding a security issues section were existing means could be added. When QUIC can help to address such issues it can become more reliable so I wouldn't say this is out of scope just because other protocols have similar issues. If it really turns out that the current mitigations are not sufficient then work on better queue management algorithm will probably come too late. Roland Am 27.11.2017 um 19:02 schrieb Christian Huitema: > On 11/27/2017 9:36 AM, Roland Zink wrote: > >> If QUIC makes the problem crystal clear then now seems to be a good >> time to solve or mitigate it before risking it becomes a real world >> problem. > First, let's start by agreeing that this is not a problem specific QUIC. > You could say the same about Bit Torrent, any protocol that sends video > over UDP, or any application that opens multiple TCP connection. So, > yes, there may well be a problem, but since it is not specific to QUIC > the mitigation does not have to be specific to QUIC either. > > But let's not panic. Practical mitigation has started long ago, with > ISPs effectively controlling how much data can be sent through a > customer's up-link. Maybe these current mitigations are not sufficient, > but if that is the case I would expect more work on better queue > management algorithm. > > -- Christian Huitema > From nobody Mon Nov 27 13:52: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 82FD3124D6C for ; Mon, 27 Nov 2017 13:52:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 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, 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=fb.com header.b=VhslihQT; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=JDhkr8En Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sJISMkzd5BV for ; Mon, 27 Nov 2017 13:52:52 -0800 (PST) Received: from mx0b-00082601.pphosted.com (mx0b-00082601.pphosted.com [67.231.153.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 C54BD1200C5 for ; Mon, 27 Nov 2017 13:52:52 -0800 (PST) Received: from pps.filterd (m0109331.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vARLlmlH014959; Mon, 27 Nov 2017 13:52:50 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=facebook; bh=DQWFFns2a4X9SR7fxU7sCPbCFhq6ZRqQpIMfLusEQ1o=; b=VhslihQTM/7yZl7KdsvpHLLFboEGEwebsWS0JTbQtGLsg3jHyOSGd5PrQMJa+629TbSu upmUwjNlcvxS4GJSGfbrScXxsoHOdaPvaMuUXkQmZzPLQcN4uFfKUEN1p9UhZfGxgjMY AzmiwshQzqyeIcoo5ixMHJEEwAVKLxHAn0M= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2egpr691jk-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 27 Nov 2017 13:52:50 -0800 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.22) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 27 Nov 2017 13:52:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fb.onmicrosoft.com; s=selector1-fb-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DQWFFns2a4X9SR7fxU7sCPbCFhq6ZRqQpIMfLusEQ1o=; b=JDhkr8EncSVaKRpWFXwurImMmaVWJeOEr6PpLeZ7pWPjNa8xIeUTnlnk/C62MGcOIPUzPCk5ldHmwOb3rACqm9CwntsKVFP5QdcfcgCzJRqMjGT9jZivXOCU+T7YVhy3/HIPmvKzWD+Ju3oSZbfWBqISoj5CVN2KKKmFoISjzzw= Received: from DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) by DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Mon, 27 Nov 2017 21:52:47 +0000 Received: from DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) by DM5PR15MB1883.namprd15.prod.outlook.com ([10.174.247.135]) with mapi id 15.20.0260.006; Mon, 27 Nov 2017 21:52:47 +0000 From: Roberto Peon To: Roland Zink , "quic@ietf.org" Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2kK2PjZ/6sbIkqQgB4yjil4AqMgHeUAgAANHICAAAmFAIAABmyAgAbXRACAAMKvAIAASyYAgACtQIA= Date: Mon, 27 Nov 2017 21:52:46 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> In-Reply-To: <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::7:2ac3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1883; 20:nHhR82Q7UdLtCAopcfz7ze2N5upF/j4H1YSuZVP3u+uvfOme6KZNx1iHWpDSUe9jhTRCqAh3yoS3ES2ygDwxBJmgXzo2nbmRnLe0bPwx53EGDMAjtOuo84fvGF+ORC9/kbKyo9Fq3DOdqWkrLM4Ntm0fD+xdA2JvRq4FNTlyH7Y= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 18dc8a94-99be-4d5b-04c4-08d535e13247 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:DM5PR15MB1883; x-ms-traffictypediagnostic: DM5PR15MB1883: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(32856632585715)(97927398514766)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(11241501159)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231022)(93006095)(93001095)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123555025)(20161123564025)(6072148)(201708071742011); SRVR:DM5PR15MB1883; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DM5PR15MB1883; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(366004)(346002)(377424004)(24454002)(13464003)(189002)(199003)(2906002)(105586002)(25786009)(189998001)(106356001)(33656002)(3660700001)(53936002)(3280700002)(236005)(101416001)(6512007)(6306002)(54896002)(50986999)(5660300001)(77096006)(2900100001)(229853002)(4001150100001)(54356999)(81166006)(6486002)(6246003)(478600001)(561944003)(6506006)(8676002)(2950100002)(81156014)(6436002)(76176999)(6116002)(102836003)(83716003)(2501003)(82746002)(8936002)(93886005)(68736007)(53546010)(110136005)(86362001)(7736002)(36756003)(97736004)(99286004)(316002)(14454004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1883; H:DM5PR15MB1883.namprd15.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: fb.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_EDBA7DFC6CC2491E9A21A935EAB18630fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 18dc8a94-99be-4d5b-04c4-08d535e13247 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2017 21:52:46.8190 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1883 X-OriginatorOrg: fb.com X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-27_11:, , signatures=0 X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 21:52:55 -0000 --_000_EDBA7DFC6CC2491E9A21A935EAB18630fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXBwbGljYXRpb24gZGV2ZWxvcGVycyBoYXZlIGJlZW4gYWJ1c2luZyBUQ1AgZm9yIHllYXJzIChv cGVuIHVwIG1hbnkgY29uY3VycmVudCBjb25uZWN0aW9ucywgZXRjLiksIHNvIHRoaXMgaXNu4oCZ dCByZWFsbHkgbmV3Lg0KSW4gYW55IGNhc2UsIFFVSUMgaGlkZXMgaXRzIGNvbmdlc3Rpb24gYXZv aWRhbmNlIGZyb20gdGhlIG5ldHdvcmsgb25seSBwYXJ0aWFsbHk6IHRoZSBuZXR3b3JrIHdpbGwg YWx3YXlzIGJlIGFibGUgdG8gc2VlIHRoZSBudW1iZXIgb2YgcGFja2V0cywgaW50ZXItYXJyaXZh bCB0aW1pbmdzLCBldGMuIGZvciBhIGZsb3cgb24gYSA1LXR1cGxlLg0K4oCcVGhlIG5ldHdvcmvi gJ0gYWxzbyBoYXMgdGhlIGFiaWxpdHkgdG8gdHVubmVsIHBhY2tldHMgaG93ZXZlciBpdCBsaWtl cyB3aXRoaW4gYW4gQVNOLiBTcGluIGJpdHMgb3Igb3RoZXIgZGF0YSBjb3VsZCBiZSBpbmNsdWRl ZCBpbiBzdWNoIGFuIGVuY2Fwc3VsYXRpb24uDQotPVINCg0KRnJvbTogUVVJQyA8cXVpYy1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgUm9sYW5kIFppbmsgPHJvbGFuZEB6aW5rcy5kZT4N CkRhdGU6IE1vbmRheSwgTm92ZW1iZXIgMjcsIDIwMTcgYXQgMzozMyBBTQ0KVG86ICJxdWljQGll dGYub3JnIiA8cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBTcGluIGJpdCBkaXNjdXNzaW9u IC0gd2hlcmUgd2UncmUgYXQNCg0KQW0gMjcuMTEuMjAxNyB1bSAwODowMyBzY2hyaWViIEphbmEg SXllbmdhcjoNCkluIGFkZGl0aW9uIHRvIGhvdyB0aGUgc3BpbiBiaXQgY2FuIGJlIGRlc2lnbmVk IGFuZCB1c2VkLCBJJ2QgbGlrZSB0aG9zZSB0YWtpbmcgb24gdGhpcyBlZmZvcnQgdG8gY29uc2lk ZXIgdGhpcyBxdWVzdGlvbjogV2hhdGV2ZXIgbmV0d29yayBtYW5hZ2VtZW50IHByb2JsZW0geW91 J3JlIGNvbnNpZGVyaW5nIHNvbHZpbmcgd2l0aCBhIGJpdCwgd2hhdCBkb2VzIGl0IHRha2UgdG8g c29sdmUgdGhpcyBwcm9ibGVtIHdpdGhvdXQgdGhlIGJpdCBleHBvc2VkPyBJJ20gYXNraW5nIHlv dSB0byBjb25zaWRlciAiemVyby1iaXQiIHNvbHV0aW9ucywgb3IgYXQgbGVhc3QgZm9yIGEgY29z dC9iZW5lZml0IGFuYWx5c2lzIG9mIGRldmVsb3Bpbmcgc29sdXRpb25zIHdpdGggYW5kIHdpdGhv dXQgdGhlIHNwaW4gYml0IGZvciBzcGVjaWZpYyBuZXR3b3JrIG1hbmFnZW1lbnQgZnVuY3Rpb25z LiBTcGVjaWZpY2FsbHksDQoNCihpKSBXaGF0J3MgaW1wb3NzaWJsZSBvciB2ZXJ5IGRpZmZpY3Vs dCB0byBkbywgZnJvbSBhIG5ldHdvcmsgbWFuYWdlbWVudCBwZXJzcGVjdGl2ZSwgb2Ygbm90IGhh dmluZyB0aGUgc3BpbiBiaXQ/IE5vdGUgdGhhdCBJJ20gbm90IGFza2luZyBmb3Igd2hhdCBpcyBh bmQgaXMgbm90IG1lYXN1cmFibGUgLS0gbm90IGV2ZXJ5dGhpbmcgbWVhc3VyYWJsZSBpcyB1c2Vm dWwuIEknbSBzcGVjaWZpY2FsbHkgYXNraW5nIGluIHRlcm1zIG9mIG5ldHdvcmsgbWFuYWdlbWVu dCBmdW5jdGlvbnMsIGluIHByYWN0aWNlLCBhcyB1c2VkIGJ5IG9wZXJhdG9ycy4gU29tZSBvZiB0 aGlzIGhhcyBiZWVuIGFkZHJlc3NlZCBpbiB0aGUgZGlzY3Vzc2lvbnMvZHJhZnRzIEkndmUgc2Vl biwgYnV0IEkgdGhpbmsgaXQncyBtb3N0IHVzZWZ1bCB3aGVuIGZyYW1lZCBpbiB0ZXJtcyBvZiBu ZXR3b3JrIG1hbmFnZW1lbnQgZnVuY3Rpb25zLg0KSSB3YW50IHRvIGV4cHJlc3MgdGhlIHF1ZXN0 aW9uIGFib3V0IG1hbmFnZWFiaWxpdHkgZnJvbSBhIGRpZmZlcmVudCBhbmdsZS4gUVVJQyBtb3Zl cyB0aGUgY29uZ2VzdGlvbiBjb250cm9sIGZyb20gYmVpbmcgYSBjb21tb24gZnVuY3Rpb25hbGl0 eSBpbiB0aGUga2VybmVsIHRvIGFwcGxpY2F0aW9uIGZ1bmN0aW9uYWxpdHkuIEl0IGFsc28gaGlk ZXMgdGhlIHByb3RvY29sIGhhbmRsaW5nIG9mIGNvbmdlc3Rpb24gZnJvbSB0aGUgbmV0d29yay4g VGhpcyBnaXZlcyBpbmNlbnRpdmVzIGZvciBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIHRvIGNoYW5n ZSBjb25nZXN0aW9uIGNvbnRyb2wgdG8gZ2l2ZSB0aGVpciBhcHBsaWNhdGlvbiBhbiBhZHZhbnRh Z2Ugb3ZlciBvdGhlcnMuIE5vIHNwZWNpYWwgcmlnaHRzIGFyZSBuZWNlc3NhcnkuIE5vdyB0aGUg cXVlc3Rpb24gaXMgZG9lcyBRVUlDIHByb3ZpZGUgZW5vdWdoIG1hbmFnZWFiaWxpdHkgdG8gYXZv aWQgYW4gSW50ZXJuZXQgKG9yIHNvbWUgcGFydCBvZiBpdCkgYnJlYWtkb3duIHdoZW4gaXQgaXMg bWlzdXNlZD8gQ2FuIGl0IGJlIHNob3duIHRoYXQgdGhpcyBjYW4ndCBoYXBwZW4/DQoNCg0KKGlp KSBXaGF0IGFyZSB0aGUgYWx0ZXJuYXRpdmVzIGZvciBidWlsZGluZyB0aGUgc2FtZSBmdW5jdGlv bnMgd2l0aG91dCB0aGUgc3BpbiBiaXQ/IExldCdzIGNvbnNpZGVyIGZvciBhIG1vbWVudCB0aGF0 IHRoZSBzcGluIGJpdCBpc24ndCBhY3R1YWxseSBhdmFpbGFibGUgaW4gcHJhY3RpY2UuIFdoYXQg d2lsbCBvcGVyYXRvcnMgZG8gdG8gY29udGludWUgbWFuYWdpbmcgdGhlaXIgbmV0d29ya3M/IFRo aXMgbWlnaHQgYmUgZXhwZW5zaXZlLCBidXQgdGhhdCdzIHByZWNpc2VseSB3aGF0IEknbSBsb29r aW5nIGZvciAtLSB0aGUgY29zdCB0byBvcGVyYXRvcnMgb2Ygbm90IGhhdmluZyB0aGUgc3BpbiBi aXQuIEZvciBpbnN0YW5jZSwgYWN0aXZlIHByb2JlcyBhcmUgYSBmaW5lIHdheSB0byBtZWFzdXJl IG5ldHdvcmsgUlRUIHdpdGhpbiBvcGVyYXRvciBuZXR3b3JrcywgYW5kIHRoYXQgaXMgYW4gYWx0 ZXJuYXRpdmUuIFRoZXJlIGFyZSBzdXJlbHkgb3RoZXJzIHRvby4gVGhlaXIgY29zdHMgYW5kIGxp bWl0YXRpb25zIGFyZSBpbXBvcnRhbnQgdG8ga25vdyBhYm91dCBpbiBvcmRlciB0byByZWFzb24g YWJvdXQgdGhlaXIgdmlhYmlsaXR5LCBzbyBJJ2QgbGlrZSB0byBzZWUgYWx0ZXJuYXRpdmVzIGNv bnNpZGVyZWQuDQpTb2x1dGlvbnMgdGhhdCBvbmx5IHdvcmsgd2l0aGluIGFuIG9wZXJhdG9ycyBu ZXR3b3JrIGFyZSBub3QgZW5vdWdoIHdoZW4gbW9yZSB0aGFuIG9uZSBvcGVyYXRvciBpcyBpbnZv bHZlZC4NCg0KDQoNCkkgZG9uJ3QgbWVhbiB0byBzdGFydCB0aGUgZGlzY3Vzc2lvbiBvbiB0aGlz IHRocmVhZCwgYnV0IEknZCBsaWtlIHRvIHVyZ2UgdGhvc2UgZ29pbmcgb2ZmIHRvIGRvIHRoZSB3 cml0aW5nIHRvIGNvbnNpZGVyIHRoZXNlIHF1ZXN0aW9ucy4NCg0KLSBqYW5hDQoNCg0KT24gU3Vu LCBOb3YgMjYsIDIwMTcgYXQgMTE6MjYgQU0sIE1PUlRPTiwgQUxGUkVEIEMgKEFMKSA8YWNtb3J0 b25AYXR0LmNvbTxtYWlsdG86YWNtb3J0b25AYXR0LmNvbT4+IHdyb3RlOg0KSGkgQnJpYW4sIFN0 ZXBoZW4sIExhcnMsIE1hcmsgYW5kIGFsbCwNCg0Kb25lIGpvaW4sIG9uZSBzdWdnZXN0aW9uLCBh bmQgb25lIHF1ZXN0aW9uIGJlbG93Lg0Kc2VlIFtBQ01dDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQo+IEZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZz5dIE9uIEJlaGFsZiBPZiBCcmlhbiBUcmFtbWVsbA0KPiAo SUVURikNCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAyMiwgMjAxNyA1OjU5IEFNDQo+IFRv OiBFZ2dlcnQsIExhcnMNCj4gQ2M6IE1hcmsgTm90dGluZ2hhbTsgUVVJQyBXRzsgU3RlcGhlbiBG YXJyZWxsDQo+IFN1YmplY3Q6IFJlOiBTcGluIGJpdCBkaXNjdXNzaW9uIC0gd2hlcmUgd2UncmUg YXQNCj4NCj4gaGkgTGFycywNCj4NCj4gPiBPbiAyMiBOb3YgMjAxNywgYXQgMTE6MzUsIEVnZ2Vy dCwgTGFycyA8bGFyc0BuZXRhcHAuY29tPG1haWx0bzpsYXJzQG5ldGFwcC5jb20+PiB3cm90ZToN Cj4gPg0KPiA+IEhpLA0KPiA+DQo+ID4gT24gMjAxNy0xMS0yMiwgYXQgMTE6MDEsIFN0ZXBoZW4g RmFycmVsbCA8c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTxtYWlsdG86c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT4+DQo+IHdyb3RlOg0KPiA+PiBXaGF0IEkgdGhvdWdodCB3YXMgYmVpbmcgcmVx dWVzdGVkIGFuZCB3aGF0IEkgZG8gdGhpbmsgaXMgcmVhc29uYWJsZQ0KPiA+PiBpcyB0byBkb2N1 bWVudCBhIHByaXZhY3kgYW5hbHlzaXMgZm9yIGFueSBxdWljIHByb3RvY29sIGJpdHMgdGhhdCBh cmUNCj4gPj4gdmlzaWJsZSB0byB0aGUgcGF0aC4gV2hldGhlciBvciBub3Qgc29tZSBvciBhbGwg b2YgdGhhdCB0ZXh0IGVuZHMgdXANCj4gPj4gaW4gc29tZSBSRkMgaXMgYW5vdGhlciBkYXkncyB3 b3JrLg0KPiA+IExhcnMgd3JvdGU6DQo+ID4gZm9yIHRoZSBTcGluIEJpdCBzcGVjaWZpY2FsbHks IHRoZSBpbnRlbnQgd2FzIHRvIHBlcm1hbmVudGx5IGNhcHR1cmUNCj4gdGhlIGFuYWx5c2lzIHRo ZSBEVCBoYXMgZG9uZSwgc28gdGhhdCB3aGVuIG90aGVycyByZXZpZXcgdGhlIHByb3Bvc2VkDQo+ IFNwaW4gQml0IHNwZWNpZmljYXRpb24sIHRoZXkgY2FuIHRha2UgdGhhdCBhcyBhIGdpdmVuIGFu ZCBkaXJlY3QgYW55DQo+IGZ1cnRoZXIgYW5hbHlzaXMgdG8gb3RoZXIgYXNwZWN0cy4gSXQgbWFk ZSBzZW5zZSB0byB0aGUgY2hhaXJzIHRoYXQgdGhhdA0KPiBzcGVjaWZpYyBhbmFseXNpcyBzaG91 bGQgYmVjb21lIHBhcnQgb2YgdGhlIFNwaW4gQml0IHNwZWNpZmljYXRpb24uIEkNCj4gdGhpbmsg d2UnZCBiZSBvcGVuIHRvIGEgZGlzY3Vzc2lvbiBvbiB3aGV0aGVyIGEgYnJvYWRlciBkb2N1bWVu dA0KPiBhbmFseXppbmcgdGhlIFFVSUMgd2lyZSBpbWFnZSB3b3VsZCBiZSBhIGJldHRlciBob21l IGZvciB0aGlzLiBUaGUgbWFpbg0KPiBwb2ludCBpcyBmb3IgdGhlIHdvcmsgdGhhdCB0aGUgRFQg aGFzIGRvbmUgdG8gYmUgZG9jdW1lbnRlZC4NCg0KPiBCcmlhbiB3cm90ZToNCj4gT2theS4gVGhh dCdzIHNvbWV3aGF0IG1vcmUgcmVhc29uYWJsZSB0aGFuIHdoYXQgSSByZWFkIHRoZSBhc2sgdG8g YmUNCj4gKCJ3ZSdyZSBnb2luZyB0byBnYXRlIHRoaXMgb24gdGhlIHBlb3BsZSB3aG8gY2FyZSBh Ym91dCB0aGlzIGRvaW5nIHNvbWUNCj4gbm9uLXRyaXZpYWwgYW1vdW50IG9mIHdvcmsiKS4gVGhv c2Ugb2YgdXMgd2hvIHZvbHVudGVlciAoaGVscCwgcGxlYXNlLA0KPiBhbnlvbmU/IDopICkgY2Fu IGNlcnRhaW5seSBwdWxsIHRvZ2V0aGVyIHdoYXQgd2UgaGF2ZSBpbiBhIHNpbmdsZSBJLUQNCj4g YW5kIGFzayB0aGUgV0cgd2hhdCBtb3JlIGl0IHRoaW5rcyBpdCBuZWVkcy4gVG8gbWUgYWxsIHRo aXMgc2VlbXMgcHJldHR5DQo+IGNsZWFyLCBidXQgSSd2ZSBiZWVuIHdvcmtpbmcgb24gdGhpcyB0 b3BpYyBmb3IgYSB3aGlsZS4NCltBQ01dDQpIYXZpbmcgcmVhY2hlZCB0aGUgZW5kIG9mIHRoZSAi VGhhbmtzZ2l2aW5nIHRocmVhZCIsDQpJJ20gc2Nyb2xsaW5nIGJhY2sgYSBmZXcgcGFnZXMgdG8g am9pbiB0aGUgdGFzayBvZg0KcGVybWFuZW50bHkgY2FwdHVyaW5nIHRoZSB3b3JrIG9mIHRoZSBE VCBpbiBhbiBJLUQgKGF0IGxlYXN0KToNClRoZXJlIHNob3VsZCBiZSBsYXN0aW5nIHZhbHVlIGlu IHNvbWUgb2Ygb3VyIGZpbmRpbmdzDQphbmQgSU1PIHRoZXkgYXJlIHdvcnRoeSBvZiBhIHBlcnNp c3RlbnQgcmVmZXJlbmNlLg0KDQo+IExhcnMgd3JvdGU6DQo+ID4gRm9yIHByb3Bvc2FscyBvdGhl ciB0aGFuIHRoZSBTcGluIEJpdCAoSSB0aGluayBJIGhhdmUgc2VlbiBpbmRpdmlkdWFsDQo+IGNv bnRyaWJ1dG9ycyBhdCBsZWFzdCBtZW50aW9uICJsb3NzIiBhbmQgImNvbmdlc3Rpb24iIGJpdHMs IGJ1dCB3aXRob3V0DQo+IG11Y2ggZGV0YWlsKSwgd2Ugd2FudGVkIHRvIGNsYXJpZnkgdGhhdCB3 ZSdkIGxpa2UgdG8gc2VlIGFuIGFuYWx5c2lzIGFuZA0KPiBkaXNjdXNzaW9uIG9mIHRoZWlyIHBy aXZhY3kgYXNwZWN0cyB0byByb3VnaGx5IHRoZSBzYW1lIGRlZ3JlZSBhcyB0aGUgRFQNCj4gaGFz IHBlcmZvcm1lZCBmb3IgdGhlIFNwaW4gQml0IHByb3Bvc2FsLg0KPg0KW0FDTV0NCkkgc3VnZ2Vz dCB0aGF0IHRoaXMgbWlnaHQgYmUgYSBkaWZmZXJlbnQgSS1ELCBhdCBsZWFzdCB0byBzdGFydC4N ClF1ZXN0aW9uOiBJcyB0aGVyZSBhIHByaXZhY3kgYW5hbHlzaXMgb2YgcHJlc2VudCBFQ04gYXZh aWxhYmxlPw0KKGEgc2VhcmNoIHlpZWxkZWQgbWFueSByZXN1bHRzIHdpdGggTWlzc2luZzogcHJp dmFjeSkNCg0KcmVnYXJkcywNCkFsDQoNCg0KDQo= --_000_EDBA7DFC6CC2491E9A21A935EAB18630fbcom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcHBsaWNhdGlvbiBkZXZlbG9wZXJzIGhh dmUgYmVlbiBhYnVzaW5nIFRDUCBmb3IgeWVhcnMgKG9wZW4gdXAgbWFueSBjb25jdXJyZW50IGNv bm5lY3Rpb25zLCBldGMuKSwgc28gdGhpcyBpc27igJl0IHJlYWxseSBuZXcuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhbnkgY2FzZSwgUVVJQyBoaWRlcyBpdHMgY29u Z2VzdGlvbiBhdm9pZGFuY2UgZnJvbSB0aGUgbmV0d29yayBvbmx5IHBhcnRpYWxseTogdGhlIG5l dHdvcmsgd2lsbCBhbHdheXMgYmUgYWJsZSB0byBzZWUgdGhlIG51bWJlciBvZiBwYWNrZXRzLCBp bnRlci1hcnJpdmFsIHRpbWluZ3MsIGV0Yy4gZm9yIGEgZmxvdyBvbiBhIDUtdHVwbGUuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJxUaGUgbmV0d29ya+KAnSBhbHNvIGhh cyB0aGUgYWJpbGl0eSB0byB0dW5uZWwgcGFja2V0cyBob3dldmVyIGl0IGxpa2VzIHdpdGhpbiBh biBBU04uIFNwaW4gYml0cyBvciBvdGhlciBkYXRhIGNvdWxkIGJlIGluY2x1ZGVkIGluIHN1Y2gg YW4gZW5jYXBzdWxhdGlvbi4NCjxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+UVVJQyAmbHQ7cXVpYy1ib3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhh bGYgb2YgUm9sYW5kIFppbmsgJmx0O3JvbGFuZEB6aW5rcy5kZSZndDs8YnI+DQo8Yj5EYXRlOiA8 L2I+TW9uZGF5LCBOb3ZlbWJlciAyNywgMjAxNyBhdCAzOjMzIEFNPGJyPg0KPGI+VG86IDwvYj4m cXVvdDtxdWljQGlldGYub3JnJnF1b3Q7ICZsdDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogU3BpbiBiaXQgZGlzY3Vzc2lvbiAtIHdoZXJlIHdlJ3JlIGF0PG86cD48 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B bSAyNy4xMS4yMDE3IHVtIDA4OjAzIHNjaHJpZWIgSmFuYSBJeWVuZ2FyOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90 dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBhZGRpdGlvbiB0byBo b3cgdGhlIHNwaW4gYml0IGNhbiBiZSBkZXNpZ25lZCBhbmQgdXNlZCwgSSdkIGxpa2UgdGhvc2Ug dGFraW5nIG9uIHRoaXMgZWZmb3J0IHRvIGNvbnNpZGVyIHRoaXMgcXVlc3Rpb246IFdoYXRldmVy IG5ldHdvcmsgbWFuYWdlbWVudCBwcm9ibGVtIHlvdSdyZSBjb25zaWRlcmluZyBzb2x2aW5nIHdp dGggYSBiaXQsIHdoYXQgZG9lcyBpdCB0YWtlIHRvIHNvbHZlIHRoaXMgcHJvYmxlbQ0KIHdpdGhv dXQgdGhlIGJpdCBleHBvc2VkPyBJJ20gYXNraW5nIHlvdSB0byBjb25zaWRlciAmcXVvdDt6ZXJv LWJpdCZxdW90OyBzb2x1dGlvbnMsIG9yIGF0IGxlYXN0IGZvciBhIGNvc3QvYmVuZWZpdCBhbmFs eXNpcyBvZiBkZXZlbG9waW5nIHNvbHV0aW9ucyB3aXRoIGFuZCB3aXRob3V0IHRoZSBzcGluIGJp dCBmb3Igc3BlY2lmaWMgbmV0d29yayBtYW5hZ2VtZW50IGZ1bmN0aW9ucy4gU3BlY2lmaWNhbGx5 LA0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oaSkgV2hh dCdzIGltcG9zc2libGUgb3IgdmVyeSBkaWZmaWN1bHQgdG8gZG8sIGZyb20gYSBuZXR3b3JrIG1h bmFnZW1lbnQgcGVyc3BlY3RpdmUsIG9mIG5vdCBoYXZpbmcgdGhlIHNwaW4gYml0PyBOb3RlIHRo YXQgSSdtIG5vdCBhc2tpbmcgZm9yIHdoYXQgaXMgYW5kIGlzIG5vdCBtZWFzdXJhYmxlIC0tIG5v dCBldmVyeXRoaW5nIG1lYXN1cmFibGUgaXMgdXNlZnVsLiBJJ20gc3BlY2lmaWNhbGx5IGFza2lu Zw0KIGluIHRlcm1zIG9mIG5ldHdvcmsgbWFuYWdlbWVudCBmdW5jdGlvbnMsIGluIHByYWN0aWNl LCBhcyB1c2VkIGJ5IG9wZXJhdG9ycy4gU29tZSBvZiB0aGlzIGhhcyBiZWVuIGFkZHJlc3NlZCBp biB0aGUgZGlzY3Vzc2lvbnMvZHJhZnRzIEkndmUgc2VlbiwgYnV0IEkgdGhpbmsgaXQncyBtb3N0 IHVzZWZ1bCB3aGVuIGZyYW1lZCBpbiB0ZXJtcyBvZiBuZXR3b3JrIG1hbmFnZW1lbnQgZnVuY3Rp b25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkkgd2FudCB0byBleHByZXNzIHRoZSBxdWVzdGlvbiBhYm91dCBtYW5h Z2VhYmlsaXR5IGZyb20gYSBkaWZmZXJlbnQgYW5nbGUuIFFVSUMgbW92ZXMgdGhlIGNvbmdlc3Rp b24gY29udHJvbCBmcm9tIGJlaW5nIGEgY29tbW9uIGZ1bmN0aW9uYWxpdHkgaW4gdGhlIGtlcm5l bCB0byBhcHBsaWNhdGlvbiBmdW5jdGlvbmFsaXR5LiBJdCBhbHNvIGhpZGVzIHRoZSBwcm90b2Nv bCBoYW5kbGluZyBvZiBjb25nZXN0aW9uDQogZnJvbSB0aGUgbmV0d29yay4gVGhpcyBnaXZlcyBp bmNlbnRpdmVzIGZvciBhcHBsaWNhdGlvbiBkZXZlbG9wZXJzIHRvIGNoYW5nZSBjb25nZXN0aW9u IGNvbnRyb2wgdG8gZ2l2ZSB0aGVpciBhcHBsaWNhdGlvbiBhbiBhZHZhbnRhZ2Ugb3ZlciBvdGhl cnMuIE5vIHNwZWNpYWwgcmlnaHRzIGFyZSBuZWNlc3NhcnkuIE5vdyB0aGUgcXVlc3Rpb24gaXMg ZG9lcyBRVUlDIHByb3ZpZGUgZW5vdWdoIG1hbmFnZWFiaWxpdHkgdG8gYXZvaWQgYW4gSW50ZXJu ZXQNCiAob3Igc29tZSBwYXJ0IG9mIGl0KSBicmVha2Rvd24gd2hlbiBpdCBpcyBtaXN1c2VkPyBD YW4gaXQgYmUgc2hvd24gdGhhdCB0aGlzIGNhbid0IGhhcHBlbj88YnI+DQo8YnI+DQo8YnI+DQo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4oaWkp IFdoYXQgYXJlIHRoZSBhbHRlcm5hdGl2ZXMgZm9yIGJ1aWxkaW5nIHRoZSBzYW1lIGZ1bmN0aW9u cyB3aXRob3V0IHRoZSBzcGluIGJpdD8gTGV0J3MgY29uc2lkZXIgZm9yIGEgbW9tZW50IHRoYXQg dGhlIHNwaW4gYml0IGlzbid0IGFjdHVhbGx5IGF2YWlsYWJsZSBpbiBwcmFjdGljZS4gV2hhdCB3 aWxsIG9wZXJhdG9ycyBkbyB0byBjb250aW51ZSBtYW5hZ2luZyB0aGVpciBuZXR3b3Jrcz8gVGhp cyBtaWdodA0KIGJlIGV4cGVuc2l2ZSwgYnV0IHRoYXQncyBwcmVjaXNlbHkgd2hhdCBJJ20gbG9v a2luZyBmb3IgLS0gdGhlIGNvc3QgdG8gb3BlcmF0b3JzIG9mIG5vdCBoYXZpbmcgdGhlIHNwaW4g Yml0LiBGb3IgaW5zdGFuY2UsIGFjdGl2ZSBwcm9iZXMgYXJlIGEgZmluZSB3YXkgdG8gbWVhc3Vy ZSBuZXR3b3JrIFJUVCB3aXRoaW4gb3BlcmF0b3IgbmV0d29ya3MsIGFuZCB0aGF0IGlzIGFuIGFs dGVybmF0aXZlLiBUaGVyZSBhcmUgc3VyZWx5IG90aGVycyB0b28uDQogVGhlaXIgY29zdHMgYW5k IGxpbWl0YXRpb25zIGFyZSBpbXBvcnRhbnQgdG8ga25vdyBhYm91dCBpbiBvcmRlciB0byByZWFz b24gYWJvdXQgdGhlaXIgdmlhYmlsaXR5LCBzbyBJJ2QgbGlrZSB0byBzZWUgYWx0ZXJuYXRpdmVz IGNvbnNpZGVyZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3Rl Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U29sdXRpb25zIHRoYXQgb25seSB3b3JrIHdpdGhpbiBh biBvcGVyYXRvcnMgbmV0d29yayBhcmUgbm90IGVub3VnaCB3aGVuIG1vcmUgdGhhbiBvbmUgb3Bl cmF0b3IgaXMgaW52b2x2ZWQuPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8Ymxv Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxk aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0IG1lYW4gdG8gc3RhcnQg dGhlIGRpc2N1c3Npb24gb24gdGhpcyB0aHJlYWQsIGJ1dCBJJ2QgbGlrZSB0byB1cmdlIHRob3Nl IGdvaW5nIG9mZiB0byBkbyB0aGUgd3JpdGluZyB0byBjb25zaWRlciB0aGVzZSBxdWVzdGlvbnMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0g amFuYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk9uIFN1biwgTm92IDI2LCAyMDE3IGF0IDExOjI2IEFNLCBNT1JUT04sIEFMRlJFRCBDIChB TCkgJmx0OzxhIGhyZWY9Im1haWx0bzphY21vcnRvbkBhdHQuY29tIiB0YXJnZXQ9Il9ibGFuayI+ YWNtb3J0b25AYXR0LmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkg QnJpYW4sIFN0ZXBoZW4sIExhcnMsIE1hcmsgYW5kIGFsbCw8YnI+DQo8YnI+DQpvbmUgam9pbiwg b25lIHN1Z2dlc3Rpb24sIGFuZCBvbmUgcXVlc3Rpb24gYmVsb3cuPGJyPg0Kc2VlIFtBQ01dPGJy Pg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogUVVJQyBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciPnF1aWMtYm91bmNl c0BpZXRmLm9yZzwvYT5dIE9uIEJlaGFsZiBPZiBCcmlhbiBUcmFtbWVsbDxicj4NCiZndDsgKElF VEYpPGJyPg0KJmd0OyBTZW50OiBXZWRuZXNkYXksIE5vdmVtYmVyIDIyLCAyMDE3IDU6NTkgQU08 YnI+DQomZ3Q7IFRvOiBFZ2dlcnQsIExhcnM8YnI+DQomZ3Q7IENjOiBNYXJrIE5vdHRpbmdoYW07 IFFVSUMgV0c7IFN0ZXBoZW4gRmFycmVsbDxicj4NCiZndDsgU3ViamVjdDogUmU6IFNwaW4gYml0 IGRpc2N1c3Npb24gLSB3aGVyZSB3ZSdyZSBhdDxicj4NCiZndDs8YnI+DQomZ3Q7IGhpIExhcnMs PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBPbiAyMiBOb3YgMjAxNywgYXQgMTE6MzUsIEVnZ2Vy dCwgTGFycyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxhcnNAbmV0YXBwLmNvbSI+bGFyc0BuZXRhcHAu Y29tPC9hPiZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEhpLDxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiAyMDE3LTExLTIyLCBhdCAxMTowMSwgU3RlcGhl biBGYXJyZWxsICZsdDs8YSBocmVmPSJtYWlsdG86c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZSI+ c3RlcGhlbi5mYXJyZWxsQGNzLnRjZC5pZTwvYT4mZ3Q7PGJyPg0KJmd0OyB3cm90ZTo8YnI+DQom Z3Q7ICZndDsmZ3Q7IFdoYXQgSSB0aG91Z2h0IHdhcyBiZWluZyByZXF1ZXN0ZWQgYW5kIHdoYXQg SSBkbyB0aGluayBpcyByZWFzb25hYmxlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpcyB0byBkb2N1bWVu dCBhIHByaXZhY3kgYW5hbHlzaXMgZm9yIGFueSBxdWljIHByb3RvY29sIGJpdHMgdGhhdCBhcmU8 YnI+DQomZ3Q7ICZndDsmZ3Q7IHZpc2libGUgdG8gdGhlIHBhdGguIFdoZXRoZXIgb3Igbm90IHNv bWUgb3IgYWxsIG9mIHRoYXQgdGV4dCBlbmRzIHVwPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBpbiBzb21l IFJGQyBpcyBhbm90aGVyIGRheSdzIHdvcmsuPGJyPg0KJmd0OyAmZ3Q7IExhcnMgd3JvdGU6PGJy Pg0KJmd0OyAmZ3Q7IGZvciB0aGUgU3BpbiBCaXQgc3BlY2lmaWNhbGx5LCB0aGUgaW50ZW50IHdh cyB0byBwZXJtYW5lbnRseSBjYXB0dXJlPGJyPg0KJmd0OyB0aGUgYW5hbHlzaXMgdGhlIERUIGhh cyBkb25lLCBzbyB0aGF0IHdoZW4gb3RoZXJzIHJldmlldyB0aGUgcHJvcG9zZWQ8YnI+DQomZ3Q7 IFNwaW4gQml0IHNwZWNpZmljYXRpb24sIHRoZXkgY2FuIHRha2UgdGhhdCBhcyBhIGdpdmVuIGFu ZCBkaXJlY3QgYW55PGJyPg0KJmd0OyBmdXJ0aGVyIGFuYWx5c2lzIHRvIG90aGVyIGFzcGVjdHMu IEl0IG1hZGUgc2Vuc2UgdG8gdGhlIGNoYWlycyB0aGF0IHRoYXQ8YnI+DQomZ3Q7IHNwZWNpZmlj IGFuYWx5c2lzIHNob3VsZCBiZWNvbWUgcGFydCBvZiB0aGUgU3BpbiBCaXQgc3BlY2lmaWNhdGlv bi4gSTxicj4NCiZndDsgdGhpbmsgd2UnZCBiZSBvcGVuIHRvIGEgZGlzY3Vzc2lvbiBvbiB3aGV0 aGVyIGEgYnJvYWRlciBkb2N1bWVudDxicj4NCiZndDsgYW5hbHl6aW5nIHRoZSBRVUlDIHdpcmUg aW1hZ2Ugd291bGQgYmUgYSBiZXR0ZXIgaG9tZSBmb3IgdGhpcy4gVGhlIG1haW48YnI+DQomZ3Q7 IHBvaW50IGlzIGZvciB0aGUgd29yayB0aGF0IHRoZSBEVCBoYXMgZG9uZSB0byBiZSBkb2N1bWVu dGVkLjxicj4NCjxicj4NCiZndDsgQnJpYW4gd3JvdGU6PGJyPg0KJmd0OyBPa2F5LiBUaGF0J3Mg c29tZXdoYXQgbW9yZSByZWFzb25hYmxlIHRoYW4gd2hhdCBJIHJlYWQgdGhlIGFzayB0byBiZTxi cj4NCiZndDsgKCZxdW90O3dlJ3JlIGdvaW5nIHRvIGdhdGUgdGhpcyBvbiB0aGUgcGVvcGxlIHdo byBjYXJlIGFib3V0IHRoaXMgZG9pbmcgc29tZTxicj4NCiZndDsgbm9uLXRyaXZpYWwgYW1vdW50 IG9mIHdvcmsmcXVvdDspLiBUaG9zZSBvZiB1cyB3aG8gdm9sdW50ZWVyIChoZWxwLCBwbGVhc2Us PGJyPg0KJmd0OyBhbnlvbmU/IDopICkgY2FuIGNlcnRhaW5seSBwdWxsIHRvZ2V0aGVyIHdoYXQg d2UgaGF2ZSBpbiBhIHNpbmdsZSBJLUQ8YnI+DQomZ3Q7IGFuZCBhc2sgdGhlIFdHIHdoYXQgbW9y ZSBpdCB0aGlua3MgaXQgbmVlZHMuIFRvIG1lIGFsbCB0aGlzIHNlZW1zIHByZXR0eTxicj4NCiZn dDsgY2xlYXIsIGJ1dCBJJ3ZlIGJlZW4gd29ya2luZyBvbiB0aGlzIHRvcGljIGZvciBhIHdoaWxl Ljxicj4NCltBQ01dPGJyPg0KSGF2aW5nIHJlYWNoZWQgdGhlIGVuZCBvZiB0aGUgJnF1b3Q7VGhh bmtzZ2l2aW5nIHRocmVhZCZxdW90Oyw8YnI+DQpJJ20gc2Nyb2xsaW5nIGJhY2sgYSBmZXcgcGFn ZXMgdG8gam9pbiB0aGUgdGFzayBvZjxicj4NCnBlcm1hbmVudGx5IGNhcHR1cmluZyB0aGUgd29y ayBvZiB0aGUgRFQgaW4gYW4gSS1EIChhdCBsZWFzdCk6PGJyPg0KVGhlcmUgc2hvdWxkIGJlIGxh c3RpbmcgdmFsdWUgaW4gc29tZSBvZiBvdXIgZmluZGluZ3M8YnI+DQphbmQgSU1PIHRoZXkgYXJl IHdvcnRoeSBvZiBhIHBlcnNpc3RlbnQgcmVmZXJlbmNlLjxicj4NCjxicj4NCiZndDsgTGFycyB3 cm90ZTo8YnI+DQomZ3Q7ICZndDsgRm9yIHByb3Bvc2FscyBvdGhlciB0aGFuIHRoZSBTcGluIEJp dCAoSSB0aGluayBJIGhhdmUgc2VlbiBpbmRpdmlkdWFsPGJyPg0KJmd0OyBjb250cmlidXRvcnMg YXQgbGVhc3QgbWVudGlvbiAmcXVvdDtsb3NzJnF1b3Q7IGFuZCAmcXVvdDtjb25nZXN0aW9uJnF1 b3Q7IGJpdHMsIGJ1dCB3aXRob3V0PGJyPg0KJmd0OyBtdWNoIGRldGFpbCksIHdlIHdhbnRlZCB0 byBjbGFyaWZ5IHRoYXQgd2UnZCBsaWtlIHRvIHNlZSBhbiBhbmFseXNpcyBhbmQ8YnI+DQomZ3Q7 IGRpc2N1c3Npb24gb2YgdGhlaXIgcHJpdmFjeSBhc3BlY3RzIHRvIHJvdWdobHkgdGhlIHNhbWUg ZGVncmVlIGFzIHRoZSBEVDxicj4NCiZndDsgaGFzIHBlcmZvcm1lZCBmb3IgdGhlIFNwaW4gQml0 IHByb3Bvc2FsLjxicj4NCiZndDs8YnI+DQpbQUNNXTxicj4NCkkgc3VnZ2VzdCB0aGF0IHRoaXMg bWlnaHQgYmUgYSBkaWZmZXJlbnQgSS1ELCBhdCBsZWFzdCB0byBzdGFydC48YnI+DQpRdWVzdGlv bjogSXMgdGhlcmUgYSBwcml2YWN5IGFuYWx5c2lzIG9mIHByZXNlbnQgRUNOIGF2YWlsYWJsZT88 YnI+DQooYSBzZWFyY2ggeWllbGRlZCBtYW55IHJlc3VsdHMgd2l0aCBNaXNzaW5nOiBwcml2YWN5 KTxicj4NCjxicj4NCnJlZ2FyZHMsPGJyPg0KQWw8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EDBA7DFC6CC2491E9A21A935EAB18630fbcom_-- From nobody Mon Nov 27 14:03: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 1EE7A127058 for ; Mon, 27 Nov 2017 14:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 0JzKbJHsEypj for ; Mon, 27 Nov 2017 14:03:13 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0113.outbound.protection.outlook.com [104.47.32.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57173124D6C for ; Mon, 27 Nov 2017 14:03:13 -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=IH5xdkxlTBdMfDL4ZUru8S1jXMEIK3+kg2Tq/he85uw=; b=hlcAQuthcVK6sHHPhvLhKUIe7IOKDDzyZ2F0x2pltsPPkGhHsXffVxAWhZf+bkyW4vZ4XoQgC++JD+CdWjBwev9qub/imlSRjnH8SfMIoyxIe9cpoOaNGjO6Z7Mi7OG+BM6eSwI4lwvgn1tA0GSrl/lN5tjrN5+33bE99fa6mzA= Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0130.namprd21.prod.outlook.com (10.173.199.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.0; Mon, 27 Nov 2017 22:03:11 +0000 Received: from BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) by BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) with mapi id 15.20.0302.001; Mon, 27 Nov 2017 22:03:11 +0000 From: Nick Banks To: "quic@ietf.org" Subject: Independent QUIC Firewall Thread-Topic: Independent QUIC Firewall Thread-Index: AdNnx7j6IOTAAe2ORW6ZmaqnN0YSzQ== Date: Mon, 27 Nov 2017 22:03:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=True; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Owner=nibanks@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-11-27T22:03:08.3571554Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=General; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Application=Microsoft Azure Information Protection; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Extended_MSFT_Method=Automatic; Sensitivity=General x-originating-ip: [2001:4898:80e8:1::744] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0130; 6:L4GTHWLsu5AHbL6MiTXnJ9q4jGQi54+hTBS53d079YcR1QZgTN+6sUYnk1aideyywe0MYz4wx4XT11e7yuoN/yyaug14ISHTsGwd4dcjmXuqszghy4U/OzzgkVgMTMkb6WxXGE7j6Hev06AKy87/trKBbAeiKbsDvIAao5kI+P0JBaxln9iKwQ3IXM04IoO8KDaLM+Pv7dBcS3UYSdqfC7vugcJUOOeEGKAUzVSoScxMO2ZhlN6AlAHNuiIfhfCpd3DVjrTmhrIPqCmg7IiC38Om85ddlKMq8QD1x3nvHgWVrhqtxuCZd/eBb8hVON1AcTTynMO8zQStsz65QAvWwReFeZOdlD97aDegZMB5Aus=; 5:QQczEnE9GgwB2sSI2X0AUDDGBx2XsNN9+iHGdraDIJaShhwy9KTgu2GglAj0a+beqwuOhyg4hz/S2S/4hI1G+orSR1twVihZtx2rw0LkPR3RhYwjEe5R9Svpf2ZGF3CWk6fqehBPnXRaNjiuF+FtoqeGpRYvayEOoKLpNXhMs80=; 24:sewR+XJqdHjV3VQK23M3SKxA+3j2UOY+25m76gNLth9XTTnKcVDAJPZqUm7YXdSo/WCG9Xaz0ZFExReWJPPSf9I6H4tStJEexsBSJViquh0=; 7:LfolHuROyn1VOAR0Yf9/XLoQRSn1pBtnY36+eC9TPYPobeLzaGY3ubvBqKhXsa7AI1QzEu6fW3KuCqqx1KVM0g7vChwR6+cxJwM0Ch/buyTQrf6wpUAS7zn8vb694lRnkrrAe6EXSNNdy4mW8HH5rkt3Bk5hTfP/D1TF1xwTCuYbLLPxVaVjz/4RYY9QLILd1hq0yVeGFwvJX1m6GnmQddTyPuvTpuAs1QCIi7rGpEjP8+WSzLl8af687S7owW3S x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3af8b902-7fb6-4124-1cd3-08d535e2a684 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(48565401081)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258); SRVR:BN6PR21MB0130; x-ms-traffictypediagnostic: BN6PR21MB0130: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(227612066756510)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231022)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123558100)(20161123560025)(20161123564025)(6072148)(201708071742011); SRVR:BN6PR21MB0130; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR21MB0130; x-forefront-prvs: 0504F29D72 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(366004)(39860400002)(376002)(47760400005)(189002)(199003)(9326002)(2900100001)(97736004)(316002)(101416001)(6436002)(54356999)(50986999)(3280700002)(5640700003)(81166006)(1730700003)(53936002)(81156014)(8676002)(3660700001)(7696005)(6506006)(2351001)(6306002)(106356001)(9686003)(54896002)(105586002)(77096006)(33656002)(8936002)(102836003)(6116002)(790700001)(7116003)(86362001)(74316002)(6916009)(25786009)(2501003)(8990500004)(10090500001)(99286004)(10290500003)(5630700001)(478600001)(5660300001)(68736007)(14454004)(7736002)(86612001)(55016002)(189998001)(3480700004)(2906002)(22452003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0130; H:BN6PR21MB0178.namprd21.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_BN6PR21MB01780DE743CEBE1EAD99774EB3250BN6PR21MB0178namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3af8b902-7fb6-4124-1cd3-08d535e2a684 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2017 22:03:11.3787 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0130 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 22:03:15 -0000 --_000_BN6PR21MB01780DE743CEBE1EAD99774EB3250BN6PR21MB0178namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, With the current state of the QUIC protocol, it seems impossible to have an= independent QUIC firewall perform source address validation before letting= packets through to the server. Ideally, the firewall might have special ha= rdware to generate the Retry packet in response to Initial packets received= and then only let traffic through once the client responded to the Retry p= acket. This wouldn't work though, because TLS authenticates the transcript = of the connection. The actual QUIC server would drop the connection if it d= idn't original the Retry packet and associated HelloRetryRequest. Is this s= omething that QUIC should support? And if this is something that QUIC should support, I have a follow up quest= ion. Because all packets are encrypted, how would we expect a hardware fire= wall to ever get close to matching the performance of a TCP equivalent fire= wall? It seems to be a lot more difficult (expensive) to protect QUIC from = attacks than TCP. Thanks, - Nick Banks --_000_BN6PR21MB01780DE743CEBE1EAD99774EB3250BN6PR21MB0178namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

With the current state of the QUIC protocol, it seem= s impossible to have an independent QUIC firewall perform source address va= lidation before letting packets through to the server. Ideally, the firewal= l might have special hardware to generate the Retry packet in response to Initial packets received and then only let= traffic through once the client responded to the Retry packet. This wouldn= ’t work though, because TLS authenticates the transcript of the conne= ction. The actual QUIC server would drop the connection if it didn’t original the Retry packet and associated= HelloRetryRequest. Is this something that QUIC should support?<= /p>

 

And if this is something that QUIC should support, I= have a follow up question. Because all packets are encrypted, how would we= expect a hardware firewall to ever get close to matching the performance o= f a TCP equivalent firewall? It seems to be a lot more difficult (expensive) to protect QUIC from attacks than T= CP.

 

Thanks,

- Nick Banks

--_000_BN6PR21MB01780DE743CEBE1EAD99774EB3250BN6PR21MB0178namp_-- From nobody Mon Nov 27 15:58: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 0CAF7128AA1 for ; Mon, 27 Nov 2017 15:58:29 -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 eeTPvtuIPlrK for ; Mon, 27 Nov 2017 15:58:27 -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 2D6C4124207 for ; Mon, 27 Nov 2017 15:58:27 -0800 (PST) Received: by mail-qt0-x22b.google.com with SMTP id j12so19807339qtc.9 for ; Mon, 27 Nov 2017 15:58: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; bh=eE60u3UTkRUwnjICIrYa3U70/B3fq64XV7iwpIdwXEg=; b=oSQKj3toeG2WA54yosXUDCORB06sysXgFukhCe+p8WaHbVam3RzrRgsphDVYA/S34+ drCgsCO9fpeVJf/TO148pOdKvf/McLnrSud1qHbbCTqv9IYQqAQaMX2LgMtIQeWS/nNP fI9gQ32F7Q5okFCdytWNQoVjc6AXuuQxCZ3p7mBRqClmliz7zG7YX6Z9hiWUeCX6+Upx OcFuFyM9P/nmGi7EpyzTAu+PmBiONxSNt6aXudNR5XUdrYTeANoW9cSR9kCcZGoDbcUP qMx+g02JL4P2gR7gVktxgxazQ2fpnrgxInNunt4dZEJsJ7ZbOGo3MBxq8TvB4QVYyLe4 hL0w== 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=eE60u3UTkRUwnjICIrYa3U70/B3fq64XV7iwpIdwXEg=; b=GS0xskXpzJdVPt+ed9d+v3YbErFx7Lr/O3Wel3PNW4i1aT76y3UircGIPAjpoutrtq +d/feBjNxjahW5NpoYd7eG//uZ+kS0U/8gFW+i/e0bSb5Jcg8sCTkQoKlElG5mBzjOJc bHR9q9YfrXWHMvKdtvUsxitbtHEQySE73dphq81xJGlfxhYcWQfO8Hs9WNLnHVWFpliU UPueYn7u1MqcYLm2ATgZmq10lpB1uT8AgEqjQElY2SSwGg9Nwq7knIP22bWJXS7dX3Ba JOA8CexjFqbIu8YnYTHVJa/8zUySEqiOjRonyH/06Ku00Q2hgwdy1sQXfgE8095ZZaPG ZUwQ== X-Gm-Message-State: AJaThX6/Qt9pFqyLf12JDLhmwGDN9irUASddb+qOwFrBtlBOQh8Bazhi hCH89St0oOIDWKdOz1EpxlrNiEPDAiHjo33sz7M= X-Google-Smtp-Source: AGs4zMbTzHHVhV+jHjBSK/j2C2S8BLhPypAzOOSZpVY/GIwj62VVm6cqbgLbjabaxKkaOeQMrPlUuwnWIdvH2kisrvc= X-Received: by 10.200.38.33 with SMTP id u30mr47963927qtu.197.1511827106060; Mon, 27 Nov 2017 15:58:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.169 with HTTP; Mon, 27 Nov 2017 15:57:55 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Mon, 27 Nov 2017 15:57:55 -0800 Message-ID: Subject: Re: Independent QUIC Firewall To: Nick Banks Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a114058a49e6050055effadff" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 23:58:29 -0000 --001a114058a49e6050055effadff Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Nick, On Mon, Nov 27, 2017 at 2:03 PM, Nick Banks wrote: > Hello, > > > > With the current state of the QUIC protocol, it seems impossible to have > an independent QUIC firewall perform source address validation before > letting packets through to the server. > So, there are clearly classes of source address validation, some of which simply verify that the source address is from a subnet appropriate to the packet ingress port. Those are unaffected by QUIC and, depending on where you put the firewall/NFV instance doing this work, they may be sufficient for many use cases. If you place the firewall further away the access nodes, this gets more difficult as there is a higher chance that the device emitting the packet is on your network but not entitled to use the source address. In that case, you apparently want an on-path device to be able to signal to the origin that it requires verification that the origin sent the packet. Absent a signalling path, you seem to have two classes of verification: drop the initial packet and confirm intent by watching for a retry after a timeout period. (This is absolutely hideous from a latency perspective, and I can hear all the HTTP use case people screaming about bandwidth delay products in my head, so don't do this or they may show up at your office with whiteboards and colored ink). The other option is to allow the initial packet and watch for the handshake completion, closing the pinhole when it fails to complete. This does not have a latency impact, but it will allow some single-packet traffic flows to egress if standard BCP 38 rules did not catch them. The working group is trying pretty hard to make sure that those attacks don't turn in to amplification attacks, and I hope you'll help in that endeavor. Ideally, the firewall might have special hardware to generate the Retry > packet in response to Initial packets received and then only let traffic > through once the client responded to the Retry packet. This wouldn=E2=80= =99t work > though, because TLS authenticates the transcript of the connection. The > actual QUIC server would drop the connection if it didn=E2=80=99t origina= l the > Retry packet and associated HelloRetryRequest. Is this something that QUI= C > should support? > > If you're asking if there should be an explicit signal than an on-path device could send that asked for verification, the short answer is a question: how do you instantiate the trust to prevent that from being an avenue of attack? (Split client models and server farms that share roots of trust or keys more or less know how to do this. But a firewall typically isn't trusted to be a party to the communication, for the Random WiFi attachment use case and many others). > > And if this is something that QUIC should support, I have a follow up > question. Because all packets are encrypted, how would we expect a hardwa= re > firewall to ever get close to matching the performance of a TCP equivalen= t > firewall? It seems to be a lot more difficult (expensive) to protect QUIC > from attacks than TCP. > > > I think source address validation mainly protects the network from spoof traffic (See RFC 6959 for much better and more complete descriptions), rather than protecting the traffic. So when you say "protect QUIC from attacks", I'm not sure exactly what you mean. Would you mind going into a bit more detail on what you need? regards, Ted Hardie > Thanks, > > - Nick Banks > --001a114058a49e6050055effadff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Nick,

On Mon, Nov 27, 2017 at 2:03 PM, Nick Banks <nibanks@= microsoft.com> wrote:

Hello,

=C2=A0

With the current state of the QUIC protocol, it seem= s impossible to have an independent QUIC firewall perform source address va= lidation before letting packets through to the server.


So, there are clearly classes of source addres= s validation, some of which simply verify that the source address is from a= subnet appropriate to the packet ingress port.=C2=A0 Those are unaffected = by QUIC and, depending on where you put the firewall/NFV instance doing thi= s work, they may be sufficient for many use cases.

If you place the firewall further away the access nodes, this gets more di= fficult as there is a higher chance that the device emitting the packet is = on your network but not entitled to use the source address.=C2=A0 In that c= ase, you apparently want an on-path device to be able to signal to the orig= in that it requires verification that the origin sent the packet.=C2=A0 Abs= ent a signalling path, you seem to have two classes of verification:=C2=A0 = drop the initial packet and confirm intent by watching for a retry after a = timeout period.=C2=A0 (This is absolutely hideous from a latency perspectiv= e, and I can hear all the HTTP use case people screaming about bandwidth de= lay products in my head, so don't do this or they may show up at your o= ffice with whiteboards and colored ink).=C2=A0 The other option is to allow= the initial packet and watch for the handshake completion, closing the pin= hole when it fails to complete.=C2=A0 This does not have a latency impact, = but it will allow some single-packet traffic flows to egress if standard BC= P 38 rules did not catch them.=C2=A0 The working group is trying pretty har= d to make sure that those attacks don't turn in to amplification attack= s, and I hope you'll help in that endeavor.

Ideally, the firewall might have special hardware to generate the Retry packet in response to Initial packets received and then only let= traffic through once the client responded to the Retry packet. This wouldn= =E2=80=99t work though, because TLS authenticates the transcript of the con= nection. The actual QUIC server would drop the connection if it didn=E2=80=99t original the Retry packet and associat= ed HelloRetryRequest. Is this something that QUIC should support?=


<= div>If you're asking if there should be an explicit signal than an on-p= ath device could send that asked for verification, the short answer is a qu= estion:=C2=A0 how do you instantiate the trust to prevent that from being a= n avenue of attack?=C2=A0 (Split client models and server farms that share = roots of trust or keys more or less know how to do this.=C2=A0 But a firewa= ll typically isn't trusted to be a party to the communication, for the = Random WiFi attachment use case and many others).

<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

=C2=A0

And if this is something that QUIC should support, I= have a follow up question. Because all packets are encrypted, how would we= expect a hardware firewall to ever get close to matching the performance o= f a TCP equivalent firewall? It seems to be a lot more difficult (expensive) to protect QUIC from attacks than T= CP.

=C2=A0

I thi= nk source address validation mainly protects the network from spoof traffic= (See RFC 6959 for much better and more complete descriptions), rather than= protecting the traffic.=C2=A0 So when you say "protect QUIC from atta= cks", I'm not sure exactly what you mean.=C2=A0 Would you mind goi= ng into a bit more detail on what you need?

regard= s,

Ted Hardie


=C2=A0

Thanks,

- Nick Banks


--001a114058a49e6050055effadff-- From nobody Mon Nov 27 16:29: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 7986C129417 for ; Mon, 27 Nov 2017 16:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.009 X-Spam-Level: X-Spam-Status: No, score=-3.009 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_H5=-1, 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=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 hz8a78JLOcZ7 for ; Mon, 27 Nov 2017 16:29:28 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0093.outbound.protection.outlook.com [104.47.38.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16329128AA1 for ; Mon, 27 Nov 2017 16:29:28 -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=clYcLpGHEvKM4TlDVVGnDunbSJlmO3RYlD3ctB0GOFA=; b=Smnls9reE2iRfhFOL+t+0wDSEgrG/wqof4Woal20nnmoPuTVHfZfpWEnJ1Pekjwx+3u20sOtgnOyRkyQb7Fl1zgVbTPatzUqkuGrIc9jCWzfgAzDod1e4G2IXLGhrGpFid1KjxshFv0LqmGCYb4UyJosrk9rogJ37Aqh1Kbrr0Q= Received: from BN6PR21MB0178.namprd21.prod.outlook.com (10.173.200.12) by BN6PR21MB0817.namprd21.prod.outlook.com (10.173.204.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.302.0; Tue, 28 Nov 2017 00:29:25 +0000 Received: from BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) by BN6PR21MB0178.namprd21.prod.outlook.com ([10.173.200.12]) with mapi id 15.20.0302.001; Tue, 28 Nov 2017 00:29:25 +0000 From: Nick Banks To: Ted Hardie CC: "quic@ietf.org" Subject: RE: Independent QUIC Firewall Thread-Topic: Independent QUIC Firewall Thread-Index: AdNnx7j6IOTAAe2ORW6ZmaqnN0YSzQAE9HyAAACpCrc= Date: Tue, 28 Nov 2017 00:29:25 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.56.240.35] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BN6PR21MB0817; 6:Bl628raJQyHTbfAckaeuxN6sStC6FsfWA5oh4sBx2LDtH8cexjkCaPiWOIuZbngbkvzGpJthSQJ5qnDx678K7O62iskKefwEFdbKxkKHZfTwmu+1xEKURAda9yRUZ9XnqPGMgq+05uRFg6ifWrwdARjdiPYmf0/qzyqo18VYfdNGNdanFfnK0kKEZg4YeTXAS80+YgTqAkyhqBfYKNed6SSht7DkMJki2Vn/xnZ5l/evkLzFJQbp9jUQHAYvJzf84oFaNyrV0UDM+w3pQHrDjS2KnGsZrTLB1oNzVIOvCzPfp0YNiJ7GueDIgZbLmdfP2ic2zsw0GpOFOSRJkPTpsqCTlFxq/ojYK7eGJfi0qTI=; 5:zn7v0T16gDE63aMAEs+ubHssROBKRm3E23Z6uEG2+XNCsy8s1K3X28s3EfF4e1sT29xqzRiIWgWlusoRmUrKbq7Ap8ToNv6hD0f+JPksoeINISqf4kwGE2U1YmDXf4VDn8t34+/0A/BeZoJh+waqT7nlJO7qPt5gy/rWfxHQCpA=; 24:woJ72FM+d8BoZGcME/dgXsupfNCeIFsYNLdiWBASh4MTQ+39MdErbgT3xWzl5/pf2r0iBz9zmYTqUJUsGpmFISMPaZguT7IGmyiGWFW8Kkg=; 7:sIDuMgAcmZYpbmCpLNFn3OrpBtjzS61bmdiqb0bZOsLAtW7Y/w+q+MHdMPJ1q+t2PT6j099GOrZcfXHL5S41ZEe1BCx0z9O3IpovYKeWtE2y9vaaOZI0I+6qTHJERL+dFeZLYdt9i8AO41K/l4CA2n3T+1BB7pMLw6sOB0Uhrnmha1T18BTZI0GqEZY1twBAg4ywkx4A1pefS7TlePQvNw9RT9EI3Qa3F2WMaX2zHsPxrQP7vLXmuB4ZihEP9LGg x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 3b761dab-69b9-4617-cfe5-08d535f7142a x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(48565401081)(2017052603258); SRVR:BN6PR21MB0817; x-ms-traffictypediagnostic: BN6PR21MB0817: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nibanks@microsoft.com; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231022)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123562025)(20161123564025)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR21MB0817; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BN6PR21MB0817; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(366004)(47760400005)(189002)(51914003)(199003)(24454002)(99286004)(86612001)(106356001)(105586002)(6506006)(86362001)(6436002)(22452003)(316002)(4326008)(10090500001)(229853002)(7696005)(68736007)(5890100001)(97736004)(25786009)(77096006)(101416001)(33656002)(478600001)(54896002)(55016002)(3660700001)(9686003)(236005)(3480700004)(2950100002)(102836003)(7736002)(10290500003)(3846002)(6116002)(6916009)(53936002)(5660300001)(2900100001)(14454004)(53546010)(8676002)(81156014)(81166006)(3280700002)(74316002)(189998001)(2906002)(8990500004)(76176999)(39060400002)(54356999)(66066001)(50986999)(7116003)(8936002)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR21MB0817; H:BN6PR21MB0178.namprd21.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_BN6PR21MB0178BC6A748C4C7A7F9DA30DB33A0BN6PR21MB0178namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3b761dab-69b9-4617-cfe5-08d535f7142a X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 00:29:25.3556 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR21MB0817 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 00:29:30 -0000 --_000_BN6PR21MB0178BC6A748C4C7A7F9DA30DB33A0BN6PR21MB0178namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Thanks for the info Ted. I=92m sorry I wasn=92t clear about the attack. I w= as referring mostly to a Slowloris attack. A specialized HW firewall could = be made to just use source address validation to try to reduce half open co= nnections and reduce the actual load on the real server. I was also thinking of the attack surface where the attacker sends a valid = long header with junk payload. The server will waste cycles trying to decry= pt it. Sent from my Windows 10 phone ________________________________ From: Ted Hardie Sent: Monday, November 27, 2017 3:57:55 PM To: Nick Banks Cc: quic@ietf.org Subject: Re: Independent QUIC Firewall Hi Nick, On Mon, Nov 27, 2017 at 2:03 PM, Nick Banks > wrote: Hello, With the current state of the QUIC protocol, it seems impossible to have an= independent QUIC firewall perform source address validation before letting= packets through to the server. So, there are clearly classes of source address validation, some of which s= imply verify that the source address is from a subnet appropriate to the pa= cket ingress port. Those are unaffected by QUIC and, depending on where yo= u put the firewall/NFV instance doing this work, they may be sufficient for= many use cases. If you place the firewall further away the access nodes, this gets more dif= ficult as there is a higher chance that the device emitting the packet is o= n your network but not entitled to use the source address. In that case, y= ou apparently want an on-path device to be able to signal to the origin tha= t it requires verification that the origin sent the packet. Absent a signa= lling path, you seem to have two classes of verification: drop the initial= packet and confirm intent by watching for a retry after a timeout period. = (This is absolutely hideous from a latency perspective, and I can hear all= the HTTP use case people screaming about bandwidth delay products in my he= ad, so don't do this or they may show up at your office with whiteboards an= d colored ink). The other option is to allow the initial packet and watch = for the handshake completion, closing the pinhole when it fails to complete= . This does not have a latency impact, but it will allow some single-packe= t traffic flows to egress if standard BCP 38 rules did not catch them. The= working group is trying pretty hard to make sure that those attacks don't = turn in to amplification attacks, and I hope you'll help in that endeavor. Ideally, the firewall might have special hardware to generate the Retry pac= ket in response to Initial packets received and then only let traffic throu= gh once the client responded to the Retry packet. This wouldn=92t work thou= gh, because TLS authenticates the transcript of the connection. The actual = QUIC server would drop the connection if it didn=92t original the Retry pac= ket and associated HelloRetryRequest. Is this something that QUIC should su= pport? If you're asking if there should be an explicit signal than an on-path devi= ce could send that asked for verification, the short answer is a question: = how do you instantiate the trust to prevent that from being an avenue of a= ttack? (Split client models and server farms that share roots of trust or = keys more or less know how to do this. But a firewall typically isn't trus= ted to be a party to the communication, for the Random WiFi attachment use = case and many others). And if this is something that QUIC should support, I have a follow up quest= ion. Because all packets are encrypted, how would we expect a hardware fire= wall to ever get close to matching the performance of a TCP equivalent fire= wall? It seems to be a lot more difficult (expensive) to protect QUIC from = attacks than TCP. I think source address validation mainly protects the network from spoof tr= affic (See RFC 6959 for much better and more complete descriptions), rather= than protecting the traffic. So when you say "protect QUIC from attacks",= I'm not sure exactly what you mean. Would you mind going into a bit more = detail on what you need? regards, Ted Hardie Thanks, - Nick Banks --_000_BN6PR21MB0178BC6A748C4C7A7F9DA30DB33A0BN6PR21MB0178namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Thanks for the info Ted. I=92m sorry I wasn=92t clea= r about the attack. I was referring mostly to a Slowloris attack. A special= ized HW firewall could be made to just use source address validation to try= to reduce half open connections and reduce the actual load on the real server.

 

I was also thinking of the attack surface where the = attacker sends a valid long header with junk payload. The server will waste= cycles trying to decrypt it.

 

Sent from my Windows 10 phone

 

From: Ted Hardie <ted.ie= tf@gmail.com>
Sent: Monday, November 27, 2017 3:57:55 PM
To: Nick Banks
Cc: quic@ietf.org
Subject: Re: Independent QUIC Firewall
 
Hi Nick,

On Mon, Nov 27, 2017 at 2:03 PM, Nick Banks <nibanks@micr= osoft.com> wrote:

Hello,

 

With the current state of the QUIC protocol, it seem= s impossible to have an independent QUIC firewall perform source address va= lidation before letting packets through to the server.


So, there are clearly classes of source address validation, some of wh= ich simply verify that the source address is from a subnet appropriate to t= he packet ingress port.  Those are unaffected by QUIC and, depending o= n where you put the firewall/NFV instance doing this work, they may be sufficient for many use cases.

If you place the firewall further away the access nodes, this gets mor= e difficult as there is a higher chance that the device emitting the packet= is on your network but not entitled to use the source address.  In th= at case, you apparently want an on-path device to be able to signal to the origin that it requires verification th= at the origin sent the packet.  Absent a signalling path, you seem to = have two classes of verification:  drop the initial packet and confirm= intent by watching for a retry after a timeout period.  (This is absolutely hideous from a latency perspective, and = I can hear all the HTTP use case people screaming about bandwidth delay pro= ducts in my head, so don't do this or they may show up at your office with = whiteboards and colored ink).  The other option is to allow the initial packet and watch for the handshake completi= on, closing the pinhole when it fails to complete.  This does not have= a latency impact, but it will allow some single-packet traffic flows to eg= ress if standard BCP 38 rules did not catch them.  The working group is trying pretty hard to make sure tha= t those attacks don't turn in to amplification attacks, and I hope you'll h= elp in that endeavor.

Ideally, the firewall might have special hardware to= generate the Retry packet in response to Initial packets received and then= only let traffic through once the client responded to the Retry packet. Th= is wouldn=92t work though, because TLS authenticates the transcript of the connection. The actual QUIC server wou= ld drop the connection if it didn=92t original the Retry packet and associa= ted HelloRetryRequest. Is this something that QUIC should support?


If you're asking if there should be an explicit signal than an on-path= device could send that asked for verification, the short answer is a quest= ion:  how do you instantiate the trust to prevent that from being an a= venue of attack?  (Split client models and server farms that share roots of trust or keys more or less know how t= o do this.  But a firewall typically isn't trusted to be a party to th= e communication, for the Random WiFi attachment use case and many others).<= br>

 

And if this is something that QUIC should support, I= have a follow up question. Because all packets are encrypted, how would we= expect a hardware firewall to ever get close to matching the performance o= f a TCP equivalent firewall? It seems to be a lot more difficult (expensive) to protect QUIC from attacks than T= CP.

 

I think source address validation mainly protects the network from spo= of traffic (See RFC 6959 for much better and more complete descriptions), r= ather than protecting the traffic.  So when you say "protect QUIC= from attacks", I'm not sure exactly what you mean.  Would you mind going into a bit more detail on what you ne= ed?

regards,

Ted Hardie


 

Thanks,

- Nick Banks


--_000_BN6PR21MB0178BC6A748C4C7A7F9DA30DB33A0BN6PR21MB0178namp_-- From nobody Mon Nov 27 23:01: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 915B012762F for ; Mon, 27 Nov 2017 23:01:27 -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 9ImqM6dJk18L for ; Mon, 27 Nov 2017 23:01:25 -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 644281200E5 for ; Mon, 27 Nov 2017 23:01:25 -0800 (PST) X-AuditID: c1b4fb25-d91ff700000020f7-fc-5a1d09c351f2 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 0D.55.08439.3C90D1A5; Tue, 28 Nov 2017 08:01:23 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.352.0; Tue, 28 Nov 2017 08:01:22 +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=o5oiScjROaGS3pW0xE8w0CuMTmexSJv79wJO7bvLv6M=; b=VGQSOUd8IPO7QxX5frdSUwody4+K8LM3lLUVqVkMR7L6qkBTs+PYApeKr2umJEMBg7mlzty4r6blPmjJoVDfZbfuqZ5yp6GH2PeuRzKZiR9WtGstUDoEMhOregyw6Z2iBdmP4m/Z5k+SHgLy/yarXEQ7NUhuOt365T2ms4MF2tM= 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_P256) id 15.20.282.3; Tue, 28 Nov 2017 07:01:21 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::e0fd:9f9f:e232:b301]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::e0fd:9f9f:e232:b301%16]) with mapi id 15.20.0282.002; Tue, 28 Nov 2017 07:01:21 +0000 From: Ingemar Johansson S To: Roland Zink , Christian Huitema CC: "Gorry (erg)" , "quic@ietf.org" Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTZ4HIwy7AvHmC906Tq5O1smuWkqMoQU8wgAANGoCAAB6/AIAAED4AgAAHW4CAABzeAIAAucGA Date: Tue, 28 Nov 2017 07:01:21 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@erg.abdn.ac.uk> <74e1c7bd-bd09-3285-db25-db04fe530cbc@zinks.de> <34BF55EB-8B3E-453C-BAFE-8048B4B94FC5@huitema.net> <54e419d4-e4c0-2e9e-93ab-6ff7750e483a@zinks.de> <118af13a-4aa7-4240-e67a-ba489e524166@zinks.de> In-Reply-To: <118af13a-4aa7-4240-e67a-ba489e524166@zinks.de> 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: [83.226.2.151] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 6:R3El+3Qspoiu1Prwl9x4PAp33rM19PXCfvZAbMU0nhDiVvn1Lu141ueYHrlogQLC4iwekFvcmH3awzM8irC+bAW9TJN+Him0ikaxoK71GikDt6AO9OliJA8goPpIfT8hqEBpnAVpDeI9t/ALjdWHZrZOe6fDe22f9bm4YhxFQvGLA+uiahzGfTlNtwt5P53PVufvt34KSSurvKEouxow/+DQGX3IWzbasp/F+LrijZHml29sTqQtgd1ryTpwbd6vfD72MLY9kRBanciRxbH3Pg0B3+YFqCpw+Pe9QHbb/8XPJPXa66VRl0LayM+MJH3DA8xU9edqK89y5viwR63MVggEBkCNq4pi0ilEPVYgvKY=; 5:xcKLRDWHvNbspsuKux1WHIpIOa3rQvjFWSBr0AUHMv/ziANSL5Fjgcegw850ORU60ewuwsPyZgeMhA8r4+CJ54d5/3eNW6XX3g3MPlTZXqrdoD7m9fJeTsUrZYaFyjqCI5lY3O64Bg/Zp9nc8ixyJPjGEzRY8KjyWtbGEMahW+w=; 24:vRqGrmwTLKwi1TsBxgewQmcX1YWnDhhoNjwYi79NbMoL7ewcMjRDdSjzj4bQ+hpMOz3Xy7wqaMlDg6CPZVVuY/oDi93R6QMZZU0JYO3TPhk=; 7:meRO66zw7ZzRX77Rkkmp9TMgKwK9EwinMggAZJnxA6bwHcnZqn5lt2Zq/C3P3Fkwuido0eAmY3rN+nb4S3wb7gUXD5m5IstZFG5OwR5o+imOTWyM/w/RbnYqRyh398FH5SG2Hkk+ypOCb+92Ch9KWffBl0Zt1I2MJLAIDGY4KhKkg3fBoB+hGgYes1tuGHa1ppM3Xxag+LeV2JMIqlZA1Zw5o/vxXxoU8mLxLfqSg7t89gnQQLH0cENnxs8eU/ef x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ae0e02cb-ddec-488e-4455-08d5362dd4e2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603199); SRVR:DB4PR07MB348; x-ms-traffictypediagnostic: DB4PR07MB348: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040450)(2401047)(8121501046)(5005006)(10201501046)(3231022)(93006095)(93001095)(3002001)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123555025)(20161123562025)(20161123560025)(20161123564025)(6072148)(201708071742011); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:DB4PR07MB348; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(376002)(346002)(39860400002)(24454002)(13464003)(199003)(189002)(93886005)(68736007)(53546010)(2900100001)(189998001)(3660700001)(2906002)(3280700002)(54906003)(316002)(5660300001)(25786009)(86362001)(33656002)(5250100002)(6436002)(6506006)(8676002)(110136005)(81156014)(81166006)(4326008)(55016002)(229853002)(2950100002)(53936002)(9686003)(8936002)(14454004)(101416001)(6246003)(478600001)(97736004)(66066001)(6306002)(7696005)(3846002)(74316002)(105586002)(102836003)(54356999)(50986999)(305945005)(7736002)(6116002)(106356001)(76176999)(99286004); 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-Network-Message-Id: ae0e02cb-ddec-488e-4455-08d5362dd4e2 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 07:01:21.5351 (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: H4sIAAAAAAAAA02SbUhTURjHObtn23U2uk3FB18wR35Y0UwTGiFRUDAN0W/VLGy6my512q6J ih80Qkqdlm/5ArlSspIya6HFBDfxlcTU/KA0Tabme6HJNGvl3V3Qt9/5/5//85zzcEhCUsv3 I7W6LFqvU6dJBSJcd7Hj/NEej0DVsdZtmWKlqAEpKgsbhIpSo6fiie0jPo2VpZuLPOVU7RBW Njfv8JS/m74L47BKFKmh07TZtD701FVRSl1BjTCzPiBn2L6ICpDZvxh5kEBFQGv3J2ExEpES qgfBcPkv92EAganWhNkDpgwEtMxa+JxTw4OZYTvB5iXULIL+6hssC6hIeGZ1IJa9qWhwvujf a0WSBBUFNdVqVvaiwuDWlxXMlYRD0fodAccqGP1cymcZUyEwY6x0sXhPX9row9zcCQF02Qtd hsferPmGdVcYUYEw45h2NSUoX5iaa+Rxb6Og2TxCcOwDS3Ynn6tPgo1JA5/TD4KtwujmQBhr LEHsMKAsQnjVvoU5Qw5v768hjmNgYsDJ44qaEBh7P7jTMnjX6HAHtLCxMOIOXIbtvi5314cE dDrZDbNGAPxZMOF7SF7/383rXRuTQdv7UE4OhqqSWWG9axsHYLBuDhsRfo58GJpJTE8OPy6n 9dokhsnQyXV01mu0918spt2QTjS+esaKKBJJ94kv4UCVhK/OZnLTrQhIQuotnhwNUEnEGnVu Hq3PSNDfTKMZK/InsdRXPBglVkmoZHUWnUrTmbT+n8sjPfwKEK9s2p68GGwO+qaKXI3unltu j10ra9/82mtr0cUcKvW6YHjwMsLkF2NZK4nN9H1DnzshS0yI35onHu88mfI0jAcNpT7azb/e lNfeKoq7XXUkp+KuZ5zZwH965Ud4t7GjzXQSNBpr2dhUfMl+nl8H7Tjrabu2LCDKZ+S9yp/5 w1LMpKjDDhN6Rv0Xp+oWsisDAAA= Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 07:01:28 -0000 SGkNCg0KSSByZWFsbHkgZG9uJ3Qgc2VlIHRoYXQgUVVJQyBpcyBhYmxlIHRvIHNvbHZlIHRoaXMg KGNvbmdlc3Rpb24pIGlzc3VlLiANCkkgcG9pbnRlZCBvdXQgQ29uRXggKHNlZSBlZy4gUkZDNjc4 OSkgYXMgb25lIHNvbHV0aW9uLiBBbmQgYXMgQ2hyaXN0aWFuIHBvaW50ZWQgb3V0LCBvcGVyYXRv cnMgYWxyZWFkeSB1c2UgcmF0ZSBzaGFwaW5nIG9yIHBvbGljaW5nIG9yIGxpbWl0IHRoZSBhbW91 bnQgb2YgZGF0YS4NCg0KRmluYWxseSwgZXZlbiB0aG91Z2ggdGhlcmUgY2FuIGJlIHJlYXNvbnMg dG8gaGFjayBhIGNvbmdlc3Rpb24gY29udHJvbCBhbGdvcml0aG0gdGhhdCB3aWxsIGhlbHAgeW91 ciBRVUlDIGNvbm5lY3Rpb24gdG8gb3V0Y29tcGV0ZSBvdGhlciBmbG93cywgaXQgYWxzbyBjb21l cyB3aXRoIHRoZSByaXNrIHRoYXQgc2FpZCBjb25uZWN0aW9uIGJsb2F0cyBpdHMgb3duIGxhc3Qg bWlsZSBhY2Nlc3MgbGluay4gU28gaW4gdGhlIGVuZCB5b3UgY3JlYXRlIG1vc3Qgb2YgdGhlIHBy b2JsZW1zIGZvciB5b3Vyc2VsZi4gRm9yIGluc3RhbmNlIHlvdXIgTFRFIGNvbm5lY3Rpb24gd2ls bCBvbmx5IHJld2FyZCB5b3Ugd2l0aCBlaXRoZXIgaGlnaCBSVFQgb3IgaGlnaCBsb3NzIG9yIGJv dGggaWYgeW91ciBjb25nZXN0aW9uIGNvbnRyb2wgaXMgbm90IGVub3VnaCByZXNwb25zaXZlIHRv IGNvbmdlc3Rpb24gc2lnbmFscy4gDQoNCi9JbmdlbWFyDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogUm9sYW5kIFppbmsgW21haWx0bzpyb2xhbmRAemlua3MuZGVdDQo+ IFNlbnQ6IGRlbiAyNyBub3ZlbWJlciAyMDE3IDIwOjQ2DQo+IFRvOiBDaHJpc3RpYW4gSHVpdGVt YSA8aHVpdGVtYUBodWl0ZW1hLm5ldD4NCj4gQ2M6IEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2Vt YXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPjsgR29ycnkgKGVyZykNCj4gPGdvcnJ5QGVyZy5h YmRuLmFjLnVrPjsgcXVpY0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogU3BpbiBiaXQgZGlzY3Vz c2lvbiAtIHdoZXJlIHdlJ3JlIGF0DQo+IA0KPiBJIGFncmVlIGl0IGlzIG5vdCBvbmx5IFFVSUMu IEkgYWxzbyBkb24ndCB0aGluayBpdCBpcyBuZWNlc3NhcnkgdG8gcGFuaWMgbm93LiBXZQ0KPiBo YXZlIGlzc3VlICM3NDANCj4gKGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMv aXNzdWVzLzc0MCkgYWJvdXQgYWRkaW5nIGEgc2VjdXJpdHkNCj4gaXNzdWVzIHNlY3Rpb24gd2Vy ZSBleGlzdGluZyBtZWFucyBjb3VsZCBiZSBhZGRlZC4gV2hlbiBRVUlDIGNhbiBoZWxwIHRvDQo+ IGFkZHJlc3Mgc3VjaCBpc3N1ZXMgaXQgY2FuIGJlY29tZSBtb3JlIHJlbGlhYmxlIHNvIEkgd291 bGRuJ3Qgc2F5IHRoaXMgaXMgb3V0DQo+IG9mIHNjb3BlIGp1c3QgYmVjYXVzZSBvdGhlciBwcm90 b2NvbHMgaGF2ZSBzaW1pbGFyIGlzc3Vlcy4gSWYgaXQgcmVhbGx5IHR1cm5zIG91dA0KPiB0aGF0 IHRoZSBjdXJyZW50IG1pdGlnYXRpb25zIGFyZSBub3Qgc3VmZmljaWVudCB0aGVuIHdvcmsgb24g YmV0dGVyIHF1ZXVlDQo+IG1hbmFnZW1lbnQgYWxnb3JpdGhtIHdpbGwgcHJvYmFibHkgY29tZSB0 b28gbGF0ZS4NCj4gDQo+IA0KPiBSb2xhbmQNCj4gDQo+IA0KPiANCj4gQW0gMjcuMTEuMjAxNyB1 bSAxOTowMiBzY2hyaWViIENocmlzdGlhbiBIdWl0ZW1hOg0KPiA+IE9uIDExLzI3LzIwMTcgOToz NiBBTSwgUm9sYW5kIFppbmsgd3JvdGU6DQo+ID4NCj4gPj4gSWYgUVVJQyBtYWtlcyB0aGUgcHJv YmxlbSBjcnlzdGFsIGNsZWFyIHRoZW4gbm93IHNlZW1zIHRvIGJlIGEgZ29vZA0KPiA+PiB0aW1l IHRvIHNvbHZlIG9yIG1pdGlnYXRlIGl0IGJlZm9yZSByaXNraW5nIGl0IGJlY29tZXMgYSByZWFs IHdvcmxkDQo+ID4+IHByb2JsZW0uDQo+ID4gRmlyc3QsIGxldCdzIHN0YXJ0IGJ5IGFncmVlaW5n IHRoYXQgdGhpcyBpcyBub3QgYSBwcm9ibGVtIHNwZWNpZmljIFFVSUMuDQo+ID4gWW91IGNvdWxk IHNheSB0aGUgc2FtZSBhYm91dCBCaXQgVG9ycmVudCwgYW55IHByb3RvY29sIHRoYXQgc2VuZHMN Cj4gPiB2aWRlbyBvdmVyIFVEUCwgb3IgYW55IGFwcGxpY2F0aW9uIHRoYXQgb3BlbnMgbXVsdGlw bGUgVENQIGNvbm5lY3Rpb24uDQo+ID4gU28sIHllcywgdGhlcmUgbWF5IHdlbGwgYmUgYSBwcm9i bGVtLCBidXQgc2luY2UgaXQgaXMgbm90IHNwZWNpZmljIHRvDQo+ID4gUVVJQyB0aGUgbWl0aWdh dGlvbiBkb2VzIG5vdCBoYXZlIHRvIGJlIHNwZWNpZmljIHRvIFFVSUMgZWl0aGVyLg0KPiA+DQo+ ID4gQnV0IGxldCdzIG5vdCBwYW5pYy4gUHJhY3RpY2FsIG1pdGlnYXRpb24gaGFzIHN0YXJ0ZWQg bG9uZyBhZ28sIHdpdGgNCj4gPiBJU1BzIGVmZmVjdGl2ZWx5IGNvbnRyb2xsaW5nIGhvdyBtdWNo IGRhdGEgY2FuIGJlIHNlbnQgdGhyb3VnaCBhDQo+ID4gY3VzdG9tZXIncyB1cC1saW5rLiBNYXli ZSB0aGVzZSBjdXJyZW50IG1pdGlnYXRpb25zIGFyZSBub3QNCj4gPiBzdWZmaWNpZW50LCBidXQg aWYgdGhhdCBpcyB0aGUgY2FzZSBJIHdvdWxkIGV4cGVjdCBtb3JlIHdvcmsgb24gYmV0dGVyDQo+ ID4gcXVldWUgbWFuYWdlbWVudCBhbGdvcml0aG0uDQo+ID4NCj4gPiAtLSBDaHJpc3RpYW4gSHVp dGVtYQ0KPiA+DQoNCg== From nobody Tue Nov 28 02:52: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 474801200F3 for ; Tue, 28 Nov 2017 02:52:41 -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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 gV7oOGmxDXGK for ; Tue, 28 Nov 2017 02:52:38 -0800 (PST) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::4]) (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 E0E47126BF0 for ; Tue, 28 Nov 2017 02:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1511866355; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:Message-ID:From:References:Cc:To:Subject:X-RZG-CLASS-ID: X-RZG-AUTH:Accept-Language:Auto-Submitted:Cc:Date:From:Message-ID: References:Reply-To:Resent-Cc:Resent-Date:Resent-From:Resent-To: Sender:Subject:To:Content-Alternative:Content-Description: Content-Disposition:Content-Duration:Content-Features:Content-ID: Content-Language:Content-Location:Content-MD5: Content-Transfer-Encoding:Content-Type:MIME-Version; bh=A4pL8gosaqgaJ3fIUIJGwU6+9ytPOdRZpDV6UVtk49Y=; b=y5si+MmdzH2M3a6DVHKkQLKMlz3jTW2NrIt9NVNuYOJIzkYj6hXBcY0v2RASnrwO++ BSGPQC+hcGnxBXuGESzAM5UY6TYptUG2lo6mpq69BkRbdOyhwPi2vLft209WuQ7mdVHO KbvQZGASMq4hrtu1U74PDxc8MyDp/estJcc3o= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKm0oaa3tXPmHrk4rPs X-RZG-CLASS-ID: mo00 Received: from [10.10.10.80] (p5DCF5713.dip0.t-ipconnect.de [93.207.87.19]) by smtp.strato.de (RZmta 42.10 DYNA|AUTH) with ESMTPSA id e03071tASAqRBnt (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Tue, 28 Nov 2017 11:52:27 +0100 (CET) Subject: Re: Spin bit discussion - where we're at To: Ingemar Johansson S , Christian Huitema Cc: "Gorry (erg)" , "quic@ietf.org" References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <07ef04d5-b211-e605-9f66-fe0ecefa5425@zinks.de> <989A02DE-F8CE-4A50-A2F3-E595B5D4931D@erg.abdn.ac.uk> <74e1c7bd-bd09-3285-db25-db04fe530cbc@zinks.de> <34BF55EB-8B3E-453C-BAFE-8048B4B94FC5@huitema.net> <54e419d4-e4c0-2e9e-93ab-6ff7750e483a@zinks.de> <118af13a-4aa7-4240-e67a-ba489e524166@zinks.de> From: Roland Zink Message-ID: Date: Tue, 28 Nov 2017 11:52:27 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 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.22 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 Nov 2017 10:52:41 -0000 Taking the spin bit and LTE as an example does it help? Assuming you placed an app on my phone and you activate it to do a DoS attack to bloat my own last mile access link. Then the RTT should go up for all the connections of my phone and the spin bit would allow to measure the RTT giving a hint what is going on. It's only a small piece of information but it may help. Even worse would be if the LTE scheduler use a single queue for all phones of the cell and you fill the queue with useless packets doing a DoS attack to all users of a LTE cell. Here most implementations already seem to act fair against users resource block allocation and give them equal shares but your mileage may vary. Of cause you can do the same attack today when you root / jailbreak my phone. Similar you can just use the amount of packets send/received but in LTE you don't know from this value if the link is saturated or not. Regards, Roland Am 28.11.2017 um 08:01 schrieb Ingemar Johansson S: > Hi > > I really don't see that QUIC is able to solve this (congestion) issue. > I pointed out ConEx (see eg. RFC6789) as one solution. And as Christian pointed out, operators already use rate shaping or policing or limit the amount of data. > > Finally, even though there can be reasons to hack a congestion control algorithm that will help your QUIC connection to outcompete other flows, it also comes with the risk that said connection bloats its own last mile access link. So in the end you create most of the problems for yourself. For instance your LTE connection will only reward you with either high RTT or high loss or both if your congestion control is not enough responsive to congestion signals. > > /Ingemar > >> -----Original Message----- >> From: Roland Zink [mailto:roland@zinks.de] >> Sent: den 27 november 2017 20:46 >> To: Christian Huitema >> Cc: Ingemar Johansson S ; Gorry (erg) >> ; quic@ietf.org >> Subject: Re: Spin bit discussion - where we're at >> >> I agree it is not only QUIC. I also don't think it is necessary to panic now. We >> have issue #740 >> (https://github.com/quicwg/base-drafts/issues/740) about adding a security >> issues section were existing means could be added. When QUIC can help to >> address such issues it can become more reliable so I wouldn't say this is out >> of scope just because other protocols have similar issues. If it really turns out >> that the current mitigations are not sufficient then work on better queue >> management algorithm will probably come too late. >> >> >> Roland >> >> >> >> Am 27.11.2017 um 19:02 schrieb Christian Huitema: >>> On 11/27/2017 9:36 AM, Roland Zink wrote: >>> >>>> If QUIC makes the problem crystal clear then now seems to be a good >>>> time to solve or mitigate it before risking it becomes a real world >>>> problem. >>> First, let's start by agreeing that this is not a problem specific QUIC. >>> You could say the same about Bit Torrent, any protocol that sends >>> video over UDP, or any application that opens multiple TCP connection. >>> So, yes, there may well be a problem, but since it is not specific to >>> QUIC the mitigation does not have to be specific to QUIC either. >>> >>> But let's not panic. Practical mitigation has started long ago, with >>> ISPs effectively controlling how much data can be sent through a >>> customer's up-link. Maybe these current mitigations are not >>> sufficient, but if that is the case I would expect more work on better >>> queue management algorithm. >>> >>> -- Christian Huitema >>> From nobody Tue Nov 28 08:22: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 0B5E7128891 for ; Tue, 28 Nov 2017 08:22: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, 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=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 Ng_kTBrWeTKU for ; Tue, 28 Nov 2017 08:22:02 -0800 (PST) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 CE82B127B73 for ; Tue, 28 Nov 2017 08:22:01 -0800 (PST) Received: from pps.filterd (m0122330.ppops.net [127.0.0.1]) by mx0b-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vASGLr87011517; Tue, 28 Nov 2017 16:21:53 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=dPA3a4Nx++s2n3UHkCwMiOE578n6A/gi/kYfUvJhxY8=; b=pMD6AARcetjBnwsaxdP7Mte0qIrE9+Zw+9neBctFyW4q0fEXjnLl1xuCKwOmYoSDxDgV r7uKjog30RaVlzzv33avR23tbLJSF5nQF7dVtOx8M09d0az6hf5Em45qP6HGVZ9RJDEs BfeIFKFjfyFS0R3biEkbH6xUxoqXUQKxI2KVIjgplDg0rQ/Xs9e2TgrQ788LFhNmTyLm RApYI4yMxnCTOzRqZPGwR+Gf9ozz0ISb2HKjqFrHg/5g1s/3m6UwP6CdnEtQB872flX0 mVw2NuurUkU61wP39pG5MjJvyCY3KimMpcuT9ADTaYSsAseHRBxPE9dne8gQmdX1QURE +A== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2ef11wgx1v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 28 Nov 2017 16:21:53 +0000 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vASGLTfW018456; Tue, 28 Nov 2017 11:21:52 -0500 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint2.akamai.com with ESMTP id 2ef4qymgen-1; Tue, 28 Nov 2017 11:21:52 -0500 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 9D59E235F7; Tue, 28 Nov 2017 16:21:52 +0000 (GMT) Subject: Re: Spin bit discussion - where we're at - use case exsist!!! To: Roni Even , QUIC WG References: <6E58094ECC8D8344914996DAD28F1CCD8464CB@DGGEMM506-MBX.china.huawei.com> From: Benjamin Kaduk Message-ID: Date: Tue, 28 Nov 2017 10:21:52 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD8464CB@DGGEMM506-MBX.china.huawei.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-28_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711280221 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-28_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1709140000 definitions=main-1711280221 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 16:22:09 -0000 On 11/23/2017 12:13 AM, Roni Even wrote: > >> 1) A description of the use case(s) that motivate this proposal. We >> understand that the goal is to measure RTT, but some people are still unclear >> as to why that's necessary to operate a network. Detailed scenarios and >> ideally real-world examples (e.g., from TCP) would help tremendously. >> Saying "I need to debug the network" is not enough detail. >> > [Roni Even] I submitted such a document but I assume that nobody read it since I would expect that this bullet will at least mention it !!! > > See https://tools.ietf.org/id/draft-even-quic-troubleshooting-video-delivery-00.tx > > Please read the document > Okay, I went and read the document.  I'm not really sure how much it helps me understand the scenarios in question. The high level takeways from my read of the document seem to be: o Streaming video is common, and a common source of end-user complaints when it doesn't work well.  (It also uses a lot of bandwidth.) o A measurement point in the middle of a TCP flow can use TCP segment numbers to estimate RTT for the upstream and downstream halfs of the flow, i.e., a video streaming flow that is largely server-to-client gives a more reliable RTT downstream RTT estimate (i.e., between measurement point and client).  RTT estimates can be noisy due to delayed acks and packet loss. o Such a measurement point can also estimate upstream/downstream loss by examining the sliding window and observing retransmits. For the server-to-client video flow, the downstream loss estimate is again the more reliable one o Home wifi is a common source of problems, and wifi has a unique signature of high RTT combined with low loss.  I guess the idea is supposed to be that a measurement point close to the home network can "blame" the wifi if it sees high RTT but not much loss on the flow in question? o Network operators can use big data analytics to detect deviations from normal network metrics and isolate faulty network segments.  The above RTT and loss metrics at measurement points are used as examples but no claim is made that other metrics would not provide equally functional input for analytics. o The network operator can use RTT/loss estimates from a measurement point near the server as evidence to try to convince the server operator that the server('s network) is misbehaving. While the discussion of how a measurement point can use segment numbers and window information to estimate RTT and loss is useful, I'm not overly concerned about that discussion and am willing to take it as a given. I think what might help me understand the utility of these measurements is a detailed walkthrough of what would happen in some (hypothetical) case where I as a user call up my ISP and complain that youtube is misbehaving, assuming I can get to a point where I'm talking to a human at the ISP that can perform/view this sort of measurement data.  What information does the ISP need from me?  What's the first thing to do -- insert a measurement point as close to my home router as possible to rule (out/in) my wifi?  Or do we start off by engaging multiple measurement points?  Does the "big data" analytics at the network measurement center come into play at all for this walkthrough or is it completely separate? It's also still unclear to me to what extent RTT/loss as input to the network measurement center's analytics is used because it's easy and works vs. what research has been done with using other metrics as input to the analytics. Thanks, Ben From nobody Tue Nov 28 10:11: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 C7670128954 for ; Tue, 28 Nov 2017 10:11:10 -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 Cr9vvBeklkmP for ; Tue, 28 Nov 2017 10:11:09 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::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 B4666127444 for ; Tue, 28 Nov 2017 10:11:08 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id i130so1011562qke.4 for ; Tue, 28 Nov 2017 10:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=67w+AF6/BRCGmSscjaZtJwI61TeRrVaGvXl8rjFrlfU=; b=P+6Li+0U430MbI9O5ilIGYwmJ2lwC28c8//1WS61ZY7q4N3aONlSeOpDRzYnZDd+jX s1BQD5SQF0XLQeCox3/GJlgkU6wLJJ/dInwjY65ZH9sALZuxzu1qWLpUsWr/TYvdsNUd 3GB5//j1yCOkUWYXYq4TFrQfm1lb9U2z9ukBawMnLLKS3PnWQArZzT/+xwPeNRlhITaZ lYEdgs0jN02ZSZ7oWEFryOsSHkuKstd9AQ+Fjk51o2iw8kyZsPDkUy2y53F+H0+SJ27+ fL8QfzP/veht0OlKbqp/dSHUzHrPVGEaoqh5U+sqHadGVtk/F3oed2JWfXqT0OSiHU0r 4Mtg== 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=67w+AF6/BRCGmSscjaZtJwI61TeRrVaGvXl8rjFrlfU=; b=oUPlsBNLW6tbFvx/HHxMbUfIwEAWnA5Uoeyg+uTOFRTyIswTVx2Ty4cXNPbviVbEe+ p/sUpw1mLwXmxTsjSu7i3KwTsLWk6Du8GdRv490jXWgnLjxFwxXgGD34uw9QOirQV31T cXRhjcjkSWgkIZWUDd5mwc8KfeBl2X9VlpuQfZwjMkJGb4XKhGlAzrOUFDACbV72waI7 SAWt/44Fp74SuQ578GKVDf296CUO1Uchu2ACl2GHSobb5hLrCADGeI6J0XQRM8ODLl+W GwTHmCTjb7PZ5P2ufNJSK46pHIFEbXamKELFGU1E/ZZ6y3HmQ/w55lmAM7pqA7KYVu7e Ev+Q== X-Gm-Message-State: AJaThX6yy5Vr9FOyV1tW8Ew+CQpDOY2eSi5b4KVI4ntA4KTlQFkK288d DtqexW2ihNCvTfEBaMLPHCjPfF1SGhGr2uF08EA= X-Google-Smtp-Source: AGs4zMZh/lwvJWr7UJcDMjUbtHYySwZFLjN5/C4tyJhl0+dGslL0omOlp7Pdkj+Bix1K+Qh5dChzKYoKUiAsgK28CM4= X-Received: by 10.55.155.198 with SMTP id d189mr360582qke.347.1511892667648; Tue, 28 Nov 2017 10:11:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.237.36.169 with HTTP; Tue, 28 Nov 2017 10:10:37 -0800 (PST) In-Reply-To: References: From: Ted Hardie Date: Tue, 28 Nov 2017 10:10:37 -0800 Message-ID: Subject: Re: Independent QUIC Firewall To: Nick Banks Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0d040e64d0bb055f0ef1ef" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 18:11:11 -0000 --94eb2c0d040e64d0bb055f0ef1ef Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 27, 2017 at 4:29 PM, Nick Banks wrote: > Thanks for the info Ted. I=E2=80=99m sorry I wasn=E2=80=99t clear about t= he attack. I was > referring mostly to a Slowloris attack. A specialized HW firewall could b= e > made to just use source address validation to try to reduce half open > connections and reduce the actual load on the real server. > > A common mitigation for slowloris-style attacks puts a load-balancer or proxy in front of an affected web server, so that these attacks are caught before being passed to the content server. Doing so in a firewall doesn't work quite as well, because it is not trusted by the content server (and may not be trusted by the client, depending on the network). It's also not clear that source address validation would help that much; after all, in a TCP/TLS connection, the TCP 3-way handshake would have completed before the attack starts (since slowloris sends partial HTTP requests to keep the connection open, it occurs after the source address is deemed valid by all parties). > > > I was also thinking of the attack surface where the attacker sends a vali= d > long header with junk payload. The server will waste cycles trying to > decrypt it. > > Here's the current format of the long header (from section 5.1 of the transport draft) 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 +-+-+-+-+-+-+-+-+ |1| Type (7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Connection ID (64) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Packet Number (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Payload (*) ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Which bits do you see as the subject of the attack? regards, Ted > > > Sent from my Windows 10 phone > > > ------------------------------ > *From:* Ted Hardie > *Sent:* Monday, November 27, 2017 3:57:55 PM > *To:* Nick Banks > *Cc:* quic@ietf.org > *Subject:* Re: Independent QUIC Firewall > > Hi Nick, > > On Mon, Nov 27, 2017 at 2:03 PM, Nick Banks wrote= : > >> Hello, >> >> >> >> With the current state of the QUIC protocol, it seems impossible to have >> an independent QUIC firewall perform source address validation before >> letting packets through to the server. >> > > So, there are clearly classes of source address validation, some of which > simply verify that the source address is from a subnet appropriate to the > packet ingress port. Those are unaffected by QUIC and, depending on wher= e > you put the firewall/NFV instance doing this work, they may be sufficient > for many use cases. > > If you place the firewall further away the access nodes, this gets more > difficult as there is a higher chance that the device emitting the packet > is on your network but not entitled to use the source address. In that > case, you apparently want an on-path device to be able to signal to the > origin that it requires verification that the origin sent the packet. > Absent a signalling path, you seem to have two classes of verification: > drop the initial packet and confirm intent by watching for a retry after = a > timeout period. (This is absolutely hideous from a latency perspective, > and I can hear all the HTTP use case people screaming about bandwidth del= ay > products in my head, so don't do this or they may show up at your office > with whiteboards and colored ink). The other option is to allow the > initial packet and watch for the handshake completion, closing the pinhol= e > when it fails to complete. This does not have a latency impact, but it > will allow some single-packet traffic flows to egress if standard BCP 38 > rules did not catch them. The working group is trying pretty hard to mak= e > sure that those attacks don't turn in to amplification attacks, and I hop= e > you'll help in that endeavor. > > Ideally, the firewall might have special hardware to generate the Retry >> packet in response to Initial packets received and then only let traffic >> through once the client responded to the Retry packet. This wouldn=E2=80= =99t work >> though, because TLS authenticates the transcript of the connection. The >> actual QUIC server would drop the connection if it didn=E2=80=99t origin= al the >> Retry packet and associated HelloRetryRequest. Is this something that QU= IC >> should support? >> >> > If you're asking if there should be an explicit signal than an on-path > device could send that asked for verification, the short answer is a > question: how do you instantiate the trust to prevent that from being an > avenue of attack? (Split client models and server farms that share roots > of trust or keys more or less know how to do this. But a firewall > typically isn't trusted to be a party to the communication, for the Rando= m > WiFi attachment use case and many others). > > >> >> And if this is something that QUIC should support, I have a follow up >> question. Because all packets are encrypted, how would we expect a hardw= are >> firewall to ever get close to matching the performance of a TCP equivale= nt >> firewall? It seems to be a lot more difficult (expensive) to protect QUI= C >> from attacks than TCP. >> >> >> > I think source address validation mainly protects the network from spoof > traffic (See RFC 6959 for much better and more complete descriptions), > rather than protecting the traffic. So when you say "protect QUIC from > attacks", I'm not sure exactly what you mean. Would you mind going into = a > bit more detail on what you need? > > regards, > > Ted Hardie > > > > >> Thanks, >> >> - Nick Banks >> > > --94eb2c0d040e64d0bb055f0ef1ef Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Nov 27, 2017 at 4:29 PM, Nick Banks <nibanks@= microsoft.com> wrote:

Thanks for the info Ted. I=E2=80=99m sorry I wasn=E2= =80=99t clear about the attack. I was referring mostly to a Slowloris attac= k. A specialized HW firewall could be made to just use source address valid= ation to try to reduce half open connections and reduce the actual load on the real server.


<= div>A common mitigation for slowloris-style attacks puts a load-balancer or= proxy in front of an affected web server, so that these attacks are caught= before being passed to the content server.=C2=A0 Doing so in a firewall do= esn't work quite as well, because it is not trusted by the content serv= er (and may not be trusted by the client, depending on the network).=C2=A0 = It's also not clear that source address validation would help that much= ; after all, in a TCP/TLS connection, the TCP 3-way handshake would have co= mpleted before the attack starts (since slowloris sends partial HTTP reques= ts to keep the connection open, it occurs after the source address is deeme= d valid by all parties).

=C2=A0

I was also thinking of the attack surface where the = attacker sends a valid long header with junk payload. The server will waste= cycles trying to decrypt it.


H= ere's the current format of the long header (from section 5.1 of the tr= ansport draft)
  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
   +-+-+-+-+-+-+-+-+
   |1|  Type (7)  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                       Connection ID (64)                      +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Packet Number (32)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Version (32)                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Payload (*)                        ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
<= /div>
=C2=A0
Which bits do you see= as the subject of the attack?

regards,
=
Ted

=C2=A0

Sent from my Windows 10 phone

=C2=A0

From: Ted Hardie <ted.ietf@gmail.com>
Sent: Monday, November 27, 2017 3:57:55 PM
To: Nick Banks
Cc: quic@ietf.org=
Subject: Re: Independent QUIC Firewall
=C2=A0
Hi Nick,

On Mon, Nov 27, 2017 at 2:03 PM, Nick Banks <nibanks@micr= osoft.com> wrote:

Hello,

=C2=A0

With the current state of the QUIC protocol, it seem= s impossible to have an independent QUIC firewall perform source address va= lidation before letting packets through to the server.


So, there are clearly classes of source address validation, some of wh= ich simply verify that the source address is from a subnet appropriate to t= he packet ingress port.=C2=A0 Those are unaffected by QUIC and, depending o= n where you put the firewall/NFV instance doing this work, they may be sufficient for many use cases.

If you place the firewall further away the access nodes, this gets mor= e difficult as there is a higher chance that the device emitting the packet= is on your network but not entitled to use the source address.=C2=A0 In th= at case, you apparently want an on-path device to be able to signal to the origin that it requires verification th= at the origin sent the packet.=C2=A0 Absent a signalling path, you seem to = have two classes of verification:=C2=A0 drop the initial packet and confirm= intent by watching for a retry after a timeout period.=C2=A0 (This is absolutely hideous from a latency perspective, and = I can hear all the HTTP use case people screaming about bandwidth delay pro= ducts in my head, so don't do this or they may show up at your office w= ith whiteboards and colored ink).=C2=A0 The other option is to allow the initial packet and watch for the handshake completi= on, closing the pinhole when it fails to complete.=C2=A0 This does not have= a latency impact, but it will allow some single-packet traffic flows to eg= ress if standard BCP 38 rules did not catch them.=C2=A0 The working group is trying pretty hard to make sure tha= t those attacks don't turn in to amplification attacks, and I hope you&= #39;ll help in that endeavor.

Ideally, the firewall might have special hardware to= generate the Retry packet in response to Initial packets received and then= only let traffic through once the client responded to the Retry packet. Th= is wouldn=E2=80=99t work though, because TLS authenticates the transcript of the connection. The actual QUIC server wou= ld drop the connection if it didn=E2=80=99t original the Retry packet and a= ssociated HelloRetryRequest. Is this something that QUIC should support?=


If you're asking if there should be an explicit signal than an on-= path device could send that asked for verification, the short answer is a q= uestion:=C2=A0 how do you instantiate the trust to prevent that from being = an avenue of attack?=C2=A0 (Split client models and server farms that share roots of trust or keys more or less know how t= o do this.=C2=A0 But a firewall typically isn't trusted to be a party t= o the communication, for the Random WiFi attachment use case and many other= s).

=C2=A0

And if this is something that QUIC should support, I= have a follow up question. Because all packets are encrypted, how would we= expect a hardware firewall to ever get close to matching the performance o= f a TCP equivalent firewall? It seems to be a lot more difficult (expensive) to protect QUIC from attacks than T= CP.

=C2=A0

I think source address validation mainly protects the network from spo= of traffic (See RFC 6959 for much better and more complete descriptions), r= ather than protecting the traffic.=C2=A0 So when you say "protect QUIC= from attacks", I'm not sure exactly what you mean.=C2=A0 Would you mind going into a bit more detail on what you ne= ed?

regards,

Ted Hardie


=C2=A0

Thanks,

- Nick Banks



--94eb2c0d040e64d0bb055f0ef1ef-- From nobody Tue Nov 28 10: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 41460128954 for ; Tue, 28 Nov 2017 10:24:14 -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, UNPARSEABLE_RELAY=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 crLnR_NM8n1a for ; Tue, 28 Nov 2017 10:24:12 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::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 71C49128D2E for ; Tue, 28 Nov 2017 10:24:04 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id p139so888137itb.1 for ; Tue, 28 Nov 2017 10:24:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=hJJs9wMhILfRy6pFaWoSrpwYovttI0bW017CzS/ss0w=; b=hkJDvCloz4VKHR46KuzKuElXnQxLRrAoFixCa4N9M5aKR41ND6sYVo8cu6iWML/zCl U5cnADShnWN1cCdDGN1qoA7mNC4spcF19OiUrnoQAHKz3oP9hL3BCC3Ri8lZMhfVRyaK kZGy3T2zM9vCenwdLv7g5ujwXhNNaCO8UWBEwSzjGstOgf05wfKJ2hQ8qFA2tLFX9BxU t+VA4Briue73kRlqPCuNvWn6SbvxLOLwZBDGAoKizjU1uU6sJ7Pf8PlYpSEyqAA971O5 oauwjtcuGs2nDC4yrInxlQ6H5wU8i57zb0QWhpUprrHIALle6VdrjpSaD+NbOOd8zZeY +m8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=hJJs9wMhILfRy6pFaWoSrpwYovttI0bW017CzS/ss0w=; b=AwVfXf61G+mRu3uWUlWc+m7ZT0G+IPvdtQFaAtQHbCw2kv08W4cWhy5luX46HceSUS ccGxrIwdsYbH6EhLnQsgZgr7JbiuZX8EFbWB6SbOGpiDQQFhxpvO/ud4EiNDrF2sGkBt CwWVO1kV3PQ9wTpGGqq/6YQKIAvLDSpFV9eKthhqr6kTlh8QZSrd20+XKvwcJ6LID5vj MelG/W0VjzAPcCCLrra9GgB6JPr2ZTwFOsWrmvoNntovIsmY8JtzWPscwT8PEJudig6c KNVYIDUcBKFalyWlt2F0gtDVy+C/46OcfV1L+mGB/hKAZRtY/rXFNoDn2E+REyHR6JP7 Yk5w== X-Gm-Message-State: AJaThX4/QaU4AHrm7TkrkWo6gQcU//dfTcKccJv0cizhRCIOc8cyhkR3 sJO4mTpyaajabIK2n7dOG61RJjMyR4UsUxx2KLU= X-Google-Smtp-Source: AGs4zMaiBtjZYa1MiEdvHrduzVxj/q/ihqJ7YwN1zROBUyUT83zoRtTyC2GfnpBiJ3HHaJVo/e/t0/BfTSQeCO1N1OE= X-Received: by 10.36.95.14 with SMTP id r14mr3677322itb.42.1511893443841; Tue, 28 Nov 2017 10:24:03 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 28 Nov 2017 10:24:03 -0800 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Tue, 28 Nov 2017 10:24:03 -0800 Message-ID: Subject: Re: Independent QUIC Firewall To: Ted Hardie , Nick Banks Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a1144b57aa8943a055f0f1f35" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 18:24:14 -0000 --001a1144b57aa8943a055f0f1f35 Content-Type: text/plain; charset="UTF-8" A common mitigation for slowloris-style attacks puts a load-balancer or proxy in front of an affected web server, so that these attacks are caught before being passed to the content server. Doing so in a firewall doesn't work quite as well, because it is not trusted by the content server (and may not be trusted by the client, depending on the network). It's also not clear that source address validation would help that much; after all, in a TCP/TLS connection, the TCP 3-way handshake would have completed before the attack starts (since slowloris sends partial HTTP requests to keep the connection open, it occurs after the source address is deemed valid by all parties). Proof of work could be added as a negotiated facility - but can it be done without introducing latency while negotiating? Nobody would want to volunteer unnecessary work. > I was also thinking of the attack surface where the attacker sends a valid long header with junk payload. The server will waste cycles trying to decrypt it. I have earlier suggested a short verifiable crypto tag in the packet header that must validate otherwise the packet would be dropped. The response on the list was that it was cheap enough to verify the entire packet, so it would not be worthwhile doing. If such a feature was present, it would prevent random content attacks, but not deliberate QUIC aware attacks. Such a verifiable tag could also be proof of work. One option could be to prioritise headers that volunteer proof of work - that would be helpful in DDoS scenarios. Perhaps a load balancer could even verify the proof of work without being aware of the TLS handshake level encryption? Mikkel --001a1144b57aa8943a055f0f1f35 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
A common mitigation= for slowloris-style attacks puts a load-balancer or proxy in front of an a= ffected web server, so that these attacks are caught before being passed to= the content server.=C2=A0 Doing so in a firewall doesn't work quite as= well, because it is not trusted by the content server (and may not be trus= ted by the client, depending on the network).=C2=A0 It's also not clear= that source address validation would help that much; after all, in a TCP/T= LS connection, the TCP 3-way handshake would have completed before the atta= ck starts (since slowloris sends partial HTTP requests to keep the connecti= on open, it occurs after the source address is deemed valid by all parties)= .

Proof of work could b= e added as a negotiated facility - but can it be done without introducing l= atency while negotiating? Nobody would want to volunteer unnecessary work.<= /p>

&g= t; I was also thinking of the attack surface where the attacker sends a val= id long header with junk payload. The server will waste cycles trying to de= crypt it.

I have earlier suggested a short verifiable cry= pto tag in the packet header that must validate otherwise the packet would = be dropped. The response on the list was that it was cheap enough to verify= the entire packet, so it would not be worthwhile doing. If such a feature = was present, it would prevent random content attacks, but not deliberate QU= IC aware attacks. Such a verifiable tag could also be proof of work.

= One option could be to prioritise headers that volunteer proof of work - th= at would be helpful in DDoS scenarios. Perhaps a load balancer could even v= erify the proof of work without being aware of the TLS handshake level encr= yption?


Mikkel

--001a1144b57aa8943a055f0f1f35-- From nobody Tue Nov 28 11:40: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 9153E126C83 for ; Tue, 28 Nov 2017 11:40:42 -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 (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 kHlyREYtx_pk for ; Tue, 28 Nov 2017 11:40:41 -0800 (PST) Received: from mx141.netapp.com (mx141.netapp.com [IPv6:2620:10a:4005:8000:2306::a]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E9CC1200CF for ; Tue, 28 Nov 2017 11:40:41 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,468,1505804400"; d="asc'?scan'208";a="242376469" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx141-out.netapp.com with ESMTP; 28 Nov 2017 11:40:40 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 28 Nov 2017 11:40:40 -0800 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 28 Nov 2017 11:40:40 -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=9zGs4edn9fKx4y1WfFDCh7mhBpyGfDI81DdJjxwByWg=; b=Wf/2F2MDFGvp8vGSX3Mt7yHC0U86QVrkkI1iZb5oGJF7P34TWEfR1EV1a8KpLRafQWuaOrXHYfLzq9rZMdm+k6wJccd5J5qnR51A1pM11y9NHC5vs+quKjD/INZePfl2q1eSWtojyZn71FuyyFnh031o07fi/tnDosAGFzUoHlQ= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Tue, 28 Nov 2017 19:40:39 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.007; Tue, 28 Nov 2017 19:40:38 +0000 From: "Eggert, Lars" To: QUIC WG Subject: Re: Doodle poll for Dec 2017 interop day Thread-Topic: Doodle poll for Dec 2017 interop day Thread-Index: AQHTX4SHf7OvFQBwUU20L/H4FHI4T6MerDOAgAuWS4A= Date: Tue, 28 Nov 2017 19:40:38 +0000 Message-ID: References: <5F30810F-C268-483C-A6BA-02D4BC86C325@netapp.com> In-Reply-To: <5F30810F-C268-483C-A6BA-02D4BC86C325@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:3614:8001:4127:2e74:8c64:2102] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:ZVHOwOi56iYkgzb9+U7EIPTOsZSfSzMUvdaviQEszLpszjo8RH9MzvqYAaAHDPOOp5f5r+T6W/4B9LGyrFr3MYhEu83VnUu0kAukdAaAuC1pPj/lL1IOqSxrGCxvEuJvCcup6J88VX1xoDY3szrFsFwJxtJLzNIVNCETtsO/5qNwPCOth1V9T293/iZMi3Dx98a0tuOk5lmpsS+UpTmu8mt3wd/g9j9QHyfM/osGmSRFsffYxoI8ykNx0ktSLXEg1tjo+ZKT16QM02dmechpFiknTeTIar7REF+rqjPTg/bUseHuQItDrdDnCEuFzkzJ/ZLY/7DMcW9FfSFz3TeJaMAxOjaqH3jyE6NvYuxQ9MA=; 5:ZYbuFYT2o6FSmthbOAY6g+pY1PhVaaR0MApyA/NthddPKsPdqKwJF7yd6/O7kFMsERNbjXN7oFJphmc7oobhVwIfQH2mEAALVAVUxZ9APFSvccYwMcpP1pU8FkoaLsFOJAoC1FGKlfW6pBccxkz/T4nvZT5T5vzArSmivEFOSP4=; 24:khmAxLTNAzDynG4IXX4sU6+EfWspgziH36QJw8nut+t8NnsTnuebJEWDo+Ns69uTqjU+lZmmUxifoqwkQBDivRAc6MyWXM1NuzovfNMvoPM=; 7:qYlj/UsN0dASHznnxnMAOjRnWk3BQlciSoCHEyPxRz3Ri6BKXP6E7uWzpJ1MMAOVjWvIpGByZYF62HJwSUOHMMBCM0a816uXBWMEJYKdKeLTgJCoWfPzNQ3s/q/Qcw+yeld/lS/UhkfqEMnVoqmx6iffeuihPV3Q5JhEbtgDlgHyv/afialPYtcfeRj0vEK6j9K94+zmOeJcIguBCo0ZYtt7oYWX/tkKtrND9zM4+VMO1vxqbIrNhmYp7TlX1SKJ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 4482c2ad-63c5-4c32-b500-08d53697e728 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603258)(49563074); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(3231022)(10201501046)(6055026)(6041248)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(6072148)(201708071742011); SRVR:BLUPR06MB1764; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1764; x-forefront-prvs: 0505147DDB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(366004)(377424004)(189002)(199003)(24454002)(305945005)(105586002)(3280700002)(316002)(14454004)(478600001)(81166006)(6916009)(106356001)(7736002)(25786009)(81156014)(2950100002)(2900100001)(8676002)(3660700001)(101416001)(97736004)(558084003)(57306001)(36756003)(68736007)(102836003)(99286004)(6116002)(33656002)(2906002)(99936001)(82746002)(189998001)(53936002)(83716003)(6246003)(229853002)(5660300001)(6512007)(6486002)(77096006)(6436002)(4001150100001)(8936002)(50986999)(86362001)(6506006)(53546010)(50226002)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1764; H:BLUPR06MB1764.namprd06.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A: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=_68FC24FD-1537-417D-889C-0EDC74376080"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4482c2ad-63c5-4c32-b500-08d53697e728 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2017 19:40:38.7865 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1764 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 19:40:42 -0000 --Apple-Mail=_68FC24FD-1537-417D-889C-0EDC74376080 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 2017-11-21, at 11:43, Eggert, Lars wrote: > at the moment, Dec 18 is in the lead Mon, Dec 18 it is. Mark your calendars. It would be good to have -08 drafts and the 3rd implementation draft = wiki a bit before that. Lars --Apple-Mail=_68FC24FD-1537-417D-889C-0EDC74376080 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlodu7UACgkQVLXDCb9w wVcqWw/+J6hRGu/dWPOnH0gcGDzGX4+c+6P+MYipnoalSl8BzqwwR+C08uGEQusI W7VvlNEKhhfD1VRXS/AsY3qcXR/DBW2egRn3+qeKP6NlcycR3SdSG6KCNpk5sha6 mMIc0ZxDwxs6Kxo06kRP1LGsf5XAbTb8oSd7p+9AsuJxtmT7wGEfRRalsv/AJDYF dU0YKSGUYeS5NanYRSQIPEoY16aqaqQCkQwBVGcen+C122gPAIrkTuwRC1Z0SXVy jBYH7k/b2nFx12fM6yi+BrQsJEvXsMzNAPDi1895SSabGf+JsYLHXWwz6bLCGJns tTgUcX9p850u4aIvAw2yN0aF8iZUQGL0g1MqlYxLeAAZ+GvD2bv+MeOJc0oIR2E/ ccfHqkXiqqhj/uZt1ERXvDhHpCa09Mdzt4qFCylJukYizpUBQNFuSsRfgh4x9s06 QnMiwVP9SEogV8YQYa5lOkI9RB/kipugWXPiNTF1JStpWHH1isuqErEhkpsEynQN f9ru3pqipkL4ycefdkfI/lMXNSr+M4dOgk5nvuwYxTcqg5YWLLR8af2YK5HSaeov DE8WknrLi8SDxWb1UQDctQNd9SLqVVvAKG9f2zzMYueT/xELT4vo4jYEtR9ZT9sn fm+WH4lii+XBBH3owjeWO3nuddME01PgAQ1EgoZHdY3PLKY21uE= =qhPc -----END PGP SIGNATURE----- --Apple-Mail=_68FC24FD-1537-417D-889C-0EDC74376080-- From nobody Tue Nov 28 15:53: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 4A6151292F5; Tue, 28 Nov 2017 15:53:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=QdwXIgEy; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=mqP//NBE Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id woHOodYh-Ptz; Tue, 28 Nov 2017 15:52:58 -0800 (PST) Received: from esa2.dell-outbound.iphmx.com (esa2.dell-outbound.iphmx.com [68.232.149.220]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680201292AE; Tue, 28 Nov 2017 15:52:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1511913178; x=1543449178; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aT+Ok+t8pdj4DBCn8EcKNP9eSHCoU5O7sTSOfTbbp9k=; b=QdwXIgEyBrMcDENkpPLtSYiGZ7bDdWfbalqa54R/Jgf865apOnmad6qg /D78z8AzupLMLV7SdMjODzAjVGhm/oOPOe2nBTHIPKljs6J4/b4zoe0eM fWDkkVoo3XpsU8LL0VEHqG3X1uYWHsaDNF1RlfOPP1Rmzs5brmo7jhJnC A=; IronPort-PHdr: =?us-ascii?q?9a23=3AJRFYNRCH/64R7iz24PCVUyQJP3N1i/DPJgcQr6Af?= =?us-ascii?q?oPdwSPX/rsbcNUDSrc9gkEXOFd2CrakV26yO6+jJYi8p2d65qncMcZhBBVcuqP?= =?us-ascii?q?49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx7xKRR6?= =?us-ascii?q?JvjvGo7Vks+7y/2+94fdbghMhzexe69+IAmrpgjNq8cahpdvJLwswRXTuHtIfO?= =?us-ascii?q?pWxWJsJV2Nmhv3+9m98p1+/SlOovwt78FPX7n0cKQ+VrxYES8pM3sp683xtBnM?= =?us-ascii?q?VhWA630BWWgLiBVIAgzF7BbnXpfttybxq+Rw1DWGMcDwULs5Qiqp4bt1RxD0iS?= =?us-ascii?q?cHLz85/3/Risxsl6JQvRatqwViz4LIfI2ZMfxzdb7fc9wHX2pMRsZfWTJcDIOg?= =?us-ascii?q?YYUBDOQBMuRZr4bhqFQDtgGxCRWoCe711jNEmmH60Ksn2OohCwHG2wkgEsoAvH?= =?us-ascii?q?nJqNX6LrsdUeOtwKLVwzvMde1W2Tbg54TGbxsspv+CUqhuccrQ1EYjDR7IjlGK?= =?us-ascii?q?poP5PDOYzfkCvHaf7+pkT+6gl2knqwRorzWp28wiiZHJi5oUx13H7yl13og4Kc?= =?us-ascii?q?OiREJmYdOpH4FcuiWZOoduX88uX3tktDg0x7AFo5K2cycHxI46yxPRaPGLa4aI?= =?us-ascii?q?7QzgWeqNJDp1gXFodb27iha89EWtyvDzWdOq3FtPsyZJj8LDu3UC2hHd6cWKSv?= =?us-ascii?q?1w9Vq71zmVzQDc8ORELFgxlarcNpEu3KY9loEWsUTfBi/2n1j2jLOOekUk5Oeo?= =?us-ascii?q?7+Pnb634qZ+HLYB5hRvyPbkwlcy7BeQ0Kw8OX3WH+eun073j4Ev5T6hUgvEsk6?= =?us-ascii?q?nZqJDaJcEUp6KjHwBV1YMj5w6+DzegztsYgWEKIVNGdR6dkYTkNU/CLOrlAfq/?= =?us-ascii?q?jFmgijNmyvPeMr3kGJrNL3zDkLn7fbZ67k5R0AQ9wspB55JVF74NOu/+Wkvru9?= =?us-ascii?q?PEDR80KBG7zPjjCNV5zI8RRWWPAqqBPKPIrVCI/v4vI/WLZIINpDb9MOYl6+f0?= =?us-ascii?q?gn8jh1ASZ7Kk3ZoJZ3CkEPRqOUKZYWDjgt0ZC2cFohI+TPD2iF2FSTNTfmuyX6?= =?us-ascii?q?Mg6TwgCYKpE5vDRo63jLyGxie7Ec4eWmcTQH2DHnrya8HMf/4Wc2jadstoiCcs?= =?us-ascii?q?U7W9Qpc5kxqpsVm+g/BCCdDo3Qtc/bvH+uJYy6X43VEb0X0+R5CU2GSKVX1zmE?= =?us-ascii?q?sBWyNw16d69x9T0FCGhOJSh/VTFpgby/pXUwtwfcrwxvJ7B5bYXgvKff+FRVKi?= =?us-ascii?q?BN6hBGdiHZoK39YSbhMlSJ2ZhRfZ0n/vWudNmg=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EuAAC59R1ah2Ka6ERcGgEBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJKIoEmEG4nB44YjxmBfZZzgU5DCoU7AoUGPxgBAQEBAQEBAQEBAhA?= =?us-ascii?q?BAQEIDQkIKC+COCQBDkghBTIBAQEBAQEBAQEBAQEBAQEBAQEXAj0TAQEYAQEBA?= =?us-ascii?q?QMtEx8aAQ8CAQgRBAEBCx0HMhQJCAIEDgUIiTZkAalGgxCHWAEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARUIgz2BNlOBV4UThSE0gxCCMotClwkGAqhblhMCBAIEBQIag?= =?us-ascii?q?TofYIErb4J4CYJZgXN3iVaBFAEBAQ?= X-IPAS-Result: =?us-ascii?q?A2EuAAC59R1ah2Ka6ERcGgEBAQEBAgEBAQEIAQEBAYJKIoE?= =?us-ascii?q?mEG4nB44YjxmBfZZzgU5DCoU7AoUGPxgBAQEBAQEBAQEBAhABAQEIDQkIKC+CO?= =?us-ascii?q?CQBDkghBTIBAQEBAQEBAQEBAQEBAQEBAQEXAj0TAQEYAQEBAQMtEx8aAQ8CAQg?= =?us-ascii?q?RBAEBCx0HMhQJCAIEDgUIiTZkAalGgxCHWAEBAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?RUIgz2BNlOBV4UThSE0gxCCMotClwkGAqhblhMCBAIEBQIagTofYIErb4J4CYJ?= =?us-ascii?q?ZgXN3iVaBFAEBAQ?= Received: from esa4.dell-outbound2.iphmx.com ([68.232.154.98]) by esa2.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 28 Nov 2017 17:52:57 -0600 From: "Black, David" Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa4.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 29 Nov 2017 05:52:56 +0600 Received: from maildlpprd55.lss.emc.com (maildlpprd55.lss.emc.com [10.106.48.159]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vASNqtKg006862 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 28 Nov 2017 18:52:56 -0500 X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com vASNqtKg006862 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1511913176; bh=+hS3LKYJWLDEfuIB1y8+H/SRUCQ=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:MIME-Version; b=mqP//NBEvx0UlyxY2Txunm5xOeOePhJRD3oLdyVvANLhQx7ua9dV64arPZCsKCnIU 9m1IiW7e+YJFbwoHh3VL6uuQDkbJiasD7eY626WzIiwxnzRplTRUYUiu8WotJ6KpXD RkDSSkmVgv3O03I4cPqhIo00EbnlrNTzX2VHLgTY= X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com vASNqtKg006862 Received: from mailusrhubprd04.lss.emc.com (mailusrhubprd04.lss.emc.com [10.253.24.22]) by maildlpprd55.lss.emc.com (RSA Interceptor); Tue, 28 Nov 2017 18:52:41 -0500 Received: from MXHUB309.corp.emc.com (MXHUB309.corp.emc.com [10.146.3.35]) by mailusrhubprd04.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id vASNqfSv031881 (version=TLSv1.2 cipher=AES128-SHA256 bits=128 verify=FAIL); Tue, 28 Nov 2017 18:52:41 -0500 Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB309.corp.emc.com ([10.146.3.35]) with mapi id 14.03.0352.000; Tue, 28 Nov 2017 18:52:41 -0500 To: "Eggert, Lars" , "MORTON, ALFRED C (AL)" CC: QUIC WG , "tsv-area@ietf.org" Subject: RE: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAANHICAAAmEgIAABm6AgAbXQwCAANXCAIACjivQ Date: Tue, 28 Nov 2017 23:52:40 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> In-Reply-To: <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.238.44.138] Content-Type: multipart/alternative; boundary="_000_CE03DB3D7B45C245BCA0D243277949362FD920D9MX307CL04corpem_" MIME-Version: 1.0 X-Sentrion-Hostname: mailusrhubprd04.lss.emc.com X-RSA-Classifications: public Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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 Nov 2017 23:53:00 -0000 --_000_CE03DB3D7B45C245BCA0D243277949362FD920D9MX307CL04corpem_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > (On first glance, the - user - privacy aspects here seem to be much more = contained, since ECN is mostly about the network exposing information to th= e end systems, and not vice versa.) That sounds like the right high-level summary. The fact that a transport p= rotocol implementation supports ECN does not intrinsically expose any infor= mation about the user to the network. The primary information flow is conge= stion information flowing from the network to the endpoints. Thanks, --David From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Eggert, Lars Sent: Monday, November 27, 2017 3:12 AM To: MORTON, ALFRED C (AL) Cc: QUIC WG ; tsv-area@ietf.org Subject: Re: Spin bit discussion - where we're at Hi, On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) > wrote: Question: Is there a privacy analysis of present ECN available? (a search yielded many results with Missing: privacy) not that I'm aware of; CC'ing tsv-area@ for some broader input. (On first glance, the - user - privacy aspects here seem to be much more co= ntained, since ECN is mostly about the network exposing information to the = end systems, and not vice versa.) Lars --_000_CE03DB3D7B45C245BCA0D243277949362FD920D9MX307CL04corpem_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

> (On first glance, the - user - privacy aspects here seem to be m= uch more contained, since ECN is mostly about the network exposing informat= ion to the end systems, and not vice versa.)

 

That sounds like the right high-level= summary.  The fact that a transport protocol implementation supports = ECN does not intrinsically expose any information about the user to the network. The primary information flow is congestion inform= ation flowing from the network to the endpoints.

 

Thanks, --David

 

From: tsv-area [mailto:tsv-area-boun= ces@ietf.org] On Behalf Of Eggert, Lars
Sent: Monday, November 27, 2017 3:12 AM
To: MORTON, ALFRED C (AL) <acmorton@att.com>
Cc: QUIC WG <quic@ietf.org>; tsv-area@ietf.org
Subject: Re: Spin bit discussion - where we're at<= /p>

 

Hi,

 

On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) <<= a href=3D"mailto:acmorton@att.com">acmorton@att.com> wrote:

Question: Is there a privacy analysis of present ECN available?

(a search yielded many results with Missing: privac= y)

 

not that I'm aware of; CC'ing tsv-area@ for some bro= ader input.

 

(On first glance, the - user - privacy aspects here = seem to be much more contained, since ECN is mostly about the network expos= ing information to the end systems, and not vice versa.)

 

Lars

--_000_CE03DB3D7B45C245BCA0D243277949362FD920D9MX307CL04corpem_-- From nobody Tue Nov 28 16:26: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 71224127735; Tue, 28 Nov 2017 16:26:42 -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 4ZICJcyyawul; Tue, 28 Nov 2017 16:26:39 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id A6BA1127136; Tue, 28 Nov 2017 16:26:38 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id DFB0234096A; Wed, 29 Nov 2017 01:26:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.6335); Wed, 29 Nov 2017 01:26: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; Wed, 29 Nov 2017 01:26:33 +0100 (CET) Received: from [114.175.86.34] (account ietf@trammell.ch HELO [192.168.1.183]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 37572338; Wed, 29 Nov 2017 01:26:32 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_1F2F7D2B-855A-4955-93C0-24173DC72004"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: Spin bit discussion - where we're at Date: Wed, 29 Nov 2017 09:26:29 +0900 In-Reply-To: Cc: "Eggert, Lars" , Al Morton , QUIC WG , "tsv-area@ietf.org" To: "Black, David" References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 00:26:42 -0000 --Apple-Mail=_1F2F7D2B-855A-4955-93C0-24173DC72004 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi, David, > On 29 Nov 2017, at 08:52, Black, David wrote: >=20 > > (On first glance, the - user - privacy aspects here seem to be much = more contained, since ECN is mostly about the network exposing = information to the end systems, and not vice versa.) >=20 > That sounds like the right high-level summary. The fact that a = transport protocol implementation supports ECN does not intrinsically = expose any information about the user to the network. The primary = information flow is congestion information flowing from the network to = the endpoints. There are three possible states for an ECN negotiation: not attempted, = failed, and succeeded. Each of these can add a fractional bit of = information about the client and server TCP implementations. If a server = negotiates ECN, you can be reasonably certain that it supports ECN, and = can leverage the observations that sysadmins love defaults and servers = are mostly Linux these days to figure out whether it's running a kernel = before or after server side defaults were turned on. Long-term observation of the ECN negotiation attempts of a client can be = used to determine if the client is using probabilistic negotiation by = default; i.e. is an Apple device of a certain vintage. These are fractional bits of fingerprinting information, though, if = that. I'm almost certain (but won't take the time to do the research = now) that any of these observations would be useless. Anyone in a = position to make them could also get much more information about the = behavior of the TCP stacks at each end, such that the ECN bits add = negligible information. cf. p0f, if that's still a thing. Cheers, B >=20 > Thanks, --David >=20 > From: tsv-area [mailto:tsv-area-bounces@ietf.org] On Behalf Of Eggert, = Lars > Sent: Monday, November 27, 2017 3:12 AM > To: MORTON, ALFRED C (AL) > Cc: QUIC WG ; tsv-area@ietf.org > Subject: Re: Spin bit discussion - where we're at >=20 > Hi, >=20 > On 2017-11-26, at 20:26, MORTON, ALFRED C (AL) = wrote: >=20 > Question: Is there a privacy analysis of present ECN available? > (a search yielded many results with Missing: privacy) >=20 > not that I'm aware of; CC'ing tsv-area@ for some broader input. >=20 > (On first glance, the - user - privacy aspects here seem to be much = more contained, since ECN is mostly about the network exposing = information to the end systems, and not vice versa.) >=20 > Lars --Apple-Mail=_1F2F7D2B-855A-4955-93C0-24173DC72004 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlod/rUACgkQihK3vwvq RqNFrg//ZL3OAGU/iG2WLs+ypl+vjoQafMC+dfgrfwphEDh9c50BzeB5+yrAy5vH HXgOS+yIZsHWer1o7BN0t6MPabWZgiw8jqs9t9BU1QW9+RI8K0zWdMgM7oqPKOoL SW8XzPXbwCEhHnuP2QJE+7P0HgK6RNpz8PZraZGhp/qsamEfCnl+OGhC+ALnN2cK mIcLlCVOfb+XiYA3JPTAsn2lni6Qw4kVmRQ943dmQoOwKvKEYeimC0pZla6MaciL 2UbRD/E/2SiEsP41vvBVCvhrfedZ/fV95IbR5mZ+0M9tOoZSUjSJyH5ZFG4ygTMN PABEDeIQIk6EQcFHTfATzDJsGdh7Xvyi6U8Ri7O0zh7O0XrlYCkR5/X09tOs706I SnFTYvsHqz2Ek4iKh4dLfFkRuvOk4w6DBpeapf4MZj70f2Ua1as1cK4sr2dpvAm6 NMYqUyIx7WUYjLPDLWS5gfk/VUVINKsG4rmdnj+CJhKo51/wM5qWPE8IdEQDlv6q T+3xCS2CYVU5v62pQCfzyT2dtZtBfzHLOJP7TlZf9e1HHu/EzI/iYLYhD2uBO++x jZlyqsmB+49NCGcu535TSIGlbUya7jy+ArNt2es5cRHMEDCUWqOCiT9PbRouYp1j QAxil2Ff+/oxkV+rzz1tkWGzhNXbr71iZUxx/m/7RO3RhaY6p8I= =7tZH -----END PGP SIGNATURE----- --Apple-Mail=_1F2F7D2B-855A-4955-93C0-24173DC72004-- From nobody Tue Nov 28 16:28: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 21EFE128B93 for ; Tue, 28 Nov 2017 16:28: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, 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 zrGk9x_bVJeZ for ; Tue, 28 Nov 2017 16:28:16 -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 A4CEB127136 for ; Tue, 28 Nov 2017 16:28:16 -0800 (PST) Received: by mail-oi0-x22f.google.com with SMTP id w131so1275880oiw.0 for ; Tue, 28 Nov 2017 16:28:16 -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=rhkhOSGFE4WhEvxtKd6yCNyzqxjpxFJFpD/mATZ4TmY=; b=jaAW3wiC2vFKvVCMpubIQw65y4WUZQ8Pz4qTj6RqNyPHIm/xM2YiYKp+F+JxqiwslH G9xAN10fZYSg7b2QEBSdTOAScUMz/qg4gzNd8+Mzc5Mvjoxn95tj6eAnYg/x0hh8J66z EwxUm+6aRlxh3mvEdPgGqywJcqe4yn4LT4gf/fIzz/Es6i//3AfjtglEIo77PBAmVa4I WVv36f1l0nSL73choc6qY3ugREofGgX9SEGaaAbLMid7U9+n7yZmDbBjt94uV5Y/IgCf tH7mgF6fU2JBlMDC6j4YC5PvBm7ppxWhxy7skBY6TT6eGZB/O5qAYuaPV04wnVtliYpo an7g== 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=rhkhOSGFE4WhEvxtKd6yCNyzqxjpxFJFpD/mATZ4TmY=; b=Y6YZBpw8PevzQFro/fu9BlOhgxzGu0WYJ+xit3S4G2WlNdXfTbAY0MPcbx5nQpfOL9 7Q9yyWsRygtO0mXFaXQVuUX0rS2odbPfwRW7IFULMmVN1ylGcOZ9bv0d8RE1a/hEQCCC oD4otcedAKwK1n+crzHqAfAVzCnMB/IynWf+cUhM9wWlIxfqa9Yyehsh5oIv0rD1Uhtk iUnksiKSmIEF9fHvE9UpfOrJHgmCkqfvTlBQmI8tFMoK78K0RsjFu2UmUzgGfxbZ1Fiz /L97cSrHurxrMuVg6xPimn/6vJG4KQXWrS4xV4Z51wI5Wcl7QueRg0S81uhRCGkfuJYG Nf3g== X-Gm-Message-State: AJaThX4UvVhfXLdpZM5NEXZLJPCZr4HFTHv+3Q8IPo3bvCm0V0HQGnqR JMNLgMXOzyAIDOjLduv59k/dMkxMJiXjrhnGAzK7z0vS X-Google-Smtp-Source: AGs4zMaI8fdO+ubN9xlNuksnENvFgfrG42W8cFtFW/AvEpJSAXAoap4pDKUJN2QMTn9IQl8NT3RMCodv/7Pn7/jiNpg= X-Received: by 10.202.86.84 with SMTP id k81mr810749oib.50.1511915295774; Tue, 28 Nov 2017 16:28:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Tue, 28 Nov 2017 16:28:15 -0800 (PST) From: Martin Thomson Date: Wed, 29 Nov 2017 11:28:15 +1100 Message-ID: Subject: Swapping Version and Packet Number fields To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 00:28:18 -0000 Ian has a PR open that switches the order of version and packet number. We discussed this in the context of invariants at the last meeting and there seemed to be general agreement that moving the invariant stuff (Version) ahead of the version-specific stuff (packet number) was a good idea. https://github.com/quicwg/base-drafts/pull/939 I plan to merge this soon. From nobody Tue Nov 28 16: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 00D9A128CFF for ; Tue, 28 Nov 2017 16:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 spLuroGUcObu for ; Tue, 28 Nov 2017 16:41:25 -0800 (PST) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CB13120724 for ; Tue, 28 Nov 2017 16:41:25 -0800 (PST) Received: by mail-yb0-x233.google.com with SMTP id 184so717452ybw.12 for ; Tue, 28 Nov 2017 16:41:25 -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=LGvPsC79dsU9KlxBzmmGAOIdwcvb0PR4UakuaaOdpCE=; b=XGzsLk1ZkxLCmQtLJC82Dw2I+VJugaDqLpunfBoIw6gzuUfFlc6J0MS07oPxxEXaor ljEPhfbhad+U4EvJs/rWjKFJYyOrfJKJtXPt4PzOOU+lXC+l20txz0/Ez5LSPqvoEEnb C1bOWcVDNP+e4F/CiLddgFDA954t7l7UINOLnLBvc4QQJlMQDCpcyn0IrEu4ijA5AkUX DzVuogfVkaPilbYbtdHUC9Aesck8ixWYU2XtkSr+lY0vxnfrbw+WBtnFQD3eDT9v0zRv 2xHiynTUCUe00KomCEYTewr48cW4wX72lJCdhOJXEaDjLrob/66JlKmukdLINzBnrZuk YsuA== 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=LGvPsC79dsU9KlxBzmmGAOIdwcvb0PR4UakuaaOdpCE=; b=NnVgV6Ltk24Ki09LXUQWOat4X2eF2ugh1xISXktaUOngF5NxvmE2Xm/Ne9AJHnNRsj g/2wPPv0a9dQsLvE2ueEovy1rbNdAUz3IisAa7wJgxiM0uhiynAYSSzhlYopxiWmPzCo c78S0IVRe2DbPLsR0ZBOSpHzor/y6I8td8mGqTvr+R+qmTiPdLzVQSyG3p1I7dmzfshI k1hLt5sRE15BJaKy/8mfqcZ6C9VGgFG5u9S9dRkzPzfaOOYuXWRjZsEWBM3/Iu/il69j YcmxLx69nQjzmqyIJoARCmxJ3zUS9s33xKuI3x/IWRpYp1ivvjTaISi8YPREz3gqFLtm eSgg== X-Gm-Message-State: AJaThX426jJ4aiqSq3hssGcjDOQDHQ0OYKjCK1APORXYw5ruhXLVeX9s iGwcV4FV0wxF0guymnXBRCqW3ZPz+XYjpWrbIOB5cg== X-Google-Smtp-Source: AGs4zMZqCmNTG1aBrudk4TmPlx6jy2COpmJT3h7QXS919ibe/nxHO/P5PNejzUr0mUykudTSlgK9V2Ekn8aXEpxHO2E= X-Received: by 10.37.47.204 with SMTP id v195mr754424ybv.186.1511916084253; Tue, 28 Nov 2017 16:41:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.90.134 with HTTP; Tue, 28 Nov 2017 16:41:23 -0800 (PST) In-Reply-To: References: From: Jana Iyengar Date: Tue, 28 Nov 2017 16:41:23 -0800 Message-ID: Subject: Re: Swapping Version and Packet Number fields To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a1140a1ec22ac05055f146552" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 00:41:27 -0000 --001a1140a1ec22ac05055f146552 Content-Type: text/plain; charset="UTF-8" +1. I think this PR makes sense, and I've only heard support on the list so far. On Tue, Nov 28, 2017 at 4:28 PM, Martin Thomson wrote: > Ian has a PR open that switches the order of version and packet > number. We discussed this in the context of invariants at the last > meeting and there seemed to be general agreement that moving the > invariant stuff (Version) ahead of the version-specific stuff (packet > number) was a good idea. > > https://github.com/quicwg/base-drafts/pull/939 > > I plan to merge this soon. > > --001a1140a1ec22ac05055f146552 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
+1. I think this PR makes sense, and I've only heard s= upport on the list so far.

On Tue, Nov 28, 2017 at 4:28 PM, Martin Thomson <= martin.thomson@gmail.com> wrote:
Ian has a PR open that switches the order of version and packet
number.=C2=A0 We discussed this in the context of invariants at the last meeting and there seemed to be general agreement that moving the
invariant stuff (Version) ahead of the version-specific stuff (packet
number) was a good idea.

https://github.com/quicwg/base-drafts/pull/939

I plan to merge this soon.


--001a1140a1ec22ac05055f146552-- From nobody Tue Nov 28 17: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 223A71292FD for ; Tue, 28 Nov 2017 17:20:27 -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 ilrIY2mAsKyS for ; Tue, 28 Nov 2017 17:20:24 -0800 (PST) Received: from mail-ot0-x22e.google.com (mail-ot0-x22e.google.com [IPv6:2607:f8b0:4003:c0f::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 D575412025C for ; Tue, 28 Nov 2017 17:20:23 -0800 (PST) Received: by mail-ot0-x22e.google.com with SMTP id h9so1683500oti.0 for ; Tue, 28 Nov 2017 17:20:23 -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=1zlZY9H9hrJB46V+SaTDyjTAhX1C+eBrwon3pNZD7us=; b=NVOYxtsFgqT9U+QSfLfigphUTWXGJKVcQWI52vuJW6/NN8EDG/BOXE9inY4yOUX8LP Ql/t1yYgk8AXrMVsNlfLWPQ9YlvfqiySLJ/5WBdtl68L6h37hj0ZUwTy7WxeOlBVcHut b/ccbFdXd9iQynYSX7Zfmo2jRZEZi00jtONOCUDWD4Wfc1pnbRiPfjdCy56se6TO3C2s Q69xcOdB7lTDqsaVqq+nMY+BYcoMI0YKZ68hA7UoA1wqTIIHFvyCJ6/7EN+g2+loFOTC ev9hFrS7J2Q+EK3k/ZWaJ1l/Y3ASWSD/CKba/ncxWAkskOdQAawS0W9W0wK/EP4odZ+G hfHQ== 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=1zlZY9H9hrJB46V+SaTDyjTAhX1C+eBrwon3pNZD7us=; b=HDR0LHxFp+KUYusM9swCmFYVNJajLR8cpDB9IEKjKn8jWg8Dra3o9Y58FpEhPNljYq URFnXxrBwXhvncb7ooJvVlYv2xzd81tuhP2TyGBfPEcw6iu/urkUq4Ig7N2TaqYNV8v8 zpK8ZL4ysuQYQj9UGJ+81btiV6FlB0GSJ3tIXLxaRBHbOJv8SrzOOD1AvurUcWMK+riG 9hrpcsZW6DXNr3V78xAzzD7Mu7c0uR+7WbPBSff9v+2TbRD96A7a88lf+JJiwDNVgeK+ zlG0ZtZLBI9Llu3miz/qa/sBvDdE/RypjvVzSvUfJt8B/mxob0Rts1FHmP03zTcPrEg1 bYNQ== X-Gm-Message-State: AJaThX5EWcciHIxWm1rWfQzEL2loFd2VTSNaML1LOF+ief4JXfoywUPO rfs7bZfu7AdjrEQXF55JjcWZwwyhZ0ReloD9+wuZuEja X-Google-Smtp-Source: AGs4zMY8jzlcaJeZODtxKsAB2lXkuXa6i1ZEQEldUaWMruM0vTtt6Q1S1nO3FUunzNUA7uO35+jvZq/QR+VquJ0lSkU= X-Received: by 10.157.74.4 with SMTP id h4mr1007850otf.308.1511918422908; Tue, 28 Nov 2017 17:20:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Tue, 28 Nov 2017 17:20:22 -0800 (PST) From: Martin Thomson Date: Wed, 29 Nov 2017 12:20:22 +1100 Message-ID: Subject: Packet Number Randomization, 0, or 1 To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 01:20:27 -0000 After a lot of back-and-forth on this subject, it seems like the value of greasing outweighs any particular fixed value. Let the network have a 0 (or 1) and it will always expect that value, but if we randomize then it has nothing. To that end, I've a PR that increases the amount of randomization so that we don't forget to randomize the high bit as well. https://github.com/quicwg/base-drafts/pull/964 I have retained 0 as a valid potential value. There doesn't seem to be a strong consensus either way on this particular point, so I'm leaving issue 832 be for the moment. From nobody Tue Nov 28 20:50: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 2CEBD1201F2 for ; Tue, 28 Nov 2017 20:50:58 -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_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 eErk74qPgS53 for ; Tue, 28 Nov 2017 20:50:56 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 60A261200F1 for ; Tue, 28 Nov 2017 20:50:56 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx16.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eJuKi-00039c-Be for quic@ietf.org; Wed, 29 Nov 2017 05:50:53 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eJuKg-0004NR-Os for quic@ietf.org; Tue, 28 Nov 2017 23:50:51 -0500 Received: (qmail 30281 invoked from network); 29 Nov 2017 04:50:48 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.196]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Nov 2017 04:50:47 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: <0f2618b6-86ea-f1c5-a3c7-aa5807cf880a@huitema.net> Date: Tue, 28 Nov 2017 20:50:45 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Subject: Re: Swapping Version and Packet Number fields X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.38) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5tGcgLIZpNypUGcM9doQ7HAXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fucC7z+ifoPGh9HuqWIXbC1B98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYdfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XIKcwsOsYjBjCZN249H7KzSqpR+WsWEoFdiO1WLSqm BPSwFySZxqWAIVU8LfaDU+TGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kAN1Mi/5oPXF0IaYXV2I96ukONoJfh+XjGSeeT90H/uIF4 BTVLWptRSZLF2XFejqfaiMmOK50hAOsUC7KjS0SE52bjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW87eqULwgkV+w1Dqc0gmbgvfFcHV2tQAVqGdj/zM7G/FqHXIoSsvffuCdDqwWbJR15ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 04:50:58 -0000 On 11/28/2017 4:41 PM, Jana Iyengar wrote: > +1. I think this PR makes sense, and I've only heard support on the > list so far. It does make sense, but it means that we are jettisoning any hope of version negotiation down to FF000007 from FF000008. Which means that we have a timing issue. When do we switch from one to the other? -- Christian Huitema From nobody Tue Nov 28 21:32: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 B2881126B7E for ; Tue, 28 Nov 2017 21:32:25 -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 13WuMtknyZuX for ; Tue, 28 Nov 2017 21:32: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 567BE1241FC for ; Tue, 28 Nov 2017 21:32:24 -0800 (PST) Received: by mail-ot0-x236.google.com with SMTP id s4so2067166ote.4 for ; Tue, 28 Nov 2017 21:32: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=98NzYfXXjnckSHFMjugrNg6cNy63SDm70bDJOHwtEak=; b=JpvCZWq/rBIqJ3unne7PE8UaZUIkNm4HPQki5BXOCV6HZ1JzOLt1XYzngmqVJHP740 pKepKiNjuOvDE4GwYyFUya3Gy5GAJT1W5v5zsb7TrTW+81ox1RbMZXs6ZHsNIrlGhPKW 7+N6hVOhnDX1THhLkzv6wJ22cQ5eVEEwSRXqqKmfeb39mDisouH2gFgwl1YTV0cpARKA hfjsxbrSjTaJqTl/hxs0zyfZeSFo2GKXU3ADeEwNAXEB1P/aK89IUy4kIQ8NRpokHU+m i5G6WqRTvXBNOfMSn2gPgAL6laqrrRJa05cqjuYoe+BJ0OnnjKUK8P7ZnfsczgZREGCY qLlQ== 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=98NzYfXXjnckSHFMjugrNg6cNy63SDm70bDJOHwtEak=; b=sK7EoHRSUK8fliC3OsgDJvNitI48s30NOAQ3/hsoSNES2a1Y4Co+6SCgbtr3+ck5CB CCWdJrT4WEBh1jpO87BLCD2JcAtxI5AQ/44Id3J7r8TjmcB+sG1v1KXzJ3hU1+tk9St1 5tqTh6+LQ9MkwRD/XSRpItZyT0b8CD5Vi0RxNyA0j/2RVmp1ihHQ8Jm+KvrwwpN1/qAv wrJrZp3RRAstTSB6zqXmnAJdTZ6UBFiN02GssoAbHUFSiDRJ3THRLnp0MjSf+2U3lSBG IEHoIl+IzVRE1uocNkpKQ97x1tj7yXEZ+r6uLRP1czZ7rx/6IbTjDPOXuGq/69AIP71D Qe8g== X-Gm-Message-State: AJaThX5vnX8uHK9mqPbwtIannD1N0DJGcCfiQejqPz3ucFqlgbXXVea/ ZPkBkvi28zS4TgJkTJKgEYn2fsVpj00ZbyeNxVw0Ag== X-Google-Smtp-Source: AGs4zMbACf43ZoROt66ah3TG4Rev+XgZTCRP9af1/eCFnTR+8dWMB4G1wuKGxcbfKbqLTDVbMkETxMYVmH6RvIR0JPA= X-Received: by 10.157.39.45 with SMTP id r42mr1575708ota.71.1511933543649; Tue, 28 Nov 2017 21:32:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Tue, 28 Nov 2017 21:32:23 -0800 (PST) In-Reply-To: <0f2618b6-86ea-f1c5-a3c7-aa5807cf880a@huitema.net> References: <0f2618b6-86ea-f1c5-a3c7-aa5807cf880a@huitema.net> From: Martin Thomson Date: Wed, 29 Nov 2017 16:32:23 +1100 Message-ID: Subject: Re: Swapping Version and Packet Number fields To: Christian Huitema Cc: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 05:32:26 -0000 We will have to coordinate that. Hopefully no one is crazy enough to deploy this, so it's only a question of interop targets. On Wed, Nov 29, 2017 at 3:50 PM, Christian Huitema wrote: > On 11/28/2017 4:41 PM, Jana Iyengar wrote: > >> +1. I think this PR makes sense, and I've only heard support on the >> list so far. > > It does make sense, but it means that we are jettisoning any hope of > version negotiation down to FF000007 from FF000008. Which means that we > have a timing issue. When do we switch from one to the other? > > -- Christian Huitema > From nobody Tue Nov 28 23:01: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 9AA70124C27 for ; Tue, 28 Nov 2017 23:01:22 -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 (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 knXTxVj6MiaF for ; Tue, 28 Nov 2017 23:01:20 -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 BC7BA124BAC for ; Tue, 28 Nov 2017 23:01:20 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id y187so967227ywd.12 for ; Tue, 28 Nov 2017 23:01: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=qXECcH+EETUL43cRiTTQI5Ffiz7f+kJTsP0Tcx4wljw=; b=iX8LDZAF+id15gWK8I8JvldPNBiKmy4yvjgh/OjtGqWl8SUzLLMwtm026TO4cHuyEO 62nfRxR65doOTCZanuq8jY7JcUvpmAm2QeEecrFRNGkowaIf2/Aei770CPCHDPT96Ith 0nN3r+xfNRDTOND/mOj/dqwPOHgF4/BkVjNSC7HVL+evel/3dBfnkn7d3DpHjAnRgjeE YHhRKlLpchudW5agScg+GdDwYqq+vY9yQnZfoOZMEWssTzyjBpAWpRPIO2RUjD3RUa4w 7uCklUT6GYxM7DiTSPbSG6k71z8VeTq43OsudPtN2nlhrv1R8Ye0NpRZGTQ8ubTzGXC3 hdeg== 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=qXECcH+EETUL43cRiTTQI5Ffiz7f+kJTsP0Tcx4wljw=; b=njZz3aTumggE/a+lg+uNK27Bc+vUH4m3uUOYUFe8SrTq/j1Fc4paNyauI0qRhx1Flz UJ8uNcxCEQ0fT180Pj5MgZ8i8qn1xMC4QzXRZaw0BcK8KPvLZmaJDb61+c2CftAHzQUS 0RFrI/xq7J6u80aRuKDha1P85BnZzSWipUcaZR3nCqvtrJbcntoaZn3ZJwmXVY+WQnPS vZKwW7t9BlIBzQXHCJokOyVne9hD6uVbZo00bMN9zAbB511D3QK4meJqfXzEIcF/YyGu A1xUto/ksrRPJQngSvXP522vqN59zUnK6cF5uYC9Gp5SeyGOH60iQB0L5fkYdS0zNLkk qgEw== X-Gm-Message-State: AJaThX6lp5io7dXhDxFq29aAdniQ0dp9p+kc7au3Ptx4+pnYzwfvHRMl j3P2ZdlEiXm1x5hf1nOZ5vfjTfDckzEWT9ayR2zdahys X-Google-Smtp-Source: AGs4zMZJ02fkba8zd99LSmqhnMmV41up+D96TYWzrinOzkaO+jvvchkZ/iqKu9mLrsscmBrGgtglSYbDOjpCNGQOV3c= X-Received: by 10.129.226.6 with SMTP id p6mr1185590ywl.72.1511938879626; Tue, 28 Nov 2017 23:01:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.37.90.134 with HTTP; Tue, 28 Nov 2017 23:01:18 -0800 (PST) In-Reply-To: References: <0f2618b6-86ea-f1c5-a3c7-aa5807cf880a@huitema.net> From: Jana Iyengar Date: Tue, 28 Nov 2017 23:01:18 -0800 Message-ID: Subject: Re: Swapping Version and Packet Number fields To: Martin Thomson Cc: Christian Huitema , QUIC WG Content-Type: multipart/alternative; boundary="f403043eca78d83c6c055f19b334" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 07:01:23 -0000 --f403043eca78d83c6c055f19b334 Content-Type: text/plain; charset="UTF-8" Good point, but as Martin notes, we can be careful around interop. There is no real deployment yet, so we're safe. (Also, this is a good reason to do this swap now if we're ever going to do it.) On Tue, Nov 28, 2017 at 9:32 PM, Martin Thomson wrote: > We will have to coordinate that. Hopefully no one is crazy enough to > deploy this, so it's only a question of interop targets. > > On Wed, Nov 29, 2017 at 3:50 PM, Christian Huitema > wrote: > > On 11/28/2017 4:41 PM, Jana Iyengar wrote: > > > >> +1. I think this PR makes sense, and I've only heard support on the > >> list so far. > > > > It does make sense, but it means that we are jettisoning any hope of > > version negotiation down to FF000007 from FF000008. Which means that we > > have a timing issue. When do we switch from one to the other? > > > > -- Christian Huitema > > > > --f403043eca78d83c6c055f19b334 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Good point, but as Martin notes, we can be careful around = interop. There is no real deployment yet, so we're safe. (Also, this is= a good reason to do this swap now if we're ever going to do it.)
=

On Tue, Nov 28, 2= 017 at 9:32 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
We will have to coordinate th= at.=C2=A0 Hopefully no one is crazy enough to
deploy this, so it's only a question of interop targets.

On Wed, Nov 29, 2017 at 3:50 PM, Christian Huitema <huitema@huitema.net> wrote:
> On 11/28/2017 4:41 PM, Jana Iyengar wrote:
>
>> +1. I think this PR makes sense, and I've only heard support o= n the
>> list so far.
>
> It does make sense, but it means that we are jettisoning any hope of > version negotiation down to FF000007 from FF000008. Which means that w= e
> have a timing issue. When do we switch from one to the other?
>
> -- Christian Huitema
>


--f403043eca78d83c6c055f19b334-- From nobody Tue Nov 28 23:09: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 45367124C27; Tue, 28 Nov 2017 23:09:11 -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, SPF_PASS=-0.001] autolearn=ham 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 p3gFini_j66F; Tue, 28 Nov 2017 23:09:09 -0800 (PST) Received: from mx142.netapp.com (mx142.netapp.com [IPv6:2620:10a:4005:8000:2306::b]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A364F124BAC; Tue, 28 Nov 2017 23:09:09 -0800 (PST) X-IronPort-AV: E=Sophos;i="5.44,471,1505804400"; d="asc'?scan'208";a="225118421" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx142-out.netapp.com with ESMTP; 28 Nov 2017 23:09:08 -0800 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by VMWEXCHTS04-PRD.hq.netapp.com (10.122.105.32) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 28 Nov 2017 23:09:09 -0800 Received: from NAM02-CY1-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Tue, 28 Nov 2017 23:09:08 -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=9uw2E8SuM/7uen/f82zbL1YNl2gky+MDmEesKmvFKyE=; b=h/b8ke18wjC/btzLGplXbKKzMIhV6dge1btLfU8s8LsrL8hRH2xmCZVcYtwHNWhfU12DXGM+xzfu8etXTkb8MivifQKxY4dtbtBuybIlzW6cGdbkBGPRobs1VLFodzAi9V/LSqqgBuCff+fkHXCPMbphjG8hYrpz+PGrxD1+aVE= Received: from BLUPR06MB1764.namprd06.prod.outlook.com (10.162.224.150) by BLUPR06MB1763.namprd06.prod.outlook.com (10.162.224.149) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.260.4; Wed, 29 Nov 2017 07:09:06 +0000 Received: from BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) by BLUPR06MB1764.namprd06.prod.outlook.com ([10.162.224.150]) with mapi id 15.20.0260.007; Wed, 29 Nov 2017 07:09:06 +0000 From: "Eggert, Lars" To: Brian Trammell CC: "Black, David" , "tsv-area@ietf.org" , QUIC WG , Al Morton Subject: Re: Spin bit discussion - where we're at Thread-Topic: Spin bit discussion - where we're at Thread-Index: AQHTY2jqp1VdukIM2U+G9HAjuBI8daMgHeUAgAANHICAAAmEgIAABm6AgAbXQwCAANXCAIACjivQgAAUcYCAAHB8gA== Date: Wed, 29 Nov 2017 07:09:06 +0000 Message-ID: References: <21B07D8C-C4A1-4321-9E43-61C9DB9DC4CA@trammell.ch> <4D7F4AD313D3FC43A053B309F97543CF4904F2FD@njmtexg5.research.att.com> <791D0F33-4CB7-4049-AF29-174E41C1FD2E@netapp.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.4.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [109.43.1.141] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:qupB32bMn4CtHD+CY69E7Dn+zLFuCm6CAqDfcETKz/DT5arU6DUWLyASMg1kZt1ViXZJmm5y/yYmDCsVMa9ncRG60WaMmYkFdXkb5JuaPyt5DOSoCNg3mg8TFbKRFNEQs1C6dA/xFSZbcEVQkmQevQYp2UTKmHZjJyqMVYGELhLgbNPlCxU/Q5e/UCPGYDN2i+iuUVso8yxa8R6VWnE8+Na1Vgqg26lpWnqUoKlkqPZbPaZi0qQWiDVP9aSXJb7zJhVulCCr05Ck9DVygwp5outb5tun09YrW6hsH2223xdm9OWFFHRTnZcae3g1gm9pV/+0qp2ZNy54R5UHlZmvo/rUp6ZRZOpaciGImDG3Akk=; 5:FvvB9ktyxQHtH1HoPM/4S7Dua/5Y8yv0XGU0i4HpqIC9yBvH83OrvSV0/CZTvSJmn6U7z2JVAHWJA56xVKAYlwaZR7mdPXA1fz0QXVOzq98PbNYtrjXtT0Z8XQ8ygcR/FOFwmX14EsT7QA5km4smoiEdGK8eR2sqx7Wqb4xee74=; 24:FL2iQ/WWOjbFvi4qFGIZOJ18Wv+de6undAZ/Kq0IqKUhMJOC3OfkMUasJEyIOHo55BF65WNScoXbIiYRqrP21k+6qBJhf2GUlRWr0vz4QLI=; 7:VyhiF+X7Rr/QXp7+8DjsKzRr4Hugq6lk+C2wupRRgmk6qenYBphduAS3EczWIGsyitDRhMme5L/nny4YzfFd4sH3Y/FFnnlCilUZubTcQFFif37oddIWcoHZgHxPsB835WjwXXZHSyLQ5Qx+8SZkObAARJNigN1egLjDntuMOfEhFdY1bj7AfXzqMwjjmImKUXOgkaWydGUwcpOMxMh75HSek037eCRnAwVnKgm0915kUl69hSZnR3bEslnRNTea x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: e7b39c40-34ba-48c6-61d8-08d536f8146f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(5600026)(4604075)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415395)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231022)(10201501046)(6055026)(6041248)(20161123558100)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(6072148)(201708071742011); SRVR:BLUPR06MB1763; BCL:0; PCL:0; RULEID:(100000803101)(100110400095); SRVR:BLUPR06MB1763; x-forefront-prvs: 05066DEDBB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(366004)(346002)(376002)(24454002)(199003)(377424004)(189002)(86362001)(575784001)(99286004)(6246003)(8666007)(8936002)(99936001)(6512007)(68736007)(57306001)(14454004)(50226002)(54906003)(53936002)(6116002)(3280700002)(3846002)(229853002)(50986999)(4001150100001)(76176999)(4326008)(6506006)(102836003)(101416001)(478600001)(3660700001)(77096006)(6486002)(6436002)(97736004)(25786009)(2906002)(33656002)(106356001)(105586002)(189998001)(93886005)(305945005)(8676002)(7736002)(2900100001)(2950100002)(66066001)(83716003)(53546010)(316002)(36756003)(6916009)(5660300001)(81156014)(81166006)(82746002); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1763; H:BLUPR06MB1764.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=_B91C8370-C8A8-4F99-BE9F-A1C45F966D52"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e7b39c40-34ba-48c6-61d8-08d536f8146f X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2017 07:09:06.4332 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4b0911a0-929b-4715-944b-c03745165b3a X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR06MB1763 X-OriginatorOrg: netapp.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 07:09:11 -0000 --Apple-Mail=_B91C8370-C8A8-4F99-BE9F-A1C45F966D52 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-11-29, at 1:26, Brian Trammell (IETF) wrote: > There are three possible states for an ECN negotiation: not attempted, = failed, and succeeded. Each of these can add a fractional bit of = information about the client and server TCP implementations. If a server = negotiates ECN, you can be reasonably certain that it supports ECN, and = can leverage the observations that sysadmins love defaults and servers = are mostly Linux these days to figure out whether it's running a kernel = before or after server side defaults were turned on. >=20 > Long-term observation of the ECN negotiation attempts of a client can = be used to determine if the client is using probabilistic negotiation by = default; i.e. is an Apple device of a certain vintage. >=20 > These are fractional bits of fingerprinting information, though, if = that. I'm almost certain (but won't take the time to do the research = now) that any of these observations would be useless. Anyone in a = position to make them could also get much more information about the = behavior of the TCP stacks at each end, such that the ECN bits add = negligible information. cf. p0f, if that's still a thing. this is certainly all true for TCP and ECN, where whether ECN is = available and/or tried by default is tied to a certain kernel versions. But for QUIC (=3D ECN with UDP), whether ECN is used or not is = completely up to the app (=3D the QUIC stack), so you can't draw = conclusions about whether a certain kernel or OS flavor is underneath = (other than they less than about ten years old, i.e., have support for = the IP_TOS/IP_RECVTOS socket options.) So the fractional information leakage seems to be less than with TCP. Lars --Apple-Mail=_B91C8370-C8A8-4F99-BE9F-A1C45F966D52 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAloeXREACgkQVLXDCb9w wVc+ihAAjiXHseS6HQXZjBeI4WAW4GzoJIo9K1DR68xMsFovTn+36OFh9qfc3gg4 ueAE9IozeqFzhKpawNYhuvcF0nAqngSKTIwXR4pR2fTx+Yhu0aHlONDdiwnhY7Xu tnjO00dIkUylyIBulH/hFncXxwZr1/wAAILCpKTxTKhy3btZYB1UpUqIBh5r2L3s A2KPe0wXdEGHXJp3QMTi3pDUvL66L1mP2dXu7D/7/J09PM/VSrjhyYbo5kcvlS3m t+Rowi8hI7TIr/9+T/dcxLXwu7Bm4M/zZ1yrNpVarcMi815kcISaHRLSvlCi2ngO mZhzczffdig4zeODMM99633t1pIBIuR/NqISxmOkgXF48SSQxwDGOH82vp5zr6EJ DgO6NW8V4GHzVvJDeV08oQZFkewZdMpI+kSGd8RMRnoOkGGtQBUQuKAPg5KRu6vc +v0LlCLd896ZSnqL3M2XvkYl68UuX7K932CSVmHGiG9DH9QR6FBqnpWMGYBIcyJx ymxDJx2bo4Z5s9VM34X1dTqlb4oAQtkLtacTcnvOBC00gtaVmHwdrcfaG4QC/ipk to0qbFLNn2u8mEl0qxWUfFAP/ycW7Tcog8Wl3sItB1U7sQp1kNJv6SdV3xp6bJdi bT+GGbZh+sVB2WNyARvZfxpk2m49MVa03gVMbUASIJsILV8EjfA= =Rl10 -----END PGP SIGNATURE----- --Apple-Mail=_B91C8370-C8A8-4F99-BE9F-A1C45F966D52-- From nobody Wed Nov 29 04:13: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 512DF1274A5 for ; Wed, 29 Nov 2017 04:13:31 -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, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zIEx9NGPj7_s for ; Wed, 29 Nov 2017 04:13:29 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D5A51273E2 for ; Wed, 29 Nov 2017 04:13:29 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1B430E9710DB1 for ; Wed, 29 Nov 2017 12:13:25 +0000 (GMT) Received: from DGGEMM422-HUB.china.huawei.com (10.1.198.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 29 Nov 2017 12:13:26 +0000 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.96]) by dggemm422-hub.china.huawei.com ([10.1.198.39]) with mapi id 14.03.0361.001; Wed, 29 Nov 2017 20:13:19 +0800 From: Roni Even To: Benjamin Kaduk , QUIC WG Subject: RE: Spin bit discussion - where we're at - use case exsist!!! Thread-Topic: Spin bit discussion - where we're at - use case exsist!!! Thread-Index: AQHTaGUIzB9fYG/ZMEaLuMn9E6PpI6MrQD+g Date: Wed, 29 Nov 2017 12:13:18 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD847B77@DGGEMM506-MBX.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD8464CB@DGGEMM506-MBX.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.203.55] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 12:13:31 -0000 SGksDQpTb21lIGNsYXJpZmljYXRpb25zOg0KIFRoZSBtZWFzdXJlbWVudHMgYXJlIG5vdCBkb25l IHRvIHJlc29sdmUgY29tcGxhaW5zIGJ1dCB0byBkaXNjb3ZlciBwcm9ibGVtcyBhaGVhZCBvZiB0 aW1lcyBzbyB0aGUgb3BlcmF0b3IgY2FuIHByb3ZpZGUgdGhlaXIgdXNlciBiZXR0ZXIgUW9FLg0K SWYgdGhlIGVuZCB1c2VyIGNvbXBsYWluIGFib3V0IHRoZSBwcm9ibGVtIGl0IGlzIGdvb2QgaWYg dGhlIElTUCBjYW4gdGVsbCBiYXNlZCBvbiB0aGUgaW5mb3JtYXRpb24gaGUgaGFzIGlmIHRoaXMg aXMgYSBwcm9ibGVtIHdpdGggdGhlIGNvbnRlbnQgcHJvdmlkZXJzICwgdGhlIHVzZXIgaG9tZSBu ZXR3b3JrIG9yIGxldCB0aGUgdXNlciBrbm93IHRoYXQgdGhleSBhcmUgYXdhcmUgb2YgdGhlIHBy b2JsZW0gYW5kIGFyZSB0cnlpbmcgdG8gZml4IGl0LiBUaGUgSVNQIHB1dCBwcm9iZXMgaW4gdGhl IGVkZ2UgaWYgdGhlIElTUCBuZXR3b3JrLg0KDQpTb21lIG1vcmUgY29tbWVudHMgaW5saW5lDQpS b25pDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogQmVuamFtaW4gS2Fk dWsgW21haWx0bzpia2FkdWtAYWthbWFpLmNvbV0NCj4gU2VudDog15nXldedwqDXkiAyOCDXoNeV 15HXnteR16ggMjAxNyAxODoyMg0KPiBUbzogUm9uaSBFdmVuOyBRVUlDIFdHDQo+IFN1YmplY3Q6 IFJlOiBTcGluIGJpdCBkaXNjdXNzaW9uIC0gd2hlcmUgd2UncmUgYXQgLSB1c2UgY2FzZSBleHNp c3QhISENCj4gDQo+IE9uIDExLzIzLzIwMTcgMTI6MTMgQU0sIFJvbmkgRXZlbiB3cm90ZToNCj4g PiA8c25pcD4NCj4gPj4gMSkgQSBkZXNjcmlwdGlvbiBvZiB0aGUgdXNlIGNhc2UocykgdGhhdCBt b3RpdmF0ZSB0aGlzIHByb3Bvc2FsLiBXZQ0KPiA+PiB1bmRlcnN0YW5kIHRoYXQgdGhlIGdvYWwg aXMgdG8gbWVhc3VyZSBSVFQsIGJ1dCBzb21lIHBlb3BsZSBhcmUgc3RpbGwNCj4gPj4gdW5jbGVh ciBhcyB0byB3aHkgdGhhdCdzIG5lY2Vzc2FyeSB0byBvcGVyYXRlIGEgbmV0d29yay4gRGV0YWls ZWQNCj4gPj4gc2NlbmFyaW9zIGFuZCBpZGVhbGx5IHJlYWwtd29ybGQgZXhhbXBsZXMgKGUuZy4s IGZyb20gVENQKSB3b3VsZCBoZWxwDQo+IHRyZW1lbmRvdXNseS4NCj4gPj4gU2F5aW5nICJJIG5l ZWQgdG8gZGVidWcgdGhlIG5ldHdvcmsiIGlzIG5vdCBlbm91Z2ggZGV0YWlsLg0KPiA+Pg0KPiA+ IFtSb25pIEV2ZW5dIEkgc3VibWl0dGVkIHN1Y2ggYSBkb2N1bWVudCBidXQgSSBhc3N1bWUgdGhh dCBub2JvZHkgcmVhZCBpdA0KPiBzaW5jZSBJIHdvdWxkIGV4cGVjdCB0aGF0IHRoaXMgYnVsbGV0 IHdpbGwgYXQgbGVhc3QgbWVudGlvbiBpdCAhISENCj4gPg0KPiA+IFNlZQ0KPiA+IGh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtZXZlbi1xdWljLXRyb3VibGVzaG9vdGluZy12aWRlby1k ZWxpdmUNCj4gPiByeS0wMC50eA0KPiA+DQo+ID4gUGxlYXNlIHJlYWQgdGhlIGRvY3VtZW50DQo+ ID4NCj4gDQo+IE9rYXksIEkgd2VudCBhbmQgcmVhZCB0aGUgZG9jdW1lbnQuwqAgSSdtIG5vdCBy ZWFsbHkgc3VyZSBob3cgbXVjaCBpdA0KPiBoZWxwcyBtZSB1bmRlcnN0YW5kIHRoZSBzY2VuYXJp b3MgaW4gcXVlc3Rpb24uDQo+IA0KPiBUaGUgaGlnaCBsZXZlbCB0YWtld2F5cyBmcm9tIG15IHJl YWQgb2YgdGhlIGRvY3VtZW50IHNlZW0gdG8gYmU6DQo+IA0KPiBvIFN0cmVhbWluZyB2aWRlbyBp cyBjb21tb24sIGFuZCBhIGNvbW1vbiBzb3VyY2Ugb2YgZW5kLXVzZXIgY29tcGxhaW50cw0KPiB3 aGVuIGl0IGRvZXNuJ3Qgd29yayB3ZWxsLsKgIChJdCBhbHNvIHVzZXMgYSBsb3Qgb2YgYmFuZHdp ZHRoLikNCltSb25pIEV2ZW5dIEluIHNvbWUgY2FzZXMgbGluZWFyIHZpZGVvIGlzIGEgcGFpZCBz ZXJ2aWNlIGFuZCB0aGUgZW5kIHVzZXIgZXhwZWN0IGdvb2QgdXNlciBleHBlcmllbmNlIChRb0Up IHRoYXQgbWF5IGJlIGFsc28gYmFzZWQgb24gU0xBIGJldHdlZW4gdGhlIGNvbnRlbnQgcHJvdmlk ZXIgYW5kIHRoZSBJU1AuDQoNCj4gDQo+IG8gQSBtZWFzdXJlbWVudCBwb2ludCBpbiB0aGUgbWlk ZGxlIG9mIGEgVENQIGZsb3cgY2FuIHVzZSBUQ1Agc2VnbWVudA0KPiBudW1iZXJzIHRvIGVzdGlt YXRlIFJUVCBmb3IgdGhlIHVwc3RyZWFtIGFuZCBkb3duc3RyZWFtIGhhbGZzIG9mIHRoZQ0KPiBm bG93LCBpLmUuLCBhIHZpZGVvIHN0cmVhbWluZyBmbG93IHRoYXQgaXMgbGFyZ2VseSBzZXJ2ZXIt dG8tY2xpZW50DQo+IGdpdmVzIGEgbW9yZSByZWxpYWJsZSBSVFQgZG93bnN0cmVhbSBSVFQgZXN0 aW1hdGUgKGkuZS4sIGJldHdlZW4NCj4gbWVhc3VyZW1lbnQgcG9pbnQgYW5kIGNsaWVudCkuwqAg UlRUIGVzdGltYXRlcyBjYW4gYmUgbm9pc3kgZHVlIHRvDQo+IGRlbGF5ZWQgYWNrcyBhbmQgcGFj a2V0IGxvc3MuDQpbUm9uaSBFdmVuXSAgeW91IGFyZSByaWdodCwgdGhlIGltcGxlbWVudGF0aW9u cyB0YWtlIHRoaXMgaW50byBhY2NvdW50IGJ5IGRvaW5nICAgbGluZWFyIHNtb290aGluZyBvciBt b3ZpbmcgbWluaW11bSBmaWx0ZXIuIFdlIGRpZCBub3QgZ28gaW50byB0aGF0IHNpbmNlIHRoZSBk b2N1bWVudCBkZXNjcmliZXMgdGhlIHVzZSBjYXNlIGFuZCBub3QgdGhlIGFsZ29yaXRobXMuDQo+ IA0KPiBvIFN1Y2ggYSBtZWFzdXJlbWVudCBwb2ludCBjYW4gYWxzbyBlc3RpbWF0ZSB1cHN0cmVh bS9kb3duc3RyZWFtIGxvc3MNCj4gYnkNCj4gZXhhbWluaW5nIHRoZSBzbGlkaW5nIHdpbmRvdyBh bmQgb2JzZXJ2aW5nIHJldHJhbnNtaXRzLiBGb3IgdGhlDQo+IHNlcnZlci10by1jbGllbnQgdmlk ZW8gZmxvdywgdGhlIGRvd25zdHJlYW0gbG9zcyBlc3RpbWF0ZSBpcyBhZ2FpbiB0aGUNCj4gbW9y ZSByZWxpYWJsZSBvbmUNCj4gDQo+IG8gSG9tZSB3aWZpIGlzIGEgY29tbW9uIHNvdXJjZSBvZiBw cm9ibGVtcywgYW5kIHdpZmkgaGFzIGEgdW5pcXVlDQo+IHNpZ25hdHVyZSBvZiBoaWdoIFJUVCBj b21iaW5lZCB3aXRoIGxvdyBsb3NzLsKgIEkgZ3Vlc3MgdGhlIGlkZWEgaXMNCj4gc3VwcG9zZWQg dG8gYmUgdGhhdCBhIG1lYXN1cmVtZW50IHBvaW50IGNsb3NlIHRvIHRoZSBob21lIG5ldHdvcmsg Y2FuDQo+ICJibGFtZSIgdGhlIHdpZmkgaWYgaXQgc2VlcyBoaWdoIFJUVCBidXQgbm90IG11Y2gg bG9zcyBvbiB0aGUgZmxvdyBpbg0KPiBxdWVzdGlvbj8NCj4gDQo+IG8gTmV0d29yayBvcGVyYXRv cnMgY2FuIHVzZSBiaWcgZGF0YSBhbmFseXRpY3MgdG8gZGV0ZWN0IGRldmlhdGlvbnMgZnJvbQ0K PiBub3JtYWwgbmV0d29yayBtZXRyaWNzIGFuZCBpc29sYXRlIGZhdWx0eSBuZXR3b3JrIHNlZ21l bnRzLsKgIFRoZSBhYm92ZQ0KPiBSVFQgYW5kIGxvc3MgbWV0cmljcyBhdCBtZWFzdXJlbWVudCBw b2ludHMgYXJlIHVzZWQgYXMgZXhhbXBsZXMgYnV0IG5vDQo+IGNsYWltIGlzIG1hZGUgdGhhdCBv dGhlciBtZXRyaWNzIHdvdWxkIG5vdCBwcm92aWRlIGVxdWFsbHkgZnVuY3Rpb25hbA0KPiBpbnB1 dCBmb3IgYW5hbHl0aWNzLg0KPiANCltSb25pIEV2ZW5dIHdlIGRlc2NyaWJlIHdoYXQgYXJlIHRo ZSBjdXJyZW50IHByYWN0aWNlcyAuICBSVFQgYW5kIHBhY2tldCBsb3NzIGFyZSB0aGUgYmFzaWMg bWVhc3VyZW1lbnRzIGFsbG93aW5nIHRoZSBjYWxjdWxhdGlvbnMgb2YgZGlmZmVyZW50IG1ldHJp Y3MgbWV0cmljcywgZm9yIGV4ZW1sZSBmb3IgUW9FIGluIElQVFYgdGhlcmUgYXJlIElUVS1UIGRj dW1lbnRzIGxpa2UgRy4xMDExIGFuZCBHLjEwODAgcmVjb21tZW5kaW5nIG1ldHJpY3MgZm9yIFFv RS4gICBBcyBmb3Igb3RoZXIgbWVhc3VyZW1lbnRzIHdoaWNoIG9uZSBkb2VzIGhlIGhhdmUgaW4g bWluZCB0aGF0IHdpbGwgYmUgc2ltcGxlIGZvciBwYXNzaXZlIG1vbml0b3JpbmcuDQoNCj4gbyBU aGUgbmV0d29yayBvcGVyYXRvciBjYW4gdXNlIFJUVC9sb3NzIGVzdGltYXRlcyBmcm9tIGEgbWVh c3VyZW1lbnQNCj4gcG9pbnQgbmVhciB0aGUgc2VydmVyIGFzIGV2aWRlbmNlIHRvIHRyeSB0byBj b252aW5jZSB0aGUgc2VydmVyIG9wZXJhdG9yDQo+IHRoYXQgdGhlIHNlcnZlcigncyBuZXR3b3Jr KSBpcyBtaXNiZWhhdmluZy4NCj4gDQo+IFdoaWxlIHRoZSBkaXNjdXNzaW9uIG9mIGhvdyBhIG1l YXN1cmVtZW50IHBvaW50IGNhbiB1c2Ugc2VnbWVudCBudW1iZXJzDQo+IGFuZCB3aW5kb3cgaW5m b3JtYXRpb24gdG8gZXN0aW1hdGUgUlRUIGFuZCBsb3NzIGlzIHVzZWZ1bCwgSSdtIG5vdA0KPiBv dmVybHkgY29uY2VybmVkIGFib3V0IHRoYXQgZGlzY3Vzc2lvbiBhbmQgYW0gd2lsbGluZyB0byB0 YWtlIGl0IGFzIGEgZ2l2ZW4uDQo+IA0KPiBJIHRoaW5rIHdoYXQgbWlnaHQgaGVscCBtZSB1bmRl cnN0YW5kIHRoZSB1dGlsaXR5IG9mIHRoZXNlIG1lYXN1cmVtZW50cw0KPiBpcyBhIGRldGFpbGVk IHdhbGt0aHJvdWdoIG9mIHdoYXQgd291bGQgaGFwcGVuIGluIHNvbWUgKGh5cG90aGV0aWNhbCkN Cj4gY2FzZSB3aGVyZSBJIGFzIGEgdXNlciBjYWxsIHVwIG15IElTUCBhbmQgY29tcGxhaW4gdGhh dCB5b3V0dWJlIGlzDQo+IG1pc2JlaGF2aW5nLCBhc3N1bWluZyBJIGNhbiBnZXQgdG8gYSBwb2lu dCB3aGVyZSBJJ20gdGFsa2luZyB0byBhIGh1bWFuDQo+IGF0IHRoZSBJU1AgdGhhdCBjYW4gcGVy Zm9ybS92aWV3IHRoaXMgc29ydCBvZiBtZWFzdXJlbWVudCBkYXRhLsKgIFdoYXQNCj4gaW5mb3Jt YXRpb24gZG9lcyB0aGUgSVNQIG5lZWQgZnJvbSBtZT/CoCBXaGF0J3MgdGhlIGZpcnN0IHRoaW5n IHRvIGRvIC0tDQo+IGluc2VydCBhIG1lYXN1cmVtZW50IHBvaW50IGFzIGNsb3NlIHRvIG15IGhv bWUgcm91dGVyIGFzIHBvc3NpYmxlIHRvDQo+IHJ1bGUgKG91dC9pbikgbXkgd2lmaT/CoCBPciBk byB3ZSBzdGFydCBvZmYgYnkgZW5nYWdpbmcgbXVsdGlwbGUNCj4gbWVhc3VyZW1lbnQgcG9pbnRz P8KgIERvZXMgdGhlICJiaWcgZGF0YSIgYW5hbHl0aWNzIGF0IHRoZSBuZXR3b3JrDQo+IG1lYXN1 cmVtZW50IGNlbnRlciBjb21lIGludG8gcGxheSBhdCBhbGwgZm9yIHRoaXMgd2Fsa3Rocm91Z2gg b3IgaXMgaXQNCj4gY29tcGxldGVseSBzZXBhcmF0ZT8NCltSb25pIEV2ZW5dIFNlZSBhYm92ZQ0K PiANCj4gSXQncyBhbHNvIHN0aWxsIHVuY2xlYXIgdG8gbWUgdG8gd2hhdCBleHRlbnQgUlRUL2xv c3MgYXMgaW5wdXQgdG8gdGhlDQo+IG5ldHdvcmsgbWVhc3VyZW1lbnQgY2VudGVyJ3MgYW5hbHl0 aWNzIGlzIHVzZWQgYmVjYXVzZSBpdCdzIGVhc3kgYW5kDQo+IHdvcmtzIHZzLiB3aGF0IHJlc2Vh cmNoIGhhcyBiZWVuIGRvbmUgd2l0aCB1c2luZyBvdGhlciBtZXRyaWNzIGFzIGlucHV0DQo+IHRv IHRoZSBhbmFseXRpY3MuDQpbUm9uaSBFdmVuXSBXaGF0IHdlIGFyZSBsb29raW5nIGF0IGlzIGhv dyB0byBnZXQgcmVsZXZhbnQgaW5mb3JtYXRpb24gYXQgdGhlIHRyYW5zcG9ydCBsZXZlbCB3aGlj aCBpcyB0aGUgbG93ZXN0IGxldmVsIHRoYXQgZ29lcyBlbmQgdG8gZW5kLiBUaGVyZSBhcmUgZGVm aW5lZCBtZXRyaWNzIG9uIHRoZSBJUCBsYXllciBidXQgdG8gZ2V0IGJldHRlciBhbmFseXNpcyB3 ZSBuZWVkIHRoZSBlbmQgdG8gZW5kIG1ldHJpY3MgYXQgaHRlIHRyYW5zcG9ydCBsZXZlbC4NCj4g DQo+IFRoYW5rcywNCj4gDQo+IEJlbg0K From nobody Wed Nov 29 07:18: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 33EC912762F for ; Wed, 29 Nov 2017 07:18:54 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DHyWsHgA-M06 for ; Wed, 29 Nov 2017 07:18:43 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id E1A02127867 for ; Wed, 29 Nov 2017 07:18:42 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 917443400E6 for ; Wed, 29 Nov 2017 16:18:40 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.6995); Wed, 29 Nov 2017 16:18:40 +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 for ; Wed, 29 Nov 2017 16:18:40 +0100 (CET) Received: from [118.243.83.76] (account ietf@trammell.ch HELO [192.168.43.105]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 37660769 for quic@ietf.org; Wed, 29 Nov 2017 16:18:39 +0100 From: "Brian Trammell (IETF)" Content-Type: multipart/signed; boundary="Apple-Mail=_2FA801D2-C245-44F4-ABCF-C6BA93DD54F1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Fwd: New Version Notification for draft-trammell-quic-spin-00.txt Message-Id: References: <151196843291.8033.13384651890461321693.idtracker@ietfa.amsl.com> To: QUIC WG Date: Thu, 30 Nov 2017 00:18:35 +0900 X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 15:18:54 -0000 --Apple-Mail=_2FA801D2-C245-44F4-ABCF-C6BA93DD54F1 Content-Type: multipart/alternative; boundary="Apple-Mail=_9141A07E-17AA-4072-871B-EFA8A053182B" --Apple-Mail=_9141A07E-17AA-4072-871B-EFA8A053182B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Greetings, all, We've submitted an initial -00 version of a draft detailing the spin = bit, as requested by the chairs under the new process to be applied to = changes to the information content of the wire image. This describes the mechanism and its intended usage, our experiments to = date with it, and the privacy analysis undertaken by the RTT DT. We have = a few open issues, mainly on the completion of section 4, adding = additional use cases beyond basic interdomain troubleshooting. Cheers, Brian > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-trammell-quic-spin-00.txt > Date: 30 November 2017 at 00:13:52 GMT+9 > To: "Emile Stephan" , "Giuseppe Fioccola" = , "Piet De Vaere" , = "Thomas Fossati" , "Piet Vaere" = , "Al Morton" , "Brian Trammell" = , "Roni Even" , "Marcus Ihlar" = , "Stephan Emile" >=20 >=20 > A new version of I-D, draft-trammell-quic-spin-00.txt > has been successfully submitted by Brian Trammell and posted to the > IETF repository. >=20 > Name: draft-trammell-quic-spin > Revision: 00 > Title: The Addition of a Spin Bit to the QUIC Transport = Protocol > Document date: 2017-11-30 > Group: Individual Submission > Pages: 14 > URL: = https://www.ietf.org/internet-drafts/draft-trammell-quic-spin-00.txt > Status: = https://datatracker.ietf.org/doc/draft-trammell-quic-spin/ > Htmlized: = https://tools.ietf.org/html/draft-trammell-quic-spin-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-trammell-quic-spin-00 >=20 >=20 > Abstract: > This document summarizes work to date on the addition of a "spin > bit", intended for explicit measurability of end-to-end RTT on QUIC > flows. It proposes a detailed mechanism for the spin bit, describes > how to use it to measure end-to-end latency, discusses corner cases > and workarounds therefor in the measurement, describes experimental > evaluation of the mechanism done to date, and examines the utility > and privacy implications of the spin bit. As the overhead and risk > associated with the spin bit are negligible, and the utility of a > passive RTT measurement signal at higher resolution than once per > flow is clear, this document advocates for the addition of the spin > bit to the protocol. >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 --Apple-Mail=_9141A07E-17AA-4072-871B-EFA8A053182B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Greetings, all,

We've submitted an initial -00 version of a draft detailing = the spin bit, as requested by the chairs under the new process to be = applied to changes to the information content of the wire = image.

This = describes the mechanism and its intended usage, our experiments to date = with it, and the privacy analysis undertaken by the RTT DT. We have a = few open issues, mainly on the completion of section 4, adding = additional use cases beyond basic interdomain troubleshooting.

Cheers,

Brian

Begin forwarded message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification for draft-trammell-quic-spin-00.txt
Date: = 30 November 2017 at 00:13:52 = GMT+9
To: = "Emile Stephan" <emile.stephan@orange.com>, "Giuseppe Fioccola" <giuseppe.fioccola@telecomitalia.it>, "Piet De Vaere" = <piet@devae.re>, = "Thomas Fossati" <thomas.fossati@nokia.com>, "Piet Vaere" <piet@devae.re>, "Al = Morton" <acmorton@att.com>, "Brian Trammell" <ietf@trammell.ch>, = "Roni Even" <roni.even@huawei.com>, "Marcus Ihlar" <marcus.ihlar@ericsson.com>, "Stephan Emile" <emile.stephan@orange.com>

A new version = of I-D, draft-trammell-quic-spin-00.txt
has been = successfully submitted by Brian Trammell and posted to the
IETF repository.

Name: = draft-trammell-quic-spin
Revision: 00
Title:= = The Addition of a Spin Bit to the QUIC Transport Protocol
Document date: 2017-11-30
Group:= = Individual Submission
Pages: 14
URL: =            https://www.ietf.org/internet-drafts/draft-trammell-quic-spin-0= 0.txt
Status: =         https://datatracker.ietf.org/doc/draft-trammell-quic-spin/<= br class=3D"">Htmlized:       https://tools.ietf.org/html/draft-trammell-quic-spin-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-trammell-quic-spin-= 00


Abstract:
  This document summarizes work to date on the = addition of a "spin
  bit", intended for = explicit measurability of end-to-end RTT on QUIC
=   flows.  It proposes a detailed mechanism for the spin = bit, describes
  how to use it to measure = end-to-end latency, discusses corner cases
=   and workarounds therefor in the measurement, describes = experimental
  evaluation of the mechanism done = to date, and examines the utility
  and privacy = implications of the spin bit.  As the overhead and risk
  associated with the spin bit are negligible, and = the utility of a
  passive RTT measurement = signal at higher resolution than once per
=   flow is clear, this document advocates for the addition of = the spin
  bit to the protocol.



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


= --Apple-Mail=_9141A07E-17AA-4072-871B-EFA8A053182B-- --Apple-Mail=_2FA801D2-C245-44F4-ABCF-C6BA93DD54F1 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAloez8sACgkQihK3vwvq RqNqNw/9Ev+rbZGiJscrsWV2E7SFjE7yvddjBMtEoAjULU65MlOBpYMt4XnBrA2l BVjRNejIt98WEntFVfgeygCzkrgNv94U2478pBkUFwUb5C/4k1Dn6PPj3qU5Pz1s 1X9gNHR5VN+Eo1T4E/F1RPBgbzHvYSxlKgGC1gku/KP8hYskLW/YSgEkhenbtr2d 6UtNlUQY8EZT6yARXMqxZLsazkbi7SPektDzJjVvy3ZZChBTmMaoNOJgjKETtlyD bZjU/tJSnhl3bFh6aeRyyovBJYBNwjDg7I+v9MSz3af+SSZj31T9EhI94dFy1B0H t7Q6PPLDX8H9AzOVhbiUxZjP0RhOwivxF5eI8V5gQbMFxn/f5+AuHW/XkOzDsseK m/uFANvP+eMifNk5E66MHJlMV3qlfuvjqbwYlsb2/2DzQW7dIdw9BbNU51ZNVfh6 6trh2oIRFr1S8cGNfWjq+tGSIhgmNrqfOuqZ+EHZWXZtEC7BCcp27Gg7htl53T2d xNWiqlc9ZEdcOLUIrjQLTjvG+x8IwV0HndllN08JXfu4eTDpZOKCtffeWwRoJscQ 5rXOE6X/EUdaZWjX6TCw3S7Ns9rkHKpItiJiKU/rH9PnM0HsYNI5KUYMcKG//v50 cvhS/BJyuoqJug8Ky0B9IAKRT7IF7SEL+0225rtCoLtONGsMizs= =POn7 -----END PGP SIGNATURE----- --Apple-Mail=_2FA801D2-C245-44F4-ABCF-C6BA93DD54F1-- From nobody Wed Nov 29 10:32: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 B9C15128B38 for ; Wed, 29 Nov 2017 10:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 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, 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 WdWjh8wHQEGb for ; Wed, 29 Nov 2017 10:32:02 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 5CF24127444 for ; Wed, 29 Nov 2017 10:32:02 -0800 (PST) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eK79K-0005iW-OW for quic@ietf.org; Wed, 29 Nov 2017 19:31:59 +0100 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eK79H-0005xS-KC for quic@ietf.org; Wed, 29 Nov 2017 13:31:56 -0500 Received: (qmail 4268 invoked from network); 29 Nov 2017 18:31:52 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.196]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Nov 2017 18:31:52 -0000 To: "Brian Trammell (IETF)" , QUIC WG References: <151196843291.8033.13384651890461321693.idtracker@ietfa.amsl.com> From: Christian Huitema Message-ID: <6f30471e-3d36-7103-deb5-7637a0541372@huitema.net> Date: Wed, 29 Nov 2017 10:31:37 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="9EvGvK1rS3122L8i70jAF6VajjRELdoOU" Subject: Re: Fwd: New Version Notification for draft-trammell-quic-spin-00.txt X-Originating-IP: 168.144.250.230 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.28) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5pkYKxbXKW2RmCylvIPwFvkXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fuR6pq1X0DKEbf1/5oEgzKOB98yDTitFWvbHwz9vKZpm/D1 Ad4OAlzgsEH8ABk9OXtfZdf1siwYNJirk4ABKayRZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xq4ax6KvrI/nhOyr4XmBA0QaRU5G7TB9RBnrQ7zv+k CkyJNpqIhNU1IsOdR4ugTG32wlJxC4huUWi14o8HfZKKx6JvzKixj8PC+OqalCFkmpH+vpUDIZeJ XjrpEEsmd+8wbu9lcViFVxDhGp2PwufGcyNBJprCgmabT8JgPqpM5kvKSvC0LDy5UGAFpFuWjThz qHM6TLNqkuowudf/UtCmJO01FCZCXT0M58dFYZkV81z1pRXWhjh9fdbl44I0Df0tN9eq0V0hlrWD EiOHLhiBfcoxmrjechJW+9VrFT0uBx3h1vgDbEdmhrg3iVBpdRY15+ZZmMZUyV9HJAkRDrR5GpIO PepTCxFMvIavjx/iA3YOJbgNLT0Ix6mdJEErnNhWBb39uS1TjWG2Inx+Ts2QvrhVVD6SNHfaCiIW OOQAkvVDEoFOK6EAWKQ3WFIxRUtYANHDTJAVnZcGvok0a1Vj X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 18:32:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --9EvGvK1rS3122L8i70jAF6VajjRELdoOU Content-Type: multipart/mixed; boundary="tsO5uWuKOeI1nRfEv6gg7hlCdnXOUCgM4"; protected-headers="v1" From: Christian Huitema To: "Brian Trammell (IETF)" , QUIC WG Message-ID: <6f30471e-3d36-7103-deb5-7637a0541372@huitema.net> Subject: Re: Fwd: New Version Notification for draft-trammell-quic-spin-00.txt References: <151196843291.8033.13384651890461321693.idtracker@ietfa.amsl.com> In-Reply-To: --tsO5uWuKOeI1nRfEv6gg7hlCdnXOUCgM4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Content-Language: en-US On 11/29/2017 7:18 AM, Brian Trammell (IETF) wrote: > Greetings, all, > > We've submitted an initial -00 version of a draft detailing the spin > bit, as requested by the chairs under the new process to be applied to > changes to the information content of the wire image. > > This describes the mechanism and its intended usage, our experiments > to date with it, and the privacy analysis undertaken by the RTT DT. We > have a few open issues, mainly on the completion of section 4, adding > additional use cases beyond basic interdomain troubleshooting. I am reading your draft, and I notice that you propose reserving the 2nd most significant bit of the UDP payload as the spin bit. This is fine if you are considering only QUIC, and indeed it matches my original PR. But I wonder whether there is something more general hiding there. All the arguments for adding reserved bits to QUIC apply equally well to other UDP based protocols that encrypt their payload, such as for example DTLS based transports, or encrypted RTP video. Wouldn't it be nice if the operators could use the spin bit, or maybe some other management bits, without first having to identify the specific transport protocol used inside UDP? My first reaction was that, if we want generalization, maybe we should reserve the N most significant bits of the UDP payload, instead of arbitrary bit positions. It breaks compatibility with previous versions, but the change in position of the version field already does that in draft 08, so maybe we should do it right now. Maybe. But then, I was thinking of our discussions about multiplexing QUIC, STUN, and maybe also DTLS and RTP on a single port. Twiddling bits in the first payload byte has a cost. If we want a general solution, maybe we should move these bits to a generally visible space, i.e. either the UDP header or the IP header. Of course, there is no space left in the UDP header, so it would have to be the IP header. The ECN bits are already there, so the spin bit could fit there too. In IPv6, we could even use that in conjunction with the flow identifier. What do you think?= -- Christian Huitema --tsO5uWuKOeI1nRfEv6gg7hlCdnXOUCgM4-- --9EvGvK1rS3122L8i70jAF6VajjRELdoOU Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJaHv0VAAoJELba05IUOHVQj8kIAIP3FUBF7tn9ak+dtaIzbnFO 0vvoNSfTVwUeb6cHxo2WJHX8yJnS2B59l2HkPvvBFg7UPnxvI/563c/ajuDGueRS vyYdCigWiCono30hKnQrvRsSolYp6gZUMviyShu7hpKGiAVSgNq1lxbS1e8/+lPS CMcPYlI9FHt9Pnd787RUa1BZLy1BNd/Payxo48rCnP/K89q5MsdRzDniex4NFSWM wb4dsKNPt4JDG9g6danNKQ6gmQu58fJlNh4CXoX3EtHarRdJAQGWQOdEDlEAaGiD C0/fk6McJfwiXLz6cxqkwnpx5NusaB6UnWTXOs1bu0hFxr4gq7teX62aiCkQe8k= =U8Sh -----END PGP SIGNATURE----- --9EvGvK1rS3122L8i70jAF6VajjRELdoOU-- From nobody Wed Nov 29 12:21: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 44B3E128CDC for ; Wed, 29 Nov 2017 12:21:38 -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 Vg3uvLX1A3xb for ; Wed, 29 Nov 2017 12:21:36 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id D95DE1289B5 for ; Wed, 29 Nov 2017 12:21:32 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A0B24340E90; Wed, 29 Nov 2017 21:21:30 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.9026); Wed, 29 Nov 2017 21:21:30 +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; Wed, 29 Nov 2017 21:21:30 +0100 (CET) Received: from [118.243.83.76] (account ietf@trammell.ch HELO [192.168.43.105]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 37690535; Wed, 29 Nov 2017 21:21:29 +0100 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_B767F600-9A52-46AD-9497-11DA3334089B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-trammell-quic-spin-00.txt Date: Thu, 30 Nov 2017 05:21:25 +0900 In-Reply-To: <6f30471e-3d36-7103-deb5-7637a0541372@huitema.net> Cc: QUIC WG To: Christian Huitema , Colin Perkins References: <151196843291.8033.13384651890461321693.idtracker@ietfa.amsl.com> <6f30471e-3d36-7103-deb5-7637a0541372@huitema.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 20:21:38 -0000 --Apple-Mail=_B767F600-9A52-46AD-9497-11DA3334089B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Christian, Colin, We probably should have said (and will say) this in the draft directly, = but we wrote section 2 to match the state of the editor's copy pre-956. = Where, exactly, the spin bit appears in the short header is > On 30 Nov 2017, at 03:31, Christian Huitema = wrote: >=20 > On 11/29/2017 7:18 AM, Brian Trammell (IETF) wrote: >=20 >> Greetings, all, >>=20 >> We've submitted an initial -00 version of a draft detailing the spin >> bit, as requested by the chairs under the new process to be applied = to >> changes to the information content of the wire image. >>=20 >> This describes the mechanism and its intended usage, our experiments >> to date with it, and the privacy analysis undertaken by the RTT DT. = We >> have a few open issues, mainly on the completion of section 4, adding >> additional use cases beyond basic interdomain troubleshooting. >=20 > I am reading your draft, and I notice that you propose reserving the = 2nd > most significant bit of the UDP payload as the spin bit. This is fine = if > you are considering only QUIC, and indeed it matches my original PR. = But > I wonder whether there is something more general hiding there. All the > arguments for adding reserved bits to QUIC apply equally well to other > UDP based protocols that encrypt their payload, such as for example = DTLS > based transports, or encrypted RTP video. Wouldn't it be nice if the > operators could use the spin bit, or maybe some other management bits, > without first having to identify the specific transport protocol used > inside UDP? >=20 > My first reaction was that, if we want generalization, maybe we should > reserve the N most significant bits of the UDP payload, instead of > arbitrary bit positions. It breaks compatibility with previous = versions, > but the change in position of the version field already does that in > draft 08, so maybe we should do it right now. Maybe. >=20 > But then, I was thinking of our discussions about multiplexing QUIC, > STUN, and maybe also DTLS and RTP on a single port. Twiddling bits in > the first payload byte has a cost. If we want a general solution, = maybe > we should move these bits to a generally visible space, i.e. either = the > UDP header or the IP header. Of course, there is no space left in the > UDP header, so it would have to be the IP header. The ECN bits are > already there, so the spin bit could fit there too. In IPv6, we could > even use that in conjunction with the flow identifier. What do you = think? >=20 > -- Christian Huitema >=20 --Apple-Mail=_B767F600-9A52-46AD-9497-11DA3334089B 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlofFsUACgkQihK3vwvq RqNCIRAAlTB4higNaOCtlhKnQflO4AQk9zrnEmOT/MRGRi1tkiFeeTxps6ajDWwj zSxLpQJOBALdesNqp2ITDp8znpuI/44Fkzn3SV1kO52RIJXmKP1b6eXcW6lW3LNz teyfYPLAgOTnX97aJ32A6mT+XnqjpAr5zyDM/wTdqGnA9ZywTThAeUuEafO2zn8/ JsRNkCofTBslomxVtFgsCBWhybAanW5JDQa64IhQFVV8C0r+Q2eXmzc4YNqOFQBH Z71lE+yLLnfESLeRRuYqxryp0eaYlJgEYD1ty9CjyoF1iAewM11Ru6o9omeDke3U WGqEdmVjgTPj9FYE3o8ncw7TAH5zLso4cJYjYtkWeN3r2WOou98iaebshfZcZLku UCqNxgk8S39qPGly7AZjEHo9jmmN9mRaPb+Mb7yCyKhWtU8Usu6Y7IUNxPe2h78B D/YK1vW5cv4Qu4S8p2/NBvCJ7or59kxwJxRnE8TR3z+xFUheMFkLx+PqhthHxcg8 JVC0DMyVRu7vDovT2McVoXzhVQ4oaXUK42FOoFXmUq6R+Eo84FqgdHhwtaftxCx9 G1K37cFp8LMfe9u3RSsAXYSWS3H0m0KGjEduLwKbLwhPp82ZXJcDyVo1dQBGGViI sNJJu9IdX5msL7MZFT9YNtlx+SPqOzVgnNL/t6XAf9YrkZJeXsI= =v7Fo -----END PGP SIGNATURE----- --Apple-Mail=_B767F600-9A52-46AD-9497-11DA3334089B-- From nobody Wed Nov 29 12:31: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 6CAC5126C83 for ; Wed, 29 Nov 2017 12:31:54 -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 bUYbqLEZgBlJ for ; Wed, 29 Nov 2017 12:31:52 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id EC7D61200CF for ; Wed, 29 Nov 2017 12:31:51 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id CFAC33404F3; Wed, 29 Nov 2017 21:31:49 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.15651); Wed, 29 Nov 2017 21:31:49 +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; Wed, 29 Nov 2017 21:31:49 +0100 (CET) Received: from [118.243.83.76] (account ietf@trammell.ch HELO [192.168.43.105]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 37691262; Wed, 29 Nov 2017 21:31:49 +0100 From: "Brian Trammell (IETF)" Message-Id: <0B5B52AD-ADFF-4E7B-ACCD-424FDD70BC3B@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_00430E01-7EC0-4F97-8B50-4A3565F45808"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-trammell-quic-spin-00.txt Date: Thu, 30 Nov 2017 05:31:45 +0900 In-Reply-To: Cc: QUIC WG To: Christian Huitema , Colin Perkins References: <151196843291.8033.13384651890461321693.idtracker@ietfa.amsl.com> <6f30471e-3d36-7103-deb5-7637a0541372@huitema.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 29 Nov 2017 20:31:54 -0000 --Apple-Mail=_00430E01-7EC0-4F97-8B50-4A3565F45808 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 30 Nov 2017, at 05:21, Brian Trammell (IETF) = wrote: >=20 > hi Christian, Colin, >=20 > We probably should have said this in the draft directly (and will say = so in -01), but we wrote section 2 to match the state of the editor's = copy pre-956. Where, exactly, the spin bit appears in the short header = is ... ... less important than the fact it shows up in the short header only. = Given that the short header structure probably hasn't finished changing = (e.g., will we varint the packet numbers?), we'll keep the draft up to = date, but we don't expect to have a definitive bit position until either = (1) we add the spin bit to -transport or (2) we reserve one (or two) = measurement bits in -transport. ( Good morning, everyone. The close button and the send button aren't = *that* close to each other... :| ) Cheers, Brian >> On 30 Nov 2017, at 03:31, Christian Huitema = wrote: >>=20 >> On 11/29/2017 7:18 AM, Brian Trammell (IETF) wrote: >>=20 >>> Greetings, all, >>>=20 >>> We've submitted an initial -00 version of a draft detailing the spin >>> bit, as requested by the chairs under the new process to be applied = to >>> changes to the information content of the wire image. >>>=20 >>> This describes the mechanism and its intended usage, our experiments >>> to date with it, and the privacy analysis undertaken by the RTT DT. = We >>> have a few open issues, mainly on the completion of section 4, = adding >>> additional use cases beyond basic interdomain troubleshooting. >>=20 >> I am reading your draft, and I notice that you propose reserving the = 2nd >> most significant bit of the UDP payload as the spin bit. This is fine = if >> you are considering only QUIC, and indeed it matches my original PR. = But >> I wonder whether there is something more general hiding there. All = the >> arguments for adding reserved bits to QUIC apply equally well to = other >> UDP based protocols that encrypt their payload, such as for example = DTLS >> based transports, or encrypted RTP video. Wouldn't it be nice if the >> operators could use the spin bit, or maybe some other management = bits, >> without first having to identify the specific transport protocol used >> inside UDP? >>=20 >> My first reaction was that, if we want generalization, maybe we = should >> reserve the N most significant bits of the UDP payload, instead of >> arbitrary bit positions. It breaks compatibility with previous = versions, >> but the change in position of the version field already does that in >> draft 08, so maybe we should do it right now. Maybe. >>=20 >> But then, I was thinking of our discussions about multiplexing QUIC, >> STUN, and maybe also DTLS and RTP on a single port. Twiddling bits in >> the first payload byte has a cost. If we want a general solution, = maybe >> we should move these bits to a generally visible space, i.e. either = the >> UDP header or the IP header. Of course, there is no space left in the >> UDP header, so it would have to be the IP header. The ECN bits are >> already there, so the spin bit could fit there too. In IPv6, we could >> even use that in conjunction with the flow identifier. What do you = think? >>=20 >> -- Christian Huitema >>=20 >=20 --Apple-Mail=_00430E01-7EC0-4F97-8B50-4A3565F45808 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlofGTEACgkQihK3vwvq RqMBhw/5AZVovk85qggI2vFgYwR5+Jsag/dqdYJPKlE8TuZ20gJkxSULtVkusYpu 9C+5rdHe4M6ZN7LmB/s5mQm7w7GfRJJJgEvzyGFFzwfoNvaH/O5Prb2LuWIxtxqm 2p+Qj/vrMkj0N4qiDVTOorotLKfKSJ5sk3nrL+xAaL9M2MdHtAYzpOAxZkqQyjtI mlH8Il4vev4aZWbcq7reIvHi/2Lpk76rssxjozN8Hzpz290gbFHlji3d6+OOEG75 FhVrHbIASvKHIDM+iJilSC8YNxR2T40nGX0U7TLw+8Pv5zqJjo1BsZ0u34am2vvd vNe00hUhQtt0RncNurvjHWOoHIo3dTMyiwjQu7FiRf8SKzoR3SFJ+03JbVX15xXP Grv/S5EFjDRWBi3FAXPahlzh9fhwzqTwAq4iGOl8RZ83UsYiIBfWoi0aV7ybfjoy UUR+KPV2T1bijjOL2whojs5vUPkGh3J0BLxd/WV+8jH0O3F+aj3462SR8gvO3IuB ZepU0jYjgEEPyxyKOZfSPwzH63ICPQDDbY7F76hxyroryqQdgxQX2y9mR79W4JMe EZMkCxU9BO6hu/X7Ku26hxS4uUUUWg/Qfcforu5jcE26c6Fl6otpKWVseCTkGbYJ w4zmZrTd/a01VOXZ8M3BX8OTSgZ766SbMa8DW+5JN5lejhDMGI4= =vr3U -----END PGP SIGNATURE----- --Apple-Mail=_00430E01-7EC0-4F97-8B50-4A3565F45808-- From nobody Wed Nov 29 17:59: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 43867128990 for ; Wed, 29 Nov 2017 17:59:40 -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 n8dEtb9Ddywz for ; Wed, 29 Nov 2017 17:59:38 -0800 (PST) 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 ietfa.amsl.com (Postfix) with ESMTPS id ABFF8127136 for ; Wed, 29 Nov 2017 17:59:37 -0800 (PST) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 3DC69340EAB; Thu, 30 Nov 2017 02:59:36 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.29432); Thu, 30 Nov 2017 02:59:36 +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, 30 Nov 2017 02:59:35 +0100 (CET) Received: from [114.175.86.34] (account ietf@trammell.ch HELO [192.168.1.183]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 37704756; Thu, 30 Nov 2017 02:59:35 +0100 From: "Brian Trammell (IETF)" Message-Id: <09654919-D9CB-4F5D-8EF4-BBBCFE3F2E18@trammell.ch> Content-Type: multipart/signed; boundary="Apple-Mail=_2905756E-D8E9-4007-BD8E-F9120A2D20E3"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-trammell-quic-spin-00.txt Date: Thu, 30 Nov 2017 10:59:31 +0900 In-Reply-To: <6f30471e-3d36-7103-deb5-7637a0541372@huitema.net> Cc: QUIC WG To: Christian Huitema References: <151196843291.8033.13384651890461321693.idtracker@ietfa.amsl.com> <6f30471e-3d36-7103-deb5-7637a0541372@huitema.net> X-Mailer: Apple Mail (2.3273) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 30 Nov 2017 01:59:40 -0000 --Apple-Mail=_2905756E-D8E9-4007-BD8E-F9120A2D20E3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii hi Christian, sorry, I didn't respond to your second proposal here... > On 30 Nov 2017, at 03:31, Christian Huitema = wrote: >=20 > On 11/29/2017 7:18 AM, Brian Trammell (IETF) wrote: >=20 >> Greetings, all, >>=20 >> We've submitted an initial -00 version of a draft detailing the spin >> bit, as requested by the chairs under the new process to be applied = to >> changes to the information content of the wire image. >>=20 >> This describes the mechanism and its intended usage, our experiments >> to date with it, and the privacy analysis undertaken by the RTT DT. = We >> have a few open issues, mainly on the completion of section 4, adding >> additional use cases beyond basic interdomain troubleshooting. >=20 > I am reading your draft, and I notice that you propose reserving the = 2nd > most significant bit of the UDP payload as the spin bit. This is fine = if > you are considering only QUIC, and indeed it matches my original PR. = But > I wonder whether there is something more general hiding there. All the > arguments for adding reserved bits to QUIC apply equally well to other > UDP based protocols that encrypt their payload, such as for example = DTLS > based transports, or encrypted RTP video. Wouldn't it be nice if the > operators could use the spin bit, or maybe some other management bits, > without first having to identify the specific transport protocol used > inside UDP? >=20 > My first reaction was that, if we want generalization, maybe we should > reserve the N most significant bits of the UDP payload, instead of > arbitrary bit positions. It breaks compatibility with previous = versions, > but the change in position of the version field already does that in > draft 08, so maybe we should do it right now. Maybe. >=20 > But then, I was thinking of our discussions about multiplexing QUIC, > STUN, and maybe also DTLS and RTP on a single port. Twiddling bits in > the first payload byte has a cost. If we want a general solution, = maybe > we should move these bits to a generally visible space, i.e. either = the > UDP header or the IP header. Of course, there is no space left in the > UDP header, so it would have to be the IP header. The ECN bits are > already there, so the spin bit could fit there too. In IPv6, we could > even use that in conjunction with the flow identifier. What do you = think? Intriguing, but I'm pessimistic about it working. The ECN bits in IP are already quite a bit overloaded. First, there's = still a some configured hardware out there that treats the whole old ToS = byte as the ToS byte, and uses it for ECMP entropy, etc. Which means = CE-marked packets go down a different path than non-CE-marked packets, = which is... fun. Second, we're already looking at tearing down the = equivalence between ECT0 and ECT1 with L4S, to mark different congestion = control expectations of a CE mark, and therefore to request alternate = treatment from an AQM. See = https://tools.ietf.org/html/draft-briscoe-tsvwg-ecn-l4s-id-02 section = A.1. Sticking the spin bit in the flow label has the same ECMP problem as = spinning ECT0/ECT1, but worse, since that's an *expected* use of the = flow label, not a deprecated one. Architecturally, I fully agree that something like this belongs in a = network-layer header. Indeed, IPPM just published an IPv6 DO based = measurement signal, RFC 8250. But doing any of this in the IP header = means you need to deploy kernels to make it happen, so the deployment = story looks less like QUIC and more like SCTP; 8250, I suspect, will = only ever see deployment in specific single network / datacenter = scenarios. Thanks, cheers, Brian --Apple-Mail=_2905756E-D8E9-4007-BD8E-F9120A2D20E3 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlofZgMACgkQihK3vwvq RqNz6Q/9FvkPbqgNEi08MNiG3k1z6MtYKmRGFPzPhcAOoy4Exo1G/ITW76WzMFLg MQPMPoEg8UlsubR1zfxPmNOD2GPQ7leqQD42jYhvI2SzIC6RBhNMnjCYWuHtCNd3 4OHfTG07ohNWX0YdDZjAVZiIqinAv9ukoiySb/792tKMmkzLzqh8CxEX56+bmxWT DLkHMtKB8MzbQShSu8SJUnpr9g2VbpJJxMRgYGLoaE+eyAeGzppOhArqWdKUDrqR pQIKBIZT2+yvzTnPjcV0czuJgh83FGBTFvxf7yzbv+2RnSNc54bSSwofMJEfu0rq hBXd29APIcPaXiuEHGkScJ8GB4bqiTXV8la5/SmsNMP1aSfSYbAH3J1m5CtotAra Qa2fQPSyvtfihlaTCEntw1/42zmvZ7j2CtnViSx71FRev86JcXONyRPl4nJxg6j9 Y3aJ2l7NdyMnfH3nlsXRLF200EiRADK97adP6xOBQqwZ82J4SdB5ie0FKCPKVXeh cLh4NPHL8DUfsSxRyldoHSaha1W4/9Pvqeuptgt3mNL1qZvSj8NFpx0tVWs2mJPv 4RvROdyQygErdC2+nm4cfTev4YepQXxE5UOLy6oAwuwiCo/hH7vcqQgpzf3dfwPs oEsiEl9KUndsdLox9GMi4g/ACbeM29ZjjUURiAMYorGYfKAOoRA= =Bck2 -----END PGP SIGNATURE----- --Apple-Mail=_2905756E-D8E9-4007-BD8E-F9120A2D20E3-- From nobody Thu Nov 30 20:09: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 BBDD11270B4 for ; Thu, 30 Nov 2017 20:09: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, 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 vsriwDQIQ-7E for ; Thu, 30 Nov 2017 20:09:39 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65EA21241F5 for ; Thu, 30 Nov 2017 20:09:39 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id 184so6383699oii.2 for ; Thu, 30 Nov 2017 20:09:39 -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=tcCr3A8fqNOinGwrfLNG9yemPXVVpEY3OQC4wqmVvmw=; b=C8z39H2Op04q7KkqtyTTidUkfqyuYJY01NtGL/GW1EPKYOGk/Xj+XyhCn9RRFp53By oFxfpFNxpFtXOIq/HTlBNPfAZUtSZGCNbtX9UU0Vm75pV5GJE99RhvZQrGZNfT3HrF2Z ElHgnvxfhhXvzHD2ipw4HhSnfS7VsAMgvgN1JXWk4pQ6zhQ/CEjTlykIEHWwzuxkcvvq w2qcLiIB3W+yHiUjkNXJQYmA/67tFleIsAjDJgoWbQimbSiUDmTDHwnvfDzh4SxytFv4 n4oVECYJWWMQi3LgWAyki3hNnEaUfMk1vv/j89MoOycrcHLjZ01qEfYqJ9b+juw7trEs qzfg== 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=tcCr3A8fqNOinGwrfLNG9yemPXVVpEY3OQC4wqmVvmw=; b=Kmp92LJlOyRrk3uoTnDVCNOCQUVJnS8IL2gG/qz3SHPJjlYnyqbMzOIFETfIIQ4wXW 5Pzos4zpksaYnRu858j8BcBa8dpUWUUObDMfSZ+q91vnlyo1ss5Fytxbtt8h8A2kMl93 p1uKeZy6RRVldVI+S7uJACW0hEGo/Qwx3Xmkf9s1Ykw/u7cBYP9w3G09HPf1HS/DZm+V jboPSEBY+9KMM6FbBi82r88kQs7i5ejZjQXvQ641graNj4wm38SXiLJFqyu40t7Nqder Pzqyq9NM7YgbJR65RA+LHYxda0e5vt8tBFGa8ybOUdquAdmrNvTd3zt5WsyyTrlyyDIC NAcw== X-Gm-Message-State: AJaThX4S1VZBVVXhtska42Dr+sWGzUJd8Qm3gzQSheckKUc88moyoqil ZNdgqw50V7ieZzY89LoCoAigGi8pzIijZWG13Jiswqsc X-Google-Smtp-Source: AGs4zMaz99gcrK2LJEK7naBLbLTitepBJ3rb5RiW/BEMUEb6I5kIu2xsF0ub78ClsHNxXq1Ydi6nSvVZ681Z1ox5G54= X-Received: by 10.202.48.8 with SMTP id w8mr6067154oiw.284.1512101378515; Thu, 30 Nov 2017 20:09:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.157.8.11 with HTTP; Thu, 30 Nov 2017 20:09:38 -0800 (PST) From: Martin Thomson Date: Fri, 1 Dec 2017 15:09:38 +1100 Message-ID: Subject: Invariants draft To: QUIC WG Content-Type: text/plain; charset="UTF-8" Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 01 Dec 2017 04:09:41 -0000 I've just submitted a personal draft that describes the invariants that I think we agreed to in Singapore. https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants This is just me for the moment (though Jana and Mike were very helpful in reviewing an even draftier draft). It also assumes a few things about the current drafts that aren't yet true, and may not even become true. Don't focus too much on the specific content of what is in or out, because that sort of detail is easy to fix. More than content, I'd like to concentrate on the general approach and scope. My hope is that we can agree that those are more or less correct. And then adopt the draft. A draft like this should help address questions people have been asking about what can and cannot change between QUIC versions. From nobody Thu Nov 30 20:47: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 CFD91126E7A for ; Thu, 30 Nov 2017 20:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 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, 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 XFiqSBoe_isN for ; Thu, 30 Nov 2017 20:47:00 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 AE81B120454 for ; Thu, 30 Nov 2017 20:46:59 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx15.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1eKdDz-0003Wr-Gn for quic@ietf.org; Fri, 01 Dec 2017 05:46:57 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1eKdDx-0003uf-Nc for quic@ietf.org; Thu, 30 Nov 2017 23:46:54 -0500 Received: (qmail 31047 invoked from network); 1 Dec 2017 04:46:51 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.119]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 1 Dec 2017 04:46:51 -0000 To: quic@ietf.org References: From: Christian Huitema Message-ID: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> Date: Thu, 30 Nov 2017 20:46:49 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: Re: Invariants draft X-Originating-IP: 168.144.250.223 X-AntiSpamCloud-Domain: xsmtpout.mail2web.com X-AntiSpamCloud-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.29) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5lK5SKP/z4AU7iS9btRMgZ4Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fvH7XfVd16SC7G3HBEg/bzuB98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYdTPSw+CekCTYoDa8nAx3W5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+PVG1YjIrFRKhESMT/tU1Dx+IHaAZrg1ulFniksjLYqZxdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31XIx4AXarfh1O38bAuuIRigptEjxjSIdK/OrMoYfnrE KKm1fqFk0+1KZZdmFFP6WgPGvVLPSj+Hlyh2mculO/W8NktFVcl6hrIDm43UklXgo0rGkb5OztVl OoF8rUUHwR1JLObs/ksVBOHvEAgSr8kAN1Mi/5oPXF0IaYXV2I96ukONoJfh+XjGSeeT90H/uIH3 cMbdqdZNuRt21KsRa0/uQG+Y0crlrpULu0k1t3AsnGbjO41FyBEqIaDudcVplPEfgkCmu0AbpCDt lYGBUhlW87eqULwgkV+w1Dqc0gmbgvfFcHV2tQAVqGdj/zM7G/FqHXIoSsvffuCdDqwWbJR15ft9 Iz0WDtXlRni5HCCJM9Qvlo9UV7vdWttsewtXKowaEO652uo+6xHVEn43gl09gN9PtOEBx/RKpFEr HkJ0VfjEzm1SsR8v3aJbN/NZfa/pGyl0Yc/hSh4fhbFqiL7w X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 01 Dec 2017 04:47:02 -0000 On 11/30/2017 8:09 PM, Martin Thomson wrote: > I've just submitted a personal draft that describes the invariants > that I think we agreed to in Singapore. > > https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants > > This is just me for the moment (though Jana and Mike were very helpful > in reviewing an even draftier draft). It also assumes a few things > about the current drafts that aren't yet true, and may not even become > true. Don't focus too much on the specific content of what is in or > out, because that sort of detail is easy to fix. Thanks for writing that, Martin. It provides a very clear description of the "invariant" approach, and helps me understand the motivation behind several changes that were proposed recently. > More than content, I'd like to concentrate on the general approach and > scope. My hope is that we can agree that those are more or less > correct. And then adopt the draft. A draft like this should help > address questions people have been asking about what can and cannot > change between QUIC versions. As far as the general approach is concerned, your draft leaves me somewhat uneasy. I understand the concern to beat ossification, and to ensure that future developers can easily define and use extended versions of QUIC. But at the same time, I am concerned with the tension between "focusing on extensibility" and "ensuring interoperability". At one end of the spectrum, we could define nothing but extensibility mechanisms, and let application developers define an application specific transport protocol. At an other end of the spectrum, we could rigidly specify a protocol, its formats, and its state machine. I do think that the working group has to strike somewhere in the middle, a well specified protocol that can be easily extended, but maybe not infinitely extensible. Developers have spent a lot of time testing features, and testing whether these features can be implemented in compatible ways between implementations. This is valuable, and I wish that we progressively converge on a "version 1" of QUIC that benefits from these tests. I think of that as some kind of simulated annealing process. At some point, part of the crystal is deemed pure enough, and we move the annealing ring up to check the next part. That may not be the best analogy, but the high level summary is that interoperability is important, that is requires some stability, and that the better is the enemy of the good. -- Christian Huitema From nobody Thu Nov 30 22:25: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 783BA12894A for ; Thu, 30 Nov 2017 22:25:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Foc4QB78wY2 for ; Thu, 30 Nov 2017 22:25:47 -0800 (PST) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id B46011243F3 for ; Thu, 30 Nov 2017 22:25:45 -0800 (PST) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id vB16PdNW008303; Fri, 1 Dec 2017 07:25:39 +0100 Date: Fri, 1 Dec 2017 07:25:39 +0100 From: Willy Tarreau To: Christian Huitema Cc: quic@ietf.org Subject: Re: Invariants draft Message-ID: <20171201062539.GA8275@1wt.eu> References: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 01 Dec 2017 06:25:48 -0000 On Thu, Nov 30, 2017 at 08:46:49PM -0800, Christian Huitema wrote: > But at the same time, I am concerned with the tension > between "focusing on extensibility" and "ensuring interoperability". At > one end of the spectrum, we could define nothing but extensibility > mechanisms, and let application developers define an application > specific transport protocol. At an other end of the spectrum, we could > rigidly specify a protocol, its formats, and its state machine. I do > think that the working group has to strike somewhere in the middle, a > well specified protocol that can be easily extended, but maybe not > infinitely extensible. I think this draft clearly leaves a *lot* of room for extensibility, and defining invariants helps us (and future generations) decide when a new protocol needs to be specified because it conflicts with the definition of what was guaranteed to be invariant. It's normal to reach an end with a protocol when new concerns need to be addressed that were out of the initial scope. Here in short, as long as we can use UDP with a few fixed bits and 64-bit connection IDs, we don't need to define a new protocol. I personally find it well balanced. Regards, Willy From nobody Thu Nov 30 22:26: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 703BA128990 for ; Thu, 30 Nov 2017 22:26:39 -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 nugnF6tBHfdq for ; Thu, 30 Nov 2017 22:26:37 -0800 (PST) Received: from mail-pl0-x22b.google.com (mail-pl0-x22b.google.com [IPv6:2607:f8b0:400e:c01::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 69B551243F3 for ; Thu, 30 Nov 2017 22:26:37 -0800 (PST) Received: by mail-pl0-x22b.google.com with SMTP id f6so5766106pln.12 for ; Thu, 30 Nov 2017 22:26:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:content-language:mime-version; bh=83rt2C6O/mDZglwM7lFTJIihz1TCcF8ggf9hiGecOrQ=; b=gVtJ4TvjIOOFaytAh93dhSekSSbfKwuHbTCvHMKQcBmNLDZH1IlhUTZiNLZydlC6Y5 uSaqfHARu/pFJI6OGzLiQ0LSz24aohs25e662C32aT2asmh5IY2oYkXr/632BYMLHMMN iSRD/Dw30lrJuZhe+v45dBmRztoG4TgldXaHH/6Tv/H5AJRcMAAhdFONDMm0BRe6fFMH mWNIM8W2qX/xfhciJeD8dLhVxz2HrSO1zFAIGCBAq9eVmhrrJDxjpl4CLaqTcRf7wb+c 9UTZkMFWNXRK7aWb3OSjsJl04mYN97OSPW67kJijeGSOSulg2zzKT1GsyDoWwHOVhjQW XrSQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:thread-topic:thread-index:date :message-id:references:in-reply-to:content-language:mime-version; bh=83rt2C6O/mDZglwM7lFTJIihz1TCcF8ggf9hiGecOrQ=; b=PiA4/u8cC4UhZMwKRLRx7qCMkdYxUw08Pw8uxw48gTM1/AZ+cV5vr5SmkiYQGJwA0G wxl2HlomO20QlEH0WotDQk/TJ0Q2ryqBb5tw1LFgCE7W4FpF2khc9x6JTEgKpF/TU6od 6CjvQGYgaZ0b1PYEdm9mn7u6qOPiOkn+5gY3pe4T/46o5y9QRADmaGB4xEWKpAfJZ+rB swm6Brq3Q0B+Omfm3FVhQhKOgLNkRv+2nJCmPcfHhq/A2ursYnLpB2p00HMGq6MPjhwj RKpAI0HlCZawiXb4ZjA7x2JSYLsaoZx+m2uMlXnOseoSCr9UOG0F0EUhHYtYMeITzpur LyTg== X-Gm-Message-State: AJaThX5oJBbB8d/ceJGOZQ/PKegZ78KaOmxqmyYQs+TxrParMPpQNU8V um8OPN2FfAhDOWmGO/mjIyAYCGjB X-Google-Smtp-Source: AGs4zMbzw5s76IBEQ9VrwixfH+zGufRVIcsIippUBP9m986tihtKueoq5G56lQhVv41WdsA7932oTA== X-Received: by 10.84.128.227 with SMTP id a90mr5260165pla.224.1512109596880; Thu, 30 Nov 2017 22:26:36 -0800 (PST) Received: from DB6PR10MB1766.EURPRD10.PROD.OUTLOOK.COM ([40.101.73.69]) by smtp.gmail.com with ESMTPSA id l73sm11673921pfi.82.2017.11.30.22.26.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 30 Nov 2017 22:26:36 -0800 (PST) From: =?iso-8859-1?Q?Mikkel_Fahn=F8e_J=F8rgensen?= To: Christian Huitema , "quic@ietf.org" Subject: Re: Invariants draft Thread-Topic: Invariants draft Thread-Index: AVEtOGdqrg3L1y5zbGtj4Yq/knkCvWMyN2FjgWDYHnY= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Fri, 1 Dec 2017 06:26:31 +0000 Message-ID: References: , <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> In-Reply-To: <440a603c-2924-a260-c477-ecb42a84ec5c@huitema.net> Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 Content-Type: multipart/alternative; boundary="_000_DB6PR10MB17668967F2AA27987B47F437AC390DB6PR10MB1766EURP_" MIME-Version: 1.0 Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.22 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, 01 Dec 2017 06:26:39 -0000 --_000_DB6PR10MB17668967F2AA27987B47F437AC390DB6PR10MB1766EURP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks for writing up. Some input: Appendix A, incorrect assumptions: - A 5-tuple is unique to a single connection. - A client uses ephemeral ports. More generally: I find it unfortunate that UDP is made an invariant, anf po= ssibly even IP. The routability of packets could also be questioned, e. g. for some embedde= d device busses. ________________________________ From: QUIC on behalf of Christian Huitema Sent: Friday, December 1, 2017 5:46:49 AM To: quic@ietf.org Subject: Re: Invariants draft On 11/30/2017 8:09 PM, Martin Thomson wrote: > I've just submitted a personal draft that describes the invariants > that I think we agreed to in Singapore. > > https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants > > This is just me for the moment (though Jana and Mike were very helpful > in reviewing an even draftier draft). It also assumes a few things > about the current drafts that aren't yet true, and may not even become > true. Don't focus too much on the specific content of what is in or > out, because that sort of detail is easy to fix. Thanks for writing that, Martin. It provides a very clear description of the "invariant" approach, and helps me understand the motivation behind several changes that were proposed recently. > More than content, I'd like to concentrate on the general approach and > scope. My hope is that we can agree that those are more or less > correct. And then adopt the draft. A draft like this should help > address questions people have been asking about what can and cannot > change between QUIC versions. As far as the general approach is concerned, your draft leaves me somewhat uneasy. I understand the concern to beat ossification, and to ensure that future developers can easily define and use extended versions of QUIC. But at the same time, I am concerned with the tension between "focusing on extensibility" and "ensuring interoperability". At one end of the spectrum, we could define nothing but extensibility mechanisms, and let application developers define an application specific transport protocol. At an other end of the spectrum, we could rigidly specify a protocol, its formats, and its state machine. I do think that the working group has to strike somewhere in the middle, a well specified protocol that can be easily extended, but maybe not infinitely extensible. Developers have spent a lot of time testing features, and testing whether these features can be implemented in compatible ways between implementations. This is valuable, and I wish that we progressively converge on a "version 1" of QUIC that benefits from these tests. I think of that as some kind of simulated annealing process. At some point, part of the crystal is deemed pure enough, and we move the annealing ring up to check the next part. That may not be the best analogy, but the high level summary is that interoperability is important, that is requires some stability, and that the better is the enemy of the good. -- Christian Huitema --_000_DB6PR10MB17668967F2AA27987B47F437AC390DB6PR10MB1766EURP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Thanks for writing up.
Some input:
Appendix A, incorrect assumptions:
- A 5-tuple is unique to a single connection.<= /div>
- A client uses ephemeral ports.

More generally: I find it unfortunate that UDP is made an invariant, a= nf possibly even IP.

The routability of packets could also be quest= ioned, e. g. for some embedded device busses.
From: QUIC <quic-bounc= es@ietf.org> on behalf of Christian Huitema <huitema@huitema.net><= br> Sent: Friday, December 1, 2017 5:46:49 AM
To: quic@ietf.org
Subject: Re: Invariants draft
 
On 11/30/2017 8:09 PM, Martin Thomson wrote:

> I've just submitted a personal draft that describes the invariants
> that I think we agreed to in Singapore.
>
> https://datatracker.ietf.org/doc/html/draft-thomson-quic-invarian= ts
>
> This is just me for the moment (though Jana and Mike were very helpful=
> in reviewing an even draftier draft).  It also assumes a few thin= gs
> about the current drafts that aren't yet true, and may not even become=
> true.  Don't focus too much on the specific content of what is in= or
> out, because that sort of detail is easy to fix.
Thanks for writing that, Martin. It provides a very clear description of the "invariant" approach, and helps me understand the motivation = behind
several changes that were proposed recently.

> More than content, I'd like to concentrate on the general approach and=
> scope.  My hope is that we can agree that those are more or less<= br> > correct.  And then adopt the draft.  A draft like this shoul= d help
> address questions people have been asking about what can and cannot > change between QUIC versions.

As far as the general approach is concerned, your draft leaves me
somewhat uneasy. I understand the concern to beat ossification, and to
ensure that future developers can easily define and use extended
versions of QUIC. But at the same time, I am concerned with the tension
between "focusing on extensibility" and "ensuring interopera= bility". At
one end of the spectrum, we could define nothing but extensibility
mechanisms, and let application developers define an application
specific transport protocol. At an other end of the spectrum, we could
rigidly specify a protocol, its formats, and its state machine. I do
think that the working group has to strike somewhere in the middle, a
well specified protocol that can be easily extended, but maybe not
infinitely extensible.

Developers have spent a lot of time testing features, and testing
whether these features can be implemented in compatible ways between
implementations. This is valuable, and I wish that we progressively
converge on a "version 1" of QUIC that benefits from these tests.= I
think of that as some kind of simulated annealing process. At some
point, part of the crystal is deemed pure enough, and we move the
annealing ring up to check the next part. That may not be the best
analogy, but the high level summary is that interoperability is
important, that is requires some stability, and that the better is the
enemy of the good.

-- Christian Huitema



 --_000_DB6PR10MB17668967F2AA27987B47F437AC390DB6PR10MB1766EURP_--