From nobody Sun Oct 1 13:31: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 1A444134B04 for ; Sun, 1 Oct 2017 13:31:58 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vK_QcW2iPr5Z for ; Sun, 1 Oct 2017 13:31:54 -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 582D31332E3 for ; Sun, 1 Oct 2017 13:31:54 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id r85so2580903ywg.1 for ; Sun, 01 Oct 2017 13:31:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=o9jErC3kk37LJ+N8RGfkNjcJP2BzSpe9BfDCBNkpMHY=; b=VvujiZmMEONjX8l3IoUcZpQHLtSX6h9T1cNWgCbOmWh1689AlxlmxRNObSON8QKvbO CzifP6WQakXjF7VCrNDfHwVrvhLQVnIn2F19Fd9Ggk8rJp19zOMD0QRsFR6G4ctuDOxm auoJIQEWhDNnluQVRG0IeMLH8xeVwD1aWtHxb9DfZKfNXaghDXc8+rrBitdlvO1ErWNe OlKrSI68sOB3lXnrujAw76Vo3e2nR6xQdz0aE97z/MyYGJxkIzSgZP80xu7K3Cedu8Nw zvkddfyGgtdOILp8az7ScGGrQyOf8BmMIVDs7X0mOqQW/FSayexk0wUa79MhlSlDEbDS /pww== 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=o9jErC3kk37LJ+N8RGfkNjcJP2BzSpe9BfDCBNkpMHY=; b=XHkYeIBjLy2Rf9RiruRYbrQguPprCsn1MLHAMw0w56e/PKxUnQzczUbS+xTUp/21p7 Jx2EemYb9X4ttnuO8tTjGHnbD6ujatF6w72g83S02Cg+6umS8DdrdD1Lp205YCMmFGaT hIQrP19OJE0YVv4r4pDCfJijubicnTgVO38CuxMw5zezm7H5kczovMwRvN5pgXbPm9WE Y5y8wihc5t5d1+jQmH9gbIdC8QAnrkQeQtfi+bsKYOI/sffqGZlINfkCHOpikEcpJ9wG oqb+1+t6f7eezT5X3+orKLl36lSlU22td2qidjMQ40PGPUgwG5TtAReQOeCBQqQGNBaE uZEQ== X-Gm-Message-State: AHPjjUgcFQOmTmhJJqAqPCFdyIWDi/xSWsJaTMuIt9xbPDZ+bACBKQG7 jsDpoGHkKkaKnoscquymRjN0osHLp3xYy1mfq8MfBAeHITU= X-Google-Smtp-Source: AOwi7QCG8qmq4MhzjMCcbH1nPgN4Fym8FadmHTgU9Dup7DStsGSH0mXpEovdiC+v6r7fBKcRlOY5BYZvQPoALFHoa34= X-Received: by 10.129.108.201 with SMTP id h192mr11124018ywc.161.1506889912903; Sun, 01 Oct 2017 13:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sun, 1 Oct 2017 13:31:12 -0700 (PDT) From: Eric Rescorla Date: Sun, 1 Oct 2017 13:31:12 -0700 Message-ID: Subject: Report on Unidirectional Streams in Minq To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114dad96f9aad7055a822597" 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, 01 Oct 2017 20:31:58 -0000 --001a114dad96f9aad7055a822597 Content-Type: text/plain; charset="UTF-8" Hi folks, As promised I spent a bunch of time hacking unidirectional streams into Minq and I'm here to report back [0]. Specifically, I implemented: - PR#643 -- Unidirectional Streams - PR#720 -- Add bidirectional streams on top of unidirectional - A bidirectional stream API that mostly mimics Minq's original API for -05. The following is kind of a wall of text, so you could also skip this and refer to my slides [1]. MINQ'S -05 ARCHITECTURE API Minq's master object is the Connection, which has a list of Streams indexed by stream ID. Applications register a handler with the connection to be notified of new events. type ConnectionHandler interface { // The connection has changed state to state |s| StateChanged(s State) // A new stream has been created (by receiving a frame // from the other side. |s| contains the stream. NewStream(s *Stream) // Stream |s| is now readable. StreamReadable(s *Stream) } Streams get created in two ways: - Locally via Connection.CreateStream() - Remotely, in which case the application is notified via a callback to ConnectionHandler.NewStream(). Streams themselves have the APIs you would expect, namely, Read(), Write(), Close(), Reset(), etc. You get notified of stream readability by a callback to ConnectionHandler.StreamReadable(), at which point you can do Stream.Read(). As expected, Stream.Read() returns WOULDBLOCK when no data ia available INTERNALS As noted above, we start with the Connection object (only relevant fields shown): type Connection struct { handler ConnectionHandler streams []*Stream maxStream uint32 outputClearQ []frame // For stream 0 outputProtectedQ []frame // For stream >= 0 } As you can see, streams are in an array slice, so they're contiguously indexed by stream ID. Right now, I have no provision for reclaiming the unused bottom part of the array, but it would be straightforward to index by |streamId| - |minStream|, which I think is consistent with the design implied by the requirement to create streams in sequence. Because Streams are bidirectional, each stream actually consists of a pair of half streams. type streamHalf struct { s *stream // pointer to parent log loggingFunction dir direction // Sending or receiving closed bool // Is the half-stream closed offset uint64 // The chunks []streamChunk maxStreamData uint64 } // Internal object to allow unit testing. type stream struct { id uint32 log loggingFunction state streamState send, recv *streamHalf blocked bool // Have we returned blocked } // Public API object, which needs access to the Connection type Stream struct { c *Connection stream } Outgoing data is enqueued into |stream.chunks|, and then periodically the connection polls the stream for all the chunks which are permitted by stream-level flow control and enqueues them into |Connection.outputClearQ| or |Connection.outputProtectedQ|. At this point, the connection owns the data and is responsible for transmitting it, subject to connection-level flow control, and (presumably) congestion control once I have that implemented [2]. Incoming data gets queued (sorted) into |stream.chunks| for later reassembly at the time when someone calls stream.read(). I'm not sure I love this, because it means I don't have a good view of the incoming queue size (which I'd need to account for separately), but it allowed me to share data structures between incoming and outgoing, which seemed kind of natural when I did it (this architecture is replicated in the unidirectional streams design, but it's probably less natural there). UNIDIRECTIONAL STREAMS ARCHITECTURE UNIDIRECTIONAL API With the unidirectional branch, Minq offers two APIs. The first is a straightforward mapping of PR#720, in which we have two objects: SendStream -- used for writing RecvStream -- used for reading As before, we have a handler object, but it's directional now: type ConnectionHandler interface { // The connection has changed state to state |s| StateChanged(s State) // A new receiving stream has been created (by receiving a frame // from the other side. |s| contains the stream. NewRecvStream(s *RecvStream) // Stream |s| is now readable. StreamReadable(s *RecvStream) } Obviously SendStreams are locally created and RecvStreams are remotely created. SendStreams can be created using Connection.CreateSendStream() and you learn about remotely created RecvStreams by a callback to ConnectionHandler.NewRecvStream(). Second-created streams can be marked as "related" to a single first-created stream, using Connection.CreateRelatedSendStream() with the appropriate RecvStream as the argument [3]. Streams have a Related() API to tell you if they are related to some other stream. The {Send,Recv}Stream APIs are about what you'd expect. You can Write() on SendStream and Read() on RecvStream(). Right now, you can Close() and Reset() SendStreams, but not do anything on RecvStreams() or than ignore them. Eventually I'll probably offer RecvStream().Mute() or something to let you send STOP_SENDING. BIDIRECTIONAL API Minq also includes a bidirectional API that's layered on top of unidirectional streams. I've created a Connection2 structure that's intended as a wrapper around Connection [4]: type Connection2 struct { Connection shim *connection2ShimHandler streams []*Stream // Odd for client originated, even for server. } type Stream struct { id uint32 send *SendStream recv *RecvStream } Basically, Stream is just a pair of SendStream and RecvStream and Connection2 does the bookkeeping to keep them connected (I even do the odd/even ID thing that QUIC-05 has). Connection2 has the same handler API as Minq for QUIC-05, and the shim is responsible for translating unidirectional events into bidirectional events. Internally, what's going on here is that when you call CreateStream() Minq creates a Stream with a nil RecvStream. When a new remote stream is detected, we check RecvStream.Related(). If they are related to an existing SendStream then we will in the relevant |Stream.send| slot. Otherwise, we create a new SendStream that's related to the incoming stream and notify the application of the creation of the new bidirectional stream. Note that this all works fine if one side does the undirectional API and one does the bidirectional API. My test programs actually exercise this. Of course, there's an assumption that the peer conforms to a 1:1 mapping. If we define unidirectional streams, we'll need some protocol mechanism to know if the other side is exercising this level of increased flexibility or not. I can imagine a number of options here (e.g., ALPN). We could also forbid 1:N mappings but I think that would be a mistake as it's a cool feature/benefit of doing unidirectional. The entire bidirectional wrapper shim is < 150 lines of Go code. (https://github.com/ekr/minq/blob/unidirectional_streams/bidi.go). Converting my test application to this API was a matter of just changing class names, e.g., s/Connectionb/Connection2/. In my implementation, I assume that at the time Minq hears about a stream, you know if its related to a given existing stream. That way you can immediately either associate it with that stream or make a new local stream. In my implementation, I always send Related Stream Id and assume that you never get an "unrelated" stream frame before a "related" one. The spec doesn't really require that right now, and offline MT suggested just sending related with offset=0 but I think that's a mistake, because it means that you need to hold stream frames in some provisional "undetermined" state until you get that frame. I would suggest instead that we require that you include the field until one of the frames is ACKed. INTERNALS Sending and receiving streams still share a lot of common components: type baseStream struct { state streamState id uint32 log loggingFunction offset uint64 chunks []streamChunk maxStreamData uint64 isRelated bool related uint32 } type sendStream struct { baseStream blocked bool } type recvStream struct { baseStream } Most of this is the same as with bidirectional streams. As above, it's probably possible to make them more asymmetrical. The connection maintains separate lists of sending and receiving streams and it's straightforward to create and access them without worrying about the odd/even stuff. COMPARISON At the end of the day, I think this shows that these designs aren't really that disssimilar. I was able to convert Minq to unidirectional streams in about 16 total hours of work (basically a long plane flight plus the next morning). While I had to make a bunch of changes to the internal structures, basically none of them modified anything tricky, and in particular the flow control mechanics and the like are basically unchanged, except for a bunch of mechanical-type transformations like referring to |sendStream.chunks| instead of |stream.send.chunks|. The only really new protocol machinery is the new frame format for related streams. There are a few pros/cons that are worth noting about these designs. - Without a bidirectional API, having unidirectional streams is more work for the programmer. However, with an API shim, the difference is trivial. - Because undirectional streams are inherently more flexible, it's possible for the sides to try to use different mappings, e.g., one side expects paired and the other expects 1:N. We'll need some way of making sure that doesn't happen, maybe ALPN? - The "Related Stream ID" frame indicator needs fleshing out a bit. From the application's perspective, it should never hear about a stream without knowing its related status. And as noted above, I think it would be best if we required that all "first flight" stream frames that are related include the fied - Undirectional streams kind of sharpen the confusion about exactly what kinds of "closure" we want to allow. Specifically, what should implementations be able to say about their willingness to receive? Right now we have STOP_SENDING, but that doesn't influence the sender's state. I don't think undirectional streams make this worse, they just require us to think it through some more. They do simplify the implementation of the closure state machine: in my QUIC-05 code, whenever one side closes I have to have checks to see if I should be transitioning to CLOSED or HALF-CLOSED, etc, which is odd because the directions are basically independent. It would probably be easier even in QUIC-05 not to reify these states but just to determine the state from the composition of the individual sub-states - Unidirectional streams don't need the kind of annoying odd-even mechanics, which was easier to code up (just having to create all the lower-numbered streams of the same parity is kind of a pain). One additional benefit here is that with QUIC-05 there are several messages which involve implicit stream creation (e.g., STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether the stream is one that should have been created locally or remotely. This just doesn't happen with bidirectional streams; I do implement odd/even mechanics but because the other side has to have its stream ids increment by one, I can make sure that they have the right IDs by construction and just check to see if the stream exists in these cases. I'd like to see us get rid of odd/even no matter what. - Unidirectional streams also helps avoid some of the corner cases around bidirectional streams. Specifically, suppose I am the client and I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed to just start sending or not? You can sort of get into this situation with unidirectional streams, but because it's explicit, one might hope that the application semantics would require clear specification. - As noted above, bidirectional streams are more flexible because they let you have mappings that you can't have with unidirectional streams (unpaired, 1:N). Happy to answer more questions if people have them. Otherwise we can talk about this in Seattle. -Ekr [0] https://github.com/ekr/minq/tree/unidirectional_streams [1] https://github.com/ekr/wg-materials/blob/404898fa2d2f0a9f9bd244d2c945e66ea88502a2/interim-17-10/Unidirectional%20Streams%20in%20Minq.pdf [2] Thanks to Patrick McManus for suggesting this design. [3] In C++, you would have a single function with a default argument of |nullptr| but Go doesn't support that, hence two different arguments. [4] For implementation reasons, it's actually using Connection as a mixin, which means it's simultaneously possible to use the unidirectional and bidirectional APIs, but that's going to cause a lot of confusion. A real implementation would probably have to either commit to one or the other or do a real wrapper, so you could only use one set of APIs, at the cost of having to do more forwarded methods. --001a114dad96f9aad7055a822597 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

As promised I spen= t a bunch of time hacking unidirectional streams
into Minq and I&= #39;m here to report back [0]. Specifically, I
implemented:
=

=C2=A0 - PR#643 -- Unidirectional Streams
=C2= =A0 - PR#720 -- Add bidirectional streams on top of unidirectional
=C2=A0 - A bidirectional stream API that mostly mimics Minq's origina= l API
=C2=A0 =C2=A0 for -05.
=C2=A0 =C2=A0=C2=A0
<= div>The following is kind of a wall of text, so you could also skip this
and refer to my slides [1].


MINQ'S -05 ARCHITECTURE
API
Minq's master obje= ct is the Connection, which has a list of Streams
indexed by stre= am ID. Applications register a handler with the
connection to be = notified of new events.

=C2=A0 =C2=A0type Connecti= onHandler interface {
=C2=A0 =C2=A0 // The connection has changed state to state |s|
=C2=A0= =C2=A0 StateChanged(s State)
<= div>=C2=A0 =C2=A0
=C2=A0 =C2=A0 <= /span>// A new stream has been created (by receiving a frame
=C2= =A0 =C2=A0 // from the other side. |= s| contains the stream.
=C2=A0 =C2=A0 NewStream(s *Stream)
=C2=A0 =C2=A0
=C2=A0 = =C2=A0 // Stream |s| is now readable= .
=C2=A0 =C2=A0 StreamRead= able(s *Stream)
=C2=A0 =C2=A0}

Streams g= et created in two ways:

- Locally via Connection.C= reateStream()
- Remotely, in which case the application is notifi= ed via a callback to
=C2=A0 ConnectionHandler.NewStream().
<= div>
Streams themselves have the APIs you would expect, namel= y, Read(),
Write(), Close(), Reset(), etc. You get notified of st= ream readability
by a callback to ConnectionHandler.StreamReadabl= e(), at which point
you can do Stream.Read(). As expected, Stream= .Read() returns
WOULDBLOCK when no data ia available

INTERNALS
As noted above, we start wi= th the Connection object (only relevant fields
shown):
=
=C2=A0 =C2=A0type Connection struct {
=C2=A0 =C2= =A0 handler=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 ConnectionHandler
=C2=A0 =C2=A0 streams=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 []*Stream
<= div>=C2=A0 =C2=A0 maxStream=C2=A0 = =C2=A0 =C2=A0 =C2=A0 uint32
outputClearQ=C2=A0 =C2=A0 =C2=A0[]frame // For stream 0
outputProtectedQ []frame // For stream &g= t;=3D 0
=C2=A0 =C2=A0}

As you can see, s= treams are in an array slice, so they're contiguously
indexed= by stream ID. Right now, I have no provision for reclaiming
the = unused bottom part of the array, but it would be straightforward
= to index by |streamId| - |minStream|, which I think is consistent with
the design implied by the requirement to create streams in sequence.<= /div>

Because Streams are bidirectional, each stream act= ually consists of a
pair of half streams.

=C2=A0 =C2=A0type streamHalf struct {
=C2=A0 =C2=A0 s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0*stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// pointer to parent
=C2=A0 =C2=A0 log=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggingFunction=C2=A0 =C2=A0
=C2= =A0 =C2=A0 dir=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0direction=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Sending o= r receiving
=C2=A0 =C2=A0 = closed=C2=A0 =C2=A0 =C2=A0 =C2=A0 bool=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 // Is the half-stream closed
=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // The
=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []strea= mChunk
=C2=A0 =C2=A0 maxSt= reamData uint64
=C2=A0 =C2=A0}

=C2=A0 = =C2=A0// Internal object to allow unit testing.
=C2=A0 =C2=A0type= stream struct {
=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 loggingF= unction
=C2=A0 =C2=A0 stat= e=C2=A0 =C2=A0 =C2=A0 streamState
=C2=A0 =C2=A0 send, recv *streamHalf
=C2=A0 blocked=C2=A0 =C2=A0 bool // Have we returned blo= cked
=C2=A0 =C2=A0}

=C2=A0 =C2=A0// Publ= ic API object, which needs access to the Connection
=C2=A0 =C2=A0= type Stream struct {
=C2=A0 =C2=A0 c *Connection
=C2=A0 =C2=A0 stream
=C2=A0 =C2=A0}

Outgoin= g data is enqueued into |stream.chunks|, and then periodically
th= e connection polls the stream for all the chunks which are permitted
<= div>by stream-level flow control and enqueues them into
|Connecti= on.outputClearQ| or |Connection.outputProtectedQ|. At this
point,= the connection owns the data and is responsible for
transmitting= it, subject to connection-level flow control, and
(presumably) c= ongestion control once I have that implemented [2].

Incoming data gets queued (sorted) into |stream.chunks| for later
reassembly at the time when someone calls stream.read(). I'm not sur= e
I love this, because it means I don't have a good view of t= he incoming
queue size (which I'd need to account for separat= ely), but it allowed
me to share data structures between incoming= and outgoing, which
seemed kind of natural when I did it (this a= rchitecture is replicated
in the unidirectional streams design, b= ut it's probably less natural
there).


UNIDIRECTIONAL STREAMS ARCHITECTURE
UNIDIRECTION= AL API
With the unidirectional branch, Minq offers two APIs. The = first is a
straightforward mapping of PR#720, in which we have tw= o objects:

=C2=A0 SendStream -- used for writing
=C2=A0 RecvStream -- used for reading

As = before, we have a handler object, but it's directional now:
<= br>
=C2=A0 =C2=A0type ConnectionHandler interface {
=C2= =A0 =C2=A0 // The connection has cha= nged state to state |s|
=C2=A0 =C2=A0 StateChanged(s State)
=C2=A0 =C2=A0
=C2=A0 = =C2=A0 // A new receiving stream has= been created (by receiving a frame
=C2=A0 =C2=A0 // from the other side. |s| contains the stream.
=C2=A0 =C2=A0 NewRecvStream(= s *RecvStream)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // Stream |s| is now readable.
=C2= =A0 =C2=A0 StreamReadable(s *RecvStr= eam)
=C2=A0 =C2=A0}

Obviously SendStream= s are locally created and RecvStreams are remotely
created. SendS= treams can be created using
Connection.CreateSendStream() and you= learn about remotely created
RecvStreams by a callback to Connec= tionHandler.NewRecvStream().
Second-created streams can be marked= as "related" to a single
first-created stream, using C= onnection.CreateRelatedSendStream() with
the appropriate RecvStre= am as the argument [3]. Streams have a
Related() API to tell you = if they are related to some other stream.

The {Sen= d,Recv}Stream APIs are about what you'd expect. You can
Write= () on SendStream and Read() on RecvStream(). Right now, you can
C= lose() and Reset() SendStreams, but not do anything on RecvStreams()
<= div>or than ignore them. Eventually I'll probably offer
RecvS= tream().Mute() or something to let you send STOP_SENDING.


BIDIRECTIONAL API
Minq also includes a bid= irectional API that's layered on top of
unidirectional stream= s. I've created a Connection2 structure that's
intended a= s a wrapper around Connection [4]:

=C2=A0 =C2=A0ty= pe Connection2 struct {
=C2=A0 =C2=A0 Connection
=C2=A0 =C2=A0 shim=C2=A0 =C2=A0 *connection2ShimHandler
=C2=A0 =C2= =A0 streams []*Stream // Odd for cli= ent originated, even for server.
=C2=A0 =C2=A0}
=C2=A0 = =C2=A0 =C2=A0
=C2=A0 =C2=A0type Stream struct {
=C2=A0 = =C2=A0 id=C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 send *SendStream
=C2=A0 =C2=A0 recv *RecvStre= am
=C2=A0 =C2=A0}

Basically, Stream is j= ust a pair of SendStream and RecvStream and
Connection2 does the = bookkeeping to keep them connected (I even do the
odd/even ID thi= ng that QUIC-05 has). Connection2 has the same handler
API as Min= q for QUIC-05, and the shim is responsible for translating
unidir= ectional events into bidirectional events.

Interna= lly, what's going on here is that when you call CreateStream()
Minq creates a Stream with a nil RecvStream. When a new remote stream
is detected, we check RecvStream.Related(). If they are related to a= n
existing SendStream then we will in the relevant |Stream.send| = slot.
Otherwise, we create a new SendStream that's related to= the incoming
stream and notify the application of the creation o= f the new
bidirectional stream.

Note tha= t this all works fine if one side does the undirectional API
and = one does the bidirectional API. My test programs actually exercise
this. Of course, there's an assumption that the peer conforms to a 1:= 1
mapping. If we define unidirectional streams, we'll need so= me protocol
mechanism to know if the other side is exercising thi= s level of
increased flexibility or not. I can imagine a number o= f options here
(e.g., ALPN).=C2=A0 We could also forbid 1:N mappi= ngs but I think that
would be a mistake as it's a cool featur= e/benefit of doing
unidirectional.

The e= ntire bidirectional wrapper shim is < 150 lines of Go code.
(<= a href=3D"https://github.com/ekr/minq/blob/unidirectional_streams/bidi.go">= https://github.com/ekr/minq/blob/unidirectional_streams/bidi.go).
=
Converting my test application to this API was a matter of just
<= div>changing class names, e.g., s/Connectionb/Connection2/.

<= /div>
In my implementation, I assume that at the time Minq hears about = a
stream, you know if its related to a given existing stream.=C2= =A0 That way
you can immediately either associate it with that st= ream or make a new
local stream. In my implementation, I always s= end Related Stream Id
and assume that you never get an "unre= lated" stream frame before a
"related" one. The sp= ec doesn't really require that right now, and
offline MT sugg= ested just sending related with offset=3D0 but I think
that's= a mistake, because it means that you need to hold stream frames
= in some provisional "undetermined" state until you get that frame= . I
would suggest instead that we require that you include the fi= eld until
one of the frames is ACKed.
=C2=A0=C2=A0

INTERNALS
Sending and receiving streams stil= l share a lot of common components:

=C2=A0 =C2=A0 = type baseStream struct {
=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streamState
= =C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 uint32
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggingFun= ction
=C2=A0 =C2=A0 offse= t=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64
=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []streamChunk
=C2=A0 =C2=A0 maxStreamData= uint64
=C2=A0 =C2=A0 isR= elated=C2=A0 =C2=A0 =C2=A0bool
=C2=A0 =C2=A0 related=C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2= =A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 type sen= dStream struct {
=C2=A0 =C2=A0 <= /span>baseStream
=C2=A0 =C2=A0 <= /span>blocked bool
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0<= /div>
=C2=A0 =C2=A0 type recvStream struct {
=C2=A0 =C2=A0 baseStream
=C2=A0 =C2=A0 }<= /div>

Most of this is the same as with bidirectional str= eams.=C2=A0 As above,
it's probably possible to make them mor= e asymmetrical.

The connection maintains separate = lists of sending and receiving
streams and it's straightforwa= rd to create and access them without
worrying about the odd/even = stuff.


COMPARISON
At the = end of the day, I think this shows that these designs aren't
= really that disssimilar. I was able to convert Minq to unidirectional
=
streams in about 16 total hours of work (basically a long plane flight=
plus the next morning). While I had to make a bunch of changes t= o the
internal structures, basically none of them modified anythi= ng tricky,
and in particular the flow control mechanics and the l= ike are
basically unchanged, except for a bunch of mechanical-typ= e
transformations like referring to |sendStream.chunks| instead o= f
|stream.send.chunks|. The only really new protocol machinery is= the
new frame format for related streams.

There are a few pros/cons that are worth noting about these designs.

- Without a bidirectional API, having unidirectional = streams is more
=C2=A0 work for the programmer. However, with an = API shim, the difference
=C2=A0 is trivial.

<= div>- Because undirectional streams are inherently more flexible, it's<= /div>
=C2=A0 possible for the sides to try to use different mappings, e= .g., one
=C2=A0 side expects paired and the other expects 1:N. We= 'll need some way
=C2=A0 of making sure that doesn't happ= en, maybe ALPN?

- The "Related Stream ID"= ; frame indicator needs fleshing out a bit.
=C2=A0 From the appli= cation's perspective, it should never hear about a
=C2=A0 str= eam without knowing its related status. And as noted above, I
=C2= =A0 think it would be best if we required that all "first flight"= stream
=C2=A0 frames that are related include the fied

- Undirectional streams kind of sharpen the confusion about= exactly
=C2=A0 what kinds of "closure" we want to allo= w. Specifically, what should
=C2=A0 implementations be able to sa= y about their willingness to receive?
=C2=A0 Right now we have ST= OP_SENDING, but that doesn't influence the
=C2=A0 sender'= s state. I don't think undirectional streams make this worse,
=C2=A0 they just require us to think it through some more. They do simplif= y
=C2=A0 the implementation of the closure state machine: in my Q= UIC-05 code,
=C2=A0 whenever one side closes I have to have check= s to see if I should be
=C2=A0 transitioning to CLOSED or HALF-CL= OSED, etc, which is odd because
=C2=A0 the directions are basical= ly independent.=C2=A0 It would probably be
=C2=A0 easier even in = QUIC-05 not to reify these states but just to
=C2=A0 determine th= e state from the composition of the individual
=C2=A0 sub-states<= /div>
=C2=A0=C2=A0
- Unidirectional streams don't need th= e kind of annoying odd-even
=C2=A0 mechanics, which was easier to= code up (just having to create all
=C2=A0 the lower-numbered str= eams of the same parity is kind of a pain).
=C2=A0 One additional= benefit here is that with QUIC-05 there are several
=C2=A0 messa= ges which involve implicit stream creation (e.g.,
=C2=A0 STREAM_M= AX_DATA, and RST_STREAM) and so you need to check whether
=C2=A0 = the stream is one that should have been created locally or
=C2=A0= remotely. This just doesn't happen with bidirectional streams; I do
=C2=A0 implement odd/even mechanics but because the other side has = to have
=C2=A0 its stream ids increment by one, I can make sure t= hat they have the
=C2=A0 right IDs by construction and just check= to see if the stream exists
=C2=A0 in these cases.=C2=A0 I'd= like to see us get rid of odd/even no matter
=C2=A0 what.
<= div>
- Unidirectional streams also helps avoid some of the co= rner cases around
=C2=A0 bidirectional streams. Specifically, sup= pose I am the client and
=C2=A0 I get MAX_STREAM_DATA as the firs= t frame on stream 2. Am I allowed
=C2=A0 to just start sending or= not? You can sort of get into this situation
=C2=A0 with unidire= ctional streams, but because it's explicit, one might
=C2=A0 = hope that the application semantics would require clear specification.
=C2=A0=C2=A0
- As noted above, bidirectional streams are mo= re flexible because they
=C2=A0 let you have mappings that you ca= n't have with unidirectional
=C2=A0 streams (unpaired, 1:N).<= /div>


Happy to answer more questions if p= eople have them. Otherwise we can
talk about this in Seattle.

-Ekr


[2] Thanks t= o Patrick McManus for suggesting this design.
[3] In C++, you wou= ld have a single function with a default argument of
=C2=A0 =C2= =A0 |nullptr| but Go doesn't support that, hence two different argument= s.
[4] For implementation reasons, it's actually using Connec= tion as a mixin,
=C2=A0 =C2=A0 which means it's simultaneousl= y possible to use the unidirectional
=C2=A0 =C2=A0 and bidirectio= nal APIs, but that's going to cause a lot of confusion.
=C2= =A0 =C2=A0 A real implementation would probably have to either commit to on= e
=C2=A0 =C2=A0 or the other or do a real wrapper, so you could o= nly use one set of
=C2=A0 =C2=A0 APIs, at the cost of having to d= o more forwarded methods.
=C2=A0 =C2=A0=C2=A0
=C2=A0=C2= =A0




<= br>



--001a114dad96f9aad7055a822597-- From nobody Sun Oct 1 13:38: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 0C8AE134B0B for ; Sun, 1 Oct 2017 13:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 kuvCshoB0N3U for ; Sun, 1 Oct 2017 13:38:37 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36A12134B08 for ; Sun, 1 Oct 2017 13:38:37 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id g18so5215785itg.5 for ; Sun, 01 Oct 2017 13:38:37 -0700 (PDT) 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; bh=QJE/twFtolXpNED0NsAkh8VSCEyHuvE38mSgITfKgIY=; b=QPog+NSpW3J9zwMf4hBFGO1Zdc7knXcgH0avp3C5F8K2wGIxY4iZw0CLPMl6WIruCF ROM2tWe2/URQmGclxKfZDu1r5eKPnpo0j1XKcm2GdjFWDCNwZm7s/9jRV9G2JQrjUL4E W/nH6Tp7UDmzSuidviM6FdssNdXv7U+raN3PIfpOWqApvaGuQRKWSUIaEsxazpfGsqF8 UmFfT628QGv9JgzL/Zc+gdhpPR70XZ+2w1/j/47N5DO7ja8aJU+7+FAEm/QbfOP21bxr ZZ9uawnBqzqxWioUclWxRFAJfBk7xHKRm5k7+C50ZDiPpa60IE0G+By3EYa6Svt7fAAz P2ew== 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; bh=QJE/twFtolXpNED0NsAkh8VSCEyHuvE38mSgITfKgIY=; b=KrxUTTWupqB5vT6hjV3mi3vT64YBQ3yfO+osU4ol/XtGuNPXUKuD6ehDJuXIDdh9Bk 7lT6lrfoFj/aET2HAhIc+Agf6U8g/Ce56yrtpPFZ5dckYB1w0QWjvCx8GSXBYafC7CtQ c34VWw294QgW1nKKUg2Vev/fc94XTokQgiUNIjjFXj/Dm2eJCv/82U6u810TX4SYGsnA E3EkiAsUAVwnnhKhVo5d+lz0ndbDUQoSUIx7R3mNF+ugzIS153ffdQSdnns223LzGmyE 3R5JV/x7h6CqLt4t0X8F+tkg0M77lEVZPd4EezVFghWdMnoap39uqQn5VUDsJi4f7Yxz JJtA== X-Gm-Message-State: AMCzsaV+FIT+7f2Vp4BU9g+1X71g7rfS16YxvXzbfCJR+M1BRzLYSmjZ w5DbxwoAiNCFP+/Dn5YCw9EOVoNM+2MvU15JB8Tr1A== X-Google-Smtp-Source: AOwi7QDsbD5xnR7raemaR+qoayZOc/4wnVAxZzO4V5C/tNl/vMeKQg/1XqpoqJ3ftmovk1ABfrnFTd0AS9y7nDZ4/ec= X-Received: by 10.36.94.5 with SMTP id h5mr16943421itb.100.1506890316391; Sun, 01 Oct 2017 13:38:36 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 1 Oct 2017 16:38:35 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 1 Oct 2017 16:38:35 -0400 Message-ID: Subject: Re: Report on Unidirectional Streams in Minq To: Eric Rescorla , IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114489a60629f0055a823e30" 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, 01 Oct 2017 20:38:41 -0000 --001a114489a60629f0055a823e30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks, I only skimmed this superfast, but one the observations appear to not cover one of my key points: You can create and close uni-streams at at very high rate of many streams per packet, without waiting for peer response, assuming the ACK framework handles retransmission. Any insights on this? Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 1 October 2017 at 22.32.02, Eric Rescorla (ekr@rtfm.com) wrote: Hi folks, As promised I spent a bunch of time hacking unidirectional streams into Minq and I'm here to report back [0]. Specifically, I implemented: - PR#643 -- Unidirectional Streams - PR#720 -- Add bidirectional streams on top of unidirectional - A bidirectional stream API that mostly mimics Minq's original API for -05. The following is kind of a wall of text, so you could also skip this and refer to my slides [1]. MINQ'S -05 ARCHITECTURE API Minq's master object is the Connection, which has a list of Streams indexed by stream ID. Applications register a handler with the connection to be notified of new events. type ConnectionHandler interface { // The connection has changed state to state |s| StateChanged(s State) // A new stream has been created (by receiving a frame // from the other side. |s| contains the stream. NewStream(s *Stream) // Stream |s| is now readable. StreamReadable(s *Stream) } Streams get created in two ways: - Locally via Connection.CreateStream() - Remotely, in which case the application is notified via a callback to ConnectionHandler.NewStream(). Streams themselves have the APIs you would expect, namely, Read(), Write(), Close(), Reset(), etc. You get notified of stream readability by a callback to ConnectionHandler.StreamReadable(), at which point you can do Stream.Read(). As expected, Stream.Read() returns WOULDBLOCK when no data ia available INTERNALS As noted above, we start with the Connection object (only relevant fields shown): type Connection struct { handler ConnectionHandler streams []*Stream maxStream uint32 outputClearQ []frame // For stream 0 outputProtectedQ []frame // For stream >=3D 0 } As you can see, streams are in an array slice, so they're contiguously indexed by stream ID. Right now, I have no provision for reclaiming the unused bottom part of the array, but it would be straightforward to index by |streamId| - |minStream|, which I think is consistent with the design implied by the requirement to create streams in sequence. Because Streams are bidirectional, each stream actually consists of a pair of half streams. type streamHalf struct { s *stream // pointer to parent log loggingFunction dir direction // Sending or receiving closed bool // Is the half-stream closed offset uint64 // The chunks []streamChunk maxStreamData uint64 } // Internal object to allow unit testing. type stream struct { id uint32 log loggingFunction state streamState send, recv *streamHalf blocked bool // Have we returned blocked } // Public API object, which needs access to the Connection type Stream struct { c *Connection stream } Outgoing data is enqueued into |stream.chunks|, and then periodically the connection polls the stream for all the chunks which are permitted by stream-level flow control and enqueues them into |Connection.outputClearQ| or |Connection.outputProtectedQ|. At this point, the connection owns the data and is responsible for transmitting it, subject to connection-level flow control, and (presumably) congestion control once I have that implemented [2]. Incoming data gets queued (sorted) into |stream.chunks| for later reassembly at the time when someone calls stream.read(). I'm not sure I love this, because it means I don't have a good view of the incoming queue size (which I'd need to account for separately), but it allowed me to share data structures between incoming and outgoing, which seemed kind of natural when I did it (this architecture is replicated in the unidirectional streams design, but it's probably less natural there). UNIDIRECTIONAL STREAMS ARCHITECTURE UNIDIRECTIONAL API With the unidirectional branch, Minq offers two APIs. The first is a straightforward mapping of PR#720, in which we have two objects: SendStream -- used for writing RecvStream -- used for reading As before, we have a handler object, but it's directional now: type ConnectionHandler interface { // The connection has changed state to state |s| StateChanged(s State) // A new receiving stream has been created (by receiving a frame // from the other side. |s| contains the stream. NewRecvStream(s *RecvStream) // Stream |s| is now readable. StreamReadable(s *RecvStream) } Obviously SendStreams are locally created and RecvStreams are remotely created. SendStreams can be created using Connection.CreateSendStream() and you learn about remotely created RecvStreams by a callback to ConnectionHandler.NewRecvStream(). Second-created streams can be marked as "related" to a single first-created stream, using Connection.CreateRelatedSendStream() with the appropriate RecvStream as the argument [3]. Streams have a Related() API to tell you if they are related to some other stream. The {Send,Recv}Stream APIs are about what you'd expect. You can Write() on SendStream and Read() on RecvStream(). Right now, you can Close() and Reset() SendStreams, but not do anything on RecvStreams() or than ignore them. Eventually I'll probably offer RecvStream().Mute() or something to let you send STOP_SENDING. BIDIRECTIONAL API Minq also includes a bidirectional API that's layered on top of unidirectional streams. I've created a Connection2 structure that's intended as a wrapper around Connection [4]: type Connection2 struct { Connection shim *connection2ShimHandler streams []*Stream // Odd for client originated, even for server. } type Stream struct { id uint32 send *SendStream recv *RecvStream } Basically, Stream is just a pair of SendStream and RecvStream and Connection2 does the bookkeeping to keep them connected (I even do the odd/even ID thing that QUIC-05 has). Connection2 has the same handler API as Minq for QUIC-05, and the shim is responsible for translating unidirectional events into bidirectional events. Internally, what's going on here is that when you call CreateStream() Minq creates a Stream with a nil RecvStream. When a new remote stream is detected, we check RecvStream.Related(). If they are related to an existing SendStream then we will in the relevant |Stream.send| slot. Otherwise, we create a new SendStream that's related to the incoming stream and notify the application of the creation of the new bidirectional stream. Note that this all works fine if one side does the undirectional API and one does the bidirectional API. My test programs actually exercise this. Of course, there's an assumption that the peer conforms to a 1:1 mapping. If we define unidirectional streams, we'll need some protocol mechanism to know if the other side is exercising this level of increased flexibility or not. I can imagine a number of options here (e.g., ALPN). We could also forbid 1:N mappings but I think that would be a mistake as it's a cool feature/benefit of doing unidirectional. The entire bidirectional wrapper shim is < 150 lines of Go code. (https://github.com/ekr/minq/blob/unidirectional_streams/bidi.go). Converting my test application to this API was a matter of just changing class names, e.g., s/Connectionb/Connection2/. In my implementation, I assume that at the time Minq hears about a stream, you know if its related to a given existing stream. That way you can immediately either associate it with that stream or make a new local stream. In my implementation, I always send Related Stream Id and assume that you never get an "unrelated" stream frame before a "related" one. The spec doesn't really require that right now, and offline MT suggested just sending related with offset=3D0 but I think that's a mistake, because it means that you need to hold stream frames in some provisional "undetermined" state until you get that frame. I would suggest instead that we require that you include the field until one of the frames is ACKed. INTERNALS Sending and receiving streams still share a lot of common components: type baseStream struct { state streamState id uint32 log loggingFunction offset uint64 chunks []streamChunk maxStreamData uint64 isRelated bool related uint32 } type sendStream struct { baseStream blocked bool } type recvStream struct { baseStream } Most of this is the same as with bidirectional streams. As above, it's probably possible to make them more asymmetrical. The connection maintains separate lists of sending and receiving streams and it's straightforward to create and access them without worrying about the odd/even stuff. COMPARISON At the end of the day, I think this shows that these designs aren't really that disssimilar. I was able to convert Minq to unidirectional streams in about 16 total hours of work (basically a long plane flight plus the next morning). While I had to make a bunch of changes to the internal structures, basically none of them modified anything tricky, and in particular the flow control mechanics and the like are basically unchanged, except for a bunch of mechanical-type transformations like referring to |sendStream.chunks| instead of |stream.send.chunks|. The only really new protocol machinery is the new frame format for related streams. There are a few pros/cons that are worth noting about these designs. - Without a bidirectional API, having unidirectional streams is more work for the programmer. However, with an API shim, the difference is trivial. - Because undirectional streams are inherently more flexible, it's possible for the sides to try to use different mappings, e.g., one side expects paired and the other expects 1:N. We'll need some way of making sure that doesn't happen, maybe ALPN? - The "Related Stream ID" frame indicator needs fleshing out a bit. From the application's perspective, it should never hear about a stream without knowing its related status. And as noted above, I think it would be best if we required that all "first flight" stream frames that are related include the fied - Undirectional streams kind of sharpen the confusion about exactly what kinds of "closure" we want to allow. Specifically, what should implementations be able to say about their willingness to receive? Right now we have STOP_SENDING, but that doesn't influence the sender's state. I don't think undirectional streams make this worse, they just require us to think it through some more. They do simplify the implementation of the closure state machine: in my QUIC-05 code, whenever one side closes I have to have checks to see if I should be transitioning to CLOSED or HALF-CLOSED, etc, which is odd because the directions are basically independent. It would probably be easier even in QUIC-05 not to reify these states but just to determine the state from the composition of the individual sub-states - Unidirectional streams don't need the kind of annoying odd-even mechanics, which was easier to code up (just having to create all the lower-numbered streams of the same parity is kind of a pain). One additional benefit here is that with QUIC-05 there are several messages which involve implicit stream creation (e.g., STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether the stream is one that should have been created locally or remotely. This just doesn't happen with bidirectional streams; I do implement odd/even mechanics but because the other side has to have its stream ids increment by one, I can make sure that they have the right IDs by construction and just check to see if the stream exists in these cases. I'd like to see us get rid of odd/even no matter what. - Unidirectional streams also helps avoid some of the corner cases around bidirectional streams. Specifically, suppose I am the client and I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed to just start sending or not? You can sort of get into this situation with unidirectional streams, but because it's explicit, one might hope that the application semantics would require clear specification. - As noted above, bidirectional streams are more flexible because they let you have mappings that you can't have with unidirectional streams (unpaired, 1:N). Happy to answer more questions if people have them. Otherwise we can talk about this in Seattle. -Ekr [0] https://github.com/ekr/minq/tree/unidirectional_streams [1] https://github.com/ekr/wg-materials/blob/404898fa2d2f0a9f9bd244d2c945e66ea8= 8502a2/interim-17-10/Unidirectional%20Streams%20in%20Minq.pdf [2] Thanks to Patrick McManus for suggesting this design. [3] In C++, you would have a single function with a default argument of |nullptr| but Go doesn't support that, hence two different arguments. [4] For implementation reasons, it's actually using Connection as a mixin, which means it's simultaneously possible to use the unidirectional and bidirectional APIs, but that's going to cause a lot of confusion. A real implementation would probably have to either commit to one or the other or do a real wrapper, so you could only use one set of APIs, at the cost of having to do more forwarded methods. --001a114489a60629f0055a823e30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Thanks,

I only skimmed this superfast, but one the observations appe= ar to not cover one of my key points:

You can create and close uni-streams at at very high rate = of many streams per packet, without waiting for peer response, assuming the= ACK framework handles retransmission. Any insights on this?

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8r= gensen


On 1 October 2017 at= 22.32.02, Eric Rescorla (ekr@rtfm.com)= wrote:

Hi folks,

As promised I spent a bunch of time hacking unidirectional streams
into Minq and I'm here to report back [0]. Specifically, I
implemented:

=C2=A0 - PR#643 -- Unidirectional Streams
=C2=A0 - PR#720 -- Add bidirectional streams on top of unidirectional
=C2=A0 - A bidirectional stream API that mostly mimics Minq's original API
=C2=A0 =C2=A0 for -05.
=C2=A0 =C2=A0=C2=A0
The following is kind of a wall of text, so you could also skip this
and refer to my slides [1].


MINQ'S -05 ARCHITECTURE
API
Minq's master object is the Connection, which has a list of Streams
indexed by stream ID. Applications register a handler with the
connection to be notified of new events.

=C2=A0 =C2=A0type ConnectionHandler interface {
=C2=A0 =C2=A0 // The connection has changed state to state |s|
=C2=A0 =C2=A0 StateChanged(s State)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // A new stream has been created (by receiving a frame
=C2=A0 =C2=A0 // from the other side. |s| contains the stream.
=C2=A0 =C2=A0 NewStream(s *Stream)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // Stream |s| is now readable.
=C2=A0 =C2=A0 StreamReadable(s *Stream)
=C2=A0 =C2=A0}

Streams get created in two ways:

- Locally via Connection.CreateStream()
- Remotely, in which case the application is notified via a callback to
=C2=A0 ConnectionHandler.NewStream().

Streams themselves have the APIs you would expect, namely, Read(),
Write(), Close(), Reset(), etc. You get notified of stream readability
by a callback to ConnectionHandler.StreamReadable(), at which point
you can do Stream.Read(). As expected, Stream.Read() returns
WOULDBLOCK when no data ia available


INTERNALS
As noted above, we start with the Connection object (only relevant fields
shown):

=C2=A0 =C2=A0type Connection struct {
=C2=A0 =C2=A0 handler=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ConnectionHandler
=C2=A0 =C2=A0 streams=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 []*Stream
=C2=A0 =C2=A0 maxStream=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
outputClearQ=C2=A0 =C2=A0 =C2=A0[]frame // For stream 0
outputProtectedQ []frame // For stream >=3D 0
=C2=A0 =C2=A0}

As you can see, streams are in an array slice, so they're contiguously
indexed by stream ID. Right now, I have no provision for reclaiming
the unused bottom part of the array, but it would be straightforward
to index by |streamId| - |minStream|, which I think is consistent with
the design implied by the requirement to create streams in sequence.

Because Streams are bidirectional, each stream actually consists of a
pair of half streams.

=C2=A0 =C2=A0type streamHalf struct {
=C2=A0 =C2=A0 s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// pointer to parent
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggingFunction=C2=A0 =C2=A0
=C2=A0 =C2=A0 dir=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0direction=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Sending or receiving
=C2=A0 =C2=A0 closed=C2=A0 =C2=A0 =C2=A0 =C2=A0 bool=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Is the half-stream closed
=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // The
=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []streamChunk
=C2=A0 =C2=A0 maxStreamData uint64
=C2=A0 =C2=A0}

=C2=A0 =C2=A0// Internal object to allow unit testing.
=C2=A0 =C2=A0type stream struct {
=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 loggingFunction
=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 streamState
=C2=A0 =C2=A0 send, recv *streamHalf
=C2=A0 blocked=C2=A0 =C2=A0 bool // Have we returned blocked
=C2=A0 =C2=A0}

=C2=A0 =C2=A0// Public API object, which needs access to the Connection
=C2=A0 =C2=A0type Stream struct {
=C2=A0 =C2=A0 c *Connection
=C2=A0 =C2=A0 stream
=C2=A0 =C2=A0}

Outgoing data is enqueued into |stream.chunks|, and then periodically
the connection polls the stream for all the chunks which are permitted
by stream-level flow control and enqueues them into
|Connection.outputClearQ| or |Connection.outputProtectedQ|. At this
point, the connection owns the data and is responsible for
transmitting it, subject to connection-level flow control, and
(presumably) congestion control once I have that implemented [2].

Incoming data gets queued (sorted) into |stream.chunks| for later
reassembly at the time when someone calls stream.read(). I'm not sure
I love this, because it means I don't have a good view of the incoming
queue size (which I'd need to account for separately), but it allowed
me to share data structures between incoming and outgoing, which
seemed kind of natural when I did it (this architecture is replicated
in the unidirectional streams design, but it's probably less natural
there).


UNIDIRECTIONAL STREAMS ARCHITECTURE
UNIDIRECTIONAL API
With the unidirectional branch, Minq offers two APIs. The first is a
straightforward mapping of PR#720, in which we have two objects:

=C2=A0 SendStream -- used for writing
=C2=A0 RecvStream -- used for reading

As before, we have a handler object, but it's directional now:

=C2=A0 =C2=A0type ConnectionHandler interface {
=C2=A0 =C2=A0 // The connection has changed state to state |s|
=C2=A0 =C2=A0 StateChanged(s State)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // A new receiving stream has been created (by receiving a frame
=C2=A0 =C2=A0 // from the other side. |s| contains the stream.
=C2=A0 =C2=A0 NewRecvStream(s *RecvStream)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // Stream |s| is now readable.
=C2=A0 =C2=A0 StreamReadable(s *RecvStream)
=C2=A0 =C2=A0}

Obviously SendStreams are locally created and RecvStreams are remotely
created. SendStreams can be created using
Connection.CreateSendStream() and you learn about remotely created
RecvStreams by a callback to ConnectionHandler.NewRecvStream().
Second-created streams can be marked as "related" to a single
first-created stream, using Connection.CreateRelatedSendStream() with
the appropriate RecvStream as the argument [3]. Streams have a
Related() API to tell you if they are related to some other stream.

The {Send,Recv}Stream APIs are about what you'd expect. You can
Write() on SendStream and Read() on RecvStream(). Right now, you can
Close() and Reset() SendStreams, but not do anything on RecvStreams()
or than ignore them. Eventually I'll probably offer
RecvStream().Mute() or something to let you send STOP_SENDING.


BIDIRECTIONAL API
Minq also includes a bidirectional API that's layered on top of
unidirectional streams. I've created a Connection2 structure that's
intended as a wrapper around Connection [4]:

=C2=A0 =C2=A0type Connection2 struct {
=C2=A0 =C2=A0 Connection
=C2=A0 =C2=A0 shim=C2=A0 =C2=A0 *connection2ShimHandler
=C2=A0 =C2=A0 streams []*Stream // Odd for client originated, even for server.
=C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0type Stream struct {
=C2=A0 =C2=A0 id=C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 send *SendStream
=C2=A0 =C2=A0 recv *RecvStream
=C2=A0 =C2=A0}

Basically, Stream is just a pair of SendStream and RecvStream and
Connection2 does the bookkeeping to keep them connected (I even do the
odd/even ID thing that QUIC-05 has). Connection2 has the same handler
API as Minq for QUIC-05, and the shim is responsible for translating
unidirectional events into bidirectional events.

Internally, what's going on here is that when you call CreateStream()
Minq creates a Stream with a nil RecvStream. When a new remote stream
is detected, we check RecvStream.Related(). If they are related to an
existing SendStream then we will in the relevant |Stream.send| slot.
Otherwise, we create a new SendStream that's related to the incoming
stream and notify the application of the creation of the new
bidirectional stream.

Note that this all works fine if one side does the undirectional API
and one does the bidirectional API. My test programs actually exercise
this. Of course, there's an assumption that the peer conforms to a 1:1
mapping. If we define unidirectional streams, we'll need some protocol
mechanism to know if the other side is exercising this level of
increased flexibility or not. I can imagine a number of options here
(e.g., ALPN).=C2=A0 We could also forbid 1:N mappings but I think that
would be a mistake as it's a cool feature/benefit of doing
unidirectional.

The entire bidirectional wrapper shim is < 150 lines of Go code.
Converting my test application to this API was a matter of just
changing class names, e.g., s/Connectionb/Connection2/.

In my implementation, I assume that at the time Minq hears about a
stream, you know if its related to a given existing stream.=C2=A0 That way
you can immediately either associate it with that stream or make a new
local stream. In my implementation, I always send Related Stream Id
and assume that you never get an "unrelated" stream frame before a
"related" one. The spec doesn't really require that righ= t now, and
offline MT suggested just sending related with offset=3D0 but I think
that's a mistake, because it means that you need to hold stream frames
in some provisional "undetermined" state until you get that frame. I
would suggest instead that we require that you include the field until
one of the frames is ACKed.
=C2=A0=C2=A0

INTERNALS
Sending and receiving streams still share a lot of common components:

=C2=A0 =C2=A0 type baseStream struct {
=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streamState
=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggingFunction
=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64
=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []streamChunk
=C2=A0 =C2=A0 maxStreamData uint64
=C2=A0 =C2=A0 isRelated=C2=A0 =C2=A0 =C2=A0bool
=C2=A0 =C2=A0 related=C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 type sendStream struct {
=C2=A0 =C2=A0 baseStream
=C2=A0 =C2=A0 blocked bool
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 type recvStream struct {
=C2=A0 =C2=A0 baseStream
=C2=A0 =C2=A0 }

Most of this is the same as with bidirectional streams.=C2=A0 As above,
it's probably possible to make them more asymmetrical.

The connection maintains separate lists of sending and receiving
streams and it's straightforward to create and access them without
worrying about the odd/even stuff.


COMPARISON
At the end of the day, I think this shows that these designs aren't
really that disssimilar. I was able to convert Minq to unidirectional
streams in about 16 total hours of work (basically a long plane flight
plus the next morning). While I had to make a bunch of changes to the
internal structures, basically none of them modified anything tricky,
and in particular the flow control mechanics and the like are
basically unchanged, except for a bunch of mechanical-type
transformations like referring to |sendStream.chunks| instead of
|stream.send.chunks|. The only really new protocol machinery is the
new frame format for related streams.

There are a few pros/cons that are worth noting about these designs.

- Without a bidirectional API, having unidirectional streams is more
=C2=A0 work for the programmer. However, with an API shim, the difference
=C2=A0 is trivial.

- Because undirectional streams are inherently more flexible, it's
=C2=A0 possible for the sides to try to use different mappings, e.g., one
=C2=A0 side expects paired and the other expects 1:N. We'll need some way
=C2=A0 of making sure that doesn't happen, maybe ALPN?

- The "Related Stream ID" frame indicator needs fleshing out= a bit.
=C2=A0 From the application's perspective, it should never hear about a
=C2=A0 stream without knowing its related status. And as noted above, I
=C2=A0 think it would be best if we required that all "first flight" stream
=C2=A0 frames that are related include the fied

- Undirectional streams kind of sharpen the confusion about exactly
=C2=A0 what kinds of "closure" we want to allow. Specificall= y, what should
=C2=A0 implementations be able to say about their willingness to receive?
=C2=A0 Right now we have STOP_SENDING, but that doesn't influence the
=C2=A0 sender's state. I don't think undirectional streams make this worse,
=C2=A0 they just require us to think it through some more. They do simplify
=C2=A0 the implementation of the closure state machine: in my QUIC-05 code,
=C2=A0 whenever one side closes I have to have checks to see if I should be
=C2=A0 transitioning to CLOSED or HALF-CLOSED, etc, which is odd because
=C2=A0 the directions are basically independent.=C2=A0 It would probably be
=C2=A0 easier even in QUIC-05 not to reify these states but just to
=C2=A0 determine the state from the composition of the individual
=C2=A0 sub-states
=C2=A0=C2=A0
- Unidirectional streams don't need the kind of annoying odd-even
=C2=A0 mechanics, which was easier to code up (just having to create all
=C2=A0 the lower-numbered streams of the same parity is kind of a pain).
=C2=A0 One additional benefit here is that with QUIC-05 there are several
=C2=A0 messages which involve implicit stream creation (e.g.,
=C2=A0 STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether
=C2=A0 the stream is one that should have been created locally or
=C2=A0 remotely. This just doesn't happen with bidirectional streams; I do
=C2=A0 implement odd/even mechanics but because the other side has to have
=C2=A0 its stream ids increment by one, I can make sure that they have the
=C2=A0 right IDs by construction and just check to see if the stream exists
=C2=A0 in these cases.=C2=A0 I'd like to see us get rid of odd/even no matter
=C2=A0 what.

- Unidirectional streams also helps avoid some of the corner cases around
=C2=A0 bidirectional streams. Specifically, suppose I am the client and
=C2=A0 I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed
=C2=A0 to just start sending or not? You can sort of get into this situation
=C2=A0 with unidirectional streams, but because it's explicit, one might
=C2=A0 hope that the application semantics would require clear specification.
=C2=A0=C2=A0
- As noted above, bidirectional streams are more flexible because they
=C2=A0 let you have mappings that you can't have with unidirectional
=C2=A0 streams (unpaired, 1:N).


Happy to answer more questions if people have them. Otherwise we can
talk about this in Seattle.

-Ekr


[2] Thanks to Patrick McManus for suggesting this design.
[3] In C++, you would have a single function with a default argument of
=C2=A0 =C2=A0 |nullptr| but Go doesn't support that, hence two different arguments.
[4] For implementation reasons, it's actually using Connection as a mixin,
=C2=A0 =C2=A0 which means it's simultaneously possible to use the unidirectional
=C2=A0 =C2=A0 and bidirectional APIs, but that's going to cause a lot of confusion.
=C2=A0 =C2=A0 A real implementation would probably have to either commit to one
=C2=A0 =C2=A0 or the other or do a real wrapper, so you could only use one set of
=C2=A0 =C2=A0 APIs, at the cost of having to do more forwarded methods.
=C2=A0 =C2=A0=C2=A0
=C2=A0=C2=A0








--001a114489a60629f0055a823e30-- From nobody Sun Oct 1 14: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 D3E20134B1E for ; Sun, 1 Oct 2017 14:04:07 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DxU1mIED8ZHs for ; Sun, 1 Oct 2017 14:04:03 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49FD0134B22 for ; Sun, 1 Oct 2017 14:04:03 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id i83so691001ywb.7 for ; Sun, 01 Oct 2017 14:04:03 -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=uYa1UPf1uTXLsFpjPOCcQAVJ76F66WpE/KeGjp8wQVc=; b=EJ6ithkRooMJDxACezhSpgVxIlNEWggcpNYoyDsKPZrx+nGLtzWcOh61aNCiBd55X0 rdsJRipRlsNpLlyJgCuepSe9uBoLvKslUPco8X96HTydCdGpUuRqYDlaj4xL9ZkvzWUL 3EcaDCAAUILDE2nCqTRigetzJyyikBewdJ3kRgg/ol0zeDQFclOcBydIdHUi7thj42rV INr0atqccxP2p2qxM1DuUMrT5CrwUOE2sasT5KSTgBEXaZnASdUoOaTvrZ13rFsB5vh9 kodMj4rYEWSekw+Bt5KwVn72z1kZavXCh5+SmDx5k+gANqsPa/W5JdmJC0qMo5598NRP bO3w== 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=uYa1UPf1uTXLsFpjPOCcQAVJ76F66WpE/KeGjp8wQVc=; b=c639+hHaxaI+cV+SpbE1Qzds7aimvKHSY/V49aKEsSUFZEu7maye/Y8X45M7rzuQnz 17Gmbvi1Y9+N6MQFsK9eihUuI9meiX/HzsHGYxtLHmdRK8UQ9mthbTNLfaA6SBo8RCu9 HYzCNIcMU2AD6rJ5OGfdcBa/KUeQX7XEHAKCNSfseL3GC2IJShbGYk8uZZyeBU7Lpprp 7Xr80MF8ty8BQhktJAKpr7GdHgPffHR4cXmnJTWE8lGCSgVe7ARIT3xd+3Bs+qDf6oyL hV/UW8xVHbH8+4vpc+C7ui9wdZM9mQwO4zjOYZkl1s8PAfCT7bnoMoG+PO5HAtOZ6onH m5BA== X-Gm-Message-State: AMCzsaXylIE8+osxM4ITijPS8blcx8yw/Lj+wyJjD2NjOsEJV3NDcrzm e497oodcFsIRUtvnhY0EobtlbGEX9L6CCQ+nMoBxwA== X-Google-Smtp-Source: AOwi7QBZBgoUykzuKnCfbyoSx8ttxzjWTAfI5fKezItTXOJDDyul7iBy+8BXhrejggtwy8xfxa8e818W178pDU1AMnU= X-Received: by 10.37.189.76 with SMTP id p12mr282320ybm.462.1506891842354; Sun, 01 Oct 2017 14:04:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sun, 1 Oct 2017 14:03:21 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 1 Oct 2017 14:03:21 -0700 Message-ID: Subject: Re: Report on Unidirectional Streams in Minq To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="089e0828b4f0fa9630055a8298be" 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, 01 Oct 2017 21:04:08 -0000 --089e0828b4f0fa9630055a8298be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'm not sure I have any useful insights on this, as my implementation handles them more or less the same. Can you explain why you think this would be different with unidirectional versus bidirectional? -Ekr On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Thanks, > > I only skimmed this superfast, but one the observations appear to not > cover one of my key points: > > You can create and close uni-streams at at very high rate of many streams > per packet, without waiting for peer response, assuming the ACK framework > handles retransmission. Any insights on this? > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 1 October 2017 at 22.32.02, Eric Rescorla (ekr@rtfm.com) wrote: > > Hi folks, > > As promised I spent a bunch of time hacking unidirectional streams > into Minq and I'm here to report back [0]. Specifically, I > implemented: > > - PR#643 -- Unidirectional Streams > - PR#720 -- Add bidirectional streams on top of unidirectional > - A bidirectional stream API that mostly mimics Minq's original API > for -05. > > The following is kind of a wall of text, so you could also skip this > and refer to my slides [1]. > > > MINQ'S -05 ARCHITECTURE > API > Minq's master object is the Connection, which has a list of Streams > indexed by stream ID. Applications register a handler with the > connection to be notified of new events. > > type ConnectionHandler interface { > // The connection has changed state to state |s| > StateChanged(s State) > > // A new stream has been created (by receiving a frame > // from the other side. |s| contains the stream. > NewStream(s *Stream) > > // Stream |s| is now readable. > StreamReadable(s *Stream) > } > > Streams get created in two ways: > > - Locally via Connection.CreateStream() > - Remotely, in which case the application is notified via a callback to > ConnectionHandler.NewStream(). > > Streams themselves have the APIs you would expect, namely, Read(), > Write(), Close(), Reset(), etc. You get notified of stream readability > by a callback to ConnectionHandler.StreamReadable(), at which point > you can do Stream.Read(). As expected, Stream.Read() returns > WOULDBLOCK when no data ia available > > > INTERNALS > As noted above, we start with the Connection object (only relevant fields > shown): > > type Connection struct { > handler ConnectionHandler > streams []*Stream > maxStream uint32 > outputClearQ []frame // For stream 0 > outputProtectedQ []frame // For stream >=3D 0 > } > > As you can see, streams are in an array slice, so they're contiguously > indexed by stream ID. Right now, I have no provision for reclaiming > the unused bottom part of the array, but it would be straightforward > to index by |streamId| - |minStream|, which I think is consistent with > the design implied by the requirement to create streams in sequence. > > Because Streams are bidirectional, each stream actually consists of a > pair of half streams. > > type streamHalf struct { > s *stream // pointer to parent > log loggingFunction > dir direction // Sending or receiving > closed bool // Is the half-stream closed > offset uint64 // The > chunks []streamChunk > maxStreamData uint64 > } > > // Internal object to allow unit testing. > type stream struct { > id uint32 > log loggingFunction > state streamState > send, recv *streamHalf > blocked bool // Have we returned blocked > } > > // Public API object, which needs access to the Connection > type Stream struct { > c *Connection > stream > } > > Outgoing data is enqueued into |stream.chunks|, and then periodically > the connection polls the stream for all the chunks which are permitted > by stream-level flow control and enqueues them into > |Connection.outputClearQ| or |Connection.outputProtectedQ|. At this > point, the connection owns the data and is responsible for > transmitting it, subject to connection-level flow control, and > (presumably) congestion control once I have that implemented [2]. > > Incoming data gets queued (sorted) into |stream.chunks| for later > reassembly at the time when someone calls stream.read(). I'm not sure > I love this, because it means I don't have a good view of the incoming > queue size (which I'd need to account for separately), but it allowed > me to share data structures between incoming and outgoing, which > seemed kind of natural when I did it (this architecture is replicated > in the unidirectional streams design, but it's probably less natural > there). > > > UNIDIRECTIONAL STREAMS ARCHITECTURE > UNIDIRECTIONAL API > With the unidirectional branch, Minq offers two APIs. The first is a > straightforward mapping of PR#720, in which we have two objects: > > SendStream -- used for writing > RecvStream -- used for reading > > As before, we have a handler object, but it's directional now: > > type ConnectionHandler interface { > // The connection has changed state to state |s| > StateChanged(s State) > > // A new receiving stream has been created (by receiving a frame > // from the other side. |s| contains the stream. > NewRecvStream(s *RecvStream) > > // Stream |s| is now readable. > StreamReadable(s *RecvStream) > } > > Obviously SendStreams are locally created and RecvStreams are remotely > created. SendStreams can be created using > Connection.CreateSendStream() and you learn about remotely created > RecvStreams by a callback to ConnectionHandler.NewRecvStream(). > Second-created streams can be marked as "related" to a single > first-created stream, using Connection.CreateRelatedSendStream() with > the appropriate RecvStream as the argument [3]. Streams have a > Related() API to tell you if they are related to some other stream. > > The {Send,Recv}Stream APIs are about what you'd expect. You can > Write() on SendStream and Read() on RecvStream(). Right now, you can > Close() and Reset() SendStreams, but not do anything on RecvStreams() > or than ignore them. Eventually I'll probably offer > RecvStream().Mute() or something to let you send STOP_SENDING. > > > BIDIRECTIONAL API > Minq also includes a bidirectional API that's layered on top of > unidirectional streams. I've created a Connection2 structure that's > intended as a wrapper around Connection [4]: > > type Connection2 struct { > Connection > shim *connection2ShimHandler > streams []*Stream // Odd for client originated, even for server. > } > > type Stream struct { > id uint32 > send *SendStream > recv *RecvStream > } > > Basically, Stream is just a pair of SendStream and RecvStream and > Connection2 does the bookkeeping to keep them connected (I even do the > odd/even ID thing that QUIC-05 has). Connection2 has the same handler > API as Minq for QUIC-05, and the shim is responsible for translating > unidirectional events into bidirectional events. > > Internally, what's going on here is that when you call CreateStream() > Minq creates a Stream with a nil RecvStream. When a new remote stream > is detected, we check RecvStream.Related(). If they are related to an > existing SendStream then we will in the relevant |Stream.send| slot. > Otherwise, we create a new SendStream that's related to the incoming > stream and notify the application of the creation of the new > bidirectional stream. > > Note that this all works fine if one side does the undirectional API > and one does the bidirectional API. My test programs actually exercise > this. Of course, there's an assumption that the peer conforms to a 1:1 > mapping. If we define unidirectional streams, we'll need some protocol > mechanism to know if the other side is exercising this level of > increased flexibility or not. I can imagine a number of options here > (e.g., ALPN). We could also forbid 1:N mappings but I think that > would be a mistake as it's a cool feature/benefit of doing > unidirectional. > > The entire bidirectional wrapper shim is < 150 lines of Go code. > (https://github.com/ekr/minq/blob/unidirectional_streams/bidi.go). > Converting my test application to this API was a matter of just > changing class names, e.g., s/Connectionb/Connection2/. > > In my implementation, I assume that at the time Minq hears about a > stream, you know if its related to a given existing stream. That way > you can immediately either associate it with that stream or make a new > local stream. In my implementation, I always send Related Stream Id > and assume that you never get an "unrelated" stream frame before a > "related" one. The spec doesn't really require that right now, and > offline MT suggested just sending related with offset=3D0 but I think > that's a mistake, because it means that you need to hold stream frames > in some provisional "undetermined" state until you get that frame. I > would suggest instead that we require that you include the field until > one of the frames is ACKed. > > > INTERNALS > Sending and receiving streams still share a lot of common components: > > type baseStream struct { > state streamState > id uint32 > log loggingFunction > offset uint64 > chunks []streamChunk > maxStreamData uint64 > isRelated bool > related uint32 > } > > type sendStream struct { > baseStream > blocked bool > } > > type recvStream struct { > baseStream > } > > Most of this is the same as with bidirectional streams. As above, > it's probably possible to make them more asymmetrical. > > The connection maintains separate lists of sending and receiving > streams and it's straightforward to create and access them without > worrying about the odd/even stuff. > > > COMPARISON > At the end of the day, I think this shows that these designs aren't > really that disssimilar. I was able to convert Minq to unidirectional > streams in about 16 total hours of work (basically a long plane flight > plus the next morning). While I had to make a bunch of changes to the > internal structures, basically none of them modified anything tricky, > and in particular the flow control mechanics and the like are > basically unchanged, except for a bunch of mechanical-type > transformations like referring to |sendStream.chunks| instead of > |stream.send.chunks|. The only really new protocol machinery is the > new frame format for related streams. > > There are a few pros/cons that are worth noting about these designs. > > - Without a bidirectional API, having unidirectional streams is more > work for the programmer. However, with an API shim, the difference > is trivial. > > - Because undirectional streams are inherently more flexible, it's > possible for the sides to try to use different mappings, e.g., one > side expects paired and the other expects 1:N. We'll need some way > of making sure that doesn't happen, maybe ALPN? > > - The "Related Stream ID" frame indicator needs fleshing out a bit. > From the application's perspective, it should never hear about a > stream without knowing its related status. And as noted above, I > think it would be best if we required that all "first flight" stream > frames that are related include the fied > > - Undirectional streams kind of sharpen the confusion about exactly > what kinds of "closure" we want to allow. Specifically, what should > implementations be able to say about their willingness to receive? > Right now we have STOP_SENDING, but that doesn't influence the > sender's state. I don't think undirectional streams make this worse, > they just require us to think it through some more. They do simplify > the implementation of the closure state machine: in my QUIC-05 code, > whenever one side closes I have to have checks to see if I should be > transitioning to CLOSED or HALF-CLOSED, etc, which is odd because > the directions are basically independent. It would probably be > easier even in QUIC-05 not to reify these states but just to > determine the state from the composition of the individual > sub-states > > - Unidirectional streams don't need the kind of annoying odd-even > mechanics, which was easier to code up (just having to create all > the lower-numbered streams of the same parity is kind of a pain). > One additional benefit here is that with QUIC-05 there are several > messages which involve implicit stream creation (e.g., > STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether > the stream is one that should have been created locally or > remotely. This just doesn't happen with bidirectional streams; I do > implement odd/even mechanics but because the other side has to have > its stream ids increment by one, I can make sure that they have the > right IDs by construction and just check to see if the stream exists > in these cases. I'd like to see us get rid of odd/even no matter > what. > > - Unidirectional streams also helps avoid some of the corner cases around > bidirectional streams. Specifically, suppose I am the client and > I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed > to just start sending or not? You can sort of get into this situation > with unidirectional streams, but because it's explicit, one might > hope that the application semantics would require clear specification. > > - As noted above, bidirectional streams are more flexible because they > let you have mappings that you can't have with unidirectional > streams (unpaired, 1:N). > > > Happy to answer more questions if people have them. Otherwise we can > talk about this in Seattle. > > -Ekr > > > [0] https://github.com/ekr/minq/tree/unidirectional_streams > [1] https://github.com/ekr/wg-materials/blob/ > 404898fa2d2f0a9f9bd244d2c945e66ea88502a2/interim-17-10/ > Unidirectional%20Streams%20in%20Minq.pdf > [2] Thanks to Patrick McManus for suggesting this design. > [3] In C++, you would have a single function with a default argument of > |nullptr| but Go doesn't support that, hence two different arguments. > [4] For implementation reasons, it's actually using Connection as a mixin= , > which means it's simultaneously possible to use the unidirectional > and bidirectional APIs, but that's going to cause a lot of confusion. > A real implementation would probably have to either commit to one > or the other or do a real wrapper, so you could only use one set of > APIs, at the cost of having to do more forwarded methods. > > > > > > > > > > > --089e0828b4f0fa9630055a8298be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm not sure I have any useful insights on this, as my= implementation handles them more or less the same. Can you explain why you= think this would be different with unidirectional versus bidirectional?
-Ekr

=
On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn= =C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Thanks,

I only skimmed this superfast, but one the observati= ons appear to not cover one of my key points:

You ca= n create and close uni-streams at at very high rate of many streams per pac= ket, without waiting for peer response, assuming the ACK framework handles = retransmission. Any insights on this?

Kind Regar= ds,
Mikkel F= ahn=C3=B8e J=C3=B8rgensen


On 1 October 2017 at 22.32.02, = Eric Rescorla (ekr@rtfm.c= om) wrote:

Hi folks,

As promised I spent a bunch of time hacking unidirectional streams
into Minq and I'm here to report back [0]. Specifically, I
implemented:

=C2=A0 - PR#643 -- Unidirectional Streams
=C2=A0 - PR#720 -- Add bidirectional streams on top of unidirectional
=C2=A0 - A bidirectional stream API that mostly mimics Minq's original API
=C2=A0 =C2=A0 for -05.
=C2=A0 =C2=A0=C2=A0
The following is kind of a wall of text, so you could also skip this
and refer to my slides [1].


MINQ'S -05 ARCHITECTURE
API
Minq's master object is the Connection, which has a list of Streams
indexed by stream ID. Applications register a handler with the
connection to be notified of new events.

=C2=A0 =C2=A0type ConnectionHandler interface {
=C2=A0 =C2=A0 // The connection has changed state to state |s|
=C2=A0 =C2=A0 StateChanged(s State)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // A new stream has been created (by receiving a frame
=C2=A0 =C2=A0 // from the other side. |s| contains the stream.
=C2=A0 =C2=A0 NewStream(s *Stream)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // Stream |s| is now readable.
=C2=A0 =C2=A0 StreamReadable(s *Stream)
=C2=A0 =C2=A0}

Streams get created in two ways:

- Locally via Connection.CreateStream()
- Remotely, in which case the application is notified via a callback to
=C2=A0 ConnectionHandler.NewStream().

Streams themselves have the APIs you would expect, namely, Read(),
Write(), Close(), Reset(), etc. You get notified of stream readability
by a callback to ConnectionHandler.StreamReadable(), at which point
you can do Stream.Read(). As expected, Stream.Read() returns
WOULDBLOCK when no data ia available


INTERNALS
As noted above, we start with the Connection object (only relevant fields
shown):

=C2=A0 =C2=A0type Connection struct {
=C2=A0 =C2=A0 handler=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ConnectionHandler
=C2=A0 =C2=A0 streams=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 []*Stream
=C2=A0 =C2=A0 maxStream=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
outputClearQ=C2=A0 =C2=A0 =C2=A0[]frame // For stream 0
outputProtectedQ []frame // For stream >=3D 0
=C2=A0 =C2=A0}

As you can see, streams are in an array slice, so they're contiguously
indexed by stream ID. Right now, I have no provision for reclaiming
the unused bottom part of the array, but it would be straightforward
to index by |streamId| - |minStream|, which I think is consistent with
the design implied by the requirement to create streams in sequence.

Because Streams are bidirectional, each stream actually consists of a
pair of half streams.

=C2=A0 =C2=A0type streamHalf struct {
=C2=A0 =C2=A0 s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// pointer to parent
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggingFunction=C2=A0 =C2=A0
=C2=A0 =C2=A0 dir=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0direction=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Sending or receiving
=C2=A0 =C2=A0 closed=C2=A0 =C2=A0 =C2=A0 =C2=A0 bool=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Is the half-stream closed
=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // The
=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []streamChunk
=C2=A0 =C2=A0 maxStreamData uint64
=C2=A0 =C2=A0}

=C2=A0 =C2=A0// Internal object to allow unit testing.
=C2=A0 =C2=A0type stream struct {
=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 loggingFunction
=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 streamState
=C2=A0 =C2=A0 send, recv *streamHalf
=C2=A0 blocked=C2=A0 =C2=A0 bool // Have we returned blocked
=C2=A0 =C2=A0}

=C2=A0 =C2=A0// Public API object, which needs access to the Connection
=C2=A0 =C2=A0type Stream struct {
=C2=A0 =C2=A0 c *Connection
=C2=A0 =C2=A0 stream
=C2=A0 =C2=A0}

Outgoing data is enqueued into |stream.chunks|, and then periodically
the connection polls the stream for all the chunks which are permitted
by stream-level flow control and enqueues them into
|Connection.outputClearQ| or |Connection.outputProtectedQ|. At this
point, the connection owns the data and is responsible for
transmitting it, subject to connection-level flow control, and
(presumably) congestion control once I have that implemented [2].

Incoming data gets queued (sorted) into |stream.chunks| for later
reassembly at the time when someone calls stream.read(). I'm not sure
I love this, because it means I don't have a good view of the incoming
queue size (which I'd need to account for separately), but it allowed
me to share data structures between incoming and outgoing, which
seemed kind of natural when I did it (this architecture is replicated
in the unidirectional streams design, but it's probably less natural
there).


UNIDIRECTIONAL STREAMS ARCHITECTURE
UNIDIRECTIONAL API
With the unidirectional branch, Minq offers two APIs. The first is a
straightforward mapping of PR#720, in which we have two objects:

=C2=A0 SendStream -- used for writing
=C2=A0 RecvStream -- used for reading

As before, we have a handler object, but it's directional now:

=C2=A0 =C2=A0type ConnectionHandler interface {
=C2=A0 =C2=A0 // The connection has changed state to state |s|
=C2=A0 =C2=A0 StateChanged(s State)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // A new receiving stream has been created (by receiving a frame
=C2=A0 =C2=A0 // from the other side. |s| contains the stream.
=C2=A0 =C2=A0 NewRecvStream(s *RecvStream)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // Stream |s| is now readable.
=C2=A0 =C2=A0 StreamReadable(s *RecvStream)
=C2=A0 =C2=A0}

Obviously SendStreams are locally created and RecvStreams are remotely
created. SendStreams can be created using
Connection.CreateSendStream() and you learn about remotely created
RecvStreams by a callback to ConnectionHandler.NewRecvStream().
Second-created streams can be marked as "related" to a single
first-created stream, using Connection.CreateRelatedSendStream() with
the appropriate RecvStream as the argument [3]. Streams have a
Related() API to tell you if they are related to some other stream.

The {Send,Recv}Stream APIs are about what you'd expect. You can
Write() on SendStream and Read() on RecvStream(). Right now, you can
Close() and Reset() SendStreams, but not do anything on RecvStreams()
or than ignore them. Eventually I'll probably offer
RecvStream().Mute() or something to let you send STOP_SENDING.


BIDIRECTIONAL API
Minq also includes a bidirectional API that's layered on top of
unidirectional streams. I've created a Connection2 structure that's
intended as a wrapper around Connection [4]:

=C2=A0 =C2=A0type Connection2 struct {
=C2=A0 =C2=A0 Connection
=C2=A0 =C2=A0 shim=C2=A0 =C2=A0 *connection2ShimHandler
=C2=A0 =C2=A0 streams []*Stream // Odd for client originated, even for server.
=C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0type Stream struct {
=C2=A0 =C2=A0 id=C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 send *SendStream
=C2=A0 =C2=A0 recv *RecvStream
=C2=A0 =C2=A0}

Basically, Stream is just a pair of SendStream and RecvStream and
Connection2 does the bookkeeping to keep them connected (I even do the
odd/even ID thing that QUIC-05 has). Connection2 has the same handler
API as Minq for QUIC-05, and the shim is responsible for translating
unidirectional events into bidirectional events.

Internally, what's going on here is that when you call CreateStream()
Minq creates a Stream with a nil RecvStream. When a new remote stream
is detected, we check RecvStream.Related(). If they are related to an
existing SendStream then we will in the relevant |Stream.send| slot.
Otherwise, we create a new SendStream that's related to the incoming
stream and notify the application of the creation of the new
bidirectional stream.

Note that this all works fine if one side does the undirectional API
and one does the bidirectional API. My test programs actually exercise
this. Of course, there's an assumption that the peer conforms to a 1:1
mapping. If we define unidirectional streams, we'll need some protocol
mechanism to know if the other side is exercising this level of
increased flexibility or not. I can imagine a number of options here
(e.g., ALPN).=C2=A0 We could also forbid 1:N mappings but I think that
would be a mistake as it's a cool feature/benefit of doing
unidirectional.

The entire bidirectional wrapper shim is < 150 lines of Go code.
Converting my test application to this API was a matter of just
changing class names, e.g., s/Connectionb/Connection2/.

In my implementation, I assume that at the time Minq hears about a
stream, you know if its related to a given existing stream.=C2=A0 That way
you can immediately either associate it with that stream or make a new
local stream. In my implementation, I always send Related Stream Id
and assume that you never get an "unrelated" stream frame before a
"related" one. The spec doesn't really require that righ= t now, and
offline MT suggested just sending related with offset=3D0 but I think
that's a mistake, because it means that you need to hold stream frames
in some provisional "undetermined" state until you get that frame. I
would suggest instead that we require that you include the field until
one of the frames is ACKed.
=C2=A0=C2=A0

INTERNALS
Sending and receiving streams still share a lot of common components:

=C2=A0 =C2=A0 type baseStream struct {
=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streamState
=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggingFunction
=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64
=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []streamChunk
=C2=A0 =C2=A0 maxStreamData uint64
=C2=A0 =C2=A0 isRelated=C2=A0 =C2=A0 =C2=A0bool
=C2=A0 =C2=A0 related=C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 type sendStream struct {
=C2=A0 =C2=A0 baseStream
=C2=A0 =C2=A0 blocked bool
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 type recvStream struct {
=C2=A0 =C2=A0 baseStream
=C2=A0 =C2=A0 }

Most of this is the same as with bidirectional streams.=C2=A0 As above,
it's probably possible to make them more asymmetrical.

The connection maintains separate lists of sending and receiving
streams and it's straightforward to create and access them without
worrying about the odd/even stuff.


COMPARISON
At the end of the day, I think this shows that these designs aren't
really that disssimilar. I was able to convert Minq to unidirectional
streams in about 16 total hours of work (basically a long plane flight
plus the next morning). While I had to make a bunch of changes to the
internal structures, basically none of them modified anything tricky,
and in particular the flow control mechanics and the like are
basically unchanged, except for a bunch of mechanical-type
transformations like referring to |sendStream.chunks| instead of
|stream.send.chunks|. The only really new protocol machinery is the
new frame format for related streams.

There are a few pros/cons that are worth noting about these designs.

- Without a bidirectional API, having unidirectional streams is more
=C2=A0 work for the programmer. However, with an API shim, the difference
=C2=A0 is trivial.

- Because undirectional streams are inherently more flexible, it's
=C2=A0 possible for the sides to try to use different mappings, e.g., one
=C2=A0 side expects paired and the other expects 1:N. We'll need some way
=C2=A0 of making sure that doesn't happen, maybe ALPN?

- The "Related Stream ID" frame indicator needs fleshing out= a bit.
=C2=A0 From the application's perspective, it should never hear about a
=C2=A0 stream without knowing its related status. And as noted above, I
=C2=A0 think it would be best if we required that all "first flight" stream
=C2=A0 frames that are related include the fied

- Undirectional streams kind of sharpen the confusion about exactly
=C2=A0 what kinds of "closure" we want to allow. Specificall= y, what should
=C2=A0 implementations be able to say about their willingness to receive?
=C2=A0 Right now we have STOP_SENDING, but that doesn't influence the
=C2=A0 sender's state. I don't think undirectional streams make this worse,
=C2=A0 they just require us to think it through some more. They do simplify
=C2=A0 the implementation of the closure state machine: in my QUIC-05 code,
=C2=A0 whenever one side closes I have to have checks to see if I should be
=C2=A0 transitioning to CLOSED or HALF-CLOSED, etc, which is odd because
=C2=A0 the directions are basically independent.=C2=A0 It would probably be
=C2=A0 easier even in QUIC-05 not to reify these states but just to
=C2=A0 determine the state from the composition of the individual
=C2=A0 sub-states
=C2=A0=C2=A0
- Unidirectional streams don't need the kind of annoying odd-even
=C2=A0 mechanics, which was easier to code up (just having to create all
=C2=A0 the lower-numbered streams of the same parity is kind of a pain).
=C2=A0 One additional benefit here is that with QUIC-05 there are several
=C2=A0 messages which involve implicit stream creation (e.g.,
=C2=A0 STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether
=C2=A0 the stream is one that should have been created locally or
=C2=A0 remotely. This just doesn't happen with bidirectional streams; I do
=C2=A0 implement odd/even mechanics but because the other side has to have
=C2=A0 its stream ids increment by one, I can make sure that they have the
=C2=A0 right IDs by construction and just check to see if the stream exists
=C2=A0 in these cases.=C2=A0 I'd like to see us get rid of odd/even no matter
=C2=A0 what.

- Unidirectional streams also helps avoid some of the corner cases around
=C2=A0 bidirectional streams. Specifically, suppose I am the client and
=C2=A0 I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed
=C2=A0 to just start sending or not? You can sort of get into this situation
=C2=A0 with unidirectional streams, but because it's explicit, one might
=C2=A0 hope that the application semantics would require clear specification.
=C2=A0=C2=A0
- As noted above, bidirectional streams are more flexible because they
=C2=A0 let you have mappings that you can't have with unidirectional
=C2=A0 streams (unpaired, 1:N).


Happy to answer more questions if people have them. Otherwise we can
talk about this in Seattle.

-Ekr


[2] Thanks to Patrick McManus for suggesting this design.
[3] In C++, you would have a single function with a default argument of
=C2=A0 =C2=A0 |nullptr| but Go doesn't support that, hence two different arguments.
[4] For implementation reasons, it's actually using Connection as a mixin,
=C2=A0 =C2=A0 which means it's simultaneously possible to use the unidirectional
=C2=A0 =C2=A0 and bidirectional APIs, but that's going to cause a lot of confusion.
=C2=A0 =C2=A0 A real implementation would probably have to either commit to one
=C2=A0 =C2=A0 or the other or do a real wrapper, so you could only use one set of
=C2=A0 =C2=A0 APIs, at the cost of having to do more forwarded methods.
=C2=A0 =C2=A0=C2=A0
=C2=A0=C2=A0









--089e0828b4f0fa9630055a8298be-- From nobody Sun Oct 1 14:19: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 05BBA133347 for ; Sun, 1 Oct 2017 14:19:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.031 X-Spam-Level: X-Spam-Status: No, score=-0.031 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, 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 QII0RZUGsqwC for ; Sun, 1 Oct 2017 14:19:29 -0700 (PDT) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0114.outbound.protection.outlook.com [104.47.36.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C6271331C2 for ; Sun, 1 Oct 2017 14:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UMPX8Y5rSpNnezrbhkyMtDOEeQVLmG+oFVezw41h3gI=; b=YQIIuBERoG/OrqA9PYxCM/zrTOZE57kKpOvriwucA7Swm38ofUTSWjOnFjexaPPm4I6NQQL8C/CQauqIHZe72jimBLxo8ozp0Vtt1hci2oLfbsPAcuWLLwZVWlYj33V1/gL6y+bZ2Zlq1WDpLZY692cEAgF4Gaauonc7pvK2jdo= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0174.namprd21.prod.outlook.com (10.173.52.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.98.3; Sun, 1 Oct 2017 21:19:26 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0122.000; Sun, 1 Oct 2017 21:19:27 +0000 From: Mike Bishop To: Eric Rescorla , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: IETF QUIC WG Subject: RE: Report on Unidirectional Streams in Minq Thread-Topic: Report on Unidirectional Streams in Minq Thread-Index: AQHTOvRa67AX08lqTkeBz6F3cSHDd6LPdJiAgAAG7ICAAANWQA== Date: Sun, 1 Oct 2017 21:19:26 +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: [2601:600:8080:5a28:ad4e:bf53:369c:11c1] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0174; 6:fvsAuTwQjdSEF5ajxumxhqriP8WU3POxc+lqSDodZSdVbR1k9Qw74njrzfmhPJWqJTLCDi65YHkhiFu/IQqEe2b/H4j1SFLIdfbqkIN8clNfNQyWp6EHwnt1ldfEV1stgsAFLS3YTTundxN2TlnRMZtg8kyo3nUQAWIJb0iVNWoxHpF5XgsfBv+EP89M3t+jWPHMzeX9dyJW2rtmdSWZMOxT3RyZGjeMe/FcgIMrgAEtkNptg6t0I43sYMMrEeLIvmv4dsYQRUTBHLorE0+/6Us1T7rZtzBv1HVhMrLpzNBqnALSUYsSUCwVeEXY2XzhkK9odNh33kbRkACVP7Wd9g==; 5:Qz8YF6UnqVJTv8sHHwTzdnGSFKCoPSJNMvOYGKdoHzT+F/ZPW/svzJ/5HuskglQt+jGkdkvaHTzGbFhhV0JwIJtRBz87KzZs9/WVIsmDPwBZg6dQLc9As4NiQv9x37v3gFbOm/CHqLIHpOxg1Z/s2g==; 24:+38K6wCoM2U3Qd+M7gZGO364HfQTbBfG3aEDzvy/tWk+J45p+NGfvYXiyZzc+lLClpAADPswUc3G77xIAGnHABl99AnTMZAhUczR5xkistQ=; 7:lFnajh5W8A8Rqdyv1otp4EjiDNMO/TjXyaoNRbd6P5XlXHizRcnxC290uTQWwEFNpTn7nGpKJpDJcTAtx9A6kSt+hYUPMswMytKj0Ce+hwoVnv9+v9CaeVi/2sNWrGs5wbI9g8AJTktmi8Ru+ZiBaunD9pSx958loE2Isj7ZDp6mUCN1JGn6z5pHcioJ2tH/jsfA86iAONtszYcBDOzKSygEcjklQX3A8tbUZW9BUgI= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 733ad836-a56f-4503-578c-08d5091218bb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR21MB0174; x-ms-traffictypediagnostic: MWHPR21MB0174: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; x-exchange-antispam-report-test: UriScan:(278428928389397)(166708455590820)(189930954265078)(219752817060721)(21748063052155)(148717330147763); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(10201501046)(12181511122)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0174; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0174; x-forefront-prvs: 0447DB1C71 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(47760400005)(24454002)(51444003)(377454003)(189002)(199003)(229853002)(86612001)(2950100002)(3280700002)(5660300001)(7696004)(101416001)(6116002)(6436002)(7736002)(478600001)(10290500003)(8676002)(81156014)(81166006)(4326008)(316002)(6246003)(8936002)(97736004)(3660700001)(561944003)(39060400002)(22452003)(2906002)(106356001)(68736007)(575784001)(86362001)(25786009)(105586002)(53946003)(10090500001)(8990500004)(55016002)(99286003)(9686003)(54356999)(53936002)(6306002)(54896002)(236005)(110136005)(102836003)(790700001)(14454004)(53546010)(33656002)(606006)(72206003)(19609705001)(50986999)(189998001)(2900100001)(6506006)(74316002)(966005)(76176999)(77096006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0174; H:MWHPR21MB0141.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_MWHPR21MB01417BDA5D8978FCAE6BDFBA877C0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Oct 2017 21:19:26.9441 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0174 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, 01 Oct 2017 21:19:34 -0000 --_000_MWHPR21MB01417BDA5D8978FCAE6BDFBA877C0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGUgZGlmZmVyZW5jZSBpcyBmb3IgdGhlIHNjZW5hcmlvIHdoZXJlIHlvdSBkb27i gJl0IGV4cGVjdCBhIHBlZXIgdG8gcmVzcG9uZCAob3IgZG9u4oCZdCBleHBlY3QgdGhlbSB0byBy ZXNwb25kIHN0cmVhbS1ieS1zdHJlYW0pLiAgV2l0aCAtMDUsIHRoZSByZWNlaXZlciBzdGlsbCBu ZWVkcyB0byBzZW5kIFNUUkVBTShvZmZzZXQ9MCxGSU4pIG9uIGVhY2ggc3RyZWFtLiAgV2l0aCBl aXRoZXIgdW5pZGlyZWN0aW9uYWwgcHJvcG9zYWwsIHRoaXMgcGF0dGVybiBpcyBhIGJpdCBjbGVh bmVyLiAgSW4gIzY1NiwgdGhlIHNlbmRlciBjYW4gZXNzZW50aWFsbHkgc2F5LCDigJxEb27igJl0 IGJvdGhlcuKAnSBhdCB0aGUgdGltZSBvZiBzdHJlYW0gY3JlYXRpb24uICBJbiAjNjQzLCB0aGVy ZeKAmXMgbm8gY29ycmVzcG9uZGluZyBjaGFubmVsIHRvIGNsb3NlLg0KDQpJbiBhbGwgY2FzZXMs IHRoZSBvbmx5IHRoaW5nIHRoYXQgcmVhbGx5IGxpbWl0cyB5b3UgaXMgdGhlIHBlZXLigJlzIHdp bGxpbmduZXNzIHRvIGluY3JlYXNlIHlvdXIgTUFYX1NUUkVBTV9JRCwgaXTigJlzIGp1c3QgYSBx dWVzdGlvbiBvZiBob3cgY2hhdHR5IHlvdSBoYXZlIHRvIGJlIOKAkyB3aGljaCBjYW4gbWF0dGVy IGlmIHRoZXNlIG1lc3NhZ2VzIGFyZSBmYWlybHkgc21hbGwuDQoNCkZyb206IFFVSUMgW21haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpTZW50 OiBTdW5kYXksIE9jdG9iZXIgMSwgMjAxNyAyOjAzIFBNDQpUbzogTWlra2VsIEZhaG7DuGUgSsO4 cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPg0KQ2M6IElFVEYgUVVJQyBXRyA8cXVpY0BpZXRm Lm9yZz4NClN1YmplY3Q6IFJlOiBSZXBvcnQgb24gVW5pZGlyZWN0aW9uYWwgU3RyZWFtcyBpbiBN aW5xDQoNCkknbSBub3Qgc3VyZSBJIGhhdmUgYW55IHVzZWZ1bCBpbnNpZ2h0cyBvbiB0aGlzLCBh cyBteSBpbXBsZW1lbnRhdGlvbiBoYW5kbGVzIHRoZW0gbW9yZSBvciBsZXNzIHRoZSBzYW1lLiBD YW4geW91IGV4cGxhaW4gd2h5IHlvdSB0aGluayB0aGlzIHdvdWxkIGJlIGRpZmZlcmVudCB3aXRo IHVuaWRpcmVjdGlvbmFsIHZlcnN1cyBiaWRpcmVjdGlvbmFsPw0KDQotRWtyDQoNCg0KT24gU3Vu LCBPY3QgMSwgMjAxNyBhdCAxOjM4IFBNLCBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtr ZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhhbmtz LA0KDQpJIG9ubHkgc2tpbW1lZCB0aGlzIHN1cGVyZmFzdCwgYnV0IG9uZSB0aGUgb2JzZXJ2YXRp b25zIGFwcGVhciB0byBub3QgY292ZXIgb25lIG9mIG15IGtleSBwb2ludHM6DQoNCllvdSBjYW4g Y3JlYXRlIGFuZCBjbG9zZSB1bmktc3RyZWFtcyBhdCBhdCB2ZXJ5IGhpZ2ggcmF0ZSBvZiBtYW55 IHN0cmVhbXMgcGVyIHBhY2tldCwgd2l0aG91dCB3YWl0aW5nIGZvciBwZWVyIHJlc3BvbnNlLCBh c3N1bWluZyB0aGUgQUNLIGZyYW1ld29yayBoYW5kbGVzIHJldHJhbnNtaXNzaW9uLiBBbnkgaW5z aWdodHMgb24gdGhpcz8NCg0KS2luZCBSZWdhcmRzLA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNl bg0KDQoNCk9uIDEgT2N0b2JlciAyMDE3IGF0IDIyLjMyLjAyLCBFcmljIFJlc2NvcmxhIChla3JA cnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNvbT4pIHdyb3RlOg0KSGkgZm9sa3MsDQoNCkFzIHBy b21pc2VkIEkgc3BlbnQgYSBidW5jaCBvZiB0aW1lIGhhY2tpbmcgdW5pZGlyZWN0aW9uYWwgc3Ry ZWFtcw0KaW50byBNaW5xIGFuZCBJJ20gaGVyZSB0byByZXBvcnQgYmFjayBbMF0uIFNwZWNpZmlj YWxseSwgSQ0KaW1wbGVtZW50ZWQ6DQoNCiAgLSBQUiM2NDMgLS0gVW5pZGlyZWN0aW9uYWwgU3Ry ZWFtcw0KICAtIFBSIzcyMCAtLSBBZGQgYmlkaXJlY3Rpb25hbCBzdHJlYW1zIG9uIHRvcCBvZiB1 bmlkaXJlY3Rpb25hbA0KICAtIEEgYmlkaXJlY3Rpb25hbCBzdHJlYW0gQVBJIHRoYXQgbW9zdGx5 IG1pbWljcyBNaW5xJ3Mgb3JpZ2luYWwgQVBJDQogICAgZm9yIC0wNS4NCg0KVGhlIGZvbGxvd2lu ZyBpcyBraW5kIG9mIGEgd2FsbCBvZiB0ZXh0LCBzbyB5b3UgY291bGQgYWxzbyBza2lwIHRoaXMN CmFuZCByZWZlciB0byBteSBzbGlkZXMgWzFdLg0KDQoNCk1JTlEnUyAtMDUgQVJDSElURUNUVVJF DQpBUEkNCk1pbnEncyBtYXN0ZXIgb2JqZWN0IGlzIHRoZSBDb25uZWN0aW9uLCB3aGljaCBoYXMg YSBsaXN0IG9mIFN0cmVhbXMNCmluZGV4ZWQgYnkgc3RyZWFtIElELiBBcHBsaWNhdGlvbnMgcmVn aXN0ZXIgYSBoYW5kbGVyIHdpdGggdGhlDQpjb25uZWN0aW9uIHRvIGJlIG5vdGlmaWVkIG9mIG5l dyBldmVudHMuDQoNCiAgIHR5cGUgQ29ubmVjdGlvbkhhbmRsZXIgaW50ZXJmYWNlIHsNCiAgICAv LyBUaGUgY29ubmVjdGlvbiBoYXMgY2hhbmdlZCBzdGF0ZSB0byBzdGF0ZSB8c3wNCiAgICBTdGF0 ZUNoYW5nZWQocyBTdGF0ZSkNCg0KICAgIC8vIEEgbmV3IHN0cmVhbSBoYXMgYmVlbiBjcmVhdGVk IChieSByZWNlaXZpbmcgYSBmcmFtZQ0KICAgIC8vIGZyb20gdGhlIG90aGVyIHNpZGUuIHxzfCBj b250YWlucyB0aGUgc3RyZWFtLg0KICAgIE5ld1N0cmVhbShzICpTdHJlYW0pDQoNCiAgICAvLyBT dHJlYW0gfHN8IGlzIG5vdyByZWFkYWJsZS4NCiAgICBTdHJlYW1SZWFkYWJsZShzICpTdHJlYW0p DQogICB9DQoNClN0cmVhbXMgZ2V0IGNyZWF0ZWQgaW4gdHdvIHdheXM6DQoNCi0gTG9jYWxseSB2 aWEgQ29ubmVjdGlvbi5DcmVhdGVTdHJlYW0oKQ0KLSBSZW1vdGVseSwgaW4gd2hpY2ggY2FzZSB0 aGUgYXBwbGljYXRpb24gaXMgbm90aWZpZWQgdmlhIGEgY2FsbGJhY2sgdG8NCiAgQ29ubmVjdGlv bkhhbmRsZXIuTmV3U3RyZWFtKCkuDQoNClN0cmVhbXMgdGhlbXNlbHZlcyBoYXZlIHRoZSBBUElz IHlvdSB3b3VsZCBleHBlY3QsIG5hbWVseSwgUmVhZCgpLA0KV3JpdGUoKSwgQ2xvc2UoKSwgUmVz ZXQoKSwgZXRjLiBZb3UgZ2V0IG5vdGlmaWVkIG9mIHN0cmVhbSByZWFkYWJpbGl0eQ0KYnkgYSBj YWxsYmFjayB0byBDb25uZWN0aW9uSGFuZGxlci5TdHJlYW1SZWFkYWJsZSgpLCBhdCB3aGljaCBw b2ludA0KeW91IGNhbiBkbyBTdHJlYW0uUmVhZCgpLiBBcyBleHBlY3RlZCwgU3RyZWFtLlJlYWQo KSByZXR1cm5zDQpXT1VMREJMT0NLIHdoZW4gbm8gZGF0YSBpYSBhdmFpbGFibGUNCg0KDQpJTlRF Uk5BTFMNCkFzIG5vdGVkIGFib3ZlLCB3ZSBzdGFydCB3aXRoIHRoZSBDb25uZWN0aW9uIG9iamVj dCAob25seSByZWxldmFudCBmaWVsZHMNCnNob3duKToNCg0KICAgdHlwZSBDb25uZWN0aW9uIHN0 cnVjdCB7DQogICAgaGFuZGxlciAgICAgICAgICBDb25uZWN0aW9uSGFuZGxlcg0KICAgIHN0cmVh bXMgICAgICAgICAgW10qU3RyZWFtDQogICAgbWF4U3RyZWFtICAgICAgICB1aW50MzINCm91dHB1 dENsZWFyUSAgICAgW11mcmFtZSAvLyBGb3Igc3RyZWFtIDANCm91dHB1dFByb3RlY3RlZFEgW11m cmFtZSAvLyBGb3Igc3RyZWFtID49IDANCiAgIH0NCg0KQXMgeW91IGNhbiBzZWUsIHN0cmVhbXMg YXJlIGluIGFuIGFycmF5IHNsaWNlLCBzbyB0aGV5J3JlIGNvbnRpZ3VvdXNseQ0KaW5kZXhlZCBi eSBzdHJlYW0gSUQuIFJpZ2h0IG5vdywgSSBoYXZlIG5vIHByb3Zpc2lvbiBmb3IgcmVjbGFpbWlu Zw0KdGhlIHVudXNlZCBib3R0b20gcGFydCBvZiB0aGUgYXJyYXksIGJ1dCBpdCB3b3VsZCBiZSBz dHJhaWdodGZvcndhcmQNCnRvIGluZGV4IGJ5IHxzdHJlYW1JZHwgLSB8bWluU3RyZWFtfCwgd2hp Y2ggSSB0aGluayBpcyBjb25zaXN0ZW50IHdpdGgNCnRoZSBkZXNpZ24gaW1wbGllZCBieSB0aGUg cmVxdWlyZW1lbnQgdG8gY3JlYXRlIHN0cmVhbXMgaW4gc2VxdWVuY2UuDQoNCkJlY2F1c2UgU3Ry ZWFtcyBhcmUgYmlkaXJlY3Rpb25hbCwgZWFjaCBzdHJlYW0gYWN0dWFsbHkgY29uc2lzdHMgb2Yg YQ0KcGFpciBvZiBoYWxmIHN0cmVhbXMuDQoNCiAgIHR5cGUgc3RyZWFtSGFsZiBzdHJ1Y3Qgew0K ICAgIHMgICAgICAgICAgICAgKnN0cmVhbSAgICAgICAgICAgLy8gcG9pbnRlciB0byBwYXJlbnQN CiAgICBsb2cgICAgICAgICAgIGxvZ2dpbmdGdW5jdGlvbg0KICAgIGRpciAgICAgICAgICAgZGly ZWN0aW9uICAgICAgICAgLy8gU2VuZGluZyBvciByZWNlaXZpbmcNCiAgICBjbG9zZWQgICAgICAg IGJvb2wgICAgICAgICAgICAgIC8vIElzIHRoZSBoYWxmLXN0cmVhbSBjbG9zZWQNCiAgICBvZmZz ZXQgICAgICAgIHVpbnQ2NCAgICAgICAgICAgIC8vIFRoZQ0KICAgIGNodW5rcyAgICAgICAgW11z dHJlYW1DaHVuaw0KICAgIG1heFN0cmVhbURhdGEgdWludDY0DQogICB9DQoNCiAgIC8vIEludGVy bmFsIG9iamVjdCB0byBhbGxvdyB1bml0IHRlc3RpbmcuDQogICB0eXBlIHN0cmVhbSBzdHJ1Y3Qg ew0KICAgIGlkICAgICAgICAgdWludDMyDQogICAgbG9nICAgICAgICBsb2dnaW5nRnVuY3Rpb24N CiAgICBzdGF0ZSAgICAgIHN0cmVhbVN0YXRlDQogICAgc2VuZCwgcmVjdiAqc3RyZWFtSGFsZg0K ICBibG9ja2VkICAgIGJvb2wgLy8gSGF2ZSB3ZSByZXR1cm5lZCBibG9ja2VkDQogICB9DQoNCiAg IC8vIFB1YmxpYyBBUEkgb2JqZWN0LCB3aGljaCBuZWVkcyBhY2Nlc3MgdG8gdGhlIENvbm5lY3Rp b24NCiAgIHR5cGUgU3RyZWFtIHN0cnVjdCB7DQogICAgYyAqQ29ubmVjdGlvbg0KICAgIHN0cmVh bQ0KICAgfQ0KDQpPdXRnb2luZyBkYXRhIGlzIGVucXVldWVkIGludG8gfHN0cmVhbS5jaHVua3N8 LCBhbmQgdGhlbiBwZXJpb2RpY2FsbHkNCnRoZSBjb25uZWN0aW9uIHBvbGxzIHRoZSBzdHJlYW0g Zm9yIGFsbCB0aGUgY2h1bmtzIHdoaWNoIGFyZSBwZXJtaXR0ZWQNCmJ5IHN0cmVhbS1sZXZlbCBm bG93IGNvbnRyb2wgYW5kIGVucXVldWVzIHRoZW0gaW50bw0KfENvbm5lY3Rpb24ub3V0cHV0Q2xl YXJRfCBvciB8Q29ubmVjdGlvbi5vdXRwdXRQcm90ZWN0ZWRRfC4gQXQgdGhpcw0KcG9pbnQsIHRo ZSBjb25uZWN0aW9uIG93bnMgdGhlIGRhdGEgYW5kIGlzIHJlc3BvbnNpYmxlIGZvcg0KdHJhbnNt aXR0aW5nIGl0LCBzdWJqZWN0IHRvIGNvbm5lY3Rpb24tbGV2ZWwgZmxvdyBjb250cm9sLCBhbmQN CihwcmVzdW1hYmx5KSBjb25nZXN0aW9uIGNvbnRyb2wgb25jZSBJIGhhdmUgdGhhdCBpbXBsZW1l bnRlZCBbMl0uDQoNCkluY29taW5nIGRhdGEgZ2V0cyBxdWV1ZWQgKHNvcnRlZCkgaW50byB8c3Ry ZWFtLmNodW5rc3wgZm9yIGxhdGVyDQpyZWFzc2VtYmx5IGF0IHRoZSB0aW1lIHdoZW4gc29tZW9u ZSBjYWxscyBzdHJlYW0ucmVhZCgpLiBJJ20gbm90IHN1cmUNCkkgbG92ZSB0aGlzLCBiZWNhdXNl IGl0IG1lYW5zIEkgZG9uJ3QgaGF2ZSBhIGdvb2QgdmlldyBvZiB0aGUgaW5jb21pbmcNCnF1ZXVl IHNpemUgKHdoaWNoIEknZCBuZWVkIHRvIGFjY291bnQgZm9yIHNlcGFyYXRlbHkpLCBidXQgaXQg YWxsb3dlZA0KbWUgdG8gc2hhcmUgZGF0YSBzdHJ1Y3R1cmVzIGJldHdlZW4gaW5jb21pbmcgYW5k IG91dGdvaW5nLCB3aGljaA0Kc2VlbWVkIGtpbmQgb2YgbmF0dXJhbCB3aGVuIEkgZGlkIGl0ICh0 aGlzIGFyY2hpdGVjdHVyZSBpcyByZXBsaWNhdGVkDQppbiB0aGUgdW5pZGlyZWN0aW9uYWwgc3Ry ZWFtcyBkZXNpZ24sIGJ1dCBpdCdzIHByb2JhYmx5IGxlc3MgbmF0dXJhbA0KdGhlcmUpLg0KDQoN ClVOSURJUkVDVElPTkFMIFNUUkVBTVMgQVJDSElURUNUVVJFDQpVTklESVJFQ1RJT05BTCBBUEkN CldpdGggdGhlIHVuaWRpcmVjdGlvbmFsIGJyYW5jaCwgTWlucSBvZmZlcnMgdHdvIEFQSXMuIFRo ZSBmaXJzdCBpcyBhDQpzdHJhaWdodGZvcndhcmQgbWFwcGluZyBvZiBQUiM3MjAsIGluIHdoaWNo IHdlIGhhdmUgdHdvIG9iamVjdHM6DQoNCiAgU2VuZFN0cmVhbSAtLSB1c2VkIGZvciB3cml0aW5n DQogIFJlY3ZTdHJlYW0gLS0gdXNlZCBmb3IgcmVhZGluZw0KDQpBcyBiZWZvcmUsIHdlIGhhdmUg YSBoYW5kbGVyIG9iamVjdCwgYnV0IGl0J3MgZGlyZWN0aW9uYWwgbm93Og0KDQogICB0eXBlIENv bm5lY3Rpb25IYW5kbGVyIGludGVyZmFjZSB7DQogICAgLy8gVGhlIGNvbm5lY3Rpb24gaGFzIGNo YW5nZWQgc3RhdGUgdG8gc3RhdGUgfHN8DQogICAgU3RhdGVDaGFuZ2VkKHMgU3RhdGUpDQoNCiAg ICAvLyBBIG5ldyByZWNlaXZpbmcgc3RyZWFtIGhhcyBiZWVuIGNyZWF0ZWQgKGJ5IHJlY2Vpdmlu ZyBhIGZyYW1lDQogICAgLy8gZnJvbSB0aGUgb3RoZXIgc2lkZS4gfHN8IGNvbnRhaW5zIHRoZSBz dHJlYW0uDQogICAgTmV3UmVjdlN0cmVhbShzICpSZWN2U3RyZWFtKQ0KDQogICAgLy8gU3RyZWFt IHxzfCBpcyBub3cgcmVhZGFibGUuDQogICAgU3RyZWFtUmVhZGFibGUocyAqUmVjdlN0cmVhbSkN CiAgIH0NCg0KT2J2aW91c2x5IFNlbmRTdHJlYW1zIGFyZSBsb2NhbGx5IGNyZWF0ZWQgYW5kIFJl Y3ZTdHJlYW1zIGFyZSByZW1vdGVseQ0KY3JlYXRlZC4gU2VuZFN0cmVhbXMgY2FuIGJlIGNyZWF0 ZWQgdXNpbmcNCkNvbm5lY3Rpb24uQ3JlYXRlU2VuZFN0cmVhbSgpIGFuZCB5b3UgbGVhcm4gYWJv dXQgcmVtb3RlbHkgY3JlYXRlZA0KUmVjdlN0cmVhbXMgYnkgYSBjYWxsYmFjayB0byBDb25uZWN0 aW9uSGFuZGxlci5OZXdSZWN2U3RyZWFtKCkuDQpTZWNvbmQtY3JlYXRlZCBzdHJlYW1zIGNhbiBi ZSBtYXJrZWQgYXMgInJlbGF0ZWQiIHRvIGEgc2luZ2xlDQpmaXJzdC1jcmVhdGVkIHN0cmVhbSwg dXNpbmcgQ29ubmVjdGlvbi5DcmVhdGVSZWxhdGVkU2VuZFN0cmVhbSgpIHdpdGgNCnRoZSBhcHBy b3ByaWF0ZSBSZWN2U3RyZWFtIGFzIHRoZSBhcmd1bWVudCBbM10uIFN0cmVhbXMgaGF2ZSBhDQpS ZWxhdGVkKCkgQVBJIHRvIHRlbGwgeW91IGlmIHRoZXkgYXJlIHJlbGF0ZWQgdG8gc29tZSBvdGhl ciBzdHJlYW0uDQoNClRoZSB7U2VuZCxSZWN2fVN0cmVhbSBBUElzIGFyZSBhYm91dCB3aGF0IHlv dSdkIGV4cGVjdC4gWW91IGNhbg0KV3JpdGUoKSBvbiBTZW5kU3RyZWFtIGFuZCBSZWFkKCkgb24g UmVjdlN0cmVhbSgpLiBSaWdodCBub3csIHlvdSBjYW4NCkNsb3NlKCkgYW5kIFJlc2V0KCkgU2Vu ZFN0cmVhbXMsIGJ1dCBub3QgZG8gYW55dGhpbmcgb24gUmVjdlN0cmVhbXMoKQ0Kb3IgdGhhbiBp Z25vcmUgdGhlbS4gRXZlbnR1YWxseSBJJ2xsIHByb2JhYmx5IG9mZmVyDQpSZWN2U3RyZWFtKCku TXV0ZSgpIG9yIHNvbWV0aGluZyB0byBsZXQgeW91IHNlbmQgU1RPUF9TRU5ESU5HLg0KDQoNCkJJ RElSRUNUSU9OQUwgQVBJDQpNaW5xIGFsc28gaW5jbHVkZXMgYSBiaWRpcmVjdGlvbmFsIEFQSSB0 aGF0J3MgbGF5ZXJlZCBvbiB0b3Agb2YNCnVuaWRpcmVjdGlvbmFsIHN0cmVhbXMuIEkndmUgY3Jl YXRlZCBhIENvbm5lY3Rpb24yIHN0cnVjdHVyZSB0aGF0J3MNCmludGVuZGVkIGFzIGEgd3JhcHBl ciBhcm91bmQgQ29ubmVjdGlvbiBbNF06DQoNCiAgIHR5cGUgQ29ubmVjdGlvbjIgc3RydWN0IHsN CiAgICBDb25uZWN0aW9uDQogICAgc2hpbSAgICAqY29ubmVjdGlvbjJTaGltSGFuZGxlcg0KICAg IHN0cmVhbXMgW10qU3RyZWFtIC8vIE9kZCBmb3IgY2xpZW50IG9yaWdpbmF0ZWQsIGV2ZW4gZm9y IHNlcnZlci4NCiAgIH0NCg0KICAgdHlwZSBTdHJlYW0gc3RydWN0IHsNCiAgICBpZCAgIHVpbnQz Mg0KICAgIHNlbmQgKlNlbmRTdHJlYW0NCiAgICByZWN2ICpSZWN2U3RyZWFtDQogICB9DQoNCkJh c2ljYWxseSwgU3RyZWFtIGlzIGp1c3QgYSBwYWlyIG9mIFNlbmRTdHJlYW0gYW5kIFJlY3ZTdHJl YW0gYW5kDQpDb25uZWN0aW9uMiBkb2VzIHRoZSBib29ra2VlcGluZyB0byBrZWVwIHRoZW0gY29u bmVjdGVkIChJIGV2ZW4gZG8gdGhlDQpvZGQvZXZlbiBJRCB0aGluZyB0aGF0IFFVSUMtMDUgaGFz KS4gQ29ubmVjdGlvbjIgaGFzIHRoZSBzYW1lIGhhbmRsZXINCkFQSSBhcyBNaW5xIGZvciBRVUlD LTA1LCBhbmQgdGhlIHNoaW0gaXMgcmVzcG9uc2libGUgZm9yIHRyYW5zbGF0aW5nDQp1bmlkaXJl Y3Rpb25hbCBldmVudHMgaW50byBiaWRpcmVjdGlvbmFsIGV2ZW50cy4NCg0KSW50ZXJuYWxseSwg d2hhdCdzIGdvaW5nIG9uIGhlcmUgaXMgdGhhdCB3aGVuIHlvdSBjYWxsIENyZWF0ZVN0cmVhbSgp DQpNaW5xIGNyZWF0ZXMgYSBTdHJlYW0gd2l0aCBhIG5pbCBSZWN2U3RyZWFtLiBXaGVuIGEgbmV3 IHJlbW90ZSBzdHJlYW0NCmlzIGRldGVjdGVkLCB3ZSBjaGVjayBSZWN2U3RyZWFtLlJlbGF0ZWQo KS4gSWYgdGhleSBhcmUgcmVsYXRlZCB0byBhbg0KZXhpc3RpbmcgU2VuZFN0cmVhbSB0aGVuIHdl IHdpbGwgaW4gdGhlIHJlbGV2YW50IHxTdHJlYW0uc2VuZHwgc2xvdC4NCk90aGVyd2lzZSwgd2Ug Y3JlYXRlIGEgbmV3IFNlbmRTdHJlYW0gdGhhdCdzIHJlbGF0ZWQgdG8gdGhlIGluY29taW5nDQpz dHJlYW0gYW5kIG5vdGlmeSB0aGUgYXBwbGljYXRpb24gb2YgdGhlIGNyZWF0aW9uIG9mIHRoZSBu ZXcNCmJpZGlyZWN0aW9uYWwgc3RyZWFtLg0KDQpOb3RlIHRoYXQgdGhpcyBhbGwgd29ya3MgZmlu ZSBpZiBvbmUgc2lkZSBkb2VzIHRoZSB1bmRpcmVjdGlvbmFsIEFQSQ0KYW5kIG9uZSBkb2VzIHRo ZSBiaWRpcmVjdGlvbmFsIEFQSS4gTXkgdGVzdCBwcm9ncmFtcyBhY3R1YWxseSBleGVyY2lzZQ0K dGhpcy4gT2YgY291cnNlLCB0aGVyZSdzIGFuIGFzc3VtcHRpb24gdGhhdCB0aGUgcGVlciBjb25m b3JtcyB0byBhIDE6MQ0KbWFwcGluZy4gSWYgd2UgZGVmaW5lIHVuaWRpcmVjdGlvbmFsIHN0cmVh bXMsIHdlJ2xsIG5lZWQgc29tZSBwcm90b2NvbA0KbWVjaGFuaXNtIHRvIGtub3cgaWYgdGhlIG90 aGVyIHNpZGUgaXMgZXhlcmNpc2luZyB0aGlzIGxldmVsIG9mDQppbmNyZWFzZWQgZmxleGliaWxp dHkgb3Igbm90LiBJIGNhbiBpbWFnaW5lIGEgbnVtYmVyIG9mIG9wdGlvbnMgaGVyZQ0KKGUuZy4s IEFMUE4pLiAgV2UgY291bGQgYWxzbyBmb3JiaWQgMTpOIG1hcHBpbmdzIGJ1dCBJIHRoaW5rIHRo YXQNCndvdWxkIGJlIGEgbWlzdGFrZSBhcyBpdCdzIGEgY29vbCBmZWF0dXJlL2JlbmVmaXQgb2Yg ZG9pbmcNCnVuaWRpcmVjdGlvbmFsLg0KDQpUaGUgZW50aXJlIGJpZGlyZWN0aW9uYWwgd3JhcHBl ciBzaGltIGlzIDwgMTUwIGxpbmVzIG9mIEdvIGNvZGUuDQooaHR0cHM6Ly9naXRodWIuY29tL2Vr ci9taW5xL2Jsb2IvdW5pZGlyZWN0aW9uYWxfc3RyZWFtcy9iaWRpLmdvPGh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHVi LmNvbSUyRmVrciUyRm1pbnElMkZibG9iJTJGdW5pZGlyZWN0aW9uYWxfc3RyZWFtcyUyRmJpZGku Z28mZGF0YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDMTRmMDc5 ODdkYTBkNGFmYjhlNzUwOGQ1MDkwZmY2ZjYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDEx ZGI0NyU3QzElN0MwJTdDNjM2NDI0ODg2NTQ2NDgxNzEwJnNkYXRhPXdwczlBV0syZmFhODNOOVIl MkJESG92aWclMkJ3ZjY4NFBTJTJCNVF3NURnellINUklM0QmcmVzZXJ2ZWQ9MD4pLg0KQ29udmVy dGluZyBteSB0ZXN0IGFwcGxpY2F0aW9uIHRvIHRoaXMgQVBJIHdhcyBhIG1hdHRlciBvZiBqdXN0 DQpjaGFuZ2luZyBjbGFzcyBuYW1lcywgZS5nLiwgcy9Db25uZWN0aW9uYi9Db25uZWN0aW9uMi8u DQoNCkluIG15IGltcGxlbWVudGF0aW9uLCBJIGFzc3VtZSB0aGF0IGF0IHRoZSB0aW1lIE1pbnEg aGVhcnMgYWJvdXQgYQ0Kc3RyZWFtLCB5b3Uga25vdyBpZiBpdHMgcmVsYXRlZCB0byBhIGdpdmVu IGV4aXN0aW5nIHN0cmVhbS4gIFRoYXQgd2F5DQp5b3UgY2FuIGltbWVkaWF0ZWx5IGVpdGhlciBh c3NvY2lhdGUgaXQgd2l0aCB0aGF0IHN0cmVhbSBvciBtYWtlIGEgbmV3DQpsb2NhbCBzdHJlYW0u IEluIG15IGltcGxlbWVudGF0aW9uLCBJIGFsd2F5cyBzZW5kIFJlbGF0ZWQgU3RyZWFtIElkDQph bmQgYXNzdW1lIHRoYXQgeW91IG5ldmVyIGdldCBhbiAidW5yZWxhdGVkIiBzdHJlYW0gZnJhbWUg YmVmb3JlIGENCiJyZWxhdGVkIiBvbmUuIFRoZSBzcGVjIGRvZXNuJ3QgcmVhbGx5IHJlcXVpcmUg dGhhdCByaWdodCBub3csIGFuZA0Kb2ZmbGluZSBNVCBzdWdnZXN0ZWQganVzdCBzZW5kaW5nIHJl bGF0ZWQgd2l0aCBvZmZzZXQ9MCBidXQgSSB0aGluaw0KdGhhdCdzIGEgbWlzdGFrZSwgYmVjYXVz ZSBpdCBtZWFucyB0aGF0IHlvdSBuZWVkIHRvIGhvbGQgc3RyZWFtIGZyYW1lcw0KaW4gc29tZSBw cm92aXNpb25hbCAidW5kZXRlcm1pbmVkIiBzdGF0ZSB1bnRpbCB5b3UgZ2V0IHRoYXQgZnJhbWUu IEkNCndvdWxkIHN1Z2dlc3QgaW5zdGVhZCB0aGF0IHdlIHJlcXVpcmUgdGhhdCB5b3UgaW5jbHVk ZSB0aGUgZmllbGQgdW50aWwNCm9uZSBvZiB0aGUgZnJhbWVzIGlzIEFDS2VkLg0KDQoNCklOVEVS TkFMUw0KU2VuZGluZyBhbmQgcmVjZWl2aW5nIHN0cmVhbXMgc3RpbGwgc2hhcmUgYSBsb3Qgb2Yg Y29tbW9uIGNvbXBvbmVudHM6DQoNCiAgICB0eXBlIGJhc2VTdHJlYW0gc3RydWN0IHsNCiAgICBz dGF0ZSAgICAgICAgIHN0cmVhbVN0YXRlDQogICAgaWQgICAgICAgICAgICB1aW50MzINCiAgICBs b2cgICAgICAgICAgIGxvZ2dpbmdGdW5jdGlvbg0KICAgIG9mZnNldCAgICAgICAgdWludDY0DQog ICAgY2h1bmtzICAgICAgICBbXXN0cmVhbUNodW5rDQogICAgbWF4U3RyZWFtRGF0YSB1aW50NjQN CiAgICBpc1JlbGF0ZWQgICAgIGJvb2wNCiAgICByZWxhdGVkICAgICAgIHVpbnQzMg0KICAgIH0N Cg0KICAgIHR5cGUgc2VuZFN0cmVhbSBzdHJ1Y3Qgew0KICAgIGJhc2VTdHJlYW0NCiAgICBibG9j a2VkIGJvb2wNCiAgICB9DQoNCiAgICB0eXBlIHJlY3ZTdHJlYW0gc3RydWN0IHsNCiAgICBiYXNl U3RyZWFtDQogICAgfQ0KDQpNb3N0IG9mIHRoaXMgaXMgdGhlIHNhbWUgYXMgd2l0aCBiaWRpcmVj dGlvbmFsIHN0cmVhbXMuICBBcyBhYm92ZSwNCml0J3MgcHJvYmFibHkgcG9zc2libGUgdG8gbWFr ZSB0aGVtIG1vcmUgYXN5bW1ldHJpY2FsLg0KDQpUaGUgY29ubmVjdGlvbiBtYWludGFpbnMgc2Vw YXJhdGUgbGlzdHMgb2Ygc2VuZGluZyBhbmQgcmVjZWl2aW5nDQpzdHJlYW1zIGFuZCBpdCdzIHN0 cmFpZ2h0Zm9yd2FyZCB0byBjcmVhdGUgYW5kIGFjY2VzcyB0aGVtIHdpdGhvdXQNCndvcnJ5aW5n IGFib3V0IHRoZSBvZGQvZXZlbiBzdHVmZi4NCg0KDQpDT01QQVJJU09ODQpBdCB0aGUgZW5kIG9m IHRoZSBkYXksIEkgdGhpbmsgdGhpcyBzaG93cyB0aGF0IHRoZXNlIGRlc2lnbnMgYXJlbid0DQpy ZWFsbHkgdGhhdCBkaXNzc2ltaWxhci4gSSB3YXMgYWJsZSB0byBjb252ZXJ0IE1pbnEgdG8gdW5p ZGlyZWN0aW9uYWwNCnN0cmVhbXMgaW4gYWJvdXQgMTYgdG90YWwgaG91cnMgb2Ygd29yayAoYmFz aWNhbGx5IGEgbG9uZyBwbGFuZSBmbGlnaHQNCnBsdXMgdGhlIG5leHQgbW9ybmluZykuIFdoaWxl IEkgaGFkIHRvIG1ha2UgYSBidW5jaCBvZiBjaGFuZ2VzIHRvIHRoZQ0KaW50ZXJuYWwgc3RydWN0 dXJlcywgYmFzaWNhbGx5IG5vbmUgb2YgdGhlbSBtb2RpZmllZCBhbnl0aGluZyB0cmlja3ksDQph bmQgaW4gcGFydGljdWxhciB0aGUgZmxvdyBjb250cm9sIG1lY2hhbmljcyBhbmQgdGhlIGxpa2Ug YXJlDQpiYXNpY2FsbHkgdW5jaGFuZ2VkLCBleGNlcHQgZm9yIGEgYnVuY2ggb2YgbWVjaGFuaWNh bC10eXBlDQp0cmFuc2Zvcm1hdGlvbnMgbGlrZSByZWZlcnJpbmcgdG8gfHNlbmRTdHJlYW0uY2h1 bmtzfCBpbnN0ZWFkIG9mDQp8c3RyZWFtLnNlbmQuY2h1bmtzfC4gVGhlIG9ubHkgcmVhbGx5IG5l dyBwcm90b2NvbCBtYWNoaW5lcnkgaXMgdGhlDQpuZXcgZnJhbWUgZm9ybWF0IGZvciByZWxhdGVk IHN0cmVhbXMuDQoNClRoZXJlIGFyZSBhIGZldyBwcm9zL2NvbnMgdGhhdCBhcmUgd29ydGggbm90 aW5nIGFib3V0IHRoZXNlIGRlc2lnbnMuDQoNCi0gV2l0aG91dCBhIGJpZGlyZWN0aW9uYWwgQVBJ LCBoYXZpbmcgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBpcyBtb3JlDQogIHdvcmsgZm9yIHRoZSBw cm9ncmFtbWVyLiBIb3dldmVyLCB3aXRoIGFuIEFQSSBzaGltLCB0aGUgZGlmZmVyZW5jZQ0KICBp cyB0cml2aWFsLg0KDQotIEJlY2F1c2UgdW5kaXJlY3Rpb25hbCBzdHJlYW1zIGFyZSBpbmhlcmVu dGx5IG1vcmUgZmxleGlibGUsIGl0J3MNCiAgcG9zc2libGUgZm9yIHRoZSBzaWRlcyB0byB0cnkg dG8gdXNlIGRpZmZlcmVudCBtYXBwaW5ncywgZS5nLiwgb25lDQogIHNpZGUgZXhwZWN0cyBwYWly ZWQgYW5kIHRoZSBvdGhlciBleHBlY3RzIDE6Ti4gV2UnbGwgbmVlZCBzb21lIHdheQ0KICBvZiBt YWtpbmcgc3VyZSB0aGF0IGRvZXNuJ3QgaGFwcGVuLCBtYXliZSBBTFBOPw0KDQotIFRoZSAiUmVs YXRlZCBTdHJlYW0gSUQiIGZyYW1lIGluZGljYXRvciBuZWVkcyBmbGVzaGluZyBvdXQgYSBiaXQu DQogIEZyb20gdGhlIGFwcGxpY2F0aW9uJ3MgcGVyc3BlY3RpdmUsIGl0IHNob3VsZCBuZXZlciBo ZWFyIGFib3V0IGENCiAgc3RyZWFtIHdpdGhvdXQga25vd2luZyBpdHMgcmVsYXRlZCBzdGF0dXMu IEFuZCBhcyBub3RlZCBhYm92ZSwgSQ0KICB0aGluayBpdCB3b3VsZCBiZSBiZXN0IGlmIHdlIHJl cXVpcmVkIHRoYXQgYWxsICJmaXJzdCBmbGlnaHQiIHN0cmVhbQ0KICBmcmFtZXMgdGhhdCBhcmUg cmVsYXRlZCBpbmNsdWRlIHRoZSBmaWVkDQoNCi0gVW5kaXJlY3Rpb25hbCBzdHJlYW1zIGtpbmQg b2Ygc2hhcnBlbiB0aGUgY29uZnVzaW9uIGFib3V0IGV4YWN0bHkNCiAgd2hhdCBraW5kcyBvZiAi Y2xvc3VyZSIgd2Ugd2FudCB0byBhbGxvdy4gU3BlY2lmaWNhbGx5LCB3aGF0IHNob3VsZA0KICBp bXBsZW1lbnRhdGlvbnMgYmUgYWJsZSB0byBzYXkgYWJvdXQgdGhlaXIgd2lsbGluZ25lc3MgdG8g cmVjZWl2ZT8NCiAgUmlnaHQgbm93IHdlIGhhdmUgU1RPUF9TRU5ESU5HLCBidXQgdGhhdCBkb2Vz bid0IGluZmx1ZW5jZSB0aGUNCiAgc2VuZGVyJ3Mgc3RhdGUuIEkgZG9uJ3QgdGhpbmsgdW5kaXJl Y3Rpb25hbCBzdHJlYW1zIG1ha2UgdGhpcyB3b3JzZSwNCiAgdGhleSBqdXN0IHJlcXVpcmUgdXMg dG8gdGhpbmsgaXQgdGhyb3VnaCBzb21lIG1vcmUuIFRoZXkgZG8gc2ltcGxpZnkNCiAgdGhlIGlt cGxlbWVudGF0aW9uIG9mIHRoZSBjbG9zdXJlIHN0YXRlIG1hY2hpbmU6IGluIG15IFFVSUMtMDUg Y29kZSwNCiAgd2hlbmV2ZXIgb25lIHNpZGUgY2xvc2VzIEkgaGF2ZSB0byBoYXZlIGNoZWNrcyB0 byBzZWUgaWYgSSBzaG91bGQgYmUNCiAgdHJhbnNpdGlvbmluZyB0byBDTE9TRUQgb3IgSEFMRi1D TE9TRUQsIGV0Yywgd2hpY2ggaXMgb2RkIGJlY2F1c2UNCiAgdGhlIGRpcmVjdGlvbnMgYXJlIGJh c2ljYWxseSBpbmRlcGVuZGVudC4gIEl0IHdvdWxkIHByb2JhYmx5IGJlDQogIGVhc2llciBldmVu IGluIFFVSUMtMDUgbm90IHRvIHJlaWZ5IHRoZXNlIHN0YXRlcyBidXQganVzdCB0bw0KICBkZXRl cm1pbmUgdGhlIHN0YXRlIGZyb20gdGhlIGNvbXBvc2l0aW9uIG9mIHRoZSBpbmRpdmlkdWFsDQog IHN1Yi1zdGF0ZXMNCg0KLSBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIGRvbid0IG5lZWQgdGhlIGtp bmQgb2YgYW5ub3lpbmcgb2RkLWV2ZW4NCiAgbWVjaGFuaWNzLCB3aGljaCB3YXMgZWFzaWVyIHRv IGNvZGUgdXAgKGp1c3QgaGF2aW5nIHRvIGNyZWF0ZSBhbGwNCiAgdGhlIGxvd2VyLW51bWJlcmVk IHN0cmVhbXMgb2YgdGhlIHNhbWUgcGFyaXR5IGlzIGtpbmQgb2YgYSBwYWluKS4NCiAgT25lIGFk ZGl0aW9uYWwgYmVuZWZpdCBoZXJlIGlzIHRoYXQgd2l0aCBRVUlDLTA1IHRoZXJlIGFyZSBzZXZl cmFsDQogIG1lc3NhZ2VzIHdoaWNoIGludm9sdmUgaW1wbGljaXQgc3RyZWFtIGNyZWF0aW9uIChl LmcuLA0KICBTVFJFQU1fTUFYX0RBVEEsIGFuZCBSU1RfU1RSRUFNKSBhbmQgc28geW91IG5lZWQg dG8gY2hlY2sgd2hldGhlcg0KICB0aGUgc3RyZWFtIGlzIG9uZSB0aGF0IHNob3VsZCBoYXZlIGJl ZW4gY3JlYXRlZCBsb2NhbGx5IG9yDQogIHJlbW90ZWx5LiBUaGlzIGp1c3QgZG9lc24ndCBoYXBw ZW4gd2l0aCBiaWRpcmVjdGlvbmFsIHN0cmVhbXM7IEkgZG8NCiAgaW1wbGVtZW50IG9kZC9ldmVu IG1lY2hhbmljcyBidXQgYmVjYXVzZSB0aGUgb3RoZXIgc2lkZSBoYXMgdG8gaGF2ZQ0KICBpdHMg c3RyZWFtIGlkcyBpbmNyZW1lbnQgYnkgb25lLCBJIGNhbiBtYWtlIHN1cmUgdGhhdCB0aGV5IGhh dmUgdGhlDQogIHJpZ2h0IElEcyBieSBjb25zdHJ1Y3Rpb24gYW5kIGp1c3QgY2hlY2sgdG8gc2Vl IGlmIHRoZSBzdHJlYW0gZXhpc3RzDQogIGluIHRoZXNlIGNhc2VzLiAgSSdkIGxpa2UgdG8gc2Vl IHVzIGdldCByaWQgb2Ygb2RkL2V2ZW4gbm8gbWF0dGVyDQogIHdoYXQuDQoNCi0gVW5pZGlyZWN0 aW9uYWwgc3RyZWFtcyBhbHNvIGhlbHBzIGF2b2lkIHNvbWUgb2YgdGhlIGNvcm5lciBjYXNlcyBh cm91bmQNCiAgYmlkaXJlY3Rpb25hbCBzdHJlYW1zLiBTcGVjaWZpY2FsbHksIHN1cHBvc2UgSSBh bSB0aGUgY2xpZW50IGFuZA0KICBJIGdldCBNQVhfU1RSRUFNX0RBVEEgYXMgdGhlIGZpcnN0IGZy YW1lIG9uIHN0cmVhbSAyLiBBbSBJIGFsbG93ZWQNCiAgdG8ganVzdCBzdGFydCBzZW5kaW5nIG9y IG5vdD8gWW91IGNhbiBzb3J0IG9mIGdldCBpbnRvIHRoaXMgc2l0dWF0aW9uDQogIHdpdGggdW5p ZGlyZWN0aW9uYWwgc3RyZWFtcywgYnV0IGJlY2F1c2UgaXQncyBleHBsaWNpdCwgb25lIG1pZ2h0 DQogIGhvcGUgdGhhdCB0aGUgYXBwbGljYXRpb24gc2VtYW50aWNzIHdvdWxkIHJlcXVpcmUgY2xl YXIgc3BlY2lmaWNhdGlvbi4NCg0KLSBBcyBub3RlZCBhYm92ZSwgYmlkaXJlY3Rpb25hbCBzdHJl YW1zIGFyZSBtb3JlIGZsZXhpYmxlIGJlY2F1c2UgdGhleQ0KICBsZXQgeW91IGhhdmUgbWFwcGlu Z3MgdGhhdCB5b3UgY2FuJ3QgaGF2ZSB3aXRoIHVuaWRpcmVjdGlvbmFsDQogIHN0cmVhbXMgKHVu cGFpcmVkLCAxOk4pLg0KDQoNCkhhcHB5IHRvIGFuc3dlciBtb3JlIHF1ZXN0aW9ucyBpZiBwZW9w bGUgaGF2ZSB0aGVtLiBPdGhlcndpc2Ugd2UgY2FuDQp0YWxrIGFib3V0IHRoaXMgaW4gU2VhdHRs ZS4NCg0KLUVrcg0KDQoNClswXSBodHRwczovL2dpdGh1Yi5jb20vZWtyL21pbnEvdHJlZS91bmlk aXJlY3Rpb25hbF9zdHJlYW1zPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRs b29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmVrciUyRm1pbnElMkZ0cmVl JTJGdW5pZGlyZWN0aW9uYWxfc3RyZWFtcyZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0 MG1pY3Jvc29mdC5jb20lN0MxNGYwNzk4N2RhMGQ0YWZiOGU3NTA4ZDUwOTBmZjZmNiU3QzcyZjk4 OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY0MjQ4ODY1NDY0ODE3MTAm c2RhdGE9eFNlU1hZRzRPQzZpVFpoaWNWZ0g2cUpUTnJaRVFoYVVCYzBYUnN4aXlwQSUzRCZyZXNl cnZlZD0wPg0KWzFdIGh0dHBzOi8vZ2l0aHViLmNvbS9la3Ivd2ctbWF0ZXJpYWxzL2Jsb2IvNDA0 ODk4ZmEyZDJmMGE5ZjliZDI0NGQyYzk0NWU2NmVhODg1MDJhMi9pbnRlcmltLTE3LTEwL1VuaWRp cmVjdGlvbmFsJTIwU3RyZWFtcyUyMGluJTIwTWlucS5wZGY8aHR0cHM6Ly9uYTAxLnNhZmVsaW5r cy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJG ZWtyJTJGd2ctbWF0ZXJpYWxzJTJGYmxvYiUyRjQwNDg5OGZhMmQyZjBhOWY5YmQyNDRkMmM5NDVl NjZlYTg4NTAyYTIlMkZpbnRlcmltLTE3LTEwJTJGVW5pZGlyZWN0aW9uYWwlMjUyMFN0cmVhbXMl MjUyMGluJTI1MjBNaW5xLnBkZiZkYXRhPTAyJTdDMDElN0NtaWNoYWVsLmJpc2hvcCU0MG1pY3Jv c29mdC5jb20lN0MxNGYwNzk4N2RhMGQ0YWZiOGU3NTA4ZDUwOTBmZjZmNiU3QzcyZjk4OGJmODZm MTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzElN0M2MzY0MjQ4ODY1NDY0ODE3MTAmc2RhdGE9 WiUyQklOT2tBQXZiWHdZN1l1d2FQajBmMXlSWFk3Uzc5QWtEJTJGdkhHcHdMb1ElM0QmcmVzZXJ2 ZWQ9MD4NClsyXSBUaGFua3MgdG8gUGF0cmljayBNY01hbnVzIGZvciBzdWdnZXN0aW5nIHRoaXMg ZGVzaWduLg0KWzNdIEluIEMrKywgeW91IHdvdWxkIGhhdmUgYSBzaW5nbGUgZnVuY3Rpb24gd2l0 aCBhIGRlZmF1bHQgYXJndW1lbnQgb2YNCiAgICB8bnVsbHB0cnwgYnV0IEdvIGRvZXNuJ3Qgc3Vw cG9ydCB0aGF0LCBoZW5jZSB0d28gZGlmZmVyZW50IGFyZ3VtZW50cy4NCls0XSBGb3IgaW1wbGVt ZW50YXRpb24gcmVhc29ucywgaXQncyBhY3R1YWxseSB1c2luZyBDb25uZWN0aW9uIGFzIGEgbWl4 aW4sDQogICAgd2hpY2ggbWVhbnMgaXQncyBzaW11bHRhbmVvdXNseSBwb3NzaWJsZSB0byB1c2Ug dGhlIHVuaWRpcmVjdGlvbmFsDQogICAgYW5kIGJpZGlyZWN0aW9uYWwgQVBJcywgYnV0IHRoYXQn cyBnb2luZyB0byBjYXVzZSBhIGxvdCBvZiBjb25mdXNpb24uDQogICAgQSByZWFsIGltcGxlbWVu dGF0aW9uIHdvdWxkIHByb2JhYmx5IGhhdmUgdG8gZWl0aGVyIGNvbW1pdCB0byBvbmUNCiAgICBv ciB0aGUgb3RoZXIgb3IgZG8gYSByZWFsIHdyYXBwZXIsIHNvIHlvdSBjb3VsZCBvbmx5IHVzZSBv bmUgc2V0IG9mDQogICAgQVBJcywgYXQgdGhlIGNvc3Qgb2YgaGF2aW5nIHRvIGRvIG1vcmUgZm9y d2FyZGVkIG1ldGhvZHMuDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K --_000_MWHPR21MB01417BDA5D8978FCAE6BDFBA877C0MWHPR21MB0141namp_ 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 emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubS02NDIy NzI4MjY4ODA0MjQ5OTU5YWlybWFpbG9uLCBsaS5tLTY0MjI3MjgyNjg4MDQyNDk5NTlhaXJtYWls b24sIGRpdi5tLTY0MjI3MjgyNjg4MDQyNDk5NTlhaXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6 bV8tNjQyMjcyODI2ODgwNDI0OTk1OWFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCglt YXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJy aSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9u MQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47 fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3Bp ZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRh dGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8 Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNz PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGluayB0aGUgZGlmZmVy ZW5jZSBpcyBmb3IgdGhlIHNjZW5hcmlvIHdoZXJlIHlvdSBkb27igJl0IGV4cGVjdCBhIHBlZXIg dG8gcmVzcG9uZCAob3IgZG9u4oCZdCBleHBlY3QgdGhlbSB0byByZXNwb25kIHN0cmVhbS1ieS1z dHJlYW0pLiZuYnNwOyBXaXRoIC0wNSwgdGhlIHJlY2VpdmVyIHN0aWxsIG5lZWRzIHRvIHNlbmQg U1RSRUFNKG9mZnNldD0wLEZJTikgb24gZWFjaCBzdHJlYW0uJm5ic3A7IFdpdGggZWl0aGVyIHVu aWRpcmVjdGlvbmFsDQogcHJvcG9zYWwsIHRoaXMgcGF0dGVybiBpcyBhIGJpdCBjbGVhbmVyLiZu YnNwOyBJbiAjNjU2LCB0aGUgc2VuZGVyIGNhbiBlc3NlbnRpYWxseSBzYXksIOKAnERvbuKAmXQg Ym90aGVy4oCdIGF0IHRoZSB0aW1lIG9mIHN0cmVhbSBjcmVhdGlvbi4mbmJzcDsgSW4gIzY0Mywg dGhlcmXigJlzIG5vIGNvcnJlc3BvbmRpbmcgY2hhbm5lbCB0byBjbG9zZS48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+SW4gYWxsIGNhc2VzLCB0aGUgb25seSB0aGluZyB0aGF0IHJlYWxseSBsaW1p dHMgeW91IGlzIHRoZSBwZWVy4oCZcyB3aWxsaW5nbmVzcyB0byBpbmNyZWFzZSB5b3VyIE1BWF9T VFJFQU1fSUQsIGl04oCZcyBqdXN0IGEgcXVlc3Rpb24gb2YgaG93IGNoYXR0eSB5b3UgaGF2ZSB0 byBiZSDigJMgd2hpY2ggY2FuIG1hdHRlciBpZiB0aGVzZSBtZXNzYWdlcyBhcmUgZmFpcmx5IHNt YWxsLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24gQmVoYWxmIE9mDQo8L2I+RXJpYyBSZXNjb3JsYTxi cj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE9jdG9iZXIgMSwgMjAxNyAyOjAzIFBNPGJyPg0KPGI+ VG86PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDttaWtrZWxmakBnbWFpbC5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBJRVRGIFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBSZXBvcnQgb24gVW5pZGlyZWN0aW9uYWwgU3RyZWFtcyBp biBNaW5xPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JJ20gbm90IHN1cmUgSSBoYXZl IGFueSB1c2VmdWwgaW5zaWdodHMgb24gdGhpcywgYXMgbXkgaW1wbGVtZW50YXRpb24gaGFuZGxl cyB0aGVtIG1vcmUgb3IgbGVzcyB0aGUgc2FtZS4gQ2FuIHlvdSBleHBsYWluIHdoeSB5b3UgdGhp bmsgdGhpcyB3b3VsZCBiZSBkaWZmZXJlbnQgd2l0aCB1bmlkaXJlY3Rpb25hbCB2ZXJzdXMgYmlk aXJlY3Rpb25hbD88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBTdW4sIE9jdCAxLCAyMDE3IGF0IDE6MzggUE0sIE1pa2tlbCBGYWhuw7hlIErDuHJn ZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2Js YW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJp Z2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdiBpZD0ibV8tNjQyMjcyODI2ODgwNDI0OTk1OWJsb29wX2N1 c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5r cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTY0MjI3MjgyNjg4 MDQyNDk5NTlibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9 Im1fLTY0MjI3MjgyNjg4MDQyNDk5NTlibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIG9ubHkgc2tpbW1lZCB0aGlzIHN1cGVyZmFzdCwg YnV0IG9uZSB0aGUgb2JzZXJ2YXRpb25zIGFwcGVhciB0byBub3QgY292ZXIgb25lIG9mIG15IGtl eSBwb2ludHM6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXy02NDIy NzI4MjY4ODA0MjQ5OTU5Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 ZGl2IGlkPSJtXy02NDIyNzI4MjY4ODA0MjQ5OTU5Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+WW91IGNhbiBjcmVhdGUgYW5kIGNsb3Nl IHVuaS1zdHJlYW1zIGF0IGF0IHZlcnkgaGlnaCByYXRlIG9mIG1hbnkgc3RyZWFtcyBwZXIgcGFj a2V0LCB3aXRob3V0IHdhaXRpbmcgZm9yIHBlZXIgcmVzcG9uc2UsIGFzc3VtaW5nIHRoZSBBQ0sg ZnJhbWV3b3JrIGhhbmRsZXMgcmV0cmFuc21pc3Npb24uDQogQW55IGluc2lnaHRzIG9uIHRoaXM/ PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9Im1fLTY0MjI3MjgyNjg4MDQyNDk5NTlibG9vcF9z aWduXzE1MDY4OTAxODMzNTg5NjU3NjAiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5LaW5kIFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im0tNjQyMjcyODI2ODgw NDI0OTk1OWFpcm1haWxvbiI+T24gMSBPY3RvYmVyIDIwMTcgYXQgMjIuMzIuMDIsIEVyaWMgUmVz Y29ybGEgKDxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JA cnRmbS5jb208L2E+KSB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpIGZvbGtzLDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBwcm9taXNlZCBJIHNwZW50 IGEgYnVuY2ggb2YgdGltZSBoYWNraW5nIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmludG8gTWlucSBhbmQg SSdtIGhlcmUgdG8gcmVwb3J0IGJhY2sgWzBdLiBTcGVjaWZpY2FsbHksIEk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmltcGxlbWVudGVkOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg LSBQUiM2NDMgLS0gVW5pZGlyZWN0aW9uYWwgU3RyZWFtczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gUFIjNzIwIC0tIEFkZCBiaWRp cmVjdGlvbmFsIHN0cmVhbXMgb24gdG9wIG9mIHVuaWRpcmVjdGlvbmFsPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgLSBBIGJpZGlyZWN0 aW9uYWwgc3RyZWFtIEFQSSB0aGF0IG1vc3RseSBtaW1pY3MgTWlucSdzIG9yaWdpbmFsIEFQSTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyBmb3IgLTA1LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGZvbGxvd2luZyBpcyBraW5kIG9mIGEgd2Fs bCBvZiB0ZXh0LCBzbyB5b3UgY291bGQgYWxzbyBza2lwIHRoaXM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCByZWZlciB0byBteSBzbGlkZXMg WzFdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1JTlEnUyAtMDUgQVJDSElURUNUVVJFPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BUEk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1pbnEncyBtYXN0ZXIgb2JqZWN0IGlzIHRoZSBDb25uZWN0 aW9uLCB3aGljaCBoYXMgYSBsaXN0IG9mIFN0cmVhbXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmluZGV4ZWQgYnkgc3RyZWFtIElELiBBcHBsaWNh dGlvbnMgcmVnaXN0ZXIgYSBoYW5kbGVyIHdpdGggdGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5jb25uZWN0aW9uIHRvIGJlIG5vdGlmaWVkIG9m IG5ldyBldmVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0eXBlIENvbm5lY3Rpb25IYW5kbGVyIGludGVyZmFjZSB7 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsgJm5ic3A7IC8vIFRoZSBjb25uZWN0aW9uIGhhcyBjaGFuZ2VkIHN0YXRlIHRvIHN0YXRlIHxz fDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwOyBTdGF0ZUNoYW5nZWQocyBTdGF0ZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgLy8gQSBu ZXcgc3RyZWFtIGhhcyBiZWVuIGNyZWF0ZWQgKGJ5IHJlY2VpdmluZyBhIGZyYW1lPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 IC8vIGZyb20gdGhlIG90aGVyIHNpZGUuIHxzfCBjb250YWlucyB0aGUgc3RyZWFtLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyBOZXdTdHJlYW0ocyAqU3RyZWFtKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAvLyBTdHJlYW0gfHN8IGlz IG5vdyByZWFkYWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgU3RyZWFtUmVhZGFibGUocyAqU3RyZWFtKTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw O308bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ U3RyZWFtcyBnZXQgY3JlYXRlZCBpbiB0d28gd2F5czo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBMb2NhbGx5IHZpYSBDb25uZWN0aW9uLkNy ZWF0ZVN0cmVhbSgpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4tIFJlbW90ZWx5LCBpbiB3aGljaCBjYXNlIHRoZSBhcHBsaWNhdGlvbiBpcyBub3Rp ZmllZCB2aWEgYSBjYWxsYmFjayB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IENvbm5lY3Rpb25IYW5kbGVyLk5ld1N0cmVhbSgpLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdHJl YW1zIHRoZW1zZWx2ZXMgaGF2ZSB0aGUgQVBJcyB5b3Ugd291bGQgZXhwZWN0LCBuYW1lbHksIFJl YWQoKSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PldyaXRlKCksIENsb3NlKCksIFJlc2V0KCksIGV0Yy4gWW91IGdldCBub3RpZmllZCBvZiBzdHJl YW0gcmVhZGFiaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPmJ5IGEgY2FsbGJhY2sgdG8gQ29ubmVjdGlvbkhhbmRsZXIuU3RyZWFtUmVhZGFi bGUoKSwgYXQgd2hpY2ggcG9pbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnlvdSBjYW4gZG8gU3RyZWFtLlJlYWQoKS4gQXMgZXhwZWN0ZWQsIFN0 cmVhbS5SZWFkKCkgcmV0dXJuczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+V09VTERCTE9DSyB3aGVuIG5vIGRhdGEgaWEgYXZhaWxhYmxlPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SU5URVJO QUxTPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B cyBub3RlZCBhYm92ZSwgd2Ugc3RhcnQgd2l0aCB0aGUgQ29ubmVjdGlvbiBvYmplY3QgKG9ubHkg cmVsZXZhbnQgZmllbGRzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5zaG93bik6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0eXBlIENvbm5lY3Rpb24gc3RydWN0IHs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgaGFuZGxlciZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ29ubmVjdGlv bkhhbmRsZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgc3RyZWFtcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgW10qU3RyZWFtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgJm5ic3A7IG1heFN0cmVhbSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyB1aW50MzI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPm91dHB1dENsZWFyUSZuYnNwOyAmbmJzcDsgJm5ic3A7W11mcmFtZSAvLyBGb3Igc3RyZWFt IDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm91 dHB1dFByb3RlY3RlZFEgW11mcmFtZSAvLyBGb3Igc3RyZWFtICZndDs9IDA8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt9PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFzIHlv dSBjYW4gc2VlLCBzdHJlYW1zIGFyZSBpbiBhbiBhcnJheSBzbGljZSwgc28gdGhleSdyZSBjb250 aWd1b3VzbHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPmluZGV4ZWQgYnkgc3RyZWFtIElELiBSaWdodCBub3csIEkgaGF2ZSBubyBwcm92aXNpb24g Zm9yIHJlY2xhaW1pbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPnRoZSB1bnVzZWQgYm90dG9tIHBhcnQgb2YgdGhlIGFycmF5LCBidXQgaXQgd291 bGQgYmUgc3RyYWlnaHRmb3J3YXJkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj50byBpbmRleCBieSB8c3RyZWFtSWR8IC0gfG1pblN0cmVhbXwsIHdo aWNoIEkgdGhpbmsgaXMgY29uc2lzdGVudCB3aXRoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgZGVzaWduIGltcGxpZWQgYnkgdGhlIHJlcXVp cmVtZW50IHRvIGNyZWF0ZSBzdHJlYW1zIGluIHNlcXVlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZWNhdXNlIFN0cmVhbXMgYXJlIGJp ZGlyZWN0aW9uYWwsIGVhY2ggc3RyZWFtIGFjdHVhbGx5IGNvbnNpc3RzIG9mIGE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBhaXIgb2YgaGFsZiBz dHJlYW1zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7dHlwZSBzdHJlYW1IYWxmIHN0cnVjdCB7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IHMmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsqc3RyZWFtJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvLyBwb2ludGVyIHRvIHBhcmVudDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyBsb2cmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvZ2dp bmdGdW5jdGlvbiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgZGlyJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtkaXJlY3Rpb24mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7Ly8gU2VuZGluZyBvciByZWNlaXZpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgY2xvc2VkJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IGJvb2wmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgLy8gSXMgdGhlIGhhbGYtc3RyZWFtIGNsb3NlZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBvZmZzZXQm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDY0Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgLy8gVGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGNodW5rcyZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBbXXN0cmVhbUNodW5rPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IG1heFN0cmVhbURhdGEgdWludDY0PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg Jm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7Ly8gSW50ZXJuYWwgb2JqZWN0IHRvIGFsbG93IHVuaXQgdGVzdGlu Zy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyAmbmJzcDt0eXBlIHN0cmVhbSBzdHJ1Y3QgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBpZCZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50MzI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgbG9nJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGxvZ2dpbmdGdW5jdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBzdGF0ZSZuYnNwOyAmbmJzcDsgJm5i c3A7IHN0cmVhbVN0YXRlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IHNlbmQsIHJlY3YgKnN0cmVhbUhhbGY8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBibG9ja2Vk Jm5ic3A7ICZuYnNwOyBib29sIC8vIEhhdmUgd2UgcmV0dXJuZWQgYmxvY2tlZDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO308 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwOy8vIFB1YmxpYyBBUEkgb2JqZWN0LCB3aGljaCBuZWVkcyBhY2Nlc3MgdG8gdGhl IENvbm5lY3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDt0eXBlIFN0cmVhbSBzdHJ1Y3QgezxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBjICpDb25u ZWN0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7IHN0cmVhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T3V0Z29pbmcgZGF0YSBpcyBlbnF1ZXVlZCBp bnRvIHxzdHJlYW0uY2h1bmtzfCwgYW5kIHRoZW4gcGVyaW9kaWNhbGx5PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50aGUgY29ubmVjdGlvbiBwb2xs cyB0aGUgc3RyZWFtIGZvciBhbGwgdGhlIGNodW5rcyB3aGljaCBhcmUgcGVybWl0dGVkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5ieSBzdHJlYW0t bGV2ZWwgZmxvdyBjb250cm9sIGFuZCBlbnF1ZXVlcyB0aGVtIGludG88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnxDb25uZWN0aW9uLm91dHB1dENs ZWFyUXwgb3IgfENvbm5lY3Rpb24ub3V0cHV0UHJvdGVjdGVkUXwuIEF0IHRoaXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnBvaW50LCB0aGUgY29u bmVjdGlvbiBvd25zIHRoZSBkYXRhIGFuZCBpcyByZXNwb25zaWJsZSBmb3I8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRyYW5zbWl0dGluZyBpdCwg c3ViamVjdCB0byBjb25uZWN0aW9uLWxldmVsIGZsb3cgY29udHJvbCwgYW5kPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4ocHJlc3VtYWJseSkgY29u Z2VzdGlvbiBjb250cm9sIG9uY2UgSSBoYXZlIHRoYXQgaW1wbGVtZW50ZWQgWzJdLjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmNvbWluZyBk YXRhIGdldHMgcXVldWVkIChzb3J0ZWQpIGludG8gfHN0cmVhbS5jaHVua3N8IGZvciBsYXRlcjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cmVhc3Nl bWJseSBhdCB0aGUgdGltZSB3aGVuIHNvbWVvbmUgY2FsbHMgc3RyZWFtLnJlYWQoKS4gSSdtIG5v dCBzdXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JIGxvdmUgdGhpcywgYmVjYXVzZSBpdCBtZWFucyBJIGRvbid0IGhhdmUgYSBnb29kIHZpZXcg b2YgdGhlIGluY29taW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5xdWV1ZSBzaXplICh3aGljaCBJJ2QgbmVlZCB0byBhY2NvdW50IGZvciBzZXBh cmF0ZWx5KSwgYnV0IGl0IGFsbG93ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPm1lIHRvIHNoYXJlIGRhdGEgc3RydWN0dXJlcyBiZXR3ZWVuIGlu Y29taW5nIGFuZCBvdXRnb2luZywgd2hpY2g8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnNlZW1lZCBraW5kIG9mIG5hdHVyYWwgd2hlbiBJIGRpZCBp dCAodGhpcyBhcmNoaXRlY3R1cmUgaXMgcmVwbGljYXRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW4gdGhlIHVuaWRpcmVjdGlvbmFsIHN0cmVh bXMgZGVzaWduLCBidXQgaXQncyBwcm9iYWJseSBsZXNzIG5hdHVyYWw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZXJlKS48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5VTklESVJFQ1RJT05B TCBTVFJFQU1TIEFSQ0hJVEVDVFVSRTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VU5JRElSRUNUSU9OQUwgQVBJPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaXRoIHRoZSB1bmlkaXJlY3Rpb25hbCBi cmFuY2gsIE1pbnEgb2ZmZXJzIHR3byBBUElzLiBUaGUgZmlyc3QgaXMgYTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c3RyYWlnaHRmb3J3YXJkIG1h cHBpbmcgb2YgUFIjNzIwLCBpbiB3aGljaCB3ZSBoYXZlIHR3byBvYmplY3RzOjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgU2VuZFN0 cmVhbSAtLSB1c2VkIGZvciB3cml0aW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgUmVjdlN0cmVhbSAtLSB1c2VkIGZvciByZWFkaW5n PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFz IGJlZm9yZSwgd2UgaGF2ZSBhIGhhbmRsZXIgb2JqZWN0LCBidXQgaXQncyBkaXJlY3Rpb25hbCBu b3c6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDt0eXBlIENvbm5lY3Rpb25IYW5kbGVyIGludGVyZmFjZSB7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7 IC8vIFRoZSBjb25uZWN0aW9uIGhhcyBjaGFuZ2VkIHN0YXRlIHRvIHN0YXRlIHxzfDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyBTdGF0ZUNoYW5nZWQocyBTdGF0ZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgLy8gQSBuZXcgcmVjZWl2 aW5nIHN0cmVhbSBoYXMgYmVlbiBjcmVhdGVkIChieSByZWNlaXZpbmcgYSBmcmFtZTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyAvLyBmcm9tIHRoZSBvdGhlciBzaWRlLiB8c3wgY29udGFpbnMgdGhlIHN0cmVhbS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJz cDsgTmV3UmVjdlN0cmVhbShzICpSZWN2U3RyZWFtKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAvLyBTdHJl YW0gfHN8IGlzIG5vdyByZWFkYWJsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgU3RyZWFtUmVhZGFibGUocyAqUmVjdlN0 cmVhbSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZuYnNwOyAmbmJzcDt9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9idmlvdXNseSBTZW5kU3RyZWFtcyBhcmUgbG9jYWxseSBjcmVhdGVkIGFu ZCBSZWN2U3RyZWFtcyBhcmUgcmVtb3RlbHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPmNyZWF0ZWQuIFNlbmRTdHJlYW1zIGNhbiBiZSBjcmVhdGVk IHVzaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5Db25uZWN0aW9uLkNyZWF0ZVNlbmRTdHJlYW0oKSBhbmQgeW91IGxlYXJuIGFib3V0IHJlbW90 ZWx5IGNyZWF0ZWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPlJlY3ZTdHJlYW1zIGJ5IGEgY2FsbGJhY2sgdG8gQ29ubmVjdGlvbkhhbmRsZXIuTmV3 UmVjdlN0cmVhbSgpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+U2Vjb25kLWNyZWF0ZWQgc3RyZWFtcyBjYW4gYmUgbWFya2VkIGFzICZxdW90O3Jl bGF0ZWQmcXVvdDsgdG8gYSBzaW5nbGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmZpcnN0LWNyZWF0ZWQgc3RyZWFtLCB1c2luZyBDb25uZWN0aW9u LkNyZWF0ZVJlbGF0ZWRTZW5kU3RyZWFtKCkgd2l0aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlIGFwcHJvcHJpYXRlIFJlY3ZTdHJlYW0gYXMg dGhlIGFyZ3VtZW50IFszXS4gU3RyZWFtcyBoYXZlIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlbGF0ZWQoKSBBUEkgdG8gdGVsbCB5b3UgaWYg dGhleSBhcmUgcmVsYXRlZCB0byBzb21lIG90aGVyIHN0cmVhbS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIHtTZW5kLFJlY3Z9U3RyZWFt IEFQSXMgYXJlIGFib3V0IHdoYXQgeW91J2QgZXhwZWN0LiBZb3UgY2FuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Xcml0ZSgpIG9uIFNlbmRTdHJl YW0gYW5kIFJlYWQoKSBvbiBSZWN2U3RyZWFtKCkuIFJpZ2h0IG5vdywgeW91IGNhbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xvc2UoKSBhbmQg UmVzZXQoKSBTZW5kU3RyZWFtcywgYnV0IG5vdCBkbyBhbnl0aGluZyBvbiBSZWN2U3RyZWFtcygp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vciB0 aGFuIGlnbm9yZSB0aGVtLiBFdmVudHVhbGx5IEknbGwgcHJvYmFibHkgb2ZmZXI8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlY3ZTdHJlYW0oKS5N dXRlKCkgb3Igc29tZXRoaW5nIHRvIGxldCB5b3Ugc2VuZCBTVE9QX1NFTkRJTkcuPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QklESVJFQ1RJ T05BTCBBUEk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPk1pbnEgYWxzbyBpbmNsdWRlcyBhIGJpZGlyZWN0aW9uYWwgQVBJIHRoYXQncyBsYXllcmVk IG9uIHRvcCBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+dW5pZGlyZWN0aW9uYWwgc3RyZWFtcy4gSSd2ZSBjcmVhdGVkIGEgQ29ubmVjdGlvbjIg c3RydWN0dXJlIHRoYXQnczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+aW50ZW5kZWQgYXMgYSB3cmFwcGVyIGFyb3VuZCBDb25uZWN0aW9uIFs0XTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7ICZuYnNwO3R5cGUgQ29ubmVjdGlvbjIgc3RydWN0IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgQ29ubmVjdGlvbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 ICZuYnNwOyBzaGltJm5ic3A7ICZuYnNwOyAqY29ubmVjdGlvbjJTaGltSGFuZGxlcjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyBzdHJlYW1zIFtdKlN0cmVhbSAvLyBPZGQgZm9yIGNsaWVudCBvcmlnaW5hdGVkLCBldmVuIGZv ciBzZXJ2ZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0eXBlIFN0cmVhbSBz dHJ1Y3QgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyBpZCZuYnNwOyAmbmJzcDt1aW50MzI8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgc2VuZCAqU2Vu ZFN0cmVhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7ICZuYnNwOyByZWN2ICpSZWN2U3RyZWFtPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CYXNpY2FsbHksIFN0cmVh bSBpcyBqdXN0IGEgcGFpciBvZiBTZW5kU3RyZWFtIGFuZCBSZWN2U3RyZWFtIGFuZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29ubmVjdGlvbjIg ZG9lcyB0aGUgYm9va2tlZXBpbmcgdG8ga2VlcCB0aGVtIGNvbm5lY3RlZCAoSSBldmVuIGRvIHRo ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+b2Rk L2V2ZW4gSUQgdGhpbmcgdGhhdCBRVUlDLTA1IGhhcykuIENvbm5lY3Rpb24yIGhhcyB0aGUgc2Ft ZSBoYW5kbGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BUEkgYXMgTWlucSBmb3IgUVVJQy0wNSwgYW5kIHRoZSBzaGltIGlzIHJlc3BvbnNpYmxl IGZvciB0cmFuc2xhdGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+dW5pZGlyZWN0aW9uYWwgZXZlbnRzIGludG8gYmlkaXJlY3Rpb25hbCBldmVu dHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkludGVybmFsbHksIHdoYXQncyBnb2luZyBvbiBoZXJlIGlzIHRoYXQgd2hlbiB5b3UgY2FsbCBD cmVhdGVTdHJlYW0oKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+TWlucSBjcmVhdGVzIGEgU3RyZWFtIHdpdGggYSBuaWwgUmVjdlN0cmVhbS4gV2hl biBhIG5ldyByZW1vdGUgc3RyZWFtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5pcyBkZXRlY3RlZCwgd2UgY2hlY2sgUmVjdlN0cmVhbS5SZWxhdGVk KCkuIElmIHRoZXkgYXJlIHJlbGF0ZWQgdG8gYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmV4aXN0aW5nIFNlbmRTdHJlYW0gdGhlbiB3ZSB3aWxs IGluIHRoZSByZWxldmFudCB8U3RyZWFtLnNlbmR8IHNsb3QuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PdGhlcndpc2UsIHdlIGNyZWF0ZSBhIG5l dyBTZW5kU3RyZWFtIHRoYXQncyByZWxhdGVkIHRvIHRoZSBpbmNvbWluZzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+c3RyZWFtIGFuZCBub3RpZnkg dGhlIGFwcGxpY2F0aW9uIG9mIHRoZSBjcmVhdGlvbiBvZiB0aGUgbmV3PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5iaWRpcmVjdGlvbmFsIHN0cmVh bS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Tm90ZSB0aGF0IHRoaXMgYWxsIHdvcmtzIGZpbmUgaWYgb25lIHNpZGUgZG9lcyB0aGUgdW5kaXJl Y3Rpb25hbCBBUEk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmFuZCBvbmUgZG9lcyB0aGUgYmlkaXJlY3Rpb25hbCBBUEkuIE15IHRlc3QgcHJvZ3Jh bXMgYWN0dWFsbHkgZXhlcmNpc2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPnRoaXMuIE9mIGNvdXJzZSwgdGhlcmUncyBhbiBhc3N1bXB0aW9uIHRo YXQgdGhlIHBlZXIgY29uZm9ybXMgdG8gYSAxOjE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1hcHBpbmcuIElmIHdlIGRlZmluZSB1bmlkaXJlY3Rp b25hbCBzdHJlYW1zLCB3ZSdsbCBuZWVkIHNvbWUgcHJvdG9jb2w8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1lY2hhbmlzbSB0byBrbm93IGlmIHRo ZSBvdGhlciBzaWRlIGlzIGV4ZXJjaXNpbmcgdGhpcyBsZXZlbCBvZjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW5jcmVhc2VkIGZsZXhpYmlsaXR5 IG9yIG5vdC4gSSBjYW4gaW1hZ2luZSBhIG51bWJlciBvZiBvcHRpb25zIGhlcmU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPihlLmcuLCBBTFBOKS4m bmJzcDsgV2UgY291bGQgYWxzbyBmb3JiaWQgMTpOIG1hcHBpbmdzIGJ1dCBJIHRoaW5rIHRoYXQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndvdWxk IGJlIGEgbWlzdGFrZSBhcyBpdCdzIGEgY29vbCBmZWF0dXJlL2JlbmVmaXQgb2YgZG9pbmc8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnVuaWRpcmVj dGlvbmFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5UaGUgZW50aXJlIGJpZGlyZWN0aW9uYWwgd3JhcHBlciBzaGltIGlzICZsdDsgMTUwIGxp bmVzIG9mIEdvIGNvZGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4oPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91 dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGZWtyJTJGbWlucSUyRmJs b2IlMkZ1bmlkaXJlY3Rpb25hbF9zdHJlYW1zJTJGYmlkaS5nbyZhbXA7ZGF0YT0wMiU3QzAxJTdD bWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDMTRmMDc5ODdkYTBkNGFmYjhlNzUwOGQ1 MDkwZmY2ZjYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2 NDI0ODg2NTQ2NDgxNzEwJmFtcDtzZGF0YT13cHM5QVdLMmZhYTgzTjlSJTJCREhvdmlnJTJCd2Y2 ODRQUyUyQjVRdzVEZ3pZSDVJJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0 cHM6Ly9naXRodWIuY29tL2Vrci9taW5xL2Jsb2IvdW5pZGlyZWN0aW9uYWxfc3RyZWFtcy9iaWRp LmdvPC9hPikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Db252ZXJ0aW5nIG15IHRlc3QgYXBwbGljYXRpb24gdG8gdGhpcyBBUEkgd2FzIGEgbWF0 dGVyIG9mIGp1c3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPmNoYW5naW5nIGNsYXNzIG5hbWVzLCBlLmcuLCBzL0Nvbm5lY3Rpb25iL0Nvbm5lY3Rp b24yLy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SW4gbXkgaW1wbGVtZW50YXRpb24sIEkgYXNzdW1lIHRoYXQgYXQgdGhlIHRpbWUgTWlucSBo ZWFycyBhYm91dCBhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5zdHJlYW0sIHlvdSBrbm93IGlmIGl0cyByZWxhdGVkIHRvIGEgZ2l2ZW4gZXhpc3Rp bmcgc3RyZWFtLiZuYnNwOyBUaGF0IHdheTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+eW91IGNhbiBpbW1lZGlhdGVseSBlaXRoZXIgYXNzb2NpYXRl IGl0IHdpdGggdGhhdCBzdHJlYW0gb3IgbWFrZSBhIG5ldzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bG9jYWwgc3RyZWFtLiBJbiBteSBpbXBsZW1l bnRhdGlvbiwgSSBhbHdheXMgc2VuZCBSZWxhdGVkIFN0cmVhbSBJZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+YW5kIGFzc3VtZSB0aGF0IHlvdSBu ZXZlciBnZXQgYW4gJnF1b3Q7dW5yZWxhdGVkJnF1b3Q7IHN0cmVhbSBmcmFtZSBiZWZvcmUgYTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JnF1b3Q7 cmVsYXRlZCZxdW90OyBvbmUuIFRoZSBzcGVjIGRvZXNuJ3QgcmVhbGx5IHJlcXVpcmUgdGhhdCBy aWdodCBub3csIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+b2ZmbGluZSBNVCBzdWdnZXN0ZWQganVzdCBzZW5kaW5nIHJlbGF0ZWQgd2l0aCBv ZmZzZXQ9MCBidXQgSSB0aGluazxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+dGhhdCdzIGEgbWlzdGFrZSwgYmVjYXVzZSBpdCBtZWFucyB0aGF0IHlv dSBuZWVkIHRvIGhvbGQgc3RyZWFtIGZyYW1lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aW4gc29tZSBwcm92aXNpb25hbCAmcXVvdDt1bmRldGVy bWluZWQmcXVvdDsgc3RhdGUgdW50aWwgeW91IGdldCB0aGF0IGZyYW1lLiBJPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53b3VsZCBzdWdnZXN0IGlu c3RlYWQgdGhhdCB3ZSByZXF1aXJlIHRoYXQgeW91IGluY2x1ZGUgdGhlIGZpZWxkIHVudGlsPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5vbmUgb2Yg dGhlIGZyYW1lcyBpcyBBQ0tlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JTlRFUk5BTFM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNlbmRpbmcgYW5kIHJlY2VpdmluZyBzdHJl YW1zIHN0aWxsIHNoYXJlIGEgbG90IG9mIGNvbW1vbiBjb21wb25lbnRzOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IHR5 cGUgYmFzZVN0cmVhbSBzdHJ1Y3QgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBzdGF0ZSZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDtzdHJlYW1TdGF0ZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBpZCZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVpbnQzMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBsb2cmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvZ2dpbmdGdW5jdGlvbjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBvZmZzZXQm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDY0PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGNodW5rcyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyBbXXN0cmVhbUNodW5rPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IG1heFN0cmVhbURhdGEg dWludDY0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDsgJm5ic3A7IGlzUmVsYXRlZCZuYnNwOyAmbmJzcDsgJm5ic3A7Ym9vbDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNw OyByZWxhdGVkJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dWludDMyPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IH08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDsgdHlwZSBzZW5kU3RyZWFtIHN0cnVjdCB7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGJh c2VTdHJlYW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyAmbmJzcDsgYmxvY2tlZCBib29sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsgdHlwZSByZWN2U3RyZWFtIHN0cnVjdCB7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IGJhc2VTdHJlYW08bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Nb3N0IG9mIHRoaXMgaXMgdGhlIHNhbWUgYXMgd2l0aCBiaWRpcmVjdGlvbmFsIHN0cmVh bXMuJm5ic3A7IEFzIGFib3ZlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+aXQncyBwcm9iYWJseSBwb3NzaWJsZSB0byBtYWtlIHRoZW0gbW9yZSBh c3ltbWV0cmljYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBjb25uZWN0aW9uIG1haW50YWlucyBzZXBhcmF0ZSBsaXN0cyBvZiBzZW5k aW5nIGFuZCByZWNlaXZpbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPnN0cmVhbXMgYW5kIGl0J3Mgc3RyYWlnaHRmb3J3YXJkIHRvIGNyZWF0ZSBh bmQgYWNjZXNzIHRoZW0gd2l0aG91dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+d29ycnlpbmcgYWJvdXQgdGhlIG9kZC9ldmVuIHN0dWZmLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNPTVBB UklTT048bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkF0IHRoZSBlbmQgb2YgdGhlIGRheSwgSSB0aGluayB0aGlzIHNob3dzIHRoYXQgdGhlc2UgZGVz aWducyBhcmVuJ3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPnJlYWxseSB0aGF0IGRpc3NzaW1pbGFyLiBJIHdhcyBhYmxlIHRvIGNvbnZlcnQgTWlu cSB0byB1bmlkaXJlY3Rpb25hbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+c3RyZWFtcyBpbiBhYm91dCAxNiB0b3RhbCBob3VycyBvZiB3b3JrIChi YXNpY2FsbHkgYSBsb25nIHBsYW5lIGZsaWdodDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+cGx1cyB0aGUgbmV4dCBtb3JuaW5nKS4gV2hpbGUgSSBo YWQgdG8gbWFrZSBhIGJ1bmNoIG9mIGNoYW5nZXMgdG8gdGhlPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5pbnRlcm5hbCBzdHJ1Y3R1cmVzLCBiYXNp Y2FsbHkgbm9uZSBvZiB0aGVtIG1vZGlmaWVkIGFueXRoaW5nIHRyaWNreSw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmFuZCBpbiBwYXJ0aWN1bGFy IHRoZSBmbG93IGNvbnRyb2wgbWVjaGFuaWNzIGFuZCB0aGUgbGlrZSBhcmU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJhc2ljYWxseSB1bmNoYW5n ZWQsIGV4Y2VwdCBmb3IgYSBidW5jaCBvZiBtZWNoYW5pY2FsLXR5cGU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRyYW5zZm9ybWF0aW9ucyBsaWtl IHJlZmVycmluZyB0byB8c2VuZFN0cmVhbS5jaHVua3N8IGluc3RlYWQgb2Y8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnxzdHJlYW0uc2VuZC5jaHVu a3N8LiBUaGUgb25seSByZWFsbHkgbmV3IHByb3RvY29sIG1hY2hpbmVyeSBpcyB0aGU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm5ldyBmcmFtZSBm b3JtYXQgZm9yIHJlbGF0ZWQgc3RyZWFtcy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlcmUgYXJlIGEgZmV3IHByb3MvY29ucyB0aGF0IGFy ZSB3b3J0aCBub3RpbmcgYWJvdXQgdGhlc2UgZGVzaWducy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBXaXRob3V0IGEgYmlkaXJlY3Rpb25h bCBBUEksIGhhdmluZyB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGlzIG1vcmU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB3b3JrIGZvciB0 aGUgcHJvZ3JhbW1lci4gSG93ZXZlciwgd2l0aCBhbiBBUEkgc2hpbSwgdGhlIGRpZmZlcmVuY2U8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyBpcyB0cml2aWFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4tIEJlY2F1c2UgdW5kaXJlY3Rpb25hbCBzdHJlYW1zIGFyZSBpbmhlcmVudGx5 IG1vcmUgZmxleGlibGUsIGl0J3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBwb3NzaWJsZSBmb3IgdGhlIHNpZGVzIHRvIHRyeSB0byB1 c2UgZGlmZmVyZW50IG1hcHBpbmdzLCBlLmcuLCBvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBzaWRlIGV4cGVjdHMgcGFpcmVkIGFu ZCB0aGUgb3RoZXIgZXhwZWN0cyAxOk4uIFdlJ2xsIG5lZWQgc29tZSB3YXk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBvZiBtYWtpbmcg c3VyZSB0aGF0IGRvZXNuJ3QgaGFwcGVuLCBtYXliZSBBTFBOPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFRoZSAmcXVvdDtSZWxhdGVkIFN0 cmVhbSBJRCZxdW90OyBmcmFtZSBpbmRpY2F0b3IgbmVlZHMgZmxlc2hpbmcgb3V0IGEgYml0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 IEZyb20gdGhlIGFwcGxpY2F0aW9uJ3MgcGVyc3BlY3RpdmUsIGl0IHNob3VsZCBuZXZlciBoZWFy IGFib3V0IGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOyBzdHJlYW0gd2l0aG91dCBrbm93aW5nIGl0cyByZWxhdGVkIHN0YXR1cy4gQW5k IGFzIG5vdGVkIGFib3ZlLCBJPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgdGhpbmsgaXQgd291bGQgYmUgYmVzdCBpZiB3ZSByZXF1aXJl ZCB0aGF0IGFsbCAmcXVvdDtmaXJzdCBmbGlnaHQmcXVvdDsgc3RyZWFtPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgZnJhbWVzIHRoYXQg YXJlIHJlbGF0ZWQgaW5jbHVkZSB0aGUgZmllZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIFVuZGlyZWN0aW9uYWwgc3RyZWFtcyBraW5kIG9m IHNoYXJwZW4gdGhlIGNvbmZ1c2lvbiBhYm91dCBleGFjdGx5PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgd2hhdCBraW5kcyBvZiAmcXVv dDtjbG9zdXJlJnF1b3Q7IHdlIHdhbnQgdG8gYWxsb3cuIFNwZWNpZmljYWxseSwgd2hhdCBzaG91 bGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOyBpbXBsZW1lbnRhdGlvbnMgYmUgYWJsZSB0byBzYXkgYWJvdXQgdGhlaXIgd2lsbGluZ25l c3MgdG8gcmVjZWl2ZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOyBSaWdodCBub3cgd2UgaGF2ZSBTVE9QX1NFTkRJTkcsIGJ1dCB0aGF0 IGRvZXNuJ3QgaW5mbHVlbmNlIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IHNlbmRlcidzIHN0YXRlLiBJIGRvbid0IHRoaW5rIHVu ZGlyZWN0aW9uYWwgc3RyZWFtcyBtYWtlIHRoaXMgd29yc2UsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgdGhleSBqdXN0IHJlcXVpcmUg dXMgdG8gdGhpbmsgaXQgdGhyb3VnaCBzb21lIG1vcmUuIFRoZXkgZG8gc2ltcGxpZnk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB0aGUg aW1wbGVtZW50YXRpb24gb2YgdGhlIGNsb3N1cmUgc3RhdGUgbWFjaGluZTogaW4gbXkgUVVJQy0w NSBjb2RlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jm5ic3A7IHdoZW5ldmVyIG9uZSBzaWRlIGNsb3NlcyBJIGhhdmUgdG8gaGF2ZSBjaGVja3Mg dG8gc2VlIGlmIEkgc2hvdWxkIGJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgdHJhbnNpdGlvbmluZyB0byBDTE9TRUQgb3IgSEFMRi1D TE9TRUQsIGV0Yywgd2hpY2ggaXMgb2RkIGJlY2F1c2U8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB0aGUgZGlyZWN0aW9ucyBhcmUgYmFz aWNhbGx5IGluZGVwZW5kZW50LiZuYnNwOyBJdCB3b3VsZCBwcm9iYWJseSBiZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGVhc2llciBl dmVuIGluIFFVSUMtMDUgbm90IHRvIHJlaWZ5IHRoZXNlIHN0YXRlcyBidXQganVzdCB0bzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IGRl dGVybWluZSB0aGUgc3RhdGUgZnJvbSB0aGUgY29tcG9zaXRpb24gb2YgdGhlIGluZGl2aWR1YWw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyBzdWItc3RhdGVzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPi0gVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBkb24ndCBuZWVkIHRoZSBr aW5kIG9mIGFubm95aW5nIG9kZC1ldmVuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgbWVjaGFuaWNzLCB3aGljaCB3YXMgZWFzaWVyIHRv IGNvZGUgdXAgKGp1c3QgaGF2aW5nIHRvIGNyZWF0ZSBhbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyB0aGUgbG93ZXItbnVtYmVyZWQg c3RyZWFtcyBvZiB0aGUgc2FtZSBwYXJpdHkgaXMga2luZCBvZiBhIHBhaW4pLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IE9uZSBhZGRp dGlvbmFsIGJlbmVmaXQgaGVyZSBpcyB0aGF0IHdpdGggUVVJQy0wNSB0aGVyZSBhcmUgc2V2ZXJh bDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7IG1lc3NhZ2VzIHdoaWNoIGludm9sdmUgaW1wbGljaXQgc3RyZWFtIGNyZWF0aW9uIChlLmcu LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7IFNUUkVBTV9NQVhfREFUQSwgYW5kIFJTVF9TVFJFQU0pIGFuZCBzbyB5b3UgbmVlZCB0byBj aGVjayB3aGV0aGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgdGhlIHN0cmVhbSBpcyBvbmUgdGhhdCBzaG91bGQgaGF2ZSBiZWVuIGNy ZWF0ZWQgbG9jYWxseSBvcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7IHJlbW90ZWx5LiBUaGlzIGp1c3QgZG9lc24ndCBoYXBwZW4gd2l0 aCBiaWRpcmVjdGlvbmFsIHN0cmVhbXM7IEkgZG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBpbXBsZW1lbnQgb2RkL2V2ZW4gbWVjaGFu aWNzIGJ1dCBiZWNhdXNlIHRoZSBvdGhlciBzaWRlIGhhcyB0byBoYXZlPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgaXRzIHN0cmVhbSBp ZHMgaW5jcmVtZW50IGJ5IG9uZSwgSSBjYW4gbWFrZSBzdXJlIHRoYXQgdGhleSBoYXZlIHRoZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 IHJpZ2h0IElEcyBieSBjb25zdHJ1Y3Rpb24gYW5kIGp1c3QgY2hlY2sgdG8gc2VlIGlmIHRoZSBz dHJlYW0gZXhpc3RzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDsgaW4gdGhlc2UgY2FzZXMuJm5ic3A7IEknZCBsaWtlIHRvIHNlZSB1cyBn ZXQgcmlkIG9mIG9kZC9ldmVuIG5vIG1hdHRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IHdoYXQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gVW5pZGlyZWN0aW9uYWwgc3RyZWFt cyBhbHNvIGhlbHBzIGF2b2lkIHNvbWUgb2YgdGhlIGNvcm5lciBjYXNlcyBhcm91bmQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBiaWRp cmVjdGlvbmFsIHN0cmVhbXMuIFNwZWNpZmljYWxseSwgc3VwcG9zZSBJIGFtIHRoZSBjbGllbnQg YW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDsgSSBnZXQgTUFYX1NUUkVBTV9EQVRBIGFzIHRoZSBmaXJzdCBmcmFtZSBvbiBzdHJlYW0g Mi4gQW0gSSBhbGxvd2VkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDsgdG8ganVzdCBzdGFydCBzZW5kaW5nIG9yIG5vdD8gWW91IGNhbiBz b3J0IG9mIGdldCBpbnRvIHRoaXMgc2l0dWF0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgd2l0aCB1bmlkaXJlY3Rpb25hbCBzdHJl YW1zLCBidXQgYmVjYXVzZSBpdCdzIGV4cGxpY2l0LCBvbmUgbWlnaHQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyBob3BlIHRoYXQgdGhl IGFwcGxpY2F0aW9uIHNlbWFudGljcyB3b3VsZCByZXF1aXJlIGNsZWFyIHNwZWNpZmljYXRpb24u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi0gQXMgbm90ZWQgYWJvdmUsIGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmUgbW9yZSBmbGV4 aWJsZSBiZWNhdXNlIHRoZXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOyBsZXQgeW91IGhhdmUgbWFwcGluZ3MgdGhhdCB5b3UgY2FuJ3Qg aGF2ZSB3aXRoIHVuaWRpcmVjdGlvbmFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgc3RyZWFtcyAodW5wYWlyZWQsIDE6TikuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGFwcHkg dG8gYW5zd2VyIG1vcmUgcXVlc3Rpb25zIGlmIHBlb3BsZSBoYXZlIHRoZW0uIE90aGVyd2lzZSB3 ZSBjYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PnRhbGsgYWJvdXQgdGhpcyBpbiBTZWF0dGxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WzBdIDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5z YWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHVi LmNvbSUyRmVrciUyRm1pbnElMkZ0cmVlJTJGdW5pZGlyZWN0aW9uYWxfc3RyZWFtcyZhbXA7ZGF0 YT0wMiU3QzAxJTdDbWljaGFlbC5iaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDMTRmMDc5ODdkYTBk NGFmYjhlNzUwOGQ1MDkwZmY2ZjYlN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3 QzElN0MwJTdDNjM2NDI0ODg2NTQ2NDgxNzEwJmFtcDtzZGF0YT14U2VTWFlHNE9DNmlUWmhpY1Zn SDZxSlROclpFUWhhVUJjMFhSc3hpeXBBJTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFu ayI+DQpodHRwczovL2dpdGh1Yi5jb20vZWtyL21pbnEvdHJlZS91bmlkaXJlY3Rpb25hbF9zdHJl YW1zPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+WzFdIDxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNvbSUyRmVrciUyRndnLW1hdGVyaWFscyUy RmJsb2IlMkY0MDQ4OThmYTJkMmYwYTlmOWJkMjQ0ZDJjOTQ1ZTY2ZWE4ODUwMmEyJTJGaW50ZXJp bS0xNy0xMCUyRlVuaWRpcmVjdGlvbmFsJTI1MjBTdHJlYW1zJTI1MjBpbiUyNTIwTWlucS5wZGYm YW1wO2RhdGE9MDIlN0MwMSU3Q21pY2hhZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3QzE0ZjA3 OTg3ZGEwZDRhZmI4ZTc1MDhkNTA5MGZmNmY2JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAx MWRiNDclN0MxJTdDMSU3QzYzNjQyNDg4NjU0NjQ4MTcxMCZhbXA7c2RhdGE9WiUyQklOT2tBQXZi WHdZN1l1d2FQajBmMXlSWFk3Uzc5QWtEJTJGdkhHcHdMb1ElM0QmYW1wO3Jlc2VydmVkPTAiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9la3Ivd2ctbWF0ZXJpYWxzL2Jsb2Iv NDA0ODk4ZmEyZDJmMGE5ZjliZDI0NGQyYzk0NWU2NmVhODg1MDJhMi9pbnRlcmltLTE3LTEwL1Vu aWRpcmVjdGlvbmFsJTIwU3RyZWFtcyUyMGluJTIwTWlucS5wZGY8L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMl0gVGhhbmtzIHRvIFBhdHJp Y2sgTWNNYW51cyBmb3Igc3VnZ2VzdGluZyB0aGlzIGRlc2lnbi48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlszXSBJbiBDJiM0MzsmIzQzOywgeW91 IHdvdWxkIGhhdmUgYSBzaW5nbGUgZnVuY3Rpb24gd2l0aCBhIGRlZmF1bHQgYXJndW1lbnQgb2Y8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsgfG51bGxwdHJ8IGJ1dCBHbyBkb2Vzbid0IHN1cHBvcnQgdGhhdCwgaGVuY2UgdHdv IGRpZmZlcmVudCBhcmd1bWVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5bNF0gRm9yIGltcGxlbWVudGF0aW9uIHJlYXNvbnMsIGl0J3MgYWN0 dWFsbHkgdXNpbmcgQ29ubmVjdGlvbiBhcyBhIG1peGluLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyB3aGljaCBtZWFucyBp dCdzIHNpbXVsdGFuZW91c2x5IHBvc3NpYmxlIHRvIHVzZSB0aGUgdW5pZGlyZWN0aW9uYWw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAm bmJzcDsgYW5kIGJpZGlyZWN0aW9uYWwgQVBJcywgYnV0IHRoYXQncyBnb2luZyB0byBjYXVzZSBh IGxvdCBvZiBjb25mdXNpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IEEgcmVhbCBpbXBsZW1lbnRhdGlvbiB3b3VsZCBw cm9iYWJseSBoYXZlIHRvIGVpdGhlciBjb21taXQgdG8gb25lPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7IG9yIHRoZSBvdGhl ciBvciBkbyBhIHJlYWwgd3JhcHBlciwgc28geW91IGNvdWxkIG9ubHkgdXNlIG9uZSBzZXQgb2Y8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OyAmbmJzcDsgQVBJcywgYXQgdGhlIGNvc3Qgb2YgaGF2aW5nIHRvIGRvIG1vcmUgZm9yd2FyZGVk IG1ldGhvZHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_MWHPR21MB01417BDA5D8978FCAE6BDFBA877C0MWHPR21MB0141namp_-- From nobody Sun Oct 1 14:24: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 C9A90134AB7 for ; Sun, 1 Oct 2017 14:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 xVeiEwtDyncZ for ; Sun, 1 Oct 2017 14:24:23 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 E3747134219 for ; Sun, 1 Oct 2017 14:24:22 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id 85so5302944ith.2 for ; Sun, 01 Oct 2017 14:24:22 -0700 (PDT) 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=m9dA2vTd2Z4eGOBJCPB1TOAtvfb4XrSWitGKeBLF0Uk=; b=E/Vqov+CX0VL+gHBhYp6hR8Uyk5iLIq8rwAW6oicmfoxGVZpE+KfxirV2XlvS3ZE/X 0dq3YAlHy0wTfUSG0buPTBGFR82qI23bACI09iZ0OqljH9D2eeaeUFnx0DzDzbuenZXS RVtGntmHSF8dwv8Bhn1Zns0SKHvhd1BHQL5Oy/E/0yb9KeQpVDMSl+rTRjamcEDIJqhZ VDlLhVUu7Ok36qkpEeADfSAO1s10GWPjdsHbJXaIf7MR6JFI95VtFxTJ7Ey5tyNfow61 7RZ0rhbpah1D+7n/HXQPjaK/0W2CYubgWizQtb7ZjEl07jJ2gBzDK2ACd0iwhyeQCasG pKZA== 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=m9dA2vTd2Z4eGOBJCPB1TOAtvfb4XrSWitGKeBLF0Uk=; b=ljCQc2MFnYXLjMFQIZE6xHNuvIkkiHR+L7iypxL+GD257tOmPbZsCUQtAZLCvcwFNO WT5BVQw7p5FvyEywMtm4sBYMlGhPCGrxrSg6RPeKB0cuAeJvZn7C2SH/X8pclQpqbY6K j1N9qyKdMXO4k646mxhLXB1du18GAhg8WYt+TBDIewyzOGVLscXXQnayFruvecCxNA56 FWvcaQ5L6jZuaNpgaUe0BFc4B1na+vj7Gy4wzUrP+VnCJVOa5h5VCol8BfRiuf9wEmPt 5PpHa107tz0rsWtBw1PQ8XwlRGdNrkl1MNTVxFL204cw6ci8t9Sr2bLTC9IbmQt4Ioo4 5Idw== X-Gm-Message-State: AMCzsaXElpHsHGdecDcKvJ7vVMgj1joR7ML9H9lG1BJGU2WF7rra0tmg fjUgu3475NuyQsYQaqXYApoBgxCV4heO6z4TjgA= X-Google-Smtp-Source: AOwi7QASmGCvMESF1iEueQWn/po/tmW6IEhBEceHyv0Z70j1X4afqSW/kQcpCV0wClUCvLwGbheZn/SSvdS2cve5z10= X-Received: by 10.36.94.5 with SMTP id h5mr17050741itb.100.1506893062174; Sun, 01 Oct 2017 14:24:22 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sun, 1 Oct 2017 17:24:21 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sun, 1 Oct 2017 17:24:21 -0400 Message-ID: Subject: Re: Report on Unidirectional Streams in Minq To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a114489a6af7fe6055a82e172" 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, 01 Oct 2017 21:24:27 -0000 --001a114489a6af7fe6055a82e172 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Can you explain why you think this would be different with unidirectional versus bidirectional? A stream needs to keep various data structures alive to recognise input on the wire, and requests from the user to access read buffers. If it is possible to receive data then those structures cannot be torn down before a FIN or RST is received by peer. Some streams may be practically uni-directional, but the transport cannot know without application protocol saying so via the API surface. This means the state needs to stay online for at least a roundtrip, plus any processing delays the peer may have. A hostile peer could indefinitely delay closing a stream. With uni-directional streams there is no peer to be waiting for. This means all sender state can be taken down immediate after sending FIN or RST. This in turn can lead to much higher through put rates if there is a limit on the number of states to keep open. Because a peer cannot delay close, the stream count limit may also be increased while also consuming less space due to less complexity. Uni-directional receiver state still has some work to do, but it can immediately take state down once a RST or FIN is seen, without waiting for the peer to close the other stream, and the receiver would (necessarily) have to create a sender state, so overall less state to manage and fewer vulnerabilities. There is still a need to track state of recently received and closed streams to handle late traffic and prevent reuse, but this is comparatively light weight. Simulated bi-directional streams on top of uni-directional streams may have some of the contains of proper bi-directional streams depending on the exact close semantics chosen, but in this case it is probably a desirable feature. In conclusion, uni-directional streams ought to support much higher bandwidth messaging over independent streams - like if you have many micro-services sending async messages through the same connection. For a very basic QUIC implementation the difference might not be so drastic since you can just allocate a map structure and garbage collect it when done. For a high performance implementation it matters a lot more. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 1 October 2017 at 23.04.03, Eric Rescorla (ekr@rtfm.com) wrote: I'm not sure I have any useful insights on this, as my implementation handles them more or less the same. Can you explain why you think this would be different with unidirectional versus bidirectional? -Ekr On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Thanks, > > I only skimmed this superfast, but one the observations appear to not > cover one of my key points: > > You can create and close uni-streams at at very high rate of many streams > per packet, without waiting for peer response, assuming the ACK framework > handles retransmission. Any insights on this? > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 1 October 2017 at 22.32.02, Eric Rescorla (ekr@rtfm.com) wrote: > > Hi folks, > > As promised I spent a bunch of time hacking unidirectional streams > into Minq and I'm here to report back [0]. Specifically, I > implemented: > > - PR#643 -- Unidirectional Streams > - PR#720 -- Add bidirectional streams on top of unidirectional > - A bidirectional stream API that mostly mimics Minq's original API > for -05. > > The following is kind of a wall of text, so you could also skip this > and refer to my slides [1]. > > > MINQ'S -05 ARCHITECTURE > API > Minq's master object is the Connection, which has a list of Streams > indexed by stream ID. Applications register a handler with the > connection to be notified of new events. > > type ConnectionHandler interface { > // The connection has changed state to state |s| > StateChanged(s State) > > // A new stream has been created (by receiving a frame > // from the other side. |s| contains the stream. > NewStream(s *Stream) > > // Stream |s| is now readable. > StreamReadable(s *Stream) > } > > Streams get created in two ways: > > - Locally via Connection.CreateStream() > - Remotely, in which case the application is notified via a callback to > ConnectionHandler.NewStream(). > > Streams themselves have the APIs you would expect, namely, Read(), > Write(), Close(), Reset(), etc. You get notified of stream readability > by a callback to ConnectionHandler.StreamReadable(), at which point > you can do Stream.Read(). As expected, Stream.Read() returns > WOULDBLOCK when no data ia available > > > INTERNALS > As noted above, we start with the Connection object (only relevant fields > shown): > > type Connection struct { > handler ConnectionHandler > streams []*Stream > maxStream uint32 > outputClearQ []frame // For stream 0 > outputProtectedQ []frame // For stream >=3D 0 > } > > As you can see, streams are in an array slice, so they're contiguously > indexed by stream ID. Right now, I have no provision for reclaiming > the unused bottom part of the array, but it would be straightforward > to index by |streamId| - |minStream|, which I think is consistent with > the design implied by the requirement to create streams in sequence. > > Because Streams are bidirectional, each stream actually consists of a > pair of half streams. > > type streamHalf struct { > s *stream // pointer to parent > log loggingFunction > dir direction // Sending or receiving > closed bool // Is the half-stream closed > offset uint64 // The > chunks []streamChunk > maxStreamData uint64 > } > > // Internal object to allow unit testing. > type stream struct { > id uint32 > log loggingFunction > state streamState > send, recv *streamHalf > blocked bool // Have we returned blocked > } > > // Public API object, which needs access to the Connection > type Stream struct { > c *Connection > stream > } > > Outgoing data is enqueued into |stream.chunks|, and then periodically > the connection polls the stream for all the chunks which are permitted > by stream-level flow control and enqueues them into > |Connection.outputClearQ| or |Connection.outputProtectedQ|. At this > point, the connection owns the data and is responsible for > transmitting it, subject to connection-level flow control, and > (presumably) congestion control once I have that implemented [2]. > > Incoming data gets queued (sorted) into |stream.chunks| for later > reassembly at the time when someone calls stream.read(). I'm not sure > I love this, because it means I don't have a good view of the incoming > queue size (which I'd need to account for separately), but it allowed > me to share data structures between incoming and outgoing, which > seemed kind of natural when I did it (this architecture is replicated > in the unidirectional streams design, but it's probably less natural > there). > > > UNIDIRECTIONAL STREAMS ARCHITECTURE > UNIDIRECTIONAL API > With the unidirectional branch, Minq offers two APIs. The first is a > straightforward mapping of PR#720, in which we have two objects: > > SendStream -- used for writing > RecvStream -- used for reading > > As before, we have a handler object, but it's directional now: > > type ConnectionHandler interface { > // The connection has changed state to state |s| > StateChanged(s State) > > // A new receiving stream has been created (by receiving a frame > // from the other side. |s| contains the stream. > NewRecvStream(s *RecvStream) > > // Stream |s| is now readable. > StreamReadable(s *RecvStream) > } > > Obviously SendStreams are locally created and RecvStreams are remotely > created. SendStreams can be created using > Connection.CreateSendStream() and you learn about remotely created > RecvStreams by a callback to ConnectionHandler.NewRecvStream(). > Second-created streams can be marked as "related" to a single > first-created stream, using Connection.CreateRelatedSendStream() with > the appropriate RecvStream as the argument [3]. Streams have a > Related() API to tell you if they are related to some other stream. > > The {Send,Recv}Stream APIs are about what you'd expect. You can > Write() on SendStream and Read() on RecvStream(). Right now, you can > Close() and Reset() SendStreams, but not do anything on RecvStreams() > or than ignore them. Eventually I'll probably offer > RecvStream().Mute() or something to let you send STOP_SENDING. > > > BIDIRECTIONAL API > Minq also includes a bidirectional API that's layered on top of > unidirectional streams. I've created a Connection2 structure that's > intended as a wrapper around Connection [4]: > > type Connection2 struct { > Connection > shim *connection2ShimHandler > streams []*Stream // Odd for client originated, even for server. > } > > type Stream struct { > id uint32 > send *SendStream > recv *RecvStream > } > > Basically, Stream is just a pair of SendStream and RecvStream and > Connection2 does the bookkeeping to keep them connected (I even do the > odd/even ID thing that QUIC-05 has). Connection2 has the same handler > API as Minq for QUIC-05, and the shim is responsible for translating > unidirectional events into bidirectional events. > > Internally, what's going on here is that when you call CreateStream() > Minq creates a Stream with a nil RecvStream. When a new remote stream > is detected, we check RecvStream.Related(). If they are related to an > existing SendStream then we will in the relevant |Stream.send| slot. > Otherwise, we create a new SendStream that's related to the incoming > stream and notify the application of the creation of the new > bidirectional stream. > > Note that this all works fine if one side does the undirectional API > and one does the bidirectional API. My test programs actually exercise > this. Of course, there's an assumption that the peer conforms to a 1:1 > mapping. If we define unidirectional streams, we'll need some protocol > mechanism to know if the other side is exercising this level of > increased flexibility or not. I can imagine a number of options here > (e.g., ALPN). We could also forbid 1:N mappings but I think that > would be a mistake as it's a cool feature/benefit of doing > unidirectional. > > The entire bidirectional wrapper shim is < 150 lines of Go code. > (https://github.com/ekr/minq/blob/unidirectional_streams/bidi.go). > Converting my test application to this API was a matter of just > changing class names, e.g., s/Connectionb/Connection2/. > > In my implementation, I assume that at the time Minq hears about a > stream, you know if its related to a given existing stream. That way > you can immediately either associate it with that stream or make a new > local stream. In my implementation, I always send Related Stream Id > and assume that you never get an "unrelated" stream frame before a > "related" one. The spec doesn't really require that right now, and > offline MT suggested just sending related with offset=3D0 but I think > that's a mistake, because it means that you need to hold stream frames > in some provisional "undetermined" state until you get that frame. I > would suggest instead that we require that you include the field until > one of the frames is ACKed. > > > INTERNALS > Sending and receiving streams still share a lot of common components: > > type baseStream struct { > state streamState > id uint32 > log loggingFunction > offset uint64 > chunks []streamChunk > maxStreamData uint64 > isRelated bool > related uint32 > } > > type sendStream struct { > baseStream > blocked bool > } > > type recvStream struct { > baseStream > } > > Most of this is the same as with bidirectional streams. As above, > it's probably possible to make them more asymmetrical. > > The connection maintains separate lists of sending and receiving > streams and it's straightforward to create and access them without > worrying about the odd/even stuff. > > > COMPARISON > At the end of the day, I think this shows that these designs aren't > really that disssimilar. I was able to convert Minq to unidirectional > streams in about 16 total hours of work (basically a long plane flight > plus the next morning). While I had to make a bunch of changes to the > internal structures, basically none of them modified anything tricky, > and in particular the flow control mechanics and the like are > basically unchanged, except for a bunch of mechanical-type > transformations like referring to |sendStream.chunks| instead of > |stream.send.chunks|. The only really new protocol machinery is the > new frame format for related streams. > > There are a few pros/cons that are worth noting about these designs. > > - Without a bidirectional API, having unidirectional streams is more > work for the programmer. However, with an API shim, the difference > is trivial. > > - Because undirectional streams are inherently more flexible, it's > possible for the sides to try to use different mappings, e.g., one > side expects paired and the other expects 1:N. We'll need some way > of making sure that doesn't happen, maybe ALPN? > > - The "Related Stream ID" frame indicator needs fleshing out a bit. > From the application's perspective, it should never hear about a > stream without knowing its related status. And as noted above, I > think it would be best if we required that all "first flight" stream > frames that are related include the fied > > - Undirectional streams kind of sharpen the confusion about exactly > what kinds of "closure" we want to allow. Specifically, what should > implementations be able to say about their willingness to receive? > Right now we have STOP_SENDING, but that doesn't influence the > sender's state. I don't think undirectional streams make this worse, > they just require us to think it through some more. They do simplify > the implementation of the closure state machine: in my QUIC-05 code, > whenever one side closes I have to have checks to see if I should be > transitioning to CLOSED or HALF-CLOSED, etc, which is odd because > the directions are basically independent. It would probably be > easier even in QUIC-05 not to reify these states but just to > determine the state from the composition of the individual > sub-states > > - Unidirectional streams don't need the kind of annoying odd-even > mechanics, which was easier to code up (just having to create all > the lower-numbered streams of the same parity is kind of a pain). > One additional benefit here is that with QUIC-05 there are several > messages which involve implicit stream creation (e.g., > STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether > the stream is one that should have been created locally or > remotely. This just doesn't happen with bidirectional streams; I do > implement odd/even mechanics but because the other side has to have > its stream ids increment by one, I can make sure that they have the > right IDs by construction and just check to see if the stream exists > in these cases. I'd like to see us get rid of odd/even no matter > what. > > - Unidirectional streams also helps avoid some of the corner cases around > bidirectional streams. Specifically, suppose I am the client and > I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed > to just start sending or not? You can sort of get into this situation > with unidirectional streams, but because it's explicit, one might > hope that the application semantics would require clear specification. > > - As noted above, bidirectional streams are more flexible because they > let you have mappings that you can't have with unidirectional > streams (unpaired, 1:N). > > > Happy to answer more questions if people have them. Otherwise we can > talk about this in Seattle. > > -Ekr > > > [0] https://github.com/ekr/minq/tree/unidirectional_streams > [1] https://github.com/ekr/wg-materials/blob/ > 404898fa2d2f0a9f9bd244d2c945e66ea88502a2/interim-17-10/ > Unidirectional%20Streams%20in%20Minq.pdf > [2] Thanks to Patrick McManus for suggesting this design. > [3] In C++, you would have a single function with a default argument of > |nullptr| but Go doesn't support that, hence two different arguments. > [4] For implementation reasons, it's actually using Connection as a mixin= , > which means it's simultaneously possible to use the unidirectional > and bidirectional APIs, but that's going to cause a lot of confusion. > A real implementation would probably have to either commit to one > or the other or do a real wrapper, so you could only use one set of > APIs, at the cost of having to do more forwarded methods. > > > > > > > > > > > --001a114489a6af7fe6055a82e172 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Can you explain why you think this would be different wi= th unidirectional versus bidirectional?


=
A stream nee= ds to keep various data structures alive to recognise input on the wire, an= d requests from the user to access read buffers. If it is possible to recei= ve data then those structures cannot be torn down before a FIN or RST is re= ceived by peer. Some streams may be practically uni-directional, but the tr= ansport cannot know without application protocol saying so via the API surf= ace. This means the state needs to stay online for at least a roundtrip, pl= us any processing delays the peer may have. A hostile peer could indefinite= ly delay closing a stream.

With uni-directional streams there is no peer to be waiting for. This= means all sender state can be taken down immediate after sending FIN or RS= T. This in turn can lead to much higher through put rates if there is a lim= it on the number of states to keep open. Because a peer cannot delay close,= the stream count limit may also be increased while also consuming less spa= ce due to less complexity.

Uni-directional receiver state still has some work to do, but it can = immediately take state down once a RST or FIN is seen, without waiting for = the peer to close the other stream, and the receiver would (necessarily) ha= ve to create a sender state, so overall less state to manage and fewer vuln= erabilities.
=
There is= still a need to track state of recently received and closed streams to han= dle late traffic and prevent reuse, but this is comparatively light weight.=

Simulated bi-directi= onal streams on top of uni-directional streams may have some of the contain= s of proper bi-directional streams depending on the exact close semantics c= hosen, but in this case it is probably a desirable feature.

In conclusion, uni-directional strea= ms ought to support much higher bandwidth messaging over independent stream= s - like if you have many micro-services sending async messages through the= same connection.

For= a very basic QUIC implementation the difference might not be so drastic si= nce you can just allocate a map structure and garbage collect it when done.= For a high performance implementation it matters a lot more.

Kind Regards,
Mikkel Fahn= =C3=B8e J=C3=B8rgensen


On 1= October 2017 at 23.04.03, Eric Rescorla (e= kr@rtfm.com) wrote:

I'm not sure I have any useful insights on this, as my implementation handles them more or less the same. Can you explain why you think this would be different with unidirectional versus bidirectional?

-Ekr


On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Thanks,

I only skimmed this superfast, but one the observations appear to not cover one of my key points:

You can create and close uni-streams at at very high rate of many streams per packet, without waiting for peer response, assuming the ACK framework handles retransmission. Any insights on this?

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 1 October 2017 at 22.32.02, Eric Rescorla (= ekr@rtfm.com) wrote:

Hi folks,

As promised I spent a bunch of time hacking unidirectional streams
into Minq and I'm here to report back [0]. Specifically, I
implemented:

=C2=A0 - PR#643 -- Unidirectional Streams
=C2=A0 - PR#720 -- Add bidirectional streams on top of unidirectional
=C2=A0 - A bidirectional stream API that mostly mimics Minq's original API
=C2=A0 =C2=A0 for -05.
=C2=A0 =C2=A0=C2=A0
The following is kind of a wall of text, so you could also skip this
and refer to my slides [1].


MINQ'S -05 ARCHITECTURE
API
Minq's master object is the Connection, which has a list of Streams
indexed by stream ID. Applications register a handler with the
connection to be notified of new events.

=C2=A0 =C2=A0type ConnectionHandler interface {
=C2=A0 =C2=A0 // The connection has changed state to state |s|
=C2=A0 =C2=A0 StateChanged(s State)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // A new stream has been created (by receiving a frame
=C2=A0 =C2=A0 // from the other side. |s| contains the stream.
=C2=A0 =C2=A0 NewStream(s *Stream)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // Stream |s| is now readable.
=C2=A0 =C2=A0 StreamReadable(s *Stream)
=C2=A0 =C2=A0}

Streams get created in two ways:

- Locally via Connection.CreateStream()
- Remotely, in which case the application is notified via a callback to
=C2=A0 ConnectionHandler.NewStream().

Streams themselves have the APIs you would expect, namely, Read(),
Write(), Close(), Reset(), etc. You get notified of stream readability
by a callback to ConnectionHandler.StreamReadable(), at which point
you can do Stream.Read(). As expected, Stream.Read() returns
WOULDBLOCK when no data ia available


INTERNALS
As noted above, we start with the Connection object (only relevant fields
shown):

=C2=A0 =C2=A0type Connection struct {
=C2=A0 =C2=A0 handler=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ConnectionHandler
=C2=A0 =C2=A0 streams=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 []*Stream
=C2=A0 =C2=A0 maxStream=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
outputClearQ=C2=A0 =C2=A0 =C2=A0[]frame // For stream 0
outputProtectedQ []frame // For stream >=3D 0
=C2=A0 =C2=A0}

As you can see, streams are in an array slice, so they're contiguously
indexed by stream ID. Right now, I have no provision for reclaiming
the unused bottom part of the array, but it would be straightforward
to index by |streamId| - |minStream|, which I think is consistent with
the design implied by the requirement to create streams in sequence.

Because Streams are bidirectional, each stream actually consists of a
pair of half streams.

=C2=A0 =C2=A0type streamHalf struct {
=C2=A0 =C2=A0 s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// pointer to parent
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggingFunction=C2=A0 =C2=A0
=C2=A0 =C2=A0 dir=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0direction=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Sending or receiving
=C2=A0 =C2=A0 closed=C2=A0 =C2=A0 =C2=A0 =C2=A0 bool=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Is the half-stream closed
=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // The
=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []streamChunk
=C2=A0 =C2=A0 maxStreamData uint64
=C2=A0 =C2=A0}

=C2=A0 =C2=A0// Internal object to allow unit testing.
=C2=A0 =C2=A0type stream struct {
=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 loggingFunction
=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 streamState
=C2=A0 =C2=A0 send, recv *streamHalf
=C2=A0 blocked=C2=A0 =C2=A0 bool // Have we returned blocked
=C2=A0 =C2=A0}

=C2=A0 =C2=A0// Public API object, which needs access to the Connection
=C2=A0 =C2=A0type Stream struct {
=C2=A0 =C2=A0 c *Connection
=C2=A0 =C2=A0 stream
=C2=A0 =C2=A0}

Outgoing data is enqueued into |stream.chunks|, and then periodically
the connection polls the stream for all the chunks which are permitted
by stream-level flow control and enqueues them into
|Connection.outputClearQ| or |Connection.outputProtectedQ|. At this
point, the connection owns the data and is responsible for
transmitting it, subject to connection-level flow control, and
(presumably) congestion control once I have that implemented [2].

Incoming data gets queued (sorted) into |stream.chunks| for later
reassembly at the time when someone calls stream.read(). I'm not sure
I love this, because it means I don't have a good view of the incoming
queue size (which I'd need to account for separately), but it allowed
me to share data structures between incoming and outgoing, which
seemed kind of natural when I did it (this architecture is replicated
in the unidirectional streams design, but it's probably less natural
there).


UNIDIRECTIONAL STREAMS ARCHITECTURE
UNIDIRECTIONAL API
With the unidirectional branch, Minq offers two APIs. The first is a
straightforward mapping of PR#720, in which we have two objects:

=C2=A0 SendStream -- used for writing
=C2=A0 RecvStream -- used for reading

As before, we have a handler object, but it's directional now:

=C2=A0 =C2=A0type ConnectionHandler interface {
=C2=A0 =C2=A0 // The connection has changed state to state |s|
=C2=A0 =C2=A0 StateChanged(s State)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // A new receiving stream has been created (by receiving a frame
=C2=A0 =C2=A0 // from the other side. |s| contains the stream.
=C2=A0 =C2=A0 NewRecvStream(s *RecvStream)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // Stream |s| is now readable.
=C2=A0 =C2=A0 StreamReadable(s *RecvStream)
=C2=A0 =C2=A0}

Obviously SendStreams are locally created and RecvStreams are remotely
created. SendStreams can be created using
Connection.CreateSendStream() and you learn about remotely created
RecvStreams by a callback to ConnectionHandler.NewRecvStream().
Second-created streams can be marked as "related" to a single
first-created stream, using Connection.CreateRelatedSendStream() with
the appropriate RecvStream as the argument [3]. Streams have a
Related() API to tell you if they are related to some other stream.

The {Send,Recv}Stream APIs are about what you'd expect. You can
Write() on SendStream and Read() on RecvStream(). Right now, you can
Close() and Reset() SendStreams, but not do anything on RecvStreams()
or than ignore them. Eventually I'll probably offer
RecvStream().Mute() or something to let you send STOP_SENDING.


BIDIRECTIONAL API
Minq also includes a bidirectional API that's layered on top of
unidirectional streams. I've created a Connection2 structure that's
intended as a wrapper around Connection [4]:

=C2=A0 =C2=A0type Connection2 struct {
=C2=A0 =C2=A0 Connection
=C2=A0 =C2=A0 shim=C2=A0 =C2=A0 *connection2ShimHandler
=C2=A0 =C2=A0 streams []*Stream // Odd for client originated, even for server.
=C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0type Stream struct {
=C2=A0 =C2=A0 id=C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 send *SendStream
=C2=A0 =C2=A0 recv *RecvStream
=C2=A0 =C2=A0}

Basically, Stream is just a pair of SendStream and RecvStream and
Connection2 does the bookkeeping to keep them connected (I even do the
odd/even ID thing that QUIC-05 has). Connection2 has the same handler
API as Minq for QUIC-05, and the shim is responsible for translating
unidirectional events into bidirectional events.

Internally, what's going on here is that when you call CreateStream()
Minq creates a Stream with a nil RecvStream. When a new remote stream
is detected, we check RecvStream.Related(). If they are related to an
existing SendStream then we will in the relevant |Stream.send| slot.
Otherwise, we create a new SendStream that's related to the incoming
stream and notify the application of the creation of the new
bidirectional stream.

Note that this all works fine if one side does the undirectional API
and one does the bidirectional API. My test programs actually exercise
this. Of course, there's an assumption that the peer conforms to a 1:1
mapping. If we define unidirectional streams, we'll need some protocol
mechanism to know if the other side is exercising this level of
increased flexibility or not. I can imagine a number of options here
(e.g., ALPN).=C2=A0 We could also forbid 1:N mappings but I think that
would be a mistake as it's a cool feature/benefit of doing
unidirectional.

The entire bidirectional wrapper shim is < 150 lines of Go code.
Converting my test application to this API was a matter of just
changing class names, e.g., s/Connectionb/Connection2/.

In my implementation, I assume that at the time Minq hears about a
stream, you know if its related to a given existing stream.=C2=A0 That way
you can immediately either associate it with that stream or make a new
local stream. In my implementation, I always send Related Stream Id
and assume that you never get an "unrelated" stream frame before a
"related" one. The spec doesn't really require tha= t right now, and
offline MT suggested just sending related with offset=3D0 but I think
that's a mistake, because it means that you need to hold stream frames
in some provisional "undetermined" state until you get that frame. I
would suggest instead that we require that you include the field until
one of the frames is ACKed.
=C2=A0=C2=A0

INTERNALS
Sending and receiving streams still share a lot of common components:

=C2=A0 =C2=A0 type baseStream struct {
=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streamState
=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggingFunction
=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64
=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []streamChunk
=C2=A0 =C2=A0 maxStreamData uint64
=C2=A0 =C2=A0 isRelated=C2=A0 =C2=A0 =C2=A0bool
=C2=A0 =C2=A0 related=C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 type sendStream struct {
=C2=A0 =C2=A0 baseStream
=C2=A0 =C2=A0 blocked bool
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 type recvStream struct {
=C2=A0 =C2=A0 baseStream
=C2=A0 =C2=A0 }

Most of this is the same as with bidirectional streams.=C2=A0 As above,
it's probably possible to make them more asymmetrical.

The connection maintains separate lists of sending and receiving
streams and it's straightforward to create and access them without
worrying about the odd/even stuff.


COMPARISON
At the end of the day, I think this shows that these designs aren't
really that disssimilar. I was able to convert Minq to unidirectional
streams in about 16 total hours of work (basically a long plane flight
plus the next morning). While I had to make a bunch of changes to the
internal structures, basically none of them modified anything tricky,
and in particular the flow control mechanics and the like are
basically unchanged, except for a bunch of mechanical-type
transformations like referring to |sendStream.chunks| instead of
|stream.send.chunks|. The only really new protocol machinery is the
new frame format for related streams.

There are a few pros/cons that are worth noting about these designs.

- Without a bidirectional API, having unidirectional streams is more
=C2=A0 work for the programmer. However, with an API shim, the difference
=C2=A0 is trivial.

- Because undirectional streams are inherently more flexible, it's
=C2=A0 possible for the sides to try to use different mappings, e.g., one
=C2=A0 side expects paired and the other expects 1:N. We'll need some way
=C2=A0 of making sure that doesn't happen, maybe ALPN?

- The "Related Stream ID" frame indicator needs fleshi= ng out a bit.
=C2=A0 From the application's perspective, it should never hear about a
=C2=A0 stream without knowing its related status. And as noted above, I
=C2=A0 think it would be best if we required that all "first flight" stream
=C2=A0 frames that are related include the fied

- Undirectional streams kind of sharpen the confusion about exactly
=C2=A0 what kinds of "closure" we want to allow. Specifically, what should
=C2=A0 implementations be able to say about their willingness to receive?
=C2=A0 Right now we have STOP_SENDING, but that doesn't influence the
=C2=A0 sender's state. I don't think undirectional streams make this worse,
=C2=A0 they just require us to think it through some more. They do simplify
=C2=A0 the implementation of the closure state machine: in my QUIC-05 code,
=C2=A0 whenever one side closes I have to have checks to see if I should be
=C2=A0 transitioning to CLOSED or HALF-CLOSED, etc, which is odd because
=C2=A0 the directions are basically independent.=C2=A0 It would probably be
=C2=A0 easier even in QUIC-05 not to reify these states but just to
=C2=A0 determine the state from the composition of the individual
=C2=A0 sub-states
=C2=A0=C2=A0
- Unidirectional streams don't need the kind of annoying odd-even
=C2=A0 mechanics, which was easier to code up (just having to create all
=C2=A0 the lower-numbered streams of the same parity is kind of a pain).
=C2=A0 One additional benefit here is that with QUIC-05 there are several
=C2=A0 messages which involve implicit stream creation (e.g.,
=C2=A0 STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether
=C2=A0 the stream is one that should have been created locally or
=C2=A0 remotely. This just doesn't happen with bidirectional streams; I do
=C2=A0 implement odd/even mechanics but because the other side has to have
=C2=A0 its stream ids increment by one, I can make sure that they have the
=C2=A0 right IDs by construction and just check to see if the stream exists
=C2=A0 in these cases.=C2=A0 I'd like to see us get rid of odd/even no matter
=C2=A0 what.

- Unidirectional streams also helps avoid some of the corner cases around
=C2=A0 bidirectional streams. Specifically, suppose I am the client and
=C2=A0 I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed
=C2=A0 to just start sending or not? You can sort of get into this situation
=C2=A0 with unidirectional streams, but because it's explicit, one might
=C2=A0 hope that the application semantics would require clear specification.
=C2=A0=C2=A0
- As noted above, bidirectional streams are more flexible because they
=C2=A0 let you have mappings that you can't have with unidirectional
=C2=A0 streams (unpaired, 1:N).


Happy to answer more questions if people have them. Otherwise we can
talk about this in Seattle.

-Ekr


[2] Thanks to Patrick McManus for suggesting this design.
[3] In C++, you would have a single function with a default argument of
=C2=A0 =C2=A0 |nullptr| but Go doesn't support that, hence two different arguments.
[4] For implementation reasons, it's actually using Connection as a mixin,
=C2=A0 =C2=A0 which means it's simultaneously possible to use the unidirectional
=C2=A0 =C2=A0 and bidirectional APIs, but that's going to cause a lot of confusion.
=C2=A0 =C2=A0 A real implementation would probably have to either commit to one
=C2=A0 =C2=A0 or the other or do a real wrapper, so you could only use one set of
=C2=A0 =C2=A0 APIs, at the cost of having to do more forwarded methods.
=C2=A0 =C2=A0=C2=A0
=C2=A0=C2=A0









--001a114489a6af7fe6055a82e172-- From nobody Sun Oct 1 14:29: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 9C64513420F for ; Sun, 1 Oct 2017 14:29:35 -0700 (PDT) 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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h7QMYOtdio_t for ; Sun, 1 Oct 2017 14:29:32 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A61671331C2 for ; Sun, 1 Oct 2017 14:29:31 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id i7so2366413ywa.4 for ; Sun, 01 Oct 2017 14:29:31 -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=nuSNIdih1/GsudNnTJ0ZUngGsX0ULvcqRJwgUCQH7+8=; b=JGi1//l83HWTvhy68BrT0aVH3K7xuKqN0ZGYHlSRZS+YUjpUf7WSnXDNyGZ3aildgK DjD9bNCke5Rb+/Bx+QA6hj/p7neVGLrKK/YfLN6Tv7XttD3rxEOq794kfZuwEsyVQQX0 2mwKh347B8iEgOmfOkG5rBLjw65L93ftJO3IDHMkwuHqHxH7gmqJAF1HjE9bnPv2B1dr B+EjtEYcmriug9R+KOx2bk+CiW1lkT2vMNgRJilqmrOvsg0LfBkfhRfwhkVXUi6gRCqL Qs5nuWDYIimCaSnwjsZOZcjC88Ud3fPcYYfJyZXTj4jq5FBrcLqlX53zltF/CBqsFpWS 5g+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nuSNIdih1/GsudNnTJ0ZUngGsX0ULvcqRJwgUCQH7+8=; b=d90nn1RQCaLN79ZXux8B5AexElrQ4Gbf8Yi9bjCI76d/wFKyhbNhSgztgh+K8DQuhe QqTkuiPwUDN0Wv5VzovyBm7SVlyea4GI4wgtgz4fRSZJRTSEoHA3wk0KZs4CBQr6pMmd ZweQmbLGAiiRikYgZs4/oBeLc4OUpJXzWUB9TCnfybUMWKduOrsihO/h3ibKrYQAVThb ozIcFGF6coJf6W/w20UM/tsDHE8DPxOAN/3vPH+68o3R2Q5Lwa0u6RhehZyUyXeodV3b 3mDrkrOC9e1x1W1P9IUUdHOZK7vhzNL7rX8sG/dRFbHw0WnVY8q26zxWapz9X1EYbWIr E8ZQ== X-Gm-Message-State: AMCzsaVJh5EFNBC3hpEQdQ40JFENDZePAZcHBLI4eEKu42hIj51W5Mjb XHA5ieCbPGZ9vMDqARSWB79E+MR/XrNC0TU7B8x0QQ== X-Google-Smtp-Source: AOwi7QAW7GsPwZzd2vXcIxClRc+O3RVHKD79K2I1K8f92ZATcCIwYuuJTqmmYrDnxIy2VsRijYE20S1wYR72z6stLcM= X-Received: by 10.37.189.76 with SMTP id p12mr319239ybm.462.1506893370713; Sun, 01 Oct 2017 14:29:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sun, 1 Oct 2017 14:28:50 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 1 Oct 2017 14:28:50 -0700 Message-ID: Subject: Re: Report on Unidirectional Streams in Minq To: Mike Bishop Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , IETF QUIC WG Content-Type: multipart/alternative; boundary="089e0828b4f0136d1b055a82f49a" 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, 01 Oct 2017 21:29:35 -0000 --089e0828b4f0136d1b055a82f49a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 1, 2017 at 2:19 PM, Mike Bishop wrote: > I think the difference is for the scenario where you don=E2=80=99t expect= a peer > to respond (or don=E2=80=99t expect them to respond stream-by-stream). W= ith -05, > the receiver still needs to send STREAM(offset=3D0,FIN) on each stream. > Nit: Can't you send RESET_STREAM? > With either unidirectional proposal, this pattern is a bit cleaner. In > #656, the sender can essentially say, =E2=80=9CDon=E2=80=99t bother=E2=80= =9D at the time of stream > creation. In #643, there=E2=80=99s no corresponding channel to close. > Yes, I agree that this is cleaner. Note that in #643 you presumably need to have some way of signaling that you don't want a return connection.... In all cases, the only thing that really limits you is the peer=E2=80=99s > willingness to increase your MAX_STREAM_ID, it=E2=80=99s just a question = of how > chatty you have to be =E2=80=93 which can matter if these messages are fa= irly small. > Agreed. -Ekr > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Sunday, October 1, 2017 2:03 PM > *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen > *Cc:* IETF QUIC WG > *Subject:* Re: Report on Unidirectional Streams in Minq > > > > I'm not sure I have any useful insights on this, as my implementation > handles them more or less the same. Can you explain why you think this > would be different with unidirectional versus bidirectional? > > > > -Ekr > > > > > > On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > > Thanks, > > > > I only skimmed this superfast, but one the observations appear to not > cover one of my key points: > > > > You can create and close uni-streams at at very high rate of many streams > per packet, without waiting for peer response, assuming the ACK framework > handles retransmission. Any insights on this? > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > On 1 October 2017 at 22.32.02, Eric Rescorla (ekr@rtfm.com) wrote: > > Hi folks, > > > > As promised I spent a bunch of time hacking unidirectional streams > > into Minq and I'm here to report back [0]. Specifically, I > > implemented: > > > > - PR#643 -- Unidirectional Streams > > - PR#720 -- Add bidirectional streams on top of unidirectional > > - A bidirectional stream API that mostly mimics Minq's original API > > for -05. > > > > The following is kind of a wall of text, so you could also skip this > > and refer to my slides [1]. > > > > > > MINQ'S -05 ARCHITECTURE > > API > > Minq's master object is the Connection, which has a list of Streams > > indexed by stream ID. Applications register a handler with the > > connection to be notified of new events. > > > > type ConnectionHandler interface { > > // The connection has changed state to state |s| > > StateChanged(s State) > > > > // A new stream has been created (by receiving a frame > > // from the other side. |s| contains the stream. > > NewStream(s *Stream) > > > > // Stream |s| is now readable. > > StreamReadable(s *Stream) > > } > > > > Streams get created in two ways: > > > > - Locally via Connection.CreateStream() > > - Remotely, in which case the application is notified via a callback to > > ConnectionHandler.NewStream(). > > > > Streams themselves have the APIs you would expect, namely, Read(), > > Write(), Close(), Reset(), etc. You get notified of stream readability > > by a callback to ConnectionHandler.StreamReadable(), at which point > > you can do Stream.Read(). As expected, Stream.Read() returns > > WOULDBLOCK when no data ia available > > > > > > INTERNALS > > As noted above, we start with the Connection object (only relevant fields > > shown): > > > > type Connection struct { > > handler ConnectionHandler > > streams []*Stream > > maxStream uint32 > > outputClearQ []frame // For stream 0 > > outputProtectedQ []frame // For stream >=3D 0 > > } > > > > As you can see, streams are in an array slice, so they're contiguously > > indexed by stream ID. Right now, I have no provision for reclaiming > > the unused bottom part of the array, but it would be straightforward > > to index by |streamId| - |minStream|, which I think is consistent with > > the design implied by the requirement to create streams in sequence. > > > > Because Streams are bidirectional, each stream actually consists of a > > pair of half streams. > > > > type streamHalf struct { > > s *stream // pointer to parent > > log loggingFunction > > dir direction // Sending or receiving > > closed bool // Is the half-stream closed > > offset uint64 // The > > chunks []streamChunk > > maxStreamData uint64 > > } > > > > // Internal object to allow unit testing. > > type stream struct { > > id uint32 > > log loggingFunction > > state streamState > > send, recv *streamHalf > > blocked bool // Have we returned blocked > > } > > > > // Public API object, which needs access to the Connection > > type Stream struct { > > c *Connection > > stream > > } > > > > Outgoing data is enqueued into |stream.chunks|, and then periodically > > the connection polls the stream for all the chunks which are permitted > > by stream-level flow control and enqueues them into > > |Connection.outputClearQ| or |Connection.outputProtectedQ|. At this > > point, the connection owns the data and is responsible for > > transmitting it, subject to connection-level flow control, and > > (presumably) congestion control once I have that implemented [2]. > > > > Incoming data gets queued (sorted) into |stream.chunks| for later > > reassembly at the time when someone calls stream.read(). I'm not sure > > I love this, because it means I don't have a good view of the incoming > > queue size (which I'd need to account for separately), but it allowed > > me to share data structures between incoming and outgoing, which > > seemed kind of natural when I did it (this architecture is replicated > > in the unidirectional streams design, but it's probably less natural > > there). > > > > > > UNIDIRECTIONAL STREAMS ARCHITECTURE > > UNIDIRECTIONAL API > > With the unidirectional branch, Minq offers two APIs. The first is a > > straightforward mapping of PR#720, in which we have two objects: > > > > SendStream -- used for writing > > RecvStream -- used for reading > > > > As before, we have a handler object, but it's directional now: > > > > type ConnectionHandler interface { > > // The connection has changed state to state |s| > > StateChanged(s State) > > > > // A new receiving stream has been created (by receiving a frame > > // from the other side. |s| contains the stream. > > NewRecvStream(s *RecvStream) > > > > // Stream |s| is now readable. > > StreamReadable(s *RecvStream) > > } > > > > Obviously SendStreams are locally created and RecvStreams are remotely > > created. SendStreams can be created using > > Connection.CreateSendStream() and you learn about remotely created > > RecvStreams by a callback to ConnectionHandler.NewRecvStream(). > > Second-created streams can be marked as "related" to a single > > first-created stream, using Connection.CreateRelatedSendStream() with > > the appropriate RecvStream as the argument [3]. Streams have a > > Related() API to tell you if they are related to some other stream. > > > > The {Send,Recv}Stream APIs are about what you'd expect. You can > > Write() on SendStream and Read() on RecvStream(). Right now, you can > > Close() and Reset() SendStreams, but not do anything on RecvStreams() > > or than ignore them. Eventually I'll probably offer > > RecvStream().Mute() or something to let you send STOP_SENDING. > > > > > > BIDIRECTIONAL API > > Minq also includes a bidirectional API that's layered on top of > > unidirectional streams. I've created a Connection2 structure that's > > intended as a wrapper around Connection [4]: > > > > type Connection2 struct { > > Connection > > shim *connection2ShimHandler > > streams []*Stream // Odd for client originated, even for server. > > } > > > > type Stream struct { > > id uint32 > > send *SendStream > > recv *RecvStream > > } > > > > Basically, Stream is just a pair of SendStream and RecvStream and > > Connection2 does the bookkeeping to keep them connected (I even do the > > odd/even ID thing that QUIC-05 has). Connection2 has the same handler > > API as Minq for QUIC-05, and the shim is responsible for translating > > unidirectional events into bidirectional events. > > > > Internally, what's going on here is that when you call CreateStream() > > Minq creates a Stream with a nil RecvStream. When a new remote stream > > is detected, we check RecvStream.Related(). If they are related to an > > existing SendStream then we will in the relevant |Stream.send| slot. > > Otherwise, we create a new SendStream that's related to the incoming > > stream and notify the application of the creation of the new > > bidirectional stream. > > > > Note that this all works fine if one side does the undirectional API > > and one does the bidirectional API. My test programs actually exercise > > this. Of course, there's an assumption that the peer conforms to a 1:1 > > mapping. If we define unidirectional streams, we'll need some protocol > > mechanism to know if the other side is exercising this level of > > increased flexibility or not. I can imagine a number of options here > > (e.g., ALPN). We could also forbid 1:N mappings but I think that > > would be a mistake as it's a cool feature/benefit of doing > > unidirectional. > > > > The entire bidirectional wrapper shim is < 150 lines of Go code. > > (https://github.com/ekr/minq/blob/unidirectional_streams/bidi.go > > ). > > Converting my test application to this API was a matter of just > > changing class names, e.g., s/Connectionb/Connection2/. > > > > In my implementation, I assume that at the time Minq hears about a > > stream, you know if its related to a given existing stream. That way > > you can immediately either associate it with that stream or make a new > > local stream. In my implementation, I always send Related Stream Id > > and assume that you never get an "unrelated" stream frame before a > > "related" one. The spec doesn't really require that right now, and > > offline MT suggested just sending related with offset=3D0 but I think > > that's a mistake, because it means that you need to hold stream frames > > in some provisional "undetermined" state until you get that frame. I > > would suggest instead that we require that you include the field until > > one of the frames is ACKed. > > > > > > INTERNALS > > Sending and receiving streams still share a lot of common components: > > > > type baseStream struct { > > state streamState > > id uint32 > > log loggingFunction > > offset uint64 > > chunks []streamChunk > > maxStreamData uint64 > > isRelated bool > > related uint32 > > } > > > > type sendStream struct { > > baseStream > > blocked bool > > } > > > > type recvStream struct { > > baseStream > > } > > > > Most of this is the same as with bidirectional streams. As above, > > it's probably possible to make them more asymmetrical. > > > > The connection maintains separate lists of sending and receiving > > streams and it's straightforward to create and access them without > > worrying about the odd/even stuff. > > > > > > COMPARISON > > At the end of the day, I think this shows that these designs aren't > > really that disssimilar. I was able to convert Minq to unidirectional > > streams in about 16 total hours of work (basically a long plane flight > > plus the next morning). While I had to make a bunch of changes to the > > internal structures, basically none of them modified anything tricky, > > and in particular the flow control mechanics and the like are > > basically unchanged, except for a bunch of mechanical-type > > transformations like referring to |sendStream.chunks| instead of > > |stream.send.chunks|. The only really new protocol machinery is the > > new frame format for related streams. > > > > There are a few pros/cons that are worth noting about these designs. > > > > - Without a bidirectional API, having unidirectional streams is more > > work for the programmer. However, with an API shim, the difference > > is trivial. > > > > - Because undirectional streams are inherently more flexible, it's > > possible for the sides to try to use different mappings, e.g., one > > side expects paired and the other expects 1:N. We'll need some way > > of making sure that doesn't happen, maybe ALPN? > > > > - The "Related Stream ID" frame indicator needs fleshing out a bit. > > From the application's perspective, it should never hear about a > > stream without knowing its related status. And as noted above, I > > think it would be best if we required that all "first flight" stream > > frames that are related include the fied > > > > - Undirectional streams kind of sharpen the confusion about exactly > > what kinds of "closure" we want to allow. Specifically, what should > > implementations be able to say about their willingness to receive? > > Right now we have STOP_SENDING, but that doesn't influence the > > sender's state. I don't think undirectional streams make this worse, > > they just require us to think it through some more. They do simplify > > the implementation of the closure state machine: in my QUIC-05 code, > > whenever one side closes I have to have checks to see if I should be > > transitioning to CLOSED or HALF-CLOSED, etc, which is odd because > > the directions are basically independent. It would probably be > > easier even in QUIC-05 not to reify these states but just to > > determine the state from the composition of the individual > > sub-states > > > > - Unidirectional streams don't need the kind of annoying odd-even > > mechanics, which was easier to code up (just having to create all > > the lower-numbered streams of the same parity is kind of a pain). > > One additional benefit here is that with QUIC-05 there are several > > messages which involve implicit stream creation (e.g., > > STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether > > the stream is one that should have been created locally or > > remotely. This just doesn't happen with bidirectional streams; I do > > implement odd/even mechanics but because the other side has to have > > its stream ids increment by one, I can make sure that they have the > > right IDs by construction and just check to see if the stream exists > > in these cases. I'd like to see us get rid of odd/even no matter > > what. > > > > - Unidirectional streams also helps avoid some of the corner cases around > > bidirectional streams. Specifically, suppose I am the client and > > I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed > > to just start sending or not? You can sort of get into this situation > > with unidirectional streams, but because it's explicit, one might > > hope that the application semantics would require clear specification. > > > > - As noted above, bidirectional streams are more flexible because they > > let you have mappings that you can't have with unidirectional > > streams (unpaired, 1:N). > > > > > > Happy to answer more questions if people have them. Otherwise we can > > talk about this in Seattle. > > > > -Ekr > > > > > > [0] https://github.com/ekr/minq/tree/unidirectional_streams > > > [1] https://github.com/ekr/wg-materials/blob/ > 404898fa2d2f0a9f9bd244d2c945e66ea88502a2/interim-17-10/ > Unidirectional%20Streams%20in%20Minq.pdf > > > [2] Thanks to Patrick McManus for suggesting this design. > > [3] In C++, you would have a single function with a default argument of > > |nullptr| but Go doesn't support that, hence two different arguments. > > [4] For implementation reasons, it's actually using Connection as a mixin= , > > which means it's simultaneously possible to use the unidirectional > > and bidirectional APIs, but that's going to cause a lot of confusion. > > A real implementation would probably have to either commit to one > > or the other or do a real wrapper, so you could only use one set of > > APIs, at the cost of having to do more forwarded methods. > > > > > > > > > > > > > > > > > > > > > > > --089e0828b4f0136d1b055a82f49a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 1, 2017 at 2:19 PM, Mike Bishop <Michael.Bishop= @microsoft.com> wrote:

I think the difference is for the scenario where you= don=E2=80=99t expect a peer to respond (or don=E2=80=99t expect them to re= spond stream-by-stream).=C2=A0 With -05, the receiver still needs to send S= TREAM(offset=3D0,FIN) on each stream.


=
Nit: Can't you send RESET_STREAM?

= =C2=A0

=C2=A0 With either unidirectional proposal, this pattern is a bit cleaner.=C2=A0 In #656, the sender can ess= entially say, =E2=80=9CDon=E2=80=99t bother=E2=80=9D at the time of stream = creation.=C2=A0 In #643, there=E2=80=99s no corresponding channel to close.=


Yes, I agree that this is = cleaner. Note that in #643 you presumably need to have some way of signalin= g that you don't want a return connection....

=

In all cases, the only thing that really limits you = is the peer=E2=80=99s willingness to increase your MAX_STREAM_ID, it=E2=80= =99s just a question of how chatty you have to be =E2=80=93 which can matte= r if these messages are fairly small.


=
Agreed.

-Ekr
=C2=A0

=

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Sunday, October 1, 2017 2:03 PM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Report on Unidirectional Streams in Minq<= /p>

=C2=A0

I'm not sure I have any useful insights on this,= as my implementation handles them more or less the same. Can you explain w= hy you think this would be different with unidirectional versus bidirection= al?

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=C3=B8e J= =C3=B8rgensen <m= ikkelfj@gmail.com> wrote:

Thanks,

=C2=A0

I only skimmed this superfast, but one the observ= ations appear to not cover one of my key points:

=C2=A0

You can create and close uni-streams at at very h= igh rate of many streams per packet, without waiting for peer response, ass= uming the ACK framework handles retransmission. Any insights on this?

=C2=A0

Kind Regards,

Mikkel Fahn=C3=B8e= J=C3=B8rgensen

=C2=A0

On 1 Octob= er 2017 at 22.32.02, Eric Rescorla (ekr@rtfm.com) wrote:

Hi folks,

=C2=A0

As promised I spent a bunch of time hacking unidirec= tional streams

into Minq and I'm here to report back [0]. Speci= fically, I

implemented:

=C2=A0

=C2=A0 - PR#643 -- Unidirectional Streams<= /u>

=C2=A0 - PR#720 -- Add bidirectional streams on top = of unidirectional

=C2=A0 - A bidirectional stream API that mostly mimi= cs Minq's original API

=C2=A0 =C2=A0 for -05.

=C2=A0 =C2=A0=C2=A0

The following is kind of a wall of text, so you coul= d also skip this

and refer to my slides [1].

=C2=A0

=C2=A0

MINQ'S -05 ARCHITECTURE

API

Minq's master object is the Connection, which ha= s a list of Streams

indexed by stream ID. Applications register a handle= r with the

connection to be notified of new events.

=C2=A0

=C2=A0 =C2=A0type ConnectionHandler interface {

=C2=A0 =C2=A0 // The connection has changed state to= state |s|

=C2=A0 =C2=A0 StateChanged(s State)

=C2=A0 =C2=A0

=C2=A0 =C2=A0 // A new stream has been created (by r= eceiving a frame

=C2=A0 =C2=A0 // from the other side. |s| contains t= he stream.

=C2=A0 =C2=A0 NewStream(s *Stream)

=C2=A0 =C2=A0

=C2=A0 =C2=A0 // Stream |s| is now readable.<= u>

=C2=A0 =C2=A0 StreamReadable(s *Stream)

=C2=A0 =C2=A0}

=C2=A0

Streams get created in two ways:

=C2=A0

- Locally via Connection.CreateStream()

- Remotely, in which case the application is notifie= d via a callback to

=C2=A0 ConnectionHandler.NewStream().<= /p>

=C2=A0

Streams themselves have the APIs you would expect, n= amely, Read(),

Write(), Close(), Reset(), etc. You get notified of = stream readability

by a callback to ConnectionHandler.StreamReadab= le(), at which point

you can do Stream.Read(). As expected, Stream.Read()= returns

WOULDBLOCK when no data ia available

=C2=A0

=C2=A0

INTERNALS

As noted above, we start with the Connection object = (only relevant fields

shown):

=C2=A0

=C2=A0 =C2=A0type Connection struct {<= /p>

=C2=A0 =C2=A0 handler=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ConnectionHandler

=C2=A0 =C2=A0 streams=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 []*Stream

=C2=A0 =C2=A0 maxStream=C2=A0 =C2=A0 =C2=A0 =C2=A0 u= int32

outputClearQ=C2=A0 =C2=A0 =C2=A0[]frame // For strea= m 0

outputProtectedQ []frame // For stream >=3D 0<= /u>

=C2=A0 =C2=A0}

=C2=A0

As you can see, streams are in an array slice, so th= ey're contiguously

indexed by stream ID. Right now, I have no provision= for reclaiming

the unused bottom part of the array, but it would be= straightforward

to index by |streamId| - |minStream|, which I think = is consistent with

the design implied by the requirement to create stre= ams in sequence.

=C2=A0

Because Streams are bidirectional, each stream actua= lly consists of a

pair of half streams.

=C2=A0

=C2=A0 =C2=A0type streamHalf struct {<= /p>

=C2=A0 =C2=A0 s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// pointer to = parent

=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0loggingFunction=C2=A0 =C2=A0

=C2=A0 =C2=A0 dir=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0direction=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Sending or receiving=

=C2=A0 =C2=A0 closed=C2=A0 =C2=A0 =C2=A0 =C2=A0 bool= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Is the half-stream clos= ed

=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint= 64=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // The

=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []st= reamChunk

=C2=A0 =C2=A0 maxStreamData uint64

=C2=A0 =C2=A0}

=C2=A0

=C2=A0 =C2=A0// Internal object to allow unit testin= g.

=C2=A0 =C2=A0type stream struct {

=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ui= nt32

=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 logging= Function

=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 streamState<= u>

=C2=A0 =C2=A0 send, recv *streamHalf

=C2=A0 blocked=C2=A0 =C2=A0 bool // Have we returned= blocked

=C2=A0 =C2=A0}

=C2=A0

=C2=A0 =C2=A0// Public API object, which needs acces= s to the Connection

=C2=A0 =C2=A0type Stream struct {

=C2=A0 =C2=A0 c *Connection

=C2=A0 =C2=A0 stream

=C2=A0 =C2=A0}

=C2=A0

Outgoing data is enqueued into |stream.chunks|, and = then periodically

the connection polls the stream for all the chunks w= hich are permitted

by stream-level flow control and enqueues them into<= u>

|Connection.outputClearQ| or |Connection.outputProte= ctedQ|. At this

point, the connection owns the data and is responsib= le for

transmitting it, subject to connection-level flow co= ntrol, and

(presumably) congestion control once I have that imp= lemented [2].

=C2=A0

Incoming data gets queued (sorted) into |stream.chun= ks| for later

reassembly at the time when someone calls stream.rea= d(). I'm not sure

I love this, because it means I don't have a goo= d view of the incoming

queue size (which I'd need to account for separa= tely), but it allowed

me to share data structures between incoming and out= going, which

seemed kind of natural when I did it (this architect= ure is replicated

in the unidirectional streams design, but it's p= robably less natural

there).

=C2=A0

=C2=A0

UNIDIRECTIONAL STREAMS ARCHITECTURE

UNIDIRECTIONAL API

With the unidirectional branch, Minq offers two APIs= . The first is a

straightforward mapping of PR#720, in which we have = two objects:

=C2=A0

=C2=A0 SendStream -- used for writing<= /p>

=C2=A0 RecvStream -- used for reading<= /p>

=C2=A0

As before, we have a handler object, but it's di= rectional now:

=C2=A0

=C2=A0 =C2=A0type ConnectionHandler interface {

=C2=A0 =C2=A0 // The connection has changed state to= state |s|

=C2=A0 =C2=A0 StateChanged(s State)

=C2=A0 =C2=A0

=C2=A0 =C2=A0 // A new receiving stream has been cre= ated (by receiving a frame

=C2=A0 =C2=A0 // from the other side. |s| contains t= he stream.

=C2=A0 =C2=A0 NewRecvStream(s *RecvStream)=

=C2=A0 =C2=A0

=C2=A0 =C2=A0 // Stream |s| is now readable.<= u>

=C2=A0 =C2=A0 StreamReadable(s *RecvStream)

=C2=A0 =C2=A0}

=C2=A0

Obviously SendStreams are locally created and RecvSt= reams are remotely

created. SendStreams can be created using<= /u>

Connection.CreateSendStream() and you learn about re= motely created

RecvStreams by a callback to ConnectionHandler.= NewRecvStream().

Second-created streams can be marked as "relate= d" to a single

first-created stream, using Connection.CreateRe= latedSendStream() with

the appropriate RecvStream as the argument [3]. Stre= ams have a

Related() API to tell you if they are related to som= e other stream.

=C2=A0

The {Send,Recv}Stream APIs are about what you'd = expect. You can

Write() on SendStream and Read() on RecvStream(). Ri= ght now, you can

Close() and Reset() SendStreams, but not do anything= on RecvStreams()

or than ignore them. Eventually I'll probably of= fer

RecvStream().Mute() or something to let you send STO= P_SENDING.

=C2=A0

=C2=A0

BIDIRECTIONAL API

Minq also includes a bidirectional API that's la= yered on top of

unidirectional streams. I've created a Connectio= n2 structure that's

intended as a wrapper around Connection [4]:<= u>

=C2=A0

=C2=A0 =C2=A0type Connection2 struct {=

=C2=A0 =C2=A0 Connection

=C2=A0 =C2=A0 shim=C2=A0 =C2=A0 *connection2ShimHand= ler

=C2=A0 =C2=A0 streams []*Stream // Odd for client or= iginated, even for server.

=C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0type Stream struct {

=C2=A0 =C2=A0 id=C2=A0 =C2=A0uint32

=C2=A0 =C2=A0 send *SendStream

=C2=A0 =C2=A0 recv *RecvStream

=C2=A0 =C2=A0}

=C2=A0

Basically, Stream is just a pair of SendStream and R= ecvStream and

Connection2 does the bookkeeping to keep them connec= ted (I even do the

odd/even ID thing that QUIC-05 has). Connection2 has= the same handler

API as Minq for QUIC-05, and the shim is responsible= for translating

unidirectional events into bidirectional events.<= /u>

=C2=A0

Internally, what's going on here is that when yo= u call CreateStream()

Minq creates a Stream with a nil RecvStream. When a = new remote stream

is detected, we check RecvStream.Related(). If they = are related to an

existing SendStream then we will in the relevant |St= ream.send| slot.

Otherwise, we create a new SendStream that's rel= ated to the incoming

stream and notify the application of the creation of= the new

bidirectional stream.

=C2=A0

Note that this all works fine if one side does the u= ndirectional API

and one does the bidirectional API. My test programs= actually exercise

this. Of course, there's an assumption that the = peer conforms to a 1:1

mapping. If we define unidirectional streams, we'= ;ll need some protocol

mechanism to know if the other side is exercising th= is level of

increased flexibility or not. I can imagine a number= of options here

(e.g., ALPN).=C2=A0 We could also forbid 1:N mapping= s but I think that

would be a mistake as it's a cool feature/benefi= t of doing

unidirectional.

=C2=A0

The entire bidirectional wrapper shim is < 150 li= nes of Go code.

Converting my test application to this API was a mat= ter of just

changing class names, e.g., s/Connectionb/Connection= 2/.

=C2=A0

In my implementation, I assume that at the time Minq= hears about a

stream, you know if its related to a given existing = stream.=C2=A0 That way

you can immediately either associate it with that st= ream or make a new

local stream. In my implementation, I always send Re= lated Stream Id

and assume that you never get an "unrelated&quo= t; stream frame before a

"related" one. The spec doesn't really= require that right now, and

offline MT suggested just sending related with offse= t=3D0 but I think

that's a mistake, because it means that you need= to hold stream frames

in some provisional "undetermined" state u= ntil you get that frame. I

would suggest instead that we require that you inclu= de the field until

one of the frames is ACKed.

=C2=A0=C2=A0

=C2=A0

INTERNALS

Sending and receiving streams still share a lot of c= ommon components:

=C2=A0

=C2=A0 =C2=A0 type baseStream struct {=

=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0streamState

=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 uint32

=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0loggingFunction

=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint= 64

=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []st= reamChunk

=C2=A0 =C2=A0 maxStreamData uint64

=C2=A0 =C2=A0 isRelated=C2=A0 =C2=A0 =C2=A0bool

=C2=A0 =C2=A0 related=C2=A0 =C2=A0 =C2=A0 =C2=A0uint= 32

=C2=A0 =C2=A0 }

=C2=A0 =C2=A0=C2=A0

=C2=A0 =C2=A0 type sendStream struct {=

=C2=A0 =C2=A0 baseStream

=C2=A0 =C2=A0 blocked bool

=C2=A0 =C2=A0 }

=C2=A0 =C2=A0=C2=A0

=C2=A0 =C2=A0 type recvStream struct {=

=C2=A0 =C2=A0 baseStream

=C2=A0 =C2=A0 }

=C2=A0

Most of this is the same as with bidirectional strea= ms.=C2=A0 As above,

it's probably possible to make them more asymmet= rical.

=C2=A0

The connection maintains separate lists of sending a= nd receiving

streams and it's straightforward to create and a= ccess them without

worrying about the odd/even stuff.

=C2=A0

=C2=A0

COMPARISON

At the end of the day, I think this shows that these= designs aren't

really that disssimilar. I was able to convert Minq = to unidirectional

streams in about 16 total hours of work (basically a= long plane flight

plus the next morning). While I had to make a bunch = of changes to the

internal structures, basically none of them modified= anything tricky,

and in particular the flow control mechanics and the= like are

basically unchanged, except for a bunch of mechanica= l-type

transformations like referring to |sendStream.chunks= | instead of

|stream.send.chunks|. The only really new protocol m= achinery is the

new frame format for related streams.<= /p>

=C2=A0

There are a few pros/cons that are worth noting abou= t these designs.

=C2=A0

- Without a bidirectional API, having unidirectional= streams is more

=C2=A0 work for the programmer. However, with an API= shim, the difference

=C2=A0 is trivial.

=C2=A0

- Because undirectional streams are inherently more = flexible, it's

=C2=A0 possible for the sides to try to use differen= t mappings, e.g., one

=C2=A0 side expects paired and the other expects 1:N= . We'll need some way

=C2=A0 of making sure that doesn't happen, maybe= ALPN?

=C2=A0

- The "Related Stream ID" frame indicator = needs fleshing out a bit.

=C2=A0 From the application's perspective, it sh= ould never hear about a

=C2=A0 stream without knowing its related status. An= d as noted above, I

=C2=A0 think it would be best if we required that al= l "first flight" stream

=C2=A0 frames that are related include the fied

=C2=A0

- Undirectional streams kind of sharpen the confusio= n about exactly

=C2=A0 what kinds of "closure" we want to = allow. Specifically, what should

=C2=A0 implementations be able to say about their wi= llingness to receive?

=C2=A0 Right now we have STOP_SENDING, but that does= n't influence the

=C2=A0 sender's state. I don't think undirec= tional streams make this worse,

=C2=A0 they just require us to think it through some= more. They do simplify

=C2=A0 the implementation of the closure state machi= ne: in my QUIC-05 code,

=C2=A0 whenever one side closes I have to have check= s to see if I should be

=C2=A0 transitioning to CLOSED or HALF-CLOSED, etc, = which is odd because

=C2=A0 the directions are basically independent.=C2= =A0 It would probably be

=C2=A0 easier even in QUIC-05 not to reify these sta= tes but just to

=C2=A0 determine the state from the composition of t= he individual

=C2=A0 sub-states

=C2=A0=C2=A0

- Unidirectional streams don't need the kind of = annoying odd-even

=C2=A0 mechanics, which was easier to code up (just = having to create all

=C2=A0 the lower-numbered streams of the same parity= is kind of a pain).

=C2=A0 One additional benefit here is that with QUIC= -05 there are several

=C2=A0 messages which involve implicit stream creati= on (e.g.,

=C2=A0 STREAM_MAX_DATA, and RST_STREAM) and so you n= eed to check whether

=C2=A0 the stream is one that should have been creat= ed locally or

=C2=A0 remotely. This just doesn't happen with b= idirectional streams; I do

=C2=A0 implement odd/even mechanics but because the = other side has to have

=C2=A0 its stream ids increment by one, I can make s= ure that they have the

=C2=A0 right IDs by construction and just check to s= ee if the stream exists

=C2=A0 in these cases.=C2=A0 I'd like to see us = get rid of odd/even no matter

=C2=A0 what.

=C2=A0

- Unidirectional streams also helps avoid some of th= e corner cases around

=C2=A0 bidirectional streams. Specifically, suppose = I am the client and

=C2=A0 I get MAX_STREAM_DATA as the first frame on s= tream 2. Am I allowed

=C2=A0 to just start sending or not? You can sort of= get into this situation

=C2=A0 with unidirectional streams, but because it&#= 39;s explicit, one might

=C2=A0 hope that the application semantics would req= uire clear specification.

=C2=A0=C2=A0

- As noted above, bidirectional streams are more fle= xible because they

=C2=A0 let you have mappings that you can't have= with unidirectional

=C2=A0 streams (unpaired, 1:N).

=C2=A0

=C2=A0

Happy to answer more questions if people have them. = Otherwise we can

talk about this in Seattle.

=C2=A0

-Ekr

=C2=A0

=C2=A0

[2] Thanks to Patrick McManus for suggesting this de= sign.

[3] In C++, you would have a single function with a = default argument of

=C2=A0 =C2=A0 |nullptr| but Go doesn't support t= hat, hence two different arguments.

[4] For implementation reasons, it's actually us= ing Connection as a mixin,

=C2=A0 =C2=A0 which means it's simultaneously po= ssible to use the unidirectional

=C2=A0 =C2=A0 and bidirectional APIs, but that's= going to cause a lot of confusion.

=C2=A0 =C2=A0 A real implementation would probably h= ave to either commit to one

=C2=A0 =C2=A0 or the other or do a real wrapper, so = you could only use one set of

=C2=A0 =C2=A0 APIs, at the cost of having to do more= forwarded methods.

=C2=A0 =C2=A0=C2=A0

=C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0


--089e0828b4f0136d1b055a82f49a-- From nobody Sun Oct 1 14:38: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 B2F6E134B5F for ; Sun, 1 Oct 2017 14:38:32 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gzyNTO3_xQzb for ; Sun, 1 Oct 2017 14:38:28 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79978134B5D for ; Sun, 1 Oct 2017 14:38:28 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id o143so2604114ywd.12 for ; Sun, 01 Oct 2017 14:38: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=D6n6x1mnfm5bZY2bp/N+OhBGGTrrJ2Ud3Mqg5t8cksE=; b=Q7/YZ3aUWRLzbvNYt8ZbHwGPMUqhgZazi5IfE6TIjcKzsEo1JzGgu+X9my17LlWY2q EJxQtU859w5V2R4iR0XR2okLTcRpFV3oimQYW0fqfhcw9bFY3dpzCdkzy/Oi6tFeMAy/ maqMsxyFLfuDTsEsqfsNhzgbP9JWiXmpaCxEhTOLKLufNlLkmvSLTMEvG0/lsXqeP1E1 b3OW1X73XbIbTXDTnBbd94p6UYB92mZwWUPMTp3HFO1YFd/NSy1oCNAnveRc0dHvsJDS Y563ipdbgfKEzwclf223iq7zxwPN6r6c6u3dYF21svBbjdh6JCIyRKlcL4obhHrGVuq8 knhA== 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=D6n6x1mnfm5bZY2bp/N+OhBGGTrrJ2Ud3Mqg5t8cksE=; b=Y1iCnwJj662JyZExJybEvpGl1gh+BnmPRfl6eVGoz/2S7iwTo95hynQL9fX71EE8UA eKJO60cDXvy/anVh4ZSq0UUlJFVPOKnslKasM5N+zsJ5jXj1lFHx8q9/FSgri3k7bpwL EvfJUwucjMn7vZC53kk9GcSW4tK7nH9jLlCbroiL1Qs8wJWW83LHUaxNcIewyhhYNXQE lT5a8pnnQFuNZde1LYEcdIIwntCa6xl6u3Xn7jTQF+SWpkvASJ+UCDDs+2AbzcB32DLN h7ZvFrGIwxIRmiBxx6tuMSdUV/leZGG6FrzxaV7VRmDco5p5jz0CdqT/yBYnwW6lel5J YoPg== X-Gm-Message-State: AHPjjUi9rbkRKhsvuaqFdvQyiDMft5m2IpKhDc0wVJ4+tvus3TDvbF53 22icxOQEx21TaccK43zK1Xwty9RxgR4tlh9EK8dUpg== X-Google-Smtp-Source: AOwi7QDpl1WiESEylQH4/QGjR0BzrLCAX0D8vzGbJOS525EYis+KX0HVOAujYgVuHcbACjI0Se5pTd3jVfCppWsTg+4= X-Received: by 10.129.178.69 with SMTP id q66mr11194705ywh.290.1506893907688; Sun, 01 Oct 2017 14:38:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Sun, 1 Oct 2017 14:37:47 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 1 Oct 2017 14:37:47 -0700 Message-ID: Subject: Re: Report on Unidirectional Streams in Minq To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c146268153379055a831402" 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, 01 Oct 2017 21:38:32 -0000 --94eb2c146268153379055a831402 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 1, 2017 at 2:24 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > Can you explain why you think this would be different with unidirectional > versus bidirectional? > > > A stream needs to keep various data structures alive to recognise input o= n > the wire, and requests from the user to access read buffers. If it is > possible to receive data then those structures cannot be torn down before= a > FIN or RST is received by peer. > Hmm... Maybe. If I don't care about the data, why can't I just send STOP_SENDING and then discard any incoming packets? I see that presently S 12 requires the receiver to enforce flow control limits even after sending STOP_SENDING ( https://quicwg.github.io/base-drafts/draft-ietf-quic-transport.html#flow-co= ntrol) "A receiver MUST close the connection with a FLOW_CONTROL_ERROR error (Sect= ion 12 ) if the peer violates the advertised connection or stream data limits." but presumably we could relax that restriction, in which case you could just treat the stream as closed and discard all associated state. Some streams may be practically uni-directional, but the transport cannot > know without application protocol saying so via the API surface. > Yes, I agree with that, but why can't the stack just provide a "Discard()" method on the stream that does the above? > This means the state needs to stay online for at least a roundtrip, plus > any processing delays the peer may have. A hostile peer could indefinitel= y > delay closing a stream. > I don't think I agree with this, for the reasons I indicated above. -Ekr Simulated bi-directional streams on top of uni-directional streams may have > some of the contains of proper bi-directional streams depending on the > exact close semantics chosen, but in this case it is probably a desirable > feature. > > In conclusion, uni-directional streams ought to support much higher > bandwidth messaging over independent streams - like if you have many > micro-services sending async messages through the same connection. > > For a very basic QUIC implementation the difference might not be so > drastic since you can just allocate a map structure and garbage collect i= t > when done. For a high performance implementation it matters a lot more. > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 1 October 2017 at 23.04.03, Eric Rescorla (ekr@rtfm.com) wrote: > > I'm not sure I have any useful insights on this, as my implementation > handles them more or less the same. Can you explain why you think this > would be different with unidirectional versus bidirectional? > > -Ekr > > > On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < > mikkelfj@gmail.com> wrote: > >> Thanks, >> >> I only skimmed this superfast, but one the observations appear to not >> cover one of my key points: >> >> You can create and close uni-streams at at very high rate of many stream= s >> per packet, without waiting for peer response, assuming the ACK framewor= k >> handles retransmission. Any insights on this? >> >> Kind Regards, >> Mikkel Fahn=C3=B8e J=C3=B8rgensen >> >> >> On 1 October 2017 at 22.32.02, Eric Rescorla (ekr@rtfm.com) wrote: >> >> Hi folks, >> >> As promised I spent a bunch of time hacking unidirectional streams >> into Minq and I'm here to report back [0]. Specifically, I >> implemented: >> >> - PR#643 -- Unidirectional Streams >> - PR#720 -- Add bidirectional streams on top of unidirectional >> - A bidirectional stream API that mostly mimics Minq's original API >> for -05. >> >> The following is kind of a wall of text, so you could also skip this >> and refer to my slides [1]. >> >> >> MINQ'S -05 ARCHITECTURE >> API >> Minq's master object is the Connection, which has a list of Streams >> indexed by stream ID. Applications register a handler with the >> connection to be notified of new events. >> >> type ConnectionHandler interface { >> // The connection has changed state to state |s| >> StateChanged(s State) >> >> // A new stream has been created (by receiving a frame >> // from the other side. |s| contains the stream. >> NewStream(s *Stream) >> >> // Stream |s| is now readable. >> StreamReadable(s *Stream) >> } >> >> Streams get created in two ways: >> >> - Locally via Connection.CreateStream() >> - Remotely, in which case the application is notified via a callback to >> ConnectionHandler.NewStream(). >> >> Streams themselves have the APIs you would expect, namely, Read(), >> Write(), Close(), Reset(), etc. You get notified of stream readability >> by a callback to ConnectionHandler.StreamReadable(), at which point >> you can do Stream.Read(). As expected, Stream.Read() returns >> WOULDBLOCK when no data ia available >> >> >> INTERNALS >> As noted above, we start with the Connection object (only relevant field= s >> shown): >> >> type Connection struct { >> handler ConnectionHandler >> streams []*Stream >> maxStream uint32 >> outputClearQ []frame // For stream 0 >> outputProtectedQ []frame // For stream >=3D 0 >> } >> >> As you can see, streams are in an array slice, so they're contiguously >> indexed by stream ID. Right now, I have no provision for reclaiming >> the unused bottom part of the array, but it would be straightforward >> to index by |streamId| - |minStream|, which I think is consistent with >> the design implied by the requirement to create streams in sequence. >> >> Because Streams are bidirectional, each stream actually consists of a >> pair of half streams. >> >> type streamHalf struct { >> s *stream // pointer to parent >> log loggingFunction >> dir direction // Sending or receiving >> closed bool // Is the half-stream closed >> offset uint64 // The >> chunks []streamChunk >> maxStreamData uint64 >> } >> >> // Internal object to allow unit testing. >> type stream struct { >> id uint32 >> log loggingFunction >> state streamState >> send, recv *streamHalf >> blocked bool // Have we returned blocked >> } >> >> // Public API object, which needs access to the Connection >> type Stream struct { >> c *Connection >> stream >> } >> >> Outgoing data is enqueued into |stream.chunks|, and then periodically >> the connection polls the stream for all the chunks which are permitted >> by stream-level flow control and enqueues them into >> |Connection.outputClearQ| or |Connection.outputProtectedQ|. At this >> point, the connection owns the data and is responsible for >> transmitting it, subject to connection-level flow control, and >> (presumably) congestion control once I have that implemented [2]. >> >> Incoming data gets queued (sorted) into |stream.chunks| for later >> reassembly at the time when someone calls stream.read(). I'm not sure >> I love this, because it means I don't have a good view of the incoming >> queue size (which I'd need to account for separately), but it allowed >> me to share data structures between incoming and outgoing, which >> seemed kind of natural when I did it (this architecture is replicated >> in the unidirectional streams design, but it's probably less natural >> there). >> >> >> UNIDIRECTIONAL STREAMS ARCHITECTURE >> UNIDIRECTIONAL API >> With the unidirectional branch, Minq offers two APIs. The first is a >> straightforward mapping of PR#720, in which we have two objects: >> >> SendStream -- used for writing >> RecvStream -- used for reading >> >> As before, we have a handler object, but it's directional now: >> >> type ConnectionHandler interface { >> // The connection has changed state to state |s| >> StateChanged(s State) >> >> // A new receiving stream has been created (by receiving a frame >> // from the other side. |s| contains the stream. >> NewRecvStream(s *RecvStream) >> >> // Stream |s| is now readable. >> StreamReadable(s *RecvStream) >> } >> >> Obviously SendStreams are locally created and RecvStreams are remotely >> created. SendStreams can be created using >> Connection.CreateSendStream() and you learn about remotely created >> RecvStreams by a callback to ConnectionHandler.NewRecvStream(). >> Second-created streams can be marked as "related" to a single >> first-created stream, using Connection.CreateRelatedSendStream() with >> the appropriate RecvStream as the argument [3]. Streams have a >> Related() API to tell you if they are related to some other stream. >> >> The {Send,Recv}Stream APIs are about what you'd expect. You can >> Write() on SendStream and Read() on RecvStream(). Right now, you can >> Close() and Reset() SendStreams, but not do anything on RecvStreams() >> or than ignore them. Eventually I'll probably offer >> RecvStream().Mute() or something to let you send STOP_SENDING. >> >> >> BIDIRECTIONAL API >> Minq also includes a bidirectional API that's layered on top of >> unidirectional streams. I've created a Connection2 structure that's >> intended as a wrapper around Connection [4]: >> >> type Connection2 struct { >> Connection >> shim *connection2ShimHandler >> streams []*Stream // Odd for client originated, even for server. >> } >> >> type Stream struct { >> id uint32 >> send *SendStream >> recv *RecvStream >> } >> >> Basically, Stream is just a pair of SendStream and RecvStream and >> Connection2 does the bookkeeping to keep them connected (I even do the >> odd/even ID thing that QUIC-05 has). Connection2 has the same handler >> API as Minq for QUIC-05, and the shim is responsible for translating >> unidirectional events into bidirectional events. >> >> Internally, what's going on here is that when you call CreateStream() >> Minq creates a Stream with a nil RecvStream. When a new remote stream >> is detected, we check RecvStream.Related(). If they are related to an >> existing SendStream then we will in the relevant |Stream.send| slot. >> Otherwise, we create a new SendStream that's related to the incoming >> stream and notify the application of the creation of the new >> bidirectional stream. >> >> Note that this all works fine if one side does the undirectional API >> and one does the bidirectional API. My test programs actually exercise >> this. Of course, there's an assumption that the peer conforms to a 1:1 >> mapping. If we define unidirectional streams, we'll need some protocol >> mechanism to know if the other side is exercising this level of >> increased flexibility or not. I can imagine a number of options here >> (e.g., ALPN). We could also forbid 1:N mappings but I think that >> would be a mistake as it's a cool feature/benefit of doing >> unidirectional. >> >> The entire bidirectional wrapper shim is < 150 lines of Go code. >> (https://github.com/ekr/minq/blob/unidirectional_streams/bidi.go). >> Converting my test application to this API was a matter of just >> changing class names, e.g., s/Connectionb/Connection2/. >> >> In my implementation, I assume that at the time Minq hears about a >> stream, you know if its related to a given existing stream. That way >> you can immediately either associate it with that stream or make a new >> local stream. In my implementation, I always send Related Stream Id >> and assume that you never get an "unrelated" stream frame before a >> "related" one. The spec doesn't really require that right now, and >> offline MT suggested just sending related with offset=3D0 but I think >> that's a mistake, because it means that you need to hold stream frames >> in some provisional "undetermined" state until you get that frame. I >> would suggest instead that we require that you include the field until >> one of the frames is ACKed. >> >> >> INTERNALS >> Sending and receiving streams still share a lot of common components: >> >> type baseStream struct { >> state streamState >> id uint32 >> log loggingFunction >> offset uint64 >> chunks []streamChunk >> maxStreamData uint64 >> isRelated bool >> related uint32 >> } >> >> type sendStream struct { >> baseStream >> blocked bool >> } >> >> type recvStream struct { >> baseStream >> } >> >> Most of this is the same as with bidirectional streams. As above, >> it's probably possible to make them more asymmetrical. >> >> The connection maintains separate lists of sending and receiving >> streams and it's straightforward to create and access them without >> worrying about the odd/even stuff. >> >> >> COMPARISON >> At the end of the day, I think this shows that these designs aren't >> really that disssimilar. I was able to convert Minq to unidirectional >> streams in about 16 total hours of work (basically a long plane flight >> plus the next morning). While I had to make a bunch of changes to the >> internal structures, basically none of them modified anything tricky, >> and in particular the flow control mechanics and the like are >> basically unchanged, except for a bunch of mechanical-type >> transformations like referring to |sendStream.chunks| instead of >> |stream.send.chunks|. The only really new protocol machinery is the >> new frame format for related streams. >> >> There are a few pros/cons that are worth noting about these designs. >> >> - Without a bidirectional API, having unidirectional streams is more >> work for the programmer. However, with an API shim, the difference >> is trivial. >> >> - Because undirectional streams are inherently more flexible, it's >> possible for the sides to try to use different mappings, e.g., one >> side expects paired and the other expects 1:N. We'll need some way >> of making sure that doesn't happen, maybe ALPN? >> >> - The "Related Stream ID" frame indicator needs fleshing out a bit. >> From the application's perspective, it should never hear about a >> stream without knowing its related status. And as noted above, I >> think it would be best if we required that all "first flight" stream >> frames that are related include the fied >> >> - Undirectional streams kind of sharpen the confusion about exactly >> what kinds of "closure" we want to allow. Specifically, what should >> implementations be able to say about their willingness to receive? >> Right now we have STOP_SENDING, but that doesn't influence the >> sender's state. I don't think undirectional streams make this worse, >> they just require us to think it through some more. They do simplify >> the implementation of the closure state machine: in my QUIC-05 code, >> whenever one side closes I have to have checks to see if I should be >> transitioning to CLOSED or HALF-CLOSED, etc, which is odd because >> the directions are basically independent. It would probably be >> easier even in QUIC-05 not to reify these states but just to >> determine the state from the composition of the individual >> sub-states >> >> - Unidirectional streams don't need the kind of annoying odd-even >> mechanics, which was easier to code up (just having to create all >> the lower-numbered streams of the same parity is kind of a pain). >> One additional benefit here is that with QUIC-05 there are several >> messages which involve implicit stream creation (e.g., >> STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether >> the stream is one that should have been created locally or >> remotely. This just doesn't happen with bidirectional streams; I do >> implement odd/even mechanics but because the other side has to have >> its stream ids increment by one, I can make sure that they have the >> right IDs by construction and just check to see if the stream exists >> in these cases. I'd like to see us get rid of odd/even no matter >> what. >> >> - Unidirectional streams also helps avoid some of the corner cases aroun= d >> bidirectional streams. Specifically, suppose I am the client and >> I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed >> to just start sending or not? You can sort of get into this situation >> with unidirectional streams, but because it's explicit, one might >> hope that the application semantics would require clear specification. >> >> - As noted above, bidirectional streams are more flexible because they >> let you have mappings that you can't have with unidirectional >> streams (unpaired, 1:N). >> >> >> Happy to answer more questions if people have them. Otherwise we can >> talk about this in Seattle. >> >> -Ekr >> >> >> [0] https://github.com/ekr/minq/tree/unidirectional_streams >> [1] https://github.com/ekr/wg-materials/blob/404898fa2d2f0a9f9bd >> 244d2c945e66ea88502a2/interim-17-10/Unidirectional% >> 20Streams%20in%20Minq.pdf >> [2] Thanks to Patrick McManus for suggesting this design. >> [3] In C++, you would have a single function with a default argument of >> |nullptr| but Go doesn't support that, hence two different arguments= . >> [4] For implementation reasons, it's actually using Connection as a mixi= n, >> which means it's simultaneously possible to use the unidirectional >> and bidirectional APIs, but that's going to cause a lot of confusion= . >> A real implementation would probably have to either commit to one >> or the other or do a real wrapper, so you could only use one set of >> APIs, at the cost of having to do more forwarded methods. >> >> >> >> >> >> >> >> >> >> >> > --94eb2c146268153379055a831402 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Oct 1, 2017 at 2:24 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mi= kkelfj@gmail.com> wrote:
Can you explain why you think this would be different with unidir= ectional versus bidirectional?


A stream= needs to keep various data structures alive to recognise input on the wire= , and requests from the user to access read buffers. If it is possible to r= eceive data then those structures cannot be torn down before a FIN or RST i= s received by peer.

Hmm... Mayb= e. If I don't care about the data, why can't I just send STOP_SENDI= NG and then discard any incoming packets? I see that presently S 12 require= s the receiver to enforce flow control limits even after sending STOP_SENDI= NG (https://quicwg.github.io/base-drafts/draft-ietf-quic-= transport.html#flow-control) "A receiver MUST close the connection= with a FLOW_CONTROL_ERROR error (= Section 12) if the peer violates the advertised connection or stream da= ta limits." but presumably we could relax that restriction, in which c= ase you could just treat the stream as closed and discard all associated st= ate.


Some streams may be practically uni= -directional, but the transport cannot know without application protocol sa= ying so via the API surface.

Ye= s, I agree with that, but why can't the stack just provide a "Disc= ard()" method on the stream that does the above?

<= div>=C2=A0
This means the state needs to stay online for at least = a roundtrip, plus any processing delays the peer may have. A hostile peer c= ould indefinitely delay closing a stream.

=
I don't think I agree with this, for the reasons I indicated= above.

-Ekr

Simulated bi-directional= streams on top of uni-directional streams may have some of the contains of= proper bi-directional streams depending on the exact close semantics chose= n, but in this case it is probably a desirable feature.

In conclusion, uni-direction= al streams ought to support much higher bandwidth messaging over independen= t streams - like if you have many micro-services sending async messages thr= ough the same connection.

For a very basic QUIC implementation the difference might = not be so drastic since you can just allocate a map structure and garbage c= ollect it when done. For a high performance implementation it matters a lot= more.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 1 October 2017 at 23.04.03, Eric Rescorla (ekr@rtfm.com) wrote:

I'm not sure I have any useful insights on this, as my implementation handles them more or less the same. Can you explain why you think this would be different with unidirectional versus bidirectional?

-Ekr


On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
Thanks,

I only skimmed this superfast, but one the observations appear to not cover one of my key points:

You can create and close uni-streams at at very high rate of many streams per packet, without waiting for peer response, assuming the ACK framework handles retransmission. Any insights on this?

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


O= n 1 October 2017 at 22.32.02, Eric Rescorla (= ekr@rtfm.com) wrote:

Hi folks,

As promised I spent a bunch of time hacking unidirectional streams
into Minq and I'm here to report back [0]. Specifically, I
implemented:

=C2=A0 - PR#643 -- Unidirectional Streams
=C2=A0 - PR#720 -- Add bidirectional streams on top of unidirectional
=C2=A0 - A bidirectional stream API that mostly mimics Minq's original API
=C2=A0 =C2=A0 for -05.
=C2=A0 =C2=A0=C2=A0
The following is kind of a wall of text, so you could also skip this
and refer to my slides [1].


MINQ'S -05 ARCHITECTURE
API
Minq's master object is the Connection, which has a list of Streams
indexed by stream ID. Applications register a handler with the
connection to be notified of new events.

=C2=A0 =C2=A0type ConnectionHandler interface {
=C2=A0 =C2=A0 // The connection has changed state to state |s|
=C2=A0 =C2=A0 StateChanged(s State)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // A new stream has been created (by receiving a frame
=C2=A0 =C2=A0 // from the other side. |s| contains the stream.
=C2=A0 =C2=A0 NewStream(s *Stream)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // Stream |s| is now readable.
=C2=A0 =C2=A0 StreamReadable(s *Stream)
=C2=A0 =C2=A0}

Streams get created in two ways:

- Locally via Connection.CreateStream()
- Remotely, in which case the application is notified via a callback to
=C2=A0 ConnectionHandler.NewStream().

Streams themselves have the APIs you would expect, namely, Read(),
Write(), Close(), Reset(), etc. You get notified of stream readability
by a callback to ConnectionHandler.StreamReadable(), at which point
you can do Stream.Read(). As expected, Stream.Read() returns
WOULDBLOCK when no data ia available


INTERNALS
As noted above, we start with the Connection object (only relevant fields
shown):

=C2=A0 =C2=A0type Connection struct {
=C2=A0 =C2=A0 handler=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ConnectionHandler
=C2=A0 =C2=A0 streams=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 []*Stream
=C2=A0 =C2=A0 maxStream=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
outputClearQ=C2=A0 =C2=A0 =C2=A0[]frame // For stream 0
outputProtectedQ []frame // For stream >=3D 0
=C2=A0 =C2=A0}

As you can see, streams are in an array slice, so they're contiguously
indexed by stream ID. Right now, I have no provision for reclaiming
the unused bottom part of the array, but it would be straightforward
to index by |streamId| - |minStream|, which I think is consistent with
the design implied by the requirement to create streams in sequence.

Because Streams are bidirectional, each stream actually consists of a
pair of half streams.

=C2=A0 =C2=A0type streamHalf struct {
=C2=A0 =C2=A0 s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0*stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// pointer to parent
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggingFunction=C2=A0 =C2=A0
=C2=A0 =C2=A0 dir=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0direction=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Sending or receiving
=C2=A0 =C2=A0 closed=C2=A0 =C2=A0 =C2=A0 =C2=A0 bool=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Is the half-stream closed
=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // The
=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []streamChunk
=C2=A0 =C2=A0 maxStreamData uint64
=C2=A0 =C2=A0}

=C2=A0 =C2=A0// Internal object to allow unit testing.
=C2=A0 =C2=A0type stream struct {
=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 loggingFunction
=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 streamState
=C2=A0 =C2=A0 send, recv *streamHalf
=C2=A0 blocked=C2=A0 =C2=A0 bool // Have we returned blocked
=C2=A0 =C2=A0}

=C2=A0 =C2=A0// Public API object, which needs access to the Connection
=C2=A0 =C2=A0type Stream struct {
=C2=A0 =C2=A0 c *Connection
=C2=A0 =C2=A0 stream
=C2=A0 =C2=A0}

Outgoing data is enqueued into |stream.chunks|, and then periodically
the connection polls the stream for all the chunks which are permitted
by stream-level flow control and enqueues them into
|Connection.outputClearQ| or |Connection.outputProtectedQ|. At this
point, the connection owns the data and is responsible for
transmitting it, subject to connection-level flow control, and
(presumably) congestion control once I have that implemented [2].

Incoming data gets queued (sorted) into |stream.chunks| for later
reassembly at the time when someone calls stream.read(). I'm not sure
I love this, because it means I don't have a good view of the incoming
queue size (which I'd need to account for separately), but it allowed
me to share data structures between incoming and outgoing, which
seemed kind of natural when I did it (this architecture is replicated
in the unidirectional streams design, but it's probably less natural
there).


UNIDIRECTIONAL STREAMS ARCHITECTURE
UNIDIRECTIONAL API
With the unidirectional branch, Minq offers two APIs. The first is a
straightforward mapping of PR#720, in which we have two objects:

=C2=A0 SendStream -- used for writing
=C2=A0 RecvStream -- used for reading

As before, we have a handler object, but it's directional now:

=C2=A0 =C2=A0type ConnectionHandler interface {
=C2=A0 =C2=A0 // The connection has changed state to state |s|
=C2=A0 =C2=A0 StateChanged(s State)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // A new receiving stream has been created (by receiving a frame
=C2=A0 =C2=A0 // from the other side. |s| contains the stream.
=C2=A0 =C2=A0 NewRecvStream(s *RecvStream)
=C2=A0 =C2=A0
=C2=A0 =C2=A0 // Stream |s| is now readable.
=C2=A0 =C2=A0 StreamReadable(s *RecvStream)
=C2=A0 =C2=A0}

Obviously SendStreams are locally created and RecvStreams are remotely
created. SendStreams can be created using
Connection.CreateSendStream() and you learn about remotely created
RecvStreams by a callback to ConnectionHandler.NewRecvStream().
Second-created streams can be marked as "related" to a single
first-created stream, using Connection.CreateRelatedSendStream() with
the appropriate RecvStream as the argument [3]. Streams have a
Related() API to tell you if they are related to some other stream.

The {Send,Recv}Stream APIs are about what you'd expect. You can
Write() on SendStream and Read() on RecvStream(). Right now, you can
Close() and Reset() SendStreams, but not do anything on RecvStreams()
or than ignore them. Eventually I'll probably offer
RecvStream().Mute() or something to let you send STOP_SENDING.


BIDIRECTIONAL API
Minq also includes a bidirectional API that's layered on top of
unidirectional streams. I've created a Connection2 structure that's
intended as a wrapper around Connection [4]:

=C2=A0 =C2=A0type Connection2 struct {
=C2=A0 =C2=A0 Connection
=C2=A0 =C2=A0 shim=C2=A0 =C2=A0 *connection2ShimHandler
=C2=A0 =C2=A0 streams []*Stream // Odd for client originated, even for server.
=C2=A0 =C2=A0}
=C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0type Stream struct {
=C2=A0 =C2=A0 id=C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 send *SendStream
=C2=A0 =C2=A0 recv *RecvStream
=C2=A0 =C2=A0}

Basically, Stream is just a pair of SendStream and RecvStream and
Connection2 does the bookkeeping to keep them connected (I even do the
odd/even ID thing that QUIC-05 has). Connection2 has the same handler
API as Minq for QUIC-05, and the shim is responsible for translating
unidirectional events into bidirectional events.

Internally, what's going on here is that when you call CreateStream()
Minq creates a Stream with a nil RecvStream. When a new remote stream
is detected, we check RecvStream.Related(). If they are related to an
existing SendStream then we will in the relevant |Stream.send| slot.
Otherwise, we create a new SendStream that's related to the incoming
stream and notify the application of the creation of the new
bidirectional stream.

Note that this all works fine if one side does the undirectional API
and one does the bidirectional API. My test programs actually exercise
this. Of course, there's an assumption that the peer conforms to a 1:1
mapping. If we define unidirectional streams, we'll need some protocol
mechanism to know if the other side is exercising this level of
increased flexibility or not. I can imagine a number of options here
(e.g., ALPN).=C2=A0 We could also forbid 1:N mappings but I think that
would be a mistake as it's a cool feature/benefit of doing
unidirectional.

The entire bidirectional wrapper shim is < 150 lines of Go code.
Converting my test application to this API was a matter of just
changing class names, e.g., s/Connectionb/Connection2/.

In my implementation, I assume that at the time Minq hears about a
stream, you know if its related to a given existing stream.=C2=A0 That way
you can immediately either associate it with that stream or make a new
local stream. In my implementation, I always send Related Stream Id
and assume that you never get an "unrelated" stream frame before a
"related" one. The spec doesn't really require tha= t right now, and
offline MT suggested just sending related with offset=3D0 but I think
that's a mistake, because it means that you need to hold stream frames
in some provisional "undetermined" state until you get that frame. I
would suggest instead that we require that you include the field until
one of the frames is ACKed.
=C2=A0=C2=A0

INTERNALS
Sending and receiving streams still share a lot of common components:

=C2=A0 =C2=A0 type baseStream struct {
=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0streamState
=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32
=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0loggingFunction
=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint64
=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []streamChunk
=C2=A0 =C2=A0 maxStreamData uint64
=C2=A0 =C2=A0 isRelated=C2=A0 =C2=A0 =C2=A0bool
=C2=A0 =C2=A0 related=C2=A0 =C2=A0 =C2=A0 =C2=A0uint32
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 type sendStream struct {
=C2=A0 =C2=A0 baseStream
=C2=A0 =C2=A0 blocked bool
=C2=A0 =C2=A0 }
=C2=A0 =C2=A0=C2=A0
=C2=A0 =C2=A0 type recvStream struct {
=C2=A0 =C2=A0 baseStream
=C2=A0 =C2=A0 }

Most of this is the same as with bidirectional streams.=C2=A0 As above,
it's probably possible to make them more asymmetrical.

The connection maintains separate lists of sending and receiving
streams and it's straightforward to create and access them without
worrying about the odd/even stuff.


COMPARISON
At the end of the day, I think this shows that these designs aren't
really that disssimilar. I was able to convert Minq to unidirectional
streams in about 16 total hours of work (basically a long plane flight
plus the next morning). While I had to make a bunch of changes to the
internal structures, basically none of them modified anything tricky,
and in particular the flow control mechanics and the like are
basically unchanged, except for a bunch of mechanical-type
transformations like referring to |sendStream.chunks| instead of
|stream.send.chunks|. The only really new protocol machinery is the
new frame format for related streams.

There are a few pros/cons that are worth noting about these designs.

- Without a bidirectional API, having unidirectional streams is more
=C2=A0 work for the programmer. However, with an API shim, the difference
=C2=A0 is trivial.

- Because undirectional streams are inherently more flexible, it's
=C2=A0 possible for the sides to try to use different mappings, e.g., one
=C2=A0 side expects paired and the other expects 1:N. We'll need some way
=C2=A0 of making sure that doesn't happen, maybe ALPN?

- The "Related Stream ID" frame indicator needs fleshi= ng out a bit.
=C2=A0 From the application's perspective, it should never hear about a
=C2=A0 stream without knowing its related status. And as noted above, I
=C2=A0 think it would be best if we required that all "first flight" stream
=C2=A0 frames that are related include the fied

- Undirectional streams kind of sharpen the confusion about exactly
=C2=A0 what kinds of "closure" we want to allow. Specifically, what should
=C2=A0 implementations be able to say about their willingness to receive?
=C2=A0 Right now we have STOP_SENDING, but that doesn't influence the
=C2=A0 sender's state. I don't think undirectional streams make this worse,
=C2=A0 they just require us to think it through some more. They do simplify
=C2=A0 the implementation of the closure state machine: in my QUIC-05 code,
=C2=A0 whenever one side closes I have to have checks to see if I should be
=C2=A0 transitioning to CLOSED or HALF-CLOSED, etc, which is odd because
=C2=A0 the directions are basically independent.=C2=A0 It would probably be
=C2=A0 easier even in QUIC-05 not to reify these states but just to
=C2=A0 determine the state from the composition of the individual
=C2=A0 sub-states
=C2=A0=C2=A0
- Unidirectional streams don't need the kind of annoying odd-even
=C2=A0 mechanics, which was easier to code up (just having to create all
=C2=A0 the lower-numbered streams of the same parity is kind of a pain).
=C2=A0 One additional benefit here is that with QUIC-05 there are several
=C2=A0 messages which involve implicit stream creation (e.g.,
=C2=A0 STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether
=C2=A0 the stream is one that should have been created locally or
=C2=A0 remotely. This just doesn't happen with bidirectional streams; I do
=C2=A0 implement odd/even mechanics but because the other side has to have
=C2=A0 its stream ids increment by one, I can make sure that they have the
=C2=A0 right IDs by construction and just check to see if the stream exists
=C2=A0 in these cases.=C2=A0 I'd like to see us get rid of odd/even no matter
=C2=A0 what.

- Unidirectional streams also helps avoid some of the corner cases around
=C2=A0 bidirectional streams. Specifically, suppose I am the client and
=C2=A0 I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed
=C2=A0 to just start sending or not? You can sort of get into this situation
=C2=A0 with unidirectional streams, but because it's explicit, one might
=C2=A0 hope that the application semantics would require clear specification.
=C2=A0=C2=A0
- As noted above, bidirectional streams are more flexible because they
=C2=A0 let you have mappings that you can't have with unidirectional
=C2=A0 streams (unpaired, 1:N).


Happy to answer more questions if people have them. Otherwise we can
talk about this in Seattle.

-Ekr


[2] Thanks to Patrick McManus for suggesting this design.
[3] In C++, you would have a single function with a default argument of
=C2=A0 =C2=A0 |nullptr| but Go doesn't support that, hence two different arguments.
[4] For implementation reasons, it's actually using Connection as a mixin,
=C2=A0 =C2=A0 which means it's simultaneously possible to use the unidirectional
=C2=A0 =C2=A0 and bidirectional APIs, but that's going to cause a lot of confusion.
=C2=A0 =C2=A0 A real implementation would probably have to either commit to one
=C2=A0 =C2=A0 or the other or do a real wrapper, so you could only use one set of
=C2=A0 =C2=A0 APIs, at the cost of having to do more forwarded methods.
=C2=A0 =C2=A0=C2=A0
=C2=A0=C2=A0










--94eb2c146268153379055a831402-- From nobody Mon Oct 2 02:20: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 1D9EC134522 for ; Mon, 2 Oct 2017 02:20:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 TJOKlo_JgOw7 for ; Mon, 2 Oct 2017 02:20:55 -0700 (PDT) Received: from mail-io0-x22d.google.com (mail-io0-x22d.google.com [IPv6:2607:f8b0:4001:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ED68133341 for ; Mon, 2 Oct 2017 02:20:55 -0700 (PDT) Received: by mail-io0-x22d.google.com with SMTP id z187so4190170ioz.12 for ; Mon, 02 Oct 2017 02:20:55 -0700 (PDT) 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=8Hnd6bmNk4icyZOI/iG8xLBWx6VETMzX3ZlgY3Us104=; b=MuxkYG+l5r7IWYBZacFfoEMUzeoOxPaMhQNxz6r4nfaXgTPlZHewhm0Ue+AM1IKb9k rX6oErxEL8sVW6sHv/yJBhBIK3z73dIh7IFHs3Z1m5SRNb4p6qHPEFB0CgEiYKpw0mhC QKG/O+c51ZhAorU5BRA1keneIGrJ+3VXWVvP8Uxe8AJXx7RBmnqp/ZovAwa2mjJwLirj mdrJ8qh6dTohrD8K3gLq3276Wb8BTGd1dNFNCwJ/9hIeGP+oZP0NoL1ruWNcSz4ckVYX 1gahaEifgaBgZBJFi2HQqX1cW6eQ1D0suOIVlGi781RmBj8q9ufRTK6XUsT8E7oY+VLu ZFfQ== 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=8Hnd6bmNk4icyZOI/iG8xLBWx6VETMzX3ZlgY3Us104=; b=Klu3KVFVPxPx5UlPHJ1vDhBLDkwoH1MaR6raJ6O0VvsNCF5Yl6K/tTG0dm3POmMzbS OJm+vIgUjn7NEUtBeAnstEySFreryFvvmhlSBXGVFFefn5bisCc4cKrKTP4hAQ1Me1mm EEQ50dARZWrPqMnhnMXd1ndmekPWvahp9NCuVhxLizrc7+lXhKztvBCDO34UdsEmbi2k obV93lBGNc94Q/h5Fwhcc/sXgNqdV1qLaPMFpbJSOHVnflBNXocdTucXQF1YLOK3Z/s7 7zgxj8Rv+xl7NVFRXwNuu5QbuNPtbNupFHU65wvt4VE4yzuNsWhnHBVQhP/agCzN2Di6 U3QQ== X-Gm-Message-State: AMCzsaW4BWmSVyXZGTN9V0gQL9FFeZnaH90Kw5uRarxJBlNPixQYlvAC tf2HhZbUhtn3anlcpW/xmo0Y1lAPNFL41hmjJUFUDg== X-Google-Smtp-Source: AOwi7QBzEE1oABsHiE5w3xKgvM+VGKFNkIFm477kqs6OB532g308CDT2cg8Nncfw73+AT+3EqMvSD2Q0l5VAb3BjFQs= X-Received: by 10.107.202.2 with SMTP id a2mr23149151iog.140.1506936054175; Mon, 02 Oct 2017 02:20:54 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 2 Oct 2017 11:20:53 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 2 Oct 2017 11:20:53 +0200 Message-ID: Subject: Compression and zstd licensing update To: quic@ietf.org Content-Type: multipart/alternative; boundary="94eb2c0bd662355d60055a8ce449" 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, 02 Oct 2017 09:20:56 -0000 --94eb2c0bd662355d60055a8ce449 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable FYI: I have just gotten confirmation by the author that Facebooks zstd compression library is now a pure BSD license without PATENTS protection claims which Facebook also removed from ReactJS and graphQL. This means that zstd it could be a viable compression technology, for example in QUIC/HTTP - though I haven=E2=80=99t followed the HTTP efforts c= losely. zstd appears to have the best tradeoff in terms of cost/bandwidth/computation effort while I personally would use LZ4 for some performance critical applications to due raw speed where bandwidth is sufficient. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --94eb2c0bd662355d60055a8ce449 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
FYI:

I have just gotten confirmation by the author that Facebooks zstd= compression library is now a pure BSD license without PATENTS protection c= laims which Facebook also removed from ReactJS and graphQL.

This means that zstd it could be a v= iable compression technology, for example in QUIC/HTTP - though I haven=E2= =80=99t followed the HTTP efforts closely.

zstd appears to have the best tradeoff in terms of c= ost/bandwidth/computation effort while I personally would use LZ4 for some = performance critical applications to due raw speed where bandwidth is suffi= cient.



=
Kind Regards,
Mikkel Fahn=C3=B8e J=C3= =B8rgensen

--94eb2c0bd662355d60055a8ce449-- From nobody Mon Oct 2 04:27: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 11F3B1345C0 for ; Mon, 2 Oct 2017 04:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, 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 xWo6ks7pLdxL for ; Mon, 2 Oct 2017 04:27:38 -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 05AF81345BE for ; Mon, 2 Oct 2017 04:27:37 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v92BRJCY004342; Mon, 2 Oct 2017 12:27:35 +0100 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=FrLuDtjNog7wNd5TONyRqPhV0GMkw2OVj24nzdvKkaE=; b=mQOwR96oI6gWRwNl60V/c8GiIw7PuL2CBiIbIy+T+xn7CmqoP805dtWZKJ+a79ji2Y5o sc88zXD/FXtD+PP9EOPcHOnS8izXGNLKPN5yGMkxC+ZaUy4fxbF8dH21CLUEsK4NVYWA ZNz8uwpENJ9UxQ+EhCpWMx5uQSPXlbex50bhrgOULqbqN1fpcaqQ6fhwCuljCQl85W+U ze5/qONQFVaAUDYpoY/guYYrhwltLWaqAbkcvWA+KaG1kBfiFR8bb1A1SUpSwLY3tUJa hiNz7YHTFpshlqj1gK2Xiq30E24Qp+r0q5YKvpNjdVlQYhGxYOb9ZUGhm8Pb3Xkrj7Y+ +A== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050093.ppops.net-00190b01. with ESMTP id 2da2hntjt1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Oct 2017 12:27:34 +0100 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 v92BQ8C1011810; Mon, 2 Oct 2017 07:27:33 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint1.akamai.com with ESMTP id 2da6ktma8e-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 02 Oct 2017 07:27:32 -0400 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; Mon, 2 Oct 2017 07:27:32 -0400 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; Mon, 2 Oct 2017 07:27:32 -0400 From: "Lubashev, Igor" To: "ekr@rtfm.com" , "Michael.Bishop@microsoft.com" CC: "quic@ietf.org" , "mikkelfj@gmail.com" Subject: RE: Report on Unidirectional Streams in Minq Thread-Topic: Report on Unidirectional Streams in Minq Thread-Index: AQHTOvRbU4+GuQVlg0GF7a8KPXeTJqLPt6aAgAAG7ICAAAR+AIAAAqAAgACnRpg= Date: Mon, 2 Oct 2017 11:27:31 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted Content-Type: multipart/alternative; boundary="_000_bb3767d16e0a4ff28667907defe909f5usma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-02_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-1710020166 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-02_03:, , 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-1710020166 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, 02 Oct 2017 11:27:42 -0000 --_000_bb3767d16e0a4ff28667907defe909f5usma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Nit: Can't you send RESET_STREAM I do not think this is an option, since RESET_STREAM may prevent data buffe= red by the transport from being delivered to the application. I am less concerned about how long connection state has to be kept around -= - in a cooperating peer situation, this is one rtt, which is the same amoun= t of time that is required to wait for an ACK. A malicious peer could withh= old ACKs for packets with STREAM+FIN. The bidirectional protocol is more ch= atty, though. -----Original Message----- From: Eric Rescorla [ekr@rtfm.com] Received: Sunday, 01 Oct 2017, 5:29PM To: Mike Bishop [Michael.Bishop@microsoft.com] CC: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]; IETF QUIC WG [quic@ie= tf.org] Subject: Re: Report on Unidirectional Streams in Minq On Sun, Oct 1, 2017 at 2:19 PM, Mike Bishop > wrote: I think the difference is for the scenario where you don=92t expect a peer = to respond (or don=92t expect them to respond stream-by-stream). With -05,= the receiver still needs to send STREAM(offset=3D0,FIN) on each stream. Nit: Can't you send RESET_STREAM? With either unidirectional proposal, this pattern is a bit cleaner. In #= 656, the sender can essentially say, =93Don=92t bother=94 at the time of st= ream creation. In #643, there=92s no corresponding channel to close. Yes, I agree that this is cleaner. Note that in #643 you presumably need to= have some way of signaling that you don't want a return connection.... In all cases, the only thing that really limits you is the peer=92s willing= ness to increase your MAX_STREAM_ID, it=92s just a question of how chatty y= ou have to be =96 which can matter if these messages are fairly small. Agreed. -Ekr From: QUIC [mailto:quic-bounces@ietf.org] On = Behalf Of Eric Rescorla Sent: Sunday, October 1, 2017 2:03 PM To: Mikkel Fahn=F8e J=F8rgensen > Cc: IETF QUIC WG > Subject: Re: Report on Unidirectional Streams in Minq I'm not sure I have any useful insights on this, as my implementation handl= es them more or less the same. Can you explain why you think this would be = different with unidirectional versus bidirectional? -Ekr On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=F8e J=F8rgensen > wrote: Thanks, I only skimmed this superfast, but one the observations appear to not cover= one of my key points: You can create and close uni-streams at at very high rate of many streams p= er packet, without waiting for peer response, assuming the ACK framework ha= ndles retransmission. Any insights on this? Kind Regards, Mikkel Fahn=F8e J=F8rgensen On 1 October 2017 at 22.32.02, Eric Rescorla (ekr@rtfm.com) wrote: Hi folks, As promised I spent a bunch of time hacking unidirectional streams into Minq and I'm here to report back [0]. Specifically, I implemented: - PR#643 -- Unidirectional Streams - PR#720 -- Add bidirectional streams on top of unidirectional - A bidirectional stream API that mostly mimics Minq's original API for -05. The following is kind of a wall of text, so you could also skip this and refer to my slides [1]. MINQ'S -05 ARCHITECTURE API Minq's master object is the Connection, which has a list of Streams indexed by stream ID. Applications register a handler with the connection to be notified of new events. type ConnectionHandler interface { // The connection has changed state to state |s| StateChanged(s State) // A new stream has been created (by receiving a frame // from the other side. |s| contains the stream. NewStream(s *Stream) // Stream |s| is now readable. StreamReadable(s *Stream) } Streams get created in two ways: - Locally via Connection.CreateStream() - Remotely, in which case the application is notified via a callback to ConnectionHandler.NewStream(). Streams themselves have the APIs you would expect, namely, Read(), Write(), Close(), Reset(), etc. You get notified of stream readability by a callback to ConnectionHandler.StreamReadable(), at which point you can do Stream.Read(). As expected, Stream.Read() returns WOULDBLOCK when no data ia available INTERNALS As noted above, we start with the Connection object (only relevant fields shown): type Connection struct { handler ConnectionHandler streams []*Stream maxStream uint32 outputClearQ []frame // For stream 0 outputProtectedQ []frame // For stream >=3D 0 } As you can see, streams are in an array slice, so they're contiguously indexed by stream ID. Right now, I have no provision for reclaiming the unused bottom part of the array, but it would be straightforward to index by |streamId| - |minStream|, which I think is consistent with the design implied by the requirement to create streams in sequence. Because Streams are bidirectional, each stream actually consists of a pair of half streams. type streamHalf struct { s *stream // pointer to parent log loggingFunction dir direction // Sending or receiving closed bool // Is the half-stream closed offset uint64 // The chunks []streamChunk maxStreamData uint64 } // Internal object to allow unit testing. type stream struct { id uint32 log loggingFunction state streamState send, recv *streamHalf blocked bool // Have we returned blocked } // Public API object, which needs access to the Connection type Stream struct { c *Connection stream } Outgoing data is enqueued into |stream.chunks|, and then periodically the connection polls the stream for all the chunks which are permitted by stream-level flow control and enqueues them into |Connection.outputClearQ| or |Connection.outputProtectedQ|. At this point, the connection owns the data and is responsible for transmitting it, subject to connection-level flow control, and (presumably) congestion control once I have that implemented [2]. Incoming data gets queued (sorted) into |stream.chunks| for later reassembly at the time when someone calls stream.read(). I'm not sure I love this, because it means I don't have a good view of the incoming queue size (which I'd need to account for separately), but it allowed me to share data structures between incoming and outgoing, which seemed kind of natural when I did it (this architecture is replicated in the unidirectional streams design, but it's probably less natural there). UNIDIRECTIONAL STREAMS ARCHITECTURE UNIDIRECTIONAL API With the unidirectional branch, Minq offers two APIs. The first is a straightforward mapping of PR#720, in which we have two objects: SendStream -- used for writing RecvStream -- used for reading As before, we have a handler object, but it's directional now: type ConnectionHandler interface { // The connection has changed state to state |s| StateChanged(s State) // A new receiving stream has been created (by receiving a frame // from the other side. |s| contains the stream. NewRecvStream(s *RecvStream) // Stream |s| is now readable. StreamReadable(s *RecvStream) } Obviously SendStreams are locally created and RecvStreams are remotely created. SendStreams can be created using Connection.CreateSendStream() and you learn about remotely created RecvStreams by a callback to ConnectionHandler.NewRecvStream(). Second-created streams can be marked as "related" to a single first-created stream, using Connection.CreateRelatedSendStream() with the appropriate RecvStream as the argument [3]. Streams have a Related() API to tell you if they are related to some other stream. The {Send,Recv}Stream APIs are about what you'd expect. You can Write() on SendStream and Read() on RecvStream(). Right now, you can Close() and Reset() SendStreams, but not do anything on RecvStreams() or than ignore them. Eventually I'll probably offer RecvStream().Mute() or something to let you send STOP_SENDING. BIDIRECTIONAL API Minq also includes a bidirectional API that's layered on top of unidirectional streams. I've created a Connection2 structure that's intended as a wrapper around Connection [4]: type Connection2 struct { Connection shim *connection2ShimHandler streams []*Stream // Odd for client originated, even for server. } type Stream struct { id uint32 send *SendStream recv *RecvStream } Basically, Stream is just a pair of SendStream and RecvStream and Connection2 does the bookkeeping to keep them connected (I even do the odd/even ID thing that QUIC-05 has). Connection2 has the same handler API as Minq for QUIC-05, and the shim is responsible for translating unidirectional events into bidirectional events. Internally, what's going on here is that when you call CreateStream() Minq creates a Stream with a nil RecvStream. When a new remote stream is detected, we check RecvStream.Related(). If they are related to an existing SendStream then we will in the relevant |Stream.send| slot. Otherwise, we create a new SendStream that's related to the incoming stream and notify the application of the creation of the new bidirectional stream. Note that this all works fine if one side does the undirectional API and one does the bidirectional API. My test programs actually exercise this. Of course, there's an assumption that the peer conforms to a 1:1 mapping. If we define unidirectional streams, we'll need some protocol mechanism to know if the other side is exercising this level of increased flexibility or not. I can imagine a number of options here (e.g., ALPN). We could also forbid 1:N mappings but I think that would be a mistake as it's a cool feature/benefit of doing unidirectional. The entire bidirectional wrapper shim is < 150 lines of Go code. (https://github.com/ekr/minq/blob/unidirectional_streams/bidi.go). Converting my test application to this API was a matter of just changing class names, e.g., s/Connectionb/Connection2/. In my implementation, I assume that at the time Minq hears about a stream, you know if its related to a given existing stream. That way you can immediately either associate it with that stream or make a new local stream. In my implementation, I always send Related Stream Id and assume that you never get an "unrelated" stream frame before a "related" one. The spec doesn't really require that right now, and offline MT suggested just sending related with offset=3D0 but I think that's a mistake, because it means that you need to hold stream frames in some provisional "undetermined" state until you get that frame. I would suggest instead that we require that you include the field until one of the frames is ACKed. INTERNALS Sending and receiving streams still share a lot of common components: type baseStream struct { state streamState id uint32 log loggingFunction offset uint64 chunks []streamChunk maxStreamData uint64 isRelated bool related uint32 } type sendStream struct { baseStream blocked bool } type recvStream struct { baseStream } Most of this is the same as with bidirectional streams. As above, it's probably possible to make them more asymmetrical. The connection maintains separate lists of sending and receiving streams and it's straightforward to create and access them without worrying about the odd/even stuff. COMPARISON At the end of the day, I think this shows that these designs aren't really that disssimilar. I was able to convert Minq to unidirectional streams in about 16 total hours of work (basically a long plane flight plus the next morning). While I had to make a bunch of changes to the internal structures, basically none of them modified anything tricky, and in particular the flow control mechanics and the like are basically unchanged, except for a bunch of mechanical-type transformations like referring to |sendStream.chunks| instead of |stream.send.chunks|. The only really new protocol machinery is the new frame format for related streams. There are a few pros/cons that are worth noting about these designs. - Without a bidirectional API, having unidirectional streams is more work for the programmer. However, with an API shim, the difference is trivial. - Because undirectional streams are inherently more flexible, it's possible for the sides to try to use different mappings, e.g., one side expects paired and the other expects 1:N. We'll need some way of making sure that doesn't happen, maybe ALPN? - The "Related Stream ID" frame indicator needs fleshing out a bit. From the application's perspective, it should never hear about a stream without knowing its related status. And as noted above, I think it would be best if we required that all "first flight" stream frames that are related include the fied - Undirectional streams kind of sharpen the confusion about exactly what kinds of "closure" we want to allow. Specifically, what should implementations be able to say about their willingness to receive? Right now we have STOP_SENDING, but that doesn't influence the sender's state. I don't think undirectional streams make this worse, they just require us to think it through some more. They do simplify the implementation of the closure state machine: in my QUIC-05 code, whenever one side closes I have to have checks to see if I should be transitioning to CLOSED or HALF-CLOSED, etc, which is odd because the directions are basically independent. It would probably be easier even in QUIC-05 not to reify these states but just to determine the state from the composition of the individual sub-states - Unidirectional streams don't need the kind of annoying odd-even mechanics, which was easier to code up (just having to create all the lower-numbered streams of the same parity is kind of a pain). One additional benefit here is that with QUIC-05 there are several messages which involve implicit stream creation (e.g., STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether the stream is one that should have been created locally or remotely. This just doesn't happen with bidirectional streams; I do implement odd/even mechanics but because the other side has to have its stream ids increment by one, I can make sure that they have the right IDs by construction and just check to see if the stream exists in these cases. I'd like to see us get rid of odd/even no matter what. - Unidirectional streams also helps avoid some of the corner cases around bidirectional streams. Specifically, suppose I am the client and I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed to just start sending or not? You can sort of get into this situation with unidirectional streams, but because it's explicit, one might hope that the application semantics would require clear specification. - As noted above, bidirectional streams are more flexible because they let you have mappings that you can't have with unidirectional streams (unpaired, 1:N). Happy to answer more questions if people have them. Otherwise we can talk about this in Seattle. -Ekr [0] https://github.com/ekr/minq/tree/unidirectional_streams [1] https://github.com/ekr/wg-materials/blob/404898fa2d2f0a9f9bd244d2c945e6= 6ea88502a2/interim-17-10/Unidirectional%20Streams%20in%20Minq.pdf [2] Thanks to Patrick McManus for suggesting this design. [3] In C++, you would have a single function with a default argument of |nullptr| but Go doesn't support that, hence two different arguments. [4] For implementation reasons, it's actually using Connection as a mixin, which means it's simultaneously possible to use the unidirectional and bidirectional APIs, but that's going to cause a lot of confusion. A real implementation would probably have to either commit to one or the other or do a real wrapper, so you could only use one set of APIs, at the cost of having to do more forwarded methods. --_000_bb3767d16e0a4ff28667907defe909f5usma1exdag1mb5msgcorpak_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable > Nit: Can't you send RESET_STREAM

I do not think this is an option, since RESET_STREAM may prevent data buffe= red by the transport from being delivered to the application.

I am less concerned about how long connection state has to be kept around -= - in a cooperating peer situation, this is one rtt, which is the same amoun= t of time that is required to wait for an ACK. A malicious peer could withh= old ACKs for packets with STREAM+FIN. The bidirectional protocol is more chatty, though.

-----Original Message-----
From: Eric Rescorla [ekr@rtfm.com]
Received: Sunday, 01 Oct 2017, 5:29PM
To: Mike Bishop [Michael.Bishop@microsoft.com]
CC: Mikkel Fahn=F8e J=F8rgensen [mikkelfj@gmail.com]; IETF QUIC WG [= quic@ietf.org]
Subject: Re: Report on Unidirectional Streams in Minq


On Sun, Oct 1, 2017 at 2:19 PM, Mike Bishop <Micha= el.Bishop@microsoft.com> wrote:

I think the difference is for the scenario where you= don=92t expect a peer to respond (or don=92t expect them to respond stream= -by-stream).  With -05, the receiver still needs to send STREAM(offset= =3D0,FIN) on each stream.


Nit: Can't you send RESET_STREAM?

 

  With either unidirectional proposal, this pat= tern is a bit cleaner.  In #656, the sender can essentially say, =93Do= n=92t bother=94 at the time of stream creation.  In #643, there=92s no= corresponding channel to close.


Yes, I agree that this is cleaner. Note that in #643 you presumably ne= ed to have some way of signaling that you don't want a return connection...= .



In all cases, the only thing that really limits you = is the peer=92s willingness to increase your MAX_STREAM_ID, it=92s just a q= uestion of how chatty you have to be =96 which can matter if these messages= are fairly small.


Agreed.

-Ekr
 

 

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Sunday, October 1, 2017 2:03 PM
To: Mikkel Fahn=F8e J=F8rgensen <mikkelfj@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Report on Unidirectional Streams in Minq<= /p>

 

I'm not sure I have any useful insights on this, as = my implementation handles them more or less the same. Can you explain why y= ou think this would be different with unidirectional versus bidirectional?<= u>

 

-Ekr

 

 

On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=F8e J=F8= rgensen <mikkelf= j@gmail.com> wrote:

Thanks,

 

I only skimmed this superfast, but one the obser= vations appear to not cover one of my key points:

 

You can create and close uni-streams at at very = high rate of many streams per packet, without waiting for peer response, as= suming the ACK framework handles retransmission. Any insights on this?

 

Kind Regards,

Mikkel Fahn=F8e J= =F8rgensen

 

On 1 Octob= er 2017 at 22.32.02, Eric Rescorla (ekr@rtfm.com) wrote:

Hi folks,

 

As promised I spent a bunch of time hacking unidirec= tional streams

into Minq and I'm here to report back [0]. Specifica= lly, I

implemented:

 

  - PR#643 -- Unidirectional Streams<= /u>

  - PR#720 -- Add bidirectional streams on top = of unidirectional

  - A bidirectional stream API that mostly mimi= cs Minq's original API

    for -05.

    

The following is kind of a wall of text, so you coul= d also skip this

and refer to my slides [1].

 

 

MINQ'S -05 ARCHITECTURE

API

Minq's master object is the Connection, which has a = list of Streams

indexed by stream ID. Applications register a handle= r with the

connection to be notified of new events.

 

   type ConnectionHandler interface {

    // The connection has changed state to= state |s|

    StateChanged(s State)

   

    // A new stream has been created (by r= eceiving a frame

    // from the other side. |s| contains t= he stream.

    NewStream(s *Stream)

   

    // Stream |s| is now readable.<= u>

    StreamReadable(s *Stream)

   }

 

Streams get created in two ways:

 

- Locally via Connection.CreateStream()

- Remotely, in which case the application is notifie= d via a callback to

  ConnectionHandler.NewStream().<= /p>

 

Streams themselves have the APIs you would expect, n= amely, Read(),

Write(), Close(), Reset(), etc. You get notified of = stream readability

by a callback to ConnectionHandler.StreamReadab= le(), at which point

you can do Stream.Read(). As expected, Stream.Read()= returns

WOULDBLOCK when no data ia available

 

 

INTERNALS

As noted above, we start with the Connection object = (only relevant fields

shown):

 

   type Connection struct {<= /p>

    handler        &nb= sp; ConnectionHandler

    streams        &nb= sp; []*Stream

    maxStream        u= int32

outputClearQ     []frame // For strea= m 0

outputProtectedQ []frame // For stream >=3D 0<= /u>

   }

 

As you can see, streams are in an array slice, so th= ey're contiguously

indexed by stream ID. Right now, I have no provision= for reclaiming

the unused bottom part of the array, but it would be= straightforward

to index by |streamId| - |minStream|, which I think = is consistent with

the design implied by the requirement to create stre= ams in sequence.

 

Because Streams are bidirectional, each stream actua= lly consists of a

pair of half streams.

 

   type streamHalf struct {<= /p>

    s          &n= bsp;  *stream           // pointer to pa= rent

    log          =  loggingFunction   

    dir          =  direction         // Sending or receiving=

    closed        bool=               // Is the half-stream clos= ed

    offset        uint= 64            // The

    chunks        []st= reamChunk

    maxStreamData uint64

   }

 

   // Internal object to allow unit testin= g.

   type stream struct {

    id         ui= nt32

    log        logging= Function

    state      streamState<= u>

    send, recv *streamHalf

  blocked    bool // Have we returned= blocked

   }

 

   // Public API object, which needs acces= s to the Connection

   type Stream struct {

    c *Connection

    stream

   }

 

Outgoing data is enqueued into |stream.chunks|, and = then periodically

the connection polls the stream for all the chunks w= hich are permitted

by stream-level flow control and enqueues them into<= u>

|Connection.outputClearQ| or |Connection.outputProte= ctedQ|. At this

point, the connection owns the data and is responsib= le for

transmitting it, subject to connection-level flow co= ntrol, and

(presumably) congestion control once I have that imp= lemented [2].

 

Incoming data gets queued (sorted) into |stream.chun= ks| for later

reassembly at the time when someone calls stream.rea= d(). I'm not sure

I love this, because it means I don't have a good vi= ew of the incoming

queue size (which I'd need to account for separately= ), but it allowed

me to share data structures between incoming and out= going, which

seemed kind of natural when I did it (this architect= ure is replicated

in the unidirectional streams design, but it's proba= bly less natural

there).

 

 

UNIDIRECTIONAL STREAMS ARCHITECTURE

UNIDIRECTIONAL API

With the unidirectional branch, Minq offers two APIs= . The first is a

straightforward mapping of PR#720, in which we have = two objects:

 

  SendStream -- used for writing<= /p>

  RecvStream -- used for reading<= /p>

 

As before, we have a handler object, but it's direct= ional now:

 

   type ConnectionHandler interface {

    // The connection has changed state to= state |s|

    StateChanged(s State)

   

    // A new receiving stream has been cre= ated (by receiving a frame

    // from the other side. |s| contains t= he stream.

    NewRecvStream(s *RecvStream)=

   

    // Stream |s| is now readable.<= u>

    StreamReadable(s *RecvStream)

   }

 

Obviously SendStreams are locally created and RecvSt= reams are remotely

created. SendStreams can be created using<= /u>

Connection.CreateSendStream() and you learn about re= motely created

RecvStreams by a callback to ConnectionHandler.= NewRecvStream().

Second-created streams can be marked as "relate= d" to a single

first-created stream, using Connection.CreateRe= latedSendStream() with

the appropriate RecvStream as the argument [3]. Stre= ams have a

Related() API to tell you if they are related to som= e other stream.

 

The {Send,Recv}Stream APIs are about what you'd expe= ct. You can

Write() on SendStream and Read() on RecvStream(). Ri= ght now, you can

Close() and Reset() SendStreams, but not do anything= on RecvStreams()

or than ignore them. Eventually I'll probably offer<= u>

RecvStream().Mute() or something to let you send STO= P_SENDING.

 

 

BIDIRECTIONAL API

Minq also includes a bidirectional API that's layere= d on top of

unidirectional streams. I've created a Connection2 s= tructure that's

intended as a wrapper around Connection [4]:<= u>

 

   type Connection2 struct {=

    Connection

    shim    *connection2ShimHand= ler

    streams []*Stream // Odd for client or= iginated, even for server.

   }

     

   type Stream struct {

    id   uint32

    send *SendStream

    recv *RecvStream

   }

 

Basically, Stream is just a pair of SendStream and R= ecvStream and

Connection2 does the bookkeeping to keep them connec= ted (I even do the

odd/even ID thing that QUIC-05 has). Connection2 has= the same handler

API as Minq for QUIC-05, and the shim is responsible= for translating

unidirectional events into bidirectional events.<= /u>

 

Internally, what's going on here is that when you ca= ll CreateStream()

Minq creates a Stream with a nil RecvStream. When a = new remote stream

is detected, we check RecvStream.Related(). If they = are related to an

existing SendStream then we will in the relevant |St= ream.send| slot.

Otherwise, we create a new SendStream that's related= to the incoming

stream and notify the application of the creation of= the new

bidirectional stream.

 

Note that this all works fine if one side does the u= ndirectional API

and one does the bidirectional API. My test programs= actually exercise

this. Of course, there's an assumption that the peer= conforms to a 1:1

mapping. If we define unidirectional streams, we'll = need some protocol

mechanism to know if the other side is exercising th= is level of

increased flexibility or not. I can imagine a number= of options here

(e.g., ALPN).  We could also forbid 1:N mapping= s but I think that

would be a mistake as it's a cool feature/benefit of= doing

unidirectional.

 

The entire bidirectional wrapper shim is < 150 li= nes of Go code.

Converting my test application to this API was a mat= ter of just

changing class names, e.g., s/Connectionb/Connection= 2/.

 

In my implementation, I assume that at the time Minq= hears about a

stream, you know if its related to a given existing = stream.  That way

you can immediately either associate it with that st= ream or make a new

local stream. In my implementation, I always send Re= lated Stream Id

and assume that you never get an "unrelated&quo= t; stream frame before a

"related" one. The spec doesn't really req= uire that right now, and

offline MT suggested just sending related with offse= t=3D0 but I think

that's a mistake, because it means that you need to = hold stream frames

in some provisional "undetermined" state u= ntil you get that frame. I

would suggest instead that we require that you inclu= de the field until

one of the frames is ACKed.

  

 

INTERNALS

Sending and receiving streams still share a lot of c= ommon components:

 

    type baseStream struct {=

    state         = ;streamState

    id          &= nbsp; uint32

    log          =  loggingFunction

    offset        uint= 64

    chunks        []st= reamChunk

    maxStreamData uint64

    isRelated     bool

    related       uint= 32

    }

    

    type sendStream struct {=

    baseStream

    blocked bool

    }

    

    type recvStream struct {=

    baseStream

    }

 

Most of this is the same as with bidirectional strea= ms.  As above,

it's probably possible to make them more asymmetrica= l.

 

The connection maintains separate lists of sending a= nd receiving

streams and it's straightforward to create and acces= s them without

worrying about the odd/even stuff.

 

 

COMPARISON

At the end of the day, I think this shows that these= designs aren't

really that disssimilar. I was able to convert Minq = to unidirectional

streams in about 16 total hours of work (basically a= long plane flight

plus the next morning). While I had to make a bunch = of changes to the

internal structures, basically none of them modified= anything tricky,

and in particular the flow control mechanics and the= like are

basically unchanged, except for a bunch of mechanica= l-type

transformations like referring to |sendStream.chunks= | instead of

|stream.send.chunks|. The only really new protocol m= achinery is the

new frame format for related streams.<= /p>

 

There are a few pros/cons that are worth noting abou= t these designs.

 

- Without a bidirectional API, having unidirectional= streams is more

  work for the programmer. However, with an API= shim, the difference

  is trivial.

 

- Because undirectional streams are inherently more = flexible, it's

  possible for the sides to try to use differen= t mappings, e.g., one

  side expects paired and the other expects 1:N= . We'll need some way

  of making sure that doesn't happen, maybe ALP= N?

 

- The "Related Stream ID" frame indicator = needs fleshing out a bit.

  From the application's perspective, it should= never hear about a

  stream without knowing its related status. An= d as noted above, I

  think it would be best if we required that al= l "first flight" stream

  frames that are related include the fied

 

- Undirectional streams kind of sharpen the confusio= n about exactly

  what kinds of "closure" we want to = allow. Specifically, what should

  implementations be able to say about their wi= llingness to receive?

  Right now we have STOP_SENDING, but that does= n't influence the

  sender's state. I don't think undirectional s= treams make this worse,

  they just require us to think it through some= more. They do simplify

  the implementation of the closure state machi= ne: in my QUIC-05 code,

  whenever one side closes I have to have check= s to see if I should be

  transitioning to CLOSED or HALF-CLOSED, etc, = which is odd because

  the directions are basically independent.&nbs= p; It would probably be

  easier even in QUIC-05 not to reify these sta= tes but just to

  determine the state from the composition of t= he individual

  sub-states

  

- Unidirectional streams don't need the kind of anno= ying odd-even

  mechanics, which was easier to code up (just = having to create all

  the lower-numbered streams of the same parity= is kind of a pain).

  One additional benefit here is that with QUIC= -05 there are several

  messages which involve implicit stream creati= on (e.g.,

  STREAM_MAX_DATA, and RST_STREAM) and so you n= eed to check whether

  the stream is one that should have been creat= ed locally or

  remotely. This just doesn't happen with bidir= ectional streams; I do

  implement odd/even mechanics but because the = other side has to have

  its stream ids increment by one, I can make s= ure that they have the

  right IDs by construction and just check to s= ee if the stream exists

  in these cases.  I'd like to see us get = rid of odd/even no matter

  what.

 

- Unidirectional streams also helps avoid some of th= e corner cases around

  bidirectional streams. Specifically, suppose = I am the client and

  I get MAX_STREAM_DATA as the first frame on s= tream 2. Am I allowed

  to just start sending or not? You can sort of= get into this situation

  with unidirectional streams, but because it's= explicit, one might

  hope that the application semantics would req= uire clear specification.

  

- As noted above, bidirectional streams are more fle= xible because they

  let you have mappings that you can't have wit= h unidirectional

  streams (unpaired, 1:N).

 

 

Happy to answer more questions if people have them. = Otherwise we can

talk about this in Seattle.

 

-Ekr

 

 

[2] Thanks to Patrick McManus for suggesting this de= sign.

[3] In C++, you would have a single function= with a default argument of

    |nullptr| but Go doesn't support that,= hence two different arguments.

[4] For implementation reasons, it's actually using = Connection as a mixin,

    which means it's simultaneously possib= le to use the unidirectional

    and bidirectional APIs, but that's goi= ng to cause a lot of confusion.

    A real implementation would probably h= ave to either commit to one

    or the other or do a real wrapper, so = you could only use one set of

    APIs, at the cost of having to do more= forwarded methods.

    

  

 

 

 

 

 

 

 

 

 


--_000_bb3767d16e0a4ff28667907defe909f5usma1exdag1mb5msgcorpak_-- From nobody Mon Oct 2 06:18: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 009E513463E for ; Mon, 2 Oct 2017 06:18:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 hu546E0ej8mM for ; Mon, 2 Oct 2017 06:18:35 -0700 (PDT) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B31D13463A for ; Mon, 2 Oct 2017 06:18:35 -0700 (PDT) Received: by mail-vk0-x22d.google.com with SMTP id w23so2828439vkw.2 for ; Mon, 02 Oct 2017 06:18:35 -0700 (PDT) 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=iZiM2anQW0IedAXE8yL3i356jYMMuga71wqeYHgdjn0=; b=D5Hms4G8Xy4KdAMgAaXK5dWuoWIWH2gJB7hbqzqb6GCGs42iBMBlIvof9QkAzG8Rqu odWxh0E56cPJcdoHxapNJq71cIVmMBSStpaICFlzioz8qpVhw/HlMJAIKJ01pa5pKxvp xQk4vz/CdGxY00qihAkfmvwaChXAIcG2FYkf3cwpfpecpvD2YMDOHbmXMLlxzJOSzDFz fi+VxPzPIjftRAp1PadYgoWRCvr6KvzzxQpstvII2nCnX2srL3MMim7HVG92h2LdM6t8 GUfAd1+a2E+xbkr8mLSB0PzVB958sZ6mmU4Zp5ZUp4V3RMmqPsBnYXprj8fGN9RZsUAl xu3w== 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=iZiM2anQW0IedAXE8yL3i356jYMMuga71wqeYHgdjn0=; b=kZSmYEElJ5NcpIDTdMx1fycGJPk0tD7qcBajvngkigUjvNcmVK0VShab1d3soB9UvI KHlfWyX5W+Bs4BmBaAnt89U2SYC6FwTc1DAQv15b+KvL/xeW+YNrYs8CJ1Si5evMTYmd 7acnD0hsdT+RporXDE2waHalny3bPZrB93mTVsFBwstq5I0cLYAtnFV67qjkSPluOpMQ aWpOAEo6ycHd6wyaH8LeEN6P/sj7vHgADMz2T0Ao7NZKsqb9zWvURZ7VO9+9aaeVdMtE swVExFiVY/r0cswmtatiNXQuM/OF8nLLydqFDsyE54V3blTLSCf4Nl55zwxdykeT5nxS lw/Q== X-Gm-Message-State: AMCzsaUUsqIPHJxDpWn9tdA41RhSf8SQSHVGrbzuwKH2S2IPhdywZ6ab e6oHSDbmzSRCvLJQSge0isg+uUww6MpIKI497w6mnw== X-Google-Smtp-Source: AOwi7QCH/GxzPH3QJBm+42v55PR7B/GejM85+piBsFFvfej14xZhVXaQNOd5q+NIMmVfNQ320uJSAA95vaFYctRML5c= X-Received: by 10.31.54.5 with SMTP id d5mr1104220vka.8.1506950314162; Mon, 02 Oct 2017 06:18:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.83.199 with HTTP; Mon, 2 Oct 2017 06:18:33 -0700 (PDT) From: Stanislav Slusny Date: Mon, 2 Oct 2017 15:18:33 +0200 Message-ID: Subject: comments on draft-ietf-quic-recovery-06 To: quic@ietf.org Content-Type: multipart/alternative; boundary="001a1143ff3c2b7d6f055a90365f" 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, 02 Oct 2017 13:18:37 -0000 --001a1143ff3c2b7d6f055a90365f Content-Type: text/plain; charset="UTF-8" Hi, A few comments on the loss detection part of draft-ietf-quic-recovery-06: - Early retransmit timer is computed since the sent time of the first unacked packet (unacked.time_sent + delay_until_lost) in DetectLostPackets(). Other timers (handshake timer, TLP timer, RTO timer) are computed since the time of the most recently sent packet, but since "now" in SetLossDetectionAlarm(). - Should we update largest_acked_packet in OnAckReceived() only if the "ack.largest_acked > largest_acked_packet" ? Acks might be reordered. - "ack.largest_acked" seems to be a packet number, but "largest_acked.packet_number" is used in DetectLostPackets(largest_acked). - Rename SentOnePacket() and SendTwoPackets() :-) (RetransmitTlp(), RetransmitRtoPackets()) - Describe variable "retransmittable_packets_outstanding" in section "Variables of interest". It would be nice to rename it so that it is clear that it expresses the count of packets. - Sent time of a packet is denoted as "sent_packets[NUMBER].time" and "unacked.time_sent", it would be nice to unify it. - Both "ack.ack_delay" and "ack.delay" are used in OnAckReceived(). - "acked_packet.packet_number" in OnAckReceived() should be "ack.packet_number". - Add a note saying that if spurious RTT occurs, variance should be increased. Thanks, Stanislav Slusny --001a1143ff3c2b7d6f055a90365f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

A few comments on the lo= ss detection part of=C2=A0draft-ietf-quic-recovery-06:

= - Early retransmit timer is computed since the sent time of the first unack= ed packet (unacked.time_sent + delay_until_lost) in DetectLostPackets().=C2= =A0=C2=A0Other timers (handshake timer, TLP timer, RTO timer) are computed = since the time of the most recently sent packet, but since "now" = in SetLossDetectionAlarm().

- Should we update largest_acked_pa= cket in OnAckReceived() only if the "ack.largest_acked > largest_ac= ked_packet" ? Acks might be reordered.

- =C2=A0&quo= t;ack.largest_acked" seems to be a packet number, but "largest_ac= ked.packet_number" is used in DetectLostPackets(largest_acked).
- Rename SentOnePacket() and SendTwoPackets() :-) (RetransmitTlp(), Retran= smitRtoPackets())

- Describe variable "retransmittable_packets_= outstanding" in section "Variables of interest". It would be= nice to rename it so that it is clear that it expresses the count of packe= ts. =C2=A0

- Sent time of a packet is denoted as "sent_packets[= NUMBER].time" and "unacked.time_sent", it would be nice to u= nify it.

- Both "ack.ack_delay" and "ack.delay"= are used in OnAckReceived().

- "acked_packet.packet_number&quo= t; in OnAckReceived() should be "ack.packet_number".

- Add= a note saying that if spurious RTT occurs, variance should be increased.
Thanks,=C2=A0

Stanislav Slusny
--001a1143ff3c2b7d6f055a90365f-- From nobody Mon Oct 2 07: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 3FCB4134681 for ; Mon, 2 Oct 2017 07:52:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.609 X-Spam-Level: X-Spam-Status: No, score=-0.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, 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 uQiZULl0pbkw for ; Mon, 2 Oct 2017 07:52:51 -0700 (PDT) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A81A1134483 for ; Mon, 2 Oct 2017 07:52:50 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id w9so3822392ywi.11 for ; Mon, 02 Oct 2017 07:52:50 -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=MT+4YCAaLP6qbHghnbJMrUd3NCGUg09q+FWrtuL/x2A=; b=n73Cg73P6+FC/E8Fa6P4fYYu6vLRMviglojrwYpIYflYnVbnQJw9IAEjZx0RJ6ZiBB /lbFaFzNBz+QLqZQnu7CnlHVI5gZlpYu/sqCftGwYG9snvDGz4RCgQoHelJYSYgFHf0r /HsJa5cYqApUEE8CPjIkXBTdmPt8MNSeVG9nPyHzn1Mth9u4pVFRHS7AIeEQAzTShrQR PHpWm49WjF+WjUpuCfBQ9Q1vmqt4bAJrrr2PuYFycjeiYjprpJJSS/8tTX8uxxBKiFTO YZ6gvb6m7rpYrqOaXBEcjTzMXMfWdZHyDLsq+7pitRIY6KDmX2wA/wQL/dxEN1CLA3kr V8hg== 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=MT+4YCAaLP6qbHghnbJMrUd3NCGUg09q+FWrtuL/x2A=; b=Y1qbY07Al6CqmzdIRmwcmCqKaBSGxZGBeaKAbtRK4NJOsphQ/opHkoB3BarMFJ89zc hlW8MuBOpPBUsGem2RukW/CPTpCsXsxpxjqvpS4zMXmN6nD/d0DEqjMqJauM6QjyP9pM IzEK9um5SYQzDa9dcky1HbpvJpweH8KlA20RygJChsJB5u9j03Ykc1RUGc/MCbDORX6s zTcaVdkPGElWfzN7Jgjjtq4biWp38/z6ZTweD8W+7c3UGWWxGM2k9Hcow5B0qvsY2hDI 9KGHcWiHbFQyz8JsNOiFg8WkxE82oHbpmFgn9iCrzo+KsncJVH7nkSvKxOwripB6Jxt0 gOPg== X-Gm-Message-State: AMCzsaX+A6+WCmBeNP/j9wwnL9hRijNXrspQneKKaOoDLpCsKcvGaQNP he0U1zJY8mksgtDt36oOL34Z9fz5C8N8AdaimWly5Q== X-Google-Smtp-Source: AOwi7QAWUXjrwjtSSPcrE1pOq4trI9gqJJ/ThPo5ZBSLowi0hSgWtiXvduIhFXGj8grShH2p8c0/9K3f8MlTNCAfRlE= X-Received: by 10.129.85.150 with SMTP id j144mr431190ywb.161.1506955969797; Mon, 02 Oct 2017 07:52:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Mon, 2 Oct 2017 07:52:09 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 2 Oct 2017 07:52:09 -0700 Message-ID: Subject: Re: Report on Unidirectional Streams in Minq To: "Lubashev, Igor" Cc: "Michael.Bishop@microsoft.com" , "quic@ietf.org" , "mikkelfj@gmail.com" Content-Type: multipart/alternative; boundary="001a113f176645ce75055a91875f" 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, 02 Oct 2017 14:52:55 -0000 --001a113f176645ce75055a91875f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 2, 2017 at 4:27 AM, Lubashev, Igor wrote: > > Nit: Can't you send RESET_STREAM > > I do not think this is an option, since RESET_STREAM may prevent data > buffered by the transport from being delivered to the application. > Those are also the semantics of STREAM(offset=3D0, FIN). -Ekr I am less concerned about how long connection state has to be kept around > -- in a cooperating peer situation, this is one rtt, which is the same > amount of time that is required to wait for an ACK. A malicious peer coul= d > withhold ACKs for packets with STREAM+FIN. The bidirectional protocol is > more chatty, though. > > > -----Original Message----- > *From:* Eric Rescorla [ekr@rtfm.com] > *Received:* Sunday, 01 Oct 2017, 5:29PM > *To:* Mike Bishop [Michael.Bishop@microsoft.com] > *CC:* Mikkel Fahn=C3=B8e J=C3=B8rgensen [mikkelfj@gmail.com]; IETF QUIC W= G [ > quic@ietf.org] > *Subject:* Re: Report on Unidirectional Streams in Minq > > > > On Sun, Oct 1, 2017 at 2:19 PM, Mike Bishop > wrote: > >> I think the difference is for the scenario where you don=E2=80=99t expec= t a peer >> to respond (or don=E2=80=99t expect them to respond stream-by-stream). = With -05, >> the receiver still needs to send STREAM(offset=3D0,FIN) on each stream. >> > > Nit: Can't you send RESET_STREAM? > > > >> With either unidirectional proposal, this pattern is a bit cleaner. I= n >> #656, the sender can essentially say, =E2=80=9CDon=E2=80=99t bother=E2= =80=9D at the time of stream >> creation. In #643, there=E2=80=99s no corresponding channel to close. >> > > Yes, I agree that this is cleaner. Note that in #643 you presumably need > to have some way of signaling that you don't want a return connection.... > > > > In all cases, the only thing that really limits you is the peer=E2=80=99s >> willingness to increase your MAX_STREAM_ID, it=E2=80=99s just a question= of how >> chatty you have to be =E2=80=93 which can matter if these messages are f= airly small. >> > > Agreed. > > -Ekr > > >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Eric Rescorla >> *Sent:* Sunday, October 1, 2017 2:03 PM >> *To:* Mikkel Fahn=C3=B8e J=C3=B8rgensen >> *Cc:* IETF QUIC WG >> *Subject:* Re: Report on Unidirectional Streams in Minq >> >> >> >> I'm not sure I have any useful insights on this, as my implementation >> handles them more or less the same. Can you explain why you think this >> would be different with unidirectional versus bidirectional? >> >> >> >> -Ekr >> >> >> >> >> >> On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen < >> mikkelfj@gmail.com> wrote: >> >> Thanks, >> >> >> >> I only skimmed this superfast, but one the observations appear to not >> cover one of my key points: >> >> >> >> You can create and close uni-streams at at very high rate of many stream= s >> per packet, without waiting for peer response, assuming the ACK framewor= k >> handles retransmission. Any insights on this? >> >> >> >> Kind Regards, >> >> Mikkel Fahn=C3=B8e J=C3=B8rgensen >> >> >> >> On 1 October 2017 at 22.32.02, Eric Rescorla (ekr@rtfm.com) wrote: >> >> Hi folks, >> >> >> >> As promised I spent a bunch of time hacking unidirectional streams >> >> into Minq and I'm here to report back [0]. Specifically, I >> >> implemented: >> >> >> >> - PR#643 -- Unidirectional Streams >> >> - PR#720 -- Add bidirectional streams on top of unidirectional >> >> - A bidirectional stream API that mostly mimics Minq's original API >> >> for -05. >> >> >> >> The following is kind of a wall of text, so you could also skip this >> >> and refer to my slides [1]. >> >> >> >> >> >> MINQ'S -05 ARCHITECTURE >> >> API >> >> Minq's master object is the Connection, which has a list of Streams >> >> indexed by stream ID. Applications register a handler with the >> >> connection to be notified of new events. >> >> >> >> type ConnectionHandler interface { >> >> // The connection has changed state to state |s| >> >> StateChanged(s State) >> >> >> >> // A new stream has been created (by receiving a frame >> >> // from the other side. |s| contains the stream. >> >> NewStream(s *Stream) >> >> >> >> // Stream |s| is now readable. >> >> StreamReadable(s *Stream) >> >> } >> >> >> >> Streams get created in two ways: >> >> >> >> - Locally via Connection.CreateStream() >> >> - Remotely, in which case the application is notified via a callback to >> >> ConnectionHandler.NewStream(). >> >> >> >> Streams themselves have the APIs you would expect, namely, Read(), >> >> Write(), Close(), Reset(), etc. You get notified of stream readability >> >> by a callback to ConnectionHandler.StreamReadable(), at which point >> >> you can do Stream.Read(). As expected, Stream.Read() returns >> >> WOULDBLOCK when no data ia available >> >> >> >> >> >> INTERNALS >> >> As noted above, we start with the Connection object (only relevant field= s >> >> shown): >> >> >> >> type Connection struct { >> >> handler ConnectionHandler >> >> streams []*Stream >> >> maxStream uint32 >> >> outputClearQ []frame // For stream 0 >> >> outputProtectedQ []frame // For stream >=3D 0 >> >> } >> >> >> >> As you can see, streams are in an array slice, so they're contiguously >> >> indexed by stream ID. Right now, I have no provision for reclaiming >> >> the unused bottom part of the array, but it would be straightforward >> >> to index by |streamId| - |minStream|, which I think is consistent with >> >> the design implied by the requirement to create streams in sequence. >> >> >> >> Because Streams are bidirectional, each stream actually consists of a >> >> pair of half streams. >> >> >> >> type streamHalf struct { >> >> s *stream // pointer to parent >> >> log loggingFunction >> >> dir direction // Sending or receiving >> >> closed bool // Is the half-stream closed >> >> offset uint64 // The >> >> chunks []streamChunk >> >> maxStreamData uint64 >> >> } >> >> >> >> // Internal object to allow unit testing. >> >> type stream struct { >> >> id uint32 >> >> log loggingFunction >> >> state streamState >> >> send, recv *streamHalf >> >> blocked bool // Have we returned blocked >> >> } >> >> >> >> // Public API object, which needs access to the Connection >> >> type Stream struct { >> >> c *Connection >> >> stream >> >> } >> >> >> >> Outgoing data is enqueued into |stream.chunks|, and then periodically >> >> the connection polls the stream for all the chunks which are permitted >> >> by stream-level flow control and enqueues them into >> >> |Connection.outputClearQ| or |Connection.outputProtectedQ|. At this >> >> point, the connection owns the data and is responsible for >> >> transmitting it, subject to connection-level flow control, and >> >> (presumably) congestion control once I have that implemented [2]. >> >> >> >> Incoming data gets queued (sorted) into |stream.chunks| for later >> >> reassembly at the time when someone calls stream.read(). I'm not sure >> >> I love this, because it means I don't have a good view of the incoming >> >> queue size (which I'd need to account for separately), but it allowed >> >> me to share data structures between incoming and outgoing, which >> >> seemed kind of natural when I did it (this architecture is replicated >> >> in the unidirectional streams design, but it's probably less natural >> >> there). >> >> >> >> >> >> UNIDIRECTIONAL STREAMS ARCHITECTURE >> >> UNIDIRECTIONAL API >> >> With the unidirectional branch, Minq offers two APIs. The first is a >> >> straightforward mapping of PR#720, in which we have two objects: >> >> >> >> SendStream -- used for writing >> >> RecvStream -- used for reading >> >> >> >> As before, we have a handler object, but it's directional now: >> >> >> >> type ConnectionHandler interface { >> >> // The connection has changed state to state |s| >> >> StateChanged(s State) >> >> >> >> // A new receiving stream has been created (by receiving a frame >> >> // from the other side. |s| contains the stream. >> >> NewRecvStream(s *RecvStream) >> >> >> >> // Stream |s| is now readable. >> >> StreamReadable(s *RecvStream) >> >> } >> >> >> >> Obviously SendStreams are locally created and RecvStreams are remotely >> >> created. SendStreams can be created using >> >> Connection.CreateSendStream() and you learn about remotely created >> >> RecvStreams by a callback to ConnectionHandler.NewRecvStream(). >> >> Second-created streams can be marked as "related" to a single >> >> first-created stream, using Connection.CreateRelatedSendStream() with >> >> the appropriate RecvStream as the argument [3]. Streams have a >> >> Related() API to tell you if they are related to some other stream. >> >> >> >> The {Send,Recv}Stream APIs are about what you'd expect. You can >> >> Write() on SendStream and Read() on RecvStream(). Right now, you can >> >> Close() and Reset() SendStreams, but not do anything on RecvStreams() >> >> or than ignore them. Eventually I'll probably offer >> >> RecvStream().Mute() or something to let you send STOP_SENDING. >> >> >> >> >> >> BIDIRECTIONAL API >> >> Minq also includes a bidirectional API that's layered on top of >> >> unidirectional streams. I've created a Connection2 structure that's >> >> intended as a wrapper around Connection [4]: >> >> >> >> type Connection2 struct { >> >> Connection >> >> shim *connection2ShimHandler >> >> streams []*Stream // Odd for client originated, even for server. >> >> } >> >> >> >> type Stream struct { >> >> id uint32 >> >> send *SendStream >> >> recv *RecvStream >> >> } >> >> >> >> Basically, Stream is just a pair of SendStream and RecvStream and >> >> Connection2 does the bookkeeping to keep them connected (I even do the >> >> odd/even ID thing that QUIC-05 has). Connection2 has the same handler >> >> API as Minq for QUIC-05, and the shim is responsible for translating >> >> unidirectional events into bidirectional events. >> >> >> >> Internally, what's going on here is that when you call CreateStream() >> >> Minq creates a Stream with a nil RecvStream. When a new remote stream >> >> is detected, we check RecvStream.Related(). If they are related to an >> >> existing SendStream then we will in the relevant |Stream.send| slot. >> >> Otherwise, we create a new SendStream that's related to the incoming >> >> stream and notify the application of the creation of the new >> >> bidirectional stream. >> >> >> >> Note that this all works fine if one side does the undirectional API >> >> and one does the bidirectional API. My test programs actually exercise >> >> this. Of course, there's an assumption that the peer conforms to a 1:1 >> >> mapping. If we define unidirectional streams, we'll need some protocol >> >> mechanism to know if the other side is exercising this level of >> >> increased flexibility or not. I can imagine a number of options here >> >> (e.g., ALPN). We could also forbid 1:N mappings but I think that >> >> would be a mistake as it's a cool feature/benefit of doing >> >> unidirectional. >> >> >> >> The entire bidirectional wrapper shim is < 150 lines of Go code. >> >> (https://github.com/ekr/minq/blob/unidirectional_streams/bidi.go >> >> ). >> >> Converting my test application to this API was a matter of just >> >> changing class names, e.g., s/Connectionb/Connection2/. >> >> >> >> In my implementation, I assume that at the time Minq hears about a >> >> stream, you know if its related to a given existing stream. That way >> >> you can immediately either associate it with that stream or make a new >> >> local stream. In my implementation, I always send Related Stream Id >> >> and assume that you never get an "unrelated" stream frame before a >> >> "related" one. The spec doesn't really require that right now, and >> >> offline MT suggested just sending related with offset=3D0 but I think >> >> that's a mistake, because it means that you need to hold stream frames >> >> in some provisional "undetermined" state until you get that frame. I >> >> would suggest instead that we require that you include the field until >> >> one of the frames is ACKed. >> >> >> >> >> >> INTERNALS >> >> Sending and receiving streams still share a lot of common components: >> >> >> >> type baseStream struct { >> >> state streamState >> >> id uint32 >> >> log loggingFunction >> >> offset uint64 >> >> chunks []streamChunk >> >> maxStreamData uint64 >> >> isRelated bool >> >> related uint32 >> >> } >> >> >> >> type sendStream struct { >> >> baseStream >> >> blocked bool >> >> } >> >> >> >> type recvStream struct { >> >> baseStream >> >> } >> >> >> >> Most of this is the same as with bidirectional streams. As above, >> >> it's probably possible to make them more asymmetrical. >> >> >> >> The connection maintains separate lists of sending and receiving >> >> streams and it's straightforward to create and access them without >> >> worrying about the odd/even stuff. >> >> >> >> >> >> COMPARISON >> >> At the end of the day, I think this shows that these designs aren't >> >> really that disssimilar. I was able to convert Minq to unidirectional >> >> streams in about 16 total hours of work (basically a long plane flight >> >> plus the next morning). While I had to make a bunch of changes to the >> >> internal structures, basically none of them modified anything tricky, >> >> and in particular the flow control mechanics and the like are >> >> basically unchanged, except for a bunch of mechanical-type >> >> transformations like referring to |sendStream.chunks| instead of >> >> |stream.send.chunks|. The only really new protocol machinery is the >> >> new frame format for related streams. >> >> >> >> There are a few pros/cons that are worth noting about these designs. >> >> >> >> - Without a bidirectional API, having unidirectional streams is more >> >> work for the programmer. However, with an API shim, the difference >> >> is trivial. >> >> >> >> - Because undirectional streams are inherently more flexible, it's >> >> possible for the sides to try to use different mappings, e.g., one >> >> side expects paired and the other expects 1:N. We'll need some way >> >> of making sure that doesn't happen, maybe ALPN? >> >> >> >> - The "Related Stream ID" frame indicator needs fleshing out a bit. >> >> From the application's perspective, it should never hear about a >> >> stream without knowing its related status. And as noted above, I >> >> think it would be best if we required that all "first flight" stream >> >> frames that are related include the fied >> >> >> >> - Undirectional streams kind of sharpen the confusion about exactly >> >> what kinds of "closure" we want to allow. Specifically, what should >> >> implementations be able to say about their willingness to receive? >> >> Right now we have STOP_SENDING, but that doesn't influence the >> >> sender's state. I don't think undirectional streams make this worse, >> >> they just require us to think it through some more. They do simplify >> >> the implementation of the closure state machine: in my QUIC-05 code, >> >> whenever one side closes I have to have checks to see if I should be >> >> transitioning to CLOSED or HALF-CLOSED, etc, which is odd because >> >> the directions are basically independent. It would probably be >> >> easier even in QUIC-05 not to reify these states but just to >> >> determine the state from the composition of the individual >> >> sub-states >> >> >> >> - Unidirectional streams don't need the kind of annoying odd-even >> >> mechanics, which was easier to code up (just having to create all >> >> the lower-numbered streams of the same parity is kind of a pain). >> >> One additional benefit here is that with QUIC-05 there are several >> >> messages which involve implicit stream creation (e.g., >> >> STREAM_MAX_DATA, and RST_STREAM) and so you need to check whether >> >> the stream is one that should have been created locally or >> >> remotely. This just doesn't happen with bidirectional streams; I do >> >> implement odd/even mechanics but because the other side has to have >> >> its stream ids increment by one, I can make sure that they have the >> >> right IDs by construction and just check to see if the stream exists >> >> in these cases. I'd like to see us get rid of odd/even no matter >> >> what. >> >> >> >> - Unidirectional streams also helps avoid some of the corner cases aroun= d >> >> bidirectional streams. Specifically, suppose I am the client and >> >> I get MAX_STREAM_DATA as the first frame on stream 2. Am I allowed >> >> to just start sending or not? You can sort of get into this situation >> >> with unidirectional streams, but because it's explicit, one might >> >> hope that the application semantics would require clear specification. >> >> >> >> - As noted above, bidirectional streams are more flexible because they >> >> let you have mappings that you can't have with unidirectional >> >> streams (unpaired, 1:N). >> >> >> >> >> >> Happy to answer more questions if people have them. Otherwise we can >> >> talk about this in Seattle. >> >> >> >> -Ekr >> >> >> >> >> >> [0] https://github.com/ekr/minq/tree/unidirectional_streams >> >> >> [1] https://github.com/ekr/wg-materials/blob/404898fa2d2f0a9f9bd >> 244d2c945e66ea88502a2/interim-17-10/Unidirectional% >> 20Streams%20in%20Minq.pdf >> >> >> [2] Thanks to Patrick McManus for suggesting this design. >> >> [3] In C++, you would have a single function with a default argument of >> >> |nullptr| but Go doesn't support that, hence two different arguments= . >> >> [4] For implementation reasons, it's actually using Connection as a mixi= n, >> >> which means it's simultaneously possible to use the unidirectional >> >> and bidirectional APIs, but that's going to cause a lot of confusion= . >> >> A real implementation would probably have to either commit to one >> >> or the other or do a real wrapper, so you could only use one set of >> >> APIs, at the cost of having to do more forwarded methods. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> > > --001a113f176645ce75055a91875f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Oct 2, 2017 at 4:27 AM, Lubashev, Igor <ilubashe@akamai.com<= /a>> wrote:
> Nit: Can't you send RESET_STREAM
I do not think this is an option, since RESET_STREAM may prevent data buffe= red by the transport from being delivered to the application.


Those are also the seman= tics of STREAM(offset=3D0, FIN).

-Ekr



I am less concerned about how long connection state has to be kept around -= - in a cooperating peer situation, this is one rtt, which is the same amoun= t of time that is required to wait for an ACK. A malicious peer could withh= old ACKs for packets with STREAM+FIN. The bidirectional protocol is more chatty, though.



-----Original Message-----
From: Eric Rescorla [ekr@rtfm.com]
Received: Sunday, 01 Oct 2017, 5:29PM
To: Mike Bishop [Michael.Bishop@microsoft.com]
CC: Mikkel Fahn=C3=B8e J=C3=B8rgensen [mikkelfj@gmail.com]; IETF QUIC WG [quic@ietf.org]
Subject: Re: Report on Unidirectional Streams in Minq



On Sun, Oct 1, 2017 at 2:19 PM, Mike Bishop <Micha= el.Bishop@microsoft.com> wrote:

I think the difference is for the scenario where you= don=E2=80=99t expect a peer to respond (or don=E2=80=99t expect them to re= spond stream-by-stream).=C2=A0 With -05, the receiver still needs to send S= TREAM(offset=3D0,FIN) on each stream.


Nit: Can't you send RESET_STREAM?

=C2=A0

=C2=A0 With either unidirectional proposal, this pat= tern is a bit cleaner.=C2=A0 In #656, the sender can essentially say, =E2= =80=9CDon=E2=80=99t bother=E2=80=9D at the time of stream creation.=C2=A0 I= n #643, there=E2=80=99s no corresponding channel to close.


Yes, I agree that this is cleaner. Note that in #643 you presumably ne= ed to have some way of signaling that you don't want a return connectio= n....



In all cases, the only thing that really limits you = is the peer=E2=80=99s willingness to increase your MAX_STREAM_ID, it=E2=80= =99s just a question of how chatty you have to be =E2=80=93 which can matte= r if these messages are fairly small.


Agreed.

-Ekr
=C2=A0

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Sunday, October 1, 2017 2:03 PM
To: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>
Cc: IETF QUIC WG <quic@ietf.org>
Subject: Re: Report on Unidirectional Streams in Minq<= /p>

=C2=A0

I'm not sure I have any useful insights on this,= as my implementation handles them more or less the same. Can you explain w= hy you think this would be different with unidirectional versus bidirection= al?

=C2=A0

-Ekr

=C2=A0

=C2=A0

On Sun, Oct 1, 2017 at 1:38 PM, Mikkel Fahn=C3=B8e J= =C3=B8rgensen <m= ikkelfj@gmail.com> wrote:

Thanks,

=C2=A0

I only skimmed this superfast, but one the observ= ations appear to not cover one of my key points:

=C2=A0

You can create and close uni-streams at at very h= igh rate of many streams per packet, without waiting for peer response, ass= uming the ACK framework handles retransmission. Any insights on this?

=C2=A0

Kind Regards,

Mikkel Fahn=C3=B8e= J=C3=B8rgensen

=C2=A0

On 1 October 2017 at 22.32.02, Eric Rescorla (ekr@rtfm.com) wrote:

Hi folks,

=C2=A0

As promised I spent a bunch of time hacking unidirec= tional streams

into Minq and I'm here to report back [0]. Speci= fically, I

implemented:

=C2=A0

=C2=A0 - PR#643 -- Unidirectional Streams<= /u>

=C2=A0 - PR#720 -- Add bidirectional streams on top = of unidirectional

=C2=A0 - A bidirectional stream API that mostly mimi= cs Minq's original API

=C2=A0 =C2=A0 for -05.

=C2=A0 =C2=A0=C2=A0

The following is kind of a wall of text, so you coul= d also skip this

and refer to my slides [1].

=C2=A0

=C2=A0

MINQ'S -05 ARCHITECTURE

API

Minq's master object is the Connection, which ha= s a list of Streams

indexed by stream ID. Applications register a handle= r with the

connection to be notified of new events.

=C2=A0

=C2=A0 =C2=A0type ConnectionHandler interface {

=C2=A0 =C2=A0 // The connection has changed state to= state |s|

=C2=A0 =C2=A0 StateChanged(s State)

=C2=A0 =C2=A0

=C2=A0 =C2=A0 // A new stream has been created (by r= eceiving a frame

=C2=A0 =C2=A0 // from the other side. |s| contains t= he stream.

=C2=A0 =C2=A0 NewStream(s *Stream)

=C2=A0 =C2=A0

=C2=A0 =C2=A0 // Stream |s| is now readable.<= u>

=C2=A0 =C2=A0 StreamReadable(s *Stream)

=C2=A0 =C2=A0}

=C2=A0

Streams get created in two ways:

=C2=A0

- Locally via Connection.CreateStream()

- Remotely, in which case the application is notifie= d via a callback to

=C2=A0 ConnectionHandler.NewStream().<= /p>

=C2=A0

Streams themselves have the APIs you would expect, n= amely, Read(),

Write(), Close(), Reset(), etc. You get notified of = stream readability

by a callback to ConnectionHandler.StreamReadab= le(), at which point

you can do Stream.Read(). As expected, Stream.Read()= returns

WOULDBLOCK when no data ia available

=C2=A0

=C2=A0

INTERNALS

As noted above, we start with the Connection object = (only relevant fields

shown):

=C2=A0

=C2=A0 =C2=A0type Connection struct {<= /p>

=C2=A0 =C2=A0 handler=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 ConnectionHandler

=C2=A0 =C2=A0 streams=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 []*Stream

=C2=A0 =C2=A0 maxStream=C2=A0 =C2=A0 =C2=A0 =C2=A0 u= int32

outputClearQ=C2=A0 =C2=A0 =C2=A0[]frame // For strea= m 0

outputProtectedQ []frame // For stream >=3D 0<= /u>

=C2=A0 =C2=A0}

=C2=A0

As you can see, streams are in an array slice, so th= ey're contiguously

indexed by stream ID. Right now, I have no provision= for reclaiming

the unused bottom part of the array, but it would be= straightforward

to index by |streamId| - |minStream|, which I think = is consistent with

the design implied by the requirement to create stre= ams in sequence.

=C2=A0

Because Streams are bidirectional, each stream actua= lly consists of a

pair of half streams.

=C2=A0

=C2=A0 =C2=A0type streamHalf struct {<= /p>

=C2=A0 =C2=A0 s=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0*stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// pointer to = parent

=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0loggingFunction=C2=A0 =C2=A0

=C2=A0 =C2=A0 dir=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0direction=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0// Sending or receiving=

=C2=A0 =C2=A0 closed=C2=A0 =C2=A0 =C2=A0 =C2=A0 bool= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // Is the half-stream clos= ed

=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint= 64=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 // The

=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []st= reamChunk

=C2=A0 =C2=A0 maxStreamData uint64

=C2=A0 =C2=A0}

=C2=A0

=C2=A0 =C2=A0// Internal object to allow unit testin= g.

=C2=A0 =C2=A0type stream struct {

=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ui= nt32

=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 logging= Function

=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 streamState<= u>

=C2=A0 =C2=A0 send, recv *streamHalf

=C2=A0 blocked=C2=A0 =C2=A0 bool // Have we returned= blocked

=C2=A0 =C2=A0}

=C2=A0

=C2=A0 =C2=A0// Public API object, which needs acces= s to the Connection

=C2=A0 =C2=A0type Stream struct {

=C2=A0 =C2=A0 c *Connection

=C2=A0 =C2=A0 stream

=C2=A0 =C2=A0}

=C2=A0

Outgoing data is enqueued into |stream.chunks|, and = then periodically

the connection polls the stream for all the chunks w= hich are permitted

by stream-level flow control and enqueues them into<= u>

|Connection.outputClearQ| or |Connection.outputProte= ctedQ|. At this

point, the connection owns the data and is responsib= le for

transmitting it, subject to connection-level flow co= ntrol, and

(presumably) congestion control once I have that imp= lemented [2].

=C2=A0

Incoming data gets queued (sorted) into |stream.chun= ks| for later

reassembly at the time when someone calls stream.rea= d(). I'm not sure

I love this, because it means I don't have a goo= d view of the incoming

queue size (which I'd need to account for separa= tely), but it allowed

me to share data structures between incoming and out= going, which

seemed kind of natural when I did it (this architect= ure is replicated

in the unidirectional streams design, but it's p= robably less natural

there).

=C2=A0

=C2=A0

UNIDIRECTIONAL STREAMS ARCHITECTURE

UNIDIRECTIONAL API

With the unidirectional branch, Minq offers two APIs= . The first is a

straightforward mapping of PR#720, in which we have = two objects:

=C2=A0

=C2=A0 SendStream -- used for writing<= /p>

=C2=A0 RecvStream -- used for reading<= /p>

=C2=A0

As before, we have a handler object, but it's di= rectional now:

=C2=A0

=C2=A0 =C2=A0type ConnectionHandler interface {

=C2=A0 =C2=A0 // The connection has changed state to= state |s|

=C2=A0 =C2=A0 StateChanged(s State)

=C2=A0 =C2=A0

=C2=A0 =C2=A0 // A new receiving stream has been cre= ated (by receiving a frame

=C2=A0 =C2=A0 // from the other side. |s| contains t= he stream.

=C2=A0 =C2=A0 NewRecvStream(s *RecvStream)=

=C2=A0 =C2=A0

=C2=A0 =C2=A0 // Stream |s| is now readable.<= u>

=C2=A0 =C2=A0 StreamReadable(s *RecvStream)

=C2=A0 =C2=A0}

=C2=A0

Obviously SendStreams are locally created and RecvSt= reams are remotely

created. SendStreams can be created using<= /u>

Connection.CreateSendStream() and you learn about re= motely created

RecvStreams by a callback to ConnectionHandler.NewRe= cvStream().

Second-created streams can be marked as "relate= d" to a single

first-created stream, using Connection.CreateRelated= SendStream() with

the appropriate RecvStream as the argument [3]. Stre= ams have a

Related() API to tell you if they are related to som= e other stream.

=C2=A0

The {Send,Recv}Stream APIs are about what you'd = expect. You can

Write() on SendStream and Read() on RecvStream(). Ri= ght now, you can

Close() and Reset() SendStreams, but not do anything= on RecvStreams()

or than ignore them. Eventually I'll probably of= fer

RecvStream().Mute() or something to let you send STO= P_SENDING.

=C2=A0

=C2=A0

BIDIRECTIONAL API

Minq also includes a bidirectional API that's la= yered on top of

unidirectional streams. I've created a Connectio= n2 structure that's

intended as a wrapper around Connection [4]:<= u>

=C2=A0

=C2=A0 =C2=A0type Connection2 struct {=

=C2=A0 =C2=A0 Connection

=C2=A0 =C2=A0 shim=C2=A0 =C2=A0 *connection2ShimHand= ler

=C2=A0 =C2=A0 streams []*Stream // Odd for client or= iginated, even for server.

=C2=A0 =C2=A0}

=C2=A0 =C2=A0 =C2=A0

=C2=A0 =C2=A0type Stream struct {

=C2=A0 =C2=A0 id=C2=A0 =C2=A0uint32

=C2=A0 =C2=A0 send *SendStream

=C2=A0 =C2=A0 recv *RecvStream

=C2=A0 =C2=A0}

=C2=A0

Basically, Stream is just a pair of SendStream and R= ecvStream and

Connection2 does the bookkeeping to keep them connec= ted (I even do the

odd/even ID thing that QUIC-05 has). Connection2 has= the same handler

API as Minq for QUIC-05, and the shim is responsible= for translating

unidirectional events into bidirectional events.<= /u>

=C2=A0

Internally, what's going on here is that when yo= u call CreateStream()

Minq creates a Stream with a nil RecvStream. When a = new remote stream

is detected, we check RecvStream.Related(). If they = are related to an

existing SendStream then we will in the relevant |St= ream.send| slot.

Otherwise, we create a new SendStream that's rel= ated to the incoming

stream and notify the application of the creation of= the new

bidirectional stream.

=C2=A0

Note that this all works fine if one side does the u= ndirectional API

and one does the bidirectional API. My test programs= actually exercise

this. Of course, there's an assumption that the = peer conforms to a 1:1

mapping. If we define unidirectional streams, we'= ;ll need some protocol

mechanism to know if the other side is exercising th= is level of

increased flexibility or not. I can imagine a number= of options here

(e.g., ALPN).=C2=A0 We could also forbid 1:N mapping= s but I think that

would be a mistake as it's a cool feature/benefi= t of doing

unidirectional.

=C2=A0

The entire bidirectional wrapper shim is < 150 li= nes of Go code.

Converting my test application to this API was a mat= ter of just

changing class names, e.g., s/Connectionb/Connection= 2/.

=C2=A0

In my implementation, I assume that at the time Minq= hears about a

stream, you know if its related to a given existing = stream.=C2=A0 That way

you can immediately either associate it with that st= ream or make a new

local stream. In my implementation, I always send Re= lated Stream Id

and assume that you never get an "unrelated&quo= t; stream frame before a

"related" one. The spec doesn't really= require that right now, and

offline MT suggested just sending related with offse= t=3D0 but I think

that's a mistake, because it means that you need= to hold stream frames

in some provisional "undetermined" state u= ntil you get that frame. I

would suggest instead that we require that you inclu= de the field until

one of the frames is ACKed.

=C2=A0=C2=A0

=C2=A0

INTERNALS

Sending and receiving streams still share a lot of c= ommon components:

=C2=A0

=C2=A0 =C2=A0 type baseStream struct {=

=C2=A0 =C2=A0 state=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0streamState

=C2=A0 =C2=A0 id=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 uint32

=C2=A0 =C2=A0 log=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0loggingFunction

=C2=A0 =C2=A0 offset=C2=A0 =C2=A0 =C2=A0 =C2=A0 uint= 64

=C2=A0 =C2=A0 chunks=C2=A0 =C2=A0 =C2=A0 =C2=A0 []st= reamChunk

=C2=A0 =C2=A0 maxStreamData uint64

=C2=A0 =C2=A0 isRelated=C2=A0 =C2=A0 =C2=A0bool

=C2=A0 =C2=A0 related=C2=A0 =C2=A0 =C2=A0 =C2=A0uint= 32

=C2=A0 =C2=A0 }

=C2=A0 =C2=A0=C2=A0

=C2=A0 =C2=A0 type sendStream struct {=

=C2=A0 =C2=A0 baseStream

=C2=A0 =C2=A0 blocked bool

=C2=A0 =C2=A0 }

=C2=A0 =C2=A0=C2=A0

=C2=A0 =C2=A0 type recvStream struct {=

=C2=A0 =C2=A0 baseStream

=C2=A0 =C2=A0 }

=C2=A0

Most of this is the same as with bidirectional strea= ms.=C2=A0 As above,

it's probably possible to make them more asymmet= rical.

=C2=A0

The connection maintains separate lists of sending a= nd receiving

streams and it's straightforward to create and a= ccess them without

worrying about the odd/even stuff.

=C2=A0

=C2=A0

COMPARISON

At the end of the day, I think this shows that these= designs aren't

really that disssimilar. I was able to convert Minq = to unidirectional

streams in about 16 total hours of work (basically a= long plane flight

plus the next morning). While I had to make a bunch = of changes to the

internal structures, basically none of them modified= anything tricky,

and in particular the flow control mechanics and the= like are

basically unchanged, except for a bunch of mechanica= l-type

transformations like referring to |sendStream.chunks= | instead of

|stream.send.chunks|. The only really new protocol m= achinery is the

new frame format for related streams.<= /p>

=C2=A0

There are a few pros/cons that are worth noting abou= t these designs.

=C2=A0

- Without a bidirectional API, having unidirectional= streams is more

=C2=A0 work for the programmer. However, with an API= shim, the difference

=C2=A0 is trivial.

=C2=A0

- Because undirectional streams are inherently more = flexible, it's

=C2=A0 possible for the sides to try to use differen= t mappings, e.g., one

=C2=A0 side expects paired and the other expects 1:N= . We'll need some way

=C2=A0 of making sure that doesn't happen, maybe= ALPN?

=C2=A0

- The "Related Stream ID" frame indicator = needs fleshing out a bit.

=C2=A0 From the application's perspective, it sh= ould never hear about a

=C2=A0 stream without knowing its related status. An= d as noted above, I

=C2=A0 think it would be best if we required that al= l "first flight" stream

=C2=A0 frames that are related include the fied

=C2=A0

- Undirectional streams kind of sharpen the confusio= n about exactly

=C2=A0 what kinds of "closure" we want to = allow. Specifically, what should

=C2=A0 implementations be able to say about their wi= llingness to receive?

=C2=A0 Right now we have STOP_SENDING, but that does= n't influence the

=C2=A0 sender's state. I don't think undirec= tional streams make this worse,

=C2=A0 they just require us to think it through some= more. They do simplify

=C2=A0 the implementation of the closure state machi= ne: in my QUIC-05 code,

=C2=A0 whenever one side closes I have to have check= s to see if I should be

=C2=A0 transitioning to CLOSED or HALF-CLOSED, etc, = which is odd because

=C2=A0 the directions are basically independent.=C2= =A0 It would probably be

=C2=A0 easier even in QUIC-05 not to reify these sta= tes but just to

=C2=A0 determine the state from the composition of t= he individual

=C2=A0 sub-states

=C2=A0=C2=A0

- Unidirectional streams don't need the kind of = annoying odd-even

=C2=A0 mechanics, which was easier to code up (just = having to create all

=C2=A0 the lower-numbered streams of the same parity= is kind of a pain).

=C2=A0 One additional benefit here is that with QUIC= -05 there are several

=C2=A0 messages which involve implicit stream creati= on (e.g.,

=C2=A0 STREAM_MAX_DATA, and RST_STREAM) and so you n= eed to check whether

=C2=A0 the stream is one that should have been creat= ed locally or

=C2=A0 remotely. This just doesn't happen with b= idirectional streams; I do

=C2=A0 implement odd/even mechanics but because the = other side has to have

=C2=A0 its stream ids increment by one, I can make s= ure that they have the

=C2=A0 right IDs by construction and just check to s= ee if the stream exists

=C2=A0 in these cases.=C2=A0 I'd like to see us = get rid of odd/even no matter

=C2=A0 what.

=C2=A0

- Unidirectional streams also helps avoid some of th= e corner cases around

=C2=A0 bidirectional streams. Specifically, suppose = I am the client and

=C2=A0 I get MAX_STREAM_DATA as the first frame on s= tream 2. Am I allowed

=C2=A0 to just start sending or not? You can sort of= get into this situation

=C2=A0 with unidirectional streams, but because it&#= 39;s explicit, one might

=C2=A0 hope that the application semantics would req= uire clear specification.

=C2=A0=C2=A0

- As noted above, bidirectional streams are more fle= xible because they

=C2=A0 let you have mappings that you can't have= with unidirectional

=C2=A0 streams (unpaired, 1:N).

=C2=A0

=C2=A0

Happy to answer more questions if people have them. = Otherwise we can

talk about this in Seattle.

=C2=A0

-Ekr

=C2=A0

=C2=A0

[2] Thanks to Patrick McManus for suggesting this de= sign.

[3] In C++, you would have a single function with a = default argument of

=C2=A0 =C2=A0 |nullptr| but Go doesn't support t= hat, hence two different arguments.

[4] For implementation reasons, it's actually us= ing Connection as a mixin,

=C2=A0 =C2=A0 which means it's simultaneously po= ssible to use the unidirectional

=C2=A0 =C2=A0 and bidirectional APIs, but that's= going to cause a lot of confusion.

=C2=A0 =C2=A0 A real implementation would probably h= ave to either commit to one

=C2=A0 =C2=A0 or the other or do a real wrapper, so = you could only use one set of

=C2=A0 =C2=A0 APIs, at the cost of having to do more= forwarded methods.

=C2=A0 =C2=A0=C2=A0

=C2=A0=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0

=C2=A0



--001a113f176645ce75055a91875f-- From nobody Mon Oct 2 07:54: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 45B85134688 for ; Mon, 2 Oct 2017 07:54:08 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stqJlGF-Ug5S for ; Mon, 2 Oct 2017 07:54:05 -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 BE746134683 for ; Mon, 2 Oct 2017 07:54:05 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id u205so3834287ywa.5 for ; Mon, 02 Oct 2017 07:54:05 -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=6BCPcAHhrNR+JkhTGVcWhZ5flDSGckF7fKUtJlcuMLE=; b=nsKrmGLDw2ETWg6rglUCYJ4lMMwbIZeA3TQdJXCNbUDBgoQyRDHkxiyM+3GSCgFn0u 6kRSvinEKenLtc1ExAtGeoceHS7dzXDPsXEglWpnl/KF2XdkCHcifYwl29szrFZ3q0FN Ng0zGalTdblE2bG12BHq7wyQDOc5RFSF9n7nRFOTAHnYdmUM19/hrA1USOnMj3wFRX1K hYmhnI3fQ3sQsLO0Rdaq2ovrv11zp6J2hv/mTSc251v2R55GVPNWJgvTIYLTQJQIjYGc uiziXo/KSJZAX7Xx0NM3zW8A7WRgrPNoJqPFq4aGAEtCsBagJUhytXaK6o2NPIY/e2b5 TW7g== 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=6BCPcAHhrNR+JkhTGVcWhZ5flDSGckF7fKUtJlcuMLE=; b=NVgglKw2eFfVvMcX31pt5NbJ2MOvtqdmRIOYE/i3UI0MzBrVW+u8+JCXlqW9blp265 VSS7U5gsltW6Z/u2jwLaAastV6c9lFYvVHcxKZdzSTKk9Xrkn5iIH2gI4NI7qoeKGDZA 0m6GBnEbTLyc3csc/q8eiUkglPKbF4lItT/3rfg1hKeabTM1e6zr3ZVXVpaqoeEew0f1 GsG2KBSsxJ/ZrpbEbMMlPl48sRDUq3oehqFHqxWUFcKE83nKH7xaiQj7AG/SxNC5AAWa bFqudu9ALvNdEvDBDB2S6uI8i25D08ZFkw8YNmNJaJlYL761WzpHZ16x9a6RZ7Dokx5Z Rt8g== X-Gm-Message-State: AHPjjUhUL05ilnQnAHI5OusmHepb4hqLUbUCvnZkqC37eFlycytW+Aog 57gJfry1mypXGpi/SgnAOoeINH9Mp2HnqZVd+wlB6xQK X-Google-Smtp-Source: AOwi7QBkE3U+ZAVhKDN97V+2jwnES5qA7Syo5hTcK8Q2gN22401qcHWGQTlvK9pIl42CEr0BET4KZvgNnWDSxrvjSKY= X-Received: by 10.129.198.13 with SMTP id l13mr12623196ywi.457.1506956044945; Mon, 02 Oct 2017 07:54:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Mon, 2 Oct 2017 07:53:24 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Mon, 2 Oct 2017 07:53:24 -0700 Message-ID: Subject: Re: Compression and zstd licensing update To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c1a5d5ac061c5055a918b84" 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, 02 Oct 2017 14:54:08 -0000 --94eb2c1a5d5ac061c5055a918b84 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would not be in favor of including any compression of the plaintext in QUIC. We already know that compression + encryption is dangerous, which is why we removed it from TLS 1.3. -Ekr On Mon, Oct 2, 2017 at 2:20 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > FYI: > > I have just gotten confirmation by the author that Facebooks zstd > compression library is now a pure BSD license without PATENTS protection > claims which Facebook also removed from ReactJS and graphQL. > > This means that zstd it could be a viable compression technology, for > example in QUIC/HTTP - though I haven=E2=80=99t followed the HTTP efforts= closely. > > zstd appears to have the best tradeoff in terms of > cost/bandwidth/computation effort while I personally would use LZ4 for so= me > performance critical applications to due raw speed where bandwidth is > sufficient. > > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > --94eb2c1a5d5ac061c5055a918b84 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would not be in favor of including any compression of th= e plaintext in QUIC. We already know that compression + encryption is dange= rous, which is why we removed it from TLS 1.3.

-Ekr


On Mon, Oct 2, 2017 at 2:20 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <m= ikkelfj@gmail.com> wrote:
<= div style=3D"word-wrap:break-word">
FYI:

I have just= gotten confirmation by the author that Facebooks zstd compression library = is now a pure BSD license without PATENTS protection claims which Facebook = also removed from ReactJS and graphQL.

This means that= zstd it could be a viable compression technology, for example in QUIC/HTTP= - though I haven=E2=80=99t followed the HTTP efforts closely.

=
zstd appears to have the best tradeoff in terms of cost/bandwidth/= computation effort while I personally would use LZ4 for some performance cr= itical applications to due raw speed where bandwidth is sufficient.



Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgens= en


--94eb2c1a5d5ac061c5055a918b84-- From nobody Mon Oct 2 08:01: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 26D86134695 for ; Mon, 2 Oct 2017 08:01:17 -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, 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=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 n6zhuK3moPNI for ; Mon, 2 Oct 2017 08:01:11 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 1FC41134691 for ; Mon, 2 Oct 2017 08:01:10 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v92Ev5r6026530; Mon, 2 Oct 2017 16:01:09 +0100 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=mirAUVZ4Blt5HCo3Qc1f8NrsQ9SMTwriORNGO8a9QWE=; b=F7HwS+VK3BZwh+EXiJhpRy4h5gBMNn5DQfr5tDyPfS/RoOv9XIpWnfmdJED6qvvyisIo agSK72WZljJqvEKrZV4noJlHL39H+J2si1AIMu3O7lUw1RifS4pq/Ge0xOHyVm2ljpYw 7GeBx0XL72412FS+2RmPCpBsmCQVXXksxTwc+W+N+ZRGgjakhgonz+/KbqKt6LeU0v9Z FVN9E7Ty2z7NOrqBWvO3+qhfeSUqtVFHcuoIoaOfK0qaHQ/iQ6lEJqLHcUr8vfeust6l k8LV78xurdDCip7XgZhlNdfp71sCnXASuQVG2qJcLc3oYxhyAWTsP+VKQlnDFilY7McM ew== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2da3agbr55-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Oct 2017 16:01:08 +0100 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 v92F11QS001392; Mon, 2 Oct 2017 11:01:07 -0400 Received: from email.msg.corp.akamai.com ([172.27.25.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2da6ku4r9k-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 02 Oct 2017 11:01:07 -0400 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com (172.27.27.101) by ustx2ex-dag1mb1.msg.corp.akamai.com (172.27.27.101) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 2 Oct 2017 10:01:06 -0500 Received: from USTX2EX-DAG1MB1.msg.corp.akamai.com ([172.27.6.131]) by ustx2ex-dag1mb1.msg.corp.akamai.com ([172.27.6.131]) with mapi id 15.00.1263.000; Mon, 2 Oct 2017 10:01:06 -0500 From: "Salz, Rich" To: Eric Rescorla , =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= CC: IETF QUIC WG Subject: Re: Compression and zstd licensing update Thread-Topic: Compression and zstd licensing update Thread-Index: AQHTO1/Eo9QG87tGXUONxY8oVPG1l6LQ+XYAgAACJwA= Date: Mon, 2 Oct 2017 15:01:06 +0000 Message-ID: <5266A1B3-3DD5-40B1-98A2-3C9AFA8D1B71@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.26.0.170902 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.225] Content-Type: multipart/alternative; boundary="_000_5266A1B33DD540B198A23C9AFA8D1B71akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-02_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-1710020219 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-02_03:, , 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-1710020218 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, 02 Oct 2017 15:01:17 -0000 --_000_5266A1B33DD540B198A23C9AFA8D1B71akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 PiBJIHdvdWxkIG5vdCBiZSBpbiBmYXZvciBvZiBpbmNsdWRpbmcgYW55IGNvbXByZXNzaW9uIG9m IHRoZSBwbGFpbnRleHQgaW4gUVVJQy4gV2UgYWxyZWFkeSBrbm93IHRoYXQgY29tcHJlc3Npb24g KyBlbmNyeXB0aW9uIGlzIGRhbmdlcm91cywgd2hpY2ggaXMgd2h5IHdlIHJlbW92ZWQgaXQgZnJv bSBUTFMgMS4zLg0KDQpTdHJvbmdseSBhZ3JlZS4gIEJlZW4gdGhlcmUsIGRvbmUgdGhhdCwgZ290 IHRoZSBDVkUuDQpMZWF2ZSBpdCB1cCB0byB0aGUgYXBwbGljYXRpb24gbGF5ZXIuDQoNCg== --_000_5266A1B33DD540B198A23C9AFA8D1B71akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <79EC9241DF712647A1C31A288413407F@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEkgd291bGQgbm90IGJlIGluIGZh dm9yIG9mIGluY2x1ZGluZyBhbnkgY29tcHJlc3Npb24gb2YgdGhlIHBsYWludGV4dCBpbiBRVUlD LiBXZSBhbHJlYWR5IGtub3cgdGhhdCBjb21wcmVzc2lvbiAmIzQzOyBlbmNyeXB0aW9uIGlzIGRh bmdlcm91cywgd2hpY2ggaXMgd2h5IHdlIHJlbW92ZWQgaXQgZnJvbSBUTFMgMS4zLg0KPG86cD48 L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TdHJvbmdseSBhZ3JlZS4mbmJzcDsgQmVlbiB0aGVy ZSwgZG9uZSB0aGF0LCBnb3QgdGhlIENWRS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkxlYXZlIGl0IHVwIHRvIHRoZSBhcHBsaWNhdGlvbiBsYXllci48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5266A1B33DD540B198A23C9AFA8D1B71akamaicom_-- From nobody Mon Oct 2 08:04: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 64608134691 for ; Mon, 2 Oct 2017 08:04:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, 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 QH6QMyrprEDE for ; Mon, 2 Oct 2017 08:04:05 -0700 (PDT) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3B55132076 for ; Mon, 2 Oct 2017 08:04:04 -0700 (PDT) Received: by mail-io0-x232.google.com with SMTP id w94so4970225ioi.7 for ; Mon, 02 Oct 2017 08:04:04 -0700 (PDT) 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=8gDrEmBZZjO7Ii2pePZHdr3Qq9s/PnZkC36C6hJ2iIE=; b=AtrnQdqNBI3Fz5KD8B9k39EQoYAOrhFsPHIP+mlDRta/a82LoFQITQEz9EG8LenLKm QEh6gSAtyGvAU5YbjLSVqnkiRwS2ZfD4klJylwM7Uewp+5GhHgYH5WNChHNNei3jiexg FVo7rBSEZKn0KFC0+j25TCdp43nyH0fdF5BZUN8z9RLiEI51vLahU/3eESq+nBKyT4HM zKj0ZVtjgNri4eT46V0D80Y9+DHfgu9UDyn5wP6/QsSKlcshF7mYMi0w4ygxZSgWvG4y 3cOQxB9pMCm6NANp5aoJOEcIdfNWPWduSm8CFdgTv3o8nmQtd2j+fIaujmdqGNMlHivK bSgA== 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=8gDrEmBZZjO7Ii2pePZHdr3Qq9s/PnZkC36C6hJ2iIE=; b=BHjM+Qe3OgO4Mwn3Bi7Xyq66P5BlHPgJwk6q6q8UD9sEkv91RPBFxSjVRQ3FUYWJ+3 X6BWP/dfUIsrLV/yhjWEOlFDlk9idqseO+od0tHracfN+BphSBPcO3KMtb2rt//1N1G1 jExUeMorDLRHOMswpVvDI15dYUaOKhuGBpjiyq7kE5zQFDKjrnDtb5Xef1TTypUs63re YkqJ/be7dY4I/+634EusCsiepLkgL6+v86lwf7j0KtJ2Y8+XF20gqDyCReBERI+ai5Z0 AD1+q5C0I0wC1lQL2D1bBMNmHE1FFpcEGkTtyqQPJm+2j/KSq8JhQFD33h1tIucZOktC tsDA== X-Gm-Message-State: AMCzsaU6O1rW2h+jyOt+spyKek9wzzQT0iuwezo6gJoR2sdsEc9Nj9Z9 1joig0KFurfAS2izB0ta0i73VV9XoL9pJnQRpmTzqg== X-Google-Smtp-Source: AOwi7QCSVi9bGoatL0GEcUq9PK3MtZ65RboS/aR6qRZkbVagQhFBWgq/pj49fSCkzgzbhZ80ys7tNcRGGvwd8VJdnkI= X-Received: by 10.107.147.196 with SMTP id v187mr24825748iod.92.1506956644116; Mon, 02 Oct 2017 08:04:04 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 2 Oct 2017 17:04:03 +0200 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 2 Oct 2017 17:04:03 +0200 Message-ID: Subject: Re: Compression and zstd licensing update To: Eric Rescorla Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c05b10e76ed8f055a91af62" 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, 02 Oct 2017 15:04:11 -0000 --94eb2c05b10e76ed8f055a91af62 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Certainly not for transport, I fully agree. But some application level protocols do need compression - in the extreme you would not send images in RAW format. I do not have a good answer to the risks of compression other than ensuring padding up to a certain block size and avoid compressing very sensitive data. Have applications protocols handling this might be safer than having leaving it to arbitrary pre-compression fed into the com channel. Regardless, I=E2=80=99m not advocating adding compression, only highlightin= g that wherever compression is deemed relevant, zstd is now a more approachable option. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 2 October 2017 at 16.54.05, Eric Rescorla (ekr@rtfm.com) wrote: I would not be in favor of including any compression of the plaintext in QUIC. We already know that compression + encryption is dangerous, which is why we removed it from TLS 1.3. -Ekr On Mon, Oct 2, 2017 at 2:20 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > FYI: > > I have just gotten confirmation by the author that Facebooks zstd > compression library is now a pure BSD license without PATENTS protection > claims which Facebook also removed from ReactJS and graphQL. > > This means that zstd it could be a viable compression technology, for > example in QUIC/HTTP - though I haven=E2=80=99t followed the HTTP efforts= closely. > > zstd appears to have the best tradeoff in terms of > cost/bandwidth/computation effort while I personally would use LZ4 for so= me > performance critical applications to due raw speed where bandwidth is > sufficient. > > > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > --94eb2c05b10e76ed8f055a91af62 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Certainly not for transport, I fully agree.
=

But some application leve= l protocols do need compression - in the extreme you would not send images = in RAW format. I do not have a good answer to the risks of compression othe= r than ensuring padding up to a certain block size and avoid compressing ve= ry sensitive data. Have applications protocols handling this might be safer= than having leaving it to arbitrary pre-compression fed into the com chann= el.

Regardless, I=E2= =80=99m not advocating adding compression, only highlighting that wherever = compression is deemed relevant, zstd is now a more approachable option.
Kind Regards,
<= div style=3D"font-family:helvetica,arial;font-size:13px">Mikkel Fahn=C3=B8e= J=C3=B8rgensen


On 2 Octobe= r 2017 at 16.54.05, Eric Rescorla (ekr@rtfm= .com) wrote:

I would not be in favor of including any compression of the plaintext in QUIC. We already know that compression + encryption is dangerous, which is why we removed it from TLS 1.3.

-Ekr


On Mon, Oct 2, 2017 at 2:20 AM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com> wrote:
FYI:

I have just gotten confirmation by the author that Facebooks zstd compression library is now a pure BSD license without PATENTS protection claims which Facebook also removed from ReactJS and graphQL.

This means that zstd it could be a viable compression technology, for example in QUIC/HTTP - though I haven=E2=80=99t followed the HTTP efforts closely.

zstd appears to have the best tradeoff in terms of cost/bandwidth/computation effort while I personally would use LZ4 for some performance critical applications to due raw speed where bandwidth is sufficient.



Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


--94eb2c05b10e76ed8f055a91af62-- From nobody Mon Oct 2 09:08: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 89396133059 for ; Mon, 2 Oct 2017 09:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.03 X-Spam-Level: X-Spam-Status: No, score=-0.03 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, 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 xMXiJnydHioj for ; Mon, 2 Oct 2017 09:08:30 -0700 (PDT) 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 F249813304D for ; Mon, 2 Oct 2017 09:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=WmzGZBcr9J8r8PTQMgFpdnZIQmAazvbK8XGWeT7Edoc=; b=Z1B2ROPxHZj+jInc2ZS1fuuKcvF9kkcVH0Os/mjmifru7dggIksXy0TGQenuPtFuQH07E/EMXGly4lYd6vxPcXHTdBI1B1KiVNx+XGfHsb7tH9FBWwteZgSjAZSfa4RCsKDeQ/J/Bz04SFn3ZVezPBrCPo43EQQbaPhxVd1LgAM= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0831.namprd21.prod.outlook.com (10.173.51.9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.98.0; Mon, 2 Oct 2017 16:08:26 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0122.000; Mon, 2 Oct 2017 16:08:26 +0000 From: Mike Bishop To: Eric Rescorla , "Lubashev, Igor" CC: "quic@ietf.org" , "mikkelfj@gmail.com" Subject: RE: Report on Unidirectional Streams in Minq Thread-Topic: Report on Unidirectional Streams in Minq Thread-Index: AQHTOvRa67AX08lqTkeBz6F3cSHDd6LPdJiAgAAG7ICAAANWQIAAA8gAgADqVICAADksgIAAFJrA Date: Mon, 2 Oct 2017 16:08:26 +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: [2601:600:8080:5a28:35a7:ae5f:8a95:4bde] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0831; 6:p5451mAKFTmazwk9pUSZ8IzBZteVl3eRuRLAka7tnpHJJQNEiOConSLUdQpd+tj2NF/OMaVawrST1K/STZ6M8qP8cC6TtPfzBTi9BN990GFVzBlRXwOisPuv1qvxNGJHPi9IsyOpw9b1SEuqfyqevJVMWPgr3lr5xaOUu7rdS7W0utWOlpUilrYzoLqK2fI88XdfaaTggHOm1CTuxhwMvJwImPScI3gzbLSnDS21EYf51mVLBYxXa17/GXB1NlaBR7Fb8l6tesAt5hbtuWwHiYFxojeOMfDxVE/EagFq6ydsxpJxtJ+T640b49ggQFuh/LX0bp9Eg6Nazy4H7/avpg==; 5:yVlPB/ut/ysQ2Q/Ut+69Vlh031n1+4/sTUTAXLZ2hAdklYE5Eu/k9Da6vDRofBhPC7Q15aC6S8Hrzl00DBocpDUBtPoOTyx/A5k0w1PIVDpQCW16zChFPZihXXB/oBS9fEJ3m7YYPewjp8t+7rTs5g==; 24:YDLIhGYIuijmsbjQnY2Jziu6aq35+9ih8SNq0b4Vbb+u0K3FL9o4nxFFE8ZyrFFEnZll9DuN/IpZzRjeFlZoVwX+0QLWILoytW2SnuYd+dU=; 7:dqCR49epWqBAPRgTuRq2/nhqK8Y923tG4pW74Y5SIlzjCN9WkZU68VM8kbikOsdpefsBkG1ynBDyBOCbyuN9sXWddQYiyQxMIPBsUHiT5dPd8mEUn3zRmB1X7Y1AOwfTDJJPYNM/KvsS7Q/9ktKFCfLbeNdtTW7KencLgzoeWxSwkoY/zPadpUlWr6Y60JTYAF9WT6XE44HqRq0xxfMFUursdysUXtK0tzGaON53i5E= x-ms-exchange-antispam-srfa-diagnostics: SOS; x-ms-office365-filtering-correlation-id: 7ed9468b-a400-424d-f5d7-08d509afd0b9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR21MB0831; x-ms-traffictypediagnostic: MWHPR21MB0831: x-exchange-antispam-report-test: UriScan:(278428928389397)(89211679590171)(166708455590820)(189930954265078)(219752817060721)(21748063052155)(148717330147763); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(12181511122)(100000703101)(100105400095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123562025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0831; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0831; x-forefront-prvs: 0448A97BF2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(346002)(47760400005)(199003)(51444003)(189002)(377454003)(13464003)(24454002)(3660700001)(316002)(229853002)(33656002)(4326008)(561944003)(575784001)(86362001)(54906003)(14454004)(77096006)(97736004)(6436002)(2950100002)(606006)(5660300001)(106356001)(55016002)(99286003)(54896002)(6306002)(9686003)(110136005)(7696004)(105586002)(19609705001)(74316002)(236005)(7736002)(478600001)(86612001)(189998001)(76176999)(3280700002)(54356999)(6506006)(39060400002)(10290500003)(50986999)(68736007)(2906002)(101416001)(6246003)(25786009)(22452003)(53936002)(8990500004)(102836003)(966005)(6116002)(81156014)(53946003)(790700001)(2900100001)(10090500001)(8936002)(53546010)(8676002)(16200700003)(81166006)(72206003)(93886005)(569006); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0831; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01413BF390A41A30611441D3877D0MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Oct 2017 16:08:26.6849 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0831 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, 02 Oct 2017 16:08:35 -0000 --_000_MWHPR21MB01413BF390A41A30611441D3877D0MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB5b3XigJlyZSB0YWxraW5nIHBhc3QgZWFjaCBvdGhlci4gIElnb3IsIHRoZSBkcmFm dCBjdXJyZW50bHkgc2F5cyB0aGF0IFJTVF9TVFJFQU0gYXBwbGllcyB0byB0aGUgc2VuZGVy4oCZ cyBkaXJlY3Rpb24gb25seSwgc28gc2VuZGluZyBhIFJTVF9TVFJFQU0gZG9lc27igJl0IGhlbHAg YW55dGhpbmcuICBUaGUgb3RoZXIgc2lkZSBjb3VsZCByZWFzb25hYmx5IHNlbmQgUlNUX1NUUkVB TSBvciB0aGUgU1RSRUFNLUZJTiwgYW5kIHRoZXnigJlyZSBpZGVudGljYWwgZm9yIGFsbCBwcmFj dGljYWwgcHVycG9zZXMuICBUaGUgcG9pbnQgaXMgdGhhdCBvbmUgc2lkZSBpcyBzZW5kaW5nIGFs bCB0aGUgZGF0YSwgYnV0IHRoZSBvdGhlciBzaWRlIHN0aWxsIGhhcyB0byBhY2sgb24gdGhlIHN0 cmVhbSBmb3IgaXQgdG8gcmVhY2ggdGhlIGNsb3NlZCBzdGF0ZS4gIFVuaWRpcmVjdGlvbmFsIHN0 cmVhbXMgZG9u4oCZdCByZXF1aXJlIGFueSBwZXItc3RyZWFtIGFjdGlvbiBieSB0aGUgcmVjZWl2 ZXIgdG8gY29tcGxldGUgdGhlIHN0YXRlIG1hY2hpbmUuDQoNCkZyb206IEVyaWMgUmVzY29ybGEg W21haWx0bzpla3JAcnRmbS5jb21dDQpTZW50OiBNb25kYXksIE9jdG9iZXIgMiwgMjAxNyA3OjUy IEFNDQpUbzogTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+DQpDYzogTWlrZSBC aXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+OyBxdWljQGlldGYub3JnOyBtaWtr ZWxmakBnbWFpbC5jb20NClN1YmplY3Q6IFJlOiBSZXBvcnQgb24gVW5pZGlyZWN0aW9uYWwgU3Ry ZWFtcyBpbiBNaW5xDQoNCg0KDQpPbiBNb24sIE9jdCAyLCAyMDE3IGF0IDQ6MjcgQU0sIEx1YmFz aGV2LCBJZ29yIDxpbHViYXNoZUBha2FtYWkuY29tPG1haWx0bzppbHViYXNoZUBha2FtYWkuY29t Pj4gd3JvdGU6DQo+IE5pdDogQ2FuJ3QgeW91IHNlbmQgUkVTRVRfU1RSRUFNDQoNCkkgZG8gbm90 IHRoaW5rIHRoaXMgaXMgYW4gb3B0aW9uLCBzaW5jZSBSRVNFVF9TVFJFQU0gbWF5IHByZXZlbnQg ZGF0YSBidWZmZXJlZCBieSB0aGUgdHJhbnNwb3J0IGZyb20gYmVpbmcgZGVsaXZlcmVkIHRvIHRo ZSBhcHBsaWNhdGlvbi4NCg0KDQpUaG9zZSBhcmUgYWxzbyB0aGUgc2VtYW50aWNzIG9mIFNUUkVB TShvZmZzZXQ9MCwgRklOKS4NCg0KLUVrcg0KDQoNCg0KSSBhbSBsZXNzIGNvbmNlcm5lZCBhYm91 dCBob3cgbG9uZyBjb25uZWN0aW9uIHN0YXRlIGhhcyB0byBiZSBrZXB0IGFyb3VuZCAtLSBpbiBh IGNvb3BlcmF0aW5nIHBlZXIgc2l0dWF0aW9uLCB0aGlzIGlzIG9uZSBydHQsIHdoaWNoIGlzIHRo ZSBzYW1lIGFtb3VudCBvZiB0aW1lIHRoYXQgaXMgcmVxdWlyZWQgdG8gd2FpdCBmb3IgYW4gQUNL LiBBIG1hbGljaW91cyBwZWVyIGNvdWxkIHdpdGhob2xkIEFDS3MgZm9yIHBhY2tldHMgd2l0aCBT VFJFQU0rRklOLiBUaGUgYmlkaXJlY3Rpb25hbCBwcm90b2NvbCBpcyBtb3JlIGNoYXR0eSwgdGhv dWdoLg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IEVyaWMgUmVzY29y bGEgW2VrckBydGZtLmNvbTxtYWlsdG86ZWtyQHJ0Zm0uY29tPl0NClJlY2VpdmVkOiBTdW5kYXks IDAxIE9jdCAyMDE3LCA1OjI5UE0NClRvOiBNaWtlIEJpc2hvcCBbTWljaGFlbC5CaXNob3BAbWlj cm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbT5dDQpDQzogTWlr a2VsIEZhaG7DuGUgSsO4cmdlbnNlbiBbbWlra2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxm akBnbWFpbC5jb20+XTsgSUVURiBRVUlDIFdHIFtxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGll dGYub3JnPl0NClN1YmplY3Q6IFJlOiBSZXBvcnQgb24gVW5pZGlyZWN0aW9uYWwgU3RyZWFtcyBp biBNaW5xDQoNCg0KT24gU3VuLCBPY3QgMSwgMjAxNyBhdCAyOjE5IFBNLCBNaWtlIEJpc2hvcCA8 TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTxtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9z b2Z0LmNvbT4+IHdyb3RlOg0KSSB0aGluayB0aGUgZGlmZmVyZW5jZSBpcyBmb3IgdGhlIHNjZW5h cmlvIHdoZXJlIHlvdSBkb27igJl0IGV4cGVjdCBhIHBlZXIgdG8gcmVzcG9uZCAob3IgZG9u4oCZ dCBleHBlY3QgdGhlbSB0byByZXNwb25kIHN0cmVhbS1ieS1zdHJlYW0pLiAgV2l0aCAtMDUsIHRo ZSByZWNlaXZlciBzdGlsbCBuZWVkcyB0byBzZW5kIFNUUkVBTShvZmZzZXQ9MCxGSU4pIG9uIGVh Y2ggc3RyZWFtLg0KDQpOaXQ6IENhbid0IHlvdSBzZW5kIFJFU0VUX1NUUkVBTT8NCg0KDQogIFdp dGggZWl0aGVyIHVuaWRpcmVjdGlvbmFsIHByb3Bvc2FsLCB0aGlzIHBhdHRlcm4gaXMgYSBiaXQg Y2xlYW5lci4gIEluICM2NTYsIHRoZSBzZW5kZXIgY2FuIGVzc2VudGlhbGx5IHNheSwg4oCcRG9u 4oCZdCBib3RoZXLigJ0gYXQgdGhlIHRpbWUgb2Ygc3RyZWFtIGNyZWF0aW9uLiAgSW4gIzY0Mywg dGhlcmXigJlzIG5vIGNvcnJlc3BvbmRpbmcgY2hhbm5lbCB0byBjbG9zZS4NCg0KWWVzLCBJIGFn cmVlIHRoYXQgdGhpcyBpcyBjbGVhbmVyLiBOb3RlIHRoYXQgaW4gIzY0MyB5b3UgcHJlc3VtYWJs eSBuZWVkIHRvIGhhdmUgc29tZSB3YXkgb2Ygc2lnbmFsaW5nIHRoYXQgeW91IGRvbid0IHdhbnQg YSByZXR1cm4gY29ubmVjdGlvbi4uLi4NCg0KDQoNCkluIGFsbCBjYXNlcywgdGhlIG9ubHkgdGhp bmcgdGhhdCByZWFsbHkgbGltaXRzIHlvdSBpcyB0aGUgcGVlcuKAmXMgd2lsbGluZ25lc3MgdG8g aW5jcmVhc2UgeW91ciBNQVhfU1RSRUFNX0lELCBpdOKAmXMganVzdCBhIHF1ZXN0aW9uIG9mIGhv dyBjaGF0dHkgeW91IGhhdmUgdG8gYmUg4oCTIHdoaWNoIGNhbiBtYXR0ZXIgaWYgdGhlc2UgbWVz c2FnZXMgYXJlIGZhaXJseSBzbWFsbC4NCg0KQWdyZWVkLg0KDQotRWtyDQoNCg0KRnJvbTogUVVJ QyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYu b3JnPl0gT24gQmVoYWxmIE9mIEVyaWMgUmVzY29ybGENClNlbnQ6IFN1bmRheSwgT2N0b2JlciAx LCAyMDE3IDI6MDMgUE0NClRvOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBn bWFpbC5jb208bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT4+DQpDYzogSUVURiBRVUlDIFdHIDxx dWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBSZXBvcnQg b24gVW5pZGlyZWN0aW9uYWwgU3RyZWFtcyBpbiBNaW5xDQoNCkknbSBub3Qgc3VyZSBJIGhhdmUg YW55IHVzZWZ1bCBpbnNpZ2h0cyBvbiB0aGlzLCBhcyBteSBpbXBsZW1lbnRhdGlvbiBoYW5kbGVz IHRoZW0gbW9yZSBvciBsZXNzIHRoZSBzYW1lLiBDYW4geW91IGV4cGxhaW4gd2h5IHlvdSB0aGlu ayB0aGlzIHdvdWxkIGJlIGRpZmZlcmVudCB3aXRoIHVuaWRpcmVjdGlvbmFsIHZlcnN1cyBiaWRp cmVjdGlvbmFsPw0KDQotRWtyDQoNCg0KT24gU3VuLCBPY3QgMSwgMjAxNyBhdCAxOjM4IFBNLCBN aWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5jb208bWFpbHRvOm1pa2tl bGZqQGdtYWlsLmNvbT4+IHdyb3RlOg0KVGhhbmtzLA0KDQpJIG9ubHkgc2tpbW1lZCB0aGlzIHN1 cGVyZmFzdCwgYnV0IG9uZSB0aGUgb2JzZXJ2YXRpb25zIGFwcGVhciB0byBub3QgY292ZXIgb25l IG9mIG15IGtleSBwb2ludHM6DQoNCllvdSBjYW4gY3JlYXRlIGFuZCBjbG9zZSB1bmktc3RyZWFt cyBhdCBhdCB2ZXJ5IGhpZ2ggcmF0ZSBvZiBtYW55IHN0cmVhbXMgcGVyIHBhY2tldCwgd2l0aG91 dCB3YWl0aW5nIGZvciBwZWVyIHJlc3BvbnNlLCBhc3N1bWluZyB0aGUgQUNLIGZyYW1ld29yayBo YW5kbGVzIHJldHJhbnNtaXNzaW9uLiBBbnkgaW5zaWdodHMgb24gdGhpcz8NCg0KS2luZCBSZWdh cmRzLA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoNCk9uIDEgT2N0b2JlciAyMDE3IGF0 IDIyLjMyLjAyLCBFcmljIFJlc2NvcmxhIChla3JAcnRmbS5jb208bWFpbHRvOmVrckBydGZtLmNv bT4pIHdyb3RlOg0KSGkgZm9sa3MsDQoNCkFzIHByb21pc2VkIEkgc3BlbnQgYSBidW5jaCBvZiB0 aW1lIGhhY2tpbmcgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcw0KaW50byBNaW5xIGFuZCBJJ20gaGVy ZSB0byByZXBvcnQgYmFjayBbMF0uIFNwZWNpZmljYWxseSwgSQ0KaW1wbGVtZW50ZWQ6DQoNCiAg LSBQUiM2NDMgLS0gVW5pZGlyZWN0aW9uYWwgU3RyZWFtcw0KICAtIFBSIzcyMCAtLSBBZGQgYmlk aXJlY3Rpb25hbCBzdHJlYW1zIG9uIHRvcCBvZiB1bmlkaXJlY3Rpb25hbA0KICAtIEEgYmlkaXJl Y3Rpb25hbCBzdHJlYW0gQVBJIHRoYXQgbW9zdGx5IG1pbWljcyBNaW5xJ3Mgb3JpZ2luYWwgQVBJ DQogICAgZm9yIC0wNS4NCg0KVGhlIGZvbGxvd2luZyBpcyBraW5kIG9mIGEgd2FsbCBvZiB0ZXh0 LCBzbyB5b3UgY291bGQgYWxzbyBza2lwIHRoaXMNCmFuZCByZWZlciB0byBteSBzbGlkZXMgWzFd Lg0KDQoNCk1JTlEnUyAtMDUgQVJDSElURUNUVVJFDQpBUEkNCk1pbnEncyBtYXN0ZXIgb2JqZWN0 IGlzIHRoZSBDb25uZWN0aW9uLCB3aGljaCBoYXMgYSBsaXN0IG9mIFN0cmVhbXMNCmluZGV4ZWQg Ynkgc3RyZWFtIElELiBBcHBsaWNhdGlvbnMgcmVnaXN0ZXIgYSBoYW5kbGVyIHdpdGggdGhlDQpj b25uZWN0aW9uIHRvIGJlIG5vdGlmaWVkIG9mIG5ldyBldmVudHMuDQoNCiAgIHR5cGUgQ29ubmVj dGlvbkhhbmRsZXIgaW50ZXJmYWNlIHsNCiAgICAvLyBUaGUgY29ubmVjdGlvbiBoYXMgY2hhbmdl ZCBzdGF0ZSB0byBzdGF0ZSB8c3wNCiAgICBTdGF0ZUNoYW5nZWQocyBTdGF0ZSkNCg0KICAgIC8v IEEgbmV3IHN0cmVhbSBoYXMgYmVlbiBjcmVhdGVkIChieSByZWNlaXZpbmcgYSBmcmFtZQ0KICAg IC8vIGZyb20gdGhlIG90aGVyIHNpZGUuIHxzfCBjb250YWlucyB0aGUgc3RyZWFtLg0KICAgIE5l d1N0cmVhbShzICpTdHJlYW0pDQoNCiAgICAvLyBTdHJlYW0gfHN8IGlzIG5vdyByZWFkYWJsZS4N CiAgICBTdHJlYW1SZWFkYWJsZShzICpTdHJlYW0pDQogICB9DQoNClN0cmVhbXMgZ2V0IGNyZWF0 ZWQgaW4gdHdvIHdheXM6DQoNCi0gTG9jYWxseSB2aWEgQ29ubmVjdGlvbi5DcmVhdGVTdHJlYW0o KQ0KLSBSZW1vdGVseSwgaW4gd2hpY2ggY2FzZSB0aGUgYXBwbGljYXRpb24gaXMgbm90aWZpZWQg dmlhIGEgY2FsbGJhY2sgdG8NCiAgQ29ubmVjdGlvbkhhbmRsZXIuTmV3U3RyZWFtKCkuDQoNClN0 cmVhbXMgdGhlbXNlbHZlcyBoYXZlIHRoZSBBUElzIHlvdSB3b3VsZCBleHBlY3QsIG5hbWVseSwg UmVhZCgpLA0KV3JpdGUoKSwgQ2xvc2UoKSwgUmVzZXQoKSwgZXRjLiBZb3UgZ2V0IG5vdGlmaWVk IG9mIHN0cmVhbSByZWFkYWJpbGl0eQ0KYnkgYSBjYWxsYmFjayB0byBDb25uZWN0aW9uSGFuZGxl ci5TdHJlYW1SZWFkYWJsZSgpLCBhdCB3aGljaCBwb2ludA0KeW91IGNhbiBkbyBTdHJlYW0uUmVh ZCgpLiBBcyBleHBlY3RlZCwgU3RyZWFtLlJlYWQoKSByZXR1cm5zDQpXT1VMREJMT0NLIHdoZW4g bm8gZGF0YSBpYSBhdmFpbGFibGUNCg0KDQpJTlRFUk5BTFMNCkFzIG5vdGVkIGFib3ZlLCB3ZSBz dGFydCB3aXRoIHRoZSBDb25uZWN0aW9uIG9iamVjdCAob25seSByZWxldmFudCBmaWVsZHMNCnNo b3duKToNCg0KICAgdHlwZSBDb25uZWN0aW9uIHN0cnVjdCB7DQogICAgaGFuZGxlciAgICAgICAg ICBDb25uZWN0aW9uSGFuZGxlcg0KICAgIHN0cmVhbXMgICAgICAgICAgW10qU3RyZWFtDQogICAg bWF4U3RyZWFtICAgICAgICB1aW50MzINCm91dHB1dENsZWFyUSAgICAgW11mcmFtZSAvLyBGb3Ig c3RyZWFtIDANCm91dHB1dFByb3RlY3RlZFEgW11mcmFtZSAvLyBGb3Igc3RyZWFtID49IDANCiAg IH0NCg0KQXMgeW91IGNhbiBzZWUsIHN0cmVhbXMgYXJlIGluIGFuIGFycmF5IHNsaWNlLCBzbyB0 aGV5J3JlIGNvbnRpZ3VvdXNseQ0KaW5kZXhlZCBieSBzdHJlYW0gSUQuIFJpZ2h0IG5vdywgSSBo YXZlIG5vIHByb3Zpc2lvbiBmb3IgcmVjbGFpbWluZw0KdGhlIHVudXNlZCBib3R0b20gcGFydCBv ZiB0aGUgYXJyYXksIGJ1dCBpdCB3b3VsZCBiZSBzdHJhaWdodGZvcndhcmQNCnRvIGluZGV4IGJ5 IHxzdHJlYW1JZHwgLSB8bWluU3RyZWFtfCwgd2hpY2ggSSB0aGluayBpcyBjb25zaXN0ZW50IHdp dGgNCnRoZSBkZXNpZ24gaW1wbGllZCBieSB0aGUgcmVxdWlyZW1lbnQgdG8gY3JlYXRlIHN0cmVh bXMgaW4gc2VxdWVuY2UuDQoNCkJlY2F1c2UgU3RyZWFtcyBhcmUgYmlkaXJlY3Rpb25hbCwgZWFj aCBzdHJlYW0gYWN0dWFsbHkgY29uc2lzdHMgb2YgYQ0KcGFpciBvZiBoYWxmIHN0cmVhbXMuDQoN CiAgIHR5cGUgc3RyZWFtSGFsZiBzdHJ1Y3Qgew0KICAgIHMgICAgICAgICAgICAgKnN0cmVhbSAg ICAgICAgICAgLy8gcG9pbnRlciB0byBwYXJlbnQNCiAgICBsb2cgICAgICAgICAgIGxvZ2dpbmdG dW5jdGlvbg0KICAgIGRpciAgICAgICAgICAgZGlyZWN0aW9uICAgICAgICAgLy8gU2VuZGluZyBv ciByZWNlaXZpbmcNCiAgICBjbG9zZWQgICAgICAgIGJvb2wgICAgICAgICAgICAgIC8vIElzIHRo ZSBoYWxmLXN0cmVhbSBjbG9zZWQNCiAgICBvZmZzZXQgICAgICAgIHVpbnQ2NCAgICAgICAgICAg IC8vIFRoZQ0KICAgIGNodW5rcyAgICAgICAgW11zdHJlYW1DaHVuaw0KICAgIG1heFN0cmVhbURh dGEgdWludDY0DQogICB9DQoNCiAgIC8vIEludGVybmFsIG9iamVjdCB0byBhbGxvdyB1bml0IHRl c3RpbmcuDQogICB0eXBlIHN0cmVhbSBzdHJ1Y3Qgew0KICAgIGlkICAgICAgICAgdWludDMyDQog ICAgbG9nICAgICAgICBsb2dnaW5nRnVuY3Rpb24NCiAgICBzdGF0ZSAgICAgIHN0cmVhbVN0YXRl DQogICAgc2VuZCwgcmVjdiAqc3RyZWFtSGFsZg0KICBibG9ja2VkICAgIGJvb2wgLy8gSGF2ZSB3 ZSByZXR1cm5lZCBibG9ja2VkDQogICB9DQoNCiAgIC8vIFB1YmxpYyBBUEkgb2JqZWN0LCB3aGlj aCBuZWVkcyBhY2Nlc3MgdG8gdGhlIENvbm5lY3Rpb24NCiAgIHR5cGUgU3RyZWFtIHN0cnVjdCB7 DQogICAgYyAqQ29ubmVjdGlvbg0KICAgIHN0cmVhbQ0KICAgfQ0KDQpPdXRnb2luZyBkYXRhIGlz IGVucXVldWVkIGludG8gfHN0cmVhbS5jaHVua3N8LCBhbmQgdGhlbiBwZXJpb2RpY2FsbHkNCnRo ZSBjb25uZWN0aW9uIHBvbGxzIHRoZSBzdHJlYW0gZm9yIGFsbCB0aGUgY2h1bmtzIHdoaWNoIGFy ZSBwZXJtaXR0ZWQNCmJ5IHN0cmVhbS1sZXZlbCBmbG93IGNvbnRyb2wgYW5kIGVucXVldWVzIHRo ZW0gaW50bw0KfENvbm5lY3Rpb24ub3V0cHV0Q2xlYXJRfCBvciB8Q29ubmVjdGlvbi5vdXRwdXRQ cm90ZWN0ZWRRfC4gQXQgdGhpcw0KcG9pbnQsIHRoZSBjb25uZWN0aW9uIG93bnMgdGhlIGRhdGEg YW5kIGlzIHJlc3BvbnNpYmxlIGZvcg0KdHJhbnNtaXR0aW5nIGl0LCBzdWJqZWN0IHRvIGNvbm5l Y3Rpb24tbGV2ZWwgZmxvdyBjb250cm9sLCBhbmQNCihwcmVzdW1hYmx5KSBjb25nZXN0aW9uIGNv bnRyb2wgb25jZSBJIGhhdmUgdGhhdCBpbXBsZW1lbnRlZCBbMl0uDQoNCkluY29taW5nIGRhdGEg Z2V0cyBxdWV1ZWQgKHNvcnRlZCkgaW50byB8c3RyZWFtLmNodW5rc3wgZm9yIGxhdGVyDQpyZWFz c2VtYmx5IGF0IHRoZSB0aW1lIHdoZW4gc29tZW9uZSBjYWxscyBzdHJlYW0ucmVhZCgpLiBJJ20g bm90IHN1cmUNCkkgbG92ZSB0aGlzLCBiZWNhdXNlIGl0IG1lYW5zIEkgZG9uJ3QgaGF2ZSBhIGdv b2QgdmlldyBvZiB0aGUgaW5jb21pbmcNCnF1ZXVlIHNpemUgKHdoaWNoIEknZCBuZWVkIHRvIGFj Y291bnQgZm9yIHNlcGFyYXRlbHkpLCBidXQgaXQgYWxsb3dlZA0KbWUgdG8gc2hhcmUgZGF0YSBz dHJ1Y3R1cmVzIGJldHdlZW4gaW5jb21pbmcgYW5kIG91dGdvaW5nLCB3aGljaA0Kc2VlbWVkIGtp bmQgb2YgbmF0dXJhbCB3aGVuIEkgZGlkIGl0ICh0aGlzIGFyY2hpdGVjdHVyZSBpcyByZXBsaWNh dGVkDQppbiB0aGUgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBkZXNpZ24sIGJ1dCBpdCdzIHByb2Jh Ymx5IGxlc3MgbmF0dXJhbA0KdGhlcmUpLg0KDQoNClVOSURJUkVDVElPTkFMIFNUUkVBTVMgQVJD SElURUNUVVJFDQpVTklESVJFQ1RJT05BTCBBUEkNCldpdGggdGhlIHVuaWRpcmVjdGlvbmFsIGJy YW5jaCwgTWlucSBvZmZlcnMgdHdvIEFQSXMuIFRoZSBmaXJzdCBpcyBhDQpzdHJhaWdodGZvcndh cmQgbWFwcGluZyBvZiBQUiM3MjAsIGluIHdoaWNoIHdlIGhhdmUgdHdvIG9iamVjdHM6DQoNCiAg U2VuZFN0cmVhbSAtLSB1c2VkIGZvciB3cml0aW5nDQogIFJlY3ZTdHJlYW0gLS0gdXNlZCBmb3Ig cmVhZGluZw0KDQpBcyBiZWZvcmUsIHdlIGhhdmUgYSBoYW5kbGVyIG9iamVjdCwgYnV0IGl0J3Mg ZGlyZWN0aW9uYWwgbm93Og0KDQogICB0eXBlIENvbm5lY3Rpb25IYW5kbGVyIGludGVyZmFjZSB7 DQogICAgLy8gVGhlIGNvbm5lY3Rpb24gaGFzIGNoYW5nZWQgc3RhdGUgdG8gc3RhdGUgfHN8DQog ICAgU3RhdGVDaGFuZ2VkKHMgU3RhdGUpDQoNCiAgICAvLyBBIG5ldyByZWNlaXZpbmcgc3RyZWFt IGhhcyBiZWVuIGNyZWF0ZWQgKGJ5IHJlY2VpdmluZyBhIGZyYW1lDQogICAgLy8gZnJvbSB0aGUg b3RoZXIgc2lkZS4gfHN8IGNvbnRhaW5zIHRoZSBzdHJlYW0uDQogICAgTmV3UmVjdlN0cmVhbShz ICpSZWN2U3RyZWFtKQ0KDQogICAgLy8gU3RyZWFtIHxzfCBpcyBub3cgcmVhZGFibGUuDQogICAg U3RyZWFtUmVhZGFibGUocyAqUmVjdlN0cmVhbSkNCiAgIH0NCg0KT2J2aW91c2x5IFNlbmRTdHJl YW1zIGFyZSBsb2NhbGx5IGNyZWF0ZWQgYW5kIFJlY3ZTdHJlYW1zIGFyZSByZW1vdGVseQ0KY3Jl YXRlZC4gU2VuZFN0cmVhbXMgY2FuIGJlIGNyZWF0ZWQgdXNpbmcNCkNvbm5lY3Rpb24uQ3JlYXRl U2VuZFN0cmVhbSgpIGFuZCB5b3UgbGVhcm4gYWJvdXQgcmVtb3RlbHkgY3JlYXRlZA0KUmVjdlN0 cmVhbXMgYnkgYSBjYWxsYmFjayB0byBDb25uZWN0aW9uSGFuZGxlci5OZXdSZWN2U3RyZWFtKCku DQpTZWNvbmQtY3JlYXRlZCBzdHJlYW1zIGNhbiBiZSBtYXJrZWQgYXMgInJlbGF0ZWQiIHRvIGEg c2luZ2xlDQpmaXJzdC1jcmVhdGVkIHN0cmVhbSwgdXNpbmcgQ29ubmVjdGlvbi5DcmVhdGVSZWxh dGVkU2VuZFN0cmVhbSgpIHdpdGgNCnRoZSBhcHByb3ByaWF0ZSBSZWN2U3RyZWFtIGFzIHRoZSBh cmd1bWVudCBbM10uIFN0cmVhbXMgaGF2ZSBhDQpSZWxhdGVkKCkgQVBJIHRvIHRlbGwgeW91IGlm IHRoZXkgYXJlIHJlbGF0ZWQgdG8gc29tZSBvdGhlciBzdHJlYW0uDQoNClRoZSB7U2VuZCxSZWN2 fVN0cmVhbSBBUElzIGFyZSBhYm91dCB3aGF0IHlvdSdkIGV4cGVjdC4gWW91IGNhbg0KV3JpdGUo KSBvbiBTZW5kU3RyZWFtIGFuZCBSZWFkKCkgb24gUmVjdlN0cmVhbSgpLiBSaWdodCBub3csIHlv dSBjYW4NCkNsb3NlKCkgYW5kIFJlc2V0KCkgU2VuZFN0cmVhbXMsIGJ1dCBub3QgZG8gYW55dGhp bmcgb24gUmVjdlN0cmVhbXMoKQ0Kb3IgdGhhbiBpZ25vcmUgdGhlbS4gRXZlbnR1YWxseSBJJ2xs IHByb2JhYmx5IG9mZmVyDQpSZWN2U3RyZWFtKCkuTXV0ZSgpIG9yIHNvbWV0aGluZyB0byBsZXQg eW91IHNlbmQgU1RPUF9TRU5ESU5HLg0KDQoNCkJJRElSRUNUSU9OQUwgQVBJDQpNaW5xIGFsc28g aW5jbHVkZXMgYSBiaWRpcmVjdGlvbmFsIEFQSSB0aGF0J3MgbGF5ZXJlZCBvbiB0b3Agb2YNCnVu aWRpcmVjdGlvbmFsIHN0cmVhbXMuIEkndmUgY3JlYXRlZCBhIENvbm5lY3Rpb24yIHN0cnVjdHVy ZSB0aGF0J3MNCmludGVuZGVkIGFzIGEgd3JhcHBlciBhcm91bmQgQ29ubmVjdGlvbiBbNF06DQoN CiAgIHR5cGUgQ29ubmVjdGlvbjIgc3RydWN0IHsNCiAgICBDb25uZWN0aW9uDQogICAgc2hpbSAg ICAqY29ubmVjdGlvbjJTaGltSGFuZGxlcg0KICAgIHN0cmVhbXMgW10qU3RyZWFtIC8vIE9kZCBm b3IgY2xpZW50IG9yaWdpbmF0ZWQsIGV2ZW4gZm9yIHNlcnZlci4NCiAgIH0NCg0KICAgdHlwZSBT dHJlYW0gc3RydWN0IHsNCiAgICBpZCAgIHVpbnQzMg0KICAgIHNlbmQgKlNlbmRTdHJlYW0NCiAg ICByZWN2ICpSZWN2U3RyZWFtDQogICB9DQoNCkJhc2ljYWxseSwgU3RyZWFtIGlzIGp1c3QgYSBw YWlyIG9mIFNlbmRTdHJlYW0gYW5kIFJlY3ZTdHJlYW0gYW5kDQpDb25uZWN0aW9uMiBkb2VzIHRo ZSBib29ra2VlcGluZyB0byBrZWVwIHRoZW0gY29ubmVjdGVkIChJIGV2ZW4gZG8gdGhlDQpvZGQv ZXZlbiBJRCB0aGluZyB0aGF0IFFVSUMtMDUgaGFzKS4gQ29ubmVjdGlvbjIgaGFzIHRoZSBzYW1l IGhhbmRsZXINCkFQSSBhcyBNaW5xIGZvciBRVUlDLTA1LCBhbmQgdGhlIHNoaW0gaXMgcmVzcG9u c2libGUgZm9yIHRyYW5zbGF0aW5nDQp1bmlkaXJlY3Rpb25hbCBldmVudHMgaW50byBiaWRpcmVj dGlvbmFsIGV2ZW50cy4NCg0KSW50ZXJuYWxseSwgd2hhdCdzIGdvaW5nIG9uIGhlcmUgaXMgdGhh dCB3aGVuIHlvdSBjYWxsIENyZWF0ZVN0cmVhbSgpDQpNaW5xIGNyZWF0ZXMgYSBTdHJlYW0gd2l0 aCBhIG5pbCBSZWN2U3RyZWFtLiBXaGVuIGEgbmV3IHJlbW90ZSBzdHJlYW0NCmlzIGRldGVjdGVk LCB3ZSBjaGVjayBSZWN2U3RyZWFtLlJlbGF0ZWQoKS4gSWYgdGhleSBhcmUgcmVsYXRlZCB0byBh bg0KZXhpc3RpbmcgU2VuZFN0cmVhbSB0aGVuIHdlIHdpbGwgaW4gdGhlIHJlbGV2YW50IHxTdHJl YW0uc2VuZHwgc2xvdC4NCk90aGVyd2lzZSwgd2UgY3JlYXRlIGEgbmV3IFNlbmRTdHJlYW0gdGhh dCdzIHJlbGF0ZWQgdG8gdGhlIGluY29taW5nDQpzdHJlYW0gYW5kIG5vdGlmeSB0aGUgYXBwbGlj YXRpb24gb2YgdGhlIGNyZWF0aW9uIG9mIHRoZSBuZXcNCmJpZGlyZWN0aW9uYWwgc3RyZWFtLg0K DQpOb3RlIHRoYXQgdGhpcyBhbGwgd29ya3MgZmluZSBpZiBvbmUgc2lkZSBkb2VzIHRoZSB1bmRp cmVjdGlvbmFsIEFQSQ0KYW5kIG9uZSBkb2VzIHRoZSBiaWRpcmVjdGlvbmFsIEFQSS4gTXkgdGVz dCBwcm9ncmFtcyBhY3R1YWxseSBleGVyY2lzZQ0KdGhpcy4gT2YgY291cnNlLCB0aGVyZSdzIGFu IGFzc3VtcHRpb24gdGhhdCB0aGUgcGVlciBjb25mb3JtcyB0byBhIDE6MQ0KbWFwcGluZy4gSWYg d2UgZGVmaW5lIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMsIHdlJ2xsIG5lZWQgc29tZSBwcm90b2Nv bA0KbWVjaGFuaXNtIHRvIGtub3cgaWYgdGhlIG90aGVyIHNpZGUgaXMgZXhlcmNpc2luZyB0aGlz IGxldmVsIG9mDQppbmNyZWFzZWQgZmxleGliaWxpdHkgb3Igbm90LiBJIGNhbiBpbWFnaW5lIGEg bnVtYmVyIG9mIG9wdGlvbnMgaGVyZQ0KKGUuZy4sIEFMUE4pLiAgV2UgY291bGQgYWxzbyBmb3Ji aWQgMTpOIG1hcHBpbmdzIGJ1dCBJIHRoaW5rIHRoYXQNCndvdWxkIGJlIGEgbWlzdGFrZSBhcyBp dCdzIGEgY29vbCBmZWF0dXJlL2JlbmVmaXQgb2YgZG9pbmcNCnVuaWRpcmVjdGlvbmFsLg0KDQpU aGUgZW50aXJlIGJpZGlyZWN0aW9uYWwgd3JhcHBlciBzaGltIGlzIDwgMTUwIGxpbmVzIG9mIEdv IGNvZGUuDQooaHR0cHM6Ly9naXRodWIuY29tL2Vrci9taW5xL2Jsb2IvdW5pZGlyZWN0aW9uYWxf c3RyZWFtcy9iaWRpLmdvPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29r LmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJG dXJsJTNGdSUzRGh0dHBzLTNBX19uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29t Xy0zRnVybC0zRGh0dHBzLTI1M0EtMjUyRi0yNTJGZ2l0aHViLmNvbS0yNTJGZWtyLTI1MkZtaW5x LTI1MkZibG9iLTI1MkZ1bmlkaXJlY3Rpb25hbC01RnN0cmVhbXMtMjUyRmJpZGkuZ28tMjZkYXRh LTNEMDItMjU3QzAxLTI1N0NtaWNoYWVsLmJpc2hvcC0yNTQwbWljcm9zb2Z0LmNvbS0yNTdDMTRm MDc5ODdkYTBkNGFmYjhlNzUwOGQ1MDkwZmY2ZjYtMjU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3 Y2QwMTFkYjQ3LTI1N0MxLTI1N0MwLTI1N0M2MzY0MjQ4ODY1NDY0ODE3MTAtMjZzZGF0YS0zRHdw czlBV0syZmFhODNOOVItMjUyQkRIb3ZpZy0yNTJCd2Y2ODRQUy0yNTJCNVF3NURnellINUktMjUz RC0yNnJlc2VydmVkLTNEMCUyNmQlM0REd01GYVElMjZjJTNEOTZaYlpaY2FNRjR3MEY0anBONkxa ZyUyNnIlM0REam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJTI2bSUz RDBDajA0RWpzajJaMDhMSVphUVZnOEpkSkxiZnEtd2U4OUMxQ0I5Q2s1VUklMjZzJTNEN08zdjVK aFRRWmRSdjVBTkVjNWhXVUVybmF0ZWk0Nnotck1Kc0piNHdSbyUyNmUlM0QmZGF0YT0wMiU3QzAx JTdDTWljaGFlbC5CaXNob3AlNDBtaWNyb3NvZnQuY29tJTdDZTdkODYzNjYxM2YxNDUwMTA0Y2Qw OGQ1MDlhNTQwY2ElN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM2NDI1NTI3NzIzMjcwMzczJnNkYXRhPWFoOVhpYTZmdzJvTThpeW9kdkpVdUx0aXFHeUQzdzFu ZjAlMkZiYVhDOGFKRSUzRCZyZXNlcnZlZD0wPikuDQpDb252ZXJ0aW5nIG15IHRlc3QgYXBwbGlj YXRpb24gdG8gdGhpcyBBUEkgd2FzIGEgbWF0dGVyIG9mIGp1c3QNCmNoYW5naW5nIGNsYXNzIG5h bWVzLCBlLmcuLCBzL0Nvbm5lY3Rpb25iL0Nvbm5lY3Rpb24yLy4NCg0KSW4gbXkgaW1wbGVtZW50 YXRpb24sIEkgYXNzdW1lIHRoYXQgYXQgdGhlIHRpbWUgTWlucSBoZWFycyBhYm91dCBhDQpzdHJl YW0sIHlvdSBrbm93IGlmIGl0cyByZWxhdGVkIHRvIGEgZ2l2ZW4gZXhpc3Rpbmcgc3RyZWFtLiAg VGhhdCB3YXkNCnlvdSBjYW4gaW1tZWRpYXRlbHkgZWl0aGVyIGFzc29jaWF0ZSBpdCB3aXRoIHRo YXQgc3RyZWFtIG9yIG1ha2UgYSBuZXcNCmxvY2FsIHN0cmVhbS4gSW4gbXkgaW1wbGVtZW50YXRp b24sIEkgYWx3YXlzIHNlbmQgUmVsYXRlZCBTdHJlYW0gSWQNCmFuZCBhc3N1bWUgdGhhdCB5b3Ug bmV2ZXIgZ2V0IGFuICJ1bnJlbGF0ZWQiIHN0cmVhbSBmcmFtZSBiZWZvcmUgYQ0KInJlbGF0ZWQi IG9uZS4gVGhlIHNwZWMgZG9lc24ndCByZWFsbHkgcmVxdWlyZSB0aGF0IHJpZ2h0IG5vdywgYW5k DQpvZmZsaW5lIE1UIHN1Z2dlc3RlZCBqdXN0IHNlbmRpbmcgcmVsYXRlZCB3aXRoIG9mZnNldD0w IGJ1dCBJIHRoaW5rDQp0aGF0J3MgYSBtaXN0YWtlLCBiZWNhdXNlIGl0IG1lYW5zIHRoYXQgeW91 IG5lZWQgdG8gaG9sZCBzdHJlYW0gZnJhbWVzDQppbiBzb21lIHByb3Zpc2lvbmFsICJ1bmRldGVy bWluZWQiIHN0YXRlIHVudGlsIHlvdSBnZXQgdGhhdCBmcmFtZS4gSQ0Kd291bGQgc3VnZ2VzdCBp bnN0ZWFkIHRoYXQgd2UgcmVxdWlyZSB0aGF0IHlvdSBpbmNsdWRlIHRoZSBmaWVsZCB1bnRpbA0K b25lIG9mIHRoZSBmcmFtZXMgaXMgQUNLZWQuDQoNCg0KSU5URVJOQUxTDQpTZW5kaW5nIGFuZCBy ZWNlaXZpbmcgc3RyZWFtcyBzdGlsbCBzaGFyZSBhIGxvdCBvZiBjb21tb24gY29tcG9uZW50czoN Cg0KICAgIHR5cGUgYmFzZVN0cmVhbSBzdHJ1Y3Qgew0KICAgIHN0YXRlICAgICAgICAgc3RyZWFt U3RhdGUNCiAgICBpZCAgICAgICAgICAgIHVpbnQzMg0KICAgIGxvZyAgICAgICAgICAgbG9nZ2lu Z0Z1bmN0aW9uDQogICAgb2Zmc2V0ICAgICAgICB1aW50NjQNCiAgICBjaHVua3MgICAgICAgIFtd c3RyZWFtQ2h1bmsNCiAgICBtYXhTdHJlYW1EYXRhIHVpbnQ2NA0KICAgIGlzUmVsYXRlZCAgICAg Ym9vbA0KICAgIHJlbGF0ZWQgICAgICAgdWludDMyDQogICAgfQ0KDQogICAgdHlwZSBzZW5kU3Ry ZWFtIHN0cnVjdCB7DQogICAgYmFzZVN0cmVhbQ0KICAgIGJsb2NrZWQgYm9vbA0KICAgIH0NCg0K ICAgIHR5cGUgcmVjdlN0cmVhbSBzdHJ1Y3Qgew0KICAgIGJhc2VTdHJlYW0NCiAgICB9DQoNCk1v c3Qgb2YgdGhpcyBpcyB0aGUgc2FtZSBhcyB3aXRoIGJpZGlyZWN0aW9uYWwgc3RyZWFtcy4gIEFz IGFib3ZlLA0KaXQncyBwcm9iYWJseSBwb3NzaWJsZSB0byBtYWtlIHRoZW0gbW9yZSBhc3ltbWV0 cmljYWwuDQoNClRoZSBjb25uZWN0aW9uIG1haW50YWlucyBzZXBhcmF0ZSBsaXN0cyBvZiBzZW5k aW5nIGFuZCByZWNlaXZpbmcNCnN0cmVhbXMgYW5kIGl0J3Mgc3RyYWlnaHRmb3J3YXJkIHRvIGNy ZWF0ZSBhbmQgYWNjZXNzIHRoZW0gd2l0aG91dA0Kd29ycnlpbmcgYWJvdXQgdGhlIG9kZC9ldmVu IHN0dWZmLg0KDQoNCkNPTVBBUklTT04NCkF0IHRoZSBlbmQgb2YgdGhlIGRheSwgSSB0aGluayB0 aGlzIHNob3dzIHRoYXQgdGhlc2UgZGVzaWducyBhcmVuJ3QNCnJlYWxseSB0aGF0IGRpc3NzaW1p bGFyLiBJIHdhcyBhYmxlIHRvIGNvbnZlcnQgTWlucSB0byB1bmlkaXJlY3Rpb25hbA0Kc3RyZWFt cyBpbiBhYm91dCAxNiB0b3RhbCBob3VycyBvZiB3b3JrIChiYXNpY2FsbHkgYSBsb25nIHBsYW5l IGZsaWdodA0KcGx1cyB0aGUgbmV4dCBtb3JuaW5nKS4gV2hpbGUgSSBoYWQgdG8gbWFrZSBhIGJ1 bmNoIG9mIGNoYW5nZXMgdG8gdGhlDQppbnRlcm5hbCBzdHJ1Y3R1cmVzLCBiYXNpY2FsbHkgbm9u ZSBvZiB0aGVtIG1vZGlmaWVkIGFueXRoaW5nIHRyaWNreSwNCmFuZCBpbiBwYXJ0aWN1bGFyIHRo ZSBmbG93IGNvbnRyb2wgbWVjaGFuaWNzIGFuZCB0aGUgbGlrZSBhcmUNCmJhc2ljYWxseSB1bmNo YW5nZWQsIGV4Y2VwdCBmb3IgYSBidW5jaCBvZiBtZWNoYW5pY2FsLXR5cGUNCnRyYW5zZm9ybWF0 aW9ucyBsaWtlIHJlZmVycmluZyB0byB8c2VuZFN0cmVhbS5jaHVua3N8IGluc3RlYWQgb2YNCnxz dHJlYW0uc2VuZC5jaHVua3N8LiBUaGUgb25seSByZWFsbHkgbmV3IHByb3RvY29sIG1hY2hpbmVy eSBpcyB0aGUNCm5ldyBmcmFtZSBmb3JtYXQgZm9yIHJlbGF0ZWQgc3RyZWFtcy4NCg0KVGhlcmUg YXJlIGEgZmV3IHByb3MvY29ucyB0aGF0IGFyZSB3b3J0aCBub3RpbmcgYWJvdXQgdGhlc2UgZGVz aWducy4NCg0KLSBXaXRob3V0IGEgYmlkaXJlY3Rpb25hbCBBUEksIGhhdmluZyB1bmlkaXJlY3Rp b25hbCBzdHJlYW1zIGlzIG1vcmUNCiAgd29yayBmb3IgdGhlIHByb2dyYW1tZXIuIEhvd2V2ZXIs IHdpdGggYW4gQVBJIHNoaW0sIHRoZSBkaWZmZXJlbmNlDQogIGlzIHRyaXZpYWwuDQoNCi0gQmVj YXVzZSB1bmRpcmVjdGlvbmFsIHN0cmVhbXMgYXJlIGluaGVyZW50bHkgbW9yZSBmbGV4aWJsZSwg aXQncw0KICBwb3NzaWJsZSBmb3IgdGhlIHNpZGVzIHRvIHRyeSB0byB1c2UgZGlmZmVyZW50IG1h cHBpbmdzLCBlLmcuLCBvbmUNCiAgc2lkZSBleHBlY3RzIHBhaXJlZCBhbmQgdGhlIG90aGVyIGV4 cGVjdHMgMTpOLiBXZSdsbCBuZWVkIHNvbWUgd2F5DQogIG9mIG1ha2luZyBzdXJlIHRoYXQgZG9l c24ndCBoYXBwZW4sIG1heWJlIEFMUE4/DQoNCi0gVGhlICJSZWxhdGVkIFN0cmVhbSBJRCIgZnJh bWUgaW5kaWNhdG9yIG5lZWRzIGZsZXNoaW5nIG91dCBhIGJpdC4NCiAgRnJvbSB0aGUgYXBwbGlj YXRpb24ncyBwZXJzcGVjdGl2ZSwgaXQgc2hvdWxkIG5ldmVyIGhlYXIgYWJvdXQgYQ0KICBzdHJl YW0gd2l0aG91dCBrbm93aW5nIGl0cyByZWxhdGVkIHN0YXR1cy4gQW5kIGFzIG5vdGVkIGFib3Zl LCBJDQogIHRoaW5rIGl0IHdvdWxkIGJlIGJlc3QgaWYgd2UgcmVxdWlyZWQgdGhhdCBhbGwgImZp cnN0IGZsaWdodCIgc3RyZWFtDQogIGZyYW1lcyB0aGF0IGFyZSByZWxhdGVkIGluY2x1ZGUgdGhl IGZpZWQNCg0KLSBVbmRpcmVjdGlvbmFsIHN0cmVhbXMga2luZCBvZiBzaGFycGVuIHRoZSBjb25m dXNpb24gYWJvdXQgZXhhY3RseQ0KICB3aGF0IGtpbmRzIG9mICJjbG9zdXJlIiB3ZSB3YW50IHRv IGFsbG93LiBTcGVjaWZpY2FsbHksIHdoYXQgc2hvdWxkDQogIGltcGxlbWVudGF0aW9ucyBiZSBh YmxlIHRvIHNheSBhYm91dCB0aGVpciB3aWxsaW5nbmVzcyB0byByZWNlaXZlPw0KICBSaWdodCBu b3cgd2UgaGF2ZSBTVE9QX1NFTkRJTkcsIGJ1dCB0aGF0IGRvZXNuJ3QgaW5mbHVlbmNlIHRoZQ0K ICBzZW5kZXIncyBzdGF0ZS4gSSBkb24ndCB0aGluayB1bmRpcmVjdGlvbmFsIHN0cmVhbXMgbWFr ZSB0aGlzIHdvcnNlLA0KICB0aGV5IGp1c3QgcmVxdWlyZSB1cyB0byB0aGluayBpdCB0aHJvdWdo IHNvbWUgbW9yZS4gVGhleSBkbyBzaW1wbGlmeQ0KICB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhl IGNsb3N1cmUgc3RhdGUgbWFjaGluZTogaW4gbXkgUVVJQy0wNSBjb2RlLA0KICB3aGVuZXZlciBv bmUgc2lkZSBjbG9zZXMgSSBoYXZlIHRvIGhhdmUgY2hlY2tzIHRvIHNlZSBpZiBJIHNob3VsZCBi ZQ0KICB0cmFuc2l0aW9uaW5nIHRvIENMT1NFRCBvciBIQUxGLUNMT1NFRCwgZXRjLCB3aGljaCBp cyBvZGQgYmVjYXVzZQ0KICB0aGUgZGlyZWN0aW9ucyBhcmUgYmFzaWNhbGx5IGluZGVwZW5kZW50 LiAgSXQgd291bGQgcHJvYmFibHkgYmUNCiAgZWFzaWVyIGV2ZW4gaW4gUVVJQy0wNSBub3QgdG8g cmVpZnkgdGhlc2Ugc3RhdGVzIGJ1dCBqdXN0IHRvDQogIGRldGVybWluZSB0aGUgc3RhdGUgZnJv bSB0aGUgY29tcG9zaXRpb24gb2YgdGhlIGluZGl2aWR1YWwNCiAgc3ViLXN0YXRlcw0KDQotIFVu aWRpcmVjdGlvbmFsIHN0cmVhbXMgZG9uJ3QgbmVlZCB0aGUga2luZCBvZiBhbm5veWluZyBvZGQt ZXZlbg0KICBtZWNoYW5pY3MsIHdoaWNoIHdhcyBlYXNpZXIgdG8gY29kZSB1cCAoanVzdCBoYXZp bmcgdG8gY3JlYXRlIGFsbA0KICB0aGUgbG93ZXItbnVtYmVyZWQgc3RyZWFtcyBvZiB0aGUgc2Ft ZSBwYXJpdHkgaXMga2luZCBvZiBhIHBhaW4pLg0KICBPbmUgYWRkaXRpb25hbCBiZW5lZml0IGhl cmUgaXMgdGhhdCB3aXRoIFFVSUMtMDUgdGhlcmUgYXJlIHNldmVyYWwNCiAgbWVzc2FnZXMgd2hp Y2ggaW52b2x2ZSBpbXBsaWNpdCBzdHJlYW0gY3JlYXRpb24gKGUuZy4sDQogIFNUUkVBTV9NQVhf REFUQSwgYW5kIFJTVF9TVFJFQU0pIGFuZCBzbyB5b3UgbmVlZCB0byBjaGVjayB3aGV0aGVyDQog IHRoZSBzdHJlYW0gaXMgb25lIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiBjcmVhdGVkIGxvY2FsbHkg b3INCiAgcmVtb3RlbHkuIFRoaXMganVzdCBkb2Vzbid0IGhhcHBlbiB3aXRoIGJpZGlyZWN0aW9u YWwgc3RyZWFtczsgSSBkbw0KICBpbXBsZW1lbnQgb2RkL2V2ZW4gbWVjaGFuaWNzIGJ1dCBiZWNh dXNlIHRoZSBvdGhlciBzaWRlIGhhcyB0byBoYXZlDQogIGl0cyBzdHJlYW0gaWRzIGluY3JlbWVu dCBieSBvbmUsIEkgY2FuIG1ha2Ugc3VyZSB0aGF0IHRoZXkgaGF2ZSB0aGUNCiAgcmlnaHQgSURz IGJ5IGNvbnN0cnVjdGlvbiBhbmQganVzdCBjaGVjayB0byBzZWUgaWYgdGhlIHN0cmVhbSBleGlz dHMNCiAgaW4gdGhlc2UgY2FzZXMuICBJJ2QgbGlrZSB0byBzZWUgdXMgZ2V0IHJpZCBvZiBvZGQv ZXZlbiBubyBtYXR0ZXINCiAgd2hhdC4NCg0KLSBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFsc28g aGVscHMgYXZvaWQgc29tZSBvZiB0aGUgY29ybmVyIGNhc2VzIGFyb3VuZA0KICBiaWRpcmVjdGlv bmFsIHN0cmVhbXMuIFNwZWNpZmljYWxseSwgc3VwcG9zZSBJIGFtIHRoZSBjbGllbnQgYW5kDQog IEkgZ2V0IE1BWF9TVFJFQU1fREFUQSBhcyB0aGUgZmlyc3QgZnJhbWUgb24gc3RyZWFtIDIuIEFt IEkgYWxsb3dlZA0KICB0byBqdXN0IHN0YXJ0IHNlbmRpbmcgb3Igbm90PyBZb3UgY2FuIHNvcnQg b2YgZ2V0IGludG8gdGhpcyBzaXR1YXRpb24NCiAgd2l0aCB1bmlkaXJlY3Rpb25hbCBzdHJlYW1z LCBidXQgYmVjYXVzZSBpdCdzIGV4cGxpY2l0LCBvbmUgbWlnaHQNCiAgaG9wZSB0aGF0IHRoZSBh cHBsaWNhdGlvbiBzZW1hbnRpY3Mgd291bGQgcmVxdWlyZSBjbGVhciBzcGVjaWZpY2F0aW9uLg0K DQotIEFzIG5vdGVkIGFib3ZlLCBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXJlIG1vcmUgZmxleGli bGUgYmVjYXVzZSB0aGV5DQogIGxldCB5b3UgaGF2ZSBtYXBwaW5ncyB0aGF0IHlvdSBjYW4ndCBo YXZlIHdpdGggdW5pZGlyZWN0aW9uYWwNCiAgc3RyZWFtcyAodW5wYWlyZWQsIDE6TikuDQoNCg0K SGFwcHkgdG8gYW5zd2VyIG1vcmUgcXVlc3Rpb25zIGlmIHBlb3BsZSBoYXZlIHRoZW0uIE90aGVy d2lzZSB3ZSBjYW4NCnRhbGsgYWJvdXQgdGhpcyBpbiBTZWF0dGxlLg0KDQotRWtyDQoNCg0KWzBd IGh0dHBzOi8vZ2l0aHViLmNvbS9la3IvbWlucS90cmVlL3VuaWRpcmVjdGlvbmFsX3N0cmVhbXM8 aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMl M0ElMkYlMkZ1cmxkZWZlbnNlLnByb29mcG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMt M0FfX25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb21fLTNGdXJsLTNEaHR0cHMt MjUzQS0yNTJGLTI1MkZnaXRodWIuY29tLTI1MkZla3ItMjUyRm1pbnEtMjUyRnRyZWUtMjUyRnVu aWRpcmVjdGlvbmFsLTVGc3RyZWFtcy0yNmRhdGEtM0QwMi0yNTdDMDEtMjU3Q21pY2hhZWwuYmlz aG9wLTI1NDBtaWNyb3NvZnQuY29tLTI1N0MxNGYwNzk4N2RhMGQ0YWZiOGU3NTA4ZDUwOTBmZjZm Ni0yNTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDctMjU3QzEtMjU3QzAtMjU3QzYz NjQyNDg4NjU0NjQ4MTcxMC0yNnNkYXRhLTNEeFNlU1hZRzRPQzZpVFpoaWNWZ0g2cUpUTnJaRVFo YVVCYzBYUnN4aXlwQS0yNTNELTI2cmVzZXJ2ZWQtM0QwJTI2ZCUzRER3TUZhUSUyNmMlM0Q5Nlpi WlpjYU1GNHcwRjRqcE42TFpnJTI2ciUzRERqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVa ZG5fbTU1S1BtbG8lMjZtJTNEMENqMDRFanNqMlowOExJWmFRVmc4SmRKTGJmcS13ZTg5QzFDQjlD azVVSSUyNnMlM0RCUE12X3U2UG9BVXlOUVQ2cVJCbzkxc19Qa2hiYXBlM0piS2U2cWRTZ29VJTI2 ZSUzRCZkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NlN2Q4 NjM2NjEzZjE0NTAxMDRjZDA4ZDUwOWE1NDBjYSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2Qw MTFkYjQ3JTdDMSU3QzAlN0M2MzY0MjU1Mjc3MjMyNzAzNzMmc2RhdGE9T0NyYkt6OHRzaE1kVFEw YU1qYWZSUURIR0MyT2JrdEkydUltb2ZSWWQlMkJ3JTNEJnJlc2VydmVkPTA+DQpbMV0gaHR0cHM6 Ly9naXRodWIuY29tL2Vrci93Zy1tYXRlcmlhbHMvYmxvYi80MDQ4OThmYTJkMmYwYTlmOWJkMjQ0 ZDJjOTQ1ZTY2ZWE4ODUwMmEyL2ludGVyaW0tMTctMTAvVW5pZGlyZWN0aW9uYWwlMjBTdHJlYW1z JTIwaW4lMjBNaW5xLnBkZjxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9v ay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UucHJvb2Zwb2ludC5jb20lMkZ2MiUy RnVybCUzRnUlM0RodHRwcy0zQV9fbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNv bV8tM0Z1cmwtM0RodHRwcy0yNTNBLTI1MkYtMjUyRmdpdGh1Yi5jb20tMjUyRmVrci0yNTJGd2ct MkRtYXRlcmlhbHMtMjUyRmJsb2ItMjUyRjQwNDg5OGZhMmQyZjBhOWY5YmQyNDRkMmM5NDVlNjZl YTg4NTAyYTItMjUyRmludGVyaW0tMkQxNy0yRDEwLTI1MkZVbmlkaXJlY3Rpb25hbC0yNTI1MjBT dHJlYW1zLTI1MjUyMGluLTI1MjUyME1pbnEucGRmLTI2ZGF0YS0zRDAyLTI1N0MwMS0yNTdDbWlj aGFlbC5iaXNob3AtMjU0MG1pY3Jvc29mdC5jb20tMjU3QzE0ZjA3OTg3ZGEwZDRhZmI4ZTc1MDhk NTA5MGZmNmY2LTI1N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0Ny0yNTdDMS0yNTdD MS0yNTdDNjM2NDI0ODg2NTQ2NDgxNzEwLTI2c2RhdGEtM0RaLTI1MkJJTk9rQUF2Ylh3WTdZdXdh UGowZjF5UlhZN1M3OUFrRC0yNTJGdkhHcHdMb1EtMjUzRC0yNnJlc2VydmVkLTNEMCUyNmQlM0RE d01GYVElMjZjJTNEOTZaYlpaY2FNRjR3MEY0anBONkxaZyUyNnIlM0REam4zYlE1dU5KRFBNXzJz a2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJTI2bSUzRDBDajA0RWpzajJaMDhMSVphUVZnOEpk SkxiZnEtd2U4OUMxQ0I5Q2s1VUklMjZzJTNEVUpVVTQxdUN3SDRKS1RkTnlaUy1XNjBqem43aHR1 bFh6RnVFV21vamh1SSUyNmUlM0QmZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5CaXNob3AlNDBtaWNy b3NvZnQuY29tJTdDZTdkODYzNjYxM2YxNDUwMTA0Y2QwOGQ1MDlhNTQwY2ElN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NDI1NTI3NzIzMjcwMzczJnNkYXRh PTV0QWZaWUo2dGlveGZTQ1k4eGRVb3htcmxOVjNWWkQ3M01tTiUyQkROeHlYdyUzRCZyZXNlcnZl ZD0wPg0KWzJdIFRoYW5rcyB0byBQYXRyaWNrIE1jTWFudXMgZm9yIHN1Z2dlc3RpbmcgdGhpcyBk ZXNpZ24uDQpbM10gSW4gQysrLCB5b3Ugd291bGQgaGF2ZSBhIHNpbmdsZSBmdW5jdGlvbiB3aXRo IGEgZGVmYXVsdCBhcmd1bWVudCBvZg0KICAgIHxudWxscHRyfCBidXQgR28gZG9lc24ndCBzdXBw b3J0IHRoYXQsIGhlbmNlIHR3byBkaWZmZXJlbnQgYXJndW1lbnRzLg0KWzRdIEZvciBpbXBsZW1l bnRhdGlvbiByZWFzb25zLCBpdCdzIGFjdHVhbGx5IHVzaW5nIENvbm5lY3Rpb24gYXMgYSBtaXhp biwNCiAgICB3aGljaCBtZWFucyBpdCdzIHNpbXVsdGFuZW91c2x5IHBvc3NpYmxlIHRvIHVzZSB0 aGUgdW5pZGlyZWN0aW9uYWwNCiAgICBhbmQgYmlkaXJlY3Rpb25hbCBBUElzLCBidXQgdGhhdCdz IGdvaW5nIHRvIGNhdXNlIGEgbG90IG9mIGNvbmZ1c2lvbi4NCiAgICBBIHJlYWwgaW1wbGVtZW50 YXRpb24gd291bGQgcHJvYmFibHkgaGF2ZSB0byBlaXRoZXIgY29tbWl0IHRvIG9uZQ0KICAgIG9y IHRoZSBvdGhlciBvciBkbyBhIHJlYWwgd3JhcHBlciwgc28geW91IGNvdWxkIG9ubHkgdXNlIG9u ZSBzZXQgb2YNCiAgICBBUElzLCBhdCB0aGUgY29zdCBvZiBoYXZpbmcgdG8gZG8gbW9yZSBmb3J3 YXJkZWQgbWV0aG9kcy4NCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0K --_000_MWHPR21MB01413BF390A41A30611441D3877D0MWHPR21MB0141namp_ 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 emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubTg5NTIx NDUzMjU4MjI1MTE2NjZtMzQ0ODU5ODY2MDM2ODE1MDI0OW0tNjQyMjcyODI2ODgwNDI0OTk1OWFp cm1haWxvbiwgbGkubTg5NTIxNDUzMjU4MjI1MTE2NjZtMzQ0ODU5ODY2MDM2ODE1MDI0OW0tNjQy MjcyODI2ODgwNDI0OTk1OWFpcm1haWxvbiwgZGl2Lm04OTUyMTQ1MzI1ODIyNTExNjY2bTM0NDg1 OTg2NjAzNjgxNTAyNDltLTY0MjI3MjgyNjg4MDQyNDk5NTlhaXJtYWlsb24NCgl7bXNvLXN0eWxl LW5hbWU6bV84OTUyMTQ1MzI1ODIyNTExNjY2bV8zNDQ4NTk4NjYwMzY4MTUwMjQ5bS02NDIyNzI4 MjY4ODA0MjQ5OTU5YWlybWFpbG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9 DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4 LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3Jk U2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgdGhpbmsgeW914oCZcmUgdGFsa2luZyBwYXN0 IGVhY2ggb3RoZXIuJm5ic3A7IElnb3IsIHRoZSBkcmFmdCBjdXJyZW50bHkgc2F5cyB0aGF0IFJT VF9TVFJFQU0gYXBwbGllcyB0byB0aGUgc2VuZGVy4oCZcyBkaXJlY3Rpb24gb25seSwgc28gc2Vu ZGluZyBhIFJTVF9TVFJFQU0gZG9lc27igJl0IGhlbHAgYW55dGhpbmcuJm5ic3A7IFRoZSBvdGhl ciBzaWRlIGNvdWxkIHJlYXNvbmFibHkgc2VuZCBSU1RfU1RSRUFNIG9yIHRoZSBTVFJFQU0tRklO LA0KIGFuZCB0aGV54oCZcmUgaWRlbnRpY2FsIGZvciBhbGwgcHJhY3RpY2FsIHB1cnBvc2VzLiZu YnNwOyBUaGUgcG9pbnQgaXMgdGhhdCBvbmUgc2lkZSBpcyBzZW5kaW5nIGFsbCB0aGUgZGF0YSwg YnV0IHRoZSBvdGhlciBzaWRlIHN0aWxsIGhhcyB0byBhY2sgb24gdGhlIHN0cmVhbSBmb3IgaXQg dG8gcmVhY2ggdGhlIGNsb3NlZCBzdGF0ZS4mbmJzcDsgVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBk b27igJl0IHJlcXVpcmUgYW55IHBlci1zdHJlYW0gYWN0aW9uIGJ5IHRoZSByZWNlaXZlcg0KIHRv IGNvbXBsZXRlIHRoZSBzdGF0ZSBtYWNoaW5lLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5G cm9tOjwvYj4gRXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0gPGJyPg0KPGI+U2Vu dDo8L2I+IE1vbmRheSwgT2N0b2JlciAyLCAyMDE3IDc6NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IEx1 YmFzaGV2LCBJZ29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4g TWlrZSBCaXNob3AgJmx0O01pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20mZ3Q7OyBxdWljQGll dGYub3JnOyBtaWtrZWxmakBnbWFpbC5jb208YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFJlcG9y dCBvbiBVbmlkaXJlY3Rpb25hbCBTdHJlYW1zIGluIE1pbnE8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IE1vbiwgT2N0IDIsIDIwMTcgYXQgNDoyNyBBTSwgTHViYXNoZXYsIElnb3IgJmx0OzxhIGhyZWY9 Im1haWx0bzppbHViYXNoZUBha2FtYWkuY29tIiB0YXJnZXQ9Il9ibGFuayI+aWx1YmFzaGVAYWth bWFpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4g MGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZndDsgTml0 OiBDYW4ndCB5b3Ugc2VuZCBSRVNFVF9TVFJFQU08YnI+DQo8YnI+DQpJIGRvIG5vdCB0aGluayB0 aGlzIGlzIGFuIG9wdGlvbiwgc2luY2UgUkVTRVRfU1RSRUFNIG1heSBwcmV2ZW50IGRhdGEgYnVm ZmVyZWQgYnkgdGhlIHRyYW5zcG9ydCBmcm9tIGJlaW5nIGRlbGl2ZXJlZCB0byB0aGUgYXBwbGlj YXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRob3NlIGFyZSBhbHNvIHRoZSBzZW1hbnRpY3Mg b2YgU1RSRUFNKG9mZnNldD0wLCBGSU4pLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0ND IDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2lu LXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj5JIGFtIGxlc3MgY29uY2VybmVkIGFib3V0IGhvdyBsb25nIGNvbm5lY3Rpb24g c3RhdGUgaGFzIHRvIGJlIGtlcHQgYXJvdW5kIC0tIGluIGEgY29vcGVyYXRpbmcgcGVlciBzaXR1 YXRpb24sIHRoaXMgaXMgb25lIHJ0dCwgd2hpY2ggaXMgdGhlIHNhbWUgYW1vdW50IG9mIHRpbWUg dGhhdCBpcyByZXF1aXJlZCB0byB3YWl0IGZvciBhbiBBQ0suIEEgbWFsaWNpb3VzIHBlZXINCiBj b3VsZCB3aXRoaG9sZCBBQ0tzIGZvciBwYWNrZXRzIHdpdGggU1RSRUFNJiM0MztGSU4uIFRoZSBi aWRpcmVjdGlvbmFsIHByb3RvY29sIGlzIG1vcmUgY2hhdHR5LCB0aG91Z2guPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PGJyPg0KPGJyPg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0gPGJyPg0KPGI+RnJvbTo8L2I+IEVyaWMgUmVzY29ybGEgWzxhIGhyZWY9 Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+XTxi cj4NCjxiPlJlY2VpdmVkOjwvYj4gU3VuZGF5LCAwMSBPY3QgMjAxNywgNToyOVBNPGJyPg0KPGI+ VG86PC9iPiBNaWtlIEJpc2hvcCBbPGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jv c29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5NaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9h Pl08YnI+DQo8Yj5DQzo8L2I+IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gWzxhIGhyZWY9Im1h aWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5taWtrZWxmakBnbWFpbC5j b208L2E+XTsgSUVURiBRVUlDIFdHIFs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIgdGFy Z2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+XTxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog UmVwb3J0IG9uIFVuaWRpcmVjdGlvbmFsIFN0cmVhbXMgaW4gTWlucTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+T24gU3VuLCBPY3QgMSwgMjAxNyBhdCAyOjE5IFBNLCBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJl Zj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5N aWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+ DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0ND QyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdp bi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgdGhp bmsgdGhlIGRpZmZlcmVuY2UgaXMgZm9yIHRoZSBzY2VuYXJpbyB3aGVyZSB5b3UgZG9u4oCZdCBl eHBlY3QgYSBwZWVyIHRvIHJlc3BvbmQgKG9yIGRvbuKAmXQgZXhwZWN0IHRoZW0gdG8gcmVzcG9u ZCBzdHJlYW0tYnktc3RyZWFtKS4mbmJzcDsgV2l0aCAtMDUsIHRoZSByZWNlaXZlciBzdGlsbCBu ZWVkcyB0byBzZW5kDQogU1RSRUFNKG9mZnNldD0wLEZJTikgb24gZWFjaCBzdHJlYW0uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Tml0OiBDYW4ndCB5b3Ugc2VuZCBSRVNFVF9TVFJFQU0/PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdp bi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyBXaXRoIGVpdGhlciB1bmlkaXJlY3Rpb25hbCBwcm9wb3NhbCwg dGhpcyBwYXR0ZXJuIGlzIGEgYml0IGNsZWFuZXIuJm5ic3A7IEluICM2NTYsIHRoZSBzZW5kZXIg Y2FuIGVzc2VudGlhbGx5IHNheSwg4oCcRG9u4oCZdCBib3RoZXLigJ0gYXQgdGhlIHRpbWUgb2Yg c3RyZWFtIGNyZWF0aW9uLiZuYnNwOyBJbiAjNjQzLCB0aGVyZeKAmXMNCiBubyBjb3JyZXNwb25k aW5nIGNoYW5uZWwgdG8gY2xvc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBJIGFncmVlIHRo YXQgdGhpcyBpcyBjbGVhbmVyLiBOb3RlIHRoYXQgaW4gIzY0MyB5b3UgcHJlc3VtYWJseSBuZWVk IHRvIGhhdmUgc29tZSB3YXkgb2Ygc2lnbmFsaW5nIHRoYXQgeW91IGRvbid0IHdhbnQgYSByZXR1 cm4gY29ubmVjdGlvbi4uLi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv dGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFk ZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGlu Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBhbGwgY2FzZXMsIHRo ZSBvbmx5IHRoaW5nIHRoYXQgcmVhbGx5IGxpbWl0cyB5b3UgaXMgdGhlIHBlZXLigJlzIHdpbGxp bmduZXNzIHRvIGluY3JlYXNlIHlvdXIgTUFYX1NUUkVBTV9JRCwgaXTigJlzIGp1c3QgYSBxdWVz dGlvbiBvZiBob3cgY2hhdHR5IHlvdSBoYXZlIHRvIGJlIOKAkyB3aGljaCBjYW4gbWF0dGVyDQog aWYgdGhlc2UgbWVzc2FnZXMgYXJlIGZhaXJseSBzbWFsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B Z3JlZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljLWJvdW5jZXNAaWV0 Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5FcmljIFJlc2NvcmxhPGJyPg0KPGI+U2Vu dDo8L2I+IFN1bmRheSwgT2N0b2JlciAxLCAyMDE3IDI6MDMgUE08YnI+DQo8Yj5Ubzo8L2I+IE1p a2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFp bC5jb20iIHRhcmdldD0iX2JsYW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxi PkNjOjwvYj4gSUVURiBRVUlDIFdHICZsdDs8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogUmVwb3J0IG9uIFVuaWRpcmVjdGlvbmFsIFN0cmVhbXMgaW4gTWlucTxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSdtIG5vdCBzdXJlIEkgaGF2 ZSBhbnkgdXNlZnVsIGluc2lnaHRzIG9uIHRoaXMsIGFzIG15IGltcGxlbWVudGF0aW9uIGhhbmRs ZXMgdGhlbSBtb3JlIG9yIGxlc3MgdGhlIHNhbWUuIENhbiB5b3UgZXhwbGFpbiB3aHkgeW91IHRo aW5rIHRoaXMgd291bGQgYmUgZGlmZmVyZW50IHdpdGggdW5pZGlyZWN0aW9uYWwNCiB2ZXJzdXMg YmlkaXJlY3Rpb25hbD88bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+T24gU3VuLCBPY3QgMSwgMjAxNyBhdCAxOjM4IFBNLCBNaWtrZWwg RmFobsO4ZSBKw7hyZ2Vuc2VuICZsdDs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29t IiB0YXJnZXQ9Il9ibGFuayI+bWlra2VsZmpAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQu OHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjUuMHB0 Ij4NCjxkaXY+DQo8ZGl2IGlkPSJtXzg5NTIxNDUzMjU4MjI1MTE2NjZtXzM0NDg1OTg2NjAzNjgx NTAyNDltXy02NDIyNzI4MjY4ODA0MjQ5OTU5Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2IGlkPSJtXzg5NTIxNDUzMjU4MjI1MTE2NjZtXzM0NDg1OTg2NjAz NjgxNTAyNDltXy02NDIyNzI4MjY4ODA0MjQ5OTU5Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fODk1MjE0NTMyNTgyMjUxMTY2Nm1fMzQ0ODU5ODY2 MDM2ODE1MDI0OW1fLTY0MjI3MjgyNjg4MDQyNDk5NTlibG9vcF9jdXN0b21mb250Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkkgb25seSBza2ltbWVkIHRoaXMg c3VwZXJmYXN0LCBidXQgb25lIHRoZSBvYnNlcnZhdGlvbnMgYXBwZWFyIHRvIG5vdCBjb3ZlciBv bmUgb2YgbXkga2V5IHBvaW50czo8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg aWQ9Im1fODk1MjE0NTMyNTgyMjUxMTY2Nm1fMzQ0ODU5ODY2MDM2ODE1MDI0OW1fLTY0MjI3Mjgy Njg4MDQyNDk5NTlibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp diBpZD0ibV84OTUyMTQ1MzI1ODIyNTExNjY2bV8zNDQ4NTk4NjYwMzY4MTUwMjQ5bV8tNjQyMjcy ODI2ODgwNDI0OTk1OWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+WW91IGNhbiBjcmVhdGUgYW5kIGNsb3NlIHVuaS1zdHJlYW1zIGF0 IGF0IHZlcnkgaGlnaCByYXRlIG9mIG1hbnkgc3RyZWFtcyBwZXIgcGFja2V0LCB3aXRob3V0IHdh aXRpbmcgZm9yIHBlZXINCiByZXNwb25zZSwgYXNzdW1pbmcgdGhlIEFDSyBmcmFtZXdvcmsgaGFu ZGxlcyByZXRyYW5zbWlzc2lvbi4gQW55IGluc2lnaHRzIG9uIHRoaXM/PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBpZD0ibV84OTUyMTQ1MzI1ODIyNTExNjY2bV8zNDQ4NTk4NjYwMzY4MTUwMjQ5 bV8tNjQyMjcyODI2ODgwNDI0OTk1OWJsb29wX3NpZ25fMTUwNjg5MDE4MzM1ODk2NTc2MCI+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+S2luZCBSZWdh cmRzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW48L3NwYW4+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Im04OTUyMTQ1MzI1ODIy NTExNjY2bTM0NDg1OTg2NjAzNjgxNTAyNDltLTY0MjI3MjgyNjg4MDQyNDk5NTlhaXJtYWlsb24i Pg0KT24gMSBPY3RvYmVyIDIwMTcgYXQgMjIuMzIuMDIsIEVyaWMgUmVzY29ybGEgKDxhIGhyZWY9 Im1haWx0bzpla3JAcnRmbS5jb20iIHRhcmdldD0iX2JsYW5rIj5la3JAcnRmbS5jb208L2E+KSB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0 O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SGkgZm9sa3MsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBwcm9taXNlZCBJIHNwZW50IGEgYnVuY2gg b2YgdGltZSBoYWNraW5nIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXM8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aW50byBNaW5xIGFuZCBJJ20gaGVy ZSB0byByZXBvcnQgYmFjayBbMF0uIFNwZWNpZmljYWxseSwgSTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pbXBsZW1lbnRlZDo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAt IFBSIzY0MyAtLSBVbmlkaXJlY3Rpb25hbCBTdHJlYW1zPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAtIFBSIzcyMCAtLSBBZGQgYmlk aXJlY3Rpb25hbCBzdHJlYW1zIG9uIHRvcCBvZiB1bmlkaXJlY3Rpb25hbDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgLSBBIGJpZGly ZWN0aW9uYWwgc3RyZWFtIEFQSSB0aGF0IG1vc3RseSBtaW1pY3MgTWlucSdzIG9yaWdpbmFsIEFQ STxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsgJm5ic3A7IGZvciAtMDUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGZvbGxvd2luZyBpcyBraW5k IG9mIGEgd2FsbCBvZiB0ZXh0LCBzbyB5b3UgY291bGQgYWxzbyBza2lwIHRoaXM8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YW5kIHJlZmVyIHRv IG15IHNsaWRlcyBbMV0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+TUlOUSdTIC0wNSBBUkNISVRFQ1RVUkU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QVBJPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1pbnEncyBtYXN0ZXIg b2JqZWN0IGlzIHRoZSBDb25uZWN0aW9uLCB3aGljaCBoYXMgYSBsaXN0IG9mIFN0cmVhbXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aW5kZXhl ZCBieSBzdHJlYW0gSUQuIEFwcGxpY2F0aW9ucyByZWdpc3RlciBhIGhhbmRsZXIgd2l0aCB0aGU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Y29u bmVjdGlvbiB0byBiZSBub3RpZmllZCBvZiBuZXcgZXZlbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3R5cGUg Q29ubmVjdGlvbkhhbmRsZXIgaW50ZXJmYWNlIHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAvLyBUaGUgY29ubmVjdGlv biBoYXMgY2hhbmdlZCBzdGF0ZSB0byBzdGF0ZSB8c3w8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBTdGF0ZUNoYW5nZWQo cyBTdGF0ZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IC8vIEEgbmV3IHN0cmVhbSBoYXMgYmVlbiBj cmVhdGVkIChieSByZWNlaXZpbmcgYSBmcmFtZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IC8vIGZyb20gdGhlIG90aGVy IHNpZGUuIHxzfCBjb250YWlucyB0aGUgc3RyZWFtLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IE5ld1N0cmVhbShzICpT dHJlYW0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOyAmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAvLyBTdHJlYW0gfHN8IGlzIG5vdyByZWFkYWJs ZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7ICZuYnNwOyBTdHJlYW1SZWFkYWJsZShzICpTdHJlYW0pPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt9PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5TdHJl YW1zIGdldCBjcmVhdGVkIGluIHR3byB3YXlzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBMb2NhbGx5IHZpYSBDb25uZWN0aW9uLkNy ZWF0ZVN0cmVhbSgpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPi0gUmVtb3RlbHksIGluIHdoaWNoIGNhc2UgdGhlIGFwcGxpY2F0aW9uIGlzIG5v dGlmaWVkIHZpYSBhIGNhbGxiYWNrIHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBDb25uZWN0aW9uSGFuZGxlci5OZXdTdHJlYW0o KS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlN0cmVhbXMgdGhlbXNlbHZlcyBoYXZlIHRoZSBBUElzIHlvdSB3b3VsZCBleHBlY3QsIG5h bWVseSwgUmVhZCgpLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5Xcml0ZSgpLCBDbG9zZSgpLCBSZXNldCgpLCBldGMuIFlvdSBnZXQgbm90aWZp ZWQgb2Ygc3RyZWFtIHJlYWRhYmlsaXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPmJ5IGEgY2FsbGJhY2sgdG8gQ29ubmVjdGlvbkhhbmRsZXIu U3RyZWFtUmVhZGFibGUoKSwgYXQgd2hpY2ggcG9pbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+eW91IGNhbiBkbyBTdHJlYW0uUmVhZCgpLiBB cyBleHBlY3RlZCwgU3RyZWFtLlJlYWQoKSByZXR1cm5zPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPldPVUxEQkxPQ0sgd2hlbiBubyBkYXRhIGlh IGF2YWlsYWJsZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPklOVEVSTkFMUzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBub3RlZCBhYm92ZSwgd2Ugc3RhcnQgd2l0aCB0aGUg Q29ubmVjdGlvbiBvYmplY3QgKG9ubHkgcmVsZXZhbnQgZmllbGRzPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnNob3duKTo8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJz cDt0eXBlIENvbm5lY3Rpb24gc3RydWN0IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBoYW5kbGVyJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBDb25uZWN0aW9uSGFuZGxlcjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IHN0cmVh bXMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtdKlN0cmVhbTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 IG1heFN0cmVhbSZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50MzI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+b3V0cHV0Q2xlYXJRJm5i c3A7ICZuYnNwOyAmbmJzcDtbXWZyYW1lIC8vIEZvciBzdHJlYW0gMDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vdXRwdXRQcm90ZWN0ZWRRIFtd ZnJhbWUgLy8gRm9yIHN0cmVhbSAmZ3Q7PSAwPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt9PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyB5b3UgY2FuIHNlZSwg c3RyZWFtcyBhcmUgaW4gYW4gYXJyYXkgc2xpY2UsIHNvIHRoZXkncmUgY29udGlndW91c2x5PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmluZGV4 ZWQgYnkgc3RyZWFtIElELiBSaWdodCBub3csIEkgaGF2ZSBubyBwcm92aXNpb24gZm9yIHJlY2xh aW1pbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+dGhlIHVudXNlZCBib3R0b20gcGFydCBvZiB0aGUgYXJyYXksIGJ1dCBpdCB3b3VsZCBiZSBz dHJhaWdodGZvcndhcmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+dG8gaW5kZXggYnkgfHN0cmVhbUlkfCAtIHxtaW5TdHJlYW18LCB3aGljaCBJ IHRoaW5rIGlzIGNvbnNpc3RlbnQgd2l0aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj50aGUgZGVzaWduIGltcGxpZWQgYnkgdGhlIHJlcXVpcmVt ZW50IHRvIGNyZWF0ZSBzdHJlYW1zIGluIHNlcXVlbmNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVjYXVzZSBTdHJlYW1zIGFyZSBi aWRpcmVjdGlvbmFsLCBlYWNoIHN0cmVhbSBhY3R1YWxseSBjb25zaXN0cyBvZiBhPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnBhaXIgb2YgaGFs ZiBzdHJlYW1zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3R5cGUgc3RyZWFtSGFsZiBzdHJ1Y3QgezxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7IHMmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsqc3Ry ZWFtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvLyBwb2ludGVyIHRv IHBhcmVudDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsgJm5ic3A7IGxvZyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7bG9nZ2luZ0Z1bmN0aW9uJm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IGRpciZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ZGlyZWN0aW9uJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOy8vIFNlbmRpbmcgb3IgcmVjZWl2aW5nPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgY2xv c2VkJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGJvb2wmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgLy8gSXMgdGhlIGhhbGYtc3RyZWFtIGNsb3NlZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7IG9mZnNldCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50NjQmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvLyBUaGU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBjaHVu a3MmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW11zdHJlYW1DaHVuazxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IG1h eFN0cmVhbURhdGEgdWludDY0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7Ly8gSW50ZXJuYWwg b2JqZWN0IHRvIGFsbG93IHVuaXQgdGVzdGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3R5cGUgc3RyZWFtIHN0cnVj dCB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyAmbmJzcDsgaWQmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7dWludDMy PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOyAmbmJzcDsgbG9nJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IGxvZ2dpbmdGdW5jdGlv bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsgJm5ic3A7IHN0YXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgc3RyZWFtU3RhdGU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZu YnNwOyBzZW5kLCByZWN2ICpzdHJlYW1IYWxmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBibG9ja2VkJm5ic3A7ICZuYnNwOyBib29s IC8vIEhhdmUgd2UgcmV0dXJuZWQgYmxvY2tlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOy8v IFB1YmxpYyBBUEkgb2JqZWN0LCB3aGljaCBuZWVkcyBhY2Nlc3MgdG8gdGhlIENvbm5lY3Rpb248 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7ICZuYnNwO3R5cGUgU3RyZWFtIHN0cnVjdCB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgYyAqQ29ubmVjdGlvbjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7IHN0cmVhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T3V0Z29pbmcgZGF0YSBpcyBlbnF1ZXVlZCBp bnRvIHxzdHJlYW0uY2h1bmtzfCwgYW5kIHRoZW4gcGVyaW9kaWNhbGx5PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRoZSBjb25uZWN0aW9uIHBv bGxzIHRoZSBzdHJlYW0gZm9yIGFsbCB0aGUgY2h1bmtzIHdoaWNoIGFyZSBwZXJtaXR0ZWQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Ynkgc3Ry ZWFtLWxldmVsIGZsb3cgY29udHJvbCBhbmQgZW5xdWV1ZXMgdGhlbSBpbnRvPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnxDb25uZWN0aW9uLm91 dHB1dENsZWFyUXwgb3IgfENvbm5lY3Rpb24ub3V0cHV0UHJvdGVjdGVkUXwuIEF0IHRoaXM8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cG9pbnQs IHRoZSBjb25uZWN0aW9uIG93bnMgdGhlIGRhdGEgYW5kIGlzIHJlc3BvbnNpYmxlIGZvcjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50cmFuc21p dHRpbmcgaXQsIHN1YmplY3QgdG8gY29ubmVjdGlvbi1sZXZlbCBmbG93IGNvbnRyb2wsIGFuZDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4ocHJl c3VtYWJseSkgY29uZ2VzdGlvbiBjb250cm9sIG9uY2UgSSBoYXZlIHRoYXQgaW1wbGVtZW50ZWQg WzJdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+SW5jb21pbmcgZGF0YSBnZXRzIHF1ZXVlZCAoc29ydGVkKSBpbnRvIHxzdHJlYW0uY2h1 bmtzfCBmb3IgbGF0ZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+cmVhc3NlbWJseSBhdCB0aGUgdGltZSB3aGVuIHNvbWVvbmUgY2FsbHMgc3Ry ZWFtLnJlYWQoKS4gSSdtIG5vdCBzdXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkkgbG92ZSB0aGlzLCBiZWNhdXNlIGl0IG1lYW5zIEkgZG9u J3QgaGF2ZSBhIGdvb2QgdmlldyBvZiB0aGUgaW5jb21pbmc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cXVldWUgc2l6ZSAod2hpY2ggSSdkIG5l ZWQgdG8gYWNjb3VudCBmb3Igc2VwYXJhdGVseSksIGJ1dCBpdCBhbGxvd2VkPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm1lIHRvIHNoYXJlIGRh dGEgc3RydWN0dXJlcyBiZXR3ZWVuIGluY29taW5nIGFuZCBvdXRnb2luZywgd2hpY2g8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+c2VlbWVkIGtp bmQgb2YgbmF0dXJhbCB3aGVuIEkgZGlkIGl0ICh0aGlzIGFyY2hpdGVjdHVyZSBpcyByZXBsaWNh dGVkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PmluIHRoZSB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGRlc2lnbiwgYnV0IGl0J3MgcHJvYmFibHkg bGVzcyBuYXR1cmFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPnRoZXJlKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5VTklESVJFQ1RJT05BTCBTVFJFQU1TIEFSQ0hJVEVDVFVS RTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5V TklESVJFQ1RJT05BTCBBUEk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+V2l0aCB0aGUgdW5pZGlyZWN0aW9uYWwgYnJhbmNoLCBNaW5xIG9mZmVy cyB0d28gQVBJcy4gVGhlIGZpcnN0IGlzIGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+c3RyYWlnaHRmb3J3YXJkIG1hcHBpbmcgb2YgUFIjNzIw LCBpbiB3aGljaCB3ZSBoYXZlIHR3byBvYmplY3RzOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IFNlbmRTdHJlYW0gLS0gdXNl ZCBmb3Igd3JpdGluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsgUmVjdlN0cmVhbSAtLSB1c2VkIGZvciByZWFkaW5nPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BcyBiZWZv cmUsIHdlIGhhdmUgYSBoYW5kbGVyIG9iamVjdCwgYnV0IGl0J3MgZGlyZWN0aW9uYWwgbm93Ojxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7ICZuYnNwO3R5cGUgQ29ubmVjdGlvbkhhbmRsZXIgaW50ZXJmYWNlIHs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNw OyAvLyBUaGUgY29ubmVjdGlvbiBoYXMgY2hhbmdlZCBzdGF0ZSB0byBzdGF0ZSB8c3w8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZu YnNwOyBTdGF0ZUNoYW5nZWQocyBTdGF0ZSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IC8vIEEgbmV3 IHJlY2VpdmluZyBzdHJlYW0gaGFzIGJlZW4gY3JlYXRlZCAoYnkgcmVjZWl2aW5nIGEgZnJhbWU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7ICZuYnNwOyAvLyBmcm9tIHRoZSBvdGhlciBzaWRlLiB8c3wgY29udGFpbnMgdGhlIHN0cmVh bS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7ICZuYnNwOyBOZXdSZWN2U3RyZWFtKHMgKlJlY3ZTdHJlYW0pPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwOyAvLyBTdHJlYW0gfHN8IGlzIG5vdyByZWFkYWJsZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBTdHJlYW1S ZWFkYWJsZShzICpSZWN2U3RyZWFtKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T2J2aW91c2x5IFNlbmRTdHJlYW1z IGFyZSBsb2NhbGx5IGNyZWF0ZWQgYW5kIFJlY3ZTdHJlYW1zIGFyZSByZW1vdGVseTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5jcmVhdGVkLiBT ZW5kU3RyZWFtcyBjYW4gYmUgY3JlYXRlZCB1c2luZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db25uZWN0aW9uLkNyZWF0ZVNlbmRTdHJlYW0o KSBhbmQgeW91IGxlYXJuIGFib3V0IHJlbW90ZWx5IGNyZWF0ZWQ8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+UmVjdlN0cmVhbXMgYnkgYSBjYWxs YmFjayB0byBDb25uZWN0aW9uSGFuZGxlci5OZXdSZWN2U3RyZWFtKCkuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNlY29uZC1jcmVhdGVkIHN0 cmVhbXMgY2FuIGJlIG1hcmtlZCBhcyAmcXVvdDtyZWxhdGVkJnF1b3Q7IHRvIGEgc2luZ2xlPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmZpcnN0 LWNyZWF0ZWQgc3RyZWFtLCB1c2luZyBDb25uZWN0aW9uLkNyZWF0ZVJlbGF0ZWRTZW5kU3RyZWFt KCkgd2l0aDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj50aGUgYXBwcm9wcmlhdGUgUmVjdlN0cmVhbSBhcyB0aGUgYXJndW1lbnQgWzNdLiBTdHJl YW1zIGhhdmUgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5SZWxhdGVkKCkgQVBJIHRvIHRlbGwgeW91IGlmIHRoZXkgYXJlIHJlbGF0ZWQgdG8g c29tZSBvdGhlciBzdHJlYW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5UaGUge1NlbmQsUmVjdn1TdHJlYW0gQVBJcyBhcmUgYWJvdXQg d2hhdCB5b3UnZCBleHBlY3QuIFlvdSBjYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V3JpdGUoKSBvbiBTZW5kU3RyZWFtIGFuZCBSZWFkKCkg b24gUmVjdlN0cmVhbSgpLiBSaWdodCBub3csIHlvdSBjYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q2xvc2UoKSBhbmQgUmVzZXQoKSBTZW5k U3RyZWFtcywgYnV0IG5vdCBkbyBhbnl0aGluZyBvbiBSZWN2U3RyZWFtcygpPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm9yIHRoYW4gaWdub3Jl IHRoZW0uIEV2ZW50dWFsbHkgSSdsbCBwcm9iYWJseSBvZmZlcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWN2U3RyZWFtKCkuTXV0ZSgpIG9y IHNvbWV0aGluZyB0byBsZXQgeW91IHNlbmQgU1RPUF9TRU5ESU5HLjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkJJRElSRUNUSU9O QUwgQVBJPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk1pbnEgYWxzbyBpbmNsdWRlcyBhIGJpZGlyZWN0aW9uYWwgQVBJIHRoYXQncyBsYXllcmVk IG9uIHRvcCBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj51bmlkaXJlY3Rpb25hbCBzdHJlYW1zLiBJJ3ZlIGNyZWF0ZWQgYSBDb25uZWN0aW9u MiBzdHJ1Y3R1cmUgdGhhdCdzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPmludGVuZGVkIGFzIGEgd3JhcHBlciBhcm91bmQgQ29ubmVjdGlvbiBb NF06PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsgJm5ic3A7dHlwZSBDb25uZWN0aW9uMiBzdHJ1Y3QgezxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IENv bm5lY3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7ICZuYnNwOyBzaGltJm5ic3A7ICZuYnNwOyAqY29ubmVjdGlvbjJTaGltSGFu ZGxlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgJm5ic3A7IHN0cmVhbXMgW10qU3RyZWFtIC8vIE9kZCBmb3IgY2xpZW50IG9yaWdp bmF0ZWQsIGV2ZW4gZm9yIHNlcnZlci48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyAmbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwO3R5cGUgU3RyZWFtIHN0cnVjdCB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgaWQmbmJzcDsgJm5ic3A7dWlu dDMyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyAmbmJzcDsgc2VuZCAqU2VuZFN0cmVhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IHJlY3YgKlJlY3ZTdHJl YW08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7ICZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkJhc2ljYWxseSwgU3RyZWFtIGlzIGp1c3QgYSBwYWlyIG9mIFNlbmRT dHJlYW0gYW5kIFJlY3ZTdHJlYW0gYW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbm5lY3Rpb24yIGRvZXMgdGhlIGJvb2trZWVwaW5nIHRv IGtlZXAgdGhlbSBjb25uZWN0ZWQgKEkgZXZlbiBkbyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+b2RkL2V2ZW4gSUQgdGhpbmcgdGhhdCBR VUlDLTA1IGhhcykuIENvbm5lY3Rpb24yIGhhcyB0aGUgc2FtZSBoYW5kbGVyPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFQSSBhcyBNaW5xIGZv ciBRVUlDLTA1LCBhbmQgdGhlIHNoaW0gaXMgcmVzcG9uc2libGUgZm9yIHRyYW5zbGF0aW5nPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnVuaWRp cmVjdGlvbmFsIGV2ZW50cyBpbnRvIGJpZGlyZWN0aW9uYWwgZXZlbnRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SW50ZXJuYWxseSwg d2hhdCdzIGdvaW5nIG9uIGhlcmUgaXMgdGhhdCB3aGVuIHlvdSBjYWxsIENyZWF0ZVN0cmVhbSgp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPk1p bnEgY3JlYXRlcyBhIFN0cmVhbSB3aXRoIGEgbmlsIFJlY3ZTdHJlYW0uIFdoZW4gYSBuZXcgcmVt b3RlIHN0cmVhbTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5pcyBkZXRlY3RlZCwgd2UgY2hlY2sgUmVjdlN0cmVhbS5SZWxhdGVkKCkuIElmIHRo ZXkgYXJlIHJlbGF0ZWQgdG8gYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+ZXhpc3RpbmcgU2VuZFN0cmVhbSB0aGVuIHdlIHdpbGwgaW4gdGhl IHJlbGV2YW50IHxTdHJlYW0uc2VuZHwgc2xvdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+T3RoZXJ3aXNlLCB3ZSBjcmVhdGUgYSBuZXcgU2Vu ZFN0cmVhbSB0aGF0J3MgcmVsYXRlZCB0byB0aGUgaW5jb21pbmc8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+c3RyZWFtIGFuZCBub3RpZnkgdGhl IGFwcGxpY2F0aW9uIG9mIHRoZSBjcmVhdGlvbiBvZiB0aGUgbmV3PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmJpZGlyZWN0aW9uYWwgc3RyZWFt LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Tm90ZSB0aGF0IHRoaXMgYWxsIHdvcmtzIGZpbmUgaWYgb25lIHNpZGUgZG9lcyB0aGUgdW5k aXJlY3Rpb25hbCBBUEk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+YW5kIG9uZSBkb2VzIHRoZSBiaWRpcmVjdGlvbmFsIEFQSS4gTXkgdGVzdCBw cm9ncmFtcyBhY3R1YWxseSBleGVyY2lzZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj50aGlzLiBPZiBjb3Vyc2UsIHRoZXJlJ3MgYW4gYXNzdW1w dGlvbiB0aGF0IHRoZSBwZWVyIGNvbmZvcm1zIHRvIGEgMToxPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm1hcHBpbmcuIElmIHdlIGRlZmluZSB1 bmlkaXJlY3Rpb25hbCBzdHJlYW1zLCB3ZSdsbCBuZWVkIHNvbWUgcHJvdG9jb2w8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+bWVjaGFuaXNtIHRv IGtub3cgaWYgdGhlIG90aGVyIHNpZGUgaXMgZXhlcmNpc2luZyB0aGlzIGxldmVsIG9mPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmluY3JlYXNl ZCBmbGV4aWJpbGl0eSBvciBub3QuIEkgY2FuIGltYWdpbmUgYSBudW1iZXIgb2Ygb3B0aW9ucyBo ZXJlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PihlLmcuLCBBTFBOKS4mbmJzcDsgV2UgY291bGQgYWxzbyBmb3JiaWQgMTpOIG1hcHBpbmdzIGJ1 dCBJIHRoaW5rIHRoYXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+d291bGQgYmUgYSBtaXN0YWtlIGFzIGl0J3MgYSBjb29sIGZlYXR1cmUvYmVu ZWZpdCBvZiBkb2luZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj51bmlkaXJlY3Rpb25hbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlRoZSBlbnRpcmUgYmlkaXJlY3Rpb25hbCB3cmFw cGVyIHNoaW0gaXMgJmx0OyAxNTAgbGluZXMgb2YgR28gY29kZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+KDxhIGhyZWY9Imh0dHBzOi8vbmEw MS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJs ZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX19uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tXy0zRnVybC0zRGh0dHBzLTI1M0EtMjUyRi0y NTJGZ2l0aHViLmNvbS0yNTJGZWtyLTI1MkZtaW5xLTI1MkZibG9iLTI1MkZ1bmlkaXJlY3Rpb25h bC01RnN0cmVhbXMtMjUyRmJpZGkuZ28tMjZkYXRhLTNEMDItMjU3QzAxLTI1N0NtaWNoYWVsLmJp c2hvcC0yNTQwbWljcm9zb2Z0LmNvbS0yNTdDMTRmMDc5ODdkYTBkNGFmYjhlNzUwOGQ1MDkwZmY2 ZjYtMjU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3LTI1N0MxLTI1N0MwLTI1N0M2 MzY0MjQ4ODY1NDY0ODE3MTAtMjZzZGF0YS0zRHdwczlBV0syZmFhODNOOVItMjUyQkRIb3ZpZy0y NTJCd2Y2ODRQUy0yNTJCNVF3NURnellINUktMjUzRC0yNnJlc2VydmVkLTNEMCUyNmQlM0REd01G YVElMjZjJTNEOTZaYlpaY2FNRjR3MEY0anBONkxaZyUyNnIlM0REam4zYlE1dU5KRFBNXzJza2ZM M3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJTI2bSUzRDBDajA0RWpzajJaMDhMSVphUVZnOEpkSkxi ZnEtd2U4OUMxQ0I5Q2s1VUklMjZzJTNEN08zdjVKaFRRWmRSdjVBTkVjNWhXVUVybmF0ZWk0Nnot ck1Kc0piNHdSbyUyNmUlM0QmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuQmlzaG9wJTQwbWlj cm9zb2Z0LmNvbSU3Q2U3ZDg2MzY2MTNmMTQ1MDEwNGNkMDhkNTA5YTU0MGNhJTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjQyNTUyNzcyMzI3MDM3MyZhbXA7 c2RhdGE9YWg5WGlhNmZ3Mm9NOGl5b2R2SlV1THRpcUd5RDN3MW5mMCUyRmJhWEM4YUpFJTNEJmFt cDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9naXRodWIuY29tL2Vrci9taW5x L2Jsb2IvdW5pZGlyZWN0aW9uYWxfc3RyZWFtcy9iaWRpLmdvPC9hPikuPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbnZlcnRpbmcgbXkgdGVz dCBhcHBsaWNhdGlvbiB0byB0aGlzIEFQSSB3YXMgYSBtYXR0ZXIgb2YganVzdDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5jaGFuZ2luZyBjbGFz cyBuYW1lcywgZS5nLiwgcy9Db25uZWN0aW9uYi9Db25uZWN0aW9uMi8uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbiBteSBpbXBsZW1l bnRhdGlvbiwgSSBhc3N1bWUgdGhhdCBhdCB0aGUgdGltZSBNaW5xIGhlYXJzIGFib3V0IGE8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+c3RyZWFt LCB5b3Uga25vdyBpZiBpdHMgcmVsYXRlZCB0byBhIGdpdmVuIGV4aXN0aW5nIHN0cmVhbS4mbmJz cDsgVGhhdCB3YXk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+eW91IGNhbiBpbW1lZGlhdGVseSBlaXRoZXIgYXNzb2NpYXRlIGl0IHdpdGggdGhh dCBzdHJlYW0gb3IgbWFrZSBhIG5ldzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5sb2NhbCBzdHJlYW0uIEluIG15IGltcGxlbWVudGF0aW9uLCBJ IGFsd2F5cyBzZW5kIFJlbGF0ZWQgU3RyZWFtIElkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmFuZCBhc3N1bWUgdGhhdCB5b3UgbmV2ZXIgZ2V0 IGFuICZxdW90O3VucmVsYXRlZCZxdW90OyBzdHJlYW0gZnJhbWUgYmVmb3JlIGE8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+JnF1b3Q7cmVsYXRl ZCZxdW90OyBvbmUuIFRoZSBzcGVjIGRvZXNuJ3QgcmVhbGx5IHJlcXVpcmUgdGhhdCByaWdodCBu b3csIGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj5vZmZsaW5lIE1UIHN1Z2dlc3RlZCBqdXN0IHNlbmRpbmcgcmVsYXRlZCB3aXRoIG9mZnNl dD0wIGJ1dCBJIHRoaW5rPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPnRoYXQncyBhIG1pc3Rha2UsIGJlY2F1c2UgaXQgbWVhbnMgdGhhdCB5b3Ug bmVlZCB0byBob2xkIHN0cmVhbSBmcmFtZXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aW4gc29tZSBwcm92aXNpb25hbCAmcXVvdDt1bmRldGVy bWluZWQmcXVvdDsgc3RhdGUgdW50aWwgeW91IGdldCB0aGF0IGZyYW1lLiBJPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPndvdWxkIHN1Z2dlc3Qg aW5zdGVhZCB0aGF0IHdlIHJlcXVpcmUgdGhhdCB5b3UgaW5jbHVkZSB0aGUgZmllbGQgdW50aWw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+b25l IG9mIHRoZSBmcmFtZXMgaXMgQUNLZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SU5URVJOQUxTPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlNlbmRpbmcgYW5kIHJl Y2VpdmluZyBzdHJlYW1zIHN0aWxsIHNoYXJlIGEgbG90IG9mIGNvbW1vbiBjb21wb25lbnRzOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7ICZuYnNwOyB0eXBlIGJhc2VTdHJlYW0gc3RydWN0IHs8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBzdGF0ZSZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtzdHJlYW1TdGF0ZTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IGlk Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDMyPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJz cDsgbG9nJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtsb2dnaW5nRnVu Y3Rpb248bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7ICZuYnNwOyBvZmZzZXQmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgdWludDY0 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOyAmbmJzcDsgY2h1bmtzJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFtdc3RyZWFtQ2h1 bms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7ICZuYnNwOyBtYXhTdHJlYW1EYXRhIHVpbnQ2NDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IGlzUmVsYXRlZCZu YnNwOyAmbmJzcDsgJm5ic3A7Ym9vbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IHJlbGF0ZWQmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDt1aW50MzI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNw OyB0eXBlIHNlbmRTdHJlYW0gc3RydWN0IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBiYXNlU3RyZWFtPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJz cDsgYmxvY2tlZCBib29sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgfTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsg dHlwZSByZWN2U3RyZWFtIHN0cnVjdCB7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgYmFzZVN0cmVhbTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPk1vc3Qgb2YgdGhpcyBpcyB0aGUgc2FtZSBhcyB3aXRoIGJpZGlyZWN0aW9uYWwgc3RyZWFt cy4mbmJzcDsgQXMgYWJvdmUsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPml0J3MgcHJvYmFibHkgcG9zc2libGUgdG8gbWFrZSB0aGVtIG1vcmUg YXN5bW1ldHJpY2FsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhlIGNvbm5lY3Rpb24gbWFpbnRhaW5zIHNlcGFyYXRlIGxpc3RzIG9m IHNlbmRpbmcgYW5kIHJlY2VpdmluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5zdHJlYW1zIGFuZCBpdCdzIHN0cmFpZ2h0Zm9yd2FyZCB0byBj cmVhdGUgYW5kIGFjY2VzcyB0aGVtIHdpdGhvdXQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+d29ycnlpbmcgYWJvdXQgdGhlIG9kZC9ldmVuIHN0 dWZmLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkNPTVBBUklTT048bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+QXQgdGhlIGVuZCBvZiB0aGUgZGF5LCBJIHRoaW5rIHRoaXMgc2hv d3MgdGhhdCB0aGVzZSBkZXNpZ25zIGFyZW4ndDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5yZWFsbHkgdGhhdCBkaXNzc2ltaWxhci4gSSB3YXMg YWJsZSB0byBjb252ZXJ0IE1pbnEgdG8gdW5pZGlyZWN0aW9uYWw8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+c3RyZWFtcyBpbiBhYm91dCAxNiB0 b3RhbCBob3VycyBvZiB3b3JrIChiYXNpY2FsbHkgYSBsb25nIHBsYW5lIGZsaWdodDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5wbHVzIHRoZSBu ZXh0IG1vcm5pbmcpLiBXaGlsZSBJIGhhZCB0byBtYWtlIGEgYnVuY2ggb2YgY2hhbmdlcyB0byB0 aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ aW50ZXJuYWwgc3RydWN0dXJlcywgYmFzaWNhbGx5IG5vbmUgb2YgdGhlbSBtb2RpZmllZCBhbnl0 aGluZyB0cmlja3ksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPmFuZCBpbiBwYXJ0aWN1bGFyIHRoZSBmbG93IGNvbnRyb2wgbWVjaGFuaWNzIGFu ZCB0aGUgbGlrZSBhcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+YmFzaWNhbGx5IHVuY2hhbmdlZCwgZXhjZXB0IGZvciBhIGJ1bmNoIG9mIG1l Y2hhbmljYWwtdHlwZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj50cmFuc2Zvcm1hdGlvbnMgbGlrZSByZWZlcnJpbmcgdG8gfHNlbmRTdHJlYW0u Y2h1bmtzfCBpbnN0ZWFkIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPnxzdHJlYW0uc2VuZC5jaHVua3N8LiBUaGUgb25seSByZWFsbHkgbmV3 IHByb3RvY29sIG1hY2hpbmVyeSBpcyB0aGU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+bmV3IGZyYW1lIGZvcm1hdCBmb3IgcmVsYXRlZCBzdHJl YW1zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+VGhlcmUgYXJlIGEgZmV3IHByb3MvY29ucyB0aGF0IGFyZSB3b3J0aCBub3RpbmcgYWJv dXQgdGhlc2UgZGVzaWducy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPi0gV2l0aG91dCBhIGJpZGlyZWN0aW9uYWwgQVBJLCBoYXZpbmcg dW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBpcyBtb3JlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyB3b3JrIGZvciB0aGUgcHJvZ3JhbW1l ci4gSG93ZXZlciwgd2l0aCBhbiBBUEkgc2hpbSwgdGhlIGRpZmZlcmVuY2U8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IGlzIHRyaXZp YWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4tIEJlY2F1c2UgdW5kaXJlY3Rpb25hbCBzdHJlYW1zIGFyZSBpbmhlcmVudGx5IG1vcmUg ZmxleGlibGUsIGl0J3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7IHBvc3NpYmxlIGZvciB0aGUgc2lkZXMgdG8gdHJ5IHRvIHVzZSBk aWZmZXJlbnQgbWFwcGluZ3MsIGUuZy4sIG9uZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgc2lkZSBleHBlY3RzIHBhaXJlZCBhbmQg dGhlIG90aGVyIGV4cGVjdHMgMTpOLiBXZSdsbCBuZWVkIHNvbWUgd2F5PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBvZiBtYWtpbmcg c3VyZSB0aGF0IGRvZXNuJ3QgaGFwcGVuLCBtYXliZSBBTFBOPzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBUaGUgJnF1b3Q7UmVsYXRl ZCBTdHJlYW0gSUQmcXVvdDsgZnJhbWUgaW5kaWNhdG9yIG5lZWRzIGZsZXNoaW5nIG91dCBhIGJp dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7IEZyb20gdGhlIGFwcGxpY2F0aW9uJ3MgcGVyc3BlY3RpdmUsIGl0IHNob3VsZCBuZXZl ciBoZWFyIGFib3V0IGE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7IHN0cmVhbSB3aXRob3V0IGtub3dpbmcgaXRzIHJlbGF0ZWQgc3Rh dHVzLiBBbmQgYXMgbm90ZWQgYWJvdmUsIEk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IHRoaW5rIGl0IHdvdWxkIGJlIGJlc3QgaWYg d2UgcmVxdWlyZWQgdGhhdCBhbGwgJnF1b3Q7Zmlyc3QgZmxpZ2h0JnF1b3Q7IHN0cmVhbTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg ZnJhbWVzIHRoYXQgYXJlIHJlbGF0ZWQgaW5jbHVkZSB0aGUgZmllZDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBVbmRpcmVjdGlvbmFs IHN0cmVhbXMga2luZCBvZiBzaGFycGVuIHRoZSBjb25mdXNpb24gYWJvdXQgZXhhY3RseTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg d2hhdCBraW5kcyBvZiAmcXVvdDtjbG9zdXJlJnF1b3Q7IHdlIHdhbnQgdG8gYWxsb3cuIFNwZWNp ZmljYWxseSwgd2hhdCBzaG91bGQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IGltcGxlbWVudGF0aW9ucyBiZSBhYmxlIHRvIHNheSBh Ym91dCB0aGVpciB3aWxsaW5nbmVzcyB0byByZWNlaXZlPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgUmlnaHQgbm93IHdlIGhhdmUg U1RPUF9TRU5ESU5HLCBidXQgdGhhdCBkb2Vzbid0IGluZmx1ZW5jZSB0aGU8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IHNlbmRlcidz IHN0YXRlLiBJIGRvbid0IHRoaW5rIHVuZGlyZWN0aW9uYWwgc3RyZWFtcyBtYWtlIHRoaXMgd29y c2UsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyB0aGV5IGp1c3QgcmVxdWlyZSB1cyB0byB0aGluayBpdCB0aHJvdWdoIHNvbWUgbW9y ZS4gVGhleSBkbyBzaW1wbGlmeTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsgdGhlIGltcGxlbWVudGF0aW9uIG9mIHRoZSBjbG9zdXJl IHN0YXRlIG1hY2hpbmU6IGluIG15IFFVSUMtMDUgY29kZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IHdoZW5ldmVyIG9uZSBzaWRl IGNsb3NlcyBJIGhhdmUgdG8gaGF2ZSBjaGVja3MgdG8gc2VlIGlmIEkgc2hvdWxkIGJlPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyB0 cmFuc2l0aW9uaW5nIHRvIENMT1NFRCBvciBIQUxGLUNMT1NFRCwgZXRjLCB3aGljaCBpcyBvZGQg YmVjYXVzZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsgdGhlIGRpcmVjdGlvbnMgYXJlIGJhc2ljYWxseSBpbmRlcGVuZGVudC4mbmJz cDsgSXQgd291bGQgcHJvYmFibHkgYmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IGVhc2llciBldmVuIGluIFFVSUMtMDUgbm90IHRv IHJlaWZ5IHRoZXNlIHN0YXRlcyBidXQganVzdCB0bzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgZGV0ZXJtaW5lIHRoZSBzdGF0ZSBm cm9tIHRoZSBjb21wb3NpdGlvbiBvZiB0aGUgaW5kaXZpZHVhbDxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgc3ViLXN0YXRlczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsm bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+LSBVbmlkaXJlY3Rpb25hbCBzdHJlYW1zIGRvbid0IG5lZWQgdGhlIGtpbmQgb2YgYW5ub3lp bmcgb2RkLWV2ZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7IG1lY2hhbmljcywgd2hpY2ggd2FzIGVhc2llciB0byBjb2RlIHVwIChq dXN0IGhhdmluZyB0byBjcmVhdGUgYWxsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyB0aGUgbG93ZXItbnVtYmVyZWQgc3RyZWFtcyBv ZiB0aGUgc2FtZSBwYXJpdHkgaXMga2luZCBvZiBhIHBhaW4pLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgT25lIGFkZGl0aW9uYWwg YmVuZWZpdCBoZXJlIGlzIHRoYXQgd2l0aCBRVUlDLTA1IHRoZXJlIGFyZSBzZXZlcmFsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBt ZXNzYWdlcyB3aGljaCBpbnZvbHZlIGltcGxpY2l0IHN0cmVhbSBjcmVhdGlvbiAoZS5nLiw8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 IFNUUkVBTV9NQVhfREFUQSwgYW5kIFJTVF9TVFJFQU0pIGFuZCBzbyB5b3UgbmVlZCB0byBjaGVj ayB3aGV0aGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyB0aGUgc3RyZWFtIGlzIG9uZSB0aGF0IHNob3VsZCBoYXZlIGJlZW4gY3Jl YXRlZCBsb2NhbGx5IG9yPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyByZW1vdGVseS4gVGhpcyBqdXN0IGRvZXNuJ3QgaGFwcGVuIHdp dGggYmlkaXJlY3Rpb25hbCBzdHJlYW1zOyBJIGRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBpbXBsZW1lbnQgb2RkL2V2ZW4gbWVj aGFuaWNzIGJ1dCBiZWNhdXNlIHRoZSBvdGhlciBzaWRlIGhhcyB0byBoYXZlPG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBpdHMgc3Ry ZWFtIGlkcyBpbmNyZW1lbnQgYnkgb25lLCBJIGNhbiBtYWtlIHN1cmUgdGhhdCB0aGV5IGhhdmUg dGhlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyByaWdodCBJRHMgYnkgY29uc3RydWN0aW9uIGFuZCBqdXN0IGNoZWNrIHRvIHNlZSBp ZiB0aGUgc3RyZWFtIGV4aXN0czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsgaW4gdGhlc2UgY2FzZXMuJm5ic3A7IEknZCBsaWtlIHRv IHNlZSB1cyBnZXQgcmlkIG9mIG9kZC9ldmVuIG5vIG1hdHRlcjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgd2hhdC48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPi0gVW5pZGly ZWN0aW9uYWwgc3RyZWFtcyBhbHNvIGhlbHBzIGF2b2lkIHNvbWUgb2YgdGhlIGNvcm5lciBjYXNl cyBhcm91bmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7IGJpZGlyZWN0aW9uYWwgc3RyZWFtcy4gU3BlY2lmaWNhbGx5LCBzdXBwb3Nl IEkgYW0gdGhlIGNsaWVudCBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IEkgZ2V0IE1BWF9TVFJFQU1fREFUQSBhcyB0aGUgZmly c3QgZnJhbWUgb24gc3RyZWFtIDIuIEFtIEkgYWxsb3dlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgdG8ganVzdCBzdGFydCBzZW5k aW5nIG9yIG5vdD8gWW91IGNhbiBzb3J0IG9mIGdldCBpbnRvIHRoaXMgc2l0dWF0aW9uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyB3 aXRoIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMsIGJ1dCBiZWNhdXNlIGl0J3MgZXhwbGljaXQsIG9u ZSBtaWdodDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsgaG9wZSB0aGF0IHRoZSBhcHBsaWNhdGlvbiBzZW1hbnRpY3Mgd291bGQgcmVx dWlyZSBjbGVhciBzcGVjaWZpY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBBcyBub3RlZCBhYm92ZSwgYmlkaXJl Y3Rpb25hbCBzdHJlYW1zIGFyZSBtb3JlIGZsZXhpYmxlIGJlY2F1c2UgdGhleTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgbGV0IHlv dSBoYXZlIG1hcHBpbmdzIHRoYXQgeW91IGNhbid0IGhhdmUgd2l0aCB1bmlkaXJlY3Rpb25hbDxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgc3RyZWFtcyAodW5wYWlyZWQsIDE6TikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SGFwcHkgdG8gYW5zd2VyIG1vcmUgcXVl c3Rpb25zIGlmIHBlb3BsZSBoYXZlIHRoZW0uIE90aGVyd2lzZSB3ZSBjYW48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGFsayBhYm91dCB0aGlz IGluIFNlYXR0bGUuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WzBdDQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20lMkZ2MiUyRnVybCUzRnUlM0RodHRwcy0zQV9fbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbV8tM0Z1cmwtM0RodHRwcy0yNTNBLTI1MkYtMjUyRmdpdGh1 Yi5jb20tMjUyRmVrci0yNTJGbWlucS0yNTJGdHJlZS0yNTJGdW5pZGlyZWN0aW9uYWwtNUZzdHJl YW1zLTI2ZGF0YS0zRDAyLTI1N0MwMS0yNTdDbWljaGFlbC5iaXNob3AtMjU0MG1pY3Jvc29mdC5j b20tMjU3QzE0ZjA3OTg3ZGEwZDRhZmI4ZTc1MDhkNTA5MGZmNmY2LTI1N0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0Ny0yNTdDMS0yNTdDMC0yNTdDNjM2NDI0ODg2NTQ2NDgxNzEwLTI2 c2RhdGEtM0R4U2VTWFlHNE9DNmlUWmhpY1ZnSDZxSlROclpFUWhhVUJjMFhSc3hpeXBBLTI1M0Qt MjZyZXNlcnZlZC0zRDAlMjZkJTNERHdNRmFRJTI2YyUzRDk2WmJaWmNhTUY0dzBGNGpwTjZMWmcl MjZyJTNERGpuM2JRNXVOSkRQTV8yc2tmTDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyUyNm0lM0Qw Q2owNEVqc2oyWjA4TElaYVFWZzhKZEpMYmZxLXdlODlDMUNCOUNrNVVJJTI2cyUzREJQTXZfdTZQ b0FVeU5RVDZxUkJvOTFzX1BraGJhcGUzSmJLZTZxZFNnb1UlMjZlJTNEJmFtcDtkYXRhPTAyJTdD MDElN0NNaWNoYWVsLkJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NlN2Q4NjM2NjEzZjE0NTAxMDRj ZDA4ZDUwOWE1NDBjYSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAl N0M2MzY0MjU1Mjc3MjMyNzAzNzMmYW1wO3NkYXRhPU9DcmJLejh0c2hNZFRRMGFNamFmUlFESEdD Mk9ia3RJMnVJbW9mUllkJTJCdyUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly9naXRodWIuY29tL2Vrci9taW5xL3RyZWUvdW5pZGlyZWN0aW9uYWxfc3RyZWFtczwv YT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ WzFdDQo8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UucHJvb2Zwb2ludC5jb20lMkZ2MiUyRnVy bCUzRnUlM0RodHRwcy0zQV9fbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbV8t M0Z1cmwtM0RodHRwcy0yNTNBLTI1MkYtMjUyRmdpdGh1Yi5jb20tMjUyRmVrci0yNTJGd2ctMkRt YXRlcmlhbHMtMjUyRmJsb2ItMjUyRjQwNDg5OGZhMmQyZjBhOWY5YmQyNDRkMmM5NDVlNjZlYTg4 NTAyYTItMjUyRmludGVyaW0tMkQxNy0yRDEwLTI1MkZVbmlkaXJlY3Rpb25hbC0yNTI1MjBTdHJl YW1zLTI1MjUyMGluLTI1MjUyME1pbnEucGRmLTI2ZGF0YS0zRDAyLTI1N0MwMS0yNTdDbWljaGFl bC5iaXNob3AtMjU0MG1pY3Jvc29mdC5jb20tMjU3QzE0ZjA3OTg3ZGEwZDRhZmI4ZTc1MDhkNTA5 MGZmNmY2LTI1N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0Ny0yNTdDMS0yNTdDMS0y NTdDNjM2NDI0ODg2NTQ2NDgxNzEwLTI2c2RhdGEtM0RaLTI1MkJJTk9rQUF2Ylh3WTdZdXdhUGow ZjF5UlhZN1M3OUFrRC0yNTJGdkhHcHdMb1EtMjUzRC0yNnJlc2VydmVkLTNEMCUyNmQlM0REd01G YVElMjZjJTNEOTZaYlpaY2FNRjR3MEY0anBONkxaZyUyNnIlM0REam4zYlE1dU5KRFBNXzJza2ZM M3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJTI2bSUzRDBDajA0RWpzajJaMDhMSVphUVZnOEpkSkxi ZnEtd2U4OUMxQ0I5Q2s1VUklMjZzJTNEVUpVVTQxdUN3SDRKS1RkTnlaUy1XNjBqem43aHR1bFh6 RnVFV21vamh1SSUyNmUlM0QmYW1wO2RhdGE9MDIlN0MwMSU3Q01pY2hhZWwuQmlzaG9wJTQwbWlj cm9zb2Z0LmNvbSU3Q2U3ZDg2MzY2MTNmMTQ1MDEwNGNkMDhkNTA5YTU0MGNhJTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjQyNTUyNzcyMzI3MDM3MyZhbXA7 c2RhdGE9NXRBZlpZSjZ0aW94ZlNDWTh4ZFVveG1ybE5WM1ZaRDczTW1OJTJCRE54eVh3JTNEJmFt cDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vZWtyL3dn LW1hdGVyaWFscy9ibG9iLzQwNDg5OGZhMmQyZjBhOWY5YmQyNDRkMmM5NDVlNjZlYTg4NTAyYTIv aW50ZXJpbS0xNy0xMC9VbmlkaXJlY3Rpb25hbCUyMFN0cmVhbXMlMjBpbiUyME1pbnEucGRmPC9h PjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5b Ml0gVGhhbmtzIHRvIFBhdHJpY2sgTWNNYW51cyBmb3Igc3VnZ2VzdGluZyB0aGlzIGRlc2lnbi48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+WzNd IEluIEMmIzQzOyYjNDM7LCB5b3Ugd291bGQgaGF2ZSBhIHNpbmdsZSBmdW5jdGlvbiB3aXRoIGEg ZGVmYXVsdCBhcmd1bWVudCBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IHxudWxscHRyfCBidXQgR28gZG9lc24ndCBz dXBwb3J0IHRoYXQsIGhlbmNlIHR3byBkaWZmZXJlbnQgYXJndW1lbnRzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bNF0gRm9yIGltcGxlbWVu dGF0aW9uIHJlYXNvbnMsIGl0J3MgYWN0dWFsbHkgdXNpbmcgQ29ubmVjdGlvbiBhcyBhIG1peGlu LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsgJm5ic3A7IHdoaWNoIG1lYW5zIGl0J3Mgc2ltdWx0YW5lb3VzbHkgcG9zc2libGUgdG8g dXNlIHRoZSB1bmlkaXJlY3Rpb25hbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IGFuZCBiaWRpcmVjdGlvbmFsIEFQSXMs IGJ1dCB0aGF0J3MgZ29pbmcgdG8gY2F1c2UgYSBsb3Qgb2YgY29uZnVzaW9uLjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 IEEgcmVhbCBpbXBsZW1lbnRhdGlvbiB3b3VsZCBwcm9iYWJseSBoYXZlIHRvIGVpdGhlciBjb21t aXQgdG8gb25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyAmbmJzcDsgb3IgdGhlIG90aGVyIG9yIGRvIGEgcmVhbCB3cmFwcGVyLCBz byB5b3UgY291bGQgb25seSB1c2Ugb25lIHNldCBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IEFQSXMsIGF0IHRoZSBj b3N0IG9mIGhhdmluZyB0byBkbyBtb3JlIGZvcndhcmRlZCBtZXRob2RzLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4N CjwvaHRtbD4NCg== --_000_MWHPR21MB01413BF390A41A30611441D3877D0MWHPR21MB0141namp_-- From nobody Mon Oct 2 09:34: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 3E67213263F for ; Mon, 2 Oct 2017 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, 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 qcX1rXqn7gta for ; Mon, 2 Oct 2017 09:34:44 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [67.231.149.131]) (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 DC20D1344C6 for ; Mon, 2 Oct 2017 09:34:43 -0700 (PDT) Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v92GW4KH027754; Mon, 2 Oct 2017 17:34:40 +0100 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=+BcJMJ9xig4WXp2Wd64k/QEYdcncpbiZpzK9KTSSamY=; b=kV3lEGhRwZZ//d6mnY0royNw66P1tBh7ZDFFFMHaKkvenda+gQ5JDZdMlVtd9vKIT94B MkfgaXM9mc4oBVMwccFNpyqrM34ZIPK1ghP3Ov+vgMUrtfhNBj60zZ9NVgwPz+oL+yDF BQwRE67/6OOom4Y/xpdd0JvRN/TEIC3OrQEjtyJdgiP3sugT3t9kUvptyrszIHjf7TnE SSfukkII48Cbty/t7bCgiIl2qvhUXI0511lKqQxlk6+RkmNx3Awq0l3VZOVo0tS/Js1Y tA8vKyNpG/HUSN51LViabTvHOwDL1Tv7KWvumRfNFXOH04KDILi1HW+C27s09/qD/MEj Ng== Received: from prod-mail-ppoint4 ([96.6.114.87]) by mx0a-00190b01.pphosted.com with ESMTP id 2da3agch4q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 02 Oct 2017 17:34:39 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id v92GVCnD004373; Mon, 2 Oct 2017 12:34:38 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint4.akamai.com with ESMTP id 2da6ku6811-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 02 Oct 2017 12:34:37 -0400 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; Mon, 2 Oct 2017 12:34:36 -0400 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; Mon, 2 Oct 2017 12:34:36 -0400 From: "Lubashev, Igor" To: Mike Bishop , Eric Rescorla CC: "quic@ietf.org" , "mikkelfj@gmail.com" Subject: RE: Report on Unidirectional Streams in Minq Thread-Topic: Report on Unidirectional Streams in Minq Thread-Index: AQHTOvRbU4+GuQVlg0GF7a8KPXeTJqLPt6aAgAAG7ICAAAR+AIAAAqAAgACnRpiAAHw6gIAAFVAA///CTSA= Date: Mon, 2 Oct 2017 16:34:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.203] Content-Type: multipart/alternative; boundary="_000_b6ca3e39c94e44c2ad1987d5ea90078eusma1exdag1mb5msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-02_04:, , 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-1710020241 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-02_04:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710020241 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, 02 Oct 2017 16:34:49 -0000 --_000_b6ca3e39c94e44c2ad1987d5ea90078eusma1exdag1mb5msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzLCBNaWtlLiAgSW5kZWVkLCBJIHRob3VnaHQgdGhlIGl0IHdhcyBwcm9wb3NlZCBmb3Ig dGhlIHNlbmRlciB0byBzZW5kIFJFU0VUX1NUUkVBTSBpbiB0aGUgc2FtZSBmcmFtZSBhcyBTVFJF QU0ob2ZmPTB8RklOKSAoYW5kIGxlbj4wKS4gIFllcywgU1RSRUFNKG9mZj0wfGxlbj0wfEZJTikg aXMgZXF1aXZhbGVudCB0byBSRVNFVF9TVFJFQU0sIGFzIGZhciBhcyB0cmFuc3BvcnQgc3RhdGUg aXMgY29uY2VybmVkIChidXQgaXQgbWF5IGhhdmUgYSBkaWZmZXJlbnQgQVBJIGVmZmVjdCDigJMg YSBkaWZmZXJlbnQgY2FsbGJhY2sgY2FsbGVkKS4NCg0KRnJvbTogTWlrZSBCaXNob3AgW21haWx0 bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tXQ0KU2VudDogTW9uZGF5LCBPY3RvYmVyIDAy LCAyMDE3IDEyOjA4IFBNDQpUbzogRXJpYyBSZXNjb3JsYSA8ZWtyQHJ0Zm0uY29tPjsgTHViYXNo ZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb20+DQpDYzogcXVpY0BpZXRmLm9yZzsgbWlra2Vs ZmpAZ21haWwuY29tDQpTdWJqZWN0OiBSRTogUmVwb3J0IG9uIFVuaWRpcmVjdGlvbmFsIFN0cmVh bXMgaW4gTWlucQ0KDQpJIHRoaW5rIHlvdeKAmXJlIHRhbGtpbmcgcGFzdCBlYWNoIG90aGVyLiAg SWdvciwgdGhlIGRyYWZ0IGN1cnJlbnRseSBzYXlzIHRoYXQgUlNUX1NUUkVBTSBhcHBsaWVzIHRv IHRoZSBzZW5kZXLigJlzIGRpcmVjdGlvbiBvbmx5LCBzbyBzZW5kaW5nIGEgUlNUX1NUUkVBTSBk b2VzbuKAmXQgaGVscCBhbnl0aGluZy4gIFRoZSBvdGhlciBzaWRlIGNvdWxkIHJlYXNvbmFibHkg c2VuZCBSU1RfU1RSRUFNIG9yIHRoZSBTVFJFQU0tRklOLCBhbmQgdGhleeKAmXJlIGlkZW50aWNh bCBmb3IgYWxsIHByYWN0aWNhbCBwdXJwb3Nlcy4gIFRoZSBwb2ludCBpcyB0aGF0IG9uZSBzaWRl IGlzIHNlbmRpbmcgYWxsIHRoZSBkYXRhLCBidXQgdGhlIG90aGVyIHNpZGUgc3RpbGwgaGFzIHRv IGFjayBvbiB0aGUgc3RyZWFtIGZvciBpdCB0byByZWFjaCB0aGUgY2xvc2VkIHN0YXRlLiAgVW5p ZGlyZWN0aW9uYWwgc3RyZWFtcyBkb27igJl0IHJlcXVpcmUgYW55IHBlci1zdHJlYW0gYWN0aW9u IGJ5IHRoZSByZWNlaXZlciB0byBjb21wbGV0ZSB0aGUgc3RhdGUgbWFjaGluZS4NCg0KRnJvbTog RXJpYyBSZXNjb3JsYSBbbWFpbHRvOmVrckBydGZtLmNvbV0NClNlbnQ6IE1vbmRheSwgT2N0b2Jl ciAyLCAyMDE3IDc6NTIgQU0NClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNv bTxtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbT4+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwu QmlzaG9wQG1pY3Jvc29mdC5jb208bWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+ PjsgcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz47IG1pa2tlbGZqQGdtYWlsLmNv bTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPg0KU3ViamVjdDogUmU6IFJlcG9ydCBvbiBVbmlk aXJlY3Rpb25hbCBTdHJlYW1zIGluIE1pbnENCg0KDQoNCk9uIE1vbiwgT2N0IDIsIDIwMTcgYXQg NDoyNyBBTSwgTHViYXNoZXYsIElnb3IgPGlsdWJhc2hlQGFrYW1haS5jb208bWFpbHRvOmlsdWJh c2hlQGFrYW1haS5jb20+PiB3cm90ZToNCj4gTml0OiBDYW4ndCB5b3Ugc2VuZCBSRVNFVF9TVFJF QU0NCg0KSSBkbyBub3QgdGhpbmsgdGhpcyBpcyBhbiBvcHRpb24sIHNpbmNlIFJFU0VUX1NUUkVB TSBtYXkgcHJldmVudCBkYXRhIGJ1ZmZlcmVkIGJ5IHRoZSB0cmFuc3BvcnQgZnJvbSBiZWluZyBk ZWxpdmVyZWQgdG8gdGhlIGFwcGxpY2F0aW9uLg0KDQoNClRob3NlIGFyZSBhbHNvIHRoZSBzZW1h bnRpY3Mgb2YgU1RSRUFNKG9mZnNldD0wLCBGSU4pLg0KDQotRWtyDQoNCg0KDQpJIGFtIGxlc3Mg Y29uY2VybmVkIGFib3V0IGhvdyBsb25nIGNvbm5lY3Rpb24gc3RhdGUgaGFzIHRvIGJlIGtlcHQg YXJvdW5kIC0tIGluIGEgY29vcGVyYXRpbmcgcGVlciBzaXR1YXRpb24sIHRoaXMgaXMgb25lIHJ0 dCwgd2hpY2ggaXMgdGhlIHNhbWUgYW1vdW50IG9mIHRpbWUgdGhhdCBpcyByZXF1aXJlZCB0byB3 YWl0IGZvciBhbiBBQ0suIEEgbWFsaWNpb3VzIHBlZXIgY291bGQgd2l0aGhvbGQgQUNLcyBmb3Ig cGFja2V0cyB3aXRoIFNUUkVBTStGSU4uIFRoZSBiaWRpcmVjdGlvbmFsIHByb3RvY29sIGlzIG1v cmUgY2hhdHR5LCB0aG91Z2guDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJv bTogRXJpYyBSZXNjb3JsYSBbZWtyQHJ0Zm0uY29tPG1haWx0bzpla3JAcnRmbS5jb20+XQ0KUmVj ZWl2ZWQ6IFN1bmRheSwgMDEgT2N0IDIwMTcsIDU6MjlQTQ0KVG86IE1pa2UgQmlzaG9wIFtNaWNo YWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQu Y29tPl0NCkNDOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIFttaWtrZWxmakBnbWFpbC5jb208 bWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNvbT5dOyBJRVRGIFFVSUMgV0cgW3F1aWNAaWV0Zi5vcmc8 bWFpbHRvOnF1aWNAaWV0Zi5vcmc+XQ0KU3ViamVjdDogUmU6IFJlcG9ydCBvbiBVbmlkaXJlY3Rp b25hbCBTdHJlYW1zIGluIE1pbnENCg0KDQpPbiBTdW4sIE9jdCAxLCAyMDE3IGF0IDI6MTkgUE0s IE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVs LkJpc2hvcEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQpJIHRoaW5rIHRoZSBkaWZmZXJlbmNlIGlz IGZvciB0aGUgc2NlbmFyaW8gd2hlcmUgeW91IGRvbuKAmXQgZXhwZWN0IGEgcGVlciB0byByZXNw b25kIChvciBkb27igJl0IGV4cGVjdCB0aGVtIHRvIHJlc3BvbmQgc3RyZWFtLWJ5LXN0cmVhbSku ICBXaXRoIC0wNSwgdGhlIHJlY2VpdmVyIHN0aWxsIG5lZWRzIHRvIHNlbmQgU1RSRUFNKG9mZnNl dD0wLEZJTikgb24gZWFjaCBzdHJlYW0uDQoNCk5pdDogQ2FuJ3QgeW91IHNlbmQgUkVTRVRfU1RS RUFNPw0KDQoNCiAgV2l0aCBlaXRoZXIgdW5pZGlyZWN0aW9uYWwgcHJvcG9zYWwsIHRoaXMgcGF0 dGVybiBpcyBhIGJpdCBjbGVhbmVyLiAgSW4gIzY1NiwgdGhlIHNlbmRlciBjYW4gZXNzZW50aWFs bHkgc2F5LCDigJxEb27igJl0IGJvdGhlcuKAnSBhdCB0aGUgdGltZSBvZiBzdHJlYW0gY3JlYXRp b24uICBJbiAjNjQzLCB0aGVyZeKAmXMgbm8gY29ycmVzcG9uZGluZyBjaGFubmVsIHRvIGNsb3Nl Lg0KDQpZZXMsIEkgYWdyZWUgdGhhdCB0aGlzIGlzIGNsZWFuZXIuIE5vdGUgdGhhdCBpbiAjNjQz IHlvdSBwcmVzdW1hYmx5IG5lZWQgdG8gaGF2ZSBzb21lIHdheSBvZiBzaWduYWxpbmcgdGhhdCB5 b3UgZG9uJ3Qgd2FudCBhIHJldHVybiBjb25uZWN0aW9uLi4uLg0KDQoNCg0KSW4gYWxsIGNhc2Vz LCB0aGUgb25seSB0aGluZyB0aGF0IHJlYWxseSBsaW1pdHMgeW91IGlzIHRoZSBwZWVy4oCZcyB3 aWxsaW5nbmVzcyB0byBpbmNyZWFzZSB5b3VyIE1BWF9TVFJFQU1fSUQsIGl04oCZcyBqdXN0IGEg cXVlc3Rpb24gb2YgaG93IGNoYXR0eSB5b3UgaGF2ZSB0byBiZSDigJMgd2hpY2ggY2FuIG1hdHRl ciBpZiB0aGVzZSBtZXNzYWdlcyBhcmUgZmFpcmx5IHNtYWxsLg0KDQpBZ3JlZWQuDQoNCi1Fa3IN Cg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpxdWlj LWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgRXJpYyBSZXNjb3JsYQ0KU2VudDogU3Vu ZGF5LCBPY3RvYmVyIDEsIDIwMTcgMjowMyBQTQ0KVG86IE1pa2tlbCBGYWhuw7hlIErDuHJnZW5z ZW4gPG1pa2tlbGZqQGdtYWlsLmNvbTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4NCkNjOiBJ RVRGIFFVSUMgV0cgPHF1aWNAaWV0Zi5vcmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Pg0KU3ViamVj dDogUmU6IFJlcG9ydCBvbiBVbmlkaXJlY3Rpb25hbCBTdHJlYW1zIGluIE1pbnENCg0KSSdtIG5v dCBzdXJlIEkgaGF2ZSBhbnkgdXNlZnVsIGluc2lnaHRzIG9uIHRoaXMsIGFzIG15IGltcGxlbWVu dGF0aW9uIGhhbmRsZXMgdGhlbSBtb3JlIG9yIGxlc3MgdGhlIHNhbWUuIENhbiB5b3UgZXhwbGFp biB3aHkgeW91IHRoaW5rIHRoaXMgd291bGQgYmUgZGlmZmVyZW50IHdpdGggdW5pZGlyZWN0aW9u YWwgdmVyc3VzIGJpZGlyZWN0aW9uYWw/DQoNCi1Fa3INCg0KDQpPbiBTdW4sIE9jdCAxLCAyMDE3 IGF0IDE6MzggUE0sIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gPG1pa2tlbGZqQGdtYWlsLmNv bTxtYWlsdG86bWlra2VsZmpAZ21haWwuY29tPj4gd3JvdGU6DQpUaGFua3MsDQoNCkkgb25seSBz a2ltbWVkIHRoaXMgc3VwZXJmYXN0LCBidXQgb25lIHRoZSBvYnNlcnZhdGlvbnMgYXBwZWFyIHRv IG5vdCBjb3ZlciBvbmUgb2YgbXkga2V5IHBvaW50czoNCg0KWW91IGNhbiBjcmVhdGUgYW5kIGNs b3NlIHVuaS1zdHJlYW1zIGF0IGF0IHZlcnkgaGlnaCByYXRlIG9mIG1hbnkgc3RyZWFtcyBwZXIg cGFja2V0LCB3aXRob3V0IHdhaXRpbmcgZm9yIHBlZXIgcmVzcG9uc2UsIGFzc3VtaW5nIHRoZSBB Q0sgZnJhbWV3b3JrIGhhbmRsZXMgcmV0cmFuc21pc3Npb24uIEFueSBpbnNpZ2h0cyBvbiB0aGlz Pw0KDQpLaW5kIFJlZ2FyZHMsDQpNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQoNCg0KT24gMSBP Y3RvYmVyIDIwMTcgYXQgMjIuMzIuMDIsIEVyaWMgUmVzY29ybGEgKGVrckBydGZtLmNvbTxtYWls dG86ZWtyQHJ0Zm0uY29tPikgd3JvdGU6DQpIaSBmb2xrcywNCg0KQXMgcHJvbWlzZWQgSSBzcGVu dCBhIGJ1bmNoIG9mIHRpbWUgaGFja2luZyB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zDQppbnRvIE1p bnEgYW5kIEknbSBoZXJlIHRvIHJlcG9ydCBiYWNrIFswXS4gU3BlY2lmaWNhbGx5LCBJDQppbXBs ZW1lbnRlZDoNCg0KICAtIFBSIzY0MyAtLSBVbmlkaXJlY3Rpb25hbCBTdHJlYW1zDQogIC0gUFIj NzIwIC0tIEFkZCBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgb24gdG9wIG9mIHVuaWRpcmVjdGlvbmFs DQogIC0gQSBiaWRpcmVjdGlvbmFsIHN0cmVhbSBBUEkgdGhhdCBtb3N0bHkgbWltaWNzIE1pbnEn cyBvcmlnaW5hbCBBUEkNCiAgICBmb3IgLTA1Lg0KDQpUaGUgZm9sbG93aW5nIGlzIGtpbmQgb2Yg YSB3YWxsIG9mIHRleHQsIHNvIHlvdSBjb3VsZCBhbHNvIHNraXAgdGhpcw0KYW5kIHJlZmVyIHRv IG15IHNsaWRlcyBbMV0uDQoNCg0KTUlOUSdTIC0wNSBBUkNISVRFQ1RVUkUNCkFQSQ0KTWlucSdz IG1hc3RlciBvYmplY3QgaXMgdGhlIENvbm5lY3Rpb24sIHdoaWNoIGhhcyBhIGxpc3Qgb2YgU3Ry ZWFtcw0KaW5kZXhlZCBieSBzdHJlYW0gSUQuIEFwcGxpY2F0aW9ucyByZWdpc3RlciBhIGhhbmRs ZXIgd2l0aCB0aGUNCmNvbm5lY3Rpb24gdG8gYmUgbm90aWZpZWQgb2YgbmV3IGV2ZW50cy4NCg0K ICAgdHlwZSBDb25uZWN0aW9uSGFuZGxlciBpbnRlcmZhY2Ugew0KICAgIC8vIFRoZSBjb25uZWN0 aW9uIGhhcyBjaGFuZ2VkIHN0YXRlIHRvIHN0YXRlIHxzfA0KICAgIFN0YXRlQ2hhbmdlZChzIFN0 YXRlKQ0KDQogICAgLy8gQSBuZXcgc3RyZWFtIGhhcyBiZWVuIGNyZWF0ZWQgKGJ5IHJlY2Vpdmlu ZyBhIGZyYW1lDQogICAgLy8gZnJvbSB0aGUgb3RoZXIgc2lkZS4gfHN8IGNvbnRhaW5zIHRoZSBz dHJlYW0uDQogICAgTmV3U3RyZWFtKHMgKlN0cmVhbSkNCg0KICAgIC8vIFN0cmVhbSB8c3wgaXMg bm93IHJlYWRhYmxlLg0KICAgIFN0cmVhbVJlYWRhYmxlKHMgKlN0cmVhbSkNCiAgIH0NCg0KU3Ry ZWFtcyBnZXQgY3JlYXRlZCBpbiB0d28gd2F5czoNCg0KLSBMb2NhbGx5IHZpYSBDb25uZWN0aW9u LkNyZWF0ZVN0cmVhbSgpDQotIFJlbW90ZWx5LCBpbiB3aGljaCBjYXNlIHRoZSBhcHBsaWNhdGlv biBpcyBub3RpZmllZCB2aWEgYSBjYWxsYmFjayB0bw0KICBDb25uZWN0aW9uSGFuZGxlci5OZXdT dHJlYW0oKS4NCg0KU3RyZWFtcyB0aGVtc2VsdmVzIGhhdmUgdGhlIEFQSXMgeW91IHdvdWxkIGV4 cGVjdCwgbmFtZWx5LCBSZWFkKCksDQpXcml0ZSgpLCBDbG9zZSgpLCBSZXNldCgpLCBldGMuIFlv dSBnZXQgbm90aWZpZWQgb2Ygc3RyZWFtIHJlYWRhYmlsaXR5DQpieSBhIGNhbGxiYWNrIHRvIENv bm5lY3Rpb25IYW5kbGVyLlN0cmVhbVJlYWRhYmxlKCksIGF0IHdoaWNoIHBvaW50DQp5b3UgY2Fu IGRvIFN0cmVhbS5SZWFkKCkuIEFzIGV4cGVjdGVkLCBTdHJlYW0uUmVhZCgpIHJldHVybnMNCldP VUxEQkxPQ0sgd2hlbiBubyBkYXRhIGlhIGF2YWlsYWJsZQ0KDQoNCklOVEVSTkFMUw0KQXMgbm90 ZWQgYWJvdmUsIHdlIHN0YXJ0IHdpdGggdGhlIENvbm5lY3Rpb24gb2JqZWN0IChvbmx5IHJlbGV2 YW50IGZpZWxkcw0Kc2hvd24pOg0KDQogICB0eXBlIENvbm5lY3Rpb24gc3RydWN0IHsNCiAgICBo YW5kbGVyICAgICAgICAgIENvbm5lY3Rpb25IYW5kbGVyDQogICAgc3RyZWFtcyAgICAgICAgICBb XSpTdHJlYW0NCiAgICBtYXhTdHJlYW0gICAgICAgIHVpbnQzMg0Kb3V0cHV0Q2xlYXJRICAgICBb XWZyYW1lIC8vIEZvciBzdHJlYW0gMA0Kb3V0cHV0UHJvdGVjdGVkUSBbXWZyYW1lIC8vIEZvciBz dHJlYW0gPj0gMA0KICAgfQ0KDQpBcyB5b3UgY2FuIHNlZSwgc3RyZWFtcyBhcmUgaW4gYW4gYXJy YXkgc2xpY2UsIHNvIHRoZXkncmUgY29udGlndW91c2x5DQppbmRleGVkIGJ5IHN0cmVhbSBJRC4g UmlnaHQgbm93LCBJIGhhdmUgbm8gcHJvdmlzaW9uIGZvciByZWNsYWltaW5nDQp0aGUgdW51c2Vk IGJvdHRvbSBwYXJ0IG9mIHRoZSBhcnJheSwgYnV0IGl0IHdvdWxkIGJlIHN0cmFpZ2h0Zm9yd2Fy ZA0KdG8gaW5kZXggYnkgfHN0cmVhbUlkfCAtIHxtaW5TdHJlYW18LCB3aGljaCBJIHRoaW5rIGlz IGNvbnNpc3RlbnQgd2l0aA0KdGhlIGRlc2lnbiBpbXBsaWVkIGJ5IHRoZSByZXF1aXJlbWVudCB0 byBjcmVhdGUgc3RyZWFtcyBpbiBzZXF1ZW5jZS4NCg0KQmVjYXVzZSBTdHJlYW1zIGFyZSBiaWRp cmVjdGlvbmFsLCBlYWNoIHN0cmVhbSBhY3R1YWxseSBjb25zaXN0cyBvZiBhDQpwYWlyIG9mIGhh bGYgc3RyZWFtcy4NCg0KICAgdHlwZSBzdHJlYW1IYWxmIHN0cnVjdCB7DQogICAgcyAgICAgICAg ICAgICAqc3RyZWFtICAgICAgICAgICAvLyBwb2ludGVyIHRvIHBhcmVudA0KICAgIGxvZyAgICAg ICAgICAgbG9nZ2luZ0Z1bmN0aW9uDQogICAgZGlyICAgICAgICAgICBkaXJlY3Rpb24gICAgICAg ICAvLyBTZW5kaW5nIG9yIHJlY2VpdmluZw0KICAgIGNsb3NlZCAgICAgICAgYm9vbCAgICAgICAg ICAgICAgLy8gSXMgdGhlIGhhbGYtc3RyZWFtIGNsb3NlZA0KICAgIG9mZnNldCAgICAgICAgdWlu dDY0ICAgICAgICAgICAgLy8gVGhlDQogICAgY2h1bmtzICAgICAgICBbXXN0cmVhbUNodW5rDQog ICAgbWF4U3RyZWFtRGF0YSB1aW50NjQNCiAgIH0NCg0KICAgLy8gSW50ZXJuYWwgb2JqZWN0IHRv IGFsbG93IHVuaXQgdGVzdGluZy4NCiAgIHR5cGUgc3RyZWFtIHN0cnVjdCB7DQogICAgaWQgICAg ICAgICB1aW50MzINCiAgICBsb2cgICAgICAgIGxvZ2dpbmdGdW5jdGlvbg0KICAgIHN0YXRlICAg ICAgc3RyZWFtU3RhdGUNCiAgICBzZW5kLCByZWN2ICpzdHJlYW1IYWxmDQogIGJsb2NrZWQgICAg Ym9vbCAvLyBIYXZlIHdlIHJldHVybmVkIGJsb2NrZWQNCiAgIH0NCg0KICAgLy8gUHVibGljIEFQ SSBvYmplY3QsIHdoaWNoIG5lZWRzIGFjY2VzcyB0byB0aGUgQ29ubmVjdGlvbg0KICAgdHlwZSBT dHJlYW0gc3RydWN0IHsNCiAgICBjICpDb25uZWN0aW9uDQogICAgc3RyZWFtDQogICB9DQoNCk91 dGdvaW5nIGRhdGEgaXMgZW5xdWV1ZWQgaW50byB8c3RyZWFtLmNodW5rc3wsIGFuZCB0aGVuIHBl cmlvZGljYWxseQ0KdGhlIGNvbm5lY3Rpb24gcG9sbHMgdGhlIHN0cmVhbSBmb3IgYWxsIHRoZSBj aHVua3Mgd2hpY2ggYXJlIHBlcm1pdHRlZA0KYnkgc3RyZWFtLWxldmVsIGZsb3cgY29udHJvbCBh bmQgZW5xdWV1ZXMgdGhlbSBpbnRvDQp8Q29ubmVjdGlvbi5vdXRwdXRDbGVhclF8IG9yIHxDb25u ZWN0aW9uLm91dHB1dFByb3RlY3RlZFF8LiBBdCB0aGlzDQpwb2ludCwgdGhlIGNvbm5lY3Rpb24g b3ducyB0aGUgZGF0YSBhbmQgaXMgcmVzcG9uc2libGUgZm9yDQp0cmFuc21pdHRpbmcgaXQsIHN1 YmplY3QgdG8gY29ubmVjdGlvbi1sZXZlbCBmbG93IGNvbnRyb2wsIGFuZA0KKHByZXN1bWFibHkp IGNvbmdlc3Rpb24gY29udHJvbCBvbmNlIEkgaGF2ZSB0aGF0IGltcGxlbWVudGVkIFsyXS4NCg0K SW5jb21pbmcgZGF0YSBnZXRzIHF1ZXVlZCAoc29ydGVkKSBpbnRvIHxzdHJlYW0uY2h1bmtzfCBm b3IgbGF0ZXINCnJlYXNzZW1ibHkgYXQgdGhlIHRpbWUgd2hlbiBzb21lb25lIGNhbGxzIHN0cmVh bS5yZWFkKCkuIEknbSBub3Qgc3VyZQ0KSSBsb3ZlIHRoaXMsIGJlY2F1c2UgaXQgbWVhbnMgSSBk b24ndCBoYXZlIGEgZ29vZCB2aWV3IG9mIHRoZSBpbmNvbWluZw0KcXVldWUgc2l6ZSAod2hpY2gg SSdkIG5lZWQgdG8gYWNjb3VudCBmb3Igc2VwYXJhdGVseSksIGJ1dCBpdCBhbGxvd2VkDQptZSB0 byBzaGFyZSBkYXRhIHN0cnVjdHVyZXMgYmV0d2VlbiBpbmNvbWluZyBhbmQgb3V0Z29pbmcsIHdo aWNoDQpzZWVtZWQga2luZCBvZiBuYXR1cmFsIHdoZW4gSSBkaWQgaXQgKHRoaXMgYXJjaGl0ZWN0 dXJlIGlzIHJlcGxpY2F0ZWQNCmluIHRoZSB1bmlkaXJlY3Rpb25hbCBzdHJlYW1zIGRlc2lnbiwg YnV0IGl0J3MgcHJvYmFibHkgbGVzcyBuYXR1cmFsDQp0aGVyZSkuDQoNCg0KVU5JRElSRUNUSU9O QUwgU1RSRUFNUyBBUkNISVRFQ1RVUkUNClVOSURJUkVDVElPTkFMIEFQSQ0KV2l0aCB0aGUgdW5p ZGlyZWN0aW9uYWwgYnJhbmNoLCBNaW5xIG9mZmVycyB0d28gQVBJcy4gVGhlIGZpcnN0IGlzIGEN CnN0cmFpZ2h0Zm9yd2FyZCBtYXBwaW5nIG9mIFBSIzcyMCwgaW4gd2hpY2ggd2UgaGF2ZSB0d28g b2JqZWN0czoNCg0KICBTZW5kU3RyZWFtIC0tIHVzZWQgZm9yIHdyaXRpbmcNCiAgUmVjdlN0cmVh bSAtLSB1c2VkIGZvciByZWFkaW5nDQoNCkFzIGJlZm9yZSwgd2UgaGF2ZSBhIGhhbmRsZXIgb2Jq ZWN0LCBidXQgaXQncyBkaXJlY3Rpb25hbCBub3c6DQoNCiAgIHR5cGUgQ29ubmVjdGlvbkhhbmRs ZXIgaW50ZXJmYWNlIHsNCiAgICAvLyBUaGUgY29ubmVjdGlvbiBoYXMgY2hhbmdlZCBzdGF0ZSB0 byBzdGF0ZSB8c3wNCiAgICBTdGF0ZUNoYW5nZWQocyBTdGF0ZSkNCg0KICAgIC8vIEEgbmV3IHJl Y2VpdmluZyBzdHJlYW0gaGFzIGJlZW4gY3JlYXRlZCAoYnkgcmVjZWl2aW5nIGEgZnJhbWUNCiAg ICAvLyBmcm9tIHRoZSBvdGhlciBzaWRlLiB8c3wgY29udGFpbnMgdGhlIHN0cmVhbS4NCiAgICBO ZXdSZWN2U3RyZWFtKHMgKlJlY3ZTdHJlYW0pDQoNCiAgICAvLyBTdHJlYW0gfHN8IGlzIG5vdyBy ZWFkYWJsZS4NCiAgICBTdHJlYW1SZWFkYWJsZShzICpSZWN2U3RyZWFtKQ0KICAgfQ0KDQpPYnZp b3VzbHkgU2VuZFN0cmVhbXMgYXJlIGxvY2FsbHkgY3JlYXRlZCBhbmQgUmVjdlN0cmVhbXMgYXJl IHJlbW90ZWx5DQpjcmVhdGVkLiBTZW5kU3RyZWFtcyBjYW4gYmUgY3JlYXRlZCB1c2luZw0KQ29u bmVjdGlvbi5DcmVhdGVTZW5kU3RyZWFtKCkgYW5kIHlvdSBsZWFybiBhYm91dCByZW1vdGVseSBj cmVhdGVkDQpSZWN2U3RyZWFtcyBieSBhIGNhbGxiYWNrIHRvIENvbm5lY3Rpb25IYW5kbGVyLk5l d1JlY3ZTdHJlYW0oKS4NClNlY29uZC1jcmVhdGVkIHN0cmVhbXMgY2FuIGJlIG1hcmtlZCBhcyAi cmVsYXRlZCIgdG8gYSBzaW5nbGUNCmZpcnN0LWNyZWF0ZWQgc3RyZWFtLCB1c2luZyBDb25uZWN0 aW9uLkNyZWF0ZVJlbGF0ZWRTZW5kU3RyZWFtKCkgd2l0aA0KdGhlIGFwcHJvcHJpYXRlIFJlY3ZT dHJlYW0gYXMgdGhlIGFyZ3VtZW50IFszXS4gU3RyZWFtcyBoYXZlIGENClJlbGF0ZWQoKSBBUEkg dG8gdGVsbCB5b3UgaWYgdGhleSBhcmUgcmVsYXRlZCB0byBzb21lIG90aGVyIHN0cmVhbS4NCg0K VGhlIHtTZW5kLFJlY3Z9U3RyZWFtIEFQSXMgYXJlIGFib3V0IHdoYXQgeW91J2QgZXhwZWN0LiBZ b3UgY2FuDQpXcml0ZSgpIG9uIFNlbmRTdHJlYW0gYW5kIFJlYWQoKSBvbiBSZWN2U3RyZWFtKCku IFJpZ2h0IG5vdywgeW91IGNhbg0KQ2xvc2UoKSBhbmQgUmVzZXQoKSBTZW5kU3RyZWFtcywgYnV0 IG5vdCBkbyBhbnl0aGluZyBvbiBSZWN2U3RyZWFtcygpDQpvciB0aGFuIGlnbm9yZSB0aGVtLiBF dmVudHVhbGx5IEknbGwgcHJvYmFibHkgb2ZmZXINClJlY3ZTdHJlYW0oKS5NdXRlKCkgb3Igc29t ZXRoaW5nIHRvIGxldCB5b3Ugc2VuZCBTVE9QX1NFTkRJTkcuDQoNCg0KQklESVJFQ1RJT05BTCBB UEkNCk1pbnEgYWxzbyBpbmNsdWRlcyBhIGJpZGlyZWN0aW9uYWwgQVBJIHRoYXQncyBsYXllcmVk IG9uIHRvcCBvZg0KdW5pZGlyZWN0aW9uYWwgc3RyZWFtcy4gSSd2ZSBjcmVhdGVkIGEgQ29ubmVj dGlvbjIgc3RydWN0dXJlIHRoYXQncw0KaW50ZW5kZWQgYXMgYSB3cmFwcGVyIGFyb3VuZCBDb25u ZWN0aW9uIFs0XToNCg0KICAgdHlwZSBDb25uZWN0aW9uMiBzdHJ1Y3Qgew0KICAgIENvbm5lY3Rp b24NCiAgICBzaGltICAgICpjb25uZWN0aW9uMlNoaW1IYW5kbGVyDQogICAgc3RyZWFtcyBbXSpT dHJlYW0gLy8gT2RkIGZvciBjbGllbnQgb3JpZ2luYXRlZCwgZXZlbiBmb3Igc2VydmVyLg0KICAg fQ0KDQogICB0eXBlIFN0cmVhbSBzdHJ1Y3Qgew0KICAgIGlkICAgdWludDMyDQogICAgc2VuZCAq U2VuZFN0cmVhbQ0KICAgIHJlY3YgKlJlY3ZTdHJlYW0NCiAgIH0NCg0KQmFzaWNhbGx5LCBTdHJl YW0gaXMganVzdCBhIHBhaXIgb2YgU2VuZFN0cmVhbSBhbmQgUmVjdlN0cmVhbSBhbmQNCkNvbm5l Y3Rpb24yIGRvZXMgdGhlIGJvb2trZWVwaW5nIHRvIGtlZXAgdGhlbSBjb25uZWN0ZWQgKEkgZXZl biBkbyB0aGUNCm9kZC9ldmVuIElEIHRoaW5nIHRoYXQgUVVJQy0wNSBoYXMpLiBDb25uZWN0aW9u MiBoYXMgdGhlIHNhbWUgaGFuZGxlcg0KQVBJIGFzIE1pbnEgZm9yIFFVSUMtMDUsIGFuZCB0aGUg c2hpbSBpcyByZXNwb25zaWJsZSBmb3IgdHJhbnNsYXRpbmcNCnVuaWRpcmVjdGlvbmFsIGV2ZW50 cyBpbnRvIGJpZGlyZWN0aW9uYWwgZXZlbnRzLg0KDQpJbnRlcm5hbGx5LCB3aGF0J3MgZ29pbmcg b24gaGVyZSBpcyB0aGF0IHdoZW4geW91IGNhbGwgQ3JlYXRlU3RyZWFtKCkNCk1pbnEgY3JlYXRl cyBhIFN0cmVhbSB3aXRoIGEgbmlsIFJlY3ZTdHJlYW0uIFdoZW4gYSBuZXcgcmVtb3RlIHN0cmVh bQ0KaXMgZGV0ZWN0ZWQsIHdlIGNoZWNrIFJlY3ZTdHJlYW0uUmVsYXRlZCgpLiBJZiB0aGV5IGFy ZSByZWxhdGVkIHRvIGFuDQpleGlzdGluZyBTZW5kU3RyZWFtIHRoZW4gd2Ugd2lsbCBpbiB0aGUg cmVsZXZhbnQgfFN0cmVhbS5zZW5kfCBzbG90Lg0KT3RoZXJ3aXNlLCB3ZSBjcmVhdGUgYSBuZXcg U2VuZFN0cmVhbSB0aGF0J3MgcmVsYXRlZCB0byB0aGUgaW5jb21pbmcNCnN0cmVhbSBhbmQgbm90 aWZ5IHRoZSBhcHBsaWNhdGlvbiBvZiB0aGUgY3JlYXRpb24gb2YgdGhlIG5ldw0KYmlkaXJlY3Rp b25hbCBzdHJlYW0uDQoNCk5vdGUgdGhhdCB0aGlzIGFsbCB3b3JrcyBmaW5lIGlmIG9uZSBzaWRl IGRvZXMgdGhlIHVuZGlyZWN0aW9uYWwgQVBJDQphbmQgb25lIGRvZXMgdGhlIGJpZGlyZWN0aW9u YWwgQVBJLiBNeSB0ZXN0IHByb2dyYW1zIGFjdHVhbGx5IGV4ZXJjaXNlDQp0aGlzLiBPZiBjb3Vy c2UsIHRoZXJlJ3MgYW4gYXNzdW1wdGlvbiB0aGF0IHRoZSBwZWVyIGNvbmZvcm1zIHRvIGEgMTox DQptYXBwaW5nLiBJZiB3ZSBkZWZpbmUgdW5pZGlyZWN0aW9uYWwgc3RyZWFtcywgd2UnbGwgbmVl ZCBzb21lIHByb3RvY29sDQptZWNoYW5pc20gdG8ga25vdyBpZiB0aGUgb3RoZXIgc2lkZSBpcyBl eGVyY2lzaW5nIHRoaXMgbGV2ZWwgb2YNCmluY3JlYXNlZCBmbGV4aWJpbGl0eSBvciBub3QuIEkg Y2FuIGltYWdpbmUgYSBudW1iZXIgb2Ygb3B0aW9ucyBoZXJlDQooZS5nLiwgQUxQTikuICBXZSBj b3VsZCBhbHNvIGZvcmJpZCAxOk4gbWFwcGluZ3MgYnV0IEkgdGhpbmsgdGhhdA0Kd291bGQgYmUg YSBtaXN0YWtlIGFzIGl0J3MgYSBjb29sIGZlYXR1cmUvYmVuZWZpdCBvZiBkb2luZw0KdW5pZGly ZWN0aW9uYWwuDQoNClRoZSBlbnRpcmUgYmlkaXJlY3Rpb25hbCB3cmFwcGVyIHNoaW0gaXMgPCAx NTAgbGluZXMgb2YgR28gY29kZS4NCihodHRwczovL2dpdGh1Yi5jb20vZWtyL21pbnEvYmxvYi91 bmlkaXJlY3Rpb25hbF9zdHJlYW1zL2JpZGkuZ288aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ1cmxkZWZlbnNlLnByb29mcG9p bnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMtM0FfX25hMDEuc2FmZWxpbmtzLnByb3RlY3Rp b24ub3V0bG9vay5jb21fLTNGdXJsLTNEaHR0cHMtMjUzQS0yNTJGLTI1MkZnaXRodWIuY29tLTI1 MkZla3ItMjUyRm1pbnEtMjUyRmJsb2ItMjUyRnVuaWRpcmVjdGlvbmFsLTVGc3RyZWFtcy0yNTJG YmlkaS5nby0yNmRhdGEtM0QwMi0yNTdDMDEtMjU3Q21pY2hhZWwuYmlzaG9wLTI1NDBtaWNyb3Nv ZnQuY29tLTI1N0MxNGYwNzk4N2RhMGQ0YWZiOGU3NTA4ZDUwOTBmZjZmNi0yNTdDNzJmOTg4YmY4 NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDctMjU3QzEtMjU3QzAtMjU3QzYzNjQyNDg4NjU0NjQ4MTcx MC0yNnNkYXRhLTNEd3BzOUFXSzJmYWE4M045Ui0yNTJCREhvdmlnLTI1MkJ3ZjY4NFBTLTI1MkI1 UXc1RGd6WUg1SS0yNTNELTI2cmVzZXJ2ZWQtM0QwJTI2ZCUzRER3TUZhUSUyNmMlM0Q5NlpiWlpj YU1GNHcwRjRqcE42TFpnJTI2ciUzRERqbjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5f bTU1S1BtbG8lMjZtJTNEMENqMDRFanNqMlowOExJWmFRVmc4SmRKTGJmcS13ZTg5QzFDQjlDazVV SSUyNnMlM0Q3TzN2NUpoVFFaZFJ2NUFORWM1aFdVRXJuYXRlaTQ2ei1yTUpzSmI0d1JvJTI2ZSUz RCZkYXRhPTAyJTdDMDElN0NNaWNoYWVsLkJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NlN2Q4NjM2 NjEzZjE0NTAxMDRjZDA4ZDUwOWE1NDBjYSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzY0MjU1Mjc3MjMyNzAzNzMmc2RhdGE9YWg5WGlhNmZ3Mm9NOGl5b2R2 SlV1THRpcUd5RDN3MW5mMCUyRmJhWEM4YUpFJTNEJnJlc2VydmVkPTA+KS4NCkNvbnZlcnRpbmcg bXkgdGVzdCBhcHBsaWNhdGlvbiB0byB0aGlzIEFQSSB3YXMgYSBtYXR0ZXIgb2YganVzdA0KY2hh bmdpbmcgY2xhc3MgbmFtZXMsIGUuZy4sIHMvQ29ubmVjdGlvbmIvQ29ubmVjdGlvbjIvLg0KDQpJ biBteSBpbXBsZW1lbnRhdGlvbiwgSSBhc3N1bWUgdGhhdCBhdCB0aGUgdGltZSBNaW5xIGhlYXJz IGFib3V0IGENCnN0cmVhbSwgeW91IGtub3cgaWYgaXRzIHJlbGF0ZWQgdG8gYSBnaXZlbiBleGlz dGluZyBzdHJlYW0uICBUaGF0IHdheQ0KeW91IGNhbiBpbW1lZGlhdGVseSBlaXRoZXIgYXNzb2Np YXRlIGl0IHdpdGggdGhhdCBzdHJlYW0gb3IgbWFrZSBhIG5ldw0KbG9jYWwgc3RyZWFtLiBJbiBt eSBpbXBsZW1lbnRhdGlvbiwgSSBhbHdheXMgc2VuZCBSZWxhdGVkIFN0cmVhbSBJZA0KYW5kIGFz c3VtZSB0aGF0IHlvdSBuZXZlciBnZXQgYW4gInVucmVsYXRlZCIgc3RyZWFtIGZyYW1lIGJlZm9y ZSBhDQoicmVsYXRlZCIgb25lLiBUaGUgc3BlYyBkb2Vzbid0IHJlYWxseSByZXF1aXJlIHRoYXQg cmlnaHQgbm93LCBhbmQNCm9mZmxpbmUgTVQgc3VnZ2VzdGVkIGp1c3Qgc2VuZGluZyByZWxhdGVk IHdpdGggb2Zmc2V0PTAgYnV0IEkgdGhpbmsNCnRoYXQncyBhIG1pc3Rha2UsIGJlY2F1c2UgaXQg bWVhbnMgdGhhdCB5b3UgbmVlZCB0byBob2xkIHN0cmVhbSBmcmFtZXMNCmluIHNvbWUgcHJvdmlz aW9uYWwgInVuZGV0ZXJtaW5lZCIgc3RhdGUgdW50aWwgeW91IGdldCB0aGF0IGZyYW1lLiBJDQp3 b3VsZCBzdWdnZXN0IGluc3RlYWQgdGhhdCB3ZSByZXF1aXJlIHRoYXQgeW91IGluY2x1ZGUgdGhl IGZpZWxkIHVudGlsDQpvbmUgb2YgdGhlIGZyYW1lcyBpcyBBQ0tlZC4NCg0KDQpJTlRFUk5BTFMN ClNlbmRpbmcgYW5kIHJlY2VpdmluZyBzdHJlYW1zIHN0aWxsIHNoYXJlIGEgbG90IG9mIGNvbW1v biBjb21wb25lbnRzOg0KDQogICAgdHlwZSBiYXNlU3RyZWFtIHN0cnVjdCB7DQogICAgc3RhdGUg ICAgICAgICBzdHJlYW1TdGF0ZQ0KICAgIGlkICAgICAgICAgICAgdWludDMyDQogICAgbG9nICAg ICAgICAgICBsb2dnaW5nRnVuY3Rpb24NCiAgICBvZmZzZXQgICAgICAgIHVpbnQ2NA0KICAgIGNo dW5rcyAgICAgICAgW11zdHJlYW1DaHVuaw0KICAgIG1heFN0cmVhbURhdGEgdWludDY0DQogICAg aXNSZWxhdGVkICAgICBib29sDQogICAgcmVsYXRlZCAgICAgICB1aW50MzINCiAgICB9DQoNCiAg ICB0eXBlIHNlbmRTdHJlYW0gc3RydWN0IHsNCiAgICBiYXNlU3RyZWFtDQogICAgYmxvY2tlZCBi b29sDQogICAgfQ0KDQogICAgdHlwZSByZWN2U3RyZWFtIHN0cnVjdCB7DQogICAgYmFzZVN0cmVh bQ0KICAgIH0NCg0KTW9zdCBvZiB0aGlzIGlzIHRoZSBzYW1lIGFzIHdpdGggYmlkaXJlY3Rpb25h bCBzdHJlYW1zLiAgQXMgYWJvdmUsDQppdCdzIHByb2JhYmx5IHBvc3NpYmxlIHRvIG1ha2UgdGhl bSBtb3JlIGFzeW1tZXRyaWNhbC4NCg0KVGhlIGNvbm5lY3Rpb24gbWFpbnRhaW5zIHNlcGFyYXRl IGxpc3RzIG9mIHNlbmRpbmcgYW5kIHJlY2VpdmluZw0Kc3RyZWFtcyBhbmQgaXQncyBzdHJhaWdo dGZvcndhcmQgdG8gY3JlYXRlIGFuZCBhY2Nlc3MgdGhlbSB3aXRob3V0DQp3b3JyeWluZyBhYm91 dCB0aGUgb2RkL2V2ZW4gc3R1ZmYuDQoNCg0KQ09NUEFSSVNPTg0KQXQgdGhlIGVuZCBvZiB0aGUg ZGF5LCBJIHRoaW5rIHRoaXMgc2hvd3MgdGhhdCB0aGVzZSBkZXNpZ25zIGFyZW4ndA0KcmVhbGx5 IHRoYXQgZGlzc3NpbWlsYXIuIEkgd2FzIGFibGUgdG8gY29udmVydCBNaW5xIHRvIHVuaWRpcmVj dGlvbmFsDQpzdHJlYW1zIGluIGFib3V0IDE2IHRvdGFsIGhvdXJzIG9mIHdvcmsgKGJhc2ljYWxs eSBhIGxvbmcgcGxhbmUgZmxpZ2h0DQpwbHVzIHRoZSBuZXh0IG1vcm5pbmcpLiBXaGlsZSBJIGhh ZCB0byBtYWtlIGEgYnVuY2ggb2YgY2hhbmdlcyB0byB0aGUNCmludGVybmFsIHN0cnVjdHVyZXMs IGJhc2ljYWxseSBub25lIG9mIHRoZW0gbW9kaWZpZWQgYW55dGhpbmcgdHJpY2t5LA0KYW5kIGlu IHBhcnRpY3VsYXIgdGhlIGZsb3cgY29udHJvbCBtZWNoYW5pY3MgYW5kIHRoZSBsaWtlIGFyZQ0K YmFzaWNhbGx5IHVuY2hhbmdlZCwgZXhjZXB0IGZvciBhIGJ1bmNoIG9mIG1lY2hhbmljYWwtdHlw ZQ0KdHJhbnNmb3JtYXRpb25zIGxpa2UgcmVmZXJyaW5nIHRvIHxzZW5kU3RyZWFtLmNodW5rc3wg aW5zdGVhZCBvZg0KfHN0cmVhbS5zZW5kLmNodW5rc3wuIFRoZSBvbmx5IHJlYWxseSBuZXcgcHJv dG9jb2wgbWFjaGluZXJ5IGlzIHRoZQ0KbmV3IGZyYW1lIGZvcm1hdCBmb3IgcmVsYXRlZCBzdHJl YW1zLg0KDQpUaGVyZSBhcmUgYSBmZXcgcHJvcy9jb25zIHRoYXQgYXJlIHdvcnRoIG5vdGluZyBh Ym91dCB0aGVzZSBkZXNpZ25zLg0KDQotIFdpdGhvdXQgYSBiaWRpcmVjdGlvbmFsIEFQSSwgaGF2 aW5nIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgaXMgbW9yZQ0KICB3b3JrIGZvciB0aGUgcHJvZ3Jh bW1lci4gSG93ZXZlciwgd2l0aCBhbiBBUEkgc2hpbSwgdGhlIGRpZmZlcmVuY2UNCiAgaXMgdHJp dmlhbC4NCg0KLSBCZWNhdXNlIHVuZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmUgaW5oZXJlbnRseSBt b3JlIGZsZXhpYmxlLCBpdCdzDQogIHBvc3NpYmxlIGZvciB0aGUgc2lkZXMgdG8gdHJ5IHRvIHVz ZSBkaWZmZXJlbnQgbWFwcGluZ3MsIGUuZy4sIG9uZQ0KICBzaWRlIGV4cGVjdHMgcGFpcmVkIGFu ZCB0aGUgb3RoZXIgZXhwZWN0cyAxOk4uIFdlJ2xsIG5lZWQgc29tZSB3YXkNCiAgb2YgbWFraW5n IHN1cmUgdGhhdCBkb2Vzbid0IGhhcHBlbiwgbWF5YmUgQUxQTj8NCg0KLSBUaGUgIlJlbGF0ZWQg U3RyZWFtIElEIiBmcmFtZSBpbmRpY2F0b3IgbmVlZHMgZmxlc2hpbmcgb3V0IGEgYml0Lg0KICBG cm9tIHRoZSBhcHBsaWNhdGlvbidzIHBlcnNwZWN0aXZlLCBpdCBzaG91bGQgbmV2ZXIgaGVhciBh Ym91dCBhDQogIHN0cmVhbSB3aXRob3V0IGtub3dpbmcgaXRzIHJlbGF0ZWQgc3RhdHVzLiBBbmQg YXMgbm90ZWQgYWJvdmUsIEkNCiAgdGhpbmsgaXQgd291bGQgYmUgYmVzdCBpZiB3ZSByZXF1aXJl ZCB0aGF0IGFsbCAiZmlyc3QgZmxpZ2h0IiBzdHJlYW0NCiAgZnJhbWVzIHRoYXQgYXJlIHJlbGF0 ZWQgaW5jbHVkZSB0aGUgZmllZA0KDQotIFVuZGlyZWN0aW9uYWwgc3RyZWFtcyBraW5kIG9mIHNo YXJwZW4gdGhlIGNvbmZ1c2lvbiBhYm91dCBleGFjdGx5DQogIHdoYXQga2luZHMgb2YgImNsb3N1 cmUiIHdlIHdhbnQgdG8gYWxsb3cuIFNwZWNpZmljYWxseSwgd2hhdCBzaG91bGQNCiAgaW1wbGVt ZW50YXRpb25zIGJlIGFibGUgdG8gc2F5IGFib3V0IHRoZWlyIHdpbGxpbmduZXNzIHRvIHJlY2Vp dmU/DQogIFJpZ2h0IG5vdyB3ZSBoYXZlIFNUT1BfU0VORElORywgYnV0IHRoYXQgZG9lc24ndCBp bmZsdWVuY2UgdGhlDQogIHNlbmRlcidzIHN0YXRlLiBJIGRvbid0IHRoaW5rIHVuZGlyZWN0aW9u YWwgc3RyZWFtcyBtYWtlIHRoaXMgd29yc2UsDQogIHRoZXkganVzdCByZXF1aXJlIHVzIHRvIHRo aW5rIGl0IHRocm91Z2ggc29tZSBtb3JlLiBUaGV5IGRvIHNpbXBsaWZ5DQogIHRoZSBpbXBsZW1l bnRhdGlvbiBvZiB0aGUgY2xvc3VyZSBzdGF0ZSBtYWNoaW5lOiBpbiBteSBRVUlDLTA1IGNvZGUs DQogIHdoZW5ldmVyIG9uZSBzaWRlIGNsb3NlcyBJIGhhdmUgdG8gaGF2ZSBjaGVja3MgdG8gc2Vl IGlmIEkgc2hvdWxkIGJlDQogIHRyYW5zaXRpb25pbmcgdG8gQ0xPU0VEIG9yIEhBTEYtQ0xPU0VE LCBldGMsIHdoaWNoIGlzIG9kZCBiZWNhdXNlDQogIHRoZSBkaXJlY3Rpb25zIGFyZSBiYXNpY2Fs bHkgaW5kZXBlbmRlbnQuICBJdCB3b3VsZCBwcm9iYWJseSBiZQ0KICBlYXNpZXIgZXZlbiBpbiBR VUlDLTA1IG5vdCB0byByZWlmeSB0aGVzZSBzdGF0ZXMgYnV0IGp1c3QgdG8NCiAgZGV0ZXJtaW5l IHRoZSBzdGF0ZSBmcm9tIHRoZSBjb21wb3NpdGlvbiBvZiB0aGUgaW5kaXZpZHVhbA0KICBzdWIt c3RhdGVzDQoNCi0gVW5pZGlyZWN0aW9uYWwgc3RyZWFtcyBkb24ndCBuZWVkIHRoZSBraW5kIG9m IGFubm95aW5nIG9kZC1ldmVuDQogIG1lY2hhbmljcywgd2hpY2ggd2FzIGVhc2llciB0byBjb2Rl IHVwIChqdXN0IGhhdmluZyB0byBjcmVhdGUgYWxsDQogIHRoZSBsb3dlci1udW1iZXJlZCBzdHJl YW1zIG9mIHRoZSBzYW1lIHBhcml0eSBpcyBraW5kIG9mIGEgcGFpbikuDQogIE9uZSBhZGRpdGlv bmFsIGJlbmVmaXQgaGVyZSBpcyB0aGF0IHdpdGggUVVJQy0wNSB0aGVyZSBhcmUgc2V2ZXJhbA0K ICBtZXNzYWdlcyB3aGljaCBpbnZvbHZlIGltcGxpY2l0IHN0cmVhbSBjcmVhdGlvbiAoZS5nLiwN CiAgU1RSRUFNX01BWF9EQVRBLCBhbmQgUlNUX1NUUkVBTSkgYW5kIHNvIHlvdSBuZWVkIHRvIGNo ZWNrIHdoZXRoZXINCiAgdGhlIHN0cmVhbSBpcyBvbmUgdGhhdCBzaG91bGQgaGF2ZSBiZWVuIGNy ZWF0ZWQgbG9jYWxseSBvcg0KICByZW1vdGVseS4gVGhpcyBqdXN0IGRvZXNuJ3QgaGFwcGVuIHdp dGggYmlkaXJlY3Rpb25hbCBzdHJlYW1zOyBJIGRvDQogIGltcGxlbWVudCBvZGQvZXZlbiBtZWNo YW5pY3MgYnV0IGJlY2F1c2UgdGhlIG90aGVyIHNpZGUgaGFzIHRvIGhhdmUNCiAgaXRzIHN0cmVh bSBpZHMgaW5jcmVtZW50IGJ5IG9uZSwgSSBjYW4gbWFrZSBzdXJlIHRoYXQgdGhleSBoYXZlIHRo ZQ0KICByaWdodCBJRHMgYnkgY29uc3RydWN0aW9uIGFuZCBqdXN0IGNoZWNrIHRvIHNlZSBpZiB0 aGUgc3RyZWFtIGV4aXN0cw0KICBpbiB0aGVzZSBjYXNlcy4gIEknZCBsaWtlIHRvIHNlZSB1cyBn ZXQgcmlkIG9mIG9kZC9ldmVuIG5vIG1hdHRlcg0KICB3aGF0Lg0KDQotIFVuaWRpcmVjdGlvbmFs IHN0cmVhbXMgYWxzbyBoZWxwcyBhdm9pZCBzb21lIG9mIHRoZSBjb3JuZXIgY2FzZXMgYXJvdW5k DQogIGJpZGlyZWN0aW9uYWwgc3RyZWFtcy4gU3BlY2lmaWNhbGx5LCBzdXBwb3NlIEkgYW0gdGhl IGNsaWVudCBhbmQNCiAgSSBnZXQgTUFYX1NUUkVBTV9EQVRBIGFzIHRoZSBmaXJzdCBmcmFtZSBv biBzdHJlYW0gMi4gQW0gSSBhbGxvd2VkDQogIHRvIGp1c3Qgc3RhcnQgc2VuZGluZyBvciBub3Q/ IFlvdSBjYW4gc29ydCBvZiBnZXQgaW50byB0aGlzIHNpdHVhdGlvbg0KICB3aXRoIHVuaWRpcmVj dGlvbmFsIHN0cmVhbXMsIGJ1dCBiZWNhdXNlIGl0J3MgZXhwbGljaXQsIG9uZSBtaWdodA0KICBo b3BlIHRoYXQgdGhlIGFwcGxpY2F0aW9uIHNlbWFudGljcyB3b3VsZCByZXF1aXJlIGNsZWFyIHNw ZWNpZmljYXRpb24uDQoNCi0gQXMgbm90ZWQgYWJvdmUsIGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBh cmUgbW9yZSBmbGV4aWJsZSBiZWNhdXNlIHRoZXkNCiAgbGV0IHlvdSBoYXZlIG1hcHBpbmdzIHRo YXQgeW91IGNhbid0IGhhdmUgd2l0aCB1bmlkaXJlY3Rpb25hbA0KICBzdHJlYW1zICh1bnBhaXJl ZCwgMTpOKS4NCg0KDQpIYXBweSB0byBhbnN3ZXIgbW9yZSBxdWVzdGlvbnMgaWYgcGVvcGxlIGhh dmUgdGhlbS4gT3RoZXJ3aXNlIHdlIGNhbg0KdGFsayBhYm91dCB0aGlzIGluIFNlYXR0bGUuDQoN Ci1Fa3INCg0KDQpbMF0gaHR0cHM6Ly9naXRodWIuY29tL2Vrci9taW5xL3RyZWUvdW5pZGlyZWN0 aW9uYWxfc3RyZWFtczxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5j b20vP3VybD1odHRwcyUzQSUyRiUyRnVybGRlZmVuc2UucHJvb2Zwb2ludC5jb20lMkZ2MiUyRnVy bCUzRnUlM0RodHRwcy0zQV9fbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbV8t M0Z1cmwtM0RodHRwcy0yNTNBLTI1MkYtMjUyRmdpdGh1Yi5jb20tMjUyRmVrci0yNTJGbWlucS0y NTJGdHJlZS0yNTJGdW5pZGlyZWN0aW9uYWwtNUZzdHJlYW1zLTI2ZGF0YS0zRDAyLTI1N0MwMS0y NTdDbWljaGFlbC5iaXNob3AtMjU0MG1pY3Jvc29mdC5jb20tMjU3QzE0ZjA3OTg3ZGEwZDRhZmI4 ZTc1MDhkNTA5MGZmNmY2LTI1N0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0Ny0yNTdD MS0yNTdDMC0yNTdDNjM2NDI0ODg2NTQ2NDgxNzEwLTI2c2RhdGEtM0R4U2VTWFlHNE9DNmlUWmhp Y1ZnSDZxSlROclpFUWhhVUJjMFhSc3hpeXBBLTI1M0QtMjZyZXNlcnZlZC0zRDAlMjZkJTNERHdN RmFRJTI2YyUzRDk2WmJaWmNhTUY0dzBGNGpwTjZMWmclMjZyJTNERGpuM2JRNXVOSkRQTV8yc2tm TDNyVzF0emNJeHlqVVpkbl9tNTVLUG1sbyUyNm0lM0QwQ2owNEVqc2oyWjA4TElaYVFWZzhKZEpM YmZxLXdlODlDMUNCOUNrNVVJJTI2cyUzREJQTXZfdTZQb0FVeU5RVDZxUkJvOTFzX1BraGJhcGUz SmJLZTZxZFNnb1UlMjZlJTNEJmRhdGE9MDIlN0MwMSU3Q01pY2hhZWwuQmlzaG9wJTQwbWljcm9z b2Z0LmNvbSU3Q2U3ZDg2MzY2MTNmMTQ1MDEwNGNkMDhkNTA5YTU0MGNhJTdDNzJmOTg4YmY4NmYx NDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjQyNTUyNzcyMzI3MDM3MyZzZGF0YT1P Q3JiS3o4dHNoTWRUUTBhTWphZlJRREhHQzJPYmt0STJ1SW1vZlJZZCUyQnclM0QmcmVzZXJ2ZWQ9 MD4NClsxXSBodHRwczovL2dpdGh1Yi5jb20vZWtyL3dnLW1hdGVyaWFscy9ibG9iLzQwNDg5OGZh MmQyZjBhOWY5YmQyNDRkMmM5NDVlNjZlYTg4NTAyYTIvaW50ZXJpbS0xNy0xMC9VbmlkaXJlY3Rp b25hbCUyMFN0cmVhbXMlMjBpbiUyME1pbnEucGRmPGh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJv dGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBv aW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX19uYTAxLnNhZmVsaW5rcy5wcm90ZWN0 aW9uLm91dGxvb2suY29tXy0zRnVybC0zRGh0dHBzLTI1M0EtMjUyRi0yNTJGZ2l0aHViLmNvbS0y NTJGZWtyLTI1MkZ3Zy0yRG1hdGVyaWFscy0yNTJGYmxvYi0yNTJGNDA0ODk4ZmEyZDJmMGE5Zjli ZDI0NGQyYzk0NWU2NmVhODg1MDJhMi0yNTJGaW50ZXJpbS0yRDE3LTJEMTAtMjUyRlVuaWRpcmVj dGlvbmFsLTI1MjUyMFN0cmVhbXMtMjUyNTIwaW4tMjUyNTIwTWlucS5wZGYtMjZkYXRhLTNEMDIt MjU3QzAxLTI1N0NtaWNoYWVsLmJpc2hvcC0yNTQwbWljcm9zb2Z0LmNvbS0yNTdDMTRmMDc5ODdk YTBkNGFmYjhlNzUwOGQ1MDkwZmY2ZjYtMjU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3LTI1N0MxLTI1N0MxLTI1N0M2MzY0MjQ4ODY1NDY0ODE3MTAtMjZzZGF0YS0zRFotMjUyQklO T2tBQXZiWHdZN1l1d2FQajBmMXlSWFk3Uzc5QWtELTI1MkZ2SEdwd0xvUS0yNTNELTI2cmVzZXJ2 ZWQtM0QwJTI2ZCUzRER3TUZhUSUyNmMlM0Q5NlpiWlpjYU1GNHcwRjRqcE42TFpnJTI2ciUzRERq bjNiUTV1TkpEUE1fMnNrZkwzclcxdHpjSXh5alVaZG5fbTU1S1BtbG8lMjZtJTNEMENqMDRFanNq MlowOExJWmFRVmc4SmRKTGJmcS13ZTg5QzFDQjlDazVVSSUyNnMlM0RVSlVVNDF1Q3dINEpLVGRO eVpTLVc2MGp6bjdodHVsWHpGdUVXbW9qaHVJJTI2ZSUzRCZkYXRhPTAyJTdDMDElN0NNaWNoYWVs LkJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0NlN2Q4NjM2NjEzZjE0NTAxMDRjZDA4ZDUwOWE1NDBj YSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY0MjU1Mjc3 MjMyNzAzNzMmc2RhdGE9NXRBZlpZSjZ0aW94ZlNDWTh4ZFVveG1ybE5WM1ZaRDczTW1OJTJCRE54 eVh3JTNEJnJlc2VydmVkPTA+DQpbMl0gVGhhbmtzIHRvIFBhdHJpY2sgTWNNYW51cyBmb3Igc3Vn Z2VzdGluZyB0aGlzIGRlc2lnbi4NClszXSBJbiBDKyssIHlvdSB3b3VsZCBoYXZlIGEgc2luZ2xl IGZ1bmN0aW9uIHdpdGggYSBkZWZhdWx0IGFyZ3VtZW50IG9mDQogICAgfG51bGxwdHJ8IGJ1dCBH byBkb2Vzbid0IHN1cHBvcnQgdGhhdCwgaGVuY2UgdHdvIGRpZmZlcmVudCBhcmd1bWVudHMuDQpb NF0gRm9yIGltcGxlbWVudGF0aW9uIHJlYXNvbnMsIGl0J3MgYWN0dWFsbHkgdXNpbmcgQ29ubmVj dGlvbiBhcyBhIG1peGluLA0KICAgIHdoaWNoIG1lYW5zIGl0J3Mgc2ltdWx0YW5lb3VzbHkgcG9z c2libGUgdG8gdXNlIHRoZSB1bmlkaXJlY3Rpb25hbA0KICAgIGFuZCBiaWRpcmVjdGlvbmFsIEFQ SXMsIGJ1dCB0aGF0J3MgZ29pbmcgdG8gY2F1c2UgYSBsb3Qgb2YgY29uZnVzaW9uLg0KICAgIEEg cmVhbCBpbXBsZW1lbnRhdGlvbiB3b3VsZCBwcm9iYWJseSBoYXZlIHRvIGVpdGhlciBjb21taXQg dG8gb25lDQogICAgb3IgdGhlIG90aGVyIG9yIGRvIGEgcmVhbCB3cmFwcGVyLCBzbyB5b3UgY291 bGQgb25seSB1c2Ugb25lIHNldCBvZg0KICAgIEFQSXMsIGF0IHRoZSBjb3N0IG9mIGhhdmluZyB0 byBkbyBtb3JlIGZvcndhcmRlZCBtZXRob2RzLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQo= --_000_b6ca3e39c94e44c2ad1987d5ea90078eusma1exdag1mb5msgcorpak_ 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 emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAubTg5NTIx NDUzMjU4MjI1MTE2NjZtMzQ0ODU5ODY2MDM2ODE1MDI0OW0tNjQyMjcyODI2ODgwNDI0OTk1OWFp cm1haWxvbiwgbGkubTg5NTIxNDUzMjU4MjI1MTE2NjZtMzQ0ODU5ODY2MDM2ODE1MDI0OW0tNjQy MjcyODI2ODgwNDI0OTk1OWFpcm1haWxvbiwgZGl2Lm04OTUyMTQ1MzI1ODIyNTExNjY2bTM0NDg1 OTg2NjAzNjgxNTAyNDltLTY0MjI3MjgyNjg4MDQyNDk5NTlhaXJtYWlsb24NCgl7bXNvLXN0eWxl LW5hbWU6bV84OTUyMTQ1MzI1ODIyNTExNjY2bV8zNDQ4NTk4NjYwMzY4MTUwMjQ5bS02NDIyNzI4 MjY4ODA0MjQ5OTU5YWlybWFpbG9uOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdp bi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6 MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFu LkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFua3MsIE1pa2UuJm5ic3A7IEluZGVlZCwgSSB0aG91Z2h0IHRoZSBpdCB3YXMgcHJvcG9z ZWQgZm9yIHRoZSBzZW5kZXIgdG8gc2VuZCBSRVNFVF9TVFJFQU0gaW4gdGhlIHNhbWUgZnJhbWUg YXMgU1RSRUFNKG9mZj0wfEZJTikgKGFuZCBsZW4mZ3Q7MCkuICZuYnNwO1llcywgU1RSRUFNKG9m Zj0wfGxlbj0wfEZJTikgaXMgZXF1aXZhbGVudCB0byBSRVNFVF9TVFJFQU0sIGFzIGZhciBhcyB0 cmFuc3BvcnQgc3RhdGUgaXMgY29uY2VybmVkDQogKGJ1dCBpdCBtYXkgaGF2ZSBhIGRpZmZlcmVu dCBBUEkgZWZmZWN0IOKAkyBhIGRpZmZlcmVudCBjYWxsYmFjayBjYWxsZWQpLjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8 L2I+IE1pa2UgQmlzaG9wIFttYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbV0NCjxi cj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE9jdG9iZXIgMDIsIDIwMTcgMTI6MDggUE08YnI+DQo8 Yj5Ubzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs7IEx1YmFzaGV2LCBJ Z29yICZsdDtpbHViYXNoZUBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gcXVpY0BpZXRm Lm9yZzsgbWlra2VsZmpAZ21haWwuY29tPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBSZXBvcnQg b24gVW5pZGlyZWN0aW9uYWwgU3RyZWFtcyBpbiBNaW5xPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIHRoaW5rIHlvdeKAmXJlIHRhbGtpbmcgcGFzdCBlYWNoIG90aGVy LiZuYnNwOyBJZ29yLCB0aGUgZHJhZnQgY3VycmVudGx5IHNheXMgdGhhdCBSU1RfU1RSRUFNIGFw cGxpZXMgdG8gdGhlIHNlbmRlcuKAmXMgZGlyZWN0aW9uIG9ubHksIHNvIHNlbmRpbmcgYSBSU1Rf U1RSRUFNIGRvZXNu4oCZdCBoZWxwIGFueXRoaW5nLiZuYnNwOyBUaGUgb3RoZXIgc2lkZSBjb3Vs ZCByZWFzb25hYmx5IHNlbmQgUlNUX1NUUkVBTSBvciB0aGUgU1RSRUFNLUZJTiwNCiBhbmQgdGhl eeKAmXJlIGlkZW50aWNhbCBmb3IgYWxsIHByYWN0aWNhbCBwdXJwb3Nlcy4mbmJzcDsgVGhlIHBv aW50IGlzIHRoYXQgb25lIHNpZGUgaXMgc2VuZGluZyBhbGwgdGhlIGRhdGEsIGJ1dCB0aGUgb3Ro ZXIgc2lkZSBzdGlsbCBoYXMgdG8gYWNrIG9uIHRoZSBzdHJlYW0gZm9yIGl0IHRvIHJlYWNoIHRo ZSBjbG9zZWQgc3RhdGUuJm5ic3A7IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgZG9u4oCZdCByZXF1 aXJlIGFueSBwZXItc3RyZWFtIGFjdGlvbiBieSB0aGUgcmVjZWl2ZXINCiB0byBjb21wbGV0ZSB0 aGUgc3RhdGUgbWFjaGluZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IEVy aWMgUmVzY29ybGEgWzxhIGhyZWY9Im1haWx0bzpla3JAcnRmbS5jb20iPm1haWx0bzpla3JAcnRm bS5jb208L2E+XQ0KPGJyPg0KPGI+U2VudDo8L2I+IE1vbmRheSwgT2N0b2JlciAyLCAyMDE3IDc6 NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IEx1YmFzaGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86 aWx1YmFzaGVAYWthbWFpLmNvbSI+aWx1YmFzaGVAYWthbWFpLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+ Q2M6PC9iPiBNaWtlIEJpc2hvcCAmbHQ7PGEgaHJlZj0ibWFpbHRvOk1pY2hhZWwuQmlzaG9wQG1p Y3Jvc29mdC5jb20iPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OzsNCjxhIGhy ZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj5xdWljQGlldGYub3JnPC9hPjsgPGEgaHJlZj0ibWFp bHRvOm1pa2tlbGZqQGdtYWlsLmNvbSI+DQptaWtrZWxmakBnbWFpbC5jb208L2E+PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFJlOiBSZXBvcnQgb24gVW5pZGlyZWN0aW9uYWwgU3RyZWFtcyBpbiBNaW5x PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBNb24sIE9jdCAyLCAyMDE3IGF0IDQ6MjcgQU0sIEx1YmFz aGV2LCBJZ29yICZsdDs8YSBocmVmPSJtYWlsdG86aWx1YmFzaGVAYWthbWFpLmNvbSIgdGFyZ2V0 PSJfYmxhbmsiPmlsdWJhc2hlQGFrYW1haS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwv cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0ND Q0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFy Z2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jmd0OyBO aXQ6IENhbid0IHlvdSBzZW5kIFJFU0VUX1NUUkVBTTxicj4NCjxicj4NCkkgZG8gbm90IHRoaW5r IHRoaXMgaXMgYW4gb3B0aW9uLCBzaW5jZSBSRVNFVF9TVFJFQU0gbWF5IHByZXZlbnQgZGF0YSBi dWZmZXJlZCBieSB0aGUgdHJhbnNwb3J0IGZyb20gYmVpbmcgZGVsaXZlcmVkIHRvIHRoZSBhcHBs aWNhdGlvbi48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhvc2UgYXJlIGFsc28gdGhlIHNlbWFudGlj cyBvZiBTVFJFQU0ob2Zmc2V0PTAsIEZJTikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0ND Q0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5JIGFtIGxl c3MgY29uY2VybmVkIGFib3V0IGhvdyBsb25nIGNvbm5lY3Rpb24gc3RhdGUgaGFzIHRvIGJlIGtl cHQgYXJvdW5kIC0tIGluIGEgY29vcGVyYXRpbmcgcGVlciBzaXR1YXRpb24sIHRoaXMgaXMgb25l IHJ0dCwgd2hpY2ggaXMgdGhlIHNhbWUgYW1vdW50IG9mIHRpbWUgdGhhdCBpcyByZXF1aXJlZCB0 byB3YWl0IGZvciBhbiBBQ0suIEEgbWFsaWNpb3VzIHBlZXINCiBjb3VsZCB3aXRoaG9sZCBBQ0tz IGZvciBwYWNrZXRzIHdpdGggU1RSRUFNJiM0MztGSU4uIFRoZSBiaWRpcmVjdGlvbmFsIHByb3Rv Y29sIGlzIG1vcmUgY2hhdHR5LCB0aG91Z2guPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxicj4N Cjxicj4NCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tIDxicj4NCjxiPkZyb206PC9iPiBFcmlj IFJlc2NvcmxhIFs8YSBocmVmPSJtYWlsdG86ZWtyQHJ0Zm0uY29tIiB0YXJnZXQ9Il9ibGFuayI+ ZWtyQHJ0Zm0uY29tPC9hPl08YnI+DQo8Yj5SZWNlaXZlZDo8L2I+IFN1bmRheSwgMDEgT2N0IDIw MTcsIDU6MjlQTTxicj4NCjxiPlRvOjwvYj4gTWlrZSBCaXNob3AgWzxhIGhyZWY9Im1haWx0bzpN aWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNo b3BAbWljcm9zb2Z0LmNvbTwvYT5dPGJyPg0KPGI+Q0M6PC9iPiBNaWtrZWwgRmFobsO4ZSBKw7hy Z2Vuc2VuIFs8YSBocmVmPSJtYWlsdG86bWlra2VsZmpAZ21haWwuY29tIiB0YXJnZXQ9Il9ibGFu ayI+bWlra2VsZmpAZ21haWwuY29tPC9hPl07IElFVEYgUVVJQyBXRyBbPGEgaHJlZj0ibWFpbHRv OnF1aWNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5xdWljQGlldGYub3JnPC9hPl08YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gUmU6IFJlcG9ydCBvbiBVbmlkaXJlY3Rpb25hbCBTdHJlYW1zIGluIE1p bnE8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFN1biwgT2N0IDEsIDIwMTcgYXQgMjoxOSBQTSwgTWlr ZSBCaXNob3AgJmx0OzxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29t IiB0YXJnZXQ9Il9ibGFuayI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvYT4mZ3Q7IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJn aW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+SSB0aGlu ayB0aGUgZGlmZmVyZW5jZSBpcyBmb3IgdGhlIHNjZW5hcmlvIHdoZXJlIHlvdSBkb27igJl0IGV4 cGVjdCBhIHBlZXIgdG8gcmVzcG9uZCAob3IgZG9u4oCZdCBleHBlY3QgdGhlbSB0byByZXNwb25k IHN0cmVhbS1ieS1zdHJlYW0pLiZuYnNwOyBXaXRoIC0wNSwgdGhlIHJlY2VpdmVyIHN0aWxsIG5l ZWRzIHRvIHNlbmQNCiBTVFJFQU0ob2Zmc2V0PTAsRklOKSBvbiBlYWNoIHN0cmVhbS48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5OaXQ6IENhbid0IHlvdSBzZW5kIFJFU0VUX1NUUkVBTT88bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2lu LWxlZnQ6NC44cHQ7bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0 b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBX aXRoIGVpdGhlciB1bmlkaXJlY3Rpb25hbCBwcm9wb3NhbCwgdGhpcyBwYXR0ZXJuIGlzIGEgYml0 IGNsZWFuZXIuJm5ic3A7IEluICM2NTYsIHRoZSBzZW5kZXIgY2FuIGVzc2VudGlhbGx5IHNheSwg 4oCcRG9u4oCZdCBib3RoZXLigJ0gYXQgdGhlIHRpbWUgb2Ygc3RyZWFtIGNyZWF0aW9uLiZuYnNw OyBJbiAjNjQzLCB0aGVyZeKAmXMNCiBubyBjb3JyZXNwb25kaW5nIGNoYW5uZWwgdG8gY2xvc2Uu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+WWVzLCBJIGFncmVlIHRoYXQgdGhpcyBpcyBjbGVhbmVyLiBO b3RlIHRoYXQgaW4gIzY0MyB5b3UgcHJlc3VtYWJseSBuZWVkIHRvIGhhdmUgc29tZSB3YXkgb2Yg c2lnbmFsaW5nIHRoYXQgeW91IGRvbid0IHdhbnQgYSByZXR1cm4gY29ubmVjdGlvbi4uLi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBw dDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1yaWdodDowaW47bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ SW4gYWxsIGNhc2VzLCB0aGUgb25seSB0aGluZyB0aGF0IHJlYWxseSBsaW1pdHMgeW91IGlzIHRo ZSBwZWVy4oCZcyB3aWxsaW5nbmVzcyB0byBpbmNyZWFzZSB5b3VyIE1BWF9TVFJFQU1fSUQsIGl0 4oCZcyBqdXN0IGEgcXVlc3Rpb24gb2YgaG93IGNoYXR0eSB5b3UgaGF2ZSB0byBiZSDigJMgd2hp Y2ggY2FuIG1hdHRlcg0KIGlmIHRoZXNlIG1lc3NhZ2VzIGFyZSBmYWlybHkgc21hbGwuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+QWdyZWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4tRWtyPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2Nr cXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7 cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tdG9wOjUu MHB0O21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxiPkZyb206PC9iPiBRVUlDIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOnF1 aWMtYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPnF1aWMtYm91bmNlc0BpZXRmLm9y ZzwvYT5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkVyaWMgUmVzY29ybGE8YnI+DQo8Yj5TZW50Ojwv Yj4gU3VuZGF5LCBPY3RvYmVyIDEsIDIwMTcgMjowMyBQTTxicj4NCjxiPlRvOjwvYj4gTWlra2Vs IEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1pa2tlbGZqQGdtYWlsLmNv bSIgdGFyZ2V0PSJfYmxhbmsiPm1pa2tlbGZqQGdtYWlsLmNvbTwvYT4mZ3Q7PGJyPg0KPGI+Q2M6 PC9iPiBJRVRGIFFVSUMgV0cgJmx0OzxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIiB0YXJn ZXQ9Il9ibGFuayI+cXVpY0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJl OiBSZXBvcnQgb24gVW5pZGlyZWN0aW9uYWwgU3RyZWFtcyBpbiBNaW5xPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JJ20gbm90IHN1cmUgSSBoYXZlIGFu eSB1c2VmdWwgaW5zaWdodHMgb24gdGhpcywgYXMgbXkgaW1wbGVtZW50YXRpb24gaGFuZGxlcyB0 aGVtIG1vcmUgb3IgbGVzcyB0aGUgc2FtZS4gQ2FuIHlvdSBleHBsYWluIHdoeSB5b3UgdGhpbmsg dGhpcyB3b3VsZCBiZSBkaWZmZXJlbnQgd2l0aCB1bmlkaXJlY3Rpb25hbA0KIHZlcnN1cyBiaWRp cmVjdGlvbmFsPzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5PbiBTdW4sIE9jdCAxLCAyMDE3IGF0IDE6MzggUE0sIE1pa2tlbCBGYWhu w7hlIErDuHJnZW5zZW4gJmx0OzxhIGhyZWY9Im1haWx0bzptaWtrZWxmakBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5taWtrZWxmakBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAj Q0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7 bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXYgaWQ9Im1fODk1MjE0NTMyNTgyMjUxMTY2Nm1fMzQ0ODU5ODY2MDM2ODE1MDI0 OW1fLTY0MjI3MjgyNjg4MDQyNDk5NTlibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyw8L3NwYW4+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fODk1MjE0NTMyNTgyMjUxMTY2Nm1fMzQ0ODU5ODY2MDM2ODE1 MDI0OW1fLTY0MjI3MjgyNjg4MDQyNDk5NTlibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV84OTUyMTQ1MzI1ODIyNTExNjY2bV8zNDQ4NTk4NjYwMzY4 MTUwMjQ5bV8tNjQyMjcyODI2ODgwNDI0OTk1OWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SSBvbmx5IHNraW1tZWQgdGhpcyBzdXBl cmZhc3QsIGJ1dCBvbmUgdGhlIG9ic2VydmF0aW9ucyBhcHBlYXIgdG8gbm90IGNvdmVyIG9uZSBv ZiBteSBrZXkgcG9pbnRzOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0i bV84OTUyMTQ1MzI1ODIyNTExNjY2bV8zNDQ4NTk4NjYwMzY4MTUwMjQ5bV8tNjQyMjcyODI2ODgw NDI0OTk1OWJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IGlk PSJtXzg5NTIxNDUzMjU4MjI1MTE2NjZtXzM0NDg1OTg2NjAzNjgxNTAyNDltXy02NDIyNzI4MjY4 ODA0MjQ5OTU5Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5Zb3UgY2FuIGNyZWF0ZSBhbmQgY2xvc2UgdW5pLXN0cmVhbXMgYXQgYXQg dmVyeSBoaWdoIHJhdGUgb2YgbWFueSBzdHJlYW1zIHBlciBwYWNrZXQsIHdpdGhvdXQgd2FpdGlu ZyBmb3IgcGVlcg0KIHJlc3BvbnNlLCBhc3N1bWluZyB0aGUgQUNLIGZyYW1ld29yayBoYW5kbGVz IHJldHJhbnNtaXNzaW9uLiBBbnkgaW5zaWdodHMgb24gdGhpcz88L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2IGlkPSJtXzg5NTIxNDUzMjU4MjI1MTE2NjZtXzM0NDg1OTg2NjAzNjgxNTAyNDltXy02 NDIyNzI4MjY4ODA0MjQ5OTU5Ymxvb3Bfc2lnbl8xNTA2ODkwMTgzMzU4OTY1NzYwIj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5LaW5kIFJlZ2FyZHMs PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0ibTg5NTIxNDUzMjU4MjI1MTE2 NjZtMzQ0ODU5ODY2MDM2ODE1MDI0OW0tNjQyMjcyODI2ODgwNDI0OTk1OWFpcm1haWxvbiI+DQpP biAxIE9jdG9iZXIgMjAxNyBhdCAyMi4zMi4wMiwgRXJpYyBSZXNjb3JsYSAoPGEgaHJlZj0ibWFp bHRvOmVrckBydGZtLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPmVrckBydGZtLmNvbTwvYT4pIHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5IaSBmb2xrcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIHByb21pc2VkIEkgc3BlbnQgYSBidW5jaCBvZiB0 aW1lIGhhY2tpbmcgdW5pZGlyZWN0aW9uYWwgc3RyZWFtczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pbnRvIE1pbnEgYW5kIEknbSBoZXJlIHRv IHJlcG9ydCBiYWNrIFswXS4gU3BlY2lmaWNhbGx5LCBJPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmltcGxlbWVudGVkOjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IC0gUFIj NjQzIC0tIFVuaWRpcmVjdGlvbmFsIFN0cmVhbXM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IC0gUFIjNzIwIC0tIEFkZCBiaWRpcmVj dGlvbmFsIHN0cmVhbXMgb24gdG9wIG9mIHVuaWRpcmVjdGlvbmFsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAtIEEgYmlkaXJlY3Rp b25hbCBzdHJlYW0gQVBJIHRoYXQgbW9zdGx5IG1pbWljcyBNaW5xJ3Mgb3JpZ2luYWwgQVBJPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OyAmbmJzcDsgZm9yIC0wNS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5UaGUgZm9sbG93aW5nIGlzIGtpbmQgb2Yg YSB3YWxsIG9mIHRleHQsIHNvIHlvdSBjb3VsZCBhbHNvIHNraXAgdGhpczxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5hbmQgcmVmZXIgdG8gbXkg c2xpZGVzIFsxXS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj5NSU5RJ1MgLTA1IEFSQ0hJVEVDVFVSRTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5BUEk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWlucSdzIG1hc3RlciBvYmpl Y3QgaXMgdGhlIENvbm5lY3Rpb24sIHdoaWNoIGhhcyBhIGxpc3Qgb2YgU3RyZWFtczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pbmRleGVkIGJ5 IHN0cmVhbSBJRC4gQXBwbGljYXRpb25zIHJlZ2lzdGVyIGEgaGFuZGxlciB3aXRoIHRoZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5jb25uZWN0 aW9uIHRvIGJlIG5vdGlmaWVkIG9mIG5ldyBldmVudHMuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7dHlwZSBDb25u ZWN0aW9uSGFuZGxlciBpbnRlcmZhY2UgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IC8vIFRoZSBjb25uZWN0aW9uIGhh cyBjaGFuZ2VkIHN0YXRlIHRvIHN0YXRlIHxzfDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IFN0YXRlQ2hhbmdlZChzIFN0 YXRlKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgLy8gQSBuZXcgc3RyZWFtIGhhcyBiZWVuIGNyZWF0 ZWQgKGJ5IHJlY2VpdmluZyBhIGZyYW1lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgLy8gZnJvbSB0aGUgb3RoZXIgc2lk ZS4gfHN8IGNvbnRhaW5zIHRoZSBzdHJlYW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgTmV3U3RyZWFtKHMgKlN0cmVh bSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ Jm5ic3A7ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IC8vIFN0cmVhbSB8c3wgaXMgbm93IHJlYWRhYmxlLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7IFN0cmVhbVJlYWRhYmxlKHMgKlN0cmVhbSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO308bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlN0cmVhbXMg Z2V0IGNyZWF0ZWQgaW4gdHdvIHdheXM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIExvY2FsbHkgdmlhIENvbm5lY3Rpb24uQ3JlYXRl U3RyZWFtKCk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+LSBSZW1vdGVseSwgaW4gd2hpY2ggY2FzZSB0aGUgYXBwbGljYXRpb24gaXMgbm90aWZp ZWQgdmlhIGEgY2FsbGJhY2sgdG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IENvbm5lY3Rpb25IYW5kbGVyLk5ld1N0cmVhbSgpLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ U3RyZWFtcyB0aGVtc2VsdmVzIGhhdmUgdGhlIEFQSXMgeW91IHdvdWxkIGV4cGVjdCwgbmFtZWx5 LCBSZWFkKCksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPldyaXRlKCksIENsb3NlKCksIFJlc2V0KCksIGV0Yy4gWW91IGdldCBub3RpZmllZCBv ZiBzdHJlYW0gcmVhZGFiaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+YnkgYSBjYWxsYmFjayB0byBDb25uZWN0aW9uSGFuZGxlci5TdHJl YW1SZWFkYWJsZSgpLCBhdCB3aGljaCBwb2ludDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj55b3UgY2FuIGRvIFN0cmVhbS5SZWFkKCkuIEFzIGV4 cGVjdGVkLCBTdHJlYW0uUmVhZCgpIHJldHVybnM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+V09VTERCTE9DSyB3aGVuIG5vIGRhdGEgaWEgYXZh aWxhYmxlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+SU5URVJOQUxTPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPkFzIG5vdGVkIGFib3ZlLCB3ZSBzdGFydCB3aXRoIHRoZSBDb25u ZWN0aW9uIG9iamVjdCAob25seSByZWxldmFudCBmaWVsZHM8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+c2hvd24pOjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO3R5 cGUgQ29ubmVjdGlvbiBzdHJ1Y3QgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IGhhbmRsZXImbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IENvbm5lY3Rpb25IYW5kbGVyPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgc3RyZWFtcyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW10qU3RyZWFtPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgbWF4 U3RyZWFtJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVpbnQzMjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vdXRwdXRDbGVhclEmbmJzcDsg Jm5ic3A7ICZuYnNwO1tdZnJhbWUgLy8gRm9yIHN0cmVhbSAwPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPm91dHB1dFByb3RlY3RlZFEgW11mcmFt ZSAvLyBGb3Igc3RyZWFtICZndDs9IDA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIHlvdSBjYW4gc2VlLCBzdHJl YW1zIGFyZSBpbiBhbiBhcnJheSBzbGljZSwgc28gdGhleSdyZSBjb250aWd1b3VzbHk8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aW5kZXhlZCBi eSBzdHJlYW0gSUQuIFJpZ2h0IG5vdywgSSBoYXZlIG5vIHByb3Zpc2lvbiBmb3IgcmVjbGFpbWlu ZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50 aGUgdW51c2VkIGJvdHRvbSBwYXJ0IG9mIHRoZSBhcnJheSwgYnV0IGl0IHdvdWxkIGJlIHN0cmFp Z2h0Zm9yd2FyZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj50byBpbmRleCBieSB8c3RyZWFtSWR8IC0gfG1pblN0cmVhbXwsIHdoaWNoIEkgdGhp bmsgaXMgY29uc2lzdGVudCB3aXRoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPnRoZSBkZXNpZ24gaW1wbGllZCBieSB0aGUgcmVxdWlyZW1lbnQg dG8gY3JlYXRlIHN0cmVhbXMgaW4gc2VxdWVuY2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5CZWNhdXNlIFN0cmVhbXMgYXJlIGJpZGly ZWN0aW9uYWwsIGVhY2ggc3RyZWFtIGFjdHVhbGx5IGNvbnNpc3RzIG9mIGE8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+cGFpciBvZiBoYWxmIHN0 cmVhbXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDsgJm5ic3A7dHlwZSBzdHJlYW1IYWxmIHN0cnVjdCB7PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsg cyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOypzdHJlYW0m bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOy8vIHBvaW50ZXIgdG8gcGFy ZW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyAmbmJzcDsgbG9nJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtsb2dnaW5nRnVuY3Rpb24mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgZGlyJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtkaXJlY3Rpb24mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7Ly8gU2VuZGluZyBvciByZWNlaXZpbmc8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBjbG9zZWQm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgYm9vbCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAvLyBJcyB0aGUgaGFsZi1zdHJlYW0gY2xvc2VkPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAm bmJzcDsgb2Zmc2V0Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHVpbnQ2NCZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8vIFRoZTxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IGNodW5rcyZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBbXXN0cmVhbUNodW5rPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgbWF4U3Ry ZWFtRGF0YSB1aW50NjQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsvLyBJbnRlcm5hbCBvYmpl Y3QgdG8gYWxsb3cgdW5pdCB0ZXN0aW5nLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7dHlwZSBzdHJlYW0gc3RydWN0IHs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7ICZuYnNwOyBpZCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt1aW50MzI8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwOyBsb2cmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbG9nZ2luZ0Z1bmN0aW9uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OyAmbmJzcDsgc3RhdGUmbmJzcDsgJm5ic3A7ICZuYnNwOyBzdHJlYW1TdGF0ZTxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 IHNlbmQsIHJlY3YgKnN0cmVhbUhhbGY8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IGJsb2NrZWQmbmJzcDsgJm5ic3A7IGJvb2wgLy8g SGF2ZSB3ZSByZXR1cm5lZCBibG9ja2VkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt9PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7Ly8gUHVi bGljIEFQSSBvYmplY3QsIHdoaWNoIG5lZWRzIGFjY2VzcyB0byB0aGUgQ29ubmVjdGlvbjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg Jm5ic3A7dHlwZSBTdHJlYW0gc3RydWN0IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBjICpDb25uZWN0aW9uPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAm bmJzcDsgc3RyZWFtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PdXRnb2luZyBkYXRhIGlzIGVucXVldWVkIGludG8g fHN0cmVhbS5jaHVua3N8LCBhbmQgdGhlbiBwZXJpb2RpY2FsbHk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dGhlIGNvbm5lY3Rpb24gcG9sbHMg dGhlIHN0cmVhbSBmb3IgYWxsIHRoZSBjaHVua3Mgd2hpY2ggYXJlIHBlcm1pdHRlZDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5ieSBzdHJlYW0t bGV2ZWwgZmxvdyBjb250cm9sIGFuZCBlbnF1ZXVlcyB0aGVtIGludG88bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+fENvbm5lY3Rpb24ub3V0cHV0 Q2xlYXJRfCBvciB8Q29ubmVjdGlvbi5vdXRwdXRQcm90ZWN0ZWRRfC4gQXQgdGhpczxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5wb2ludCwgdGhl IGNvbm5lY3Rpb24gb3ducyB0aGUgZGF0YSBhbmQgaXMgcmVzcG9uc2libGUgZm9yPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnRyYW5zbWl0dGlu ZyBpdCwgc3ViamVjdCB0byBjb25uZWN0aW9uLWxldmVsIGZsb3cgY29udHJvbCwgYW5kPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPihwcmVzdW1h Ymx5KSBjb25nZXN0aW9uIGNvbnRyb2wgb25jZSBJIGhhdmUgdGhhdCBpbXBsZW1lbnRlZCBbMl0u PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5JbmNvbWluZyBkYXRhIGdldHMgcXVldWVkIChzb3J0ZWQpIGludG8gfHN0cmVhbS5jaHVua3N8 IGZvciBsYXRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5yZWFzc2VtYmx5IGF0IHRoZSB0aW1lIHdoZW4gc29tZW9uZSBjYWxscyBzdHJlYW0u cmVhZCgpLiBJJ20gbm90IHN1cmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+SSBsb3ZlIHRoaXMsIGJlY2F1c2UgaXQgbWVhbnMgSSBkb24ndCBo YXZlIGEgZ29vZCB2aWV3IG9mIHRoZSBpbmNvbWluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5xdWV1ZSBzaXplICh3aGljaCBJJ2QgbmVlZCB0 byBhY2NvdW50IGZvciBzZXBhcmF0ZWx5KSwgYnV0IGl0IGFsbG93ZWQ8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+bWUgdG8gc2hhcmUgZGF0YSBz dHJ1Y3R1cmVzIGJldHdlZW4gaW5jb21pbmcgYW5kIG91dGdvaW5nLCB3aGljaDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zZWVtZWQga2luZCBv ZiBuYXR1cmFsIHdoZW4gSSBkaWQgaXQgKHRoaXMgYXJjaGl0ZWN0dXJlIGlzIHJlcGxpY2F0ZWQ8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aW4g dGhlIHVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgZGVzaWduLCBidXQgaXQncyBwcm9iYWJseSBsZXNz IG5hdHVyYWw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+dGhlcmUpLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPlVOSURJUkVDVElPTkFMIFNUUkVBTVMgQVJDSElURUNUVVJFPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlVOSURJ UkVDVElPTkFMIEFQSTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5XaXRoIHRoZSB1bmlkaXJlY3Rpb25hbCBicmFuY2gsIE1pbnEgb2ZmZXJzIHR3 byBBUElzLiBUaGUgZmlyc3QgaXMgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5zdHJhaWdodGZvcndhcmQgbWFwcGluZyBvZiBQUiM3MjAsIGlu IHdoaWNoIHdlIGhhdmUgdHdvIG9iamVjdHM6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgU2VuZFN0cmVhbSAtLSB1c2VkIGZv ciB3cml0aW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOyBSZWN2U3RyZWFtIC0tIHVzZWQgZm9yIHJlYWRpbmc8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkFzIGJlZm9yZSwg d2UgaGF2ZSBhIGhhbmRsZXIgb2JqZWN0LCBidXQgaXQncyBkaXJlY3Rpb25hbCBub3c6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7dHlwZSBDb25uZWN0aW9uSGFuZGxlciBpbnRlcmZhY2UgezxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IC8v IFRoZSBjb25uZWN0aW9uIGhhcyBjaGFuZ2VkIHN0YXRlIHRvIHN0YXRlIHxzfDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7 IFN0YXRlQ2hhbmdlZChzIFN0YXRlKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgLy8gQSBuZXcgcmVj ZWl2aW5nIHN0cmVhbSBoYXMgYmVlbiBjcmVhdGVkIChieSByZWNlaXZpbmcgYSBmcmFtZTxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsg Jm5ic3A7IC8vIGZyb20gdGhlIG90aGVyIHNpZGUuIHxzfCBjb250YWlucyB0aGUgc3RyZWFtLjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7IE5ld1JlY3ZTdHJlYW0ocyAqUmVjdlN0cmVhbSk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7IC8vIFN0cmVhbSB8c3wgaXMgbm93IHJlYWRhYmxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IFN0cmVhbVJlYWRh YmxlKHMgKlJlY3ZTdHJlYW0pPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDt9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5PYnZpb3VzbHkgU2VuZFN0cmVhbXMgYXJl IGxvY2FsbHkgY3JlYXRlZCBhbmQgUmVjdlN0cmVhbXMgYXJlIHJlbW90ZWx5PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmNyZWF0ZWQuIFNlbmRT dHJlYW1zIGNhbiBiZSBjcmVhdGVkIHVzaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNvbm5lY3Rpb24uQ3JlYXRlU2VuZFN0cmVhbSgpIGFu ZCB5b3UgbGVhcm4gYWJvdXQgcmVtb3RlbHkgY3JlYXRlZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5SZWN2U3RyZWFtcyBieSBhIGNhbGxiYWNr IHRvIENvbm5lY3Rpb25IYW5kbGVyLk5ld1JlY3ZTdHJlYW0oKS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2Vjb25kLWNyZWF0ZWQgc3RyZWFt cyBjYW4gYmUgbWFya2VkIGFzICZxdW90O3JlbGF0ZWQmcXVvdDsgdG8gYSBzaW5nbGU8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Zmlyc3QtY3Jl YXRlZCBzdHJlYW0sIHVzaW5nIENvbm5lY3Rpb24uQ3JlYXRlUmVsYXRlZFNlbmRTdHJlYW0oKSB3 aXRoPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PnRoZSBhcHByb3ByaWF0ZSBSZWN2U3RyZWFtIGFzIHRoZSBhcmd1bWVudCBbM10uIFN0cmVhbXMg aGF2ZSBhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPlJlbGF0ZWQoKSBBUEkgdG8gdGVsbCB5b3UgaWYgdGhleSBhcmUgcmVsYXRlZCB0byBzb21l IG90aGVyIHN0cmVhbS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPlRoZSB7U2VuZCxSZWN2fVN0cmVhbSBBUElzIGFyZSBhYm91dCB3aGF0 IHlvdSdkIGV4cGVjdC4gWW91IGNhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5Xcml0ZSgpIG9uIFNlbmRTdHJlYW0gYW5kIFJlYWQoKSBvbiBS ZWN2U3RyZWFtKCkuIFJpZ2h0IG5vdywgeW91IGNhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5DbG9zZSgpIGFuZCBSZXNldCgpIFNlbmRTdHJl YW1zLCBidXQgbm90IGRvIGFueXRoaW5nIG9uIFJlY3ZTdHJlYW1zKCk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+b3IgdGhhbiBpZ25vcmUgdGhl bS4gRXZlbnR1YWxseSBJJ2xsIHByb2JhYmx5IG9mZmVyPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlY3ZTdHJlYW0oKS5NdXRlKCkgb3Igc29t ZXRoaW5nIHRvIGxldCB5b3Ugc2VuZCBTVE9QX1NFTkRJTkcuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QklESVJFQ1RJT05BTCBB UEk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ TWlucSBhbHNvIGluY2x1ZGVzIGEgYmlkaXJlY3Rpb25hbCBBUEkgdGhhdCdzIGxheWVyZWQgb24g dG9wIG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPnVuaWRpcmVjdGlvbmFsIHN0cmVhbXMuIEkndmUgY3JlYXRlZCBhIENvbm5lY3Rpb24yIHN0 cnVjdHVyZSB0aGF0J3M8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+aW50ZW5kZWQgYXMgYSB3cmFwcGVyIGFyb3VuZCBDb25uZWN0aW9uIFs0XTo8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyAmbmJzcDt0eXBlIENvbm5lY3Rpb24yIHN0cnVjdCB7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgQ29ubmVj dGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgJm5ic3A7IHNoaW0mbmJzcDsgJm5ic3A7ICpjb25uZWN0aW9uMlNoaW1IYW5kbGVy PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOyAmbmJzcDsgc3RyZWFtcyBbXSpTdHJlYW0gLy8gT2RkIGZvciBjbGllbnQgb3JpZ2luYXRl ZCwgZXZlbiBmb3Igc2VydmVyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7ICZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5i c3A7dHlwZSBTdHJlYW0gc3RydWN0IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBpZCZuYnNwOyAmbmJzcDt1aW50MzI8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7ICZuYnNwOyBzZW5kICpTZW5kU3RyZWFtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgcmVjdiAqUmVjdlN0cmVhbTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+QmFzaWNhbGx5LCBTdHJlYW0gaXMganVzdCBhIHBhaXIgb2YgU2VuZFN0cmVh bSBhbmQgUmVjdlN0cmVhbSBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Q29ubmVjdGlvbjIgZG9lcyB0aGUgYm9va2tlZXBpbmcgdG8ga2Vl cCB0aGVtIGNvbm5lY3RlZCAoSSBldmVuIGRvIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vZGQvZXZlbiBJRCB0aGluZyB0aGF0IFFVSUMt MDUgaGFzKS4gQ29ubmVjdGlvbjIgaGFzIHRoZSBzYW1lIGhhbmRsZXI8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QVBJIGFzIE1pbnEgZm9yIFFV SUMtMDUsIGFuZCB0aGUgc2hpbSBpcyByZXNwb25zaWJsZSBmb3IgdHJhbnNsYXRpbmc8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+dW5pZGlyZWN0 aW9uYWwgZXZlbnRzIGludG8gYmlkaXJlY3Rpb25hbCBldmVudHMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JbnRlcm5hbGx5LCB3aGF0 J3MgZ29pbmcgb24gaGVyZSBpcyB0aGF0IHdoZW4geW91IGNhbGwgQ3JlYXRlU3RyZWFtKCk8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWlucSBj cmVhdGVzIGEgU3RyZWFtIHdpdGggYSBuaWwgUmVjdlN0cmVhbS4gV2hlbiBhIG5ldyByZW1vdGUg c3RyZWFtPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPmlzIGRldGVjdGVkLCB3ZSBjaGVjayBSZWN2U3RyZWFtLlJlbGF0ZWQoKS4gSWYgdGhleSBh cmUgcmVsYXRlZCB0byBhbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5leGlzdGluZyBTZW5kU3RyZWFtIHRoZW4gd2Ugd2lsbCBpbiB0aGUgcmVs ZXZhbnQgfFN0cmVhbS5zZW5kfCBzbG90LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj5PdGhlcndpc2UsIHdlIGNyZWF0ZSBhIG5ldyBTZW5kU3Ry ZWFtIHRoYXQncyByZWxhdGVkIHRvIHRoZSBpbmNvbWluZzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zdHJlYW0gYW5kIG5vdGlmeSB0aGUgYXBw bGljYXRpb24gb2YgdGhlIGNyZWF0aW9uIG9mIHRoZSBuZXc8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YmlkaXJlY3Rpb25hbCBzdHJlYW0uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5O b3RlIHRoYXQgdGhpcyBhbGwgd29ya3MgZmluZSBpZiBvbmUgc2lkZSBkb2VzIHRoZSB1bmRpcmVj dGlvbmFsIEFQSTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5hbmQgb25lIGRvZXMgdGhlIGJpZGlyZWN0aW9uYWwgQVBJLiBNeSB0ZXN0IHByb2dy YW1zIGFjdHVhbGx5IGV4ZXJjaXNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPnRoaXMuIE9mIGNvdXJzZSwgdGhlcmUncyBhbiBhc3N1bXB0aW9u IHRoYXQgdGhlIHBlZXIgY29uZm9ybXMgdG8gYSAxOjE8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+bWFwcGluZy4gSWYgd2UgZGVmaW5lIHVuaWRp cmVjdGlvbmFsIHN0cmVhbXMsIHdlJ2xsIG5lZWQgc29tZSBwcm90b2NvbDxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5tZWNoYW5pc20gdG8ga25v dyBpZiB0aGUgb3RoZXIgc2lkZSBpcyBleGVyY2lzaW5nIHRoaXMgbGV2ZWwgb2Y8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+aW5jcmVhc2VkIGZs ZXhpYmlsaXR5IG9yIG5vdC4gSSBjYW4gaW1hZ2luZSBhIG51bWJlciBvZiBvcHRpb25zIGhlcmU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+KGUu Zy4sIEFMUE4pLiZuYnNwOyBXZSBjb3VsZCBhbHNvIGZvcmJpZCAxOk4gbWFwcGluZ3MgYnV0IEkg dGhpbmsgdGhhdDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj53b3VsZCBiZSBhIG1pc3Rha2UgYXMgaXQncyBhIGNvb2wgZmVhdHVyZS9iZW5lZml0 IG9mIGRvaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPnVuaWRpcmVjdGlvbmFsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhlIGVudGlyZSBiaWRpcmVjdGlvbmFsIHdyYXBwZXIg c2hpbSBpcyAmbHQ7IDE1MCBsaW5lcyBvZiBHbyBjb2RlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4oPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZ1cmxkZWZl bnNlLnByb29mcG9pbnQuY29tJTJGdjIlMkZ1cmwlM0Z1JTNEaHR0cHMtM0FfX25hMDEuc2FmZWxp bmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb21fLTNGdXJsLTNEaHR0cHMtMjUzQS0yNTJGLTI1MkZn aXRodWIuY29tLTI1MkZla3ItMjUyRm1pbnEtMjUyRmJsb2ItMjUyRnVuaWRpcmVjdGlvbmFsLTVG c3RyZWFtcy0yNTJGYmlkaS5nby0yNmRhdGEtM0QwMi0yNTdDMDEtMjU3Q21pY2hhZWwuYmlzaG9w LTI1NDBtaWNyb3NvZnQuY29tLTI1N0MxNGYwNzk4N2RhMGQ0YWZiOGU3NTA4ZDUwOTBmZjZmNi0y NTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDctMjU3QzEtMjU3QzAtMjU3QzYzNjQy NDg4NjU0NjQ4MTcxMC0yNnNkYXRhLTNEd3BzOUFXSzJmYWE4M045Ui0yNTJCREhvdmlnLTI1MkJ3 ZjY4NFBTLTI1MkI1UXc1RGd6WUg1SS0yNTNELTI2cmVzZXJ2ZWQtM0QwJTI2ZCUzRER3TUZhUSUy NmMlM0Q5NlpiWlpjYU1GNHcwRjRqcE42TFpnJTI2ciUzRERqbjNiUTV1TkpEUE1fMnNrZkwzclcx dHpjSXh5alVaZG5fbTU1S1BtbG8lMjZtJTNEMENqMDRFanNqMlowOExJWmFRVmc4SmRKTGJmcS13 ZTg5QzFDQjlDazVVSSUyNnMlM0Q3TzN2NUpoVFFaZFJ2NUFORWM1aFdVRXJuYXRlaTQ2ei1yTUpz SmI0d1JvJTI2ZSUzRCZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5CaXNob3AlNDBtaWNyb3Nv ZnQuY29tJTdDZTdkODYzNjYxM2YxNDUwMTA0Y2QwOGQ1MDlhNTQwY2ElN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NDI1NTI3NzIzMjcwMzczJmFtcDtzZGF0 YT1haDlYaWE2Zncyb004aXlvZHZKVXVMdGlxR3lEM3cxbmYwJTJGYmFYQzhhSkUlM0QmYW1wO3Jl c2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL2dpdGh1Yi5jb20vZWtyL21pbnEvYmxv Yi91bmlkaXJlY3Rpb25hbF9zdHJlYW1zL2JpZGkuZ288L2E+KS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Q29udmVydGluZyBteSB0ZXN0IGFw cGxpY2F0aW9uIHRvIHRoaXMgQVBJIHdhcyBhIG1hdHRlciBvZiBqdXN0PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPmNoYW5naW5nIGNsYXNzIG5h bWVzLCBlLmcuLCBzL0Nvbm5lY3Rpb25iL0Nvbm5lY3Rpb24yLy48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkluIG15IGltcGxlbWVudGF0 aW9uLCBJIGFzc3VtZSB0aGF0IGF0IHRoZSB0aW1lIE1pbnEgaGVhcnMgYWJvdXQgYTxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zdHJlYW0sIHlv dSBrbm93IGlmIGl0cyByZWxhdGVkIHRvIGEgZ2l2ZW4gZXhpc3Rpbmcgc3RyZWFtLiZuYnNwOyBU aGF0IHdheTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj55b3UgY2FuIGltbWVkaWF0ZWx5IGVpdGhlciBhc3NvY2lhdGUgaXQgd2l0aCB0aGF0IHN0 cmVhbSBvciBtYWtlIGEgbmV3PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPmxvY2FsIHN0cmVhbS4gSW4gbXkgaW1wbGVtZW50YXRpb24sIEkgYWx3 YXlzIHNlbmQgUmVsYXRlZCBTdHJlYW0gSWQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+YW5kIGFzc3VtZSB0aGF0IHlvdSBuZXZlciBnZXQgYW4g JnF1b3Q7dW5yZWxhdGVkJnF1b3Q7IHN0cmVhbSBmcmFtZSBiZWZvcmUgYTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mcXVvdDtyZWxhdGVkJnF1 b3Q7IG9uZS4gVGhlIHNwZWMgZG9lc24ndCByZWFsbHkgcmVxdWlyZSB0aGF0IHJpZ2h0IG5vdywg YW5kPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pm9mZmxpbmUgTVQgc3VnZ2VzdGVkIGp1c3Qgc2VuZGluZyByZWxhdGVkIHdpdGggb2Zmc2V0PTAg YnV0IEkgdGhpbms8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+dGhhdCdzIGEgbWlzdGFrZSwgYmVjYXVzZSBpdCBtZWFucyB0aGF0IHlvdSBuZWVk IHRvIGhvbGQgc3RyZWFtIGZyYW1lczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5pbiBzb21lIHByb3Zpc2lvbmFsICZxdW90O3VuZGV0ZXJtaW5l ZCZxdW90OyBzdGF0ZSB1bnRpbCB5b3UgZ2V0IHRoYXQgZnJhbWUuIEk8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+d291bGQgc3VnZ2VzdCBpbnN0 ZWFkIHRoYXQgd2UgcmVxdWlyZSB0aGF0IHlvdSBpbmNsdWRlIHRoZSBmaWVsZCB1bnRpbDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5vbmUgb2Yg dGhlIGZyYW1lcyBpcyBBQ0tlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5JTlRFUk5BTFM8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+U2VuZGluZyBhbmQgcmVjZWl2 aW5nIHN0cmVhbXMgc3RpbGwgc2hhcmUgYSBsb3Qgb2YgY29tbW9uIGNvbXBvbmVudHM6PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7IHR5cGUgYmFzZVN0cmVhbSBzdHJ1Y3QgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IHN0YXRlJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3N0cmVhbVN0YXRlPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgaWQmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50MzI8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBs b2cmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2xvZ2dpbmdGdW5jdGlv bjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4m bmJzcDsgJm5ic3A7IG9mZnNldCZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB1aW50NjQ8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 ICZuYnNwOyBjaHVua3MmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgW11zdHJlYW1DaHVuazxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgJm5ic3A7IG1heFN0cmVhbURhdGEgdWludDY0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgaXNSZWxhdGVkJm5ic3A7 ICZuYnNwOyAmbmJzcDtib29sPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgcmVsYXRlZCZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO3VpbnQzMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IH08bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IHR5 cGUgc2VuZFN0cmVhbSBzdHJ1Y3QgezxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgJm5ic3A7IGJhc2VTdHJlYW08bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBi bG9ja2VkIGJvb2w8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyB9PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyB0eXBl IHJlY3ZTdHJlYW0gc3RydWN0IHs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7ICZuYnNwOyBiYXNlU3RyZWFtPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgfTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ TW9zdCBvZiB0aGlzIGlzIHRoZSBzYW1lIGFzIHdpdGggYmlkaXJlY3Rpb25hbCBzdHJlYW1zLiZu YnNwOyBBcyBhYm92ZSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+aXQncyBwcm9iYWJseSBwb3NzaWJsZSB0byBtYWtlIHRoZW0gbW9yZSBhc3lt bWV0cmljYWwuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj5UaGUgY29ubmVjdGlvbiBtYWludGFpbnMgc2VwYXJhdGUgbGlzdHMgb2Ygc2Vu ZGluZyBhbmQgcmVjZWl2aW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPnN0cmVhbXMgYW5kIGl0J3Mgc3RyYWlnaHRmb3J3YXJkIHRvIGNyZWF0 ZSBhbmQgYWNjZXNzIHRoZW0gd2l0aG91dDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj53b3JyeWluZyBhYm91dCB0aGUgb2RkL2V2ZW4gc3R1ZmYu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Q09NUEFSSVNPTjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5BdCB0aGUgZW5kIG9mIHRoZSBkYXksIEkgdGhpbmsgdGhpcyBzaG93cyB0 aGF0IHRoZXNlIGRlc2lnbnMgYXJlbid0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPnJlYWxseSB0aGF0IGRpc3NzaW1pbGFyLiBJIHdhcyBhYmxl IHRvIGNvbnZlcnQgTWlucSB0byB1bmlkaXJlY3Rpb25hbDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5zdHJlYW1zIGluIGFib3V0IDE2IHRvdGFs IGhvdXJzIG9mIHdvcmsgKGJhc2ljYWxseSBhIGxvbmcgcGxhbmUgZmxpZ2h0PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPnBsdXMgdGhlIG5leHQg bW9ybmluZykuIFdoaWxlIEkgaGFkIHRvIG1ha2UgYSBidW5jaCBvZiBjaGFuZ2VzIHRvIHRoZTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5pbnRl cm5hbCBzdHJ1Y3R1cmVzLCBiYXNpY2FsbHkgbm9uZSBvZiB0aGVtIG1vZGlmaWVkIGFueXRoaW5n IHRyaWNreSw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+YW5kIGluIHBhcnRpY3VsYXIgdGhlIGZsb3cgY29udHJvbCBtZWNoYW5pY3MgYW5kIHRo ZSBsaWtlIGFyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj5iYXNpY2FsbHkgdW5jaGFuZ2VkLCBleGNlcHQgZm9yIGEgYnVuY2ggb2YgbWVjaGFu aWNhbC10eXBlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPnRyYW5zZm9ybWF0aW9ucyBsaWtlIHJlZmVycmluZyB0byB8c2VuZFN0cmVhbS5jaHVu a3N8IGluc3RlYWQgb2Y8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+fHN0cmVhbS5zZW5kLmNodW5rc3wuIFRoZSBvbmx5IHJlYWxseSBuZXcgcHJv dG9jb2wgbWFjaGluZXJ5IGlzIHRoZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5uZXcgZnJhbWUgZm9ybWF0IGZvciByZWxhdGVkIHN0cmVhbXMu PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij5UaGVyZSBhcmUgYSBmZXcgcHJvcy9jb25zIHRoYXQgYXJlIHdvcnRoIG5vdGluZyBhYm91dCB0 aGVzZSBkZXNpZ25zLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+LSBXaXRob3V0IGEgYmlkaXJlY3Rpb25hbCBBUEksIGhhdmluZyB1bmlk aXJlY3Rpb25hbCBzdHJlYW1zIGlzIG1vcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IHdvcmsgZm9yIHRoZSBwcm9ncmFtbWVyLiBI b3dldmVyLCB3aXRoIGFuIEFQSSBzaGltLCB0aGUgZGlmZmVyZW5jZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgaXMgdHJpdmlhbC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i Pi0gQmVjYXVzZSB1bmRpcmVjdGlvbmFsIHN0cmVhbXMgYXJlIGluaGVyZW50bHkgbW9yZSBmbGV4 aWJsZSwgaXQnczxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDsgcG9zc2libGUgZm9yIHRoZSBzaWRlcyB0byB0cnkgdG8gdXNlIGRpZmZl cmVudCBtYXBwaW5ncywgZS5nLiwgb25lPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBzaWRlIGV4cGVjdHMgcGFpcmVkIGFuZCB0aGUg b3RoZXIgZXhwZWN0cyAxOk4uIFdlJ2xsIG5lZWQgc29tZSB3YXk8bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IG9mIG1ha2luZyBzdXJl IHRoYXQgZG9lc24ndCBoYXBwZW4sIG1heWJlIEFMUE4/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIFRoZSAmcXVvdDtSZWxhdGVkIFN0 cmVhbSBJRCZxdW90OyBmcmFtZSBpbmRpY2F0b3IgbmVlZHMgZmxlc2hpbmcgb3V0IGEgYml0Ljxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJz cDsgRnJvbSB0aGUgYXBwbGljYXRpb24ncyBwZXJzcGVjdGl2ZSwgaXQgc2hvdWxkIG5ldmVyIGhl YXIgYWJvdXQgYTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4mbmJzcDsgc3RyZWFtIHdpdGhvdXQga25vd2luZyBpdHMgcmVsYXRlZCBzdGF0dXMu IEFuZCBhcyBub3RlZCBhYm92ZSwgSTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgdGhpbmsgaXQgd291bGQgYmUgYmVzdCBpZiB3ZSBy ZXF1aXJlZCB0aGF0IGFsbCAmcXVvdDtmaXJzdCBmbGlnaHQmcXVvdDsgc3RyZWFtPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBmcmFt ZXMgdGhhdCBhcmUgcmVsYXRlZCBpbmNsdWRlIHRoZSBmaWVkPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIFVuZGlyZWN0aW9uYWwgc3Ry ZWFtcyBraW5kIG9mIHNoYXJwZW4gdGhlIGNvbmZ1c2lvbiBhYm91dCBleGFjdGx5PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyB3aGF0 IGtpbmRzIG9mICZxdW90O2Nsb3N1cmUmcXVvdDsgd2Ugd2FudCB0byBhbGxvdy4gU3BlY2lmaWNh bGx5LCB3aGF0IHNob3VsZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDsgaW1wbGVtZW50YXRpb25zIGJlIGFibGUgdG8gc2F5IGFib3V0 IHRoZWlyIHdpbGxpbmduZXNzIHRvIHJlY2VpdmU/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBSaWdodCBub3cgd2UgaGF2ZSBTVE9Q X1NFTkRJTkcsIGJ1dCB0aGF0IGRvZXNuJ3QgaW5mbHVlbmNlIHRoZTxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgc2VuZGVyJ3Mgc3Rh dGUuIEkgZG9uJ3QgdGhpbmsgdW5kaXJlY3Rpb25hbCBzdHJlYW1zIG1ha2UgdGhpcyB3b3JzZSw8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7IHRoZXkganVzdCByZXF1aXJlIHVzIHRvIHRoaW5rIGl0IHRocm91Z2ggc29tZSBtb3JlLiBU aGV5IGRvIHNpbXBsaWZ5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyB0aGUgaW1wbGVtZW50YXRpb24gb2YgdGhlIGNsb3N1cmUgc3Rh dGUgbWFjaGluZTogaW4gbXkgUVVJQy0wNSBjb2RlLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgd2hlbmV2ZXIgb25lIHNpZGUgY2xv c2VzIEkgaGF2ZSB0byBoYXZlIGNoZWNrcyB0byBzZWUgaWYgSSBzaG91bGQgYmU8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IHRyYW5z aXRpb25pbmcgdG8gQ0xPU0VEIG9yIEhBTEYtQ0xPU0VELCBldGMsIHdoaWNoIGlzIG9kZCBiZWNh dXNlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyB0aGUgZGlyZWN0aW9ucyBhcmUgYmFzaWNhbGx5IGluZGVwZW5kZW50LiZuYnNwOyBJ dCB3b3VsZCBwcm9iYWJseSBiZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvIj4mbmJzcDsgZWFzaWVyIGV2ZW4gaW4gUVVJQy0wNSBub3QgdG8gcmVp ZnkgdGhlc2Ugc3RhdGVzIGJ1dCBqdXN0IHRvPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBkZXRlcm1pbmUgdGhlIHN0YXRlIGZyb20g dGhlIGNvbXBvc2l0aW9uIG9mIHRoZSBpbmRpdmlkdWFsPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBzdWItc3RhdGVzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4t IFVuaWRpcmVjdGlvbmFsIHN0cmVhbXMgZG9uJ3QgbmVlZCB0aGUga2luZCBvZiBhbm5veWluZyBv ZGQtZXZlbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDsgbWVjaGFuaWNzLCB3aGljaCB3YXMgZWFzaWVyIHRvIGNvZGUgdXAgKGp1c3Qg aGF2aW5nIHRvIGNyZWF0ZSBhbGw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IHRoZSBsb3dlci1udW1iZXJlZCBzdHJlYW1zIG9mIHRo ZSBzYW1lIHBhcml0eSBpcyBraW5kIG9mIGEgcGFpbikuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBPbmUgYWRkaXRpb25hbCBiZW5l Zml0IGhlcmUgaXMgdGhhdCB3aXRoIFFVSUMtMDUgdGhlcmUgYXJlIHNldmVyYWw8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IG1lc3Nh Z2VzIHdoaWNoIGludm9sdmUgaW1wbGljaXQgc3RyZWFtIGNyZWF0aW9uIChlLmcuLDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDsgU1RS RUFNX01BWF9EQVRBLCBhbmQgUlNUX1NUUkVBTSkgYW5kIHNvIHlvdSBuZWVkIHRvIGNoZWNrIHdo ZXRoZXI8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7IHRoZSBzdHJlYW0gaXMgb25lIHRoYXQgc2hvdWxkIGhhdmUgYmVlbiBjcmVhdGVk IGxvY2FsbHkgb3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7IHJlbW90ZWx5LiBUaGlzIGp1c3QgZG9lc24ndCBoYXBwZW4gd2l0aCBi aWRpcmVjdGlvbmFsIHN0cmVhbXM7IEkgZG88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IGltcGxlbWVudCBvZGQvZXZlbiBtZWNoYW5p Y3MgYnV0IGJlY2F1c2UgdGhlIG90aGVyIHNpZGUgaGFzIHRvIGhhdmU8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IGl0cyBzdHJlYW0g aWRzIGluY3JlbWVudCBieSBvbmUsIEkgY2FuIG1ha2Ugc3VyZSB0aGF0IHRoZXkgaGF2ZSB0aGU8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7IHJpZ2h0IElEcyBieSBjb25zdHJ1Y3Rpb24gYW5kIGp1c3QgY2hlY2sgdG8gc2VlIGlmIHRo ZSBzdHJlYW0gZXhpc3RzPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyBpbiB0aGVzZSBjYXNlcy4mbmJzcDsgSSdkIGxpa2UgdG8gc2Vl IHVzIGdldCByaWQgb2Ygb2RkL2V2ZW4gbm8gbWF0dGVyPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyB3aGF0LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+LSBVbmlkaXJlY3Rp b25hbCBzdHJlYW1zIGFsc28gaGVscHMgYXZvaWQgc29tZSBvZiB0aGUgY29ybmVyIGNhc2VzIGFy b3VuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv Ij4mbmJzcDsgYmlkaXJlY3Rpb25hbCBzdHJlYW1zLiBTcGVjaWZpY2FsbHksIHN1cHBvc2UgSSBh bSB0aGUgY2xpZW50IGFuZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj4mbmJzcDsgSSBnZXQgTUFYX1NUUkVBTV9EQVRBIGFzIHRoZSBmaXJzdCBm cmFtZSBvbiBzdHJlYW0gMi4gQW0gSSBhbGxvd2VkPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyB0byBqdXN0IHN0YXJ0IHNlbmRpbmcg b3Igbm90PyBZb3UgY2FuIHNvcnQgb2YgZ2V0IGludG8gdGhpcyBzaXR1YXRpb248bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7IHdpdGgg dW5pZGlyZWN0aW9uYWwgc3RyZWFtcywgYnV0IGJlY2F1c2UgaXQncyBleHBsaWNpdCwgb25lIG1p Z2h0PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOyBob3BlIHRoYXQgdGhlIGFwcGxpY2F0aW9uIHNlbWFudGljcyB3b3VsZCByZXF1aXJl IGNsZWFyIHNwZWNpZmljYXRpb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4tIEFzIG5vdGVkIGFib3ZlLCBiaWRpcmVjdGlv bmFsIHN0cmVhbXMgYXJlIG1vcmUgZmxleGlibGUgYmVjYXVzZSB0aGV5PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBsZXQgeW91IGhh dmUgbWFwcGluZ3MgdGhhdCB5b3UgY2FuJ3QgaGF2ZSB3aXRoIHVuaWRpcmVjdGlvbmFsPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyBz dHJlYW1zICh1bnBhaXJlZCwgMTpOKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5IYXBweSB0byBhbnN3ZXIgbW9yZSBxdWVzdGlv bnMgaWYgcGVvcGxlIGhhdmUgdGhlbS4gT3RoZXJ3aXNlIHdlIGNhbjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj50YWxrIGFib3V0IHRoaXMgaW4g U2VhdHRsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6 YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPi1Fa3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvIj5bMF0NCjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3Mu cHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9v ZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNGdSUzRGh0dHBzLTNBX19uYTAxLnNhZmVsaW5rcy5wcm90 ZWN0aW9uLm91dGxvb2suY29tXy0zRnVybC0zRGh0dHBzLTI1M0EtMjUyRi0yNTJGZ2l0aHViLmNv bS0yNTJGZWtyLTI1MkZtaW5xLTI1MkZ0cmVlLTI1MkZ1bmlkaXJlY3Rpb25hbC01RnN0cmVhbXMt MjZkYXRhLTNEMDItMjU3QzAxLTI1N0NtaWNoYWVsLmJpc2hvcC0yNTQwbWljcm9zb2Z0LmNvbS0y NTdDMTRmMDc5ODdkYTBkNGFmYjhlNzUwOGQ1MDkwZmY2ZjYtMjU3QzcyZjk4OGJmODZmMTQxYWY5 MWFiMmQ3Y2QwMTFkYjQ3LTI1N0MxLTI1N0MwLTI1N0M2MzY0MjQ4ODY1NDY0ODE3MTAtMjZzZGF0 YS0zRHhTZVNYWUc0T0M2aVRaaGljVmdINnFKVE5yWkVRaGFVQmMwWFJzeGl5cEEtMjUzRC0yNnJl c2VydmVkLTNEMCUyNmQlM0REd01GYVElMjZjJTNEOTZaYlpaY2FNRjR3MEY0anBONkxaZyUyNnIl M0REam4zYlE1dU5KRFBNXzJza2ZMM3JXMXR6Y0l4eWpVWmRuX201NUtQbWxvJTI2bSUzRDBDajA0 RWpzajJaMDhMSVphUVZnOEpkSkxiZnEtd2U4OUMxQ0I5Q2s1VUklMjZzJTNEQlBNdl91NlBvQVV5 TlFUNnFSQm85MXNfUGtoYmFwZTNKYktlNnFkU2dvVSUyNmUlM0QmYW1wO2RhdGE9MDIlN0MwMSU3 Q01pY2hhZWwuQmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3Q2U3ZDg2MzY2MTNmMTQ1MDEwNGNkMDhk NTA5YTU0MGNhJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYz NjQyNTUyNzcyMzI3MDM3MyZhbXA7c2RhdGE9T0NyYkt6OHRzaE1kVFEwYU1qYWZSUURIR0MyT2Jr dEkydUltb2ZSWWQlMkJ3JTNEJmFtcDtyZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRw czovL2dpdGh1Yi5jb20vZWtyL21pbnEvdHJlZS91bmlkaXJlY3Rpb25hbF9zdHJlYW1zPC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bMV0N CjxhIGhyZWY9Imh0dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/ dXJsPWh0dHBzJTNBJTJGJTJGdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbSUyRnYyJTJGdXJsJTNG dSUzRGh0dHBzLTNBX19uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tXy0zRnVy bC0zRGh0dHBzLTI1M0EtMjUyRi0yNTJGZ2l0aHViLmNvbS0yNTJGZWtyLTI1MkZ3Zy0yRG1hdGVy aWFscy0yNTJGYmxvYi0yNTJGNDA0ODk4ZmEyZDJmMGE5ZjliZDI0NGQyYzk0NWU2NmVhODg1MDJh Mi0yNTJGaW50ZXJpbS0yRDE3LTJEMTAtMjUyRlVuaWRpcmVjdGlvbmFsLTI1MjUyMFN0cmVhbXMt MjUyNTIwaW4tMjUyNTIwTWlucS5wZGYtMjZkYXRhLTNEMDItMjU3QzAxLTI1N0NtaWNoYWVsLmJp c2hvcC0yNTQwbWljcm9zb2Z0LmNvbS0yNTdDMTRmMDc5ODdkYTBkNGFmYjhlNzUwOGQ1MDkwZmY2 ZjYtMjU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3LTI1N0MxLTI1N0MxLTI1N0M2 MzY0MjQ4ODY1NDY0ODE3MTAtMjZzZGF0YS0zRFotMjUyQklOT2tBQXZiWHdZN1l1d2FQajBmMXlS WFk3Uzc5QWtELTI1MkZ2SEdwd0xvUS0yNTNELTI2cmVzZXJ2ZWQtM0QwJTI2ZCUzRER3TUZhUSUy NmMlM0Q5NlpiWlpjYU1GNHcwRjRqcE42TFpnJTI2ciUzRERqbjNiUTV1TkpEUE1fMnNrZkwzclcx dHpjSXh5alVaZG5fbTU1S1BtbG8lMjZtJTNEMENqMDRFanNqMlowOExJWmFRVmc4SmRKTGJmcS13 ZTg5QzFDQjlDazVVSSUyNnMlM0RVSlVVNDF1Q3dINEpLVGROeVpTLVc2MGp6bjdodHVsWHpGdUVX bW9qaHVJJTI2ZSUzRCZhbXA7ZGF0YT0wMiU3QzAxJTdDTWljaGFlbC5CaXNob3AlNDBtaWNyb3Nv ZnQuY29tJTdDZTdkODYzNjYxM2YxNDUwMTA0Y2QwOGQ1MDlhNTQwY2ElN0M3MmY5ODhiZjg2ZjE0 MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NDI1NTI3NzIzMjcwMzczJmFtcDtzZGF0 YT01dEFmWllKNnRpb3hmU0NZOHhkVW94bXJsTlYzVlpENzNNbU4lMkJETnh5WHclM0QmYW1wO3Jl c2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9la3Ivd2ctbWF0 ZXJpYWxzL2Jsb2IvNDA0ODk4ZmEyZDJmMGE5ZjliZDI0NGQyYzk0NWU2NmVhODg1MDJhMi9pbnRl cmltLTE3LTEwL1VuaWRpcmVjdGlvbmFsJTIwU3RyZWFtcyUyMGluJTIwTWlucS5wZGY8L2E+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlsyXSBU aGFua3MgdG8gUGF0cmljayBNY01hbnVzIGZvciBzdWdnZXN0aW5nIHRoaXMgZGVzaWduLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5bM10gSW4g QyYjNDM7JiM0MzssIHlvdSB3b3VsZCBoYXZlIGEgc2luZ2xlIGZ1bmN0aW9uIHdpdGggYSBkZWZh dWx0IGFyZ3VtZW50IG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgfG51bGxwdHJ8IGJ1dCBHbyBkb2Vzbid0IHN1cHBv cnQgdGhhdCwgaGVuY2UgdHdvIGRpZmZlcmVudCBhcmd1bWVudHMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPls0XSBGb3IgaW1wbGVtZW50YXRp b24gcmVhc29ucywgaXQncyBhY3R1YWxseSB1c2luZyBDb25uZWN0aW9uIGFzIGEgbWl4aW4sPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNw OyAmbmJzcDsgd2hpY2ggbWVhbnMgaXQncyBzaW11bHRhbmVvdXNseSBwb3NzaWJsZSB0byB1c2Ug dGhlIHVuaWRpcmVjdGlvbmFsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgYW5kIGJpZGlyZWN0aW9uYWwgQVBJcywgYnV0 IHRoYXQncyBnb2luZyB0byBjYXVzZSBhIGxvdCBvZiBjb25mdXNpb24uPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgQSBy ZWFsIGltcGxlbWVudGF0aW9uIHdvdWxkIHByb2JhYmx5IGhhdmUgdG8gZWl0aGVyIGNvbW1pdCB0 byBvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+Jm5ic3A7ICZuYnNwOyBvciB0aGUgb3RoZXIgb3IgZG8gYSByZWFsIHdyYXBwZXIsIHNvIHlv dSBjb3VsZCBvbmx5IHVzZSBvbmUgc2V0IG9mPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsgQVBJcywgYXQgdGhlIGNvc3Qg b2YgaGF2aW5nIHRvIGRvIG1vcmUgZm9yd2FyZGVkIG1ldGhvZHMuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOyAmbmJzcDsmbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1 dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_b6ca3e39c94e44c2ad1987d5ea90078eusma1exdag1mb5msgcorpak_-- From nobody Mon Oct 2 20:57: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 9260413304B for ; Mon, 2 Oct 2017 20:57:28 -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 vAjBOtA6F_KI for ; Mon, 2 Oct 2017 20:57:26 -0700 (PDT) Received: from mail-wr0-x234.google.com (mail-wr0-x234.google.com [IPv6:2a00:1450:400c:c0c::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51A6E1320CF for ; Mon, 2 Oct 2017 20:57:26 -0700 (PDT) Received: by mail-wr0-x234.google.com with SMTP id j14so5415789wre.8 for ; Mon, 02 Oct 2017 20:57:26 -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=06JAHt27vtOEE1fWOOVjf7D/au6sLybGskf153plZak=; b=YT2gb5j8WuFPRTifP9LF4O0QVez8NOCslkAxyhqrL4RfLrxz3TAbCnXUMo7PkWG4SR sYQEt21/IO2jW9ur+SE6MkQ/ZyNxnIH5YQr+0/oyx7a2EqgnrC5YtwkYsNW+X92LF6+7 iPxq/BTavu9LMQB1rcL0b+MQDwAEAyKlBYBIQb8ZVrR80UcOnuAxWZHXikthORR5L3ba tEYmAoBc+6HrGWkihY1WjjdGfWcowD02CcV8DHxA+ubBp4yTz8M27gu0UB398yRKV+zj T1wMPJ6UR0Nx2B0/IjyveTaJ85HSowa3OfeXZ10RX4D9o4HzK6i2Uqw08Zi55vl6N8bN 6C9w== 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=06JAHt27vtOEE1fWOOVjf7D/au6sLybGskf153plZak=; b=azb3bfO159b5PJkXVuG83dXkic+j6IBiOKBpNecssFG56CNyUhdUWdkWUjBOESO4RM zVksYNGs+MmrYG5/3cz9wByADmhWQjwSa1Qc8DSCH2gxEwTvl2nFx5r6orNktWv73dDp Iu2mEp3HRlAdyqHRLmRXaLj2KrRuOuoZ2rR209MgDqbFPevGGYoQiHUk3ffxgiqUqGq+ ow8crkzsOB7psUmRZsZaNc6P1zv8spWnEOuwro7NFkfrJb3qBTftJagrUgzREiL9Fyj6 lFzVasTinjRE8WDk49ydt77rT/qdZ5jp8ISR1Nr//iB/Jg3x5vSPjyZvTpdSbPWUYZmv A7oA== X-Gm-Message-State: AMCzsaXL4U2WnFQFN//ptUo6/JJYU6DeXwAQnwZLPDQHINkP8L25lWs2 1NVPYD9i4xgkR8odm3wDxee2Ma9EwwaDxjf40WQ= X-Google-Smtp-Source: AOwi7QC7h8sEHheQfz02JX4sQd7iLa2O3C25iSUIz3J+k0vPAE2fxMaNgoThy0lkX07VdNJSt2Ihd+X3QTVxwqfO7VA= X-Received: by 10.223.170.15 with SMTP id p15mr162921wrd.243.1507003044820; Mon, 02 Oct 2017 20:57:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.139.132 with HTTP; Mon, 2 Oct 2017 20:57:24 -0700 (PDT) In-Reply-To: References: From: Martin Duke Date: Mon, 2 Oct 2017 20:57:24 -0700 Message-ID: Subject: Re: Seattle Interim meeting - next week To: Mark Nottingham Cc: QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="94eb2c1cc52e297aca055a9c7d1c" 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, 03 Oct 2017 03:57:28 -0000 --94eb2c1cc52e297aca055a9c7d1c Content-Type: text/plain; charset="UTF-8" Hello all, The forecast is unseasonably good! I've already gotten all of your badges and will have them at the "Diablo" conference room on the first floor of 351 Elliott Avenue, so there's no need to go to the fifth floor as indicated on the instructions. if you do, the staff has been told to send you on down. I'll be in Diablo by 9. Martin Duke F5 Networks On Thu, Sep 28, 2017 at 10:55 PM, Mark Nottingham wrote: > We're looking forward to seeing many of you at the interim meeting next > week. > > As stated before, Tuesday is an interop day, whereas Wednesday and > Thursday are the Working Group meeting. > > Meeting arrangements are available here: > https://github.com/quicwg/wg-materials/blob/master/interim- > 17-10/arrangements.md > > The agenda (subject to bashing) is here: > https://datatracker.ietf.org/meeting/interim-2017-quic-04/ > materials/agenda-interim-2017-quic-04-sessa/ > > We'll upload the presentations that introduce the architectural issues > shortly. > > Please note that the room is at capacity; only those who have registered > may attend. > > If you registered for remote participation, you should have received > details from WebEx already; if not, please ping Lars and I privately. > > Cheers, > > -- > Mark Nottingham https://www.mnot.net/ > > --94eb2c1cc52e297aca055a9c7d1c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

The forecast is unseasonably= good!

I've already gotten all of your badges = and will have them at the "Diablo" conference room on the first f= loor of 351 Elliott Avenue, so there's no need to go to the fifth floor= as indicated on the instructions.

if you do, the = staff has been told to send you on down. I'll be in Diablo by 9.
<= div>
Martin Duke
F5 Networks

On Thu, Sep 28, 2017 at 10:= 55 PM, Mark Nottingham <mnot@mnot.net> wrote:
We're looking forward to seeing many of you at the inte= rim meeting next week.

As stated before, Tuesday is an interop day, whereas Wednesday and Thursday= are the Working Group meeting.

Meeting arrangements are available here:
=C2=A0 https://githu= b.com/quicwg/wg-materials/blob/master/interim-17-10/arrangements.= md

The agenda (subject to bashing) is here:
=C2=A0 https://datatracker.ietf.org/meeting/interim-2017-quic-04/materials/agenda-interim-2017-quic-04-sessa/

We'll upload the presentations that introduce the architectural issues = shortly.

Please note that the room is at capacity; only those who have registered ma= y attend.

If you registered for remote participation, you should have received detail= s from WebEx already; if not, please ping Lars and I privately.

Cheers,

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


--94eb2c1cc52e297aca055a9c7d1c-- From nobody Tue Oct 3 11:01:53 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 7A4F3134FBF; Tue, 3 Oct 2017 11:01:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: mnot@mnot.net, quic@ietf.org, spencerdawkins.ietf@gmail.com, quic-chairs@ietf.org Subject: quic - New Interim Meeting Request X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150705371047.30686.14879264932019039231.idtracker@ietfa.amsl.com> Date: Tue, 03 Oct 2017 11:01:50 -0700 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: Tue, 03 Oct 2017 18:01:50 -0000 A new interim meeting request has just been submitted by Mark Nottingham. This request requires approval by the Transport Area Area Director The meeting can be approved here: https://datatracker.ietf.org/meeting/interim/request/interim-2018-quic-01 --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Mark Nottingham City: Melbourne Country: AU Session 1: Date: 2018-01-23 Start Time: 09:30 Australia/Melbourne Duration: 07:30 Remote Participation Information: Remote participation information will be provided upon registration. Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-18-01/arrangements.md Session 2: Date: 2018-01-24 Start Time: 09:30 Australia/Melbourne Duration: 07:30 Remote Participation Information: Remote participation information will be provided upon registration. Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-18-01/arrangements.md Session 3: Date: 2018-01-25 Start Time: 09:30 Australia/Melbourne Duration: 07:30 Remote Participation Information: Remote participation information will be provided upon registration. Agenda Note: https://github.com/quicwg/wg-materials/blob/master/interim-18-01/arrangements.md --------------------------------------------------------- From nobody Wed Oct 4 06:45:59 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 01FC6132199; Wed, 4 Oct 2017 06:45:53 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: quic@ietf.org Subject: QUIC (quic) WG Interim Meeting: 2018-01-23 X-Test-IDTracker: no X-IETF-IDTracker: 6.63.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150712475270.24252.1965027482254580403@ietfa.amsl.com> Date: Wed, 04 Oct 2017 06:45:52 -0700 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, 04 Oct 2017 13:45:53 -0000 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/arrangements.md From nobody Wed Oct 4 11:28:48 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF1B13445D for ; Wed, 4 Oct 2017 11:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 AIFyq7vYeRdh for ; Wed, 4 Oct 2017 11:28:45 -0700 (PDT) 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 4BF1413445C for ; Wed, 4 Oct 2017 11:28:45 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.42,478,1500966000"; d="asc'?scan'208";a="219501970" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx144-out.netapp.com with ESMTP; 04 Oct 2017 10:58:45 -0700 Received: from VMWEXCCAS11-PRD.hq.netapp.com (10.122.105.29) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 4 Oct 2017 11:28:40 -0700 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.1263.5 via Frontend Transport; Wed, 4 Oct 2017 11:28:40 -0700 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=LlTZ4387gRNOP+EliRNTJjPf6qy/nuX71u0Li21hz3Y=; b=b0M65UoH9bna1miYJAyk17nm7CdUtb+FkEkCltagq54opjZBac9QI2YgDYCpWGHeD7+XZqvDssZ/47RifUdZsUyxm+xaiLgqYnN06gtKcZ6frrY4L0SdBZ+WioYH6XRkqpRnhjTDFfO7yNQBrxibre3mUK6G84qVqIcYmVsttwA= 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.77.7; Wed, 4 Oct 2017 18:28: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.0077.018; Wed, 4 Oct 2017 18:28:38 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: QUIC interop at IETF-100 hackathon Thread-Topic: QUIC interop at IETF-100 hackathon Thread-Index: AQHTPT6YV42pZmN8Qk6OmPTjkZyY2g== Date: Wed, 4 Oct 2017 18:28:38 +0000 Message-ID: <61671212-35D2-46A4-8CD3-D7E2102ED312@netapp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3273) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [50.206.82.160] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 6:hgFBOo1XMuZsumSvAy6DkR8kgg85cXusI5PzBkD9bmAbRTAk6EdCzii6EjUC2Z4Qa3oRBoRFsUNbau9bohNa7SVeLEw/QKBuizxEMdg6rl3mwkfjEXD+Xx+VQknON5YDBFfhfmMpEJvgzf1nzcGFMSnfpea8cSvPinCasZmnEqUBltxsqwB7e4Lv5J6uXvBe4G9fybRoumecnyzd1JKuml5JMKKNZlVUu8KqQCOcprbXprOtdYj2/OnpIc+m2I44pQAzQi5SmvfXFA10zLX6ebu0MXrROCAgxuJNZVu3hzPGDp2S1DJQTCNAw4xrotvTuD0zQbdkUOIC1Q49dTwXTg==; 5:irwhiaSavwHDSkcpbbIP3mMFrGQ3q0nh45OlsA7KJz6RNQ3ul8C6gw3hx03+QvOyw2Hi60/9LteMbkHiug3shxiDMLte87NJuhpy6S5UG62RmmehDjOvVspD07p1HkwuAInGx2VWVyduhLq6GUFG+g==; 24:5oHCnZmens22tg/68rRTyF+wZeeCSKu4h6lhqZkEb0oVjnZeCyXHo+3HzRkEt5AMeXkEI8u9THIrBZ9NCe6nowQJ1hxgCf8ZWrCu6CvKaHk=; 7:BKPhBhdFfml+UxYiahDn7xEctZyICOu43EZMvLRKbhoYvr+4CB0mSPoq9oYreFMp9M9nB6Tm9Hj0Tn+UQV0hPcrsH/5DA/1eVto7B6U9cYPdeDJhnka4xSq5PwHbbyNB1tMA4R71OmOpPWcba+y9glimWdYjzWW5A0DqUTQjATs0CxvIOXxfKCM7r7fYGMz92cQzNk+QgRMuwubtqDfORo8ikfdNM85f1fo7Me3/X0E= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1e2285f7-21d3-4aa7-7b63-08d50b55bb8b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(49563074)(201703131423075)(201703031133081)(201702281549075); SRVR:BLUPR06MB1762; x-ms-traffictypediagnostic: BLUPR06MB1762: x-exchange-antispam-report-test: UriScan:(222300048226458); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(6041248)(20161123555025)(20161123558100)(20161123564025)(20161123562025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(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: 0450A714CB x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(199003)(189002)(6512007)(6916009)(14454004)(99936001)(57306001)(33656002)(6486002)(25786009)(189998001)(77096006)(101416001)(8936002)(66066001)(83716003)(6506006)(966005)(2900100001)(478600001)(68736007)(6436002)(50986999)(8676002)(97736004)(81156014)(106356001)(81166006)(105586002)(50226002)(316002)(53936002)(3280700002)(36756003)(2906002)(102836003)(3846002)(86362001)(305945005)(6116002)(5660300001)(7736002)(6306002)(82746002)(99286003)(3660700001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR06MB1762; 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=_D969EAE7-10D0-4436-AFC4-F1022B3DC576"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 Oct 2017 18:28:38.6743 (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, 04 Oct 2017 18:28:47 -0000 --Apple-Mail=_D969EAE7-10D0-4436-AFC4-F1022B3DC576 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I have registered a QUIC interop as a topic for the hackathon at = IETF-100. You need to please sign up (free) if you are planning on = attending, so that space and food can be provisioned accordingly: = https://www.ietf.org/registration/MeetingWiki/wiki/100hackathon Lars PS: The QUIC implementers are using a Slack channel at = https://quicdev.slack.com/ for coordination/discussion. Anyone can join, = but joining requires an invite - contact your chairs if you want to = join. (FWIW, the Slack channels are *not* covered under the IETF Note = Well, since the interop events aren't either.) --Apple-Mail=_D969EAE7-10D0-4436-AFC4-F1022B3DC576 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlnVKFQACgkQVLXDCb9w wVe2ERAAz6f9SEQSqmxcNh2Tk1gAsCCtY7VLtVgXrYQfx77do8ks9JFLE2d+Mxu1 zacrMLXH/NLTMx9TsA9EPSFdK+SI11yWGMfiPdLPsnv/OdYqiB2vRVmIxruXcINz uGRKFv0r7roT/MvKu8ycR8g1GuakDe6yp+c3dLQ1vERMpzl/KGcQXPWsqDBRScqa WiKPiNJXNSsIqMJtQcF5jN9bHZkuggSbhsYF9E3qGFkErH72eOtgTa0OgCnWkurv vdx4D6eB8kdn0UVhlaN/j70yAdrmaSI6zBJOsUpdTPJIS9FT5jM0nP87nVyRFma6 DqS0Nz7i459NrTjcFSPmAENt0N3wgDBWAFhuoGJ1i8xlWHfiJHe4tz9rQ9HN7uK3 jSY8Py0vEl5BAfo6fYoKKIVyfxwqKMLvNRHRoHoEjjmhHAUSmfMbyZddCDR6gaVC dDtxkfrdUX095ZWlr1anJPCJ4/KBnW95A9zJtjW6GLzFx1Bq8VQSOdJZ0M9UCBRO l5lz4F+b6CafPYbavqjLqefhYZGI9c2ZtNKK2JNCrPDyj8Ypn7vnuHImKH5pljMW QltXNxpqxTj2XeNkSLGcmiBiRmYtd2DU4X851uGs47pfLHhCgRAWpm34cS5CXu10 0Op/uZUO5a/BeQN3djMIF2NQB/LASVTJvwDFMh5du2Xq3XB0cO8= =zJRb -----END PGP SIGNATURE----- --Apple-Mail=_D969EAE7-10D0-4436-AFC4-F1022B3DC576-- From nobody Fri Oct 6 12:36: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 420171332D7 for ; Fri, 6 Oct 2017 12:35:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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=fRn1qKrA; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=S9GrRfsV Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pVykPVwqYewI for ; Fri, 6 Oct 2017 12:35:56 -0700 (PDT) Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C836E13293A for ; Fri, 6 Oct 2017 12:35:56 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 1EF0520C0E; Fri, 6 Oct 2017 15:35:56 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 06 Oct 2017 15:35:56 -0400 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 :x-sasl-enc; s=fm1; bh=8AgPmxWDgMYUIuv00JWvtSpaxDn6Xj5tmvlF3G6hh NQ=; b=fRn1qKrABycCqskybS5NDUltEPnYvvIVUOmbF/ogBqOJ441xANwEVqRc3 jkXrhS9QFZh4FtC7klp4NPIz884RX8C3ov2mmsAqh8UTc/MGrb5WuEv7oxTimSVn wd9cDHEBNrQfujvMrcCtR+zBnK9ZSWfN3Lblcx9S0DmYV40zvB+WQzN2i0BjtzJr caEuxp22GYqtHs9q/tZMLTNpvIBe8Osu1KrgP0F9KydJmAyO0sAUR4ptRFC7WVLc hiLtn+ChOBapEc2ZNhV+N3PT8wtzXzmdkIFnekqfi8p8BXpjtpw4WQtSzpRpWi1i OklGuCwJOR7P2jaklqi6vRo9FVysQ== 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:x-sasl-enc; s=fm1; bh=8AgPmxWDgMYUIuv00J WvtSpaxDn6Xj5tmvlF3G6hhNQ=; b=S9GrRfsVPTToOIIotWv8QCcHCv5TXxCIBV WlhBEsYfiOKtaGiXrTL1JEB9FbW2UUhrNbQWnNaDylvpzDIVdlJnchPOLPWkDlx7 Jr4Og5AzlgswDHuzDmY3NJPYRRaC27FwRiyDjHc2TANY/tmE2+SLM2MgxwHNrS7t HkeX5xYa+HrG5Y5sj3bOzRlMkGKAeTUss1wruv2kScodJ4YeUrRKxTqPn537++XR MBS3ybS+2vuCwjszglBeAjCI9j++MpiQ2xuFryzkxgmNqwA+kIW1MW4ci/sPSEwJ 9P8gTsekjJ2Z2KSxmEPS9/3I0NyJNsjuK2LryEXOrjPgedgpbV7Q== X-ME-Sender: X-Sasl-enc: YHAvcxZxMeT6dmkuuzTl7atUSpkhJUGtYAIWGxopTBiX 1507318555 Received: from [172.20.1.133] (unknown [208.186.24.154]) by mail.messagingengine.com (Postfix) with ESMTPA id 3F65E7F92C; Fri, 6 Oct 2017 15:35:55 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Subject: DRAFT minutes for Seattle interim Message-Id: Date: Fri, 6 Oct 2017 12:35:53 -0700 Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3445.1.6) 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, 06 Oct 2017 19:35:59 -0000 ... are available at: https://github.com/quicwg/wg-materials/blob/master/interim-17-10/minutes.md As always, corrections welcome, either as pull requests or through e-mail. Thanks again to our scribes: - Sean Turner - Roberto Peon - Martin Duke - Ted Hardie - Mike Bishop Likewise, thanks to F5 and Martin Duke for hosting the meeting. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Oct 6 23:37:46 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D263C1321A1 for ; Fri, 6 Oct 2017 23:37:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 zbSmkSFf8FM6 for ; Fri, 6 Oct 2017 23:37:44 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id CF9C9132025 for ; Fri, 6 Oct 2017 23:37:43 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v976bclX022999; Sat, 7 Oct 2017 08:37:38 +0200 Date: Sat, 7 Oct 2017 08:37:38 +0200 From: Willy Tarreau To: Mark Nottingham Cc: QUIC WG , Lars Eggert Subject: Re: DRAFT minutes for Seattle interim Message-ID: <20171007063738.GA22772@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Sat, 07 Oct 2017 06:37:46 -0000 On Fri, Oct 06, 2017 at 12:35:53PM -0700, Mark Nottingham wrote: > ... are available at: > https://github.com/quicwg/wg-materials/blob/master/interim-17-10/minutes.md Fairly detailed, thanks to the scribes! willy From nobody Mon Oct 9 03:46: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 BE2C41344C5 for ; Mon, 9 Oct 2017 03:46:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3zCIY1xBD1TS for ; Mon, 9 Oct 2017 03:46:05 -0700 (PDT) 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 63FF5134459 for ; Mon, 9 Oct 2017 03:46:05 -0700 (PDT) X-AuditID: c1b4fb3a-de7ff70000006897-a8-59db536b1641 Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 3C.BC.26775.B635BD95; Mon, 9 Oct 2017 12:46:03 +0200 (CEST) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.24) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 9 Oct 2017 12:46:03 +0200 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=nrGTNumS+eRqFOGduumkxt2lzIgkmrix38bTkKymIcI=; b=HeeKspK+pSkxAsll0lbn0kjXVPZfMnUgzCmRMQTxxLnMDA1t6MwTcNhLY+vQtB6SgCqpUAHeyA4nIePPCfE9mME1RXTHDqDZ6PyPpGalrqwHvWiwq+o7gUenJYPXXUho78UD37ilcgCvkqOLvMWAJ1kvTsb/UX8TbThNMIf1B8Q= 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.77.5; Mon, 9 Oct 2017 10:46:01 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.019; Mon, 9 Oct 2017 10:46:01 +0000 From: Ingemar Johansson S To: Mark Nottingham , QUIC WG CC: Lars Eggert Subject: ECN and Timestamps (was RE: DRAFT minutes for Seattle interim) Thread-Topic: ECN and Timestamps (was RE: DRAFT minutes for Seattle interim) Thread-Index: AdNA6wD3FhOBJ5FRRxKLPjB/mv0CgA== Date: Mon, 9 Oct 2017 10:46:01 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 6:bOtwb2m/mUeejcomR3eCBLiyEgopOn1g9n0kcJYebQdc53Z+BO24w0tjZZjU6oidxuxZoCjedgsjSECsLecKBpKlWOWputi3y8n4QNBlb0A3g1Qf+n1wVY25kVAL08yU1EaeH3S0ooJl0Q4yYzzwG6InKVLC8252pkKGKgWfiIBrm5zIWV2hJkdkU6nAIknhWT/EdnbBrdWnysNnGyuryGBxgbr9MJ6qzDjLFbCy83A9TRRhI8HLA9ogjCkGPSGDr5MUyCEPOpaI2qKnV8fA3wPSnv5fPRsHUhdRw8yc/RBxrEuN0l5i3zmLS8Q89lA+wfLkEzJ9DuGOe/orMeDeew==; 5:Gs7FYt6zgouP9F6BN+bBZAelgUqkzkgNrm+qOgx7VvO6iJPa76E3QFMr+pf+4qtivbI+b6xgeRFaZ05xtUuhUzwU8aspg0HJNtEyRrGReLX4st+M2fmwyHZ8SNYwF9QUcj1hnkJ97bQ+teeIaNnL7w==; 24:07qeyQ7H4jpTUiMEuQqhLT/NoXSFlC2ERfcFwap6Mbh6cefj0pjGQbyBvkAZLjHX/IzQw9JrAKHGdfwH9R3LopkEN271kx5NB7RMWuaZJzo=; 7:BtZi02JEju2R5NN2rdNSaqcQK8Bjz1jtAKNRRjyjn1wOjyANW7cVb40z/8WDgWU6qsXvyXQT/iMyET9tmOObz3D1TBtxK+OdkXAi0tgk/U37C3hKGQ8y7368FWeq5/PebMMeNJX0AvNa2eEBzfVDjIZnc42IuQoqU5++F7ukccJtxbtNMDRhotuBEnuED0JPIaog8lFhzcvYvx/S+l0f01zUqsOj4vFgdUnL7u8tOpE= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: b4543978-d9c5-4c49-a343-08d50f02eefa x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB4PR07MB348; x-ms-traffictypediagnostic: DB4PR07MB348: x-exchange-antispam-report-test: UriScan:(166708455590820); 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)(100000703101)(100105400095)(3002001)(93006095)(93001095)(10201501046)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123558100)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB348; x-forefront-prvs: 045584D28C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(979002)(6009001)(376002)(346002)(199003)(43784003)(189002)(13464003)(53936002)(5660300001)(14454004)(3846002)(6116002)(102836003)(68736007)(3660700001)(478600001)(5250100002)(106356001)(3280700002)(105586002)(66066001)(110136005)(316002)(97736004)(2906002)(86362001)(966005)(6506006)(2900100001)(4326008)(25786009)(6436002)(8676002)(101416001)(305945005)(81166006)(81156014)(8936002)(53546010)(54356999)(55016002)(74316002)(99286003)(50986999)(7736002)(33656002)(7696004)(189998001)(6306002)(9686003)(969003)(989001)(999001)(1009001)(1019001); 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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Oct 2017 10:46:01.5297 (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: H4sIAAAAAAAAA02Sa0hTcRjG/e9cPK6Gp+Xl1TRq6IdS54XSoSJKHxIyCPyQGlJDDzqc03bM VKjGRARTyhJSwXaiaSqFqeUyLXV5pctsaRcl84YWJuJUpijRtrOgb7/3eR6eP+/Ln8LEtwhf SqEqYNQquVJCCvG6FAOE5CRPp4Z19YbIfq5U4rI2ywKSVXL74rFEvX5HkNj+0Eok1lo2yXNY mjA2k1EqChl1aNwlYfb29mM8f0lYNHqnAtOgQaoCuVFAn4C55lGiAgkpMT2IoGFCi/HDCAIT V4PsA05XYbC2VOOM1QjAuFVO8sMMgs+1b0h7GUnHQovRiuzsYeOt3y2EnTH6KAw+tWJ2Pkif BmOdgeQzSTDePOFkKUw0TjryOB0A6+YPAjuL6DTQba44dET7ww/rDM53esPUok7AL0GDvteE 8ewJvxb+OPMZYPlWRfD6Edgzz5M8+4NZd9OxGtBlrsDNm3DekMLz6lXE81ngyr879QYE9/vE PB+Dbp3VqccAV9Zhe5iysQIG9rz5zjECdie1zh4/4Lglkje+EKAvNTkMMc3Aoydl6DYKqv9v IZ6DgeuxkDwHQdODFazecYwDMFa3iHMIb0WeLMOyuVkREVJGrchg2TyVVMUUdCDbNxl4thv9 Ag0sJxgRTSHJftHb6OlUMSEvZItzjQgoTOIhaoqySaJMeXEJo867qL6iZFgjOkThEm9R/Ovx FDGdJS9gchgmn1H/cwWUm68G5YX6zjbuuEe6dha9S5+d9xq60XkyuQjrDtMUJk3GYat3z2g2 ZPeuXgsYGbL4uLWvbvX3XY4y+ES+X+9KWdYy/cMbwaSlNJB1aes5LPGTBs7prw+Hf4y88OrT nmfSee3cqeJOsag6UFn51T1GNJXvkkCbX6ri1lq60ksMOi9ZjwRns+XhxzE1K/8LVwsiYiID 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: Mon, 09 Oct 2017 10:46:08 -0000 Hi Two comments on the discussion topics in the draft notes (thanks for produc= ing the notes) : + ECN: Yes, I would very much like to be in the ECN design team :-) + Timestamp: I get the feeling that there is discussions on removing the ti= mestamps. I have found ACK timestamps quite useful, these makes it possible= to implement LEDBAT style congestion controls, which we believe can be use= ful for e.g. low priority transport in wireless access. It is however not s= trictly necessary to have a timestamp for each and every packet in the ACKs= . In addition I don't see either that a floating point representation is ne= cessary. /Ingemar > -----Original Message----- > From: Mark Nottingham [mailto:mnot@mnot.net] > Sent: den 6 oktober 2017 21:36 > To: QUIC WG > Cc: Lars Eggert > Subject: DRAFT minutes for Seattle interim >=20 > ... are available at: > https://github.com/quicwg/wg-materials/blob/master/interim-17- > 10/minutes.md >=20 > As always, corrections welcome, either as pull requests or through e-mail= . >=20 > Thanks again to our scribes: > - Sean Turner > - Roberto Peon > - Martin Duke > - Ted Hardie > - Mike Bishop >=20 > Likewise, thanks to F5 and Martin Duke for hosting the meeting. >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 From nobody Mon Oct 9 07:03: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 B784B1342D4 for ; Mon, 9 Oct 2017 07:03:08 -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, 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 yI79TwXXa-C5 for ; Mon, 9 Oct 2017 07:03:01 -0700 (PDT) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87FFC126C0F for ; Mon, 9 Oct 2017 07:03:01 -0700 (PDT) Received: by mail-it0-x22c.google.com with SMTP id n195so12946502itg.2 for ; Mon, 09 Oct 2017 07:03:01 -0700 (PDT) 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=bMtVlq7eF6DWgNTSYYdBGyP54OcfHZtRlibi4MUUvq8=; b=E1omcTcqCSflGVaTrQ+GDfCtGI+yPW7M/sOxmwBXbIO4Qid8UNFEgipyL7r2fTzbkW 6d4kjdfVTDS3YYkaQksRQfE3USKPSCtpfUCu8x0P6Oezv13oR5t6uwOrVhu85N7T6lgF Rmkw3CdM6vuDA6XDzN9yvHij251p4Z/h4oNWMrMGa3dcnihRB1OcF2YoNXnoFMVEUf+p PovR8megNTUVNGTQdAjfszsA7rUmVTSyrkz0HL9uY07/DVwP/H8681mwdyYtLMdL+L/t yB3/S9quaHHNXwwAb9oCGw41ymdVbSV66KmMsGb60nw6Njq48c/L+z4r1ImsfTASeSZh wmKg== 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=bMtVlq7eF6DWgNTSYYdBGyP54OcfHZtRlibi4MUUvq8=; b=axYibNdoIAqnt5FzlHhBw5Wnfc37kBmyG/6ni4S0IqCBbhEBg2bv2qhDHWvw6EAtmh 4Zzfwwm0DlsdDhiZfDWWyeyo7wgMg0Jvkv8l4HAIcfc9XHpmEEdhAJSqhidYA8JvMTFA /OVlwHq9Mk401Bev8TUyoxxV4fa2C8jEYe5QHsLyviwJfTxv1PXNreh8nddhQP8IdPGd Bmrek/1UykVs0VnoDyuaRLl/KqLevdK23Vxflw8Fmx+bRh4O4LbBPRkn4r95G+Jn+ikN QYdjfK7DJtoAPIwX622Tc70fFZyODbNppCxUJHtK/WJDFxMHNfMK30R5AQabrSZycgIu M0cQ== X-Gm-Message-State: AMCzsaVH5bBOkuReZNqtqP3Iw1cDf/sMIink+zoPqbbJZdCI57dkwhkr yiBOFD8a1W/4Rkjma2LB7i6yDsnpRMUQVn4VOykvFQ== X-Google-Smtp-Source: AOwi7QCFdrYsJZY0w0I0UiztxUVFVsz8QVgzko93C/MSF1m7PDTwfRQ02d20mckd8/lEfSmKF9sb3O662ySc1nnrfSo= X-Received: by 10.36.3.141 with SMTP id e135mr14251640ite.1.1507557780616; Mon, 09 Oct 2017 07:03:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.30.133 with HTTP; Mon, 9 Oct 2017 07:02:39 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Mon, 9 Oct 2017 10:02:39 -0400 Message-ID: Subject: Re: ECN and Timestamps (was RE: DRAFT minutes for Seattle interim) To: Ingemar Johansson S Cc: Mark Nottingham , QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="001a1144d692fe7595055b1da50a" 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, 09 Oct 2017 14:03:08 -0000 --001a1144d692fe7595055b1da50a Content-Type: text/plain; charset="UTF-8" Thanks Ingemar. I agree that timestamps can be very useful. The agreement at the interim was to remove timestamps from the current draft and people interested in ECN and Timestamps will create a proposal for each, as well as a way to negotiate them. The timestamp proposal can be similar to the current one or completely different. One could imagine having multiple different timestamp and ECN formats for different congestion controllers, but I think it makes sense to focus on one of each initially. Would you be interested in working on an optional timestamp format as well as an ECN format? On Mon, Oct 9, 2017 at 6:46 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > Hi > Two comments on the discussion topics in the draft notes (thanks for > producing the notes) : > > + ECN: Yes, I would very much like to be in the ECN design team :-) > > + Timestamp: I get the feeling that there is discussions on removing the > timestamps. I have found ACK timestamps quite useful, these makes it > possible to implement LEDBAT style congestion controls, which we believe > can be useful for e.g. low priority transport in wireless access. It is > however not strictly necessary to have a timestamp for each and every > packet in the ACKs. In addition I don't see either that a floating point > representation is necessary. > > > /Ingemar > > > -----Original Message----- > > From: Mark Nottingham [mailto:mnot@mnot.net] > > Sent: den 6 oktober 2017 21:36 > > To: QUIC WG > > Cc: Lars Eggert > > Subject: DRAFT minutes for Seattle interim > > > > ... are available at: > > https://github.com/quicwg/wg-materials/blob/master/interim-17- > > 10/minutes.md > > > > As always, corrections welcome, either as pull requests or through > e-mail. > > > > Thanks again to our scribes: > > - Sean Turner > > - Roberto Peon > > - Martin Duke > > - Ted Hardie > > - Mike Bishop > > > > Likewise, thanks to F5 and Martin Duke for hosting the meeting. > > > > Cheers, > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > --001a1144d692fe7595055b1da50a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Ingemar.=C2=A0 I agree that timestamps can be very = useful.=C2=A0 The agreement at the interim was to remove timestamps from th= e current draft and people interested in ECN and Timestamps will create a p= roposal for each, as well as a way to negotiate them.=C2=A0 The timestamp p= roposal can be similar to the current one or completely different.=C2=A0 On= e could imagine having multiple different timestamp and ECN formats for dif= ferent congestion controllers, but I think it makes sense to focus on one o= f each initially.

Would you be interested in working on = an optional timestamp format as well as an ECN format?

On Mon, Oct 9, 2017 at 6:4= 6 AM, Ingemar Johansson S <ingemar.s.johansson@ericsson.com= > wrote:
Hi
Two comments on the discussion topics in the draft notes (thanks for produc= ing the notes) :

+ ECN: Yes, I would very much like to be in the ECN design team :-)

+ Timestamp: I get the feeling that there is discussions on removing the ti= mestamps. I have found ACK timestamps quite useful, these makes it possible= to implement LEDBAT style congestion controls, which we believe can be use= ful for e.g. low priority transport in wireless access. It is however not s= trictly necessary to have a timestamp for each and every packet in the ACKs= . In addition I don't see either that a floating point representation i= s necessary.


/Ingemar

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mn= ot.net]
> Sent: den 6 oktober 2017 21:36
> To: QUIC WG <quic@ietf.org>=
> Cc: Lars Eggert <lars@netapp.com= >
> Subject: DRAFT minutes for Seattle interim
>
> ... are available at:
>=C2=A0 =C2=A0https://github.com/qu= icwg/wg-materials/blob/master/interim-17-
> 10/= minutes.md
>
> As always, corrections welcome, either as pull requests or through e-m= ail.
>
> Thanks again to our scribes:
>=C2=A0 =C2=A0- Sean Turner
>=C2=A0 =C2=A0- Roberto Peon
>=C2=A0 =C2=A0- Martin Duke
>=C2=A0 =C2=A0- Ted Hardie
>=C2=A0 =C2=A0- Mike Bishop
>
> Likewise, thanks to F5 and Martin Duke for hosting the meeting.
>
> Cheers,
>
> --
> Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/
>


--001a1144d692fe7595055b1da50a-- From nobody Mon Oct 9 17:07: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 D2130132143 for ; Mon, 9 Oct 2017 17:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 nQ06S1Hks_oO for ; Mon, 9 Oct 2017 17:07:51 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D18AF120720 for ; Mon, 9 Oct 2017 17:07:50 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id w197so37919716oif.6 for ; Mon, 09 Oct 2017 17:07:50 -0700 (PDT) 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=SNSTbyAt+1M9GvuvjxSABkiYVV8n/kZxKNB8cqeMwto=; b=poO7TGGyxvDMNSewu7geq7dKE1V+mY3PFOhNAlHtGblUuDPccsXdOVEM8nj+4PEFnj 0U8xsA+t+AMAqhKScyeSRJgsXmlGsRzc+BL9ZXPzNp6K66DG6al6ovIIqz3n8mmFRQ0p xwvekEoBeS0jhMd6JLpmRhzZLunA/JHK8vSwaniCvQ1VAxKEHH1iMSd7YuwfczfzNFWO QhH1WYHRl+1/3iUQI7euLzpSMHzWZ/qIJ88lsSqkH4oUWrwulYVvlxudS0MxnbJkw6OO aOE9Av1/3WZ7DZCyBsI1/KLxxcwcqzwgDCSEigoh3OA1W87gGbv37A7tcxdg8oG7aplI GbwA== 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=SNSTbyAt+1M9GvuvjxSABkiYVV8n/kZxKNB8cqeMwto=; b=VpNMh+P8hgUYhkn4960h0O7TLAkCYHcZf1rRkIs6D690nw7RfNUKmuy/ldkuhjQEis rFvqPHf9QLZ0EZubEZx800DmlPriUweeSPsxL7WJV/XWSeb53WIebTNIIj6a4zQZgDLI 7AC4MdBFGi2Ni09SqlIztD7WlmMyksg4KknCQJ60otm+xUuOtdmLFRn//5OWfiJZWu22 wBcPHMWFICwR4b7LucWDuhwRwMBx9ii80rygiG4vkZ5I3hytz0HR32veEGgjcLTLhJ5g MHCjn9+BbYqHWEa8+K+Vu/M2WJo4BREro10JYhUeJ4UFnbBKFDKHIX3kJrIJJfImoyaI 6eQQ== X-Gm-Message-State: AMCzsaVC01u609LJcYhZCs6pq0CRnvJpJvEaPcWNSX6vlxQv4FNbgVEK wvw0v5ixaQpXOQG8WhAy9m1txq5+7iRMpW9xzOg/NQ== X-Google-Smtp-Source: AOwi7QBUNK5A+xFTGjsvweenDKwbhpcYUVlCSPqDK8PXI/f9US/luUz0Cc2PV1AG7Uft132EinHgrsIoyiJgEL7FICE= X-Received: by 10.202.166.141 with SMTP id t13mr6359834oij.392.1507594069902; Mon, 09 Oct 2017 17:07:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 17:07:49 -0700 (PDT) From: Martin Thomson Date: Tue, 10 Oct 2017 11:07:49 +1100 Message-ID: Subject: That means Client Initial as well 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: Tue, 10 Oct 2017 00:07:52 -0000 Just a heads up. I just merged PR #844, which adds AEAD protection to almost all packets. For people implementing, take special note: this applies to *Client Initial*. Only Version Negotiation and Stateless Reset are exempted from packet protection. From nobody Mon Oct 9 21:39: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 667AC1331FF for ; Mon, 9 Oct 2017 21:39:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 MTkY0avP7UgY for ; Mon, 9 Oct 2017 21:39:25 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 C4BCE132F3F for ; Mon, 9 Oct 2017 21:39:25 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id n82so35937367oig.3 for ; Mon, 09 Oct 2017 21:39:25 -0700 (PDT) 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=c25HD1vF0mRcLBDvf2z9c3XETaTfghCvLH4vPyFfUpY=; b=qM/rz1zz3ZoJZf7s9QxbKyWk7lKGlk/N01TXuGEG77io6qPIbzEYCLbyZ0YoEFpChc 9PlR2Bwy5nAl2V4a2qAi29eYe3fcipAMgQ+FjDA8nnBthE5ZHbA+UHWq0NnHzJhsGZlo Y1Wf6XR9bU8UH2sfQvq3j66oAjTghZsBswRan6Nr/4HLCve+k8+lVRbRlKVfHhJypJUO nenLh0aes/Owm1s5Jc1FOx+18zNkQosoPSdMxy9fj421+ICmYsOqyAGk67xWb+cCD3U3 Cl/oJrgg6N5sr02UwaRHzq23QVoKm1NgH7oHOIUsEn59q3ZeCKZDnMZNTbszEc34sFri 2bYA== 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=c25HD1vF0mRcLBDvf2z9c3XETaTfghCvLH4vPyFfUpY=; b=nUtkTsf5Ck38I93F3XY8H+pz7R/kPhfNuzFMIDbVw2UYhQtVQJ1sCPA6YvCrQef4Cz fWAEghMG+leB0113SQ8F9vERgQ0WcxVuRhS4pi+rnZtkDS9qT2RpCQ3rrL0oqsxVJOJd IqLsI1896VsFQovpzn/xZCY+Tm2JkIaEBMrsvuCUOSDiEbBAtPNi1Aorhwa9sVGCtLou fbgs0lQ4/3FkY2ACNpu/wfz/uF4KCBbk8MKIiK3N2HovT9lWQ2PTW/7LMnpPsODOfXOQ Cg3iyi5M7J49qIIkIrd1AhLFfiCuS5jGamMAjSo3yBcUYwdybTGvJKkjDwPVd6D+gdJf LCNw== X-Gm-Message-State: AMCzsaXU/X+gCm6Y4wMMIZna7LHLBNMSs1oExZ9DcjaMj3DXXr7SfWNx +m3RqgOzeZ+2T7tA5epmmEQaESLfGIgyciEOHJGg1xjm X-Google-Smtp-Source: AOwi7QDTOWzZqyVDZI8u1a5DLvXlWvSMOd3cEMwUzlUO6iTOkPe0MWaAyyIR705jnhnLDGCinzcghtdsaP1hGlOqqLA= X-Received: by 10.157.43.183 with SMTP id u52mr892552ota.44.1507610364913; Mon, 09 Oct 2017 21:39:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 9 Oct 2017 21:39:24 -0700 (PDT) From: Martin Thomson Date: Tue, 10 Oct 2017 15:39:24 +1100 Message-ID: Subject: Stateless reset tweak 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: Tue, 10 Oct 2017 04:39:27 -0000 https://github.com/quicwg/base-drafts/pull/842 ekr pointed out that handling a stateless reset is a little tricky because the payload overlaps with the header. After some discussion (on #820), we concluded that the easiest way to solve this problem was to put the token at the very end of the packet. This makes the packet more easily identified by clients, because the token is always in the same place no matter what flags or packet type is used. Does anyone think that this is a bad idea? I'd like to integrate this into -07. From nobody Mon Oct 9 22:39: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 AAEA213219B for ; Mon, 9 Oct 2017 22:39:32 -0700 (PDT) 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 s-MKJ9LuFylF for ; Mon, 9 Oct 2017 22:39:30 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3142E13202D for ; Mon, 9 Oct 2017 22:39:30 -0700 (PDT) X-AuditID: c1b4fb2d-bddff7000000268d-17-59dc5d0f7357 Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 21.68.09869.F0D5CD95; Tue, 10 Oct 2017 07:39:28 +0200 (CEST) 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, 10 Oct 2017 07:39:27 +0200 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=QwdSSZEeBhlsh1rc9y4aen/5IXOc7emugYYCoV/kaUk=; b=ei32R/dZd9w+jLekc2+Q25u3R6nvuNRcz/v7md9x9YT3+8mJYbXdvasMLVOmXfQDVx99gPa9O+Z4Vlh5CwkPObzzMcLPw4J9ulCFTzriyT32QQNRk8qd/ZDMTy2Wk0uYKbZmFdltAmdb65yQWhMnCsL5EJiPUwwo+yY1yma/E6w= 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.77.5; Tue, 10 Oct 2017 05:39:26 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.020; Tue, 10 Oct 2017 05:39:25 +0000 From: Ingemar Johansson S To: Ian Swett CC: Mark Nottingham , QUIC WG , Lars Eggert , Ingemar Johansson S Subject: RE: ECN and Timestamps (was RE: DRAFT minutes for Seattle interim) Thread-Topic: ECN and Timestamps (was RE: DRAFT minutes for Seattle interim) Thread-Index: AdNA6wD3FhOBJ5FRRxKLPjB/mv0CgAAHENSAAANx4QA= Date: Tue, 10 Oct 2017 05:39:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB345; 6:ZrhQZFE1WXTqHK6lciH0x6ew79+HgAIlrCUEVgUKpvcbOwXXbklD14ABQbdHaMdjFyaMDnFinXWZcg+ptxVcUTPLKOVwbCxHQPrRyl7IDN2ZEkT0UQoa4tuWJRSht0FcECxhlIVXBJjEAN+FukKo7bJAQulOKV3vxC0AKrBdoewbZQXcYTi4SZT2Cuq+6T+l3eugbvvm7LLJRpWrQBPBNL1OJRAuaidqApX8THRIr9b29SE9CszlJYDDaM56BMdXnaJEHDmEy6zpsy3Hn5c1AY1lKDsjcEFN+AXTvrH+72RXd4btaVja3uTP5UxBu6l61nLceWlMpD3IzRIlbzgWfw==; 5:nyILDRC6NxtrjXpGK79kF3W0jxVqGycNsSQDPzo/I+7wv+5GTyR9XxoK3DyIsQaDvehd6+kKe/1GJjTrGidTo+xiveZIvKGkaJfGdTxqoZzccbfWqe2AuuRrz4YzIyzAf79wErgcb+gs29WzTi3umQ==; 24:DWCEBjfMjYcpdNZfbfyFlc5sXtoLDDKM02fQ+tMm/apijM1q7j2QP9r0oVVgEgHHnRGlFSp7Z2BnRkHc0ElKhXSI9SARsotHtOSaWkcaL34=; 7:EPo1MI0do+/W1LtUU/Ti9uj1pivVKAdjH2UkKdLqwBgdpoxBs7kYCzNF+5mjo8EqrHgJXNYRnQXZBHP3T4f2Rx93e18Naolwmt9slyCgfiZBHO91SYyctI1BCqG5Q/hKQNgkONvhQ3VMJlqR7QgO2QoMChiy7YVBiO8uQSqJElP/zNtmDVJxeQ0GVeFNsVCtlAfJvGuPBT91CeFgCvapkWxfByZGsmRc8CLFQMo6ceE= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(189002)(43784003)(51444003)(13464003)(199003)(24454002)(377454003)(55016002)(34040400001)(8676002)(99286003)(53936002)(606006)(105586002)(5250100002)(6306002)(106356001)(8936002)(97736004)(54896002)(3846002)(14454004)(86362001)(33656002)(561944003)(81156014)(2906002)(189998001)(9686003)(81166006)(236005)(6116002)(790700001)(478600001)(101416001)(5660300001)(3660700001)(66066001)(53546010)(54906003)(3280700002)(966005)(2950100002)(6916009)(102836003)(316002)(7696004)(25786009)(68736007)(6506006)(6436002)(74316002)(76176999)(54356999)(50986999)(6246003)(107886003)(53386004)(19609705001)(229853002)(7736002)(2900100001)(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; x-ms-office365-filtering-correlation-id: f5481ea2-6cad-468d-c08e-08d50fa14447 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); 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)(166708455590820)(211936372134217)(21748063052155); 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)(93006095)(93001095)(3002001)(100000703101)(100105400095)(920507026)(6041248)(20161123555025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(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: 04569283F9 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_DB4PR07MB348C4AC13E2FC4A1ADC670DC2750DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Oct 2017 05:39:25.0935 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB345 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHKsWRmVeSWpSXmKPExsUyM2K7oq5A7J1Ig6udYhY/7+1ktXjxuofF Yv2nx4wWPQu4HVg8Fmwq9Viy5CeTx8bF31k9Znz6whbAEsVlk5Kak1mWWqRvl8CVce3WF7aC J5UVTcuOMTcwHijrYuTkkBAwkZj5ajtrFyMXh5DAEUaJhhefmCGcE4wSWyYcZAFxWAR6mSU+ /+hmh8hMZZL4v/USVNl9oJ7z01hBhrEJ2EisPPSdEcQWEVCWOHpnEiNIEbPAVEaJUx9usYMk hAW8Jdq3/4Iq8pG4sOIKG4RtJfF90RSwOIuAqsTD421gQ3kFoiQm931igti2kFHi2oGdTCAJ ToFAiSWzT4MNZRSQlbj//R4LiM0sIC5x68l8Joj3BCSW7DnPDGGLSrx8/I8VwlaQ+HPpERuE LStxaX432KUSAq3sEmemTmWHSBhLdE3YwwqRuMsmcXXxRCCHA8jxlXh8BaphLqPEpf1tUA2a Eo8m/GCGuChZ4tPNXqhtORK/dvdC1WRKrNn0AKr5CqvEuz2n2CYw6sxCcjmEnS/x4cxJxlng IBCUODnzCcssoN3MQDvW79KHKFGUmNL9kB3C1pBonTOXHVl8ASP7KkbR4tTi4tx0I2O91KLM 5OLi/Dy9vNSSTYzAVHVwy2/dHYyrXzseYhTgYFTi4e31uRMpxJpYVlyZe4hRgoNZSYQ3RBko xJuSWFmVWpQfX1Sak1p8iFGag0VJnNdh34UIIYH0xJLU7NTUgtQimCwTB6dUA6Pwm6ySWG/9 SC9VS8GQzSe011z+1Pr6/lRHlTWverc7u348ad55rfbLG40fcZ1pnzbIpQe6iqTsdt4y5bXa /w+irBYTcm3c5TXlzUvtXRf9XFRda3z84fHQf5vepVgJqvo27DRwcF/QWr6OP0v16ur3vJpy a9RNtS+e2bL48fR3F1zcAyPLJiuxFGckGmoxFxUnAgAlGhSpUQMAAA== 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, 10 Oct 2017 05:39:33 -0000 --_000_DB4PR07MB348C4AC13E2FC4A1ADC670DC2750DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 T0ssIHRoZW4gSSB1bmRlcnN0YW5kLg0KDQpQZXJoYXBzIGEgbGF0ZXIgaGVhZGFjaGUgYnV04oCm DQpJZiBJIHRha2UgU0NSZUFNIGFzIGFuIGV4YW1wbGUsIGluIGl0cyBiYXNpYyBmb3JtIGl0IHdv cmtzIHdpdGggdGltZXN0YW1wIChhbmQgbm9ybWFsIEFDS3MgdGhhdCBpbmRpY2F0ZSBwYWNrZXQg bG9zcyksIEVDTiAgZmVlZGJhY2sgaXMgYWxzbyB1c2VkIGlmIGVuYWJsZWQsIGJ1dCB0aGUgZGVs YXkgYmFzZWQgY29uZ2VzdGlvbiBjb250cm9sIGlzIGFsd2F5cyBhY3RpdmUsIGluIG90aGVyIHdv cmRzIHRoZXJlIGlzIG5vIGhhcmQgc3dpdGNoIGJldHdlZW4gbG9zcyBiYXNlZCwgZGVsYXkgYmFz ZWQgYW5kICBFQ04gYmFzZWQgY29uZ2VzdGlvbiBjb250cm9sLg0KVGhlIGZlZWRiYWNrIGZvciBh bGwgb2YgdGhpcyBpcyBidW5kbGVkIGludG8gdGhlIHNhbWUgUlRDUCBBQ0sgcGFja2V0LCBzb2Zh ciBhIHByb3ByaWV0YXJ5IG5vbi1zdGFuZGFyZGl6ZWQgUlRDUC4gQSAxNiBiaXQgRUNOLUNFIG1h cmtlZCBieXRlcyBjb3VudGVyIGlzIGFsd2F5cyBwcmVzZW50IGluIHRoZSBmZWVkYmFjayBldmVu IHRob3VnaCBFQ04gaXMgbm90IGVuYWJsZWQuDQoNCkluIHRoZSBRVUlDIGNhc2UgSSB1bmRlcnN0 YW5kIHRoYXQgdGhlcmUgaXMgYSB3aXNoIHRvIGNyZWF0ZSBuZXcgZnJhbWUgdHlwZXMgZm9yIHRp bWVzdGFtcHMgYW5kIEVDTi4gSW4gdGhlIHdvcnN0IGNhc2Ugd2UgZ2V0IHRoZSBmb2xsb3dpbmcg QUNLIGZyYW1lIHR5cGVzIDoNCkFDSw0KQUNLICsgVFMNCkFDSyArIEVDTg0KQUNLICsgVFMgKyBF Q04NCk9yIGRvIEkgbWlzdW5kZXJzdGFuZCA/DQoNClRvIHlvdXIgcXVlc3Rpb24sIHllcywgSSB0 aGluayB0aGF0IEkgY2FuIGpvaW4gdGhlIHRpbWVzdGFtcCBkZXNpZ24gdGVhbSBhcyB3ZWxsIGlm IE9rIHdpdGggeW91Lg0KDQovSW5nZW1hcg0KDQpGcm9tOiBJYW4gU3dldHQgW21haWx0bzppYW5z d2V0dEBnb29nbGUuY29tXQ0KU2VudDogZGVuIDkgb2t0b2JlciAyMDE3IDE2OjAzDQpUbzogSW5n ZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+DQpDYzog TWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47 IExhcnMgRWdnZXJ0IDxsYXJzQG5ldGFwcC5jb20+DQpTdWJqZWN0OiBSZTogRUNOIGFuZCBUaW1l c3RhbXBzICh3YXMgUkU6IERSQUZUIG1pbnV0ZXMgZm9yIFNlYXR0bGUgaW50ZXJpbSkNCg0KVGhh bmtzIEluZ2VtYXIuICBJIGFncmVlIHRoYXQgdGltZXN0YW1wcyBjYW4gYmUgdmVyeSB1c2VmdWwu ICBUaGUgYWdyZWVtZW50IGF0IHRoZSBpbnRlcmltIHdhcyB0byByZW1vdmUgdGltZXN0YW1wcyBm cm9tIHRoZSBjdXJyZW50IGRyYWZ0IGFuZCBwZW9wbGUgaW50ZXJlc3RlZCBpbiBFQ04gYW5kIFRp bWVzdGFtcHMgd2lsbCBjcmVhdGUgYSBwcm9wb3NhbCBmb3IgZWFjaCwgYXMgd2VsbCBhcyBhIHdh eSB0byBuZWdvdGlhdGUgdGhlbS4gIFRoZSB0aW1lc3RhbXAgcHJvcG9zYWwgY2FuIGJlIHNpbWls YXIgdG8gdGhlIGN1cnJlbnQgb25lIG9yIGNvbXBsZXRlbHkgZGlmZmVyZW50LiAgT25lIGNvdWxk IGltYWdpbmUgaGF2aW5nIG11bHRpcGxlIGRpZmZlcmVudCB0aW1lc3RhbXAgYW5kIEVDTiBmb3Jt YXRzIGZvciBkaWZmZXJlbnQgY29uZ2VzdGlvbiBjb250cm9sbGVycywgYnV0IEkgdGhpbmsgaXQg bWFrZXMgc2Vuc2UgdG8gZm9jdXMgb24gb25lIG9mIGVhY2ggaW5pdGlhbGx5Lg0KDQpXb3VsZCB5 b3UgYmUgaW50ZXJlc3RlZCBpbiB3b3JraW5nIG9uIGFuIG9wdGlvbmFsIHRpbWVzdGFtcCBmb3Jt YXQgYXMgd2VsbCBhcyBhbiBFQ04gZm9ybWF0Pw0KDQpPbiBNb24sIE9jdCA5LCAyMDE3IGF0IDY6 NDYgQU0sIEluZ2VtYXIgSm9oYW5zc29uIFMgPGluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24u Y29tPG1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KSGkN ClR3byBjb21tZW50cyBvbiB0aGUgZGlzY3Vzc2lvbiB0b3BpY3MgaW4gdGhlIGRyYWZ0IG5vdGVz ICh0aGFua3MgZm9yIHByb2R1Y2luZyB0aGUgbm90ZXMpIDoNCg0KKyBFQ046IFllcywgSSB3b3Vs ZCB2ZXJ5IG11Y2ggbGlrZSB0byBiZSBpbiB0aGUgRUNOIGRlc2lnbiB0ZWFtIDotKQ0KDQorIFRp bWVzdGFtcDogSSBnZXQgdGhlIGZlZWxpbmcgdGhhdCB0aGVyZSBpcyBkaXNjdXNzaW9ucyBvbiBy ZW1vdmluZyB0aGUgdGltZXN0YW1wcy4gSSBoYXZlIGZvdW5kIEFDSyB0aW1lc3RhbXBzIHF1aXRl IHVzZWZ1bCwgdGhlc2UgbWFrZXMgaXQgcG9zc2libGUgdG8gaW1wbGVtZW50IExFREJBVCBzdHls ZSBjb25nZXN0aW9uIGNvbnRyb2xzLCB3aGljaCB3ZSBiZWxpZXZlIGNhbiBiZSB1c2VmdWwgZm9y IGUuZy4gbG93IHByaW9yaXR5IHRyYW5zcG9ydCBpbiB3aXJlbGVzcyBhY2Nlc3MuIEl0IGlzIGhv d2V2ZXIgbm90IHN0cmljdGx5IG5lY2Vzc2FyeSB0byBoYXZlIGEgdGltZXN0YW1wIGZvciBlYWNo IGFuZCBldmVyeSBwYWNrZXQgaW4gdGhlIEFDS3MuIEluIGFkZGl0aW9uIEkgZG9uJ3Qgc2VlIGVp dGhlciB0aGF0IGEgZmxvYXRpbmcgcG9pbnQgcmVwcmVzZW50YXRpb24gaXMgbmVjZXNzYXJ5Lg0K DQoNCi9JbmdlbWFyDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogTWFy ayBOb3R0aW5naGFtIFttYWlsdG86bW5vdEBtbm90Lm5ldDxtYWlsdG86bW5vdEBtbm90Lm5ldD5d DQo+IFNlbnQ6IGRlbiA2IG9rdG9iZXIgMjAxNyAyMTozNg0KPiBUbzogUVVJQyBXRyA8cXVpY0Bp ZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4+DQo+IENjOiBMYXJzIEVnZ2VydCA8bGFyc0Bu ZXRhcHAuY29tPG1haWx0bzpsYXJzQG5ldGFwcC5jb20+Pg0KPiBTdWJqZWN0OiBEUkFGVCBtaW51 dGVzIGZvciBTZWF0dGxlIGludGVyaW0NCj4NCj4gLi4uIGFyZSBhdmFpbGFibGUgYXQ6DQo+ICAg aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy93Zy1tYXRlcmlhbHMvYmxvYi9tYXN0ZXIvaW50ZXJp bS0xNy0NCj4gMTAvbWludXRlcy5tZDxodHRwOi8vbWludXRlcy5tZD4NCj4NCj4gQXMgYWx3YXlz LCBjb3JyZWN0aW9ucyB3ZWxjb21lLCBlaXRoZXIgYXMgcHVsbCByZXF1ZXN0cyBvciB0aHJvdWdo IGUtbWFpbC4NCj4NCj4gVGhhbmtzIGFnYWluIHRvIG91ciBzY3JpYmVzOg0KPiAgIC0gU2VhbiBU dXJuZXINCj4gICAtIFJvYmVydG8gUGVvbg0KPiAgIC0gTWFydGluIER1a2UNCj4gICAtIFRlZCBI YXJkaWUNCj4gICAtIE1pa2UgQmlzaG9wDQo+DQo+IExpa2V3aXNlLCB0aGFua3MgdG8gRjUgYW5k IE1hcnRpbiBEdWtlIGZvciBob3N0aW5nIHRoZSBtZWV0aW5nLg0KPg0KPiBDaGVlcnMsDQo+DQo+ IC0tDQo+IE1hcmsgTm90dGluZ2hhbSAgIGh0dHBzOi8vd3d3Lm1ub3QubmV0Lw0KPg0KDQo= --_000_DB4PR07MB348C4AC13E2FC4A1ADC670DC2750DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uaG9lbnpiDQoJe21zby1zdHls ZS1uYW1lOmhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3 aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5 Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 MC44NXB0IDcwLjg1cHQgNzAuODVwdCA3MC44NXB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFn ZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtl bmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJl ZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0 PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPk9LLCB0aGVuIEkgdW5kZXJzdGFuZC4gPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlBlcmhhcHMgYSBsYXRlciBoZWFkYWNoZSBidXTigKY8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPklmIEkgdGFrZSBTQ1JlQU0gYXMgYW4gZXhhbXBsZSwgaW4gaXRzIGJh c2ljIGZvcm0gaXQgd29ya3Mgd2l0aCB0aW1lc3RhbXAgKGFuZCBub3JtYWwgQUNLcyB0aGF0IGlu ZGljYXRlIHBhY2tldCBsb3NzKSwgRUNOICZuYnNwO2ZlZWRiYWNrIGlzIGFsc28gdXNlZCBpZiBl bmFibGVkLCBidXQgdGhlIGRlbGF5IGJhc2VkIGNvbmdlc3Rpb24gY29udHJvbCBpcyBhbHdheXMg YWN0aXZlLCBpbiBvdGhlciB3b3JkcyB0aGVyZQ0KIGlzIG5vIGhhcmQgc3dpdGNoIGJldHdlZW4g bG9zcyBiYXNlZCwgZGVsYXkgYmFzZWQgYW5kICZuYnNwO0VDTiBiYXNlZCBjb25nZXN0aW9uIGNv bnRyb2wuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZmVlZGJhY2sg Zm9yIGFsbCBvZiB0aGlzIGlzIGJ1bmRsZWQgaW50byB0aGUgc2FtZSBSVENQIEFDSyBwYWNrZXQs IHNvZmFyIGEgcHJvcHJpZXRhcnkgbm9uLXN0YW5kYXJkaXplZCBSVENQLiBBIDE2IGJpdCBFQ04t Q0UgbWFya2VkIGJ5dGVzIGNvdW50ZXIgaXMgYWx3YXlzIHByZXNlbnQgaW4gdGhlIGZlZWRiYWNr IGV2ZW4gdGhvdWdoIEVDTiBpcyBub3QgZW5hYmxlZC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JbiB0aGUgUVVJQyBjYXNlIEkgdW5kZXJzdGFuZCB0aGF0IHRoZXJlIGlzIGEgd2lzaCB0byBj cmVhdGUgbmV3IGZyYW1lIHR5cGVzIGZvciB0aW1lc3RhbXBzIGFuZCBFQ04uIEluIHRoZSB3b3Jz dCBjYXNlIHdlIGdldCB0aGUgZm9sbG93aW5nIEFDSyBmcmFtZSB0eXBlcyA6DQo8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFDSzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+QUNLICYjNDM7IFRTPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5BQ0sgJiM0MzsgRUNOPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5B Q0sgJiM0MzsgVFMgJiM0MzsgRUNOPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5PciBkbyBJIG1pc3VuZGVyc3RhbmQgPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UbyB5b3Vy IHF1ZXN0aW9uLCB5ZXMsIEkgdGhpbmsgdGhhdCBJIGNhbiBqb2luIHRoZSB0aW1lc3RhbXAgZGVz aWduIHRlYW0gYXMgd2VsbCBpZiBPayB3aXRoIHlvdS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4vSW5nZW1hcjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBJ YW4gU3dldHQgW21haWx0bzppYW5zd2V0dEBnb29nbGUuY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4g ZGVuIDkgb2t0b2JlciAyMDE3IDE2OjAzPGJyPg0KPGI+VG86PC9iPiBJbmdlbWFyIEpvaGFuc3Nv biBTICZsdDtpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSZndDs8YnI+DQo8Yj5DYzo8 L2I+IE1hcmsgTm90dGluZ2hhbSAmbHQ7bW5vdEBtbm90Lm5ldCZndDs7IFFVSUMgV0cgJmx0O3F1 aWNAaWV0Zi5vcmcmZ3Q7OyBMYXJzIEVnZ2VydCAmbHQ7bGFyc0BuZXRhcHAuY29tJmd0Ozxicj4N CjxiPlN1YmplY3Q6PC9iPiBSZTogRUNOIGFuZCBUaW1lc3RhbXBzICh3YXMgUkU6IERSQUZUIG1p bnV0ZXMgZm9yIFNlYXR0bGUgaW50ZXJpbSk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgSW5nZW1hci4mbmJzcDsgSSBhZ3JlZSB0aGF0IHRpbWVz dGFtcHMgY2FuIGJlIHZlcnkgdXNlZnVsLiZuYnNwOyBUaGUgYWdyZWVtZW50IGF0IHRoZSBpbnRl cmltIHdhcyB0byByZW1vdmUgdGltZXN0YW1wcyBmcm9tIHRoZSBjdXJyZW50IGRyYWZ0IGFuZCBw ZW9wbGUgaW50ZXJlc3RlZCBpbiBFQ04gYW5kIFRpbWVzdGFtcHMgd2lsbCBjcmVhdGUgYSBwcm9w b3NhbCBmb3IgZWFjaCwgYXMgd2VsbCBhcyBhIHdheSB0bw0KIG5lZ290aWF0ZSB0aGVtLiZuYnNw OyBUaGUgdGltZXN0YW1wIHByb3Bvc2FsIGNhbiBiZSBzaW1pbGFyIHRvIHRoZSBjdXJyZW50IG9u ZSBvciBjb21wbGV0ZWx5IGRpZmZlcmVudC4mbmJzcDsgT25lIGNvdWxkIGltYWdpbmUgaGF2aW5n IG11bHRpcGxlIGRpZmZlcmVudCB0aW1lc3RhbXAgYW5kIEVDTiBmb3JtYXRzIGZvciBkaWZmZXJl bnQgY29uZ2VzdGlvbiBjb250cm9sbGVycywgYnV0IEkgdGhpbmsgaXQgbWFrZXMgc2Vuc2UgdG8g Zm9jdXMgb24gb25lIG9mIGVhY2gNCiBpbml0aWFsbHkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Xb3VsZCB5b3UgYmUgaW50ZXJlc3RlZCBpbiB3b3JraW5n IG9uIGFuIG9wdGlvbmFsIHRpbWVzdGFtcCBmb3JtYXQgYXMgd2VsbCBhcyBhbiBFQ04gZm9ybWF0 PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5P biBNb24sIE9jdCA5LCAyMDE3IGF0IDY6NDYgQU0sIEluZ2VtYXIgSm9oYW5zc29uIFMgJmx0Ozxh IGhyZWY9Im1haWx0bzppbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNvbSIgdGFyZ2V0PSJf YmxhbmsiPmluZ2VtYXIucy5qb2hhbnNzb25AZXJpY3Nzb24uY29tPC9hPiZndDsgd3JvdGU6PG86 cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6 c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDYuMHB0O21hcmdpbi1sZWZ0 OjQuOHB0O21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLXJpZ2h0OjBjbTttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+ SGk8YnI+DQpUd28gY29tbWVudHMgb24gdGhlIGRpc2N1c3Npb24gdG9waWNzIGluIHRoZSBkcmFm dCBub3RlcyAodGhhbmtzIGZvciBwcm9kdWNpbmcgdGhlIG5vdGVzKSA6PGJyPg0KPGJyPg0KJiM0 MzsgRUNOOiBZZXMsIEkgd291bGQgdmVyeSBtdWNoIGxpa2UgdG8gYmUgaW4gdGhlIEVDTiBkZXNp Z24gdGVhbSA6LSk8YnI+DQo8YnI+DQomIzQzOyBUaW1lc3RhbXA6IEkgZ2V0IHRoZSBmZWVsaW5n IHRoYXQgdGhlcmUgaXMgZGlzY3Vzc2lvbnMgb24gcmVtb3ZpbmcgdGhlIHRpbWVzdGFtcHMuIEkg aGF2ZSBmb3VuZCBBQ0sgdGltZXN0YW1wcyBxdWl0ZSB1c2VmdWwsIHRoZXNlIG1ha2VzIGl0IHBv c3NpYmxlIHRvIGltcGxlbWVudCBMRURCQVQgc3R5bGUgY29uZ2VzdGlvbiBjb250cm9scywgd2hp Y2ggd2UgYmVsaWV2ZSBjYW4gYmUgdXNlZnVsIGZvciBlLmcuIGxvdyBwcmlvcml0eSB0cmFuc3Bv cnQNCiBpbiB3aXJlbGVzcyBhY2Nlc3MuIEl0IGlzIGhvd2V2ZXIgbm90IHN0cmljdGx5IG5lY2Vz c2FyeSB0byBoYXZlIGEgdGltZXN0YW1wIGZvciBlYWNoIGFuZCBldmVyeSBwYWNrZXQgaW4gdGhl IEFDS3MuIEluIGFkZGl0aW9uIEkgZG9uJ3Qgc2VlIGVpdGhlciB0aGF0IGEgZmxvYXRpbmcgcG9p bnQgcmVwcmVzZW50YXRpb24gaXMgbmVjZXNzYXJ5Ljxicj4NCjxicj4NCjxicj4NCi9JbmdlbWFy PGJyPg0KPGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgRnJv bTogTWFyayBOb3R0aW5naGFtIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1ub3RAbW5vdC5uZXQi Pm1ub3RAbW5vdC5uZXQ8L2E+XTxicj4NCiZndDsgU2VudDogZGVuIDYgb2t0b2JlciAyMDE3IDIx OjM2PGJyPg0KJmd0OyBUbzogUVVJQyBXRyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5v cmciPnF1aWNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgQ2M6IExhcnMgRWdnZXJ0ICZsdDs8 YSBocmVmPSJtYWlsdG86bGFyc0BuZXRhcHAuY29tIj5sYXJzQG5ldGFwcC5jb208L2E+Jmd0Ozxi cj4NCiZndDsgU3ViamVjdDogRFJBRlQgbWludXRlcyBmb3IgU2VhdHRsZSBpbnRlcmltPGJyPg0K Jmd0Ozxicj4NCiZndDsgLi4uIGFyZSBhdmFpbGFibGUgYXQ6PGJyPg0KJmd0OyZuYnNwOyAmbmJz cDs8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL3dnLW1hdGVyaWFscy9ibG9iL21h c3Rlci9pbnRlcmltLTE3LSIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZ2l0aHViLmNvbS9xdWlj d2cvd2ctbWF0ZXJpYWxzL2Jsb2IvbWFzdGVyL2ludGVyaW0tMTctPC9hPjxicj4NCiZndDsgMTAv PGEgaHJlZj0iaHR0cDovL21pbnV0ZXMubWQiIHRhcmdldD0iX2JsYW5rIj5taW51dGVzLm1kPC9h Pjxicj4NCiZndDs8YnI+DQomZ3Q7IEFzIGFsd2F5cywgY29ycmVjdGlvbnMgd2VsY29tZSwgZWl0 aGVyIGFzIHB1bGwgcmVxdWVzdHMgb3IgdGhyb3VnaCBlLW1haWwuPGJyPg0KJmd0Ozxicj4NCiZn dDsgVGhhbmtzIGFnYWluIHRvIG91ciBzY3JpYmVzOjxicj4NCiZndDsmbmJzcDsgJm5ic3A7LSBT ZWFuIFR1cm5lcjxicj4NCiZndDsmbmJzcDsgJm5ic3A7LSBSb2JlcnRvIFBlb248YnI+DQomZ3Q7 Jm5ic3A7ICZuYnNwOy0gTWFydGluIER1a2U8YnI+DQomZ3Q7Jm5ic3A7ICZuYnNwOy0gVGVkIEhh cmRpZTxicj4NCiZndDsmbmJzcDsgJm5ic3A7LSBNaWtlIEJpc2hvcDxicj4NCiZndDs8YnI+DQom Z3Q7IExpa2V3aXNlLCB0aGFua3MgdG8gRjUgYW5kIE1hcnRpbiBEdWtlIGZvciBob3N0aW5nIHRo ZSBtZWV0aW5nLjxicj4NCiZndDs8YnI+DQomZ3Q7IENoZWVycyw8YnI+DQo8c3BhbiBjbGFzcz0i aG9lbnpiIj48c3BhbiBzdHlsZT0iY29sb3I6Izg4ODg4OCI+Jmd0Ozwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImNvbG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPiZndDsg LS08L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+Jmd0OyBNYXJrIE5vdHRpbmdoYW0m bmJzcDsgJm5ic3A7PC9zcGFuPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3d3dy5tbm90Lm5ldC8i IHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5tbm90Lm5ldC88L2E+PHNwYW4gc3R5bGU9ImNv bG9yOiM4ODg4ODgiPjxicj4NCjxzcGFuIGNsYXNzPSJob2VuemIiPiZndDs8L3NwYW4+PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_DB4PR07MB348C4AC13E2FC4A1ADC670DC2750DB4PR07MB348eurprd_-- From nobody Tue Oct 10 05:23: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 CDE92134DEF for ; Tue, 10 Oct 2017 05:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 TZdLbqZXOwsg for ; Tue, 10 Oct 2017 05:23:19 -0700 (PDT) Received: from mail-io0-x22a.google.com (mail-io0-x22a.google.com [IPv6:2607:f8b0:4001: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 5733F134DBA for ; Tue, 10 Oct 2017 05:23:06 -0700 (PDT) Received: by mail-io0-x22a.google.com with SMTP id j17so8622585iod.5 for ; Tue, 10 Oct 2017 05:23:06 -0700 (PDT) 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=8YanN+nhmpK1Gvexbuu13L+YidT3m/fbehAjjwZlG0I=; b=pCVQL4Ar267qRdmJAsI7QLPIguOh94yzZXEnvTxjDU/Af0rbfVUdoq8dJpyCKXYoMV 0kcHcGLMxp5VuQbgLTp0jdxez6LiuHwmH5qWV7oZP6ukGPxp/25TbYMGqYcgZS5o6lt/ KQwcjvdUXU0cNbMOpIFUW8/hoJ0SDzbtNxVfVtFt3boWOpAbp/embdvljaQJfxXaCOZ7 3eG+v3dzOB/WxpahQv+yiQ4U079u/i4YRhdvCNm+A1hFYQJuFjKL1JBqAdOyZ8cRQ5xZ lnDxbXhQgfzrAvEbW4D460YtV6rQwNn5WeJJjosXhRXKdXIpT5BocwR7UbxtZTmjJyGU ZJ2Q== 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=8YanN+nhmpK1Gvexbuu13L+YidT3m/fbehAjjwZlG0I=; b=t60oVY80fQJ6KJDiGXITka1/EY0yroUyu70PEMXMPDU/VMs1NTw7M5Vw/TeQgicUTH FwBGDrqAqkF1xB+tFYPYw7obFTD1gPeIiVsE2ouH3+KIp5ktJXtBASYUfh95HQKmldd1 Y7xEnedgDGd+CEh1lvgunMlanHsiIW9/IFwVOskK4DUG++MX8QRwHkHqaSJPKW2HMTZG 6kNrekEXNLJ6tSC47hxUXo16sd4k9+/4qSdhIhYGjVdLEN5uCD4+B1evdPjwIyHQc/U4 iKTHz+BDFs0dO1ubtac2YJLOaIbqTFnxTr5+dwHaZjv1T+APYUw2Ugn1fcvGHpsbKqJa G41A== X-Gm-Message-State: AMCzsaUV0be1gsZuCKtk8Od0aX28x/qb2qsif57SD9Y82+WreVPRFEme e3JnWAs6FfUxBbnKwsQ8ZMfM7pD3hXSqCw7j5AR17Q== X-Google-Smtp-Source: AOwi7QAnBVu7R1gR7UziCl7iGocxkHLieXEc+PY+coluWq1V2EPsO+pyepmUsHcOdXxQnwIEltmhXze3JM1xoVR4CS0= X-Received: by 10.107.190.7 with SMTP id o7mr18183615iof.18.1507638185356; Tue, 10 Oct 2017 05:23:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.30.133 with HTTP; Tue, 10 Oct 2017 05:22:44 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Tue, 10 Oct 2017 08:22:44 -0400 Message-ID: Subject: Re: Stateless reset tweak To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a114f03947d8b95055b305e88" 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, 10 Oct 2017 12:23:33 -0000 --001a114f03947d8b95055b305e88 Content-Type: text/plain; charset="UTF-8" Sounds good to me. After failed decryption, the end of the packet would be more likely to be in cache anyway. On Tue, Oct 10, 2017 at 12:39 AM, Martin Thomson wrote: > https://github.com/quicwg/base-drafts/pull/842 > > ekr pointed out that handling a stateless reset is a little tricky > because the payload overlaps with the header. After some discussion > (on #820), we concluded that the easiest way to solve this problem was > to put the token at the very end of the packet. This makes the packet > more easily identified by clients, because the token is always in the > same place no matter what flags or packet type is used. > > Does anyone think that this is a bad idea? I'd like to integrate this > into -07. > > --001a114f03947d8b95055b305e88 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Sounds good to me.

After failed decrypt= ion, the end of the packet would be more likely to be in cache anyway.

On Tue, Oc= t 10, 2017 at 12:39 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
= https://github.com/quicwg/base-drafts/pull/842

ekr pointed out that handling a stateless reset is a little tricky
because the payload overlaps with the header.=C2=A0 =C2=A0After some discus= sion
(on #820), we concluded that the easiest way to solve this problem was
to put the token at the very end of the packet.=C2=A0 This makes the packet=
more easily identified by clients, because the token is always in the
same place no matter what flags or packet type is used.

Does anyone think that this is a bad idea?=C2=A0 I'd like to integrate = this into -07.


--001a114f03947d8b95055b305e88-- From nobody Wed Oct 11 06:29:28 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C101134224 for ; Wed, 11 Oct 2017 06:29:27 -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, 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 JMwBUvc8rF55 for ; Wed, 11 Oct 2017 06:29:26 -0700 (PDT) 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 A3779134222 for ; Wed, 11 Oct 2017 06:29:25 -0700 (PDT) X-AuditID: c1b4fb30-659ff700000033c8-d8-59de1cb32f3f Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 7F.39.13256.3BC1ED95; Wed, 11 Oct 2017 15:29:23 +0200 (CEST) Received: from EUR03-VE1-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; Wed, 11 Oct 2017 15:29:23 +0200 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=AO7FbYQlG+cLFyoAagkNSpeq982PTcz6o2OCUjcuIVE=; b=U80qqO2yUU8YCZARbPym4qeZMOU7WS2psXZ4iLPyzpmEhE0ucQC4AX04hxYCXKbhvZs8s8GB+qG3hh1uqaNjSFOcQeokD9Jj86A01iRiZbT0lxFJr6+daz5rT1/sthjv2khSwD+DB0ZIlxMBw6c5bLEIgmVDkSZ+M/OXsA4t/fU= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Wed, 11 Oct 2017 13:29:10 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.020; Wed, 11 Oct 2017 13:29:10 +0000 From: Ingemar Johansson S To: QUIC WG Subject: ECN and/or timestamp design team Thread-Topic: ECN and/or timestamp design team Thread-Index: AdNCk9tIT3KdE2lkSJCid4oOdn/02g== Date: Wed, 11 Oct 2017 13:29:10 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 6:GjBirQJZKCtIKyda7jEojRUD3y5XTPUTnvl8eeSNaZYtKUiGo91yJsfBy5DHieEICfLWxNZ/bIXr6GMudGDX2JHh5pu0Fv7xZ7UieB0FReAHhe9eOHDlAIDy/Gcf9LnJNLO+vq7uR/EVeAH+YkvG7yF35JRgLhjgemoV552tuWyewExEPI9X6J3t/OcSVEYtuXmAcUHw7Kl+TN7ZCzYuDcoM5FZuKD1mpcIhZpFWRlrW2XAOckRu6ePX4x4wOr4ShcJM/I91pn28pfsw1gAxUs8QABoNtTP+GyBjFeYMowXmW/lW2aSrElj6EUN+0sI2uZsReBCmzXdqeo81GbAF6A==; 5:nTN2pxBUqg8X4ttQHa6Hsfm8H9y44Q/HOGoCDehTySBnphcq0OX3qto9Gf3uXgjUfgJehy5FTh5kIHOGN406eEWC2IrDHp0/Rx/GHfSopmBlC3X1+Zr4hfMwUkNKMx30LdAqDXuIcnW9P6lzwSt5Io2q/QGsMtkjgqnqUIrrBec=; 24:3Ml8trJVr456XFcV5ernU9OQ1eJgyxPb+aAo1osGNBWW/ZiHHNQ24qLMiHzqVMT/G0h7tA1IiOYpzjXX2KOTmi9OreEJ7w+f5JrWP4vqFw4=; 7:4odN83YmYGcdEL3JL8gWUbeSr34zU9U2qHnEqjC7XjPbnMDwmvkWlGNxU5YspYoLCtCe+rDLhBmX6M1bnCbrq7khGHOmrRnqkiR3Rh0ROeLRlizS452Na/LU8RWaHwFciimF2Nj4wADAx3F7zm6QElggP0Kb6s1InRRFnUhg+XjbUvTICvEUyncZr+bsWMUnnSZHGoh3i4kBAZgp1u4STS/0aofirtHD9W+b/f2988A= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 69a149a8-455d-48d4-a02b-08d510ac0e84 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB4PR07MB346; x-ms-traffictypediagnostic: DB4PR07MB346: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(202460600054446)(21748063052155); 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)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123562025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB346; x-forefront-prvs: 0457F11EAF x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(189002)(199003)(7696004)(606006)(3846002)(3660700001)(25786009)(8676002)(33656002)(8936002)(5250100002)(81156014)(81166006)(14454004)(2906002)(7736002)(74316002)(2900100001)(5660300001)(3280700002)(790700001)(316002)(102836003)(6116002)(97736004)(19609705001)(105586002)(6436002)(86362001)(53936002)(106356001)(54896002)(101416001)(6506006)(6306002)(6916009)(9686003)(55016002)(99286003)(236005)(966005)(478600001)(9326002)(189998001)(50986999)(66066001)(68736007)(54356999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DB4PR07MB348873BAF04F991E4213FD8C24A0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Oct 2017 13:29:10.5535 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02Sa0iTYRTHe/a+e/e6WjxOxYMXqHU1cZkaiJfIPpQfki4fQv1iU190NDfZ pmkUeClWpqGks+m85dK0iTAVSyJ0GWkhyTLI1E3KrGESSWTWWrk9CX77nf//fzjnOTwsJW7m B7FypZZTK2UKCSOkDamDOyP6QuxpkZWLcbGVrVuPomSTaY13GqULE7I5hbyQUx88cl6Y67KX 0vnOuKL6qxNUCbIerkAsCzgGXlbsq0BCVoxHESxP36VJMYagsmOR5yloXEXB4Ew/Q5w6HvR+ LKVI4UBQ/nlqvceHZXACdFlXkYf9cTBYzN8Yzww/HAaWmV1EloL7zQC9wQ0WE9/DNN4DC9cd jIdFOB2GjF3eDMKh4Fi1e5nCgfBuoYXnYcAYTI9fUYQDwPnBzSf5LFiZruITfQe4bO8ZwqFg a7mJPDsDNgigu73rvyGFgZplRDgFvs410STUhMBpmBKQI4XB5Hw8yShg8dlzAWE5NLsmGJIf 54POuEYTIwRqdW4BMdr50Na64u0QYw46e655p/nhIJibuoGqUVjDptcRVsF9nYtq8F7DF8YN CzTRpfC2rpYhHA4dbUsU4Qi447bSm/VWJOhGARpOk5mXExUl5dTyLI1GpZQqOa0Frf+akf7f kQ+R81OSFWEWSbaJnN/n0sR8WaGmOM+KgKUk/iLmz7okypYVX+LUqgx1gYLTWFEwS0sCRUlP JlPFOEem5S5wXD6n3nB5rE9QCTIWOWLv+Q7v/TXiKJutPjuxysssSTgeHtkXf+WcvF6lrzH2 59kHzTH589z2W2fM7TV/hWWJrFgfrWNsBaMhcKLXvMuvXD8s6clI7rFYvqyEJ5X+ePCiZalK 53gt36LTR2t/ngy4nNjW6VBoj+1/6hq6aGs8NbZ7MuU2f/ZRWqOE1uTKDh2g1BrZPxkjeuQx AwAA 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, 11 Oct 2017 13:29:27 -0000 --_000_DB4PR07MB348873BAF04F991E4213FD8C24A0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Unless something around this is already planned for. I will attend IETF-100 and would be very much interested to get in contact = with others who are interested to discuss the format of the ECN fields and = timestamps in the ACK frames. Posted in "issue" on this as https://github.com/quicwg/base-drafts/issues/8= 56 Sorry for possible mis-use of the issue-tracker /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 You never slow down, You never grow old Tom Petty & The Heartbreakers =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_DB4PR07MB348873BAF04F991E4213FD8C24A0DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

 

Unless something around this is already planned for.=

I will attend IETF-100 and would be very much intere= sted to get in contact with others who are interested to discuss the format= of the ECN fields and timestamps in the ACK frames.

Posted in “issue” on this as https://github.com/quicwg/base-drafts/issues/856

Sorry for possible mis-use of the issue-tracker=

 

/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

 

 =        You never slow down,=

 =         You never grow old
    Tom Petty & Th= e Heartbreakers
=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<= /o:p>

 

--_000_DB4PR07MB348873BAF04F991E4213FD8C24A0DB4PR07MB348eurprd_-- From nobody Wed Oct 11 08:29: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 8584E133224 for ; Wed, 11 Oct 2017 08:29:08 -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, 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 KWvOLhZEO5Y2 for ; Wed, 11 Oct 2017 08:29:06 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CDF812ECEC for ; Wed, 11 Oct 2017 08:29:06 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id m81so2242681ioi.13 for ; Wed, 11 Oct 2017 08:29:06 -0700 (PDT) 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=K7M91NyDYK+fAI5pIBPuBaq7jElttXZFo6d6j3MfjaA=; b=ZE3/chZPW1davK1WLcyRzeFlqrkSZDQmI6oIa9fG5tOiOWlQekIfyaXe1bUFPJI9Ax 1s0KMLUTyHPxsPs3LbfDg1SEvVSdirfGJenRRNpOEiut34nZjFCY1+kSonaHEDosbDZD MUzPgu4dTGF7C8MrS/ZsFHCJCd2MJ2Pc0fPQ72VqcufBTouvpVT5t9qebdqR4PZ/P1j6 4r13fDTLxa0wecWBRyhrFnEoTVobR688xEinkZQTOFh4s011HMwuAkR/7OD1TOxZmpBh j76t+a9TYfDNSTZI5Ly8YEhIrWsP4hIXqSevHHz5wj5At8RTFlB0Xf+ma3smQqq2sMMO bV4g== 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=K7M91NyDYK+fAI5pIBPuBaq7jElttXZFo6d6j3MfjaA=; b=O5kQyMstaoa6aa6JzcydCcPhxocCcx+8Aoi0qmG8xTCUNLBwscNGkw9xfYilp5XUsM Luwu1BSVLYcYhWF7et/Pm83xuhhdMAw/jNXmbV6Oxn/BuA68WMeLyRscGJ0bsXgYZ+Su VPI7MvcQU/2PUURebkapIPGl+G47+S+DhOIQsksEfaKNESnv2yg3tJTJldPi0vgVkrLg A4WGzgJzkKKxO3DkEkRACe4ZC6ZxvgfU9z1+dtnYHumIvcizvj5RniEZHKVn2tpDFlaf ejUZrTX9HpkWAsCUx0oOjTYVkIjmiZTAag2cLRsnFsAxpUIpbAnYX5TWP90xdl7emk4R 03ng== X-Gm-Message-State: AMCzsaUWll2WiGM93OwTeC3U4jwDZghptLe90OvTgzrkCDMuAuYVR449 XlqDGMoLyHGJErRRwejFvksYB2Dg2694EKK7/C0MLw== X-Google-Smtp-Source: ABhQp+StOv2mprYb99Ks8a+tZ8jBaDM5AxWmAQ0vQf8ma/FL5OcNBOIjl5Wo05ICZCAAMqHMObg40uwMzf9XpApVMPo= X-Received: by 10.107.202.2 with SMTP id a2mr13522iog.140.1507735745448; Wed, 11 Oct 2017 08:29:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.4 with HTTP; Wed, 11 Oct 2017 08:28:44 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Wed, 11 Oct 2017 11:28:44 -0400 Message-ID: Subject: Re: ECN and Timestamps (was RE: DRAFT minutes for Seattle interim) To: Ingemar Johansson S Cc: Mark Nottingham , QUIC WG , Lars Eggert Content-Type: multipart/alternative; boundary="94eb2c0bd662863116055b47153b" 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, 11 Oct 2017 15:29:08 -0000 --94eb2c0bd662863116055b47153b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 10, 2017 at 1:39 AM, Ingemar Johansson S < ingemar.s.johansson@ericsson.com> wrote: > OK, then I understand. > > > > Perhaps a later headache but=E2=80=A6 > > If I take SCReAM as an example, in its basic form it works with timestamp > (and normal ACKs that indicate packet loss), ECN feedback is also used i= f > enabled, but the delay based congestion control is always active, in othe= r > words there is no hard switch between loss based, delay based and ECN > based congestion control. > > The feedback for all of this is bundled into the same RTCP ACK packet, > sofar a proprietary non-standardized RTCP. A 16 bit ECN-CE marked bytes > counter is always present in the feedback even though ECN is not enabled. > > > > In the QUIC case I understand that there is a wish to create new frame > types for timestamps and ECN. In the worst case we get the following ACK > frame types : > > ACK > > ACK + TS > > ACK + ECN > > ACK + TS + ECN > > Or do I misunderstand ? > > I think you have it right, though how that's requested/negotiated and framed is up to the (informal) design team, and I would greatly appreciate your participation. > > > To your question, yes, I think that I can join the timestamp design team > as well if Ok with you. > > > > /Ingemar > > > > *From:* Ian Swett [mailto:ianswett@google.com] > *Sent:* den 9 oktober 2017 16:03 > *To:* Ingemar Johansson S > *Cc:* Mark Nottingham ; QUIC WG ; Lars > Eggert > *Subject:* Re: ECN and Timestamps (was RE: DRAFT minutes for Seattle > interim) > > > > Thanks Ingemar. I agree that timestamps can be very useful. The > agreement at the interim was to remove timestamps from the current draft > and people interested in ECN and Timestamps will create a proposal for > each, as well as a way to negotiate them. The timestamp proposal can be > similar to the current one or completely different. One could imagine > having multiple different timestamp and ECN formats for different > congestion controllers, but I think it makes sense to focus on one of eac= h > initially. > > > > Would you be interested in working on an optional timestamp format as wel= l > as an ECN format? > > > > On Mon, Oct 9, 2017 at 6:46 AM, Ingemar Johansson S < > ingemar.s.johansson@ericsson.com> wrote: > > Hi > Two comments on the discussion topics in the draft notes (thanks for > producing the notes) : > > + ECN: Yes, I would very much like to be in the ECN design team :-) > > + Timestamp: I get the feeling that there is discussions on removing the > timestamps. I have found ACK timestamps quite useful, these makes it > possible to implement LEDBAT style congestion controls, which we believe > can be useful for e.g. low priority transport in wireless access. It is > however not strictly necessary to have a timestamp for each and every > packet in the ACKs. In addition I don't see either that a floating point > representation is necessary. > > > /Ingemar > > > -----Original Message----- > > From: Mark Nottingham [mailto:mnot@mnot.net] > > Sent: den 6 oktober 2017 21:36 > > To: QUIC WG > > Cc: Lars Eggert > > Subject: DRAFT minutes for Seattle interim > > > > ... are available at: > > https://github.com/quicwg/wg-materials/blob/master/interim-17- > > 10/minutes.md > > > > As always, corrections welcome, either as pull requests or through > e-mail. > > > > Thanks again to our scribes: > > - Sean Turner > > - Roberto Peon > > - Martin Duke > > - Ted Hardie > > - Mike Bishop > > > > Likewise, thanks to F5 and Martin Duke for hosting the meeting. > > > > Cheers, > > > > -- > > Mark Nottingham https://www.mnot.net/ > > > > > --94eb2c0bd662863116055b47153b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Oct 10, 2017 at 1:39 AM, Ingemar Johansson S <ingemar.s= .johansson@ericsson.com> wrote:

OK, then I understand.

=C2=A0

Perhaps a later headache but=E2=80=A6<= /p>

If I take SCReAM as an example, in its basic form it= works with timestamp (and normal ACKs that indicate packet loss), ECN =C2= =A0feedback is also used if enabled, but the delay based congestion control= is always active, in other words there is no hard switch between loss based, delay based and =C2=A0ECN based cong= estion control.

The feedback for all of this is bundled into the sam= e RTCP ACK packet, sofar a proprietary non-standardized RTCP. A 16 bit ECN-= CE marked bytes counter is always present in the feedback even though ECN i= s not enabled.

=C2=A0

In the QUIC case I understand that there is a wish t= o create new frame types for timestamps and ECN. In the worst case we get t= he following ACK frame types :

ACK

ACK + TS

ACK + ECN

ACK + TS + ECN

Or do I misunderstand ?


<= div>I think you have it right, though how that's requested/negotiated a= nd framed is up to the (informal) design team, and I would greatly apprecia= te your participation.

=C2=A0

To your question, yes, I think that I can join the t= imestamp design team as well if Ok with you.

=C2=A0=C2=A0

/Ingemar

=C2=A0

From: Ian Swett [mailto:ianswett@google.com]
Sent: den 9 oktober 2017 16:03
To: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>=
Cc: Mark Nottingham <mnot@mnot.net>; QUIC WG <quic@ietf.org>; Lars Eggert <lars@netapp.com>
Subject: Re: ECN and Timestamps (was RE: DRAFT minutes for Seattle i= nterim)

=C2=A0

Thanks Ingemar.=C2=A0 I agree that timestamps can be= very useful.=C2=A0 The agreement at the interim was to remove timestamps f= rom the current draft and people interested in ECN and Timestamps will crea= te a proposal for each, as well as a way to negotiate them.=C2=A0 The timestamp proposal can be similar to the current= one or completely different.=C2=A0 One could imagine having multiple diffe= rent timestamp and ECN formats for different congestion controllers, but I = think it makes sense to focus on one of each initially.

=C2=A0

Would you be interested in working on an optional ti= mestamp format as well as an ECN format?

=C2=A0

On Mon, Oct 9, 2017 at 6:46 AM, Ingemar Johansson S = <i= ngemar.s.johansson@ericsson.com> wrote:

Hi
Two comments on the discussion topics in the draft notes (thanks for produc= ing the notes) :

+ ECN: Yes, I would very much like to be in the ECN design team :-)

+ Timestamp: I get the feeling that there is discussions on removing the ti= mestamps. I have found ACK timestamps quite useful, these makes it possible= to implement LEDBAT style congestion controls, which we believe can be use= ful for e.g. low priority transport in wireless access. It is however not strictly necessary to have a timesta= mp for each and every packet in the ACKs. In addition I don't see eithe= r that a floating point representation is necessary.


/Ingemar

> -----Original Message-----
> From: Mark Nottingham [mailto:mnot@mnot.net]
> Sent: den 6 oktober 2017 21:36
> To: QUIC WG <qui= c@ietf.org>
> Cc: Lars Eggert <lars@netapp.com>
> Subject: DRAFT minutes for Seattle interim
>
> ... are available at:
>=C2=A0 =C2=A0https://github.com/quicwg/wg-materi= als/blob/master/interim-17-
> 10/minutes.md
>
> As always, corrections welcome, either as pull requests or through e-m= ail.
>
> Thanks again to our scribes:
>=C2=A0 =C2=A0- Sean Turner
>=C2=A0 =C2=A0- Roberto Peon
>=C2=A0 =C2=A0- Martin Duke
>=C2=A0 =C2=A0- Ted Hardie
>=C2=A0 =C2=A0- Mike Bishop
>
> Likewise, thanks to F5 and Martin Duke for hosting the meeting.
>
> Cheers,
&= gt;
> --
> Mark Nottingham=C2=A0 =C2= =A0https:= //www.mnot.net/
>

=C2=A0


--94eb2c0bd662863116055b47153b-- From nobody Wed Oct 11 23:54: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 50F6D1320D9 for ; Wed, 11 Oct 2017 23:54:26 -0700 (PDT) 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 SmHia8TyJJXH for ; Wed, 11 Oct 2017 23:54:24 -0700 (PDT) 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 9F2CC1243F6 for ; Wed, 11 Oct 2017 23:54:23 -0700 (PDT) X-AuditID: c1b4fb3a-1c7889c000006897-4e-59df119daf63 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 53.BF.26775.D911FD95; Thu, 12 Oct 2017 08:54:21 +0200 (CEST) Received: from EUR02-HE1-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; Thu, 12 Oct 2017 08:53:31 +0200 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=1aEatbftsc3OOWSK6Bz6MNMkhnijsDwg0nBjI1y7uN4=; b=Yd+M03bF8/FT/mLl/t1aP7PXrDKKf0B2HkZfoN3xOUvbyXLSvAht+iI3ij07Re7AbXDyszfkA9R56N/e2Tflt8pOA/6lZWIMdA7hmHILZzUfUMqoaEMe5pSt4/4GhEMaEpql5CW5zv/bABgMm3cLwtRbfysfVPcpXOsrGZom4gE= 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.77.5; Thu, 12 Oct 2017 06:53:29 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.020; Thu, 12 Oct 2017 06:53:28 +0000 From: Ingemar Johansson S To: QUIC WG CC: Subir Das , Ian Swett , "Jana Iyengar (jri@google.com)" , "'csp@csperkins.org'" , "Mirja Kuehlewind (IETF)" , "ietf@trammell.ch" , Ingemar Johansson S Subject: ECN design team wiki Thread-Topic: ECN design team wiki Thread-Index: AdNDJTwcKtg1luFJTdO+JTp9EOqxmw== Date: Thu, 12 Oct 2017 06:53:27 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB348; 6:A5XVFIe8S9gO5b8ElMW73VpuLmVvLyV8jD45kmIN9r2YTOHLLN6i4pqM0gFygJT8AS+yEqGMsfshMJvE42M6i9/4goYW2dz4lSfgqiyZhrasuSjE/lDmv0IBNAtE+y3B+QTm/s3eRlbKVM5oGF14fMYMeVO1QU5SUycUHKoV9aMKTVbkZgyzS0ejqhYY9WYJMRmVF97gk6Rn7FMsytR5UiqeGIY1edLx2ZSht65X2kKa3rP7CSWXWDjKOGabeKg6l44KqlTMt/pchD4lDfSLHMUm1uPHgnmGTo18FzeVYsILQ2mdrOD6pzhylLstzvTq9vbMhZYMP5v1whvPFadILQ==; 5:AIcWr6hPLalv/aiLkKgbz0OaAyfAdkQhInUbxLFM+sFzbKyjIbFV995zQOMQZJiSXruR8REjlsAVyIQ4t52OY48pHmD/s4n8ClzOPN6zqWnd7hYv4hh7NfPzjUHS0CXDUP7je05ZhP/l3knxm3+HdA==; 24:bAUJGmgOgqS7hJC/iVa1kruczB6uw4JCutMRU07VCjcwNAMBf1KvgOshlkB3sjSKV8IVh0i4PpfWxykDIjGEui9cfFU0Xx1g6mQzNTPOw9g=; 7:J/MayBx0ZDoBUiMkVGbUkqWwFFl/iZs43gxB3BKurdbI0XE/ZvB08Sy20/1VNHnzamEo1/WFLfJ7cohNTL6KpqM0x4wyPtiolYzv2Et9/KiK7juDe1iqzb96H00beLZ/UA0LNRYDv/WDQsSXunZjGjnvedv/iygawoo0cgB3HPsZDbx+Val9tIR+mFx8RfMVgcD0mmMgSOFclIrmDPAOQkc20LCfx92LqL+aA66QoXE= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(199003)(189002)(316002)(55016002)(74316002)(2906002)(8936002)(101416001)(7736002)(5660300001)(2900100001)(6436002)(99286003)(105586002)(54356999)(189998001)(81156014)(3660700001)(6506006)(50986999)(8676002)(861006)(107886003)(790700001)(102836003)(7696004)(9686003)(33656002)(19609705001)(6116002)(25786009)(3280700002)(9326002)(97736004)(81166006)(3480700004)(733005)(478600001)(68736007)(966005)(3846002)(5250100002)(86362001)(18926415007)(106356001)(54906003)(53546010)(14454004)(6306002)(54896002)(4326008)(236005)(6916009)(39060400002)(66066001)(53936002)(606006); 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; x-ms-office365-filtering-correlation-id: 85bbfa5f-2c50-4600-1ebf-08d5113df13d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB4PR07MB348; x-ms-traffictypediagnostic: DB4PR07MB348: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(21748063052155); 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)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123562025)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB348; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB348; x-forefront-prvs: 04583CED1A 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_DB4PR07MB348D8942C2A6BEAC9F021D8C24B0DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Oct 2017 06:53:27.8597 (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: H4sIAAAAAAAAA02SWUxTQRSGnd6VSuOlgh5BXKoYMQq4plEx+EBSTYz44gIPUOEGGkshvdQo PugDxVAkblhtY6WESpWUgFWRNuCCEGvUoCAhaKSCRSVxq1Gpu70dTHj7zn/++eecybCEvI+K ZzW6Ml6vU2sVtJS07L6RucIW49+TVjGaoHSO+5Dy+7CHUr4dDBLKKxUfaOWpnnpSecw+XVl7 u5HJYFRmv59WeawvGJXdbVA5HN8lqopgPaUK3LKQWXS2dGMBr9Xs5/Wpm/KkRYGmaqr0UvqB e3fbqSPo4QYTimKBWwMN32wSE5Kycq4bwbmXdhoXPgRmY2+kILkaAv6GPjG4c0YCVW0WChd+ BF+azYwYRnMb4XLXBBI5lksAtytIi0xwXgkYjyaLPJNLhPf1rTT2KKDb2kqaEBvmFBirJEWZ 5JKg/VcnJbKMywZv0Buxo/BR/8QwiSNnw7NAnQTvwIGjo5fAHAfjr/5Q2J8Pn4dqKKwvgF99 ozTmROirq0bi/MAZGQj5QpNBq8F0ooPCDRsNZ+2dEnE44LZBZQ9gjw3BhVtyzMngqZsgsSUH 7o6rsayBsUcXJ2PuU/Dg8ZXJIebCkzFL5H3kHA/OZiM6gZZZp+yDuQRMHXWMNbJ/DNy3BEhr +AoifF2LNxVbFkJt9QiDeSkYz9uYqbodMU0oTuAFobhw1aoUXq/JF4QSXYqOL3Oj8E+7c+3n +nZ0583mLsSxSBEt8/wY3iOn1PuFg8VdCFhCESvb7g1LsgL1wXJeX5KrN2h5oQslsKRitizj 5uPdcq5QXcbv4/lSXv+/K2Gj4o8gc+LQlixDef9yzeAhQ+HxnAGif11a3uDSs2ca3G3zUi2n Zdnx7/Yez2t4vitpVtVT5/xMp8s90ubbSmX8/jlQuSj01bB47VVHtFDRuKR9+gy75/D63nPR yB5XfmxNoGpOzWuusmXaw0ate3NgNHDSvdOVH7XjqEstv/ExfeR6TEuughSK1CuXEXpB/Q82 GRTFZQMAAA== 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, 12 Oct 2017 06:54:26 -0000 --_000_DB4PR07MB348D8942C2A6BEAC9F021D8C24B0DB4PR07MB348eurprd_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkNCg0KSSBjcmVhdGVkIGEgc21hbGwgRUNOIHdpa2kuIFRoaXMgY2FuIHBlcmhhcHMgYmUgdXNl ZCBhcyBhIHNjcmF0Y2gtYm9vayBmb3IgdGhlIGRlc2lnbiB0ZWFtID8NCg0KSSBzdGFydGVkIG9u IGEgbGlzdCBvZiByZXF1aXJlbWVudHMsIHNvbWUgb2YgdGhlbSBhcmUgcHJvYmFibHkgYm90Y2hl ZCBidXQgaXQgaXMgYXRsZWFzdCBhIGZpcnN0IHN0YWIgYXQgaXQuIEZlZWwgZnJlZSB0byBlZGl0 Lg0KDQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvRUNOLWluLVFV SUMNCg0KL0luZ2VtYXINCg0KRnJvbTogTWFydGluIFRob21zb24gW21haWx0bzpub3RpZmljYXRp b25zQGdpdGh1Yi5jb21dDQpTZW50OiBkZW4gMTEgb2t0b2JlciAyMDE3IDIzOjUzDQpUbzogcXVp Y3dnL2Jhc2UtZHJhZnRzIDxiYXNlLWRyYWZ0c0Bub3JlcGx5LmdpdGh1Yi5jb20+DQpDYzogSW5n ZW1hciBKb2hhbnNzb24gUyA8aW5nZW1hci5zLmpvaGFuc3NvbkBlcmljc3Nvbi5jb20+OyBBdXRo b3IgPGF1dGhvckBub3JlcGx5LmdpdGh1Yi5jb20+DQpTdWJqZWN0OiBSZTogW3F1aWN3Zy9iYXNl LWRyYWZ0c10gRGVzaWduIHRlYW0gZm9yIEVDTiBhbmQvb3IgdGltZXN0YW1wIGRlc2lnbiB0ZWFt ICgjODU2KQ0KDQoNCkZlZWwgZnJlZSB0byB1c2UgdGhlIHF1aWNAaWV0ZiBsaXN0IG9yIHRoZSB3 aWtpPGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvd2lraT4gdG8gY29vcmRp bmF0ZSB0aGlzIHNvcnQgb2YgYWN0aXZpdHkuDQoNCuKAlA0KWW91IGFyZSByZWNlaXZpbmcgdGhp cyBiZWNhdXNlIHlvdSBhdXRob3JlZCB0aGUgdGhyZWFkLg0KUmVwbHkgdG8gdGhpcyBlbWFpbCBk aXJlY3RseSwgdmlldyBpdCBvbiBHaXRIdWI8aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNl LWRyYWZ0cy9pc3N1ZXMvODU2I2lzc3VlY29tbWVudC0zMzU5NjAwNjY+LCBvciBtdXRlIHRoZSB0 aHJlYWQ8aHR0cHM6Ly9naXRodWIuY29tL25vdGlmaWNhdGlvbnMvdW5zdWJzY3JpYmUtYXV0aC9B S09kR0c0R2hQZXBGcVdta1NLV3RDQTdtaWNEZzlCUmtzNXNyVGpIZ2FKcFpNNFAxZVRvPi4NCg== --_000_DB4PR07MB348D8942C2A6BEAC9F021D8C24B0DB4PR07MB348eurprd_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPCEtLVtp ZiAhbXNvXT48c3R5bGU+dlw6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kb1w6KiB7 YmVoYXZpb3I6dXJsKCNkZWZhdWx0I1ZNTCk7fQ0Kd1w6KiB7YmVoYXZpb3I6dXJsKCNkZWZhdWx0 I1ZNTCk7fQ0KLnNoYXBlIHtiZWhhdmlvcjp1cmwoI2RlZmF1bHQjVk1MKTt9DQo8L3N0eWxlPjwh W2VuZGlmXS0tPjxzdHlsZT48IS0tDQovKiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYg MyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIg MTUgNSAyIDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJp b3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6 dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29u b3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTpt c29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsN Cgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1z aXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVt YWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTIx DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1z ZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFy Z2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcwLjg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1s Pg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1s PjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpl eHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVs YXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGlu az0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBjcmVhdGVkIGEg c21hbGwgRUNOIHdpa2kuIFRoaXMgY2FuIHBlcmhhcHMgYmUgdXNlZCBhcyBhIHNjcmF0Y2gtYm9v ayBmb3IgdGhlIGRlc2lnbiB0ZWFtID88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdGFydGVk IG9uIGEgbGlzdCBvZiByZXF1aXJlbWVudHMsIHNvbWUgb2YgdGhlbSBhcmUgcHJvYmFibHkgYm90 Y2hlZCBidXQgaXQgaXMgYXRsZWFzdCBhIGZpcnN0IHN0YWIgYXQgaXQuIEZlZWwgZnJlZSB0byBl ZGl0LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20v cXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kvRUNOLWluLVFVSUMiPmh0dHBzOi8vZ2l0aHViLmNvbS9x dWljd2cvYmFzZS1kcmFmdHMvd2lraS9FQ04taW4tUVVJQzwvYT48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+L0luZ2VtYXI8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gTWFy dGluIFRob21zb24gW21haWx0bzpub3RpZmljYXRpb25zQGdpdGh1Yi5jb21dDQo8YnI+DQo8Yj5T ZW50OjwvYj4gZGVuIDExIG9rdG9iZXIgMjAxNyAyMzo1Mzxicj4NCjxiPlRvOjwvYj4gcXVpY3dn L2Jhc2UtZHJhZnRzICZsdDtiYXNlLWRyYWZ0c0Bub3JlcGx5LmdpdGh1Yi5jb20mZ3Q7PGJyPg0K PGI+Q2M6PC9iPiBJbmdlbWFyIEpvaGFuc3NvbiBTICZsdDtpbmdlbWFyLnMuam9oYW5zc29uQGVy aWNzc29uLmNvbSZndDs7IEF1dGhvciAmbHQ7YXV0aG9yQG5vcmVwbHkuZ2l0aHViLmNvbSZndDs8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtxdWljd2cvYmFzZS1kcmFmdHNdIERlc2lnbiB0ZWFt IGZvciBFQ04gYW5kL29yIHRpbWVzdGFtcCBkZXNpZ24gdGVhbSAoIzg1Nik8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwPkZlZWwgZnJlZSB0byB1c2UgdGhlIHF1aWNAaWV0ZiBsaXN0IG9yIHRoZSA8YSBo cmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3dpa2kiPg0Kd2lraTwv YT4gdG8gY29vcmRpbmF0ZSB0aGlzIHNvcnQgb2YgYWN0aXZpdHkuPG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0iLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0Om5vbmUiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2NvbG9yOiM2NjY2NjYiPuKAlDxicj4NCllvdSBhcmUgcmVjZWl2aW5nIHRo aXMgYmVjYXVzZSB5b3UgYXV0aG9yZWQgdGhlIHRocmVhZC48YnI+DQpSZXBseSB0byB0aGlzIGVt YWlsIGRpcmVjdGx5LCA8YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJh ZnRzL2lzc3Vlcy84NTYjaXNzdWVjb21tZW50LTMzNTk2MDA2NiI+DQp2aWV3IGl0IG9uIEdpdEh1 YjwvYT4sIG9yIDxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9ub3RpZmljYXRpb25zL3Vuc3Vi c2NyaWJlLWF1dGgvQUtPZEdHNEdoUGVwRnFXbWtTS1d0Q0E3bWljRGc5QlJrczVzclRqSGdhSnBa TTRQMWVUbyI+DQptdXRlIHRoZSB0aHJlYWQ8L2E+LjxpbWcgYm9yZGVyPSIwIiB3aWR0aD0iMSIg aGVpZ2h0PSIxIiBzdHlsZT0id2lkdGg6LjAxMDRpbjtoZWlnaHQ6LjAxMDRpbiIgaWQ9Il94MDAw MF9pMTAyNSIgc3JjPSJodHRwczovL2dpdGh1Yi5jb20vbm90aWZpY2F0aW9ucy9iZWFjb24vQUtP ZEdBM28wSUZMQVJwN2xzQzJVVUdsenZ3anptSzhrczVzclRqSGdhSnBaTTRQMWVUby5naWYiPjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DB4PR07MB348D8942C2A6BEAC9F021D8C24B0DB4PR07MB348eurprd_-- From nobody Thu Oct 12 11:04: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 1024C134220 for ; Thu, 12 Oct 2017 11:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 jqUUfKWhv8Iq for ; Thu, 12 Oct 2017 11:04:42 -0700 (PDT) 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 B62F013209C for ; Thu, 12 Oct 2017 11:04:41 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx19.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e2hqK-00045N-G4 for quic@ietf.org; Thu, 12 Oct 2017 20:04:32 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1e2hpE-0005BG-PF for quic@ietf.org; Thu, 12 Oct 2017 14:03:50 -0400 Received: (qmail 3623 invoked from network); 12 Oct 2017 18:03:14 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.26]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 12 Oct 2017 18:03:14 -0000 To: Ingemar Johansson S , QUIC WG Cc: Ian Swett , "'csp@csperkins.org'" , "Mirja Kuehlewind (IETF)" , "ietf@trammell.ch" , "Jana Iyengar (jri@google.com)" , Subir Das References: From: Christian Huitema Message-ID: <306076fe-bc12-4156-7bb0-07881da03b46@huitema.net> Date: Thu, 12 Oct 2017 11:03:10 -0700 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="------------A4C7D82547CE4D397159BA18" Content-Language: en-US Subject: Re: ECN design team wiki X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.03) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5iBpnpUEHyVtVeYTKGkBsJsXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fvhk7gUk19UeyHr/sC1zRG0B98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYfVCZ1my7qTGj+pYSPpnV3tZsQEbaxxISMHgJxrdMdSS+C+me6dA6yBk+me OMe0W20IwpnDW1iuevuskcdSkQBqqDYcAbb25yfA/Qzc5alGOhdG5bOwa1rOgT+89+/XFrGt2tce crpXRY6fm8RXptyzavERpop5LF7RavHozgbn9XzprFRbpFQTOcEGeQOY3IcDlgJpEbxunV7tCPNi PQvHQpVRoYcix47lJTuKsG8TgnDHFRDF834rtLc6Wv9Yj+vBPX9bzGJi0ycLbiOUDEySIK/1NH5T HMtlYvyHAYGOGheVSH7cGoIH3Vd41lbD31Xe5FFYx70dwpnXuYL0mrvA8FWxgXlWmTYKYIcQI2OJ enQ1CeGtOhmqjL0ST/MpOVwHmFDqewO9xyOqCYO8P1aHuJ+q0VAdWduuFNAGSPDW/D0UF36LWvas gj4e2T8BuA1dHghQC//pO9KiygTP+bGFDJc/3lHzX92E3nO7lXITicibYT4C2qF2lnc18bVJn64U W/9f+FJnOevBAh1cKzxka/oZHL0JV4n2pNzkk9hNSTwJWw42swm4bO6gacpMpzLdQBUMkAI/PGrN 0+wWmMSTwMPXVqLhHTCtUoQNwWJnsFjI1dRH6f16eQCtvwPkeoxEbFBkDEb7h/VcBU3NCXbKl1Fr MVSE/J/ewUnTj7YP55q9INbyRwqQyVkoHpS/jX2RVYKU9W9tbmVXJBqdHHDm8ZIH36IzEI956ubs TR4WHrFV5oTvAcwA4rM3FkfW8/2B3o0d/ygg1mkxyifBss2L 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, 12 Oct 2017 18:04:44 -0000 This is a multi-part message in MIME format. --------------A4C7D82547CE4D397159BA18 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit In the same spirit, I took a crack at time stamps: https://github.com/quicwg/base-drafts/wiki/Time-stamps-in-QUIC On 10/11/2017 11:53 PM, Ingemar Johansson S wrote: > > Hi > >   > > I created a small ECN wiki. This can perhaps be used as a scratch-book > for the design team ? > >   > > I started on a list of requirements, some of them are probably botched > but it is atleast a first stab at it. Feel free to edit. > >   > > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC > >   > > /Ingemar > >   > > *From:* Martin Thomson [mailto:notifications@github.com] > *Sent:* den 11 oktober 2017 23:53 > *To:* quicwg/base-drafts > *Cc:* Ingemar Johansson S ; Author > > *Subject:* Re: [quicwg/base-drafts] Design team for ECN and/or > timestamp design team (#856) > >   > > Feel free to use the quic@ietf list or the wiki > to coordinate this sort > of activity. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , > or mute the thread > . > -- Christian Huitema --------------A4C7D82547CE4D397159BA18 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

In the same spirit, I took a crack at time stamps: https://github.com/quicwg/base-drafts/wiki/Time-stamps-in-QUIC


On 10/11/2017 11:53 PM, Ingemar Johansson S wrote:

Hi

 

I created a small ECN wiki. This can perhaps be used as a scratch-book for the design team ?

 

I started on a list of requirements, some of them are probably botched but it is atleast a first stab at it. Feel free to edit.

 

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

 

/Ingemar

 

From: Martin Thomson [mailto:notifications@github.com]
Sent: den 11 oktober 2017 23:53
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Ingemar Johansson S <ingemar.s.johansson@ericsson.com>; Author <author@noreply.github.com>
Subject: Re: [quicwg/base-drafts] Design team for ECN and/or timestamp design team (#856)

 

Feel free to use the quic@ietf list or the wiki to coordinate this sort of activity.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


-- 
Christian Huitema
--------------A4C7D82547CE4D397159BA18-- From nobody Thu Oct 12 11:41: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 1E26A134311 for ; Thu, 12 Oct 2017 11:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 NaTa3o2zSKMb for ; Thu, 12 Oct 2017 11:41:19 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CBCD126BF3 for ; Thu, 12 Oct 2017 11:41:19 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id f15so15373302qtf.7 for ; Thu, 12 Oct 2017 11:41:19 -0700 (PDT) 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=fJxgqhupXgGp6x2pJECKp+5V03E7MGNeyQReBcWOLck=; b=fxQlPgfjjkFt5OaZOfb6ZOrwmPPlIcc5DhNneIiH3XSAI/99kyV5DoWFIpBzMezqKX 6sK6c7cXNTFSRJmJY7zzJB51qCNtlAZ5qg2KJLZ8ZjWUAKukgtcVlH0CVyGTFrcPD6Fm pi/xPjYC8DNUf9NNX1r/QhoEBbywD5fmslAeTrm6XG/iz3ibb55b8BiOUQ2wsLnawRSG oR8eZht+mPyOqB3LEazXlwrb3tXRkFgLOVWoGRmfw2p8UngM6fAKWosLjS2Bo3VmEY5h eqSsffXNiADgujn2EOOasbNs7yVqsveH+0AZkrLm+nQjP9sYLUGkws9Jg34lYgk9XOlD /klw== 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=fJxgqhupXgGp6x2pJECKp+5V03E7MGNeyQReBcWOLck=; b=HAJAlAqZT2zgZB1cvcMZJ5F4iNjMfQeMG6qwX9wnsgzD8lKoqICa49VpsFpommZtWe tSqizCo5cyRl+4mTGRpe7AA+MPyg+9UxetkF1/lVuh75jCba42vLfDOmFIrnHRF6iG+U fc1+hBgfGGfoK9tyiyu6mXowFSH8/Zx5VzZYHWRFmlxI6S0aV5UFzLjIKXue7dCR5KcB Wbwy0A8ShellvqEmAzhqLyzkT68AxcfxSWPvUyx/rXtoNse1OsgEG8p0Ym6iFOHyNUoa n7cDz8Fm2D9DZ1SRtI7eSSxO69Lw+mlpavf8FVYs1o8p8B+JE0C3gj/Pg1HmeuyJDJ9Z y4hA== X-Gm-Message-State: AMCzsaVtAxsza9hH0eWjGRDcpFcL+/Ev3t3GLpelO14gGN1TnYrr2TCn FW+dpw4zqaMt1xavM1w2vKmK0J+f8U5ct53v9mb8gw== X-Google-Smtp-Source: AOwi7QCCFDsFJvNAeSUxHLDYqjh6IwHPJ8FPYMZOPgWdo/RGL2buhrn19uUOYMJfQ9EZ6dPTTObX0AbFH1NLaA9JWtU= X-Received: by 10.37.119.196 with SMTP id s187mr1473441ybc.186.1507833676849; Thu, 12 Oct 2017 11:41:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.70.5 with HTTP; Thu, 12 Oct 2017 11:41:16 -0700 (PDT) In-Reply-To: <306076fe-bc12-4156-7bb0-07881da03b46@huitema.net> References: <306076fe-bc12-4156-7bb0-07881da03b46@huitema.net> From: Jana Iyengar Date: Thu, 12 Oct 2017 11:41:16 -0700 Message-ID: Subject: Re: ECN design team wiki To: Christian Huitema Cc: Ingemar Johansson S , QUIC WG , Ian Swett , "csp@csperkins.org" , "Mirja Kuehlewind (IETF)" , "ietf@trammell.ch" , Subir Das Content-Type: multipart/alternative; boundary="001a114bda5eb10759055b5de2d1" 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, 12 Oct 2017 18:41:21 -0000 --001a114bda5eb10759055b5de2d1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks much for setting up the wiki, Ingemar! On Thu, Oct 12, 2017 at 11:03 AM, Christian Huitema wrote: > In the same spirit, I took a crack at time stamps: > https://github.com/quicwg/base-drafts/wiki/Time-stamps-in-QUIC > > On 10/11/2017 11:53 PM, Ingemar Johansson S wrote: > > Hi > > > > I created a small ECN wiki. This can perhaps be used as a scratch-book fo= r > the design team ? > > > > I started on a list of requirements, some of them are probably botched bu= t > it is atleast a first stab at it. Feel free to edit. > > > > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC > > > > /Ingemar > > > > *From:* Martin Thomson [mailto:notifications@github.com > ] > *Sent:* den 11 oktober 2017 23:53 > *To:* quicwg/base-drafts > > *Cc:* Ingemar Johansson S > ; Author > > *Subject:* Re: [quicwg/base-drafts] Design team for ECN and/or timestamp > design team (#856) > > > > Feel free to use the quic@ietf list or the wiki > to coordinate this sort of > activity. > > =E2=80=94 > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > = , > or mute the thread > > . > > > -- > Christian Huitema > > --001a114bda5eb10759055b5de2d1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks much for setting up the wiki, Ingemar!

On Thu, Oct 12, 2017 at = 11:03 AM, Christian Huitema <huitema@huitema.net> wrote:
=20 =20 =20

In the same spirit, I took a crack at time stamps: https://github.com/quicwg/base-drafts/wiki/Time-stamps-in-QUIC=


On 10/11/2017 11:5= 3 PM, Ingemar Johansson S wrote:
=20 =20 =20 =20

Hi

=C2=A0

I created a small ECN wiki. This can perhaps be used as a scratch-book for the design team ?=

=C2=A0

I started on a list of requirements, some of them are probably botched but it is atleast a first stab at it. Feel free to edit.

=C2=A0

https://github.com/quicwg/bas= e-drafts/wiki/ECN-in-QUIC

=C2=A0

/Ingemar

=C2=A0

From: Martin Thomson [mailto:notificati= ons@github.com]
Sent: den 11 oktober 2017 23:53
To: quicwg/base-drafts <base-dra= fts@noreply.github.com>
Cc: Ingemar Johansson S <ingema= r.s.johansson@ericsson.com>; Author <author@norepl= y.github.com>
Subject: Re: [quicwg/base-drafts] Design team for ECN and/or timestamp design team (#856)

=C2=A0

Feel free to use the quic@ietf list or the wiki to coordinate this sort of activity.

=E2=80=94
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


--=20
Christian Huitema

--001a114bda5eb10759055b5de2d1-- From nobody Fri Oct 13 00:50: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 BC270126B7E for ; Fri, 13 Oct 2017 00:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=it-uc3m-es.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csKIyETPifQT for ; Fri, 13 Oct 2017 00:50:29 -0700 (PDT) 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 2CE031320B5 for ; Fri, 13 Oct 2017 00:50:29 -0700 (PDT) Received: by mail-wm0-x231.google.com with SMTP id u138so19003920wmu.5 for ; Fri, 13 Oct 2017 00:50:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=it-uc3m-es.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=WMvjVhVsJb9Th7rfzYJUhf3AG+oVRMwHRzK2VB/x6KA=; b=Nu1ihOt97DyEBHATHJoIbi2f/RrHKsTEoQL1xJPS8NmrWeZPcJd2SzGdDK3ZEEMOmJ U3fBYSUGnYZPt2Xq4naRbxaEyJiCDVJ2mwTAd0lzU6PCD89SXPRZC3qrPn90gsRwefzS qtS0iFWwbM/W6gkvj97bj0iWS2k/nCFl9RYVPgnEzM/TfPTpFBACfiXqvwQ8Y2YZ8DO2 xgVj/cVTDgUSs6JzoM/XkFtAp14ZRBNdlpw+44SxNWn01tbITEQ4//yYbGFaHjkRBfku OukIyPzp2+bf9arNWxu+3W48UwfhCc2x30FXjKF93BDpM9jN/pkJUjnr1J19ajN2AjZI Jl5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WMvjVhVsJb9Th7rfzYJUhf3AG+oVRMwHRzK2VB/x6KA=; b=gjYgOFIRSdpSHL6NhgfgovxoOCvH/oBm/YMPu+nDEv4Lv3KWvOrT4kj4sZHQmO7P9q JQ+ONHVUR9GtN9NR3AaFjRvepMHmbVH5otW63GkW2McRYKANRWZnlFwHOKodwr84I88B L6cVn2GNfANlttPQUMIb3vzwlGv+jHDxFbBMbIasLZ8JYydZyAyoZoEbsGmyB4AQZOJD 5vO06ghF9ZYEt4ydWW9+Nzqb+OnOBM4mMeW5ZiQFPiCILBk2FfqJ8LQ/t43mOTnacEYn YU9+GGYRAjll/Mg5QIZkW/xTZ8FBjlJqrjXDvyb+TLXjFdry2Ic0sRkZ6FoOT3BpA/gb PLPw== X-Gm-Message-State: AMCzsaXTeO6Dziwxa9BXdxxqWMKUmzoOk2wgH7lddHQ8ZrX/CNO0znkV hOto1es2V0NWvq0djChyfi0g6Q== X-Google-Smtp-Source: AOwi7QAYcpQ50uJew6rltQGllrI6z59ecqffO+ZB2CrhD1XaiKuf1uYwZW8mwrORr0Bf04CoM4cg+w== X-Received: by 10.223.143.66 with SMTP id p60mr655971wrb.142.1507881027653; Fri, 13 Oct 2017 00:50:27 -0700 (PDT) Received: from Macintosh-6.local ([2001:720:410:1010:1472:3c39:d26b:5130]) by smtp.gmail.com with ESMTPSA id l9sm536091wrf.70.2017.10.13.00.50.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Oct 2017 00:50:26 -0700 (PDT) Subject: Re: ECN design team wiki To: Ingemar Johansson S , QUIC WG References: Cc: Ian Swett , "'csp@csperkins.org'" , "Mirja Kuehlewind (IETF)" , "ietf@trammell.ch" , "Jana Iyengar (jri@google.com)" , Subir Das From: marcelo bagnulo braun Message-ID: <758855f3-ea7e-2020-bfd4-30c356df3bb9@it.uc3m.es> Date: Fri, 13 Oct 2017 09:50:25 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: X-BeenThere: quic@ietf.org X-Mailman-Version: 2.1.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, 13 Oct 2017 07:50:33 -0000 Hi, Thanks for this. One question, not sure if this has been discussed or not, is a requirement to allow ECT/CE marking of all packet type in a quic connection? (including handshake, acks, etc) (i see you have a reference to the generalized ECN draft, but it is not really referenced in the document) Regards, marcelo El 12/10/17 a las 08:53, Ingemar Johansson S escribió: > > Hi > > I created a small ECN wiki. This can perhaps be used as a scratch-book > for the design team ? > > I started on a list of requirements, some of them are probably botched > but it is atleast a first stab at it. Feel free to edit. > > https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC > > /Ingemar > > *From:* Martin Thomson [mailto:notifications@github.com] > *Sent:* den 11 oktober 2017 23:53 > *To:* quicwg/base-drafts > *Cc:* Ingemar Johansson S ; Author > > *Subject:* Re: [quicwg/base-drafts] Design team for ECN and/or > timestamp design team (#856) > > Feel free to use the quic@ietf list or the wiki > to coordinate this sort > of activity. > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > , > or mute the thread > . > From nobody Fri Oct 13 11:51: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 B139C132396 for ; Fri, 13 Oct 2017 11:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 1OGESZVA4Bt8 for ; Fri, 13 Oct 2017 11:51:39 -0700 (PDT) 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 D34C812426E for ; Fri, 13 Oct 2017 11:51:38 -0700 (PDT) Received: by mail-qt0-x22f.google.com with SMTP id q4so21356533qtq.8 for ; Fri, 13 Oct 2017 11:51:38 -0700 (PDT) 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=2VfQ1Nubns51txMCv0R6R7LiGgWK0H8bKSR78g+rf/M=; b=MQ5ezsMa7vSIyblqvR+mF3epC0fVUtEme5/EbXcZ2oHxBpTvc/TNgmIlYpQuI5H5D3 1RDukorReBHHMp0diaoouBCwAdVkC0XLJTR0/1Ro6A+Ka13Cn+mX1Y734XkGgQUjt/ol O01TqSo/unenWIK5tdfzNWxDDHt81hTxjQ/m8Fdqm0302ZKDMxVeJl+lG/V16uGioyXZ 5oUm/y1O5xS9hpjrxjE91JLfGx4vAAfEqYc6X5ESYGaQnaYsZ3/UZC4WKPW/y15FI2fb /pQpa3y6BlyIVz5DB6u+xZUiyD9zydMPfXESrX8uHvimbA98cFNhdxY9qfYHol7tCOtr 3rxw== 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=2VfQ1Nubns51txMCv0R6R7LiGgWK0H8bKSR78g+rf/M=; b=VLDrZ6T3LYhBwSzbetqW9zpQ6OvLva4iUktBjApf6prC6NhD4Z3A2Qx9z/Lg2klTPj JaJmZdCTGQMTuXWfg9oReK1s0dDOZx7U0wNFPJJTTJzDMieiuHL0x4etuzLYOwYDfpT2 R7cl8RRfnL6GcZJtCpSLT6PzKC1/V5ijMtjml+Xc//CKh2Kd0IoEQXibHlkf8LL9uDs0 iMQGGqhhSn4lzQF6dz4nU9G0IiApyLanNLUzehQdwWydYcjHLox4xSpHzHaCOEkUy58j tGxaqBQSTYnRrs4mf2/4Q9tLDXTH35Dsshwf3jpMhzLPVggEPBgO294VDpuamgxfTzdo yT5Q== X-Gm-Message-State: AMCzsaXOrJcoHPTsLkKEPDD2ZvqYyObINgzhH1+6SWP4WwuzfjHmlPJg +16ykN26blVhpNfDDaSd1lPBLTLYOemT2w9RqiHNH6zdsHE= X-Google-Smtp-Source: ABhQp+SexxI2XcIkE/bFYHH2jc4RQI9KXoGB601OxWj5lSxac7B7eT0fUdXCbLHQoMMWThSgIVofsqifrqztcOMJWwc= X-Received: by 10.37.187.137 with SMTP id y9mr1585175ybg.302.1507920697398; Fri, 13 Oct 2017 11:51:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.132.132 with HTTP; Fri, 13 Oct 2017 11:51:36 -0700 (PDT) From: Ryan Hamilton Date: Fri, 13 Oct 2017 11:51:36 -0700 Message-ID: Subject: Identify streams unidirectional vs bidirectional based on stream ID To: IETF QUIC WG Content-Type: multipart/alternative; boundary="f403043dcc6085428e055b72251e" 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, 13 Oct 2017 18:51:41 -0000 --f403043dcc6085428e055b72251e Content-Type: text/plain; charset="UTF-8" As I understand the discussions at the interim, we've decided to allow streams to be unidirectional or bidirectional. I support this idea and was motivated to write up an idea I've been thinking about for a while. In the same way that we use a bit in the stream ID to identify the client vs server nature of the stream, we can use a bit to identify the directionality. This divides the stream ID space neatly into 4 distinct spaces (much like the 2 two we have today: client/server). In addition this means that a stream ID always uniquely identifies a single stream, and frames which mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, RST_STREAM, etc) do not need to explicitly convey the directionality as fields in those frames (or implicitly based on the directionality of the frames themselves). https://github.com/quicwg/base-drafts/pull/872 Cheers, Ryan --f403043dcc6085428e055b72251e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
As I understand the discussions at the interim= , we've decided to allow streams to be unidirectional or bidirectional.= I support this idea and was motivated to write up an idea I've been th= inking about for a while. In the same way that we use a bit in the stream I= D to identify the client vs server nature of the stream, we can use a bit t= o identify the directionality. This divides the stream ID space neatly into= 4 distinct spaces (much like the 2 two we have today: client/server). In a= ddition this means that a stream ID always uniquely identifies a single str= eam, and frames which mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_= DATA, RST_STREAM, etc) do not need to explicitly convey the directionality = as fields in those frames (or implicitly based on the directionality of the= frames themselves).

https://github.com/quicwg/base-drafts/pull/872

Cheers,

Ryan
--f403043dcc6085428e055b72251e-- From nobody Fri Oct 13 12:50: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 5F7CF132620 for ; Fri, 13 Oct 2017 12:50:03 -0700 (PDT) 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 YquJ9lPJJjAg for ; Fri, 13 Oct 2017 12:50:01 -0700 (PDT) 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 41DB7126BF0 for ; Fri, 13 Oct 2017 12:50:01 -0700 (PDT) Received: by mail.in.tum.de (Postfix, from userid 107) id 4C2E31C2A2D; Fri, 13 Oct 2017 21:49:59 +0200 (CEST) Received: (Authenticated sender: fafard) by mail.in.tum.de (Postfix) with ESMTPSA id 822061C2A18 for ; Fri, 13 Oct 2017 21:49:57 +0200 (CEST) (Extended-Queue-bit tech_bmmqp@fff.in.tum.de) Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: quic@ietf.org References: From: Hugues Fafard Message-ID: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> Date: Fri, 13 Oct 2017 21:49:57 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: de-DE 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: Fri, 13 Oct 2017 19:50:03 -0000 I see, you used the 2 least significant bits to encode that information. When only using one bit to indicate the direction, it boiled down to odd/even which more or less made sense, but when using 2 bits that breaks apart. Why not use the most significant bits instead? That way, getting the 'clean' stream ID without the flags would be as simple doing a `& 0x3F...FF` instead of bit-shifting things around. Similarly, encoding the stream ID would just entail `| 0x?0...00` to set the appropriate bits and also avoid bit-shifts. Regards, Hugues On 2017-10-13 20:51, Ryan Hamilton wrote: > As I understand the discussions at the interim, we've decided to > allow streams to be unidirectional or bidirectional. I support this > idea and was motivated to write up an idea I've been thinking about > for a while. In the same way that we use a bit in the stream ID to > identify the client vs server nature of the stream, we can use a > bit to identify the directionality. This divides the stream ID > space neatly into 4 distinct spaces (much like the 2 two we have > today: client/server). In addition this means that a stream ID > always uniquely identifies a single stream, and frames which > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, > RST_STREAM, etc) do not need to explicitly convey the > directionality as fields in those frames (or implicitly based on > the directionality of the frames themselves). > > https://github.com/quicwg/base-drafts/pull/872 > > Cheers, > > Ryan From nobody Fri Oct 13 13:02: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 9A0F5132944 for ; Fri, 13 Oct 2017 13:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 MT-f0wTberTG for ; Fri, 13 Oct 2017 13:02:41 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C509126BF0 for ; Fri, 13 Oct 2017 13:02:41 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id f15so21683178qtf.7 for ; Fri, 13 Oct 2017 13:02:41 -0700 (PDT) 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=PCM6BRLQr80Ovf/pJavNK1lpdr3tRQsI3L4OE9JdKoI=; b=QoGkbut+z4en14hgtS7TiB7kPLxwrzxDZq6EdewPA8s0ECPkDN3gbkyDyan9somdTq ik0bWS4GQdOGdK2IS4fCtao53nYGS9pq6oXN0FfCExe6javtGZGxOAoLTiga3cne111a LzxmCJ9SOH5yBJS20orj6LIreHQ+/4VWdkH86F2BR7tPXGtVhd00EOihMVyS+Au3II+x eQcGsDzBN/8jgGUhsn8IDjtj6cjFkR2xhEYSrJq2Z62fnrT+Cvlch18hcn4W1fMVa7bh 8MLB1/ey5XrVNYemB7pNmwAhRXPkQCtM4Ilz2KM7lev7//AMzNgSVj1ixYL7J0kEo8hc owFw== 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=PCM6BRLQr80Ovf/pJavNK1lpdr3tRQsI3L4OE9JdKoI=; b=K5oKitEZKuMFSxc7ftKTam1pO6DrO9HUtFTF3AlryR1Jji2bKXS1ufA81DjpCnvED0 y2hrE81cSURVGfHm/DfJWqJytwNtWwRSEX4X2BN42bjEyAHu/r4Gh1Q5ZA8si0K5hjTz Uhk01ld40ilZG9gBBNE7e5kYYjB6puVn2olHNkih0Oytf6F75hmHErXzeZJkzTwBNAv+ xt6xCOsf75HiXP6jxqYxNS0xzvsg/EHIvnynJeGzObHMB9RXUHA6/n8/V70E01LcFVLU 2r6LeMV9QR7koDXwT9/DhUDok9WeRk7oSbvFoOaCXo2IlLurYAYEMPghZAEZscmDTPNJ 4Yeg== X-Gm-Message-State: AMCzsaXZgzNfzSkafpRDjsisbE56wPXfjx70L1ZVcFqOM/TUehNhvShA Bu4edA7J2ap/7QEtJR5UooGy6RQr/pNSojri37cE+A== X-Google-Smtp-Source: AOwi7QDdDsEKv6ve9sInpQnaC13HPpdHkaTD4plkuEB6Ypv1zwxjhiHgSHrEOity3T/Io4KvjHaJKIXa9p8s/oeSWk8= X-Received: by 10.13.234.215 with SMTP id t206mr1783472ywe.422.1507924959886; Fri, 13 Oct 2017 13:02:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.132.132 with HTTP; Fri, 13 Oct 2017 13:02:39 -0700 (PDT) In-Reply-To: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> From: Ryan Hamilton Date: Fri, 13 Oct 2017 13:02:39 -0700 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: Hugues Fafard Cc: IETF QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0879449594d5055b732398" 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, 13 Oct 2017 20:02:43 -0000 --94eb2c0879449594d5055b732398 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 13, 2017 at 12:49 PM, Hugues Fafard wrote: > I see, you used the 2 least significant bits to encode that > information. When only using one bit to indicate the direction, it > boiled down to odd/even which more or less made sense, but when using > 2 bits that breaks apart. > > Why not use the most significant bits instead? That way, getting the > 'clean' stream ID without the flags would be as simple doing a `& > 0x3F...FF` instead of bit-shifting things around. Similarly, encoding > the stream ID would just entail `| 0x?0...00` to set the appropriate > bits and also avoid bit-shifts. > =E2=80=8BThat's definitely possible and I don't feel terribly strongly. Tha= t being said, I chose this approach for a couple reasons: * As with client/server today, there's really no need to ever use the "clean" stream ID as you call it. The stream ID (including the lowest two bits) identifies the stream. Not, the stream id >> 2, just as today we don't talk about stream ID >> 1. * Using the least significant bit means that all stream IDs start out as small number.=E2=80=8B C =E2=80=8Bheers, Ryan=E2=80=8B --94eb2c0879449594d5055b732398 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Oct 13, 2017 at 12:49 PM, Hugues Fafard <fafard@in.tum.de> wrote:
I see, you used the 2 least significant bits to encode that
information. When only using one bit to indicate the direction, it
boiled down to odd/even which more or less made sense, but when using
2 bits that breaks apart.

Why not use the most significant bits instead? That way, getting the
'clean' stream ID without the flags would be as simple doing a `&am= p;
0x3F...FF` instead of bit-shifting things around. Similarly, encoding
the stream ID would just entail `| 0x?0...00` to set the appropriate
bits and also avoid bit-shifts.

=
=E2=80=8BThat's definitely possible and I don't feel te= rribly strongly. That being said, I chose this approach for a couple reason= s:
* As with client/server today, there's really no ne= ed to ever use the "clean" stream ID as you call it. The stream I= D (including the lowest two bits) identifies the stream. Not, the stream id= >> 2, just as today we don't talk about stream ID >> 1.* Using = the least significant bit means that all stream IDs start out as small numb= er.=E2=80=8B

C
=E2=80=8Bheer= s,

Ryan=E2=80=8B
--94eb2c0879449594d5055b732398-- From nobody Fri Oct 13 13:04: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 0F2EB132396 for ; Fri, 13 Oct 2017 13:04:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 vudFZ_4l9zjc for ; Fri, 13 Oct 2017 13:03:58 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18251126BF0 for ; Fri, 13 Oct 2017 13:03:58 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id j17so10170400iod.5 for ; Fri, 13 Oct 2017 13:03:58 -0700 (PDT) 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; bh=QEPevy7b3Cz1MPg1QT/TecBLHaJ+e1ZlCRUsF7TYBXs=; b=qyAOx83eJdO6uQYT8f2JoZpo/5vMKaCfUVFQsjWyIbpOzf3/YMpgfRz3UdEdpBSkGA J0vK5pQ5C1iXmJ2LlWBvc0JiTFwi9Jeucm0+qikcNO1paRD51o1v6BbkAeLAozXG+fOr 1sIXW6Lwk3AGk7PygUD5miEgtsFqKZwK5aYILQL34OpVOchd5dgdV0+isK1cEt7blyj2 u6yi9/FirhGljHISL2cCm5RvPvirlc4Z8dNw9+E8gPbp3beK31zfRmcXRHTkYH3hxfrh t0mz0CbufuYY0wArr3Xj8coxnL84rJP3barIUr/QjupZTRLaY2rY5pWHZsxBzx5UozxF Bmqg== 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; bh=QEPevy7b3Cz1MPg1QT/TecBLHaJ+e1ZlCRUsF7TYBXs=; b=UItctb1iZ5yFqDcKkCVGaL3BwmU0XNKm9qqpzOvism8z5SR7EmpI4ysWSlT6YXhKZg cKmMxVISCkP9N3GvEuo2kVnSoxDESG1QqlqYauGP1hQB6Iz9+J8ebyA5nJqv/VQnsxN3 njHlvwKLRq5GoEvBDEK9TkBaAWSg8furx1sAMnYBZ1UGj5n/t0I9W4K/bLtaz9BDFnYK ApfPd7AAT8pP08XZHf/x1/pvJ+LofQ6QvmqB1ivfzV0jsa0JFuL0qkiRu5R5iXC85QkR 9ZuJYylMkqHHQL8EmwzhkgeuahKtAZFs2BCnYiLsdY1GZwAwr4TpEyNPOxj2/sLUSLUB WAgw== X-Gm-Message-State: AMCzsaXBGHe8MO735f3FCJ087esiG4erIIjb0miCpJgLJf6GtkYuB1GW mRU0D3j4cio/92K/EzbQBlehYT557gsfu/wDEFSqvA== X-Google-Smtp-Source: AOwi7QCvZ0auGWk/w28n2ICRVTWA6N7qCag/G645MjL42b6RirdDMfZBO0fyVuQuu8NBdghjjNAVC7DRUZTQ9SjDRNA= X-Received: by 10.107.164.76 with SMTP id n73mr3125564ioe.175.1507925037191; Fri, 13 Oct 2017 13:03:57 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 13 Oct 2017 13:03:56 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Fri, 13 Oct 2017 13:03:56 -0700 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: quic@ietf.org, Hugues Fafard Content-Type: multipart/alternative; boundary="001a1142249c3098b0055b73286a" 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, 13 Oct 2017 20:04:00 -0000 --001a1142249c3098b0055b73286a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Especially with the new variable length encoding proposal, storing the identifiers early makes sense, as you only have to inspect the first byte. But it gets complicated, because you don=E2=80=99t want to use 8 bytes for = some stream types and you don=E2=80=99t want the bits at some random location in= a decoded 8 byte representation either. Regardless of bit placement, encoding state using bits is not ideal when considering variable length encoding because you now use two bits for length and two bits for stream type, leaving only 16 different streams before the stream identifier needs to use two bytes, and so forth. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote: I see, you used the 2 least significant bits to encode that information. When only using one bit to indicate the direction, it boiled down to odd/even which more or less made sense, but when using 2 bits that breaks apart. Why not use the most significant bits instead? That way, getting the 'clean' stream ID without the flags would be as simple doing a `& 0x3F...FF` instead of bit-shifting things around. Similarly, encoding the stream ID would just entail `| 0x?0...00` to set the appropriate bits and also avoid bit-shifts. Regards, Hugues On 2017-10-13 20:51, Ryan Hamilton wrote: > As I understand the discussions at the interim, we've decided to > allow streams to be unidirectional or bidirectional. I support this > idea and was motivated to write up an idea I've been thinking about > for a while. In the same way that we use a bit in the stream ID to > identify the client vs server nature of the stream, we can use a > bit to identify the directionality. This divides the stream ID > space neatly into 4 distinct spaces (much like the 2 two we have > today: client/server). In addition this means that a stream ID > always uniquely identifies a single stream, and frames which > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, > RST_STREAM, etc) do not need to explicitly convey the > directionality as fields in those frames (or implicitly based on > the directionality of the frames themselves). > > https://github.com/quicwg/base-drafts/pull/872 > > Cheers, > > Ryan --001a1142249c3098b0055b73286a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = Especially with the = new variable length encoding proposal, storing the identifiers early makes = sense, as you only have to inspect the first byte. But it gets complicated,= because you don=E2=80=99t want to use 8 bytes for some stream types and yo= u don=E2=80=99t want the bits at some random location in a decoded 8 byte r= epresentation either.

Regardless of bit placement, encoding state using bits is not ideal when c= onsidering variable length encoding because you now use two bits for length= and two bits for stream type, leaving only 16 different streams before the= stream identifier needs to use two bytes, and so forth.


Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

=

On 13 October 2017 at 21.50.06, Hu= gues Fafard (fafard@in.tum.de) wrot= e:

<= div>I see, you used the 2 least significant bits to encode that
information. When only using one bit to indicate the direction, it
boiled down to odd/even which more or less made sense, but when using
2 bits that breaks apart.

Why not use the most significant bits instead? That way, getting the
'clean' stream ID without the flags would be as simple doing a = `&
0x3F...FF` instead of bit-shifting things around. Similarly, encoding
the stream ID would just entail `| 0x?0...00` to set the appropriate
bits and also avoid bit-shifts.

Regards,
Hugues

On 2017-10-13 20:51, Ryan Hamilton wrote:
> As I understand the discussions at the interim, we've decided = to
> allow streams to be unidirectional or bidirectional. I support thi= s
> idea and was motivated to write up an idea I've been thinking = about
> for a while. In the same way that we use a bit in the stream ID to
> identify the client vs server nature of the stream, we can use a
> bit to identify the directionality. This divides the stream ID
> space neatly into 4 distinct spaces (much like the 2 two we have
> today: client/server). In addition this means that a stream ID
> always uniquely identifies a single stream, and frames which
> mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA,
> RST_STREAM, etc) do not need to explicitly convey the =20
> directionality as fields in those frames (or implicitly based on
> the directionality of the frames themselves).
> =20
> https:/= /github.com/quicwg/base-drafts/pull/872
> =20
> Cheers,
> =20
> Ryan

--001a1142249c3098b0055b73286a-- From nobody Fri Oct 13 13:56: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 536E3133011 for ; Fri, 13 Oct 2017 13:56:51 -0700 (PDT) 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 (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 6zv9vFEQC_pK for ; Fri, 13 Oct 2017 13:56:48 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0096.outbound.protection.outlook.com [104.47.41.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CA4312895E for ; Fri, 13 Oct 2017 13:56:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MKhaUeqrcOfYHLrxG6VFv6AM+tkm2jNlamy74TxPtvU=; b=jl3iooISJlpR2wsluzCk9PV/9FLMHaLlKmwRhOBwRDIwIci/h91JWEMoeVaDB6dTdb+UV001nmcpHDFcoh1VOsZ1w5tvMt870Xpsi4AS0pvUlN7P08SNVciccZhJRkfRoXfLTXE7sF09g5NHNqA8w7kHvB8nub/t5UUDMX9sN1k= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0511.namprd21.prod.outlook.com (10.172.95.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.156.0; Fri, 13 Oct 2017 20:56:46 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0156.003; Fri, 13 Oct 2017 20:56:46 +0000 From: Mike Bishop To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "quic@ietf.org" , Hugues Fafard Subject: RE: Identify streams unidirectional vs bidirectional based on stream ID Thread-Topic: Identify streams unidirectional vs bidirectional based on stream ID Thread-Index: AQHTRFRRiH0s+jTDREOMs7S3K8wGd6LiMDyAgAAD6ACAAAxZgA== Date: Fri, 13 Oct 2017 20:56:46 +0000 Message-ID: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:6::302] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0511; 6:A//0IavoyBsYYonwsyPxWB+srkxQXj2ITHwSeKg7K3rWqCOnjDzPk0JmmkKVSzmQUF6aOQb1rlkCljNU053VSSfAiF/lNIkiEx0FpjMa98va3YORwrvaLcuIH20K0sbK2ctOqCxOwZnHGKIbsHeBEX+BBxiangkHDrGSu2NtZg515qxCaBQSfw5BtKcVRY5SwW/Ce9tPBdJpHuuuZauMHr+FAWgb+ntYmsPDwEkZUlRhhq0gRxF9jPu5WHsR6DHJb2rsGcw1AhzXJTDtkh4bC6pxWEBSDSeQ/qlPA3occ3OEMldTB9kj8aSau8h2sGCZum32RhuLm5kJOYGSnRYf5w==; 5:gN0WAtOo3pT8qWm/C2XWvNWgYgifXNdl7zUR7HLtayjtd+EG/6p4dl7NM0X/JEyY4yF1LfRIuvm3Z4j/34AqMEhkvmsPyc6wLFE4UQZSFO42yXWMA4Qqn8EGKJOLGMVrbDI87wGlmw+FoACMFaxWFTKTmi5BuWfHGAV+WMSD9TM=; 24:CzNv436WmN4YdR8J2vg8h4oFGxPScbCMhUuLhz/tUnjZeezIwbCZzf7tm5zHW4jZlg5JJ64SyqBZb1LQwljRsJ/pgaO8icdeQSPSPA1yFCc=; 7:TIuiQsYAIDY2+2OYN2YqS+8XOkK1765+wMuHRzpNrYlpiTfm1ANu80yBjSmCMHzcOOc2lxIWbbrbI/fxx2Vz3ufC25E3vgt3rpLaNFVvhf3Lmareoo5u64ciZm1AkSdh9kK5VricjaE5qzaM0nnbBn0gtZUprpPEECRV6eHujLRJnV8cVjqrDcKdCzd2UXg/A0wox/RXfyFAdyGxL2dmea+cm4uqqThLH+F3wa0AH/A= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 04469515-e2ee-4480-e40e-08d5127ceaec x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603217)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR21MB0511; x-ms-traffictypediagnostic: MWHPR21MB0511: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820)(189930954265078)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123560025)(20161123555025)(20161123558100)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0511; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0511; x-forefront-prvs: 04599F3534 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(47760400005)(189002)(199003)(24454002)(377454003)(377424004)(6506006)(77096006)(81166006)(81156014)(10090500001)(236005)(54356999)(86362001)(76176999)(8676002)(53936002)(6306002)(54896002)(8936002)(9686003)(6246003)(561944003)(39060400002)(6436002)(86612001)(50986999)(99286003)(55016002)(106356001)(33656002)(101416001)(229853002)(105586002)(25786009)(72206003)(966005)(3660700001)(5660300001)(3280700002)(2906002)(68736007)(8990500004)(102836003)(6116002)(790700001)(2950100002)(97736004)(53546010)(478600001)(10290500003)(2501003)(14454004)(189998001)(606006)(19609705001)(7696004)(7736002)(4001150100001)(316002)(22452003)(74316002)(110136005)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0511; H:MWHPR21MB0141.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) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB01412840605BA9EBC872900D87480MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 04469515-e2ee-4480-e40e-08d5127ceaec X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Oct 2017 20:56:46.8493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0511 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, 13 Oct 2017 20:56:51 -0000 --_000_MWHPR21MB01412840605BA9EBC872900D87480MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW5kZWVkLiAgSSBhbG1vc3QgdGhpbmsgaXQgbWFrZXMgbW9yZSBzZW5zZSB0byBzYXkgdGhhdCB0 aGVyZSBhcmUgZm91ciBpbmRlcGVuZGVudCBzdHJlYW0gc3BhY2VzLCBlYWNoIHdpdGggdGhlaXIg b3duIG51bWJlcnMuICBUaGF0IGRvZXMgbWVhbiB0aGF0IGVhY2ggc2lkZSB3aWxsIG5lZWQgdG8g c2VwYXJhdGVseSBtYW5hZ2UgTWF4IFN0cmVhbSBJRCBmb3IgdHdvIHNwYWNlcywgYnV0IHRoYXQg c2VlbXMgbW9yZSByZWFzb25hYmxlIHRoYW4gdGhlIGFsdGVybmF0aXZlLiAgSW4gZmFjdCwgdGhp cyBQUiBhbHJlYWR5IGltcGxpZXMgdGhhdCB0aGUgbGltaXRzIGZvciB1bmlkaXJlY3Rpb25hbCBh bmQgYmlkaXJlY3Rpb25hbCBzdHJlYW1zIGFyZSBoYW5kbGVkIHNlcGFyYXRlbHksIHdoaWNoIGdl dHMgcmVhbGx5IHdlaXJkIHdoZW4gdGhlIElEcyBhcmUgaW50ZXJsZWF2ZWQgd2l0aCBlYWNoIG90 aGVyLg0KDQpJbiBmYWN0LCB0aGlzIHBsYXlzIHdlbGwgd2l0aCB0aGUgdmFyaWFibGUtbGVuZ3Ro IGVuY29kaW5nIGlkZWEsIHNpbmNlIHRoZSBtYXhpbXVtIHNpemUgb2YgYSBTdHJlYW0gSUQgd291 bGQgYmUgNjIgYml0cy4gIFRoZXkgY291bGQgdGhlbiBiZSBzdG9yZWQgbG9jYWxseSBhcyBhIDY0 LWJpdCB2YWx1ZSB3aXRoIHRoZSDigJxleHRyYeKAnSBiaXRzIGluZGljYXRpbmcgd2hpY2ggc3Bh Y2UgdGhleSByZWZlciB0by4NCg0KRnJvbTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIE1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4NClNlbnQ6IEZyaWRh eSwgT2N0b2JlciAxMywgMjAxNyAxOjA0IFBNDQpUbzogcXVpY0BpZXRmLm9yZzsgSHVndWVzIEZh ZmFyZCA8ZmFmYXJkQGluLnR1bS5kZT4NClN1YmplY3Q6IFJlOiBJZGVudGlmeSBzdHJlYW1zIHVu aWRpcmVjdGlvbmFsIHZzIGJpZGlyZWN0aW9uYWwgYmFzZWQgb24gc3RyZWFtIElEDQoNCkVzcGVj aWFsbHkgd2l0aCB0aGUgbmV3IHZhcmlhYmxlIGxlbmd0aCBlbmNvZGluZyBwcm9wb3NhbCwgc3Rv cmluZyB0aGUgaWRlbnRpZmllcnMgZWFybHkgbWFrZXMgc2Vuc2UsIGFzIHlvdSBvbmx5IGhhdmUg dG8gaW5zcGVjdCB0aGUgZmlyc3QgYnl0ZS4gQnV0IGl0IGdldHMgY29tcGxpY2F0ZWQsIGJlY2F1 c2UgeW91IGRvbuKAmXQgd2FudCB0byB1c2UgOCBieXRlcyBmb3Igc29tZSBzdHJlYW0gdHlwZXMg YW5kIHlvdSBkb27igJl0IHdhbnQgdGhlIGJpdHMgYXQgc29tZSByYW5kb20gbG9jYXRpb24gaW4g YSBkZWNvZGVkIDggYnl0ZSByZXByZXNlbnRhdGlvbiBlaXRoZXIuDQoNClJlZ2FyZGxlc3Mgb2Yg Yml0IHBsYWNlbWVudCwgZW5jb2Rpbmcgc3RhdGUgdXNpbmcgYml0cyBpcyBub3QgaWRlYWwgd2hl biBjb25zaWRlcmluZyB2YXJpYWJsZSBsZW5ndGggZW5jb2RpbmcgYmVjYXVzZSB5b3Ugbm93IHVz ZSB0d28gYml0cyBmb3IgbGVuZ3RoIGFuZCB0d28gYml0cyBmb3Igc3RyZWFtIHR5cGUsIGxlYXZp bmcgb25seSAxNiBkaWZmZXJlbnQgc3RyZWFtcyBiZWZvcmUgdGhlIHN0cmVhbSBpZGVudGlmaWVy IG5lZWRzIHRvIHVzZSB0d28gYnl0ZXMsIGFuZCBzbyBmb3J0aC4NCg0KDQpLaW5kIFJlZ2FyZHMs DQpNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQoNCg0KT24gMTMgT2N0b2JlciAyMDE3IGF0IDIx LjUwLjA2LCBIdWd1ZXMgRmFmYXJkIChmYWZhcmRAaW4udHVtLmRlPG1haWx0bzpmYWZhcmRAaW4u dHVtLmRlPikgd3JvdGU6DQpJIHNlZSwgeW91IHVzZWQgdGhlIDIgbGVhc3Qgc2lnbmlmaWNhbnQg Yml0cyB0byBlbmNvZGUgdGhhdA0KaW5mb3JtYXRpb24uIFdoZW4gb25seSB1c2luZyBvbmUgYml0 IHRvIGluZGljYXRlIHRoZSBkaXJlY3Rpb24sIGl0DQpib2lsZWQgZG93biB0byBvZGQvZXZlbiB3 aGljaCBtb3JlIG9yIGxlc3MgbWFkZSBzZW5zZSwgYnV0IHdoZW4gdXNpbmcNCjIgYml0cyB0aGF0 IGJyZWFrcyBhcGFydC4NCg0KV2h5IG5vdCB1c2UgdGhlIG1vc3Qgc2lnbmlmaWNhbnQgYml0cyBp bnN0ZWFkPyBUaGF0IHdheSwgZ2V0dGluZyB0aGUNCidjbGVhbicgc3RyZWFtIElEIHdpdGhvdXQg dGhlIGZsYWdzIHdvdWxkIGJlIGFzIHNpbXBsZSBkb2luZyBhIGAmDQoweDNGLi4uRkZgIGluc3Rl YWQgb2YgYml0LXNoaWZ0aW5nIHRoaW5ncyBhcm91bmQuIFNpbWlsYXJseSwgZW5jb2RpbmcNCnRo ZSBzdHJlYW0gSUQgd291bGQganVzdCBlbnRhaWwgYHwgMHg/MC4uLjAwYCB0byBzZXQgdGhlIGFw cHJvcHJpYXRlDQpiaXRzIGFuZCBhbHNvIGF2b2lkIGJpdC1zaGlmdHMuDQoNClJlZ2FyZHMsDQpI dWd1ZXMNCg0KT24gMjAxNy0xMC0xMyAyMDo1MSwgUnlhbiBIYW1pbHRvbiB3cm90ZToNCj4gQXMg SSB1bmRlcnN0YW5kIHRoZSBkaXNjdXNzaW9ucyBhdCB0aGUgaW50ZXJpbSwgd2UndmUgZGVjaWRl ZCB0bw0KPiBhbGxvdyBzdHJlYW1zIHRvIGJlIHVuaWRpcmVjdGlvbmFsIG9yIGJpZGlyZWN0aW9u YWwuIEkgc3VwcG9ydCB0aGlzDQo+IGlkZWEgYW5kIHdhcyBtb3RpdmF0ZWQgdG8gd3JpdGUgdXAg YW4gaWRlYSBJJ3ZlIGJlZW4gdGhpbmtpbmcgYWJvdXQNCj4gZm9yIGEgd2hpbGUuIEluIHRoZSBz YW1lIHdheSB0aGF0IHdlIHVzZSBhIGJpdCBpbiB0aGUgc3RyZWFtIElEIHRvDQo+IGlkZW50aWZ5 IHRoZSBjbGllbnQgdnMgc2VydmVyIG5hdHVyZSBvZiB0aGUgc3RyZWFtLCB3ZSBjYW4gdXNlIGEN Cj4gYml0IHRvIGlkZW50aWZ5IHRoZSBkaXJlY3Rpb25hbGl0eS4gVGhpcyBkaXZpZGVzIHRoZSBz dHJlYW0gSUQNCj4gc3BhY2UgbmVhdGx5IGludG8gNCBkaXN0aW5jdCBzcGFjZXMgKG11Y2ggbGlr ZSB0aGUgMiB0d28gd2UgaGF2ZQ0KPiB0b2RheTogY2xpZW50L3NlcnZlcikuIEluIGFkZGl0aW9u IHRoaXMgbWVhbnMgdGhhdCBhIHN0cmVhbSBJRA0KPiBhbHdheXMgdW5pcXVlbHkgaWRlbnRpZmll cyBhIHNpbmdsZSBzdHJlYW0sIGFuZCBmcmFtZXMgd2hpY2gNCj4gbWVudGlvbiBzdHJlYW0gSUQg KFNUUkVBTSwgTUFYX1NUUkVBTV9JRCwgTUFYX1NUUkVBTV9EQVRBLA0KPiBSU1RfU1RSRUFNLCBl dGMpIGRvIG5vdCBuZWVkIHRvIGV4cGxpY2l0bHkgY29udmV5IHRoZQ0KPiBkaXJlY3Rpb25hbGl0 eSBhcyBmaWVsZHMgaW4gdGhvc2UgZnJhbWVzIChvciBpbXBsaWNpdGx5IGJhc2VkIG9uDQo+IHRo ZSBkaXJlY3Rpb25hbGl0eSBvZiB0aGUgZnJhbWVzIHRoZW1zZWx2ZXMpLg0KPg0KPiBodHRwczov L2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvODcyPGh0dHBzOi8vbmEwMS5zYWZl bGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNBJTJGJTJGZ2l0aHViLmNv bSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGcHVsbCUyRjg3MiZkYXRhPTAyJTdDMDElN0NtaWNo YWVsLmJpc2hvcCU0MG1pY3Jvc29mdC5jb20lN0MzYmFmMDQzMjVlMGY0Yzk0NGMxMzA4ZDUxMjc1 OGQzMyU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2MzY0MzUy MTg0NjMwNjY4MDUmc2RhdGE9V0xKWFJFOUp6M3J0THNWcXhCT3lhTWNPSSUyQnE2blo4VEptbEFy c2JoVTJNJTNEJnJlc2VydmVkPTA+DQo+DQo+IENoZWVycywNCj4NCj4gUnlhbg0K --_000_MWHPR21MB01412840605BA9EBC872900D87480MWHPR21MB0141namp_ 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 emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFp bG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFp bF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0 IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDld Pjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRp dCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVh ZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbmRlZWQuJm5ic3A7 IEkgYWxtb3N0IHRoaW5rIGl0IG1ha2VzIG1vcmUgc2Vuc2UgdG8gc2F5IHRoYXQgdGhlcmUgYXJl IGZvdXIgaW5kZXBlbmRlbnQgc3RyZWFtIHNwYWNlcywgZWFjaCB3aXRoIHRoZWlyIG93biBudW1i ZXJzLiZuYnNwOyBUaGF0IGRvZXMgbWVhbiB0aGF0IGVhY2ggc2lkZSB3aWxsIG5lZWQgdG8gc2Vw YXJhdGVseSBtYW5hZ2UgTWF4IFN0cmVhbSBJRCBmb3IgdHdvIHNwYWNlcywgYnV0IHRoYXQgc2Vl bXMgbW9yZQ0KIHJlYXNvbmFibGUgdGhhbiB0aGUgYWx0ZXJuYXRpdmUuJm5ic3A7IEluIGZhY3Qs IHRoaXMgUFIgYWxyZWFkeSBpbXBsaWVzIHRoYXQgdGhlIGxpbWl0cyBmb3IgdW5pZGlyZWN0aW9u YWwgYW5kIGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmUgaGFuZGxlZCBzZXBhcmF0ZWx5LCB3aGlj aCBnZXRzIHJlYWxseSB3ZWlyZCB3aGVuIHRoZSBJRHMgYXJlIGludGVybGVhdmVkIHdpdGggZWFj aCBvdGhlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gZmFjdCwgdGhpcyBwbGF5cyB3ZWxs IHdpdGggdGhlIHZhcmlhYmxlLWxlbmd0aCBlbmNvZGluZyBpZGVhLCBzaW5jZSB0aGUgbWF4aW11 bSBzaXplIG9mIGEgU3RyZWFtIElEIHdvdWxkIGJlIDYyIGJpdHMuJm5ic3A7IFRoZXkgY291bGQg dGhlbiBiZSBzdG9yZWQgbG9jYWxseSBhcyBhIDY0LWJpdCB2YWx1ZSB3aXRoIHRoZSDigJxleHRy YeKAnSBiaXRzIGluZGljYXRpbmcgd2hpY2ggc3BhY2UgdGhleSByZWZlciB0by48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtw YWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206 PC9iPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YN CjwvYj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwg T2N0b2JlciAxMywgMjAxNyAxOjA0IFBNPGJyPg0KPGI+VG86PC9iPiBxdWljQGlldGYub3JnOyBI dWd1ZXMgRmFmYXJkICZsdDtmYWZhcmRAaW4udHVtLmRlJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogSWRlbnRpZnkgc3RyZWFtcyB1bmlkaXJlY3Rpb25hbCB2cyBiaWRpcmVjdGlvbmFsIGJh c2VkIG9uIHN0cmVhbSBJRDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9t Zm9udCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+RXNwZWNpYWxs eSB3aXRoIHRoZSBuZXcgdmFyaWFibGUgbGVuZ3RoIGVuY29kaW5nIHByb3Bvc2FsLCBzdG9yaW5n IHRoZSBpZGVudGlmaWVycyBlYXJseSBtYWtlcyBzZW5zZSwgYXMgeW91IG9ubHkgaGF2ZSB0byBp bnNwZWN0IHRoZSBmaXJzdCBieXRlLiBCdXQgaXQgZ2V0cyBjb21wbGljYXRlZCwNCiBiZWNhdXNl IHlvdSBkb27igJl0IHdhbnQgdG8gdXNlIDggYnl0ZXMgZm9yIHNvbWUgc3RyZWFtIHR5cGVzIGFu ZCB5b3UgZG9u4oCZdCB3YW50IHRoZSBiaXRzIGF0IHNvbWUgcmFuZG9tIGxvY2F0aW9uIGluIGEg ZGVjb2RlZCA4IGJ5dGUgcmVwcmVzZW50YXRpb24gZWl0aGVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj5SZWdhcmRsZXNzIG9mIGJpdCBwbGFjZW1lbnQsIGVuY29kaW5nIHN0 YXRlIHVzaW5nIGJpdHMgaXMgbm90IGlkZWFsIHdoZW4gY29uc2lkZXJpbmcgdmFyaWFibGUgbGVu Z3RoIGVuY29kaW5nIGJlY2F1c2UgeW91IG5vdyB1c2UgdHdvIGJpdHMgZm9yIGxlbmd0aCBhbmQg dHdvIGJpdHMgZm9yIHN0cmVhbQ0KIHR5cGUsIGxlYXZpbmcgb25seSAxNiBkaWZmZXJlbnQgc3Ry ZWFtcyBiZWZvcmUgdGhlIHN0cmVhbSBpZGVudGlmaWVyIG5lZWRzIHRvIHVzZSB0d28gYnl0ZXMs IGFuZCBzbyBmb3J0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJs b29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYg aWQ9ImJsb29wX3NpZ25fMTUwNzkyNDc5MzUwODcxOTg3MiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu LWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vu c2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+T24gMTMgT2N0b2JlciAyMDE3 IGF0IDIxLjUwLjA2LCBIdWd1ZXMgRmFmYXJkICg8YSBocmVmPSJtYWlsdG86ZmFmYXJkQGluLnR1 bS5kZSI+ZmFmYXJkQGluLnR1bS5kZTwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5JIHNlZSwgeW91IHVzZWQgdGhlIDIgbGVhc3Qg c2lnbmlmaWNhbnQgYml0cyB0byBlbmNvZGUgdGhhdA0KPGJyPg0KaW5mb3JtYXRpb24uIFdoZW4g b25seSB1c2luZyBvbmUgYml0IHRvIGluZGljYXRlIHRoZSBkaXJlY3Rpb24sIGl0IDxicj4NCmJv aWxlZCBkb3duIHRvIG9kZC9ldmVuIHdoaWNoIG1vcmUgb3IgbGVzcyBtYWRlIHNlbnNlLCBidXQg d2hlbiB1c2luZyA8YnI+DQoyIGJpdHMgdGhhdCBicmVha3MgYXBhcnQuIDxicj4NCjxicj4NCldo eSBub3QgdXNlIHRoZSBtb3N0IHNpZ25pZmljYW50IGJpdHMgaW5zdGVhZD8gVGhhdCB3YXksIGdl dHRpbmcgdGhlIDxicj4NCidjbGVhbicgc3RyZWFtIElEIHdpdGhvdXQgdGhlIGZsYWdzIHdvdWxk IGJlIGFzIHNpbXBsZSBkb2luZyBhIGAmYW1wOyA8YnI+DQoweDNGLi4uRkZgIGluc3RlYWQgb2Yg Yml0LXNoaWZ0aW5nIHRoaW5ncyBhcm91bmQuIFNpbWlsYXJseSwgZW5jb2RpbmcgPGJyPg0KdGhl IHN0cmVhbSBJRCB3b3VsZCBqdXN0IGVudGFpbCBgfCAweD8wLi4uMDBgIHRvIHNldCB0aGUgYXBw cm9wcmlhdGUgPGJyPg0KYml0cyBhbmQgYWxzbyBhdm9pZCBiaXQtc2hpZnRzLiA8YnI+DQo8YnI+ DQpSZWdhcmRzLCA8YnI+DQpIdWd1ZXMgPGJyPg0KPGJyPg0KT24gMjAxNy0xMC0xMyAyMDo1MSwg UnlhbiBIYW1pbHRvbiB3cm90ZTogPGJyPg0KJmd0OyBBcyBJIHVuZGVyc3RhbmQgdGhlIGRpc2N1 c3Npb25zIGF0IHRoZSBpbnRlcmltLCB3ZSd2ZSBkZWNpZGVkIHRvIDxicj4NCiZndDsgYWxsb3cg c3RyZWFtcyB0byBiZSB1bmlkaXJlY3Rpb25hbCBvciBiaWRpcmVjdGlvbmFsLiBJIHN1cHBvcnQg dGhpcyA8YnI+DQomZ3Q7IGlkZWEgYW5kIHdhcyBtb3RpdmF0ZWQgdG8gd3JpdGUgdXAgYW4gaWRl YSBJJ3ZlIGJlZW4gdGhpbmtpbmcgYWJvdXQgPGJyPg0KJmd0OyBmb3IgYSB3aGlsZS4gSW4gdGhl IHNhbWUgd2F5IHRoYXQgd2UgdXNlIGEgYml0IGluIHRoZSBzdHJlYW0gSUQgdG8gPGJyPg0KJmd0 OyBpZGVudGlmeSB0aGUgY2xpZW50IHZzIHNlcnZlciBuYXR1cmUgb2YgdGhlIHN0cmVhbSwgd2Ug Y2FuIHVzZSBhIDxicj4NCiZndDsgYml0IHRvIGlkZW50aWZ5IHRoZSBkaXJlY3Rpb25hbGl0eS4g VGhpcyBkaXZpZGVzIHRoZSBzdHJlYW0gSUQgPGJyPg0KJmd0OyBzcGFjZSBuZWF0bHkgaW50byA0 IGRpc3RpbmN0IHNwYWNlcyAobXVjaCBsaWtlIHRoZSAyIHR3byB3ZSBoYXZlIDxicj4NCiZndDsg dG9kYXk6IGNsaWVudC9zZXJ2ZXIpLiBJbiBhZGRpdGlvbiB0aGlzIG1lYW5zIHRoYXQgYSBzdHJl YW0gSUQgPGJyPg0KJmd0OyBhbHdheXMgdW5pcXVlbHkgaWRlbnRpZmllcyBhIHNpbmdsZSBzdHJl YW0sIGFuZCBmcmFtZXMgd2hpY2ggPGJyPg0KJmd0OyBtZW50aW9uIHN0cmVhbSBJRCAoU1RSRUFN LCBNQVhfU1RSRUFNX0lELCBNQVhfU1RSRUFNX0RBVEEsIDxicj4NCiZndDsgUlNUX1NUUkVBTSwg ZXRjKSBkbyBub3QgbmVlZCB0byBleHBsaWNpdGx5IGNvbnZleSB0aGUgPGJyPg0KJmd0OyBkaXJl Y3Rpb25hbGl0eSBhcyBmaWVsZHMgaW4gdGhvc2UgZnJhbWVzIChvciBpbXBsaWNpdGx5IGJhc2Vk IG9uIDxicj4NCiZndDsgdGhlIGRpcmVjdGlvbmFsaXR5IG9mIHRoZSBmcmFtZXMgdGhlbXNlbHZl cykuIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtz LnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZx dWljd2clMkZiYXNlLWRyYWZ0cyUyRnB1bGwlMkY4NzImYW1wO2RhdGE9MDIlN0MwMSU3Q21pY2hh ZWwuYmlzaG9wJTQwbWljcm9zb2Z0LmNvbSU3QzNiYWYwNDMyNWUwZjRjOTQ0YzEzMDhkNTEyNzU4 ZDMzJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjQzNTIx ODQ2MzA2NjgwNSZhbXA7c2RhdGE9V0xKWFJFOUp6M3J0THNWcXhCT3lhTWNPSSUyQnE2blo4VEpt bEFyc2JoVTJNJTNEJmFtcDtyZXNlcnZlZD0wIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cv YmFzZS1kcmFmdHMvcHVsbC84NzI8L2E+IDxicj4NCiZndDsgPGJyPg0KJmd0OyBDaGVlcnMsIDxi cj4NCiZndDsgPGJyPg0KJmd0OyBSeWFuIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR21MB01412840605BA9EBC872900D87480MWHPR21MB0141namp_-- From nobody Fri Oct 13 14:05: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 7A80B126B6E for ; Fri, 13 Oct 2017 14:05:08 -0700 (PDT) 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, 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 5bYi3eaL8dTC for ; Fri, 13 Oct 2017 14:04:58 -0700 (PDT) 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 DD0A7127517 for ; Fri, 13 Oct 2017 14:04:57 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id l196so12013117itl.4 for ; Fri, 13 Oct 2017 14:04:57 -0700 (PDT) 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=7tdLS11YI1DUyIU1Hy8+3vQ6w/utzRcONGN36iIQ5J4=; b=QjhWS7cYwnp8Gs0xM2Ddrohf4RQDolS0cVrPo3Qr7SqcMv5tlBn/zFof2U6aeJcbTp jexgH9u6/lc13M6kaSrFAgXkcI/QmcqI15xRRnh1pO69xG8/kfvnxqAo+ejKsV5luGMq VYzJ0CUZdJPdbUlZNqP3g1WLWz9G7a8yXmlsUIiiUVWz4toZLck3zu3+PYHEr7qhxPvw 28RYviSm1gfo4mi8WtuNhK3uo0wWCfpX8xqUGeOO0xhAT2Jb7kNb8jCMdFTYLt0F10bA Iz1TDcMGgy2Aa5fRTi2sqgTnruD7WeqnkWfRV4053/9UE5uToGnPZptNFRf2Ig6iPba4 4W4A== 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=7tdLS11YI1DUyIU1Hy8+3vQ6w/utzRcONGN36iIQ5J4=; b=dMkFsKjXYQUNVAZjOhKGpfzfgG88Scr6yvUu2VsMLFgLwB/8O144x5ROqWZu4LdP5s AlwV5wcJLs6Tc964eDszpKFGPwIepBv0DB7+On5rbgoK4yT/X/a/aoHnmGwuP3YlBYK7 D68GtWG3B8kBHynTQwoAIWwfMPyBuX+i99kXsHhoRFrmENd7XnyN2md/JDKHIqLKQfwj EjHyx38suFv5yo0zwXleqCV6/x7N4FHokURm5rfZy+nF8bs6+SdXz4CR2v82RPRQhRub 7ugVnAeckHj9BInyCCXNhkgm7/xiY2Zndc4AWe8uTTbLba0ZoKD97yCMIkOjcEr8ypoj Ycfw== X-Gm-Message-State: AMCzsaUsGnCOmw2greyAWzyFn40VefXtBcrQxz6NmHYq0QxvU8sNjdul inKeJltIewcIoTBjyyPbZuOPfswE2n7ebL722xDM1g== X-Google-Smtp-Source: ABhQp+QDAwAid33Msw7lHPpBJumAu6IhhS5LMWgs+88GiswcADcqxnPuGFvQ2wYe6iSiEyvQvBfXp+yGjxhEdZyxoZs= X-Received: by 10.36.120.136 with SMTP id p130mr4006776itc.54.1507928696787; Fri, 13 Oct 2017 14:04:56 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.4 with HTTP; Fri, 13 Oct 2017 14:04:36 -0700 (PDT) In-Reply-To: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> From: Ian Swett Date: Fri, 13 Oct 2017 17:04:36 -0400 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: Mike Bishop Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Hugues Fafard Content-Type: multipart/alternative; boundary="001a114ab8e4522701055b74024a" 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, 13 Oct 2017 21:05:08 -0000 --001a114ab8e4522701055b74024a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In many ways, they are 4 independent spaces, but Ryan pointed out to me that both for the purposes of draft text and implementation it's very useful to have a single unique identifier for a stream, since otherwise you have to talk about/pass around (StreamID, Type) everywhere instead of just StreamID. Keeping one stream ID avoids creating two of all the stream specific frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET, etc), one for each stream space. Using the two most significant bits would eliminate the usefulness of any variable length integer encoding(current or Martin's new proposal), so using the lower bits makes sense. On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop wrote: > Indeed. I almost think it makes more sense to say that there are four > independent stream spaces, each with their own numbers. That does mean > that each side will need to separately manage Max Stream ID for two space= s, > but that seems more reasonable than the alternative. In fact, this PR > already implies that the limits for unidirectional and bidirectional > streams are handled separately, which gets really weird when the IDs are > interleaved with each other. > > > > In fact, this plays well with the variable-length encoding idea, since th= e > maximum size of a Stream ID would be 62 bits. They could then be stored > locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits indicatin= g which space they > refer to. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=C3= =B8e > J=C3=B8rgensen > *Sent:* Friday, October 13, 2017 1:04 PM > *To:* quic@ietf.org; Hugues Fafard > *Subject:* Re: Identify streams unidirectional vs bidirectional based on > stream ID > > > > Especially with the new variable length encoding proposal, storing the > identifiers early makes sense, as you only have to inspect the first byte= . > But it gets complicated, because you don=E2=80=99t want to use 8 bytes fo= r some > stream types and you don=E2=80=99t want the bits at some random location = in a > decoded 8 byte representation either. > > > > Regardless of bit placement, encoding state using bits is not ideal when > considering variable length encoding because you now use two bits for > length and two bits for stream type, leaving only 16 different streams > before the stream identifier needs to use two bytes, and so forth. > > > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote: > > I see, you used the 2 least significant bits to encode that > information. When only using one bit to indicate the direction, it > boiled down to odd/even which more or less made sense, but when using > 2 bits that breaks apart. > > Why not use the most significant bits instead? That way, getting the > 'clean' stream ID without the flags would be as simple doing a `& > 0x3F...FF` instead of bit-shifting things around. Similarly, encoding > the stream ID would just entail `| 0x?0...00` to set the appropriate > bits and also avoid bit-shifts. > > Regards, > Hugues > > On 2017-10-13 20:51, Ryan Hamilton wrote: > > As I understand the discussions at the interim, we've decided to > > allow streams to be unidirectional or bidirectional. I support this > > idea and was motivated to write up an idea I've been thinking about > > for a while. In the same way that we use a bit in the stream ID to > > identify the client vs server nature of the stream, we can use a > > bit to identify the directionality. This divides the stream ID > > space neatly into 4 distinct spaces (much like the 2 two we have > > today: client/server). In addition this means that a stream ID > > always uniquely identifies a single stream, and frames which > > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, > > RST_STREAM, etc) do not need to explicitly convey the > > directionality as fields in those frames (or implicitly based on > > the directionality of the frames themselves). > > > > https://github.com/quicwg/base-drafts/pull/872 > > > > > Cheers, > > > > Ryan > > --001a114ab8e4522701055b74024a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In many ways, they are 4 independent spaces, but Ryan poin= ted out to me that both for the purposes of draft text and implementation i= t's very useful to have a single unique identifier for a stream, since = otherwise you have to talk about/pass around (StreamID, Type) everywhere in= stead of just StreamID.

Keeping one stream ID avoids cre= ating two of all the stream specific frames(STOP_SENDING, RST_STREAM, STREA= M_FRAME, MAX_DATA_OFFSET, etc), one for each stream space.

Using the two most significant bits would eliminate the usefulness= of any variable length integer encoding(current or Martin's new propos= al), so using the lower bits makes sense.

On Fri, Oct 13, 2017 at 4:56 PM, Mike B= ishop <Michael.Bishop@microsoft.com> wrote:

Indeed.=C2=A0 I almost think it makes more sense to = say that there are four independent stream spaces, each with their own numb= ers.=C2=A0 That does mean that each side will need to separately manage Max= Stream ID for two spaces, but that seems more reasonable than the alternative.=C2=A0 In fact, this PR already implies th= at the limits for unidirectional and bidirectional streams are handled sepa= rately, which gets really weird when the IDs are interleaved with each othe= r.

=C2=A0

In fact, this plays well with the variable-length en= coding idea, since the maximum size of a Stream ID would be 62 bits.=C2=A0 = They could then be stored locally as a 64-bit value with the =E2=80=9Cextra= =E2=80=9D bits indicating which space they refer to.

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Friday, October 13, 2017 1:04 PM
To: quic@ietf.org= ; Hugues Fafard <fafard@in.tum.de>
Subject: Re: Identify streams unidirectional vs bidirectional based = on stream ID

=C2=A0

Especially with the new variable length encoding = proposal, storing the identifiers early makes sense, as you only have to in= spect the first byte. But it gets complicated, because you don=E2=80=99t want to use 8 bytes for some stream types and yo= u don=E2=80=99t want the bits at some random location in a decoded 8 byte r= epresentation either.

=C2=A0

Regardless of bit placement, encoding state using= bits is not ideal when considering variable length encoding because you no= w use two bits for length and two bits for stream type, leaving only 16 different streams before the stream identifier needs= to use two bytes, and so forth.

=C2=A0

=C2=A0

Kind Regards,

Mikkel Fahn=C3=B8e= J=C3=B8rgensen

=C2=A0

On 13 October 2017 at 21.50= .06, Hugues Fafard (f= afard@in.tum.de) wrote:

I see, you used th= e 2 least significant bits to encode that
information. When only using one bit to indicate the direction, it
boiled down to odd/even which more or less made sense, but when using
2 bits that breaks apart.

Why not use the most significant bits instead? That way, getting the
'clean' stream ID without the flags would be as simple doing a `&am= p;
0x3F...FF` instead of bit-shifting things around. Similarly, encoding
the stream ID would just entail `| 0x?0...00` to set the appropriate
bits and also avoid bit-shifts.

Regards,
Hugues

On 2017-10-13 20:51, Ryan Hamilton wrote:
> As I understand the discussions at the interim, we've decided to <= br> > allow streams to be unidirectional or bidirectional. I support this > idea and was motivated to write up an idea I've been thinking abou= t
> for a while. In the same way that we use a bit in the stream ID to > identify the client vs server nature of the stream, we can use a
> bit to identify the directionality. This divides the stream ID
> space neatly into 4 distinct spaces (much like the 2 two we have
> today: client/server). In addition this means that a stream ID
> always uniquely identifies a single stream, and frames which
> mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA,
> RST_STREAM, etc) do not need to explicitly convey the
> directionality as fields in those frames (or implicitly based on
> the directionality of the frames themselves).
>
> https://github.com/quicwg/base-drafts/pull/872
>
> Cheers,
>
> Ryan


--001a114ab8e4522701055b74024a-- From nobody Fri Oct 13 15:04: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 65465132D8A for ; Fri, 13 Oct 2017 15:04:02 -0700 (PDT) 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 (2048-bit key) header.d=mnot.net header.b=WVXVTsj+; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=Uz3C8EXa Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jkp9sJWodmm for ; Fri, 13 Oct 2017 15:03:59 -0700 (PDT) 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 C1963124239 for ; Fri, 13 Oct 2017 15:03:59 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 35E3B2098A for ; Fri, 13 Oct 2017 18:03:58 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 13 Oct 2017 18:03:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h= content-type:date:from:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=rSkXj0 CZK3LAehG/4KAQ7mQckpCfd7LDkvSQu3Pmuko=; b=WVXVTsj+X+b0jOt64H7Ctj h8H5oo0Df0jlmWvF324wb2Pq5YAK8c7TEFO5wlGkfuLi+RfFo6GEahXZUt0XbNm4 tjGskE4Xs/84inhW8TZ10EPLNdMSf7hDys/YDjA4/Rq5nzc05mR2ex/jCVgU8XUa bsJkM8VNXzjVEzvRRkOBd1WK1mV5STgGxmiyB5wXfcd5HT6ijUdos+AxdgwvKQPj pqikDELI8u34dEVdsLjNEC95UkAKXe7G4NjaAyXINrZS5rp5w5cxdX4QmksHLKGj Py8a6xfjGv35TcBVcVBJnYHVXEBhxJk8vNNKIfqv6lmS0HxWWsaIeAD4BybLqy5A == DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-type:date:from:message-id :mime-version:references:subject:to:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=rSkXj0CZK3LAehG/4KAQ7mQckpCfd7LDkvSQu3Pmu ko=; b=Uz3C8EXar9D58a+dudb3j2Q+91gaYjYyVPTd9GU36FPlo86AqesiXOvla SAa7YOVH6TplLc1gDiRTALVaN6JWySRAt3JidsM+Z8+MWTqIDccO/8VGotQfvJmL hrEXH2a11349/G0Hxvhj7oEIPvuFDg4vTX/3z457c1gpE/Ik9X186tPAAI4VLGYh 8XjjmKF0eC9dldZxVzcPhcqkD5+nbLc93PkX3be9edIbEVFvwwgx6L2jDjj8AhWR LCXyIlg/C+qRpWng64DWFNs/wys8pzn7rmZVhWglKTrvR+1MkcQURN91TUGV2EeH tMsdBh1JmwNOQy5CLh6vwU4Z3t3JQ== X-ME-Sender: Received: from [10.100.20.220] (unknown [8.18.217.202]) by mail.messagingengine.com (Postfix) with ESMTPA id BFCFB7F3AB for ; Fri, 13 Oct 2017 18:03:57 -0400 (EDT) From: Mark Nottingham Content-Type: multipart/alternative; boundary="Apple-Mail=_94CA6342-B12F-4374-9CFB-58B69B3EE0AC" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Fwd: IETF 100 Preliminary Agenda Message-Id: <8B55D726-3D8E-4874-9F17-991DCC3C06DC@mnot.net> References: <150793205528.5002.3779402115235848093.idtracker@ietfa.amsl.com> To: QUIC WG Date: Fri, 13 Oct 2017 15:03:57 -0700 X-Mailer: Apple Mail (2.3445.1.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: Fri, 13 Oct 2017 22:04:02 -0000 --Apple-Mail=_94CA6342-B12F-4374-9CFB-58B69B3EE0AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii For those coming to Singapore, we're on Tuesday and Wednesday. Note that = this is a draft agenda, and may change. Cheers, > Begin forwarded message: >=20 > From: IETF Agenda > Subject: IETF 100 Preliminary Agenda > Date: 13 October 2017 at 3:00:55 pm GMT-7 > To: "Working Group Chairs" > Reply-To: IETF Agenda > Archived-At: = >=20 > The IETF 100 preliminary agenda has been posted. The final agenda will = be published on Friday, October 20, 2017. =20 >=20 > If you would like to request a change to the preliminary agenda, = please send a message to agenda@ietf.org and copy all relevant Area = Directors. >=20 > https://datatracker.ietf.org/meeting/100/agenda.html > https://datatracker.ietf.org/meeting/100/agenda.txt >=20 > Thank you! >=20 > IETF Secretariat >=20 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_94CA6342-B12F-4374-9CFB-58B69B3EE0AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii For = those coming to Singapore, we're on Tuesday and Wednesday. Note that = this is a draft agenda, and may change.

Cheers,


Begin forwarded message:

From: = IETF Agenda <agenda@ietf.org>
Subject: = IETF 100 = Preliminary Agenda
Date: = 13 October 2017 at 3:00:55 pm = GMT-7
To: = "Working Group Chairs" <wgchairs@ietf.org>
Reply-To: = IETF Agenda <agenda@ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/wgchairs/ZNCMn16MBNSOp8lF= vFKIFxn_t5w>

The IETF 100 preliminary agenda has been = posted. The final agenda will be published on Friday, October 20, 2017. =  

If you would like to request a = change to the preliminary agenda, please send a message to agenda@ietf.org and copy = all relevant Area Directors.

https://datatracker.ietf.org/meeting/100/agenda.html
https://datatracker.ietf.org/meeting/100/agenda.txt

Thank you!

IETF = Secretariat


--
Mark Nottingham  =  https://www.mnot.net/

= --Apple-Mail=_94CA6342-B12F-4374-9CFB-58B69B3EE0AC-- From nobody Sat Oct 14 00:04:25 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 417E7132D41; Sat, 14 Oct 2017 00:04:23 -0700 (PDT) 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-transport-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150796466319.4994.10865371663317337108@ietfa.amsl.com> Date: Sat, 14 Oct 2017 00:04:23 -0700 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: Sat, 14 Oct 2017 07:04:23 -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: A UDP-Based Multiplexed and Secure Transport Authors : Jana Iyengar Martin Thomson Filename : draft-ietf-quic-transport-07.txt Pages : 82 Date : 2017-10-13 Abstract: This document defines the core of the QUIC transport protocol. This document describes connection establishment, packet format, multiplexing and reliability. Accompanying documents describe the cryptographic handshake and loss detection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-transport/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-transport-07 https://datatracker.ietf.org/doc/html/draft-ietf-quic-transport-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-transport-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 Sat Oct 14 00:04:47 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 7EC59133207; Sat, 14 Oct 2017 00:04:23 -0700 (PDT) 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-tls-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150796466347.5206.2840092358418940886@ietfa.amsl.com> Date: Sat, 14 Oct 2017 00:04:23 -0700 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: Sat, 14 Oct 2017 07:04:23 -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 : Using Transport Layer Security (TLS) to Secure QUIC Authors : Martin Thomson Sean Turner Filename : draft-ietf-quic-tls-07.txt Pages : 38 Date : 2017-10-13 Abstract: This document describes how Transport Layer Security (TLS) is used to secure 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/tls [3]. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-tls/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-tls-07 https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-tls-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 Sat Oct 14 02:07: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 49B3313235C for ; Sat, 14 Oct 2017 02:07:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, 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 HDxJGVjpZzpP for ; Sat, 14 Oct 2017 02:07:23 -0700 (PDT) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::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 7DFF9132143 for ; Sat, 14 Oct 2017 02:07:23 -0700 (PDT) Received: by mail-io0-x235.google.com with SMTP id 189so11297429iow.10 for ; Sat, 14 Oct 2017 02:07:23 -0700 (PDT) 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=FsDQf6kQfxKgbDHfdbifoqctS9RkrVk2wKzsVKIXH1Q=; b=Xn+HMC/t+tZTgaNvd7FyoDwk+evYlGqzpVTKxW+Bz4BlC61mpC+OfMoIgCoI2UinX+ /QTycmsI3l6+sgNfU6fWDWqa8Muurys0tI8RjdQmyCjP6l7hq5znnrZHxrDW6DIvCXzV sU6/pbydeaPlybQCSD8X+pmXtXMBNnJwh8THUl2QZXOkkJqsYvPtY/j7NUEYGqt33JWc 9iW48XFwYqS94vxCDY21wD2zaBH5K702KvEU+sqYGizNz6QKGqIGqDiBNtHf+vWpoXKY Mu7rvxMHneTIF7+VxSALJyvyFvZkoQiCVkYdwxSb+V5V5nZtcRTSHWe0Er19fAWLQ3Sd pHpA== 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=FsDQf6kQfxKgbDHfdbifoqctS9RkrVk2wKzsVKIXH1Q=; b=pzj9qTwjZkcH0QQ0JPdLDzChcaimB0W45o8K8G9L93lr2zM5n0gitzzLPTR5ngkQZ0 plEMvwT0tUvf8IfCvmvC8ia85SusM+5A6kyVkxTNHbzMMhAzveyDttwCKgiAam/mHpNm jvMotEY3T9gHRSJ1Yz12vGaUxSCk/eVASMAYIeBErjYm3ECy4qd0AHQ81TcL/kprY3Gw uHF6pWuaGSWvieF1guCGOTHI7kTKh7b3M7vXqG+iYlAq9HzAqHsajZE0ZjbV10cXNdpb Y7n+HGYFvPNeJGjbh5ZpNj8lYll3F8KnUkp/r+ykt93Nt0Sn6F5d6FOt/sg67abBlXl9 Gqpg== X-Gm-Message-State: AMCzsaXKrvQ42LBI3EngnLRTn+CXirdOoS4WsklcRYSQzWrG25v+9Kay Ikva1DN4kpHgTG34DnNFgfSVCgMth5wGiq3h8rjAsA== X-Google-Smtp-Source: AOwi7QDdbLkAGKXtkhHHhdagojDuN6SuLdcjl8QBbE0uXStKxHuUyPyPUUi2OKIr0MrQX3INBpifMQhNVnzOuW/16iU= X-Received: by 10.107.47.17 with SMTP id j17mr4940373ioo.96.1507972042529; Sat, 14 Oct 2017 02:07:22 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 14 Oct 2017 02:07:21 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 14 Oct 2017 02:07:21 -0700 Message-ID: Subject: packet number increments To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a11377560ed1f63055b7e19d8" 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, 14 Oct 2017 09:07:25 -0000 --001a11377560ed1f63055b7e19d8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the recently published 07 transport draft there are two formulations on packet numbers section 5.4.1: The first Client Initial packet that is sent by a client contains a random 31-bit value. All subsequent packets contain a packet number that is incremented by one, see (Section 5.7 ). section 5.7 The packet number for sending MUST increase by at least one after sending any packet, unless otherwise specified (see Section 5.7.1 ). Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --001a11377560ed1f63055b7e19d8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = In the recently publ= ished 07 transport draft there are two formulations on packet numbers
=

section 5.4.1:

The first=
 Client Initial packet that is sent by a client contains a
   random 31-bit value.  All subsequent packets contain a packet number
   that is incremented by one, see (Section 5.7).

section 5.7

=
 The packet
   number for sending MUST increase by at least one after sending any
   packet, unless otherwise specified (see Section 5.7.1).





Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen
--001a11377560ed1f63055b7e19d8-- From nobody Sat Oct 14 02:12: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 9762A13235C for ; Sat, 14 Oct 2017 02:12:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 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, 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 ieLFbI6YS6tI for ; Sat, 14 Oct 2017 02:12:13 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001: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 92074132143 for ; Sat, 14 Oct 2017 02:12:13 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id h70so11307670ioi.4 for ; Sat, 14 Oct 2017 02:12:13 -0700 (PDT) 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; bh=o7z7sqXNt7gdija6oo/KYs/+FzEnTHXdkIYxJ/tA81M=; b=jKilQqlA2k6hiYLGQzMMBhfzoRp3BMsazRoJGGbB2m+a+B1G3vawQv1aA4t3KtouoP cM50NEBgAW75wSUyc+ZogDL0B8ytwxMPi50vM4outrZmJ35oTRa6vr5EaHV7aCSaRHF9 9Zm2xFWl0GKGtEPJR7MY4rHLEf3EJLzH45Hagwd34PfpeS7CEvmwXWi03WKmxSn4j6FZ g/YHVEPb3w2n3nqdNxB7cwR16Ls+M+bhoURCoKuOMD485weP1s/XAZXlxV8250yG4sAp BZ+94lwHKd94WRMRycEKCuwAlqJJNusByHQ7kCYwAIm/xc2YYgAFCDPfFu+4U25kGim4 Dukw== 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; bh=o7z7sqXNt7gdija6oo/KYs/+FzEnTHXdkIYxJ/tA81M=; b=QawkQ+pohaHn87JzExz0h4gZqMRvHHyt7UHNrkTCebe5TpO9tsUhrzqXoXBFz8ad63 gnQK3gvV47kLb0SbUWwAccUpOufgN2jIms1qNb/SCDqSLvUSAJk3qzGIfdlcXwVe7t+W uht4nvFWJqSX3Otr+PsjkvRwUSZe8i8cukEAgFikRi0MqP61a8EX9va1Okh0PhJS8spZ 0tFFVPK2/GNSJB5YHVeq0QygMXyP+RFqj0WEID77ch7HcwKANTsn4lAN/b64+UHz10r4 MZHoaxtE4ldD/nc07lcV7pjrEa+c/+5CRTCJ7uxiOT6/WX++GVSuzXn8csFHVGxpjz0o wMPw== X-Gm-Message-State: AMCzsaU2z7cG5121+htEKGyay+ecZpbm1/SANvlgcyZlNJzjFFYk7wuw r/LiDAieNWJ7I473tWkREZeaYIpWI/R4Nos62u396w== X-Google-Smtp-Source: AOwi7QCwDnHCYTpv72EsRZrEWnbcbPy0Fjp9jop9mD3fQIF8paw84ADy5d1ynjo14Df0Fwo/OY2Gf28x2wmThxM2GLg= X-Received: by 10.107.164.76 with SMTP id n73mr4859499ioe.175.1507972332866; Sat, 14 Oct 2017 02:12:12 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Sat, 14 Oct 2017 02:12:12 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Sat, 14 Oct 2017 02:12:12 -0700 Message-ID: Subject: Re: packet number increments To: IETF QUIC WG Content-Type: multipart/alternative; boundary="001a1142249c3b500b055b7e2bee" 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, 14 Oct 2017 09:12:16 -0000 --001a1142249c3b500b055b7e2bee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I should have mentioned my point: incremented by at LEAST one vs exactly incremented by one. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 14 October 2017 at 11.07.21, Mikkel Fahn=C3=B8e J=C3=B8rgensen (mikkelfj= @gmail.com) wrote: In the recently published 07 transport draft there are two formulations on packet numbers section 5.4.1: The first Client Initial packet that is sent by a client contains a random 31-bit value. All subsequent packets contain a packet number that is incremented by one, see (Section 5.7 ). section 5.7 The packet number for sending MUST increase by at least one after sending any packet, unless otherwise specified (see Section 5.7.1 ). Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen --001a1142249c3b500b055b7e2bee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I should have mentio= ned my point:

increme= nted by at LEAST one vs exactly incremented by one.



Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

=

On 14 October 2017 at 11.07.21, Mikkel Fahn=C3= =B8e J=C3=B8rgensen (mikkelfj@gmail.c= om) wrote:

In the recently published 07 transport draft there are two formulations on packet numbers

section 5.4.1:

The first Client Initial packet that is sent by a cli=
ent contains a
   random 31-bit value.  All subsequent packets contain a packet number
   that is incremented by one, see (Section 5.7).

section 5.7

 The packet
   number for sending MUST increase by at least one after sending any
   packet, unless otherwise specified (see Section 5.7.1).





Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

--001a1142249c3b500b055b7e2bee-- From nobody Sat Oct 14 07:04:57 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 99AF113293A; Sat, 14 Oct 2017 07:04:50 -0700 (PDT) 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-http-07.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.63.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150798989061.5024.3331224299751603138@ietfa.amsl.com> Date: Sat, 14 Oct 2017 07:04:50 -0700 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: Sat, 14 Oct 2017 14:04:51 -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 : Hypertext Transfer Protocol (HTTP) over QUIC Author : Mike Bishop Filename : draft-ietf-quic-http-07.txt Pages : 35 Date : 2017-10-13 Abstract: The QUIC transport protocol has several features that are desirable in a transport for HTTP, such as stream multiplexing, per-stream flow control, and low-latency connection establishment. This document describes a mapping of HTTP semantics over QUIC. This document also identifies HTTP/2 features that are subsumed by QUIC, and describes how HTTP/2 extensions can be ported to QUIC. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-http/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-http-07 https://datatracker.ietf.org/doc/html/draft-ietf-quic-http-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-http-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 Sun Oct 15 12:47: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 A5355124F57 for ; Sun, 15 Oct 2017 12:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WImbSeuP8OBk for ; Sun, 15 Oct 2017 12:47:24 -0700 (PDT) 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 5FD961331DC for ; Sun, 15 Oct 2017 12:47:23 -0700 (PDT) X-AuditID: c1b4fb25-1b7d19c000000c94-45-59e3bb495022 Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id B5.B7.03220.94BB3E95; Sun, 15 Oct 2017 21:47:22 +0200 (CEST) Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.27) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sun, 15 Oct 2017 21:46:54 +0200 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=3CUTCECcHhswBgAHDWHTkm3u/wLC0woN8bLvB/7Qkmw=; b=J/Dqzs+TixRq4j1uLAN0/XE9Y7PMxb6Vi8oENwzpOIMGkaau+D9onUFYpX7U0se+Ue1xcgvXPaXD9eS89eeDuNXoS/SnjfV2tox7IKQflAoutIz+CS1C4Ab8N5IYaUHIpmsbKrj8UlNbXSvHwVC5IDP/5Ja9fh1spBrQZLnMHio= Received: from DB4PR07MB348.eurprd07.prod.outlook.com (10.141.234.148) by DB4PR07MB346.eurprd07.prod.outlook.com (10.141.234.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.5; Sun, 15 Oct 2017 19:46:52 +0000 Received: from DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784]) by DB4PR07MB348.eurprd07.prod.outlook.com ([fe80::ac05:1040:f4fc:784%15]) with mapi id 15.20.0077.022; Sun, 15 Oct 2017 19:46:51 +0000 From: Ingemar Johansson S To: marcelo bagnulo braun , QUIC WG CC: Ian Swett , "'csp@csperkins.org'" , "Mirja Kuehlewind (IETF)" , "ietf@trammell.ch" , "Jana Iyengar (jri@google.com)" , Subir Das , Ingemar Johansson S Subject: RE: ECN design team wiki Thread-Topic: ECN design team wiki Thread-Index: AdNDJTwcKtg1luFJTdO+JTp9EOqxmwA0rG6AAH2afMA= Date: Sun, 15 Oct 2017 19:46:51 +0000 Message-ID: References: <758855f3-ea7e-2020-bfd4-30c356df3bb9@it.uc3m.es> In-Reply-To: <758855f3-ea7e-2020-bfd4-30c356df3bb9@it.uc3m.es> 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: [213.113.27.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB346; 6:3vWHmGMG6jnwvJltp/iu2V1i8AArBuOqzhODzKBqRFMhmCP77GLg4le5eBMoI11QjJw6akE2g3EVQLbKin/sIEa/wH/q+b0B1UT/cxOOTQxzevaP3gzebJbxwBSBXPY6kwtONwGmnPVsLQbaTXQ8aYdrl66ZI5iz6LlH67srTWLdp0ZLu3XhyRtS8VOsB5xhH+AiwMMKXIpLl1vWNC4trX6VtaiN6/0PfUUkucKePBjoXlTqoUjKhAwtoZDnry77kJh+rUZsEnX23pdDgSKqvdJ4PWdJ/ccPTMzIssMhEYUUnfib1arA6OKqIwDl+8Tmh6I1OVAeEHBMgA4TfXRTNQ==; 5:v2kC6C6bBh99xtW75aTGXi7hnsq2w/ctbDRsWb/imeVmdMRQQg1blSAL83U2o8GgB1e4mzcrPTqO+uTdbY2G4X2WnEL28W41mKGTiRW5Kgs4Oc4xbUG2cSUO6HIV5bXDUH9ixslH9RDNIIO8vX3QXA==; 24:n6nd9s6OXHO3FOIe3S980FX9VY9BL+tGVrkJdPo9HCs8pYASsLLo8JTvBFo+6KhT314jqld5TUj6TE7EU/DJ2mKoTvV4mTLjQbcfrpuMFHw=; 7:tLoX1d5SoioGMZDwmTfy/rLnt19qD1MMg12eSowVpMPFaimX3Awy3DiNY2jAIswBj6bUAeIlHU244RDNEHJfxuP9u5y+XFgpnlQoF2mCx11xdMVSCaYQQ7XkUIg78isHOFiLpq/rCfHYHqNQAbOqjrqBqeOVwjeNp1NICYlT/ziGprauusYFWJfJDOt/uqD7SzdsxzmvS9LkJO+tYsnB7/LnLZtJqXUOcQzCZZSGiFM= x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(189002)(13464003)(86362001)(110136005)(54906003)(316002)(105586002)(106356001)(3660700001)(6306002)(9686003)(3846002)(68736007)(5250100002)(7736002)(74316002)(305945005)(34040400001)(2950100002)(5660300001)(7696004)(478600001)(14454004)(6116002)(53936002)(966005)(53546010)(102836003)(4326008)(3480700004)(6246003)(25786009)(39060400002)(107886003)(229853002)(6506006)(81166006)(33656002)(3280700002)(2906002)(6436002)(189998001)(55016002)(99286003)(8676002)(81156014)(8936002)(50986999)(2900100001)(101416001)(66066001)(97736004)(54356999)(76176999); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB346; H:DB4PR07MB348.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: ce0a2799-a070-4b95-7b56-08d514057b52 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DB4PR07MB346; x-ms-traffictypediagnostic: DB4PR07MB346: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(211936372134217)(153496737603132); 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)(3002001)(100000703101)(100105400095)(93006095)(93001095)(920507026)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB346; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB346; x-forefront-prvs: 046164D5C4 received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2017 19:46:51.8250 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB4PR07MB346 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA01SaUhUYRTlm/fevOcy8HLBiwvhgD8q1EqlKUXyl5OhBIFoEDnqQ4d0tHmO ZmL4Q/vhkubaTJkKY45TkCu5UaNpmoZ72phbqOSASYa7pM34GfTvnHvOvffcj48h7DooZ0au SOGUClmCWGhNqiPeuniGdC5FnjfkMZI60wCS7M23U5LV6Q1C0pi9LpQU99WQkpwVvVCSX20j KTW8pK8y0vKFBaG0XTNHS6ubVFKtdk8g3Z5upKTZGzWUdPm9mrxB37IOiOUS5Kmc0jswyjre ULxOJE+53e+c1dNZaNM1F1kxwPpCyWwznYusGTu2F8H0jJ7AZABBnv6QshCSLSCgu/sjiZUy AfwyVlGYLCDY2h4XWoYJ2QCo79lBFuzABsPW0OQxJtgOARx+u5SLGMaedQd9vy22iKFX00Bi fAXqhk2EBZOsB2yWT1EWLGJvwcGPzyeRHiNY3ag9FqzYQHhdUnjcjFg3WNiZJ/EuJ5hZrhLg 41jQdo0QGDuCaemQwv4Y+G0soCx5wJyntzQNW9xgvCoPWXYBm0ODoaQVYcEHcou6KCwUCuHP ZP7J0FDQ9c0JsFCJwKSepPHUMzC66I89iXBUVHcSSA67X5oJ7J+koKyhX1CEPDX/BdeY2wlz +5sOb1x2h9K877Tm+DFOwSf1MlmNSD1y5Dk+OjHuoo8Xp5TH8HySwkvBpTQh84/qbjnwaEMT a0E9iGWQ2Fakq1uKtKNkqXx6Yg8ChhA7iJ5nmUuiWFn6A06ZdEepSuD4HuTCkGInUdC70Qg7 Nk6Wwt3luGRO+U8VMFbOWci/V/Vha+Nn21wpmidtdjpVRt8j+b1zN/24nTAvt8GMyxl+JR72 tSntxqCIa/HZ4Q+N9VpZJjUQN8SH09VRTq7zhtOPnmp1T6a9xGn7oWNfR8pfpUWHBB+pWtS3 BcOZqqr9sIrWkcEXKxXO/c8q12J19dd1szUN22h3bDF/wltM8vGyC2cJJS/7C47MwMdNAwAA 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, 15 Oct 2017 19:47:27 -0000 SGkgTWFyY2Vsbw0KDQpZb3UgYXJlIGNvcnJlY3QgaW4geW91ciBvYnNlcnZhdGlvbiB0aGF0IHRo ZSAtMDMgdmVyc2lvbiBpbmRpY2F0ZXMgdGhhdCBFQ04gY2FwYWJpbGl0eSBleGNoYW5nZSAod2l0 aCBFQ1QgY29kZXBvaW50IHNldCkgc2hvdWxkIHRha2UgcGxhY2UgYWZ0ZXIgdGhlIFFVSUMgY29u bmVjdGlvbiBzZXR1cC4gSG93ZXZlciwgSSBicm91Z2h0IHVwIHRoZSBwb3NzaWJpbGl0eSB0aGF0 IHRoaXMgY2FuIGFsc28gdGFrZSBwbGFjZSBhbHJlYWR5IGF0IHRoZSBjb25uZWN0aW9uIHNldHVw IGF0IGhlIFFVSUMgV0cgc2Vzc2lvbiBhdCBJRVRGLTk5LiBUaGVyZSBhcmUgc29tZSBwb3RlbnRp YWwgYmVuZWZpdHMgd2l0aCB0aGlzIGFuZCBBcHBsZcK0cyBFQ04gdGVzdCByZXN1bHQgKG9uIFRD UCkgc2VlbSB0byBpbmRpY2F0ZSB0aGF0IHRoaXMgaXMgc2FmZS4NCkJhc2VkIG9uIHRoaXMsIEkg YmVsaWV2ZSB0aGF0IG9uZSBzaG91bGQgYXBwZW5kIFIuNyBpbiB0aGUgRUNOIFFVSUMgd2lraSB3 aXRoIA0KIkVDTiBjYXBhYmlsaXR5IGV4Y2hhbmdlIE1BWSB0YWtlIHBsYWNlIGVpdGhlciBhdCBv ciBhZnRlciBRVUlDIGNvbm5lY3Rpb24gc2V0dXAuIiAgDQoNCi9JbmdlbWFyDQogDQoNCj4gLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogbWFyY2VsbyBiYWdudWxvIGJyYXVuIFtt YWlsdG86bWFyY2Vsb0BpdC51YzNtLmVzXQ0KPiBTZW50OiBkZW4gMTMgb2t0b2JlciAyMDE3IDA5 OjUwDQo+IFRvOiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNz c29uLmNvbT47IFFVSUMgV0cNCj4gPHF1aWNAaWV0Zi5vcmc+DQo+IENjOiBJYW4gU3dldHQgPGlh bnN3ZXR0QGdvb2dsZS5jb20+OyAnY3NwQGNzcGVya2lucy5vcmcnDQo+IDxjc3BAY3NwZXJraW5z Lm9yZz47IE1pcmphIEt1ZWhsZXdpbmQgKElFVEYpIDxpZXRmQGt1ZWhsZXdpbmQubmV0PjsNCj4g aWV0ZkB0cmFtbWVsbC5jaDsgSmFuYSBJeWVuZ2FyIChqcmlAZ29vZ2xlLmNvbSkgPGpyaUBnb29n bGUuY29tPjsgU3ViaXINCj4gRGFzIDxzdWJpcmRhczIxQGdtYWlsLmNvbT4NCj4gU3ViamVjdDog UmU6IEVDTiBkZXNpZ24gdGVhbSB3aWtpDQo+IA0KPiBIaSwNCj4gDQo+IFRoYW5rcyBmb3IgdGhp cy4NCj4gT25lIHF1ZXN0aW9uLCBub3Qgc3VyZSBpZiB0aGlzIGhhcyBiZWVuIGRpc2N1c3NlZCBv ciBub3QsIGlzIGEgcmVxdWlyZW1lbnQgdG8NCj4gYWxsb3cgRUNUL0NFIG1hcmtpbmcgb2YgYWxs IHBhY2tldCB0eXBlIGluIGEgcXVpYyBjb25uZWN0aW9uPyAoaW5jbHVkaW5nDQo+IGhhbmRzaGFr ZSwgYWNrcywgZXRjKSAoaSBzZWUgeW91IGhhdmUgYSByZWZlcmVuY2UgdG8gdGhlIGdlbmVyYWxp emVkIEVDTg0KPiBkcmFmdCwgYnV0IGl0IGlzIG5vdCByZWFsbHkgcmVmZXJlbmNlZCBpbiB0aGUN Cj4gZG9jdW1lbnQpDQo+IA0KPiBSZWdhcmRzLCBtYXJjZWxvDQo+IA0KPiANCj4gRWwgMTIvMTAv MTcgYSBsYXMgMDg6NTMsIEluZ2VtYXIgSm9oYW5zc29uIFMgZXNjcmliacOzOg0KPiA+DQo+ID4g SGkNCj4gPg0KPiA+IEkgY3JlYXRlZCBhIHNtYWxsIEVDTiB3aWtpLiBUaGlzIGNhbiBwZXJoYXBz IGJlIHVzZWQgYXMgYSBzY3JhdGNoLWJvb2sNCj4gPiBmb3IgdGhlIGRlc2lnbiB0ZWFtID8NCj4g Pg0KPiA+IEkgc3RhcnRlZCBvbiBhIGxpc3Qgb2YgcmVxdWlyZW1lbnRzLCBzb21lIG9mIHRoZW0g YXJlIHByb2JhYmx5IGJvdGNoZWQNCj4gPiBidXQgaXQgaXMgYXRsZWFzdCBhIGZpcnN0IHN0YWIg YXQgaXQuIEZlZWwgZnJlZSB0byBlZGl0Lg0KPiA+DQo+ID4gaHR0cHM6Ly9naXRodWIuY29tL3F1 aWN3Zy9iYXNlLWRyYWZ0cy93aWtpL0VDTi1pbi1RVUlDDQo+ID4NCj4gPiAvSW5nZW1hcg0KPiA+ DQo+ID4gKkZyb206KiBNYXJ0aW4gVGhvbXNvbiBbbWFpbHRvOm5vdGlmaWNhdGlvbnNAZ2l0aHVi LmNvbV0NCj4gPiAqU2VudDoqIGRlbiAxMSBva3RvYmVyIDIwMTcgMjM6NTMNCj4gPiAqVG86KiBx dWljd2cvYmFzZS1kcmFmdHMgPGJhc2UtZHJhZnRzQG5vcmVwbHkuZ2l0aHViLmNvbT4NCj4gPiAq Q2M6KiBJbmdlbWFyIEpvaGFuc3NvbiBTIDxpbmdlbWFyLnMuam9oYW5zc29uQGVyaWNzc29uLmNv bT47IEF1dGhvcg0KPiA+IDxhdXRob3JAbm9yZXBseS5naXRodWIuY29tPg0KPiA+ICpTdWJqZWN0 OiogUmU6IFtxdWljd2cvYmFzZS1kcmFmdHNdIERlc2lnbiB0ZWFtIGZvciBFQ04gYW5kL29yDQo+ ID4gdGltZXN0YW1wIGRlc2lnbiB0ZWFtICgjODU2KQ0KPiA+DQo+ID4gRmVlbCBmcmVlIHRvIHVz ZSB0aGUgcXVpY0BpZXRmIGxpc3Qgb3IgdGhlIHdpa2kNCj4gPiA8aHR0cHM6Ly9naXRodWIuY29t L3F1aWN3Zy9iYXNlLWRyYWZ0cy93aWtpPiB0byBjb29yZGluYXRlIHRoaXMgc29ydA0KPiA+IG9m IGFjdGl2aXR5Lg0KPiA+DQo+ID4g4oCUDQo+ID4gWW91IGFyZSByZWNlaXZpbmcgdGhpcyBiZWNh dXNlIHlvdSBhdXRob3JlZCB0aGUgdGhyZWFkLg0KPiA+IFJlcGx5IHRvIHRoaXMgZW1haWwgZGly ZWN0bHksIHZpZXcgaXQgb24gR2l0SHViDQo+ID4gPGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cv YmFzZS1kcmFmdHMvaXNzdWVzLzg1NiNpc3N1ZWNvbW1lbnQtDQo+IDMzNTk2MDANCj4gPiA2Nj4s DQo+ID4gb3IgbXV0ZSB0aGUgdGhyZWFkDQo+ID4gPGh0dHBzOi8vZ2l0aHViLmNvbS9ub3RpZmlj YXRpb25zL3Vuc3Vic2NyaWJlLQ0KPiBhdXRoL0FLT2RHRzRHaFBlcEZxV21rU0tXdENBN21pY0Rn OUJSa3M1c3JUakhnYUpwWk00UDFlVG8+Lg0KPiA+DQo+IA0KDQo= From nobody Mon Oct 16 08:01:51 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE5761344FD for ; Mon, 16 Oct 2017 08:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.73 X-Spam-Level: X-Spam-Status: No, score=-0.73 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, 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=jocSM3Yu; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=Whgjb5xl Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DG9Ag2AaIy9p for ; Mon, 16 Oct 2017 08:01:45 -0700 (PDT) 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 03E921344FF for ; Mon, 16 Oct 2017 08:01:41 -0700 (PDT) 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 v9GEwoQB027822; Mon, 16 Oct 2017 08:01:36 -0700 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=78pwhZS3Y6xuJjtK31txUSwEHRaOjeXqHHX2yImNtjU=; b=jocSM3YuyVXhlApXpXSq0mNcJxuwpjjO6juVUAFZLvyMzfZnScxOkSsQSYQZj9QTFx1N sr40YfsXkkZxXuGlGwoAq7jZSi/Dlxs1NHFkFtrRv3KobxDcSdIgm29NP1h1uWjnRgnX oIe7DXygBxAyu4H5XDfApFcCJgVGJklecsU= Received: from mail.thefacebook.com ([199.201.64.23]) by m0089730.ppops.net with ESMTP id 2dmx8xr656-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 16 Oct 2017 08:01:36 -0700 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.11) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 16 Oct 2017 08:01:34 -0700 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=78pwhZS3Y6xuJjtK31txUSwEHRaOjeXqHHX2yImNtjU=; b=Whgjb5xlwVEEncrtZL+BFI8DWICnkCamAF9pcZEzPh0Kt/YmZlmXmiVZn4ObAEbwNsfQst+roNGhagUHG9cJsVNWHc6RG+wlLoEDcit76JxFaYYADXBObj8+egaL2AFNwlegmiNhdMwn1YWEIo1qlLdVNmawsM8caetaO+8iyK4= Received: from DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) by DM5PR15MB1882.namprd15.prod.outlook.com (10.174.247.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Mon, 16 Oct 2017 15:01:21 +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.0077.022; Mon, 16 Oct 2017 15:01:21 +0000 From: Roberto Peon To: Ian Swett , Mike Bishop CC: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , "quic@ietf.org" , Hugues Fafard Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID Thread-Topic: Identify streams unidirectional vs bidirectional based on stream ID Thread-Index: AQHTRFRftngxozqk0kSQL77VF1fSR6LiMDuAgAAD6QCAAA7DAIAAAjAAgAPcIYA= Date: Mon, 16 Oct 2017 15:01:21 +0000 Message-ID: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [50.240.197.178] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1882; 20:WHLmZ1TLWs6SeaMjjgGSjyHnIlQGSdPIvr51GUva0hZtKTsDsmZwmpqQYzDDvni1d4bFe5vodgxM8vwEMwgDxtma1EYVVw2JwrL4lrXhhQYIpVYWQ6fiHBGsFKtNk7PY/hFc+4j1oEgSimW085e4eVjtFMyTOAw+Kb2279uj3OA= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: d7b456d3-e345-40a8-ac87-08d514a6c37d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(2017052603199)(201703131423075)(201703031133081)(201702281549075); SRVR:DM5PR15MB1882; x-ms-traffictypediagnostic: DM5PR15MB1882: x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(89211679590171)(166708455590820)(189930954265078)(211936372134217)(153496737603132)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(11241501159)(6040450)(2401047)(5005006)(8121501046)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(920507026)(6041248)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123562025)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR15MB1882; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR15MB1882; x-forefront-prvs: 0462918D61 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(199003)(377454003)(377424004)(189002)(24454002)(66066001)(6486002)(2900100001)(236005)(229853002)(8666007)(6512007)(6306002)(54896002)(99286003)(2906002)(561944003)(189998001)(606006)(3280700002)(76176999)(50986999)(54356999)(101416001)(53546010)(3660700001)(93886005)(4326008)(7736002)(1511001)(2421001)(86362001)(3846002)(6116002)(102836003)(45080400002)(82746002)(81166006)(83716003)(81156014)(54906003)(68736007)(5660300001)(8676002)(2950100002)(478600001)(33656002)(25786009)(966005)(14454004)(77096006)(36756003)(8936002)(316002)(6506006)(39060400002)(53936002)(110136005)(106356001)(105586002)(2561002)(34040400001)(4001150100001)(6246003)(6436002)(97736004)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1882; 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_DC15026F237641B3B05EC5606C8E0C73fbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Oct 2017 15:01:21.8619 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1882 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-16_05:, , signatures=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: Mon, 16 Oct 2017 15:01:49 -0000 --_000_DC15026F237641B3B05EC5606C8E0C73fbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gSDIsIHRoZSBldmVuL29kZCB0aGluZyB3YXMganVzdCBhbiBlYXN5IHdheSB0byBlbmNvZGUg YSB1bmlxdWUgSUQgcGVyIHN0cmVhbSB3aGlsZSBpbmRpY2F0aW5nIGRpcmVjdGlvbi4NClRoaXMg cHJvcG9zYWwgc2VlbXMgdG8gZG8gdGhlIHNhbWUgdGhpbmcsIGFuZCB0aGF0IG1ha2VzIHNlbnNl IHRvIG1l4oCUaW5zdGVhZCBvZiBldmVuLW9kZCwgd2UgaGF2ZSBtb2QtNC1vZmZzZXQuDQoNCkni gJlkIGFzayB3aHkgYm90aGVyIHRvIGhhdmUgc2VwYXJhdGUgc3RyZWFtIGxpbWl0cy4gWW91IGNv dWxkIHN0aWxsIGp1c3QgaGF2ZSB0aGUgb25lIGxpbWl0IGZvciB0aGUgb3ZlcmFsbCBzcGFjZS4N CldpdGggSDIsIHRoYXQgd2FzIHBhcnQgb2YgdGhlIHBvaW50IG9mIHB1dHRpbmcgaXQgdGhlcmUg KHRob3VnaCBpdCB3YXMgaW1wbGl0KeKAlGl0IHdhcyBhbGwgcGFydCBvZiBvbmUgc3BhY2UsIGFu ZCB0aHVzIHRoZSBzcGFjZSB3YXMgc2luZ2x5IGNvdW50YWJsZSENCg0KLT1SDQoNCkZyb206IFFV SUMgPHF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIElhbiBTd2V0dCA8aWFuc3dl dHRAZ29vZ2xlLmNvbT4NCkRhdGU6IEZyaWRheSwgT2N0b2JlciAxMywgMjAxNyBhdCAyOjA1IFBN DQpUbzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+DQpDYzogTWlr a2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlra2VsZmpAZ21haWwuY29tPiwgInF1aWNAaWV0Zi5v cmciIDxxdWljQGlldGYub3JnPiwgSHVndWVzIEZhZmFyZCA8ZmFmYXJkQGluLnR1bS5kZT4NClN1 YmplY3Q6IFJlOiBJZGVudGlmeSBzdHJlYW1zIHVuaWRpcmVjdGlvbmFsIHZzIGJpZGlyZWN0aW9u YWwgYmFzZWQgb24gc3RyZWFtIElEDQoNCkluIG1hbnkgd2F5cywgdGhleSBhcmUgNCBpbmRlcGVu ZGVudCBzcGFjZXMsIGJ1dCBSeWFuIHBvaW50ZWQgb3V0IHRvIG1lIHRoYXQgYm90aCBmb3IgdGhl IHB1cnBvc2VzIG9mIGRyYWZ0IHRleHQgYW5kIGltcGxlbWVudGF0aW9uIGl0J3MgdmVyeSB1c2Vm dWwgdG8gaGF2ZSBhIHNpbmdsZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgYSBzdHJlYW0sIHNpbmNl IG90aGVyd2lzZSB5b3UgaGF2ZSB0byB0YWxrIGFib3V0L3Bhc3MgYXJvdW5kIChTdHJlYW1JRCwg VHlwZSkgZXZlcnl3aGVyZSBpbnN0ZWFkIG9mIGp1c3QgU3RyZWFtSUQuDQoNCktlZXBpbmcgb25l IHN0cmVhbSBJRCBhdm9pZHMgY3JlYXRpbmcgdHdvIG9mIGFsbCB0aGUgc3RyZWFtIHNwZWNpZmlj IGZyYW1lcyhTVE9QX1NFTkRJTkcsIFJTVF9TVFJFQU0sIFNUUkVBTV9GUkFNRSwgTUFYX0RBVEFf T0ZGU0VULCBldGMpLCBvbmUgZm9yIGVhY2ggc3RyZWFtIHNwYWNlLg0KDQpVc2luZyB0aGUgdHdv IG1vc3Qgc2lnbmlmaWNhbnQgYml0cyB3b3VsZCBlbGltaW5hdGUgdGhlIHVzZWZ1bG5lc3Mgb2Yg YW55IHZhcmlhYmxlIGxlbmd0aCBpbnRlZ2VyIGVuY29kaW5nKGN1cnJlbnQgb3IgTWFydGluJ3Mg bmV3IHByb3Bvc2FsKSwgc28gdXNpbmcgdGhlIGxvd2VyIGJpdHMgbWFrZXMgc2Vuc2UuDQoNCk9u IEZyaSwgT2N0IDEzLCAyMDE3IGF0IDQ6NTYgUE0sIE1pa2UgQmlzaG9wIDxNaWNoYWVsLkJpc2hv cEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj4gd3Jv dGU6DQpJbmRlZWQuICBJIGFsbW9zdCB0aGluayBpdCBtYWtlcyBtb3JlIHNlbnNlIHRvIHNheSB0 aGF0IHRoZXJlIGFyZSBmb3VyIGluZGVwZW5kZW50IHN0cmVhbSBzcGFjZXMsIGVhY2ggd2l0aCB0 aGVpciBvd24gbnVtYmVycy4gIFRoYXQgZG9lcyBtZWFuIHRoYXQgZWFjaCBzaWRlIHdpbGwgbmVl ZCB0byBzZXBhcmF0ZWx5IG1hbmFnZSBNYXggU3RyZWFtIElEIGZvciB0d28gc3BhY2VzLCBidXQg dGhhdCBzZWVtcyBtb3JlIHJlYXNvbmFibGUgdGhhbiB0aGUgYWx0ZXJuYXRpdmUuICBJbiBmYWN0 LCB0aGlzIFBSIGFscmVhZHkgaW1wbGllcyB0aGF0IHRoZSBsaW1pdHMgZm9yIHVuaWRpcmVjdGlv bmFsIGFuZCBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXJlIGhhbmRsZWQgc2VwYXJhdGVseSwgd2hp Y2ggZ2V0cyByZWFsbHkgd2VpcmQgd2hlbiB0aGUgSURzIGFyZSBpbnRlcmxlYXZlZCB3aXRoIGVh Y2ggb3RoZXIuDQoNCkluIGZhY3QsIHRoaXMgcGxheXMgd2VsbCB3aXRoIHRoZSB2YXJpYWJsZS1s ZW5ndGggZW5jb2RpbmcgaWRlYSwgc2luY2UgdGhlIG1heGltdW0gc2l6ZSBvZiBhIFN0cmVhbSBJ RCB3b3VsZCBiZSA2MiBiaXRzLiAgVGhleSBjb3VsZCB0aGVuIGJlIHN0b3JlZCBsb2NhbGx5IGFz IGEgNjQtYml0IHZhbHVlIHdpdGggdGhlIOKAnGV4dHJh4oCdIGJpdHMgaW5kaWNhdGluZyB3aGlj aCBzcGFjZSB0aGV5IHJlZmVyIHRvLg0KDQpGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWlr a2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KU2VudDogRnJpZGF5LCBPY3RvYmVyIDEzLCAyMDE3IDE6 MDQgUE0NClRvOiBxdWljQGlldGYub3JnPG1haWx0bzpxdWljQGlldGYub3JnPjsgSHVndWVzIEZh ZmFyZCA8ZmFmYXJkQGluLnR1bS5kZTxtYWlsdG86ZmFmYXJkQGluLnR1bS5kZT4+DQpTdWJqZWN0 OiBSZTogSWRlbnRpZnkgc3RyZWFtcyB1bmlkaXJlY3Rpb25hbCB2cyBiaWRpcmVjdGlvbmFsIGJh c2VkIG9uIHN0cmVhbSBJRA0KDQpFc3BlY2lhbGx5IHdpdGggdGhlIG5ldyB2YXJpYWJsZSBsZW5n dGggZW5jb2RpbmcgcHJvcG9zYWwsIHN0b3JpbmcgdGhlIGlkZW50aWZpZXJzIGVhcmx5IG1ha2Vz IHNlbnNlLCBhcyB5b3Ugb25seSBoYXZlIHRvIGluc3BlY3QgdGhlIGZpcnN0IGJ5dGUuIEJ1dCBp dCBnZXRzIGNvbXBsaWNhdGVkLCBiZWNhdXNlIHlvdSBkb27igJl0IHdhbnQgdG8gdXNlIDggYnl0 ZXMgZm9yIHNvbWUgc3RyZWFtIHR5cGVzIGFuZCB5b3UgZG9u4oCZdCB3YW50IHRoZSBiaXRzIGF0 IHNvbWUgcmFuZG9tIGxvY2F0aW9uIGluIGEgZGVjb2RlZCA4IGJ5dGUgcmVwcmVzZW50YXRpb24g ZWl0aGVyLg0KDQpSZWdhcmRsZXNzIG9mIGJpdCBwbGFjZW1lbnQsIGVuY29kaW5nIHN0YXRlIHVz aW5nIGJpdHMgaXMgbm90IGlkZWFsIHdoZW4gY29uc2lkZXJpbmcgdmFyaWFibGUgbGVuZ3RoIGVu Y29kaW5nIGJlY2F1c2UgeW91IG5vdyB1c2UgdHdvIGJpdHMgZm9yIGxlbmd0aCBhbmQgdHdvIGJp dHMgZm9yIHN0cmVhbSB0eXBlLCBsZWF2aW5nIG9ubHkgMTYgZGlmZmVyZW50IHN0cmVhbXMgYmVm b3JlIHRoZSBzdHJlYW0gaWRlbnRpZmllciBuZWVkcyB0byB1c2UgdHdvIGJ5dGVzLCBhbmQgc28g Zm9ydGguDQoNCg0KS2luZCBSZWdhcmRzLA0KTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg0KDQoN Ck9uIDEzIE9jdG9iZXIgMjAxNyBhdCAyMS41MC4wNiwgSHVndWVzIEZhZmFyZCAoZmFmYXJkQGlu LnR1bS5kZTxtYWlsdG86ZmFmYXJkQGluLnR1bS5kZT4pIHdyb3RlOg0KSSBzZWUsIHlvdSB1c2Vk IHRoZSAyIGxlYXN0IHNpZ25pZmljYW50IGJpdHMgdG8gZW5jb2RlIHRoYXQNCmluZm9ybWF0aW9u LiBXaGVuIG9ubHkgdXNpbmcgb25lIGJpdCB0byBpbmRpY2F0ZSB0aGUgZGlyZWN0aW9uLCBpdA0K Ym9pbGVkIGRvd24gdG8gb2RkL2V2ZW4gd2hpY2ggbW9yZSBvciBsZXNzIG1hZGUgc2Vuc2UsIGJ1 dCB3aGVuIHVzaW5nDQoyIGJpdHMgdGhhdCBicmVha3MgYXBhcnQuDQoNCldoeSBub3QgdXNlIHRo ZSBtb3N0IHNpZ25pZmljYW50IGJpdHMgaW5zdGVhZD8gVGhhdCB3YXksIGdldHRpbmcgdGhlDQon Y2xlYW4nIHN0cmVhbSBJRCB3aXRob3V0IHRoZSBmbGFncyB3b3VsZCBiZSBhcyBzaW1wbGUgZG9p bmcgYSBgJg0KMHgzRi4uLkZGYCBpbnN0ZWFkIG9mIGJpdC1zaGlmdGluZyB0aGluZ3MgYXJvdW5k LiBTaW1pbGFybHksIGVuY29kaW5nDQp0aGUgc3RyZWFtIElEIHdvdWxkIGp1c3QgZW50YWlsIGB8 IDB4PzAuLi4wMGAgdG8gc2V0IHRoZSBhcHByb3ByaWF0ZQ0KYml0cyBhbmQgYWxzbyBhdm9pZCBi aXQtc2hpZnRzLg0KDQpSZWdhcmRzLA0KSHVndWVzDQoNCk9uIDIwMTctMTAtMTMgMjA6NTEsIFJ5 YW4gSGFtaWx0b24gd3JvdGU6DQo+IEFzIEkgdW5kZXJzdGFuZCB0aGUgZGlzY3Vzc2lvbnMgYXQg dGhlIGludGVyaW0sIHdlJ3ZlIGRlY2lkZWQgdG8NCj4gYWxsb3cgc3RyZWFtcyB0byBiZSB1bmlk aXJlY3Rpb25hbCBvciBiaWRpcmVjdGlvbmFsLiBJIHN1cHBvcnQgdGhpcw0KPiBpZGVhIGFuZCB3 YXMgbW90aXZhdGVkIHRvIHdyaXRlIHVwIGFuIGlkZWEgSSd2ZSBiZWVuIHRoaW5raW5nIGFib3V0 DQo+IGZvciBhIHdoaWxlLiBJbiB0aGUgc2FtZSB3YXkgdGhhdCB3ZSB1c2UgYSBiaXQgaW4gdGhl IHN0cmVhbSBJRCB0bw0KPiBpZGVudGlmeSB0aGUgY2xpZW50IHZzIHNlcnZlciBuYXR1cmUgb2Yg dGhlIHN0cmVhbSwgd2UgY2FuIHVzZSBhDQo+IGJpdCB0byBpZGVudGlmeSB0aGUgZGlyZWN0aW9u YWxpdHkuIFRoaXMgZGl2aWRlcyB0aGUgc3RyZWFtIElEDQo+IHNwYWNlIG5lYXRseSBpbnRvIDQg ZGlzdGluY3Qgc3BhY2VzIChtdWNoIGxpa2UgdGhlIDIgdHdvIHdlIGhhdmUNCj4gdG9kYXk6IGNs aWVudC9zZXJ2ZXIpLiBJbiBhZGRpdGlvbiB0aGlzIG1lYW5zIHRoYXQgYSBzdHJlYW0gSUQNCj4g YWx3YXlzIHVuaXF1ZWx5IGlkZW50aWZpZXMgYSBzaW5nbGUgc3RyZWFtLCBhbmQgZnJhbWVzIHdo aWNoDQo+IG1lbnRpb24gc3RyZWFtIElEIChTVFJFQU0sIE1BWF9TVFJFQU1fSUQsIE1BWF9TVFJF QU1fREFUQSwNCj4gUlNUX1NUUkVBTSwgZXRjKSBkbyBub3QgbmVlZCB0byBleHBsaWNpdGx5IGNv bnZleSB0aGUNCj4gZGlyZWN0aW9uYWxpdHkgYXMgZmllbGRzIGluIHRob3NlIGZyYW1lcyAob3Ig aW1wbGljaXRseSBiYXNlZCBvbg0KPiB0aGUgZGlyZWN0aW9uYWxpdHkgb2YgdGhlIGZyYW1lcyB0 aGVtc2VsdmVzKS4NCj4NCj4gaHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9w dWxsLzg3MjxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb21fLTNGdXJsLTNEaHR0cHMt MjUzQS0yNTJGLTI1MkZnaXRodWIuY29tLTI1MkZxdWljd2ctMjUyRmJhc2UtMkRkcmFmdHMtMjUy RnB1bGwtMjUyRjg3Mi0yNmRhdGEtM0QwMi0yNTdDMDEtMjU3Q21pY2hhZWwuYmlzaG9wLTI1NDBt aWNyb3NvZnQuY29tLTI1N0MzYmFmMDQzMjVlMGY0Yzk0NGMxMzA4ZDUxMjc1OGQzMy0yNTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDctMjU3QzEtMjU3QzAtMjU3QzYzNjQzNTIxODQ2 MzA2NjgwNS0yNnNkYXRhLTNEV0xKWFJFOUp6M3J0THNWcXhCT3lhTWNPSS0yNTJCcTZuWjhUSm1s QXJzYmhVMk0tMjUzRC0yNnJlc2VydmVkLTNEMCZkPUR3TUZhUSZjPTVWRDBSVHRObFRoM3ljZDQx YjNNVXcmcj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJm09c1BPQ0pQdTVIQ25hcXpmMEZZNkVNc2Ja U2ZjRTNYS3pIX2p4dnJlamh3RSZzPXBteEk3Ql9kRXJLYnZqVmloMWk5NnVMclBYcVVTN0R2ZTRF bjVHOVRUVTQmZT0+DQo+DQo+IENoZWVycywNCj4NCj4gUnlhbg0KDQo= --_000_DC15026F237641B3B05EC5606C8E0C73fbcom_ 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 ZTt9DQpwLm0tMjI0MDEzOTE1ODIwMzkxMzQwOGFpcm1haWxvbiwgbGkubS0yMjQwMTM5MTU4MjAz OTEzNDA4YWlybWFpbG9uLCBkaXYubS0yMjQwMTM5MTU4MjAzOTEzNDA4YWlybWFpbG9uDQoJe21z by1zdHlsZS1uYW1lOm1fLTIyNDAxMzkxNTgyMDM5MTM0MDhhaXJtYWlsb247DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5 bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J biBIMiwgdGhlIGV2ZW4vb2RkIHRoaW5nIHdhcyBqdXN0IGFuIGVhc3kgd2F5IHRvIGVuY29kZSBh IHVuaXF1ZSBJRCBwZXIgc3RyZWFtIHdoaWxlIGluZGljYXRpbmcgZGlyZWN0aW9uLjxicj4NClRo aXMgcHJvcG9zYWwgc2VlbXMgdG8gZG8gdGhlIHNhbWUgdGhpbmcsIGFuZCB0aGF0IG1ha2VzIHNl bnNlIHRvIG1l4oCUaW5zdGVhZCBvZiBldmVuLW9kZCwgd2UgaGF2ZSBtb2QtNC1vZmZzZXQuPGJy Pg0KPGJyPg0KSeKAmWQgYXNrIHdoeSBib3RoZXIgdG8gaGF2ZSBzZXBhcmF0ZSBzdHJlYW0gbGlt aXRzLiBZb3UgY291bGQgc3RpbGwganVzdCBoYXZlIHRoZSBvbmUgbGltaXQgZm9yIHRoZSBvdmVy YWxsIHNwYWNlLjxicj4NCldpdGggSDIsIHRoYXQgd2FzIHBhcnQgb2YgdGhlIHBvaW50IG9mIHB1 dHRpbmcgaXQgdGhlcmUgKHRob3VnaCBpdCB3YXMgaW1wbGl0KeKAlGl0IHdhcyBhbGwgcGFydCBv ZiBvbmUgc3BhY2UsIGFuZCB0aHVzIHRoZSBzcGFjZSB3YXMgc2luZ2x5IGNvdW50YWJsZSE8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LT1SPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5RVUlDICZsdDtxdWljLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBv ZiBJYW4gU3dldHQgJmx0O2lhbnN3ZXR0QGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+RGF0ZTogPC9i PkZyaWRheSwgT2N0b2JlciAxMywgMjAxNyBhdCAyOjA1IFBNPGJyPg0KPGI+VG86IDwvYj5NaWtl IEJpc2hvcCAmbHQ7TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs8YnI+DQo8Yj5DYzog PC9iPk1pa2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0O21pa2tlbGZqQGdtYWlsLmNvbSZndDss ICZxdW90O3F1aWNAaWV0Zi5vcmcmcXVvdDsgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7LCBIdWd1ZXMg RmFmYXJkICZsdDtmYWZhcmRAaW4udHVtLmRlJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTog SWRlbnRpZnkgc3RyZWFtcyB1bmlkaXJlY3Rpb25hbCB2cyBiaWRpcmVjdGlvbmFsIGJhc2VkIG9u IHN0cmVhbSBJRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SW4gbWFueSB3YXlzLCB0aGV5IGFyZSA0IGluZGVwZW5kZW50IHNwYWNl cywgYnV0IFJ5YW4gcG9pbnRlZCBvdXQgdG8gbWUgdGhhdCBib3RoIGZvciB0aGUgcHVycG9zZXMg b2YgZHJhZnQgdGV4dCBhbmQgaW1wbGVtZW50YXRpb24gaXQncyB2ZXJ5IHVzZWZ1bCB0byBoYXZl IGEgc2luZ2xlIHVuaXF1ZSBpZGVudGlmaWVyIGZvciBhIHN0cmVhbSwgc2luY2Ugb3RoZXJ3aXNl IHlvdSBoYXZlIHRvIHRhbGsgYWJvdXQvcGFzcw0KIGFyb3VuZCAoU3RyZWFtSUQsIFR5cGUpIGV2 ZXJ5d2hlcmUgaW5zdGVhZCBvZiBqdXN0IFN0cmVhbUlELiA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPktlZXBpbmcgb25lIHN0cmVhbSBJRCBhdm9pZHMgY3Jl YXRpbmcgdHdvIG9mIGFsbCB0aGUgc3RyZWFtIHNwZWNpZmljIGZyYW1lcyhTVE9QX1NFTkRJTkcs IFJTVF9TVFJFQU0sIFNUUkVBTV9GUkFNRSwgTUFYX0RBVEFfT0ZGU0VULCBldGMpLCBvbmUgZm9y IGVhY2ggc3RyZWFtIHNwYWNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5Vc2luZyB0aGUgdHdvIG1vc3Qgc2lnbmlmaWNhbnQgYml0cyB3b3Vs ZCBlbGltaW5hdGUgdGhlIHVzZWZ1bG5lc3Mgb2YgYW55IHZhcmlhYmxlIGxlbmd0aCBpbnRlZ2Vy IGVuY29kaW5nKGN1cnJlbnQgb3IgTWFydGluJ3MgbmV3IHByb3Bvc2FsKSwgc28gdXNpbmcgdGhl IGxvd2VyIGJpdHMgbWFrZXMgc2Vuc2UuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZyaSwgT2N0IDEzLCAyMDE3IGF0IDQ6NTYgUE0sIE1p a2UgQmlzaG9wICZsdDs8YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNv bSIgdGFyZ2V0PSJfYmxhbmsiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L2E+Jmd0OyB3 cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFy Z2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+SW5kZWVkLiZuYnNwOyBJIGFsbW9zdCB0aGluayBpdCBtYWtlcyBtb3Jl IHNlbnNlIHRvIHNheSB0aGF0IHRoZXJlIGFyZSBmb3VyIGluZGVwZW5kZW50IHN0cmVhbSBzcGFj ZXMsIGVhY2ggd2l0aCB0aGVpciBvd24gbnVtYmVycy4mbmJzcDsgVGhhdCBkb2VzIG1lYW4gdGhh dCBlYWNoIHNpZGUgd2lsbCBuZWVkIHRvIHNlcGFyYXRlbHkNCiBtYW5hZ2UgTWF4IFN0cmVhbSBJ RCBmb3IgdHdvIHNwYWNlcywgYnV0IHRoYXQgc2VlbXMgbW9yZSByZWFzb25hYmxlIHRoYW4gdGhl IGFsdGVybmF0aXZlLiZuYnNwOyBJbiBmYWN0LCB0aGlzIFBSIGFscmVhZHkgaW1wbGllcyB0aGF0 IHRoZSBsaW1pdHMgZm9yIHVuaWRpcmVjdGlvbmFsIGFuZCBiaWRpcmVjdGlvbmFsIHN0cmVhbXMg YXJlIGhhbmRsZWQgc2VwYXJhdGVseSwgd2hpY2ggZ2V0cyByZWFsbHkgd2VpcmQgd2hlbiB0aGUg SURzIGFyZSBpbnRlcmxlYXZlZA0KIHdpdGggZWFjaCBvdGhlci48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPkluIGZhY3QsIHRoaXMgcGxheXMgd2VsbCB3aXRoIHRoZSB2YXJpYWJsZS1sZW5n dGggZW5jb2RpbmcgaWRlYSwgc2luY2UgdGhlIG1heGltdW0gc2l6ZSBvZiBhIFN0cmVhbSBJRCB3 b3VsZCBiZSA2MiBiaXRzLiZuYnNwOyBUaGV5IGNvdWxkIHRoZW4gYmUgc3RvcmVkIGxvY2FsbHkg YXMgYSA2NC1iaXQgdmFsdWUgd2l0aA0KIHRoZSDigJxleHRyYeKAnSBiaXRzIGluZGljYXRpbmcg d2hpY2ggc3BhY2UgdGhleSByZWZlciB0by48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRv OjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5x dWljLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5NaWtrZWwgRmFo bsO4ZSBKw7hyZ2Vuc2VuPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgT2N0b2JlciAxMywgMjAx NyAxOjA0IFBNPGJyPg0KPGI+VG86PC9iPiA8YSBocmVmPSJtYWlsdG86cXVpY0BpZXRmLm9yZyIg dGFyZ2V0PSJfYmxhbmsiPnF1aWNAaWV0Zi5vcmc8L2E+OyBIdWd1ZXMgRmFmYXJkICZsdDs8YSBo cmVmPSJtYWlsdG86ZmFmYXJkQGluLnR1bS5kZSIgdGFyZ2V0PSJfYmxhbmsiPmZhZmFyZEBpbi50 dW0uZGU8L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSWRlbnRpZnkgc3RyZWFtcyB1 bmlkaXJlY3Rpb25hbCB2cyBiaWRpcmVjdGlvbmFsIGJhc2VkIG9uIHN0cmVhbSBJRDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9Im1fLTIyNDAxMzkxNTgyMDM5MTM0 MDhibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkVzcGVjaWFsbHkgd2l0aCB0aGUgbmV3IHZhcmlhYmxlIGxlbmd0aCBlbmNvZGluZyBw cm9wb3NhbCwgc3RvcmluZyB0aGUgaWRlbnRpZmllcnMgZWFybHkgbWFrZXMgc2Vuc2UsIGFzIHlv dSBvbmx5DQogaGF2ZSB0byBpbnNwZWN0IHRoZSBmaXJzdCBieXRlLiBCdXQgaXQgZ2V0cyBjb21w bGljYXRlZCwgYmVjYXVzZSB5b3UgZG9u4oCZdCB3YW50IHRvIHVzZSA4IGJ5dGVzIGZvciBzb21l IHN0cmVhbSB0eXBlcyBhbmQgeW91IGRvbuKAmXQgd2FudCB0aGUgYml0cyBhdCBzb21lIHJhbmRv bSBsb2NhdGlvbiBpbiBhIGRlY29kZWQgOCBieXRlIHJlcHJlc2VudGF0aW9uIGVpdGhlci48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9Im1fLTIyNDAxMzkxNTgyMDM5MTM0 MDhibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0ibV8t MjI0MDEzOTE1ODIwMzkxMzQwOGJsb29wX2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+UmVnYXJkbGVzcyBvZiBiaXQgcGxhY2VtZW50LCBlbmNv ZGluZyBzdGF0ZSB1c2luZyBiaXRzIGlzIG5vdCBpZGVhbCB3aGVuIGNvbnNpZGVyaW5nIHZhcmlh YmxlIGxlbmd0aCBlbmNvZGluZyBiZWNhdXNlDQogeW91IG5vdyB1c2UgdHdvIGJpdHMgZm9yIGxl bmd0aCBhbmQgdHdvIGJpdHMgZm9yIHN0cmVhbSB0eXBlLCBsZWF2aW5nIG9ubHkgMTYgZGlmZmVy ZW50IHN0cmVhbXMgYmVmb3JlIHRoZSBzdHJlYW0gaWRlbnRpZmllciBuZWVkcyB0byB1c2UgdHdv IGJ5dGVzLCBhbmQgc28gZm9ydGguPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 IGlkPSJtXy0yMjQwMTM5MTU4MjAzOTEzNDA4Ymxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZu YnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxkaXYgaWQ9Im1fLTIyNDAxMzkxNTgyMDM5MTM0 MDhibG9vcF9zaWduXzE1MDc5MjQ3OTM1MDg3MTk4NzIiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktpbmQgUmVnYXJkcyw8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJtLTIyNDAxMzkxNTgyMDM5MTM0MDhh aXJtYWlsb24iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5PbiAxMyBPY3RvYmVyIDIwMTcgYXQgMjEuNTAu MDYsIEh1Z3VlcyBGYWZhcmQgKDxhIGhyZWY9Im1haWx0bzpmYWZhcmRAaW4udHVtLmRlIiB0YXJn ZXQ9Il9ibGFuayI+ZmFmYXJkQGluLnR1bS5kZTwvYT4pIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm Ij5JIHNlZSwgeW91IHVzZWQgdGhlIDIgbGVhc3Qgc2lnbmlmaWNhbnQgYml0cyB0byBlbmNvZGUg dGhhdA0KPGJyPg0KaW5mb3JtYXRpb24uIFdoZW4gb25seSB1c2luZyBvbmUgYml0IHRvIGluZGlj YXRlIHRoZSBkaXJlY3Rpb24sIGl0IDxicj4NCmJvaWxlZCBkb3duIHRvIG9kZC9ldmVuIHdoaWNo IG1vcmUgb3IgbGVzcyBtYWRlIHNlbnNlLCBidXQgd2hlbiB1c2luZyA8YnI+DQoyIGJpdHMgdGhh dCBicmVha3MgYXBhcnQuIDxicj4NCjxicj4NCldoeSBub3QgdXNlIHRoZSBtb3N0IHNpZ25pZmlj YW50IGJpdHMgaW5zdGVhZD8gVGhhdCB3YXksIGdldHRpbmcgdGhlIDxicj4NCidjbGVhbicgc3Ry ZWFtIElEIHdpdGhvdXQgdGhlIGZsYWdzIHdvdWxkIGJlIGFzIHNpbXBsZSBkb2luZyBhIGAmYW1w OyA8YnI+DQoweDNGLi4uRkZgIGluc3RlYWQgb2YgYml0LXNoaWZ0aW5nIHRoaW5ncyBhcm91bmQu IFNpbWlsYXJseSwgZW5jb2RpbmcgPGJyPg0KdGhlIHN0cmVhbSBJRCB3b3VsZCBqdXN0IGVudGFp bCBgfCAweD8wLi4uMDBgIHRvIHNldCB0aGUgYXBwcm9wcmlhdGUgPGJyPg0KYml0cyBhbmQgYWxz byBhdm9pZCBiaXQtc2hpZnRzLiA8YnI+DQo8YnI+DQpSZWdhcmRzLCA8YnI+DQpIdWd1ZXMgPGJy Pg0KPGJyPg0KT24gMjAxNy0xMC0xMyAyMDo1MSwgUnlhbiBIYW1pbHRvbiB3cm90ZTogPGJyPg0K Jmd0OyBBcyBJIHVuZGVyc3RhbmQgdGhlIGRpc2N1c3Npb25zIGF0IHRoZSBpbnRlcmltLCB3ZSd2 ZSBkZWNpZGVkIHRvIDxicj4NCiZndDsgYWxsb3cgc3RyZWFtcyB0byBiZSB1bmlkaXJlY3Rpb25h bCBvciBiaWRpcmVjdGlvbmFsLiBJIHN1cHBvcnQgdGhpcyA8YnI+DQomZ3Q7IGlkZWEgYW5kIHdh cyBtb3RpdmF0ZWQgdG8gd3JpdGUgdXAgYW4gaWRlYSBJJ3ZlIGJlZW4gdGhpbmtpbmcgYWJvdXQg PGJyPg0KJmd0OyBmb3IgYSB3aGlsZS4gSW4gdGhlIHNhbWUgd2F5IHRoYXQgd2UgdXNlIGEgYml0 IGluIHRoZSBzdHJlYW0gSUQgdG8gPGJyPg0KJmd0OyBpZGVudGlmeSB0aGUgY2xpZW50IHZzIHNl cnZlciBuYXR1cmUgb2YgdGhlIHN0cmVhbSwgd2UgY2FuIHVzZSBhIDxicj4NCiZndDsgYml0IHRv IGlkZW50aWZ5IHRoZSBkaXJlY3Rpb25hbGl0eS4gVGhpcyBkaXZpZGVzIHRoZSBzdHJlYW0gSUQg PGJyPg0KJmd0OyBzcGFjZSBuZWF0bHkgaW50byA0IGRpc3RpbmN0IHNwYWNlcyAobXVjaCBsaWtl IHRoZSAyIHR3byB3ZSBoYXZlIDxicj4NCiZndDsgdG9kYXk6IGNsaWVudC9zZXJ2ZXIpLiBJbiBh ZGRpdGlvbiB0aGlzIG1lYW5zIHRoYXQgYSBzdHJlYW0gSUQgPGJyPg0KJmd0OyBhbHdheXMgdW5p cXVlbHkgaWRlbnRpZmllcyBhIHNpbmdsZSBzdHJlYW0sIGFuZCBmcmFtZXMgd2hpY2ggPGJyPg0K Jmd0OyBtZW50aW9uIHN0cmVhbSBJRCAoU1RSRUFNLCBNQVhfU1RSRUFNX0lELCBNQVhfU1RSRUFN X0RBVEEsIDxicj4NCiZndDsgUlNUX1NUUkVBTSwgZXRjKSBkbyBub3QgbmVlZCB0byBleHBsaWNp dGx5IGNvbnZleSB0aGUgPGJyPg0KJmd0OyBkaXJlY3Rpb25hbGl0eSBhcyBmaWVsZHMgaW4gdGhv c2UgZnJhbWVzIChvciBpbXBsaWNpdGx5IGJhc2VkIG9uIDxicj4NCiZndDsgdGhlIGRpcmVjdGlv bmFsaXR5IG9mIHRoZSBmcmFtZXMgdGhlbXNlbHZlcykuIDxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb21fLTNGdXJsLTNEaHR0cHMt MjUzQS0yNTJGLTI1MkZnaXRodWIuY29tLTI1MkZxdWljd2ctMjUyRmJhc2UtMkRkcmFmdHMtMjUy RnB1bGwtMjUyRjg3Mi0yNmRhdGEtM0QwMi0yNTdDMDEtMjU3Q21pY2hhZWwuYmlzaG9wLTI1NDBt aWNyb3NvZnQuY29tLTI1N0MzYmFmMDQzMjVlMGY0Yzk0NGMxMzA4ZDUxMjc1OGQzMy0yNTdDNzJm OTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDctMjU3QzEtMjU3QzAtMjU3QzYzNjQzNTIxODQ2 MzA2NjgwNS0yNnNkYXRhLTNEV0xKWFJFOUp6M3J0THNWcXhCT3lhTWNPSS0yNTJCcTZuWjhUSm1s QXJzYmhVMk0tMjUzRC0yNnJlc2VydmVkLTNEMCZhbXA7ZD1Ed01GYVEmYW1wO2M9NVZEMFJUdE5s VGgzeWNkNDFiM01VdyZhbXA7cj1DMHNVby1MRk5CYVlmeW9hQ3NmNlRBJmFtcDttPXNQT0NKUHU1 SENuYXF6ZjBGWTZFTXNiWlNmY0UzWEt6SF9qeHZyZWpod0UmYW1wO3M9cG14STdCX2RFcktidmpW aWgxaTk2dUxyUFhxVVM3RHZlNEVuNUc5VFRVNCZhbXA7ZT0iIHRhcmdldD0iX2JsYW5rIj4NCmh0 dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC84NzI8L2E+IDxicj4NCiZn dDsgPGJyPg0KJmd0OyBDaGVlcnMsIDxicj4NCiZndDsgPGJyPg0KJmd0OyBSeWFuIDwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_DC15026F237641B3B05EC5606C8E0C73fbcom_-- From nobody Mon Oct 16 08:16: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 2402613303A for ; Mon, 16 Oct 2017 08:16:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, 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 ThJmFAgTr9h2 for ; Mon, 16 Oct 2017 08:16:07 -0700 (PDT) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::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 DAC2F1329B5 for ; Mon, 16 Oct 2017 08:16:06 -0700 (PDT) Received: by mail-it0-x236.google.com with SMTP id o135so1566291itb.0 for ; Mon, 16 Oct 2017 08:16:06 -0700 (PDT) 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=77KYXK6AnmsGuAMFVfMD9CNpAIZR8YQ4waXnebSEjIE=; b=YGXymNMKsOR3YKiiDLoRy7MuGCDgTGVT9B0d2d5G3mtXymkPW+zil3hbDmdC1Gkgic liIEfyuGWqSVZbSUzD6/NoauuzZQJiMtCPJQFC6/5jVVOul902FKgL5HdkWl2mwdSwXs vR8qwBu+7Fu75ltY5zsKuhuwG7rUtqPWX8VUfL2lyHXMf39PWOouhpmVf/sXJMoO2YAC mvYB/VBHaUfR0v/gMGp6bDX5qti1h5+EYsycNhNlFoEyd7bCUA9a9uAPbk+5diZDaG4J C9trLIAIdoamMlMDHsmgZQ7y9CMYU3KGVxuzuSdrTDAl6pLiHDy+hFS77MwfqRwsiull FwMQ== 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=77KYXK6AnmsGuAMFVfMD9CNpAIZR8YQ4waXnebSEjIE=; b=EdrjUV6VXFxzxpcXXIwX3A8cELy9ksH4LruXGVa/TJvw440igIjbzn7jcuWPC8wMwc /bIu6JjF2zUtE55KFdeWkiESwtRWVQA92sXioM1fHd8LUIyuaBjWZAr2Qgv2mAz0pLdZ 5EN+O3TTc6jTX8jcdJ2Oks1smxTEY3x97Q2mSzTlKeeW1Z2HH9W7giQ9SnfsC/cq6B0O lKwZpFavFMsql8ObHXDGMK725nW8uCiy/ECbAyt55+4USxNJqs/NSrNR4gV0Lb8af7Ze TS5mvNJOARg+oFfXqz/Ekfo7llFKfP+/EedDvmow8OgbWRyORdbctuwhJtuKuintGG9+ C1Rw== X-Gm-Message-State: AMCzsaX6MT/Ypd0Pr2g4xz1va9eCbqUV1wLn8wKvr707kDN3SUZmJZR8 r+NKTRA8x2hTTks8vjnohglXzumbCWPOV4JBYBZX4Q== X-Google-Smtp-Source: ABhQp+QKl2YQ9qaIKec01FzxzosdiHOYJZ9zuzFvz/XtO32KgKxMLzGfp7Blld44HPjQbg/o3J8WaGx1MdfqC9B0umo= X-Received: by 10.36.154.66 with SMTP id l63mr1651845ite.118.1508166965728; Mon, 16 Oct 2017 08:16:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.4 with HTTP; Mon, 16 Oct 2017 08:15:45 -0700 (PDT) In-Reply-To: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> From: Ian Swett Date: Mon, 16 Oct 2017 11:15:45 -0400 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: Roberto Peon Cc: Mike Bishop , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Hugues Fafard Content-Type: multipart/alternative; boundary="94eb2c1142d641a970055bab7c38" 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, 16 Oct 2017 15:16:09 -0000 --94eb2c1142d641a970055bab7c38 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I believe the motivation for separate stream limits is to put a reasonable limit on the number of incoming streams you'll accept. Otherwise, an application could use a very large number of one type(ie: uni) of stream and almost none of another(ie: bidi), which would allow them to suddenly open a huge number of the other type(ie: bidi) of stream if they wanted. If we were using H2 style max open streams we could do it either way, but I think keeping them separate is probably best anyway. On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon wrote: > In H2, the even/odd thing was just an easy way to encode a unique ID per > stream while indicating direction. > This proposal seems to do the same thing, and that makes sense to > me=E2=80=94instead of even-odd, we have mod-4-offset. > > I=E2=80=99d ask why bother to have separate stream limits. You could stil= l just > have the one limit for the overall space. > With H2, that was part of the point of putting it there (though it was > implit)=E2=80=94it was all part of one space, and thus the space was sing= ly > countable! > > > > -=3DR > > > > *From: *QUIC on behalf of Ian Swett < > ianswett@google.com> > *Date: *Friday, October 13, 2017 at 2:05 PM > *To: *Mike Bishop > *Cc: *Mikkel Fahn=C3=B8e J=C3=B8rgensen , "quic@ietf.= org" < > quic@ietf.org>, Hugues Fafard > > *Subject: *Re: Identify streams unidirectional vs bidirectional based on > stream ID > > > > In many ways, they are 4 independent spaces, but Ryan pointed out to me > that both for the purposes of draft text and implementation it's very > useful to have a single unique identifier for a stream, since otherwise y= ou > have to talk about/pass around (StreamID, Type) everywhere instead of jus= t > StreamID. > > > > Keeping one stream ID avoids creating two of all the stream specific > frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET, etc), one > for each stream space. > > > > Using the two most significant bits would eliminate the usefulness of any > variable length integer encoding(current or Martin's new proposal), so > using the lower bits makes sense. > > > > On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop > wrote: > > Indeed. I almost think it makes more sense to say that there are four > independent stream spaces, each with their own numbers. That does mean > that each side will need to separately manage Max Stream ID for two space= s, > but that seems more reasonable than the alternative. In fact, this PR > already implies that the limits for unidirectional and bidirectional > streams are handled separately, which gets really weird when the IDs are > interleaved with each other. > > > > In fact, this plays well with the variable-length encoding idea, since th= e > maximum size of a Stream ID would be 62 bits. They could then be stored > locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits indicatin= g which space they > refer to. > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=C3= =B8e > J=C3=B8rgensen > *Sent:* Friday, October 13, 2017 1:04 PM > *To:* quic@ietf.org; Hugues Fafard > *Subject:* Re: Identify streams unidirectional vs bidirectional based on > stream ID > > > > Especially with the new variable length encoding proposal, storing the > identifiers early makes sense, as you only have to inspect the first byte= . > But it gets complicated, because you don=E2=80=99t want to use 8 bytes fo= r some > stream types and you don=E2=80=99t want the bits at some random location = in a > decoded 8 byte representation either. > > > > Regardless of bit placement, encoding state using bits is not ideal when > considering variable length encoding because you now use two bits for > length and two bits for stream type, leaving only 16 different streams > before the stream identifier needs to use two bytes, and so forth. > > > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote: > > I see, you used the 2 least significant bits to encode that > information. When only using one bit to indicate the direction, it > boiled down to odd/even which more or less made sense, but when using > 2 bits that breaks apart. > > Why not use the most significant bits instead? That way, getting the > 'clean' stream ID without the flags would be as simple doing a `& > 0x3F...FF` instead of bit-shifting things around. Similarly, encoding > the stream ID would just entail `| 0x?0...00` to set the appropriate > bits and also avoid bit-shifts. > > Regards, > Hugues > > On 2017-10-13 20:51, Ryan Hamilton wrote: > > As I understand the discussions at the interim, we've decided to > > allow streams to be unidirectional or bidirectional. I support this > > idea and was motivated to write up an idea I've been thinking about > > for a while. In the same way that we use a bit in the stream ID to > > identify the client vs server nature of the stream, we can use a > > bit to identify the directionality. This divides the stream ID > > space neatly into 4 distinct spaces (much like the 2 two we have > > today: client/server). In addition this means that a stream ID > > always uniquely identifies a single stream, and frames which > > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, > > RST_STREAM, etc) do not need to explicitly convey the > > directionality as fields in those frames (or implicitly based on > > the directionality of the frames themselves). > > > > https://github.com/quicwg/base-drafts/pull/872 > > > > > Cheers, > > > > Ryan > > > --94eb2c1142d641a970055bab7c38 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I believe the motivation for separate stream limits is to = put a reasonable limit on the number of incoming streams you'll accept.= =C2=A0 Otherwise, an application could use a very large number of one type(= ie: uni) of stream and almost none of another(ie: bidi), which would allow = them to suddenly open a huge number of the other type(ie: bidi) of stream i= f they wanted.=C2=A0=C2=A0

If we were using H2 style max= open streams we could do it either way, but I think keeping them separate = is probably best anyway.

On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon <fenix@fb.com= > wrote:

In H2, the even/odd thing was just an easy way to en= code a unique ID per stream while indicating direction.
This proposal seems to do the same thing, and that makes sense to me=E2=80= =94instead of even-odd, we have mod-4-offset.

I=E2=80=99d ask why bother to have separate stream limits. You could still = just have the one limit for the overall space.
With H2, that was part of the point of putting it there (though it was impl= it)=E2=80=94it was all part of one space, and thus the space was singly cou= ntable!

=C2=A0

-=3DR

=C2=A0

From= : QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <ianswett@google.com>
Date: Friday, October 13, 2017 at 2:05 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>, "quic@ietf.org" <quic@ietf.org>, Hugues F= afard <fafard@in.t= um.de>


Subject: Re: Identify streams unidirectional vs bidirectional based = on stream ID

=C2=A0

In many ways, they are 4 independent spaces, but Rya= n pointed out to me that both for the purposes of draft text and implementa= tion it's very useful to have a single unique identifier for a stream, = since otherwise you have to talk about/pass around (StreamID, Type) everywhere instead of just StreamID.

=C2=A0

Keeping one stream ID avoids creating two of all the= stream specific frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OF= FSET, etc), one for each stream space.

=C2=A0

Using the two most significant bits would eliminate = the usefulness of any variable length integer encoding(current or Martin= 9;s new proposal), so using the lower bits makes sense.

=C2=A0

On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop <Michael.Bish= op@microsoft.com> wrote:

Indeed.=C2=A0 I almost think it makes more sense to = say that there are four independent stream spaces, each with their own numb= ers.=C2=A0 That does mean that each side will need to separately manage Max Stream ID for two spaces, but that seems more reasonable than t= he alternative.=C2=A0 In fact, this PR already implies that the limits for = unidirectional and bidirectional streams are handled separately, which gets= really weird when the IDs are interleaved with each other.

=C2=A0

In fact, this plays well with the variable-length en= coding idea, since the maximum size of a Stream ID would be 62 bits.=C2=A0 = They could then be stored locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits indicating which space they refer to.<= /u>

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Friday, October 13, 2017 1:04 PM
To: quic@ietf.org= ; Hugues Fafard <fafard@in.tum.de>
Subject: Re: Identify streams unidirectional vs bidirectional based = on stream ID

=C2=A0

Especially with the new variable length encoding = proposal, storing the identifiers early makes sense, as you only have to inspect the first byte. But it gets complicated, because you don= =E2=80=99t want to use 8 bytes for some stream types and you don=E2=80=99t = want the bits at some random location in a decoded 8 byte representation ei= ther.

=C2=A0

Regardless of bit placement, encoding state using= bits is not ideal when considering variable length encoding because you now use two bits for length and two bits for stream type, leaving only= 16 different streams before the stream identifier needs to use two bytes, = and so forth.

=C2=A0

=C2=A0

Kind Regards,

Mikkel Fahn=C3=B8e= J=C3=B8rgensen

=C2=A0

On 13 = October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote:

I see, you used th= e 2 least significant bits to encode that
information. When only using one bit to indicate the direction, it
boiled down to odd/even which more or less made sense, but when using
2 bits that breaks apart.

Why not use the most significant bits instead? That way, getting the
'clean' stream ID without the flags would be as simple doing a `&am= p;
0x3F...FF` instead of bit-shifting things around. Similarly, encoding
the stream ID would just entail `| 0x?0...00` to set the appropriate
bits and also avoid bit-shifts.

Regards,
Hugues

On 2017-10-13 20:51, Ryan Hamilton wrote:
> As I understand the discussions at the interim, we've decided to <= br> > allow streams to be unidirectional or bidirectional. I support this > idea and was motivated to write up an idea I've been thinking abou= t
> for a while. In the same way that we use a bit in the stream ID to > identify the client vs server nature of the stream, we can use a
> bit to identify the directionality. This divides the stream ID
> space neatly into 4 distinct spaces (much like the 2 two we have
> today: client/server). In addition this means that a stream ID
> always uniquely identifies a single stream, and frames which
> mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA,
> RST_STREAM, etc) do not need to explicitly convey the
> directionality as fields in those frames (or implicitly based on
> the directionality of the frames themselves).
>
> https://github.com/quicwg/base-drafts/pull/872
>
> Cheers,
>
> Ryan

=C2=A0


--94eb2c1142d641a970055bab7c38-- From nobody Mon Oct 16 16: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 8078A133039 for ; Mon, 16 Oct 2017 16:48:05 -0700 (PDT) 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 RlwouPCTUH9E for ; Mon, 16 Oct 2017 16:48:02 -0700 (PDT) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AEF2126BF0 for ; Mon, 16 Oct 2017 16:48:02 -0700 (PDT) Received: by mail-qt0-x234.google.com with SMTP id 31so9866944qtz.9 for ; Mon, 16 Oct 2017 16:48:02 -0700 (PDT) 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=3QY2UZiEVG7bvbchsuYjdAUbWBL3Cv9Z5jUCX6V7BDI=; b=p6Q9M1HwjHv1cNn1rftDNcidZFHP0rTrnoLyS8n1Hq5gZM68CbAOF03v9oV6UiVmfH awk4ayrFymesn9D72ubHohxDd1xaQFW4kqgZNAkMUtHX/o67oClxNjTG2lIu1nXO/lQP 0yUzEbk4JxsjwkN5FaagleqNJ5Gp0g50g9sjPj50IYF38apVfBWDalTWvd3YHoAurO73 PTSGGrrdoJ0NMJx4lV4oXMHZve3+nOTGh9iOuQKSKGlFZe9AULmjzzEbIw6cW/GNdKjH foKOaFFJ2rPQ0Kp7bn/iQFjYR6YmZRrfFnYzkC1NERm967S4ZpxrCZfd7CTcXrTyCEuq +CcQ== 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=3QY2UZiEVG7bvbchsuYjdAUbWBL3Cv9Z5jUCX6V7BDI=; b=rnKO/YzetwTBlODRU1roCxj1LKJM0LFwPAwmbSPip5XlZ++IxguFLy0qI5/JrIBFKI LDMcHJ9n4uY0MDvL4Us/GEIVeV+B7i/FibBzdcBFqUC//bc0aST49/n9BEctNoULApef MfMwuu3XDP4DX7lLtmIw1592/b3B5VO7rh73c4OY7ydqWNm/u4UDmf60jWqHcmNcWftr GHlte10AgPLPS1zxbCQJaOZYOzi3/z8XTu85PA1HbEXu+uzLvPAfasAjcOvWMmyUJgBO H1nLdQG18lY5csmFRmQFNcsQ6fHnZNi6ePjtQpf12LsyHTvkAymHvofBG2orqOtSMB7P GJnA== X-Gm-Message-State: AMCzsaXZjEfT1KERH2M/Wt78iWmA0t2tYXhMM6BeyOcqprKTSo7LZMEk 1xdumK3MynVtwzipPIRlKYVVif1tmK12Rc9SpfNGHw== X-Google-Smtp-Source: ABhQp+RZB16a2xNWBq4ZZIRvIe+/8mQZBWjthD4PbEW9a4JxiUdjsUS9g/ngNOeEBjuuZ5i2E2eW3Z7CJ1xQeLqcgLo= X-Received: by 10.129.228.14 with SMTP id r14mr1467534ywl.256.1508197681049; Mon, 16 Oct 2017 16:48:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.70.5 with HTTP; Mon, 16 Oct 2017 16:48:00 -0700 (PDT) In-Reply-To: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> From: Jana Iyengar Date: Mon, 16 Oct 2017 16:48:00 -0700 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: Ian Swett Cc: Roberto Peon , Mike Bishop , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Hugues Fafard Content-Type: multipart/alternative; boundary="089e082208d00834c7055bb2a393" 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, 16 Oct 2017 23:48:05 -0000 --089e082208d00834c7055bb2a393 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Based on what I'm seeing on the PR and on this thread, I think there's general agreement on this strategy to go forward. I would like to merge this PR soon, modulo a new revision to address some open comments. (There's currently a question about whether to use the high or the low-order bits for this, which should also get resolved before merging.) I'm asking folks to please review and speak up if they have disagreements with the direction or with any specifics. I'll be away from connectivity for a week, so unless there are unresolved issues then, I'd like to merge this in a week when I return. Martin can merge this sooner if there's only agreement. On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett wrote: > I believe the motivation for separate stream limits is to put a reasonabl= e > limit on the number of incoming streams you'll accept. Otherwise, an > application could use a very large number of one type(ie: uni) of stream > and almost none of another(ie: bidi), which would allow them to suddenly > open a huge number of the other type(ie: bidi) of stream if they wanted. > > If we were using H2 style max open streams we could do it either way, but > I think keeping them separate is probably best anyway. > > On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon wrote: > >> In H2, the even/odd thing was just an easy way to encode a unique ID per >> stream while indicating direction. >> This proposal seems to do the same thing, and that makes sense to >> me=E2=80=94instead of even-odd, we have mod-4-offset. >> >> I=E2=80=99d ask why bother to have separate stream limits. You could sti= ll just >> have the one limit for the overall space. >> With H2, that was part of the point of putting it there (though it was >> implit)=E2=80=94it was all part of one space, and thus the space was sin= gly >> countable! >> >> >> >> -=3DR >> >> >> >> *From: *QUIC on behalf of Ian Swett < >> ianswett@google.com> >> *Date: *Friday, October 13, 2017 at 2:05 PM >> *To: *Mike Bishop >> *Cc: *Mikkel Fahn=C3=B8e J=C3=B8rgensen , "quic@ietf= .org" < >> quic@ietf.org>, Hugues Fafard >> >> *Subject: *Re: Identify streams unidirectional vs bidirectional based on >> stream ID >> >> >> >> In many ways, they are 4 independent spaces, but Ryan pointed out to me >> that both for the purposes of draft text and implementation it's very >> useful to have a single unique identifier for a stream, since otherwise = you >> have to talk about/pass around (StreamID, Type) everywhere instead of ju= st >> StreamID. >> >> >> >> Keeping one stream ID avoids creating two of all the stream specific >> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET, etc), on= e >> for each stream space. >> >> >> >> Using the two most significant bits would eliminate the usefulness of an= y >> variable length integer encoding(current or Martin's new proposal), so >> using the lower bits makes sense. >> >> >> >> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop < >> Michael.Bishop@microsoft.com> wrote: >> >> Indeed. I almost think it makes more sense to say that there are four >> independent stream spaces, each with their own numbers. That does mean >> that each side will need to separately manage Max Stream ID for two spac= es, >> but that seems more reasonable than the alternative. In fact, this PR >> already implies that the limits for unidirectional and bidirectional >> streams are handled separately, which gets really weird when the IDs are >> interleaved with each other. >> >> >> >> In fact, this plays well with the variable-length encoding idea, since >> the maximum size of a Stream ID would be 62 bits. They could then be >> stored locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits i= ndicating which >> space they refer to. >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn= =C3=B8e >> J=C3=B8rgensen >> *Sent:* Friday, October 13, 2017 1:04 PM >> *To:* quic@ietf.org; Hugues Fafard >> *Subject:* Re: Identify streams unidirectional vs bidirectional based on >> stream ID >> >> >> >> Especially with the new variable length encoding proposal, storing the >> identifiers early makes sense, as you only have to inspect the first byt= e. >> But it gets complicated, because you don=E2=80=99t want to use 8 bytes f= or some >> stream types and you don=E2=80=99t want the bits at some random location= in a >> decoded 8 byte representation either. >> >> >> >> Regardless of bit placement, encoding state using bits is not ideal when >> considering variable length encoding because you now use two bits for >> length and two bits for stream type, leaving only 16 different streams >> before the stream identifier needs to use two bytes, and so forth. >> >> >> >> >> >> Kind Regards, >> >> Mikkel Fahn=C3=B8e J=C3=B8rgensen >> >> >> >> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote: >> >> I see, you used the 2 least significant bits to encode that >> information. When only using one bit to indicate the direction, it >> boiled down to odd/even which more or less made sense, but when using >> 2 bits that breaks apart. >> >> Why not use the most significant bits instead? That way, getting the >> 'clean' stream ID without the flags would be as simple doing a `& >> 0x3F...FF` instead of bit-shifting things around. Similarly, encoding >> the stream ID would just entail `| 0x?0...00` to set the appropriate >> bits and also avoid bit-shifts. >> >> Regards, >> Hugues >> >> On 2017-10-13 20:51, Ryan Hamilton wrote: >> > As I understand the discussions at the interim, we've decided to >> > allow streams to be unidirectional or bidirectional. I support this >> > idea and was motivated to write up an idea I've been thinking about >> > for a while. In the same way that we use a bit in the stream ID to >> > identify the client vs server nature of the stream, we can use a >> > bit to identify the directionality. This divides the stream ID >> > space neatly into 4 distinct spaces (much like the 2 two we have >> > today: client/server). In addition this means that a stream ID >> > always uniquely identifies a single stream, and frames which >> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, >> > RST_STREAM, etc) do not need to explicitly convey the >> > directionality as fields in those frames (or implicitly based on >> > the directionality of the frames themselves). >> > >> > https://github.com/quicwg/base-drafts/pull/872 >> >> > >> > Cheers, >> > >> > Ryan >> >> >> > > --089e082208d00834c7055bb2a393 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Based on what I'm seeing on the PR and on this thread,= I think there's general agreement on this strategy to go forward. I wo= uld like to merge this PR soon, modulo a new revision to address some open = comments. (There's currently a question about whether to use the high o= r the low-order bits for this, which should also get resolved before mergin= g.)

I'm asking folks to please review and speak up i= f they have disagreements with the direction or with any specifics.

I'll be away from connectivity for a week, so unless = there are unresolved issues then,=C2=A0I'd like to merge this in a week= when I return. Martin can merge this sooner if there's only agreement.=

On Mo= n, Oct 16, 2017 at 8:15 AM, Ian Swett <ianswett@google.com> wrote:
I believe the m= otivation for separate stream limits is to put a reasonable limit on the nu= mber of incoming streams you'll accept.=C2=A0 Otherwise, an application= could use a very large number of one type(ie: uni) of stream and almost no= ne of another(ie: bidi), which would allow them to suddenly open a huge num= ber of the other type(ie: bidi) of stream if they wanted.=C2=A0=C2=A0
<= br>
If we were using H2 style max open streams we could do it eit= her way, but I think keeping them separate is probably best anyway.

=
On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon <= span dir=3D"ltr"><feni= x@fb.com> wrote:

In H2, the even/odd thing was just an easy way to en= code a unique ID per stream while indicating direction.
This proposal seems to do the same thing, and that makes sense to me=E2=80= =94instead of even-odd, we have mod-4-offset.

I=E2=80=99d ask why bother to have separate stream limits. You could still = just have the one limit for the overall space.
With H2, that was part of the point of putting it there (though it was impl= it)=E2=80=94it was all part of one space, and thus the space was singly cou= ntable!

=C2=A0

-=3DR

=C2=A0

From= : QUIC <quic-bounces@ietf.org> on behalf of Ian Swett <ianswett@google.com>
Date: Friday, October 13, 2017 at 2:05 PM
To: Mike Bishop <Michael.Bishop@microsoft.com>
Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>, "quic@ietf.org" <quic@ietf.org>, Hugues F= afard <fafard@in.t= um.de>


Subject: Re: Identify streams unidirectional vs bidirectional based = on stream ID

=C2=A0

In many ways, they are 4 independent spaces, but Rya= n pointed out to me that both for the purposes of draft text and implementa= tion it's very useful to have a single unique identifier for a stream, = since otherwise you have to talk about/pass around (StreamID, Type) everywhere instead of just StreamID.

=C2=A0

Keeping one stream ID avoids creating two of all the= stream specific frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OF= FSET, etc), one for each stream space.

=C2=A0

Using the two most significant bits would eliminate = the usefulness of any variable length integer encoding(current or Martin= 9;s new proposal), so using the lower bits makes sense.

=C2=A0

On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop <Michael.Bish= op@microsoft.com> wrote:

Indeed.=C2=A0 I almost think it makes more sense to = say that there are four independent stream spaces, each with their own numb= ers.=C2=A0 That does mean that each side will need to separately manage Max Stream ID for two spaces, but that seems more reasonable than t= he alternative.=C2=A0 In fact, this PR already implies that the limits for = unidirectional and bidirectional streams are handled separately, which gets= really weird when the IDs are interleaved with each other.

=C2=A0

In fact, this plays well with the variable-length en= coding idea, since the maximum size of a Stream ID would be 62 bits.=C2=A0 = They could then be stored locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits indicating which space they refer to.<= /u>

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Friday, October 13, 2017 1:04 PM
To: quic@ietf.org= ; Hugues Fafard <fafard@in.tum.de>
Subject: Re: Identify streams unidirectional vs bidirectional based = on stream ID

=C2=A0

Especially with the new variable length encoding = proposal, storing the identifiers early makes sense, as you only have to inspect the first byte. But it gets complicated, because you don= =E2=80=99t want to use 8 bytes for some stream types and you don=E2=80=99t = want the bits at some random location in a decoded 8 byte representation ei= ther.

=C2=A0

Regardless of bit placement, encoding state using= bits is not ideal when considering variable length encoding because you now use two bits for length and two bits for stream type, leaving only= 16 different streams before the stream identifier needs to use two bytes, = and so forth.

=C2=A0

=C2=A0

Kind Regards,

Mikkel Fahn=C3=B8e= J=C3=B8rgensen

=C2=A0

On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote:

I see, you used th= e 2 least significant bits to encode that
information. When only using one bit to indicate the direction, it
boiled down to odd/even which more or less made sense, but when using
2 bits that breaks apart.

Why not use the most significant bits instead? That way, getting the
'clean' stream ID without the flags would be as simple doing a `&am= p;
0x3F...FF` instead of bit-shifting things around. Similarly, encoding
the stream ID would just entail `| 0x?0...00` to set the appropriate
bits and also avoid bit-shifts.

Regards,
Hugues

On 2017-10-13 20:51, Ryan Hamilton wrote:
> As I understand the discussions at the interim, we've decided to <= br> > allow streams to be unidirectional or bidirectional. I support this > idea and was motivated to write up an idea I've been thinking abou= t
> for a while. In the same way that we use a bit in the stream ID to > identify the client vs server nature of the stream, we can use a
> bit to identify the directionality. This divides the stream ID
> space neatly into 4 distinct spaces (much like the 2 two we have
> today: client/server). In addition this means that a stream ID
> always uniquely identifies a single stream, and frames which
> mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA,
> RST_STREAM, etc) do not need to explicitly convey the
> directionality as fields in those frames (or implicitly based on
> the directionality of the frames themselves).
>
> https://github.com/quicwg/base-drafts/pull/872
>
> Cheers,
>
> Ryan

=C2=A0



--089e082208d00834c7055bb2a393-- From nobody Mon Oct 16 17:49: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 D7D4C1320BD for ; Mon, 16 Oct 2017 17:49:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 vc6pIhBcycKW for ; Mon, 16 Oct 2017 17:49:39 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 117A4126BF0 for ; Mon, 16 Oct 2017 17:49:39 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id a132so118478oih.11 for ; Mon, 16 Oct 2017 17:49:39 -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:content-transfer-encoding; bh=Tp2YnpmgrsiMelSxsTMClmvUEqviDFbZp9+dID6L6G0=; b=FOX8s2ApBaIibnR/TBlZv3Jr8RxHNZ5e6j/lybvRV2am0+QjW5a94GgX+WQGhn/oFO zdJhCDkMNBX+zZXCx+Yc3H9KgQKtlRrD4Ai66rMdlCYwMFSgqq+xBGX1eguwqkb80KWd J9ns5s3ob9ZsKqyQXko1U210ZYiA80YVLXQ9LsfO56bD4IxGCr1Gb5lJtcwFVzSsEUso XUgdJAHfqjDGHpjRfVBxoJpzBFbNx+UTeHv+RLMLxODP95bCikaVwqsHdxXNWWjynqRH fbz6z7a6+U7hZF6Rh9+vutti2N3w+E0YCgc4NFxPwGe/0taiCISvhD83XgeiEOduaGoz EEPA== 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=Tp2YnpmgrsiMelSxsTMClmvUEqviDFbZp9+dID6L6G0=; b=YNhjAIguWNuDe/9zF8M5Xd3lfj9je/As/pO43ufyKkl2d3zwujMQR2/zsaZ3mFphke sgl75eg00iE2eJd0jXf4WNimeWEj/bPiCVS81Le0SeLbE2/9z6WI6eL3+b+EB/3NUpJ4 F1JCNGGWEZlndFitHtDiLKXhfDJ4up/WSrfbFSaWf+WqVGpSX6IJLrAti7+twxj2KBoa ev2oFdI7LnuDyfcBOcqQotlZTRhBZNrR46wVyGF4YIJw/TWyr/1tMEnixRRtk9rxViM8 RGzDiQbKoMNj1tScooaDA0Y/hzbBb5njy2reWMeUvnm8Sey/SYlIc9WD8L23VH87aknd a9ew== X-Gm-Message-State: AMCzsaXblzz+mqTRX/iJwBksvE7Oy6UqSU1/6gvfw2BJLVBFWUEQNseC gyulof0HKSFq843WdYgAqRY+4xH9M42YA5GqqbU= X-Google-Smtp-Source: ABhQp+RMWpJdXUX+pjcxGgWn+WbCeVgyyFBNuvDyzSQ8Ul+d5CzeDx6IaD+SQ9axv/PmSi5Rm5iDDM/C7bL+bRSq/gs= X-Received: by 10.202.217.197 with SMTP id q188mr5341332oig.83.1508201378360; Mon, 16 Oct 2017 17:49:38 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Mon, 16 Oct 2017 17:49:37 -0700 (PDT) In-Reply-To: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> From: Martin Thomson Date: Tue, 17 Oct 2017 11:49:37 +1100 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: Jana Iyengar Cc: Ian Swett , Hugues Fafard , Mike Bishop , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , "quic@ietf.org" , Roberto Peon 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: Tue, 17 Oct 2017 00:49:42 -0000 Those low order bits are important. No need to rush (it's a relatively small changeset). On Tue, Oct 17, 2017 at 10:48 AM, Jana Iyengar wrote: > Based on what I'm seeing on the PR and on this thread, I think there's > general agreement on this strategy to go forward. I would like to merge t= his > PR soon, modulo a new revision to address some open comments. (There's > currently a question about whether to use the high or the low-order bits = for > this, which should also get resolved before merging.) > > I'm asking folks to please review and speak up if they have disagreements > with the direction or with any specifics. > > I'll be away from connectivity for a week, so unless there are unresolved > issues then, I'd like to merge this in a week when I return. Martin can > merge this sooner if there's only agreement. > > On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett wrote: >> >> I believe the motivation for separate stream limits is to put a reasonab= le >> limit on the number of incoming streams you'll accept. Otherwise, an >> application could use a very large number of one type(ie: uni) of stream= and >> almost none of another(ie: bidi), which would allow them to suddenly ope= n a >> huge number of the other type(ie: bidi) of stream if they wanted. >> >> If we were using H2 style max open streams we could do it either way, bu= t >> I think keeping them separate is probably best anyway. >> >> On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon wrote: >>> >>> In H2, the even/odd thing was just an easy way to encode a unique ID pe= r >>> stream while indicating direction. >>> This proposal seems to do the same thing, and that makes sense to >>> me=E2=80=94instead of even-odd, we have mod-4-offset. >>> >>> I=E2=80=99d ask why bother to have separate stream limits. You could st= ill just >>> have the one limit for the overall space. >>> With H2, that was part of the point of putting it there (though it was >>> implit)=E2=80=94it was all part of one space, and thus the space was si= ngly >>> countable! >>> >>> >>> >>> -=3DR >>> >>> >>> >>> From: QUIC on behalf of Ian Swett >>> >>> Date: Friday, October 13, 2017 at 2:05 PM >>> To: Mike Bishop >>> Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen , "quic@ietf.= org" >>> , Hugues Fafard >>> >>> >>> Subject: Re: Identify streams unidirectional vs bidirectional based on >>> stream ID >>> >>> >>> >>> In many ways, they are 4 independent spaces, but Ryan pointed out to me >>> that both for the purposes of draft text and implementation it's very u= seful >>> to have a single unique identifier for a stream, since otherwise you ha= ve to >>> talk about/pass around (StreamID, Type) everywhere instead of just Stre= amID. >>> >>> >>> >>> Keeping one stream ID avoids creating two of all the stream specific >>> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET, etc), o= ne >>> for each stream space. >>> >>> >>> >>> Using the two most significant bits would eliminate the usefulness of a= ny >>> variable length integer encoding(current or Martin's new proposal), so = using >>> the lower bits makes sense. >>> >>> >>> >>> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop >>> wrote: >>> >>> Indeed. I almost think it makes more sense to say that there are four >>> independent stream spaces, each with their own numbers. That does mean= that >>> each side will need to separately manage Max Stream ID for two spaces, = but >>> that seems more reasonable than the alternative. In fact, this PR alre= ady >>> implies that the limits for unidirectional and bidirectional streams ar= e >>> handled separately, which gets really weird when the IDs are interleave= d >>> with each other. >>> >>> >>> >>> In fact, this plays well with the variable-length encoding idea, since >>> the maximum size of a Stream ID would be 62 bits. They could then be s= tored >>> locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits indicat= ing which space they >>> refer to. >>> >>> >>> >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3= =B8e >>> J=C3=B8rgensen >>> Sent: Friday, October 13, 2017 1:04 PM >>> To: quic@ietf.org; Hugues Fafard >>> Subject: Re: Identify streams unidirectional vs bidirectional based on >>> stream ID >>> >>> >>> >>> Especially with the new variable length encoding proposal, storing the >>> identifiers early makes sense, as you only have to inspect the first by= te. >>> But it gets complicated, because you don=E2=80=99t want to use 8 bytes = for some >>> stream types and you don=E2=80=99t want the bits at some random locatio= n in a >>> decoded 8 byte representation either. >>> >>> >>> >>> Regardless of bit placement, encoding state using bits is not ideal whe= n >>> considering variable length encoding because you now use two bits for l= ength >>> and two bits for stream type, leaving only 16 different streams before = the >>> stream identifier needs to use two bytes, and so forth. >>> >>> >>> >>> >>> >>> Kind Regards, >>> >>> Mikkel Fahn=C3=B8e J=C3=B8rgensen >>> >>> >>> >>> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote: >>> >>> I see, you used the 2 least significant bits to encode that >>> information. When only using one bit to indicate the direction, it >>> boiled down to odd/even which more or less made sense, but when using >>> 2 bits that breaks apart. >>> >>> Why not use the most significant bits instead? That way, getting the >>> 'clean' stream ID without the flags would be as simple doing a `& >>> 0x3F...FF` instead of bit-shifting things around. Similarly, encoding >>> the stream ID would just entail `| 0x?0...00` to set the appropriate >>> bits and also avoid bit-shifts. >>> >>> Regards, >>> Hugues >>> >>> On 2017-10-13 20:51, Ryan Hamilton wrote: >>> > As I understand the discussions at the interim, we've decided to >>> > allow streams to be unidirectional or bidirectional. I support this >>> > idea and was motivated to write up an idea I've been thinking about >>> > for a while. In the same way that we use a bit in the stream ID to >>> > identify the client vs server nature of the stream, we can use a >>> > bit to identify the directionality. This divides the stream ID >>> > space neatly into 4 distinct spaces (much like the 2 two we have >>> > today: client/server). In addition this means that a stream ID >>> > always uniquely identifies a single stream, and frames which >>> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, >>> > RST_STREAM, etc) do not need to explicitly convey the >>> > directionality as fields in those frames (or implicitly based on >>> > the directionality of the frames themselves). >>> > >>> > https://github.com/quicwg/base-drafts/pull/872 >>> > >>> > Cheers, >>> > >>> > Ryan >>> >>> >> >> > From nobody Mon Oct 16 18:20: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 760C712ECEC for ; Mon, 16 Oct 2017 18:20:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 oU588BDR3WJe for ; Mon, 16 Oct 2017 18:19:59 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 DFBDD127005 for ; Mon, 16 Oct 2017 18:19:58 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id 134so502549ioo.0 for ; Mon, 16 Oct 2017 18:19:58 -0700 (PDT) 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=hbCI4NGTUkxNLKlA+VJUYw2Y/xfwcjIjC5JkcfShdvU=; b=qL80l1yBeYdk0ozZmwAfEJpXKiMaudU0ESbLrL39rSkAtGF4AxpZOjLxo23nG/wW1Q 9Qs0vYWXT9+ZzOULES/DdzP2Ik+PyzBP1WuWTaPCAqNXV9tKQovqeMBNtp1vTA/PHzIs vas+sKAuxwb5PRgj+A5RY2r2gzqwls+julDBOFZzSgEvccNHvXow18bSMKRsdgzfyclH 3Yuff4yqlN/iovuI5KwFVGZC+1aMdfRJ/8gsxMtMPnkraquXB2Uje+mKRtslE6w6YkWI eqzBDHETl6gnvVB/vJ1QRxrHysuGgIqsWSCYCut9uLXd4PxAiqxmAUDol/Kl/ZL+Z8zn BDPg== 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=hbCI4NGTUkxNLKlA+VJUYw2Y/xfwcjIjC5JkcfShdvU=; b=CfAz+26814C7An2IZlYUKwFr/MBjmyTwLePh+5kaRH6k6Gr/L+J4rglTXWb1sGaAgk yE93db0nPN922gNjihTszPQD3zQuASZxH2uG+iWQ3SSM3pvPbQJnCrDg+2ZEoDpO7fXF gWFcNuImIIcMgUmKG0A6Z7OBabtQ6KjEVX9hANe4351jsgg1omodR1FT/7YREVPpVu1O FsfLSFC4DqQoq3D8qnL3mUzS7ni4+8dBNDXIiZpDIKGS5DFweAqiXXRp05uS+CSWfc30 b7tMOmh3tRARzouPOWkwFCHhH/obPK6onCxw3MXKddN+8cegIiT8Ck47EsZX4CHPba3E mXwg== X-Gm-Message-State: AMCzsaWqVSTvNhIR8EVEpLNI+8hcyB+7CmboijsQds6/np0kI3oKAqft Ngj84Z9XbWK/RqOTHgJDBJWu6CE9RIKQeloeyGM= X-Google-Smtp-Source: ABhQp+SjgW1jT5jLZhE/8W4KjK0lLXm6wpDkYErdLDVFCP6uasF6evCQeSzM1nnt6Rgxb8cLeN/jsO6wFPvoheejyNc= X-Received: by 10.107.201.204 with SMTP id z195mr13965149iof.16.1508203197873; Mon, 16 Oct 2017 18:19:57 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 16 Oct 2017 18:19:56 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Mon, 16 Oct 2017 18:19:56 -0700 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: Martin Thomson , Jana Iyengar Cc: Mike Bishop , "quic@ietf.org" , Ian Swett , Hugues Fafard , Roberto Peon Content-Type: multipart/alternative; boundary="94eb2c0b89e8dbc1c4055bb3ebec" 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, 17 Oct 2017 01:20:01 -0000 --94eb2c0b89e8dbc1c4055bb3ebec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I=E2=80=99m just wondering why this approach was preferred as opposed to bu= ilding bidi on top of uni. I suppose this must have been discussed at the interim and in part based on the recent experimental implementation of uni streams. A straightforward implementation may not have much difficulty in handling the implementation either way but when you attempt to achieve low latency and low memory foot print with shortest possible state life times including coordination with application level buffers, then bidi streams are not very fun to work with at the transport level. As become more agreeable after it was concluded that teardown did not have to wait for FIN ACK and related, but it is still a lot of complexity with potential bugs. One aspect of the complexity is that there are now four special cases instead of two in the stream identifiers which must be dealt with in several frame types. Some of this involves flow control per stream type which bidi on top of uni would not support at the same granularity, but is this really needed? Adding uni streams in addition to bidi streams is still a lot better than not having uni streams because they solve problems such as async messaging at high volume and partial reliability via throw away streams. However, they do nothing to simplify the transport with the current proposal. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 17 October 2017 at 02.49.38, Martin Thomson (martin.thomson@gmail.com) wrote: Those low order bits are important. No need to rush (it's a relatively small changeset). On Tue, Oct 17, 2017 at 10:48 AM, Jana Iyengar wrote: > Based on what I'm seeing on the PR and on this thread, I think there's > general agreement on this strategy to go forward. I would like to merge this > PR soon, modulo a new revision to address some open comments. (There's > currently a question about whether to use the high or the low-order bits for > this, which should also get resolved before merging.) > > I'm asking folks to please review and speak up if they have disagreements > with the direction or with any specifics. > > I'll be away from connectivity for a week, so unless there are unresolved > issues then, I'd like to merge this in a week when I return. Martin can > merge this sooner if there's only agreement. > > On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett wrote: >> >> I believe the motivation for separate stream limits is to put a reasonable >> limit on the number of incoming streams you'll accept. Otherwise, an >> application could use a very large number of one type(ie: uni) of stream and >> almost none of another(ie: bidi), which would allow them to suddenly open a >> huge number of the other type(ie: bidi) of stream if they wanted. >> >> If we were using H2 style max open streams we could do it either way, but >> I think keeping them separate is probably best anyway. >> >> On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon wrote: >>> >>> In H2, the even/odd thing was just an easy way to encode a unique ID per >>> stream while indicating direction. >>> This proposal seems to do the same thing, and that makes sense to >>> me=E2=80=94instead of even-odd, we have mod-4-offset. >>> >>> I=E2=80=99d ask why bother to have separate stream limits. You could st= ill just >>> have the one limit for the overall space. >>> With H2, that was part of the point of putting it there (though it was >>> implit)=E2=80=94it was all part of one space, and thus the space was si= ngly >>> countable! >>> >>> >>> >>> -=3DR >>> >>> >>> >>> From: QUIC on behalf of Ian Swett >>> >>> Date: Friday, October 13, 2017 at 2:05 PM >>> To: Mike Bishop >>> Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen , "quic@ietf.= org" >>> , Hugues Fafard >>> >>> >>> Subject: Re: Identify streams unidirectional vs bidirectional based on >>> stream ID >>> >>> >>> >>> In many ways, they are 4 independent spaces, but Ryan pointed out to me >>> that both for the purposes of draft text and implementation it's very useful >>> to have a single unique identifier for a stream, since otherwise you have to >>> talk about/pass around (StreamID, Type) everywhere instead of just StreamID. >>> >>> >>> >>> Keeping one stream ID avoids creating two of all the stream specific >>> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET, etc), one >>> for each stream space. >>> >>> >>> >>> Using the two most significant bits would eliminate the usefulness of any >>> variable length integer encoding(current or Martin's new proposal), so using >>> the lower bits makes sense. >>> >>> >>> >>> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop >>> wrote: >>> >>> Indeed. I almost think it makes more sense to say that there are four >>> independent stream spaces, each with their own numbers. That does mean that >>> each side will need to separately manage Max Stream ID for two spaces, but >>> that seems more reasonable than the alternative. In fact, this PR already >>> implies that the limits for unidirectional and bidirectional streams are >>> handled separately, which gets really weird when the IDs are interleaved >>> with each other. >>> >>> >>> >>> In fact, this plays well with the variable-length encoding idea, since >>> the maximum size of a Stream ID would be 62 bits. They could then be stored >>> locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits indicat= ing which space they >>> refer to. >>> >>> >>> >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3= =B8e >>> J=C3=B8rgensen >>> Sent: Friday, October 13, 2017 1:04 PM >>> To: quic@ietf.org; Hugues Fafard >>> Subject: Re: Identify streams unidirectional vs bidirectional based on >>> stream ID >>> >>> >>> >>> Especially with the new variable length encoding proposal, storing the >>> identifiers early makes sense, as you only have to inspect the first byte. >>> But it gets complicated, because you don=E2=80=99t want to use 8 bytes = for some >>> stream types and you don=E2=80=99t want the bits at some random locatio= n in a >>> decoded 8 byte representation either. >>> >>> >>> >>> Regardless of bit placement, encoding state using bits is not ideal when >>> considering variable length encoding because you now use two bits for length >>> and two bits for stream type, leaving only 16 different streams before the >>> stream identifier needs to use two bytes, and so forth. >>> >>> >>> >>> >>> >>> Kind Regards, >>> >>> Mikkel Fahn=C3=B8e J=C3=B8rgensen >>> >>> >>> >>> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote: >>> >>> I see, you used the 2 least significant bits to encode that >>> information. When only using one bit to indicate the direction, it >>> boiled down to odd/even which more or less made sense, but when using >>> 2 bits that breaks apart. >>> >>> Why not use the most significant bits instead? That way, getting the >>> 'clean' stream ID without the flags would be as simple doing a `& >>> 0x3F...FF` instead of bit-shifting things around. Similarly, encoding >>> the stream ID would just entail `| 0x?0...00` to set the appropriate >>> bits and also avoid bit-shifts. >>> >>> Regards, >>> Hugues >>> >>> On 2017-10-13 20:51, Ryan Hamilton wrote: >>> > As I understand the discussions at the interim, we've decided to >>> > allow streams to be unidirectional or bidirectional. I support this >>> > idea and was motivated to write up an idea I've been thinking about >>> > for a while. In the same way that we use a bit in the stream ID to >>> > identify the client vs server nature of the stream, we can use a >>> > bit to identify the directionality. This divides the stream ID >>> > space neatly into 4 distinct spaces (much like the 2 two we have >>> > today: client/server). In addition this means that a stream ID >>> > always uniquely identifies a single stream, and frames which >>> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, >>> > RST_STREAM, etc) do not need to explicitly convey the >>> > directionality as fields in those frames (or implicitly based on >>> > the directionality of the frames themselves). >>> > >>> > https://github.com/quicwg/base-drafts/pull/872 >>> > >>> > Cheers, >>> > >>> > Ryan >>> >>> >> >> > --94eb2c0b89e8dbc1c4055bb3ebec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = I=E2=80=99m just won= dering why this approach was preferred as opposed to building bidi on top o= f uni. I suppose this must have been discussed at the interim and in part b= ased on the recent experimental implementation of uni streams.
<= br>
A straightforward implementation may not have much difficulty in h= andling the implementation either way but when you attempt to achieve low l= atency and low memory foot print with shortest possible state life times in= cluding coordination with application level buffers, then bidi streams are = not very fun to work with at the transport level. As become more agreeable = after it was concluded that teardown did not have to wait for FIN ACK and r= elated, but it is still a lot of complexity with potential bugs.

One aspect of the complexity is that there are now four special ca= ses instead of two in the stream identifiers which must be dealt with in se= veral frame types. Some of this involves flow control per stream type which= bidi on top of uni would not support at the same granularity, but is this = really needed?

Adding uni streams in addition to bid= i streams is still a lot better than not having uni streams because they so= lve problems such as async messaging at high volume and partial reliability= via throw away streams. However, they do nothing to simplify the transport= with the current proposal.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen


On 17 October 2017 at 02.49.38, Martin Thomson (martin.thomson@gmail.com) wrote:=

Those low order bits are important. No need to rush (it's a
relatively small changeset).

On Tue, Oct 17, 2017 at 10:48 AM, Jana Iyengar <jri@google.com> wrote:
> Based on what I'm seeing on the PR and on this thread, I think= there's
> general agreement on this strategy to go forward. I would like to = merge this
> PR soon, modulo a new revision to address some open comments. (The= re's
> currently a question about whether to use the high or the low-orde= r bits for
> this, which should also get resolved before merging.)
>
> I'm asking folks to please review and speak up if they have di= sagreements
> with the direction or with any specifics.
>
> I'll be away from connectivity for a week, so unless there are= unresolved
> issues then, I'd like to merge this in a week when I return. M= artin can
> merge this sooner if there's only agreement.
>
> On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett <ianswett@google.com> wrote:
>>
>> I believe the motivation for separate stream limits is to put = a reasonable
>> limit on the number of incoming streams you'll accept. Ot= herwise, an
>> application could use a very large number of one type(ie: uni)= of stream and
>> almost none of another(ie: bidi), which would allow them to su= ddenly open a
>> huge number of the other type(ie: bidi) of stream if they want= ed.
>>
>> If we were using H2 style max open streams we could do it eith= er way, but
>> I think keeping them separate is probably best anyway.
>>
>> On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon <fenix@fb.com> wrote:
>>>
>>> In H2, the even/odd thing was just an easy way to encode a= unique ID per
>>> stream while indicating direction.
>>> This proposal seems to do the same thing, and that makes s= ense to
>>> me=E2=80=94instead of even-odd, we have mod-4-offset.
>>>
>>> I=E2=80=99d ask why bother to have separate stream limits.= You could still just
>>> have the one limit for the overall space.
>>> With H2, that was part of the point of putting it there (t= hough it was
>>> implit)=E2=80=94it was all part of one space, and thus the= space was singly
>>> countable!
>>>
>>>
>>>
>>> -=3DR
>>>
>>>
>>>
>>> From: QUIC <qu= ic-bounces@ietf.org> on behalf of Ian Swett
>>> <ianswett@google= .com>
>>> Date: Friday, October 13, 2017 at 2:05 PM
>>> To: Mike Bishop <Michael.Bishop@microsoft.com>
>>> Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com>, "quic@ietf.org"
>>> <quic@ietf.org>= , Hugues Fafard <fafard@in.tum.de>
>>>
>>>
>>> Subject: Re: Identify streams unidirectional vs bidirectio= nal based on
>>> stream ID
>>>
>>>
>>>
>>> In many ways, they are 4 independent spaces, but Ryan poin= ted out to me
>>> that both for the purposes of draft text and implementatio= n it's very useful
>>> to have a single unique identifier for a stream, since oth= erwise you have to
>>> talk about/pass around (StreamID, Type) everywhere instead= of just StreamID.
>>>
>>>
>>>
>>> Keeping one stream ID avoids creating two of all the strea= m specific
>>> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OF= FSET, etc), one
>>> for each stream space.
>>>
>>>
>>>
>>> Using the two most significant bits would eliminate the us= efulness of any
>>> variable length integer encoding(current or Martin's n= ew proposal), so using
>>> the lower bits makes sense.
>>>
>>>
>>>
>>> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop
>>> <Michae= l.Bishop@microsoft.com> wrote:
>>>
>>> Indeed. I almost think it makes more sense to say that th= ere are four
>>> independent stream spaces, each with their own numbers. T= hat does mean that
>>> each side will need to separately manage Max Stream ID for= two spaces, but
>>> that seems more reasonable than the alternative. In fact,= this PR already
>>> implies that the limits for unidirectional and bidirection= al streams are
>>> handled separately, which gets really weird when the IDs a= re interleaved
>>> with each other.
>>>
>>>
>>>
>>> In fact, this plays well with the variable-length encoding= idea, since
>>> the maximum size of a Stream ID would be 62 bits. They co= uld then be stored
>>> locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D= bits indicating which space they
>>> refer to.
>>>
>>>
>>>
>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3=B8e
>>> J=C3=B8rgensen
>>> Sent: Friday, October 13, 2017 1:04 PM
>>> To: quic@ietf.org; Hu= gues Fafard <fafard@in.tum.de>= ;
>>> Subject: Re: Identify streams unidirectional vs bidirectio= nal based on
>>> stream ID
>>>
>>>
>>>
>>> Especially with the new variable length encoding proposal,= storing the
>>> identifiers early makes sense, as you only have to inspect= the first byte.
>>> But it gets complicated, because you don=E2=80=99t want to= use 8 bytes for some
>>> stream types and you don=E2=80=99t want the bits at some r= andom location in a
>>> decoded 8 byte representation either.
>>>
>>>
>>>
>>> Regardless of bit placement, encoding state using bits is = not ideal when
>>> considering variable length encoding because you now use t= wo bits for length
>>> and two bits for stream type, leaving only 16 different st= reams before the
>>> stream identifier needs to use two bytes, and so forth.
>>>
>>>
>>>
>>>
>>>
>>> Kind Regards,
>>>
>>> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>>>
>>>
>>>
>>> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote:
>>>
>>> I see, you used the 2 least significant bits to encode tha= t
>>> information. When only using one bit to indicate the direc= tion, it
>>> boiled down to odd/even which more or less made sense, but= when using
>>> 2 bits that breaks apart.
>>>
>>> Why not use the most significant bits instead? That way, g= etting the
>>> 'clean' stream ID without the flags would be as si= mple doing a `&
>>> 0x3F...FF` instead of bit-shifting things around. Similarl= y, encoding
>>> the stream ID would just entail `| 0x?0...00` to set the a= ppropriate
>>> bits and also avoid bit-shifts.
>>>
>>> Regards,
>>> Hugues
>>>
>>> On 2017-10-13 20:51, Ryan Hamilton wrote:
>>> > As I understand the discussions at the interim, we= 9;ve decided to
>>> > allow streams to be unidirectional or bidirectional. = I support this
>>> > idea and was motivated to write up an idea I've b= een thinking about
>>> > for a while. In the same way that we use a bit in the= stream ID to
>>> > identify the client vs server nature of the stream, w= e can use a
>>> > bit to identify the directionality. This divides the = stream ID
>>> > space neatly into 4 distinct spaces (much like the 2 = two we have
>>> > today: client/server). In addition this means that a = stream ID
>>> > always uniquely identifies a single stream, and frame= s which
>>> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_= DATA,
>>> > RST_STREAM, etc) do not need to explicitly convey the
>>> > directionality as fields in those frames (or implicit= ly based on
>>> > the directionality of the frames themselves).
>>> >
>>> > https://github.com/quicwg/base-drafts/pull/872
>>> >
>>> > Cheers,
>>> >
>>> > Ryan
>>>
>>>
>>
>>
>
--94eb2c0b89e8dbc1c4055bb3ebec-- From nobody Mon Oct 16 18:41: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 821E4132EDA for ; Mon, 16 Oct 2017 18:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 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, 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=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 U9yE063wdMNc for ; Mon, 16 Oct 2017 18:41:45 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0099.outbound.protection.outlook.com [104.47.37.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 D8464132949 for ; Mon, 16 Oct 2017 18:41:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=VhWTwKH9bfUb44XmUaE2Jco940SQ0RGIHJhjlVu9t64=; b=n6fz/VZL4g1sW7cvZYxH9kb2NDEqxlbsmQN618jHBvA0aMN0tWpPj8azS9pzqwGMTZxpSbuQBvwi7epl+EB9XYU7hX13IQchAoqst7qmRZXKwXE+RpQ4GJ3hDbBZ0hQY8Zp7MMHKE4o9uD1gwoYn6U9yyg7wNnfqptiLNGy6naY= Received: from MWHPR21MB0288.namprd21.prod.outlook.com (10.173.53.18) by MWHPR21MB0704.namprd21.prod.outlook.com (10.175.142.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.178.1; Tue, 17 Oct 2017 01:41:42 +0000 Received: from MWHPR21MB0288.namprd21.prod.outlook.com ([10.173.53.18]) by MWHPR21MB0288.namprd21.prod.outlook.com ([10.173.53.18]) with mapi id 15.20.0156.003; Tue, 17 Oct 2017 01:41:41 +0000 From: Praveen Balasubramanian To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Martin Thomson , Jana Iyengar CC: Mike Bishop , Ian Swett , "quic@ietf.org" , Hugues Fafard , Roberto Peon Subject: RE: Identify streams unidirectional vs bidirectional based on stream ID Thread-Topic: Identify streams unidirectional vs bidirectional based on stream ID Thread-Index: AQHTRFRX3Y8S/jyPrkiHgIo+cZaNKKLiMDyAgAAD6ACAAA7DAIAAAjAAgARRgYCAAAQGgIAAjx8AgAARN4CAAAh4AIAAAHxg Date: Tue, 17 Oct 2017 01:41:41 +0000 Message-ID: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:f::712] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0704; 6:6eiiJBS+K7V7MGAJ9EoywY10pIKBnq65cyygEEeMnto0G/saBN9M9+ML17P9u08yEF5XKz7MzLfV47pOlQ5Fubr7bb8f8WJTBK+/1c/PvE1deZ0zp6zBC4+uwYqdPIMwSMHOTagHq5D2WqTX2rlXoXrAJ6CUkgl/nDq33wKLAowc0CIO9kqqr+ecSRKLoHocNJ1QTG/RJKFQY0KJV2IS0CHHXtfha262C/bLtOqsKe2L4ZFVgnW+SMKHKS7DHOTaD3JyxZ0aA6UBn4gyEcDZKbgURYz9rhqpQrOaSZ04mlQo4VW8nr8m1b2ZZVazKE4ejErjmvtkjCUZjakGSvQRXw+KEGDSdM+DhiEPm1v6Qmg=; 5:OUvFweUaUvF58aCaDrNIUFVWK/g5OhVJPVzzr3pp8SAww7qbfdQiv2nn1RwOYWeDDJm8IrzphOBKlk/ICAzvkVDaDTbJfHm677hi3/t36mPbJxWMuJ+obO4wCuSJSN9KI46tgZkef0eZC4cc4kto/ksO3r5cdw/nk4lbwx9J0tI=; 24:oq3deyvgNm5NXUO4Ii4MwmrtHgc2WHYK4jce5Xv5uidEifwkTIJhlifu/itREVby7mKjrP1g8JOQw9AK5bqC/gR3lX20DUK02yy2ZsJi8MY=; 7:eVxcqL6llfD36tsZwQfDHgqR8bZm2PzsA8KVf8JZs+BCzLkEYjebsX5p4XX/YdNUBtxds7rf9ML3IEWgTzKTmhCCAhL+SuCumk0Z/tRmrhOY9uKMjjKVOuE0HhA3brYuEw+6TZR6SWcQyu0IQPyY+krlVjnN66hrdP8pFDXiL5x4T+XJWBleTGXZpndtCuwvNO3bx4sN+9fx88v+vx8Obd67DU4mDa1S/K4yoHO4Y1LEIaLj38Xnz2uLLvFqc+H1 x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR; x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(47760400005)(199003)(377424004)(57704003)(24454002)(189002)(377454003)(10090500001)(54356999)(10290500003)(25786009)(229853002)(76176999)(561944003)(101416001)(8990500004)(2950100002)(478600001)(50986999)(966005)(189998001)(6436002)(39060400002)(6506006)(54906003)(110136005)(6246003)(99286003)(102836003)(53936002)(68736007)(790700001)(54896002)(33656002)(6116002)(55016002)(6306002)(9686003)(236005)(2900100001)(77096006)(105586002)(106356001)(316002)(22452003)(4326008)(86612001)(34040400001)(3660700001)(4001150100001)(74316002)(3280700002)(7696004)(86362001)(7736002)(19609705001)(5660300001)(8936002)(81166006)(93886005)(97736004)(606006)(14454004)(53546010)(2906002)(8676002)(81156014); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0704; H:MWHPR21MB0288.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; x-ms-office365-filtering-correlation-id: 95a4c758-dee1-4b96-fde4-08d51500378e x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254152)(48565401081)(2017052603219)(201703131423075)(201703031133081)(201702281549075); SRVR:MWHPR21MB0704; x-ms-traffictypediagnostic: MWHPR21MB0704: x-exchange-antispam-report-test: UriScan:(158342451672863)(89211679590171)(166708455590820)(189930954265078)(67672495146484)(211936372134217)(153496737603132)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(920507026)(6055026)(61426038)(61427038)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123555025)(20161123558100)(20161123560025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0704; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0704; x-forefront-prvs: 04631F8F77 received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0288008D1302D533FB07C6DFB64C0MWHPR21MB0288namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 95a4c758-dee1-4b96-fde4-08d51500378e X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Oct 2017 01:41:41.7523 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0704 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, 17 Oct 2017 01:41:48 -0000 --_000_MWHPR21MB0288008D1302D533FB07C6DFB64C0MWHPR21MB0288namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhZ3JlZSB0aGF0IHRoaXMgaXMgYWRkaW5nIGNvbXBsZXhpdHkgd2l0aCBmb3VyIHNwZWNpYWwg Y2FzZXMsIGJ1dCBJIHdvdWxkIGFjdHVhbGx5IGFyZ3VlIHRoZSBvdGhlciB3YXk6IGFwcHMgdGhh dCB3YW50IHVuaSBzdHJlYW1zIHNob3VsZCBiZSBhYmxlIHRvIHVzZSB0aGUgZXhpc3RpbmcgYmlk aSBzdHJlYW0gbWVjaGFuaXNtLiBBbiBBUEkgZm9yIHVuaSBzdHJlYW0gY2FuIGFjaGlldmUgdGhp cyBieSBjbG9zaW5nIHRoZSBzdHJlYW0gaW4gb25lIGRpcmVjdGlvbiBpbW1lZGlhdGVseSBhZnRl ciBvcGVuaW5nIGl0IHNvIHRoYXQgdGhlIHZlcnkgZmlyc3QgcGFja2V0IGZvciB0aGF0IHN0cmVh bSBzaWduYWxzIHRoYXQgb25lIGRpcmVjdGlvbiBpcyBjbG9zZWQgYW5kIHRoZSBvdGhlciBlbmQg a25vd3MgdGhhdCB0aGUgc3RyZWFtIGlzIHVuaS4gQmlkaSBzdHJlYW1zIGFyZSBhIG1vcmUgZ2Vu ZXJhbCBjYXNlIGFuZCBpZiB3ZSBhcmUgZ29pbmcgdG8gc3VwcG9ydCB0aGVtICh3aGljaCBJIHRo aW5rIHdlIHNob3VsZCkgdGhlbiBkbyB3ZSBuZWVkIGFueSBkZWRpY2F0ZWQgdHJhbnNwb3J0IG1l Y2hhbmlzbXMgZm9yIHVuaSBzdHJlYW1zPw0KDQpUaGFua3MNCg0KRnJvbTogUVVJQyBbbWFpbHRv OnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIE1pa2tlbCBGYWhuw7hlIErDuHJn ZW5zZW4NClNlbnQ6IE1vbmRheSwgT2N0b2JlciAxNiwgMjAxNyA2OjIwIFBNDQpUbzogTWFydGlu IFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbT47IEphbmEgSXllbmdhciA8anJpQGdv b2dsZS5jb20+DQpDYzogTWlrZSBCaXNob3AgPE1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb20+ OyBJYW4gU3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb20+OyBxdWljQGlldGYub3JnOyBIdWd1ZXMg RmFmYXJkIDxmYWZhcmRAaW4udHVtLmRlPjsgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb20+DQpT dWJqZWN0OiBSZTogSWRlbnRpZnkgc3RyZWFtcyB1bmlkaXJlY3Rpb25hbCB2cyBiaWRpcmVjdGlv bmFsIGJhc2VkIG9uIHN0cmVhbSBJRA0KDQpJ4oCZbSBqdXN0IHdvbmRlcmluZyB3aHkgdGhpcyBh cHByb2FjaCB3YXMgcHJlZmVycmVkIGFzIG9wcG9zZWQgdG8gYnVpbGRpbmcgYmlkaSBvbiB0b3Ag b2YgdW5pLiBJIHN1cHBvc2UgdGhpcyBtdXN0IGhhdmUgYmVlbiBkaXNjdXNzZWQgYXQgdGhlIGlu dGVyaW0gYW5kIGluIHBhcnQgYmFzZWQgb24gdGhlIHJlY2VudCBleHBlcmltZW50YWwgaW1wbGVt ZW50YXRpb24gb2YgdW5pIHN0cmVhbXMuDQoNCkEgc3RyYWlnaHRmb3J3YXJkIGltcGxlbWVudGF0 aW9uIG1heSBub3QgaGF2ZSBtdWNoIGRpZmZpY3VsdHkgaW4gaGFuZGxpbmcgdGhlIGltcGxlbWVu dGF0aW9uIGVpdGhlciB3YXkgYnV0IHdoZW4geW91IGF0dGVtcHQgdG8gYWNoaWV2ZSBsb3cgbGF0 ZW5jeSBhbmQgbG93IG1lbW9yeSBmb290IHByaW50IHdpdGggc2hvcnRlc3QgcG9zc2libGUgc3Rh dGUgbGlmZSB0aW1lcyBpbmNsdWRpbmcgY29vcmRpbmF0aW9uIHdpdGggYXBwbGljYXRpb24gbGV2 ZWwgYnVmZmVycywgdGhlbiBiaWRpIHN0cmVhbXMgYXJlIG5vdCB2ZXJ5IGZ1biB0byB3b3JrIHdp dGggYXQgdGhlIHRyYW5zcG9ydCBsZXZlbC4gQXMgYmVjb21lIG1vcmUgYWdyZWVhYmxlIGFmdGVy IGl0IHdhcyBjb25jbHVkZWQgdGhhdCB0ZWFyZG93biBkaWQgbm90IGhhdmUgdG8gd2FpdCBmb3Ig RklOIEFDSyBhbmQgcmVsYXRlZCwgYnV0IGl0IGlzIHN0aWxsIGEgbG90IG9mIGNvbXBsZXhpdHkg d2l0aCBwb3RlbnRpYWwgYnVncy4NCg0KT25lIGFzcGVjdCBvZiB0aGUgY29tcGxleGl0eSBpcyB0 aGF0IHRoZXJlIGFyZSBub3cgZm91ciBzcGVjaWFsIGNhc2VzIGluc3RlYWQgb2YgdHdvIGluIHRo ZSBzdHJlYW0gaWRlbnRpZmllcnMgd2hpY2ggbXVzdCBiZSBkZWFsdCB3aXRoIGluIHNldmVyYWwg ZnJhbWUgdHlwZXMuIFNvbWUgb2YgdGhpcyBpbnZvbHZlcyBmbG93IGNvbnRyb2wgcGVyIHN0cmVh bSB0eXBlIHdoaWNoIGJpZGkgb24gdG9wIG9mIHVuaSB3b3VsZCBub3Qgc3VwcG9ydCBhdCB0aGUg c2FtZSBncmFudWxhcml0eSwgYnV0IGlzIHRoaXMgcmVhbGx5IG5lZWRlZD8NCg0KQWRkaW5nIHVu aSBzdHJlYW1zIGluIGFkZGl0aW9uIHRvIGJpZGkgc3RyZWFtcyBpcyBzdGlsbCBhIGxvdCBiZXR0 ZXIgdGhhbiBub3QgaGF2aW5nIHVuaSBzdHJlYW1zIGJlY2F1c2UgdGhleSBzb2x2ZSBwcm9ibGVt cyBzdWNoIGFzIGFzeW5jIG1lc3NhZ2luZyBhdCBoaWdoIHZvbHVtZSBhbmQgcGFydGlhbCByZWxp YWJpbGl0eSB2aWEgdGhyb3cgYXdheSBzdHJlYW1zLiBIb3dldmVyLCB0aGV5IGRvIG5vdGhpbmcg dG8gc2ltcGxpZnkgdGhlIHRyYW5zcG9ydCB3aXRoIHRoZSBjdXJyZW50IHByb3Bvc2FsLg0KDQpL aW5kIFJlZ2FyZHMsDQpNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuDQoNCg0KT24gMTcgT2N0b2Jl ciAyMDE3IGF0IDAyLjQ5LjM4LCBNYXJ0aW4gVGhvbXNvbiAobWFydGluLnRob21zb25AZ21haWwu Y29tPG1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+KSB3cm90ZToNClRob3NlIGxvdyBv cmRlciBiaXRzIGFyZSBpbXBvcnRhbnQuIE5vIG5lZWQgdG8gcnVzaCAoaXQncyBhDQpyZWxhdGl2 ZWx5IHNtYWxsIGNoYW5nZXNldCkuDQoNCk9uIFR1ZSwgT2N0IDE3LCAyMDE3IGF0IDEwOjQ4IEFN LCBKYW5hIEl5ZW5nYXIgPGpyaUBnb29nbGUuY29tPG1haWx0bzpqcmlAZ29vZ2xlLmNvbT4+IHdy b3RlOg0KPiBCYXNlZCBvbiB3aGF0IEknbSBzZWVpbmcgb24gdGhlIFBSIGFuZCBvbiB0aGlzIHRo cmVhZCwgSSB0aGluayB0aGVyZSdzDQo+IGdlbmVyYWwgYWdyZWVtZW50IG9uIHRoaXMgc3RyYXRl Z3kgdG8gZ28gZm9yd2FyZC4gSSB3b3VsZCBsaWtlIHRvIG1lcmdlIHRoaXMNCj4gUFIgc29vbiwg bW9kdWxvIGEgbmV3IHJldmlzaW9uIHRvIGFkZHJlc3Mgc29tZSBvcGVuIGNvbW1lbnRzLiAoVGhl cmUncw0KPiBjdXJyZW50bHkgYSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIHRvIHVzZSB0aGUgaGln aCBvciB0aGUgbG93LW9yZGVyIGJpdHMgZm9yDQo+IHRoaXMsIHdoaWNoIHNob3VsZCBhbHNvIGdl dCByZXNvbHZlZCBiZWZvcmUgbWVyZ2luZy4pDQo+DQo+IEknbSBhc2tpbmcgZm9sa3MgdG8gcGxl YXNlIHJldmlldyBhbmQgc3BlYWsgdXAgaWYgdGhleSBoYXZlIGRpc2FncmVlbWVudHMNCj4gd2l0 aCB0aGUgZGlyZWN0aW9uIG9yIHdpdGggYW55IHNwZWNpZmljcy4NCj4NCj4gSSdsbCBiZSBhd2F5 IGZyb20gY29ubmVjdGl2aXR5IGZvciBhIHdlZWssIHNvIHVubGVzcyB0aGVyZSBhcmUgdW5yZXNv bHZlZA0KPiBpc3N1ZXMgdGhlbiwgSSdkIGxpa2UgdG8gbWVyZ2UgdGhpcyBpbiBhIHdlZWsgd2hl biBJIHJldHVybi4gTWFydGluIGNhbg0KPiBtZXJnZSB0aGlzIHNvb25lciBpZiB0aGVyZSdzIG9u bHkgYWdyZWVtZW50Lg0KPg0KPiBPbiBNb24sIE9jdCAxNiwgMjAxNyBhdCA4OjE1IEFNLCBJYW4g U3dldHQgPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+PiB3 cm90ZToNCj4+DQo+PiBJIGJlbGlldmUgdGhlIG1vdGl2YXRpb24gZm9yIHNlcGFyYXRlIHN0cmVh bSBsaW1pdHMgaXMgdG8gcHV0IGEgcmVhc29uYWJsZQ0KPj4gbGltaXQgb24gdGhlIG51bWJlciBv ZiBpbmNvbWluZyBzdHJlYW1zIHlvdSdsbCBhY2NlcHQuIE90aGVyd2lzZSwgYW4NCj4+IGFwcGxp Y2F0aW9uIGNvdWxkIHVzZSBhIHZlcnkgbGFyZ2UgbnVtYmVyIG9mIG9uZSB0eXBlKGllOiB1bmkp IG9mIHN0cmVhbSBhbmQNCj4+IGFsbW9zdCBub25lIG9mIGFub3RoZXIoaWU6IGJpZGkpLCB3aGlj aCB3b3VsZCBhbGxvdyB0aGVtIHRvIHN1ZGRlbmx5IG9wZW4gYQ0KPj4gaHVnZSBudW1iZXIgb2Yg dGhlIG90aGVyIHR5cGUoaWU6IGJpZGkpIG9mIHN0cmVhbSBpZiB0aGV5IHdhbnRlZC4NCj4+DQo+ PiBJZiB3ZSB3ZXJlIHVzaW5nIEgyIHN0eWxlIG1heCBvcGVuIHN0cmVhbXMgd2UgY291bGQgZG8g aXQgZWl0aGVyIHdheSwgYnV0DQo+PiBJIHRoaW5rIGtlZXBpbmcgdGhlbSBzZXBhcmF0ZSBpcyBw cm9iYWJseSBiZXN0IGFueXdheS4NCj4+DQo+PiBPbiBNb24sIE9jdCAxNiwgMjAxNyBhdCAxMTow MSBBTSwgUm9iZXJ0byBQZW9uIDxmZW5peEBmYi5jb208bWFpbHRvOmZlbml4QGZiLmNvbT4+IHdy b3RlOg0KPj4+DQo+Pj4gSW4gSDIsIHRoZSBldmVuL29kZCB0aGluZyB3YXMganVzdCBhbiBlYXN5 IHdheSB0byBlbmNvZGUgYSB1bmlxdWUgSUQgcGVyDQo+Pj4gc3RyZWFtIHdoaWxlIGluZGljYXRp bmcgZGlyZWN0aW9uLg0KPj4+IFRoaXMgcHJvcG9zYWwgc2VlbXMgdG8gZG8gdGhlIHNhbWUgdGhp bmcsIGFuZCB0aGF0IG1ha2VzIHNlbnNlIHRvDQo+Pj4gbWXigJRpbnN0ZWFkIG9mIGV2ZW4tb2Rk LCB3ZSBoYXZlIG1vZC00LW9mZnNldC4NCj4+Pg0KPj4+IEnigJlkIGFzayB3aHkgYm90aGVyIHRv IGhhdmUgc2VwYXJhdGUgc3RyZWFtIGxpbWl0cy4gWW91IGNvdWxkIHN0aWxsIGp1c3QNCj4+PiBo YXZlIHRoZSBvbmUgbGltaXQgZm9yIHRoZSBvdmVyYWxsIHNwYWNlLg0KPj4+IFdpdGggSDIsIHRo YXQgd2FzIHBhcnQgb2YgdGhlIHBvaW50IG9mIHB1dHRpbmcgaXQgdGhlcmUgKHRob3VnaCBpdCB3 YXMNCj4+PiBpbXBsaXQp4oCUaXQgd2FzIGFsbCBwYXJ0IG9mIG9uZSBzcGFjZSwgYW5kIHRodXMg dGhlIHNwYWNlIHdhcyBzaW5nbHkNCj4+PiBjb3VudGFibGUhDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4g LT1SDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gRnJvbTogUVVJQyA8cXVpYy1ib3VuY2VzQGlldGYub3Jn PG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+PiBvbiBiZWhhbGYgb2YgSWFuIFN3ZXR0DQo+ Pj4gPGlhbnN3ZXR0QGdvb2dsZS5jb208bWFpbHRvOmlhbnN3ZXR0QGdvb2dsZS5jb20+Pg0KPj4+ IERhdGU6IEZyaWRheSwgT2N0b2JlciAxMywgMjAxNyBhdCAyOjA1IFBNDQo+Pj4gVG86IE1pa2Ug QmlzaG9wIDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNoYWVsLkJpc2hv cEBtaWNyb3NvZnQuY29tPj4NCj4+PiBDYzogTWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiA8bWlr a2VsZmpAZ21haWwuY29tPG1haWx0bzptaWtrZWxmakBnbWFpbC5jb20+PiwgInF1aWNAaWV0Zi5v cmc8bWFpbHRvOnF1aWNAaWV0Zi5vcmc+Ig0KPj4+IDxxdWljQGlldGYub3JnPG1haWx0bzpxdWlj QGlldGYub3JnPj4sIEh1Z3VlcyBGYWZhcmQgPGZhZmFyZEBpbi50dW0uZGU8bWFpbHRvOmZhZmFy ZEBpbi50dW0uZGU+Pg0KPj4+DQo+Pj4NCj4+PiBTdWJqZWN0OiBSZTogSWRlbnRpZnkgc3RyZWFt cyB1bmlkaXJlY3Rpb25hbCB2cyBiaWRpcmVjdGlvbmFsIGJhc2VkIG9uDQo+Pj4gc3RyZWFtIElE DQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gSW4gbWFueSB3YXlzLCB0aGV5IGFyZSA0IGluZGVwZW5kZW50 IHNwYWNlcywgYnV0IFJ5YW4gcG9pbnRlZCBvdXQgdG8gbWUNCj4+PiB0aGF0IGJvdGggZm9yIHRo ZSBwdXJwb3NlcyBvZiBkcmFmdCB0ZXh0IGFuZCBpbXBsZW1lbnRhdGlvbiBpdCdzIHZlcnkgdXNl ZnVsDQo+Pj4gdG8gaGF2ZSBhIHNpbmdsZSB1bmlxdWUgaWRlbnRpZmllciBmb3IgYSBzdHJlYW0s IHNpbmNlIG90aGVyd2lzZSB5b3UgaGF2ZSB0bw0KPj4+IHRhbGsgYWJvdXQvcGFzcyBhcm91bmQg KFN0cmVhbUlELCBUeXBlKSBldmVyeXdoZXJlIGluc3RlYWQgb2YganVzdCBTdHJlYW1JRC4NCj4+ Pg0KPj4+DQo+Pj4NCj4+PiBLZWVwaW5nIG9uZSBzdHJlYW0gSUQgYXZvaWRzIGNyZWF0aW5nIHR3 byBvZiBhbGwgdGhlIHN0cmVhbSBzcGVjaWZpYw0KPj4+IGZyYW1lcyhTVE9QX1NFTkRJTkcsIFJT VF9TVFJFQU0sIFNUUkVBTV9GUkFNRSwgTUFYX0RBVEFfT0ZGU0VULCBldGMpLCBvbmUNCj4+PiBm b3IgZWFjaCBzdHJlYW0gc3BhY2UuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gVXNpbmcgdGhlIHR3byBt b3N0IHNpZ25pZmljYW50IGJpdHMgd291bGQgZWxpbWluYXRlIHRoZSB1c2VmdWxuZXNzIG9mIGFu eQ0KPj4+IHZhcmlhYmxlIGxlbmd0aCBpbnRlZ2VyIGVuY29kaW5nKGN1cnJlbnQgb3IgTWFydGlu J3MgbmV3IHByb3Bvc2FsKSwgc28gdXNpbmcNCj4+PiB0aGUgbG93ZXIgYml0cyBtYWtlcyBzZW5z ZS4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBPbiBGcmksIE9jdCAxMywgMjAxNyBhdCA0OjU2IFBNLCBN aWtlIEJpc2hvcA0KPj4+IDxNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPG1haWx0bzpNaWNo YWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tPj4gd3JvdGU6DQo+Pj4NCj4+PiBJbmRlZWQuIEkgYWxt b3N0IHRoaW5rIGl0IG1ha2VzIG1vcmUgc2Vuc2UgdG8gc2F5IHRoYXQgdGhlcmUgYXJlIGZvdXIN Cj4+PiBpbmRlcGVuZGVudCBzdHJlYW0gc3BhY2VzLCBlYWNoIHdpdGggdGhlaXIgb3duIG51bWJl cnMuIFRoYXQgZG9lcyBtZWFuIHRoYXQNCj4+PiBlYWNoIHNpZGUgd2lsbCBuZWVkIHRvIHNlcGFy YXRlbHkgbWFuYWdlIE1heCBTdHJlYW0gSUQgZm9yIHR3byBzcGFjZXMsIGJ1dA0KPj4+IHRoYXQg c2VlbXMgbW9yZSByZWFzb25hYmxlIHRoYW4gdGhlIGFsdGVybmF0aXZlLiBJbiBmYWN0LCB0aGlz IFBSIGFscmVhZHkNCj4+PiBpbXBsaWVzIHRoYXQgdGhlIGxpbWl0cyBmb3IgdW5pZGlyZWN0aW9u YWwgYW5kIGJpZGlyZWN0aW9uYWwgc3RyZWFtcyBhcmUNCj4+PiBoYW5kbGVkIHNlcGFyYXRlbHks IHdoaWNoIGdldHMgcmVhbGx5IHdlaXJkIHdoZW4gdGhlIElEcyBhcmUgaW50ZXJsZWF2ZWQNCj4+ PiB3aXRoIGVhY2ggb3RoZXIuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gSW4gZmFjdCwgdGhpcyBwbGF5 cyB3ZWxsIHdpdGggdGhlIHZhcmlhYmxlLWxlbmd0aCBlbmNvZGluZyBpZGVhLCBzaW5jZQ0KPj4+ IHRoZSBtYXhpbXVtIHNpemUgb2YgYSBTdHJlYW0gSUQgd291bGQgYmUgNjIgYml0cy4gVGhleSBj b3VsZCB0aGVuIGJlIHN0b3JlZA0KPj4+IGxvY2FsbHkgYXMgYSA2NC1iaXQgdmFsdWUgd2l0aCB0 aGUg4oCcZXh0cmHigJ0gYml0cyBpbmRpY2F0aW5nIHdoaWNoIHNwYWNlIHRoZXkNCj4+PiByZWZl ciB0by4NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBGcm9tOiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWlr a2VsIEZhaG7DuGUNCj4+PiBKw7hyZ2Vuc2VuDQo+Pj4gU2VudDogRnJpZGF5LCBPY3RvYmVyIDEz LCAyMDE3IDE6MDQgUE0NCj4+PiBUbzogcXVpY0BpZXRmLm9yZzxtYWlsdG86cXVpY0BpZXRmLm9y Zz47IEh1Z3VlcyBGYWZhcmQgPGZhZmFyZEBpbi50dW0uZGU8bWFpbHRvOmZhZmFyZEBpbi50dW0u ZGU+Pg0KPj4+IFN1YmplY3Q6IFJlOiBJZGVudGlmeSBzdHJlYW1zIHVuaWRpcmVjdGlvbmFsIHZz IGJpZGlyZWN0aW9uYWwgYmFzZWQgb24NCj4+PiBzdHJlYW0gSUQNCj4+Pg0KPj4+DQo+Pj4NCj4+ PiBFc3BlY2lhbGx5IHdpdGggdGhlIG5ldyB2YXJpYWJsZSBsZW5ndGggZW5jb2RpbmcgcHJvcG9z YWwsIHN0b3JpbmcgdGhlDQo+Pj4gaWRlbnRpZmllcnMgZWFybHkgbWFrZXMgc2Vuc2UsIGFzIHlv dSBvbmx5IGhhdmUgdG8gaW5zcGVjdCB0aGUgZmlyc3QgYnl0ZS4NCj4+PiBCdXQgaXQgZ2V0cyBj b21wbGljYXRlZCwgYmVjYXVzZSB5b3UgZG9u4oCZdCB3YW50IHRvIHVzZSA4IGJ5dGVzIGZvciBz b21lDQo+Pj4gc3RyZWFtIHR5cGVzIGFuZCB5b3UgZG9u4oCZdCB3YW50IHRoZSBiaXRzIGF0IHNv bWUgcmFuZG9tIGxvY2F0aW9uIGluIGENCj4+PiBkZWNvZGVkIDggYnl0ZSByZXByZXNlbnRhdGlv biBlaXRoZXIuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gUmVnYXJkbGVzcyBvZiBiaXQgcGxhY2VtZW50 LCBlbmNvZGluZyBzdGF0ZSB1c2luZyBiaXRzIGlzIG5vdCBpZGVhbCB3aGVuDQo+Pj4gY29uc2lk ZXJpbmcgdmFyaWFibGUgbGVuZ3RoIGVuY29kaW5nIGJlY2F1c2UgeW91IG5vdyB1c2UgdHdvIGJp dHMgZm9yIGxlbmd0aA0KPj4+IGFuZCB0d28gYml0cyBmb3Igc3RyZWFtIHR5cGUsIGxlYXZpbmcg b25seSAxNiBkaWZmZXJlbnQgc3RyZWFtcyBiZWZvcmUgdGhlDQo+Pj4gc3RyZWFtIGlkZW50aWZp ZXIgbmVlZHMgdG8gdXNlIHR3byBieXRlcywgYW5kIHNvIGZvcnRoLg0KPj4+DQo+Pj4NCj4+Pg0K Pj4+DQo+Pj4NCj4+PiBLaW5kIFJlZ2FyZHMsDQo+Pj4NCj4+PiBNaWtrZWwgRmFobsO4ZSBKw7hy Z2Vuc2VuDQo+Pj4NCj4+Pg0KPj4+DQo+Pj4gT24gMTMgT2N0b2JlciAyMDE3IGF0IDIxLjUwLjA2 LCBIdWd1ZXMgRmFmYXJkIChmYWZhcmRAaW4udHVtLmRlPG1haWx0bzpmYWZhcmRAaW4udHVtLmRl Pikgd3JvdGU6DQo+Pj4NCj4+PiBJIHNlZSwgeW91IHVzZWQgdGhlIDIgbGVhc3Qgc2lnbmlmaWNh bnQgYml0cyB0byBlbmNvZGUgdGhhdA0KPj4+IGluZm9ybWF0aW9uLiBXaGVuIG9ubHkgdXNpbmcg b25lIGJpdCB0byBpbmRpY2F0ZSB0aGUgZGlyZWN0aW9uLCBpdA0KPj4+IGJvaWxlZCBkb3duIHRv IG9kZC9ldmVuIHdoaWNoIG1vcmUgb3IgbGVzcyBtYWRlIHNlbnNlLCBidXQgd2hlbiB1c2luZw0K Pj4+IDIgYml0cyB0aGF0IGJyZWFrcyBhcGFydC4NCj4+Pg0KPj4+IFdoeSBub3QgdXNlIHRoZSBt b3N0IHNpZ25pZmljYW50IGJpdHMgaW5zdGVhZD8gVGhhdCB3YXksIGdldHRpbmcgdGhlDQo+Pj4g J2NsZWFuJyBzdHJlYW0gSUQgd2l0aG91dCB0aGUgZmxhZ3Mgd291bGQgYmUgYXMgc2ltcGxlIGRv aW5nIGEgYCYNCj4+PiAweDNGLi4uRkZgIGluc3RlYWQgb2YgYml0LXNoaWZ0aW5nIHRoaW5ncyBh cm91bmQuIFNpbWlsYXJseSwgZW5jb2RpbmcNCj4+PiB0aGUgc3RyZWFtIElEIHdvdWxkIGp1c3Qg ZW50YWlsIGB8IDB4PzAuLi4wMGAgdG8gc2V0IHRoZSBhcHByb3ByaWF0ZQ0KPj4+IGJpdHMgYW5k IGFsc28gYXZvaWQgYml0LXNoaWZ0cy4NCj4+Pg0KPj4+IFJlZ2FyZHMsDQo+Pj4gSHVndWVzDQo+ Pj4NCj4+PiBPbiAyMDE3LTEwLTEzIDIwOjUxLCBSeWFuIEhhbWlsdG9uIHdyb3RlOg0KPj4+ID4g QXMgSSB1bmRlcnN0YW5kIHRoZSBkaXNjdXNzaW9ucyBhdCB0aGUgaW50ZXJpbSwgd2UndmUgZGVj aWRlZCB0bw0KPj4+ID4gYWxsb3cgc3RyZWFtcyB0byBiZSB1bmlkaXJlY3Rpb25hbCBvciBiaWRp cmVjdGlvbmFsLiBJIHN1cHBvcnQgdGhpcw0KPj4+ID4gaWRlYSBhbmQgd2FzIG1vdGl2YXRlZCB0 byB3cml0ZSB1cCBhbiBpZGVhIEkndmUgYmVlbiB0aGlua2luZyBhYm91dA0KPj4+ID4gZm9yIGEg d2hpbGUuIEluIHRoZSBzYW1lIHdheSB0aGF0IHdlIHVzZSBhIGJpdCBpbiB0aGUgc3RyZWFtIElE IHRvDQo+Pj4gPiBpZGVudGlmeSB0aGUgY2xpZW50IHZzIHNlcnZlciBuYXR1cmUgb2YgdGhlIHN0 cmVhbSwgd2UgY2FuIHVzZSBhDQo+Pj4gPiBiaXQgdG8gaWRlbnRpZnkgdGhlIGRpcmVjdGlvbmFs aXR5LiBUaGlzIGRpdmlkZXMgdGhlIHN0cmVhbSBJRA0KPj4+ID4gc3BhY2UgbmVhdGx5IGludG8g NCBkaXN0aW5jdCBzcGFjZXMgKG11Y2ggbGlrZSB0aGUgMiB0d28gd2UgaGF2ZQ0KPj4+ID4gdG9k YXk6IGNsaWVudC9zZXJ2ZXIpLiBJbiBhZGRpdGlvbiB0aGlzIG1lYW5zIHRoYXQgYSBzdHJlYW0g SUQNCj4+PiA+IGFsd2F5cyB1bmlxdWVseSBpZGVudGlmaWVzIGEgc2luZ2xlIHN0cmVhbSwgYW5k IGZyYW1lcyB3aGljaA0KPj4+ID4gbWVudGlvbiBzdHJlYW0gSUQgKFNUUkVBTSwgTUFYX1NUUkVB TV9JRCwgTUFYX1NUUkVBTV9EQVRBLA0KPj4+ID4gUlNUX1NUUkVBTSwgZXRjKSBkbyBub3QgbmVl ZCB0byBleHBsaWNpdGx5IGNvbnZleSB0aGUNCj4+PiA+IGRpcmVjdGlvbmFsaXR5IGFzIGZpZWxk cyBpbiB0aG9zZSBmcmFtZXMgKG9yIGltcGxpY2l0bHkgYmFzZWQgb24NCj4+PiA+IHRoZSBkaXJl Y3Rpb25hbGl0eSBvZiB0aGUgZnJhbWVzIHRoZW1zZWx2ZXMpLg0KPj4+ID4NCj4+PiA+IGh0dHBz Oi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC84NzI8aHR0cHM6Ly9uYTAxLnNh ZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxvb2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIu Y29tJTJGcXVpY3dnJTJGYmFzZS1kcmFmdHMlMkZwdWxsJTJGODcyJmRhdGE9MDIlN0MwMSU3Q3By YXZiJTQwbWljcm9zb2Z0LmNvbSU3QzdmZDIwMTNjNjk0OTRlOGQyMDJhMDhkNTE0ZmQzMjZlJTdD NzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYzNjQzODAwMDA3MzMw MDg0OSZzZGF0YT1vdThRYXVrbjZHZ0lhMGJzV1BWQ1dyVExrdXROYVc4NVRIVVFmakxkdXlzJTNE JnJlc2VydmVkPTA+DQo+Pj4gPg0KPj4+ID4gQ2hlZXJzLA0KPj4+ID4NCj4+PiA+IFJ5YW4NCj4+ Pg0KPj4+DQo+Pg0KPj4NCj4NCg== --_000_MWHPR21MB0288008D1302D533FB07C6DFB64C0MWHPR21MB0288namp_ 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 emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnAuYWlybWFp bG9uLCBsaS5haXJtYWlsb24sIGRpdi5haXJtYWlsb24NCgl7bXNvLXN0eWxlLW5hbWU6YWlybWFp bF9vbjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6 MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxT dHlsZTE5DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQN Cgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFn ZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGlu IDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdy ZWUgdGhhdCB0aGlzIGlzIGFkZGluZyBjb21wbGV4aXR5IHdpdGggZm91ciBzcGVjaWFsIGNhc2Vz LCBidXQgSSB3b3VsZCBhY3R1YWxseSBhcmd1ZSB0aGUgb3RoZXIgd2F5OiBhcHBzIHRoYXQgd2Fu dCB1bmkgc3RyZWFtcyBzaG91bGQgYmUgYWJsZSB0byB1c2UgdGhlIGV4aXN0aW5nIGJpZGkgc3Ry ZWFtIG1lY2hhbmlzbS4gQW4gQVBJIGZvciB1bmkgc3RyZWFtIGNhbiBhY2hpZXZlIHRoaXMgYnkg Y2xvc2luZw0KIHRoZSBzdHJlYW0gaW4gb25lIGRpcmVjdGlvbiBpbW1lZGlhdGVseSBhZnRlciBv cGVuaW5nIGl0IHNvIHRoYXQgdGhlIHZlcnkgZmlyc3QgcGFja2V0IGZvciB0aGF0IHN0cmVhbSBz aWduYWxzIHRoYXQgb25lIGRpcmVjdGlvbiBpcyBjbG9zZWQgYW5kIHRoZSBvdGhlciBlbmQga25v d3MgdGhhdCB0aGUgc3RyZWFtIGlzIHVuaS4gQmlkaSBzdHJlYW1zIGFyZSBhIG1vcmUgZ2VuZXJh bCBjYXNlIGFuZCBpZiB3ZSBhcmUgZ29pbmcgdG8gc3VwcG9ydA0KIHRoZW0gKHdoaWNoIEkgdGhp bmsgd2Ugc2hvdWxkKSB0aGVuIGRvIHdlIG5lZWQgYW55IGRlZGljYXRlZCB0cmFuc3BvcnQgbWVj aGFuaXNtcyBmb3IgdW5pIHN0cmVhbXM/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtz PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUx RTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+T24g QmVoYWxmIE9mDQo8L2I+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxicj4NCjxiPlNlbnQ6PC9i PiBNb25kYXksIE9jdG9iZXIgMTYsIDIwMTcgNjoyMCBQTTxicj4NCjxiPlRvOjwvYj4gTWFydGlu IFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDs7IEphbmEgSXllbmdhciAm bHQ7anJpQGdvb2dsZS5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBNaWtlIEJpc2hvcCAmbHQ7TWlj aGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbSZndDs7IElhbiBTd2V0dCAmbHQ7aWFuc3dldHRAZ29v Z2xlLmNvbSZndDs7IHF1aWNAaWV0Zi5vcmc7IEh1Z3VlcyBGYWZhcmQgJmx0O2ZhZmFyZEBpbi50 dW0uZGUmZ3Q7OyBSb2JlcnRvIFBlb24gJmx0O2Zlbml4QGZiLmNvbSZndDs8YnI+DQo8Yj5TdWJq ZWN0OjwvYj4gUmU6IElkZW50aWZ5IHN0cmVhbXMgdW5pZGlyZWN0aW9uYWwgdnMgYmlkaXJlY3Rp b25hbCBiYXNlZCBvbiBzdHJlYW0gSUQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYgaWQ9ImJsb29w X2N1c3RvbWZvbnQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkni gJltIGp1c3Qgd29uZGVyaW5nIHdoeSB0aGlzIGFwcHJvYWNoIHdhcyBwcmVmZXJyZWQgYXMgb3Bw b3NlZCB0byBidWlsZGluZyBiaWRpIG9uIHRvcCBvZiB1bmkuIEkgc3VwcG9zZSB0aGlzIG11c3Qg aGF2ZSBiZWVuIGRpc2N1c3NlZCBhdCB0aGUgaW50ZXJpbSBhbmQgaW4gcGFydCBiYXNlZCBvbg0K IHRoZSByZWNlbnQgZXhwZXJpbWVudGFsIGltcGxlbWVudGF0aW9uIG9mIHVuaSBzdHJlYW1zLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BIHN0cmFpZ2h0Zm9yd2Fy ZCBpbXBsZW1lbnRhdGlvbiBtYXkgbm90IGhhdmUgbXVjaCBkaWZmaWN1bHR5IGluIGhhbmRsaW5n IHRoZSBpbXBsZW1lbnRhdGlvbiBlaXRoZXIgd2F5IGJ1dCB3aGVuIHlvdSBhdHRlbXB0IHRvIGFj aGlldmUgbG93IGxhdGVuY3kgYW5kIGxvdyBtZW1vcnkgZm9vdCBwcmludA0KIHdpdGggc2hvcnRl c3QgcG9zc2libGUgc3RhdGUgbGlmZSB0aW1lcyBpbmNsdWRpbmcgY29vcmRpbmF0aW9uIHdpdGgg YXBwbGljYXRpb24gbGV2ZWwgYnVmZmVycywgdGhlbiBiaWRpIHN0cmVhbXMgYXJlIG5vdCB2ZXJ5 IGZ1biB0byB3b3JrIHdpdGggYXQgdGhlIHRyYW5zcG9ydCBsZXZlbC4gQXMgYmVjb21lIG1vcmUg YWdyZWVhYmxlIGFmdGVyIGl0IHdhcyBjb25jbHVkZWQgdGhhdCB0ZWFyZG93biBkaWQgbm90IGhh dmUgdG8gd2FpdCBmb3IgRklODQogQUNLIGFuZCByZWxhdGVkLCBidXQgaXQgaXMgc3RpbGwgYSBs b3Qgb2YgY29tcGxleGl0eSB3aXRoIHBvdGVudGlhbCBidWdzLjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uZSBhc3BlY3Qgb2YgdGhlIGNvbXBsZXhpdHkgaXMgdGhh dCB0aGVyZSBhcmUgbm93IGZvdXIgc3BlY2lhbCBjYXNlcyBpbnN0ZWFkIG9mIHR3byBpbiB0aGUg c3RyZWFtIGlkZW50aWZpZXJzIHdoaWNoIG11c3QgYmUgZGVhbHQgd2l0aCBpbiBzZXZlcmFsIGZy YW1lIHR5cGVzLiBTb21lIG9mIHRoaXMNCiBpbnZvbHZlcyBmbG93IGNvbnRyb2wgcGVyIHN0cmVh bSB0eXBlIHdoaWNoIGJpZGkgb24gdG9wIG9mIHVuaSB3b3VsZCBub3Qgc3VwcG9ydCBhdCB0aGUg c2FtZSBncmFudWxhcml0eSwgYnV0IGlzIHRoaXMgcmVhbGx5IG5lZWRlZD88bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5BZGRpbmcgdW5pIHN0cmVhbXMgaW4gYWRkaXRp b24gdG8gYmlkaSBzdHJlYW1zIGlzIHN0aWxsIGEgbG90IGJldHRlciB0aGFuIG5vdCBoYXZpbmcg dW5pIHN0cmVhbXMgYmVjYXVzZSB0aGV5IHNvbHZlIHByb2JsZW1zIHN1Y2ggYXMgYXN5bmMgbWVz c2FnaW5nIGF0IGhpZ2ggdm9sdW1lIGFuZCBwYXJ0aWFsDQogcmVsaWFiaWxpdHkgdmlhIHRocm93 IGF3YXkgc3RyZWFtcy4gSG93ZXZlciwgdGhleSBkbyBub3RoaW5nIHRvIHNpbXBsaWZ5IHRoZSB0 cmFuc3BvcnQgd2l0aCB0aGUgY3VycmVudCBwcm9wb3NhbC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgaWQ9ImJsb29wX3NpZ25fMTUwODIwMjU1NzU4NDU3 NjI1NiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPktp bmQgUmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5NaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iYWlybWFpbG9uIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+T24gMTcgT2N0b2JlciAyMDE3IGF0IDAyLjQ5LjM4LCBNYXJ0aW4gVGhvbXNvbiAo PC9zcGFuPjxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90Oyxz YW5zLXNlcmlmIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj4pDQogd3JvdGU6PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5 bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaG9zZSBsb3cgb3JkZXIg Yml0cyBhcmUgaW1wb3J0YW50LiBObyBuZWVkIHRvIHJ1c2ggKGl0J3MgYQ0KPGJyPg0KcmVsYXRp dmVseSBzbWFsbCBjaGFuZ2VzZXQpLiA8YnI+DQo8YnI+DQpPbiBUdWUsIE9jdCAxNywgMjAxNyBh dCAxMDo0OCBBTSwgSmFuYSBJeWVuZ2FyICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmpyaUBn b29nbGUuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+anJpQGdvb2dsZS5jb208L3NwYW4+PC9hPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7IHdyb3RlOg0KPGJyPg0KJmd0OyBCYXNlZCBvbiB3aGF0IEkn bSBzZWVpbmcgb24gdGhlIFBSIGFuZCBvbiB0aGlzIHRocmVhZCwgSSB0aGluayB0aGVyZSdzIDxi cj4NCiZndDsgZ2VuZXJhbCBhZ3JlZW1lbnQgb24gdGhpcyBzdHJhdGVneSB0byBnbyBmb3J3YXJk LiBJIHdvdWxkIGxpa2UgdG8gbWVyZ2UgdGhpcyA8YnI+DQomZ3Q7IFBSIHNvb24sIG1vZHVsbyBh IG5ldyByZXZpc2lvbiB0byBhZGRyZXNzIHNvbWUgb3BlbiBjb21tZW50cy4gKFRoZXJlJ3MgPGJy Pg0KJmd0OyBjdXJyZW50bHkgYSBxdWVzdGlvbiBhYm91dCB3aGV0aGVyIHRvIHVzZSB0aGUgaGln aCBvciB0aGUgbG93LW9yZGVyIGJpdHMgZm9yIDxicj4NCiZndDsgdGhpcywgd2hpY2ggc2hvdWxk IGFsc28gZ2V0IHJlc29sdmVkIGJlZm9yZSBtZXJnaW5nLikgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEknbSBhc2tpbmcgZm9sa3MgdG8gcGxlYXNlIHJldmlldyBhbmQgc3BlYWsgdXAgaWYgdGhleSBo YXZlIGRpc2FncmVlbWVudHMgPGJyPg0KJmd0OyB3aXRoIHRoZSBkaXJlY3Rpb24gb3Igd2l0aCBh bnkgc3BlY2lmaWNzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSdsbCBiZSBhd2F5IGZyb20gY29u bmVjdGl2aXR5IGZvciBhIHdlZWssIHNvIHVubGVzcyB0aGVyZSBhcmUgdW5yZXNvbHZlZCA8YnI+ DQomZ3Q7IGlzc3VlcyB0aGVuLCBJJ2QgbGlrZSB0byBtZXJnZSB0aGlzIGluIGEgd2VlayB3aGVu IEkgcmV0dXJuLiBNYXJ0aW4gY2FuIDxicj4NCiZndDsgbWVyZ2UgdGhpcyBzb29uZXIgaWYgdGhl cmUncyBvbmx5IGFncmVlbWVudC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIE1vbiwgT2N0IDE2 LCAyMDE3IGF0IDg6MTUgQU0sIElhbiBTd2V0dCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpp YW5zd2V0dEBnb29nbGUuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+aWFuc3dldHRAZ29vZ2xlLmNv bTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgd3JvdGU6DQo8YnI+DQomZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyBJIGJlbGlldmUgdGhlIG1vdGl2YXRpb24gZm9yIHNlcGFyYXRlIHN0 cmVhbSBsaW1pdHMgaXMgdG8gcHV0IGEgcmVhc29uYWJsZSA8YnI+DQomZ3Q7Jmd0OyBsaW1pdCBv biB0aGUgbnVtYmVyIG9mIGluY29taW5nIHN0cmVhbXMgeW91J2xsIGFjY2VwdC4gT3RoZXJ3aXNl LCBhbiA8YnI+DQomZ3Q7Jmd0OyBhcHBsaWNhdGlvbiBjb3VsZCB1c2UgYSB2ZXJ5IGxhcmdlIG51 bWJlciBvZiBvbmUgdHlwZShpZTogdW5pKSBvZiBzdHJlYW0gYW5kIDxicj4NCiZndDsmZ3Q7IGFs bW9zdCBub25lIG9mIGFub3RoZXIoaWU6IGJpZGkpLCB3aGljaCB3b3VsZCBhbGxvdyB0aGVtIHRv IHN1ZGRlbmx5IG9wZW4gYSA8YnI+DQomZ3Q7Jmd0OyBodWdlIG51bWJlciBvZiB0aGUgb3RoZXIg dHlwZShpZTogYmlkaSkgb2Ygc3RyZWFtIGlmIHRoZXkgd2FudGVkLiA8YnI+DQomZ3Q7Jmd0OyA8 YnI+DQomZ3Q7Jmd0OyBJZiB3ZSB3ZXJlIHVzaW5nIEgyIHN0eWxlIG1heCBvcGVuIHN0cmVhbXMg d2UgY291bGQgZG8gaXQgZWl0aGVyIHdheSwgYnV0IDxicj4NCiZndDsmZ3Q7IEkgdGhpbmsga2Vl cGluZyB0aGVtIHNlcGFyYXRlIGlzIHByb2JhYmx5IGJlc3QgYW55d2F5LiA8YnI+DQomZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyBPbiBNb24sIE9jdCAxNiwgMjAxNyBhdCAxMTowMSBBTSwgUm9iZXJ0 byBQZW9uICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmZlbml4QGZiLmNvbSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPmZlbml4QGZiLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsg d3JvdGU6DQo8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEluIEgyLCB0aGUg ZXZlbi9vZGQgdGhpbmcgd2FzIGp1c3QgYW4gZWFzeSB3YXkgdG8gZW5jb2RlIGEgdW5pcXVlIElE IHBlciA8YnI+DQomZ3Q7Jmd0OyZndDsgc3RyZWFtIHdoaWxlIGluZGljYXRpbmcgZGlyZWN0aW9u LiA8YnI+DQomZ3Q7Jmd0OyZndDsgVGhpcyBwcm9wb3NhbCBzZWVtcyB0byBkbyB0aGUgc2FtZSB0 aGluZywgYW5kIHRoYXQgbWFrZXMgc2Vuc2UgdG8gPGJyPg0KJmd0OyZndDsmZ3Q7IG1l4oCUaW5z dGVhZCBvZiBldmVuLW9kZCwgd2UgaGF2ZSBtb2QtNC1vZmZzZXQuIDxicj4NCiZndDsmZ3Q7Jmd0 OyA8YnI+DQomZ3Q7Jmd0OyZndDsgSeKAmWQgYXNrIHdoeSBib3RoZXIgdG8gaGF2ZSBzZXBhcmF0 ZSBzdHJlYW0gbGltaXRzLiBZb3UgY291bGQgc3RpbGwganVzdCA8YnI+DQomZ3Q7Jmd0OyZndDsg aGF2ZSB0aGUgb25lIGxpbWl0IGZvciB0aGUgb3ZlcmFsbCBzcGFjZS4gPGJyPg0KJmd0OyZndDsm Z3Q7IFdpdGggSDIsIHRoYXQgd2FzIHBhcnQgb2YgdGhlIHBvaW50IG9mIHB1dHRpbmcgaXQgdGhl cmUgKHRob3VnaCBpdCB3YXMgPGJyPg0KJmd0OyZndDsmZ3Q7IGltcGxpdCnigJRpdCB3YXMgYWxs IHBhcnQgb2Ygb25lIHNwYWNlLCBhbmQgdGh1cyB0aGUgc3BhY2Ugd2FzIHNpbmdseSA8YnI+DQom Z3Q7Jmd0OyZndDsgY291bnRhYmxlISA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgLT1SIDxicj4NCiZndDsm Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7Jmd0OyBGcm9tOiBRVUlDICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNl c0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnF1aWMtYm91bmNlc0BpZXRmLm9yZzwvc3Bh bj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgb24gYmVoYWxmIG9mIElhbiBTd2V0dA0KPGJy Pg0KJmd0OyZndDsmZ3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmlhbnN3ZXR0QGdvb2ds ZS5jb20iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5pYW5zd2V0dEBnb29nbGUuY29tPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KPGJyPg0KJmd0OyZndDsmZ3Q7IERhdGU6IEZyaWRheSwg T2N0b2JlciAxMywgMjAxNyBhdCAyOjA1IFBNIDxicj4NCiZndDsmZ3Q7Jmd0OyBUbzogTWlrZSBC aXNob3AgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0 LmNvbSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk1pY2hhZWwuQmlzaG9wQG1pY3Jvc29mdC5jb208L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7DQo8YnI+DQomZ3Q7Jmd0OyZndDsgQ2M6IE1p a2tlbCBGYWhuw7hlIErDuHJnZW5zZW4gJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86bWlra2Vs ZmpAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+bWlra2VsZmpAZ21haWwuY29tPC9zcGFu PjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OywgJnF1b3Q7PC9zcGFuPjxhIGhyZWY9Im1haWx0 bzpxdWljQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+cXVpY0BpZXRmLm9yZzwvc3Bhbj48 L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZxdW90Ow0KPGJyPg0KJmd0OyZndDsmZ3Q7ICZsdDs8L3Nw YW4+PGEgaHJlZj0ibWFpbHRvOnF1aWNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5xdWlj QGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OywgSHVndWVzIEZhZmFy ZCAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpmYWZhcmRAaW4udHVtLmRlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+ZmFmYXJkQGluLnR1bS5kZTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsNCjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7IFN1YmplY3Q6IFJlOiBJZGVudGlmeSBzdHJlYW1zIHVuaWRpcmVjdGlvbmFsIHZzIGJpZGly ZWN0aW9uYWwgYmFzZWQgb24gPGJyPg0KJmd0OyZndDsmZ3Q7IHN0cmVhbSBJRCA8YnI+DQomZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyZndDsgSW4gbWFueSB3YXlzLCB0aGV5IGFyZSA0IGluZGVwZW5kZW50IHNwYWNlcywgYnV0 IFJ5YW4gcG9pbnRlZCBvdXQgdG8gbWUgPGJyPg0KJmd0OyZndDsmZ3Q7IHRoYXQgYm90aCBmb3Ig dGhlIHB1cnBvc2VzIG9mIGRyYWZ0IHRleHQgYW5kIGltcGxlbWVudGF0aW9uIGl0J3MgdmVyeSB1 c2VmdWwgPGJyPg0KJmd0OyZndDsmZ3Q7IHRvIGhhdmUgYSBzaW5nbGUgdW5pcXVlIGlkZW50aWZp ZXIgZm9yIGEgc3RyZWFtLCBzaW5jZSBvdGhlcndpc2UgeW91IGhhdmUgdG8gPGJyPg0KJmd0OyZn dDsmZ3Q7IHRhbGsgYWJvdXQvcGFzcyBhcm91bmQgKFN0cmVhbUlELCBUeXBlKSBldmVyeXdoZXJl IGluc3RlYWQgb2YganVzdCBTdHJlYW1JRC4gPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsm Z3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEtlZXBpbmcgb25l IHN0cmVhbSBJRCBhdm9pZHMgY3JlYXRpbmcgdHdvIG9mIGFsbCB0aGUgc3RyZWFtIHNwZWNpZmlj IDxicj4NCiZndDsmZ3Q7Jmd0OyBmcmFtZXMoU1RPUF9TRU5ESU5HLCBSU1RfU1RSRUFNLCBTVFJF QU1fRlJBTUUsIE1BWF9EQVRBX09GRlNFVCwgZXRjKSwgb25lIDxicj4NCiZndDsmZ3Q7Jmd0OyBm b3IgZWFjaCBzdHJlYW0gc3BhY2UuIDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn dDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBVc2luZyB0aGUgdHdvIG1v c3Qgc2lnbmlmaWNhbnQgYml0cyB3b3VsZCBlbGltaW5hdGUgdGhlIHVzZWZ1bG5lc3Mgb2YgYW55 IDxicj4NCiZndDsmZ3Q7Jmd0OyB2YXJpYWJsZSBsZW5ndGggaW50ZWdlciBlbmNvZGluZyhjdXJy ZW50IG9yIE1hcnRpbidzIG5ldyBwcm9wb3NhbCksIHNvIHVzaW5nIDxicj4NCiZndDsmZ3Q7Jmd0 OyB0aGUgbG93ZXIgYml0cyBtYWtlcyBzZW5zZS4gPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IE9uIEZyaSwg T2N0IDEzLCAyMDE3IGF0IDQ6NTYgUE0sIE1pa2UgQmlzaG9wIDxicj4NCiZndDsmZ3Q7Jmd0OyAm bHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpNaWNoYWVsLkJpc2hvcEBtaWNyb3NvZnQuY29tIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+TWljaGFlbC5CaXNob3BAbWljcm9zb2Z0LmNvbTwvc3Bhbj48L2E+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgd3JvdGU6DQo8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7IEluZGVlZC4gSSBhbG1vc3QgdGhpbmsgaXQgbWFrZXMgbW9yZSBzZW5zZSB0 byBzYXkgdGhhdCB0aGVyZSBhcmUgZm91ciA8YnI+DQomZ3Q7Jmd0OyZndDsgaW5kZXBlbmRlbnQg c3RyZWFtIHNwYWNlcywgZWFjaCB3aXRoIHRoZWlyIG93biBudW1iZXJzLiBUaGF0IGRvZXMgbWVh biB0aGF0IDxicj4NCiZndDsmZ3Q7Jmd0OyBlYWNoIHNpZGUgd2lsbCBuZWVkIHRvIHNlcGFyYXRl bHkgbWFuYWdlIE1heCBTdHJlYW0gSUQgZm9yIHR3byBzcGFjZXMsIGJ1dCA8YnI+DQomZ3Q7Jmd0 OyZndDsgdGhhdCBzZWVtcyBtb3JlIHJlYXNvbmFibGUgdGhhbiB0aGUgYWx0ZXJuYXRpdmUuIElu IGZhY3QsIHRoaXMgUFIgYWxyZWFkeSA8YnI+DQomZ3Q7Jmd0OyZndDsgaW1wbGllcyB0aGF0IHRo ZSBsaW1pdHMgZm9yIHVuaWRpcmVjdGlvbmFsIGFuZCBiaWRpcmVjdGlvbmFsIHN0cmVhbXMgYXJl IDxicj4NCiZndDsmZ3Q7Jmd0OyBoYW5kbGVkIHNlcGFyYXRlbHksIHdoaWNoIGdldHMgcmVhbGx5 IHdlaXJkIHdoZW4gdGhlIElEcyBhcmUgaW50ZXJsZWF2ZWQgPGJyPg0KJmd0OyZndDsmZ3Q7IHdp dGggZWFjaCBvdGhlci4gPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+ DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEluIGZhY3QsIHRoaXMgcGxheXMgd2Vs bCB3aXRoIHRoZSB2YXJpYWJsZS1sZW5ndGggZW5jb2RpbmcgaWRlYSwgc2luY2UgPGJyPg0KJmd0 OyZndDsmZ3Q7IHRoZSBtYXhpbXVtIHNpemUgb2YgYSBTdHJlYW0gSUQgd291bGQgYmUgNjIgYml0 cy4gVGhleSBjb3VsZCB0aGVuIGJlIHN0b3JlZCA8YnI+DQomZ3Q7Jmd0OyZndDsgbG9jYWxseSBh cyBhIDY0LWJpdCB2YWx1ZSB3aXRoIHRoZSDigJxleHRyYeKAnSBiaXRzIGluZGljYXRpbmcgd2hp Y2ggc3BhY2UgdGhleSA8YnI+DQomZ3Q7Jmd0OyZndDsgcmVmZXIgdG8uIDxicj4NCiZndDsmZ3Q7 Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7 Jmd0OyBGcm9tOiBRVUlDIFttYWlsdG86PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5xdWljLWJvdW5jZXNAaWV0Zi5vcmc8L3Nw YW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5dIE9uIEJlaGFsZiBPZiBNaWtrZWwgRmFobsO4ZQ0K PGJyPg0KJmd0OyZndDsmZ3Q7IErDuHJnZW5zZW4gPGJyPg0KJmd0OyZndDsmZ3Q7IFNlbnQ6IEZy aWRheSwgT2N0b2JlciAxMywgMjAxNyAxOjA0IFBNIDxicj4NCiZndDsmZ3Q7Jmd0OyBUbzogPC9z cGFuPjxhIGhyZWY9Im1haWx0bzpxdWljQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+cXVp Y0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjsgSHVndWVzIEZhZmFyZCAm bHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpmYWZhcmRAaW4udHVtLmRlIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1z ZXJpZiI+ZmFmYXJkQGluLnR1bS5kZTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsN Cjxicj4NCiZndDsmZ3Q7Jmd0OyBTdWJqZWN0OiBSZTogSWRlbnRpZnkgc3RyZWFtcyB1bmlkaXJl Y3Rpb25hbCB2cyBiaWRpcmVjdGlvbmFsIGJhc2VkIG9uIDxicj4NCiZndDsmZ3Q7Jmd0OyBzdHJl YW0gSUQgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0 OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IEVzcGVjaWFsbHkgd2l0aCB0aGUgbmV3IHZhcmlhYmxl IGxlbmd0aCBlbmNvZGluZyBwcm9wb3NhbCwgc3RvcmluZyB0aGUgPGJyPg0KJmd0OyZndDsmZ3Q7 IGlkZW50aWZpZXJzIGVhcmx5IG1ha2VzIHNlbnNlLCBhcyB5b3Ugb25seSBoYXZlIHRvIGluc3Bl Y3QgdGhlIGZpcnN0IGJ5dGUuIDxicj4NCiZndDsmZ3Q7Jmd0OyBCdXQgaXQgZ2V0cyBjb21wbGlj YXRlZCwgYmVjYXVzZSB5b3UgZG9u4oCZdCB3YW50IHRvIHVzZSA4IGJ5dGVzIGZvciBzb21lIDxi cj4NCiZndDsmZ3Q7Jmd0OyBzdHJlYW0gdHlwZXMgYW5kIHlvdSBkb27igJl0IHdhbnQgdGhlIGJp dHMgYXQgc29tZSByYW5kb20gbG9jYXRpb24gaW4gYSA8YnI+DQomZ3Q7Jmd0OyZndDsgZGVjb2Rl ZCA4IGJ5dGUgcmVwcmVzZW50YXRpb24gZWl0aGVyLiA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0K Jmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgUmVnYXJk bGVzcyBvZiBiaXQgcGxhY2VtZW50LCBlbmNvZGluZyBzdGF0ZSB1c2luZyBiaXRzIGlzIG5vdCBp ZGVhbCB3aGVuIDxicj4NCiZndDsmZ3Q7Jmd0OyBjb25zaWRlcmluZyB2YXJpYWJsZSBsZW5ndGgg ZW5jb2RpbmcgYmVjYXVzZSB5b3Ugbm93IHVzZSB0d28gYml0cyBmb3IgbGVuZ3RoIDxicj4NCiZn dDsmZ3Q7Jmd0OyBhbmQgdHdvIGJpdHMgZm9yIHN0cmVhbSB0eXBlLCBsZWF2aW5nIG9ubHkgMTYg ZGlmZmVyZW50IHN0cmVhbXMgYmVmb3JlIHRoZSA8YnI+DQomZ3Q7Jmd0OyZndDsgc3RyZWFtIGlk ZW50aWZpZXIgbmVlZHMgdG8gdXNlIHR3byBieXRlcywgYW5kIHNvIGZvcnRoLiA8YnI+DQomZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7 Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBLaW5kIFJlZ2Fy ZHMsIDxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgTWlra2VsIEZhaG7DuGUg SsO4cmdlbnNlbiA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgT24gMTMgT2N0b2JlciAyMDE3IGF0IDIxLjUw LjA2LCBIdWd1ZXMgRmFmYXJkICg8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmZhZmFyZEBpbi50dW0u ZGUiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj5mYWZhcmRAaW4udHVtLmRlPC9zcGFuPjwvYT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+KSB3cm90ZToNCjxicj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZn dDsgSSBzZWUsIHlvdSB1c2VkIHRoZSAyIGxlYXN0IHNpZ25pZmljYW50IGJpdHMgdG8gZW5jb2Rl IHRoYXQgPGJyPg0KJmd0OyZndDsmZ3Q7IGluZm9ybWF0aW9uLiBXaGVuIG9ubHkgdXNpbmcgb25l IGJpdCB0byBpbmRpY2F0ZSB0aGUgZGlyZWN0aW9uLCBpdCA8YnI+DQomZ3Q7Jmd0OyZndDsgYm9p bGVkIGRvd24gdG8gb2RkL2V2ZW4gd2hpY2ggbW9yZSBvciBsZXNzIG1hZGUgc2Vuc2UsIGJ1dCB3 aGVuIHVzaW5nIDxicj4NCiZndDsmZ3Q7Jmd0OyAyIGJpdHMgdGhhdCBicmVha3MgYXBhcnQuIDxi cj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgV2h5IG5vdCB1c2UgdGhlIG1vc3Qg c2lnbmlmaWNhbnQgYml0cyBpbnN0ZWFkPyBUaGF0IHdheSwgZ2V0dGluZyB0aGUgPGJyPg0KJmd0 OyZndDsmZ3Q7ICdjbGVhbicgc3RyZWFtIElEIHdpdGhvdXQgdGhlIGZsYWdzIHdvdWxkIGJlIGFz IHNpbXBsZSBkb2luZyBhIGAmYW1wOyA8YnI+DQomZ3Q7Jmd0OyZndDsgMHgzRi4uLkZGYCBpbnN0 ZWFkIG9mIGJpdC1zaGlmdGluZyB0aGluZ3MgYXJvdW5kLiBTaW1pbGFybHksIGVuY29kaW5nIDxi cj4NCiZndDsmZ3Q7Jmd0OyB0aGUgc3RyZWFtIElEIHdvdWxkIGp1c3QgZW50YWlsIGB8IDB4PzAu Li4wMGAgdG8gc2V0IHRoZSBhcHByb3ByaWF0ZSA8YnI+DQomZ3Q7Jmd0OyZndDsgYml0cyBhbmQg YWxzbyBhdm9pZCBiaXQtc2hpZnRzLiA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsm Z3Q7IFJlZ2FyZHMsIDxicj4NCiZndDsmZ3Q7Jmd0OyBIdWd1ZXMgPGJyPg0KJmd0OyZndDsmZ3Q7 IDxicj4NCiZndDsmZ3Q7Jmd0OyBPbiAyMDE3LTEwLTEzIDIwOjUxLCBSeWFuIEhhbWlsdG9uIHdy b3RlOiA8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyBBcyBJIHVuZGVyc3RhbmQgdGhlIGRpc2N1c3Np b25zIGF0IHRoZSBpbnRlcmltLCB3ZSd2ZSBkZWNpZGVkIHRvIDxicj4NCiZndDsmZ3Q7Jmd0OyAm Z3Q7IGFsbG93IHN0cmVhbXMgdG8gYmUgdW5pZGlyZWN0aW9uYWwgb3IgYmlkaXJlY3Rpb25hbC4g SSBzdXBwb3J0IHRoaXMgPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgaWRlYSBhbmQgd2FzIG1vdGl2 YXRlZCB0byB3cml0ZSB1cCBhbiBpZGVhIEkndmUgYmVlbiB0aGlua2luZyBhYm91dCA8YnI+DQom Z3Q7Jmd0OyZndDsgJmd0OyBmb3IgYSB3aGlsZS4gSW4gdGhlIHNhbWUgd2F5IHRoYXQgd2UgdXNl IGEgYml0IGluIHRoZSBzdHJlYW0gSUQgdG8gPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgaWRlbnRp ZnkgdGhlIGNsaWVudCB2cyBzZXJ2ZXIgbmF0dXJlIG9mIHRoZSBzdHJlYW0sIHdlIGNhbiB1c2Ug YSA8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyBiaXQgdG8gaWRlbnRpZnkgdGhlIGRpcmVjdGlvbmFs aXR5LiBUaGlzIGRpdmlkZXMgdGhlIHN0cmVhbSBJRCA8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyBz cGFjZSBuZWF0bHkgaW50byA0IGRpc3RpbmN0IHNwYWNlcyAobXVjaCBsaWtlIHRoZSAyIHR3byB3 ZSBoYXZlIDxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IHRvZGF5OiBjbGllbnQvc2VydmVyKS4gSW4g YWRkaXRpb24gdGhpcyBtZWFucyB0aGF0IGEgc3RyZWFtIElEIDxicj4NCiZndDsmZ3Q7Jmd0OyAm Z3Q7IGFsd2F5cyB1bmlxdWVseSBpZGVudGlmaWVzIGEgc2luZ2xlIHN0cmVhbSwgYW5kIGZyYW1l cyB3aGljaCA8YnI+DQomZ3Q7Jmd0OyZndDsgJmd0OyBtZW50aW9uIHN0cmVhbSBJRCAoU1RSRUFN LCBNQVhfU1RSRUFNX0lELCBNQVhfU1RSRUFNX0RBVEEsIDxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7 IFJTVF9TVFJFQU0sIGV0YykgZG8gbm90IG5lZWQgdG8gZXhwbGljaXRseSBjb252ZXkgdGhlIDxi cj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IGRpcmVjdGlvbmFsaXR5IGFzIGZpZWxkcyBpbiB0aG9zZSBm cmFtZXMgKG9yIGltcGxpY2l0bHkgYmFzZWQgb24gPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgdGhl IGRpcmVjdGlvbmFsaXR5IG9mIHRoZSBmcmFtZXMgdGhlbXNlbHZlcykuIDxicj4NCiZndDsmZ3Q7 Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IDwvc3Bhbj48YSBocmVmPSJodHRwczov L25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUy RmdpdGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRnB1bGwlMkY4NzImYW1wO2RhdGE9 MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3QzdmZDIwMTNjNjk0OTRlOGQyMDJhMDhk NTE0ZmQzMjZlJTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0MxJTdDMCU3QzYz NjQzODAwMDA3MzMwMDg0OSZhbXA7c2RhdGE9b3U4UWF1a242R2dJYTBic1dQVkNXclRMa3V0TmFX ODVUSFVRZmpMZHV5cyUzRCZhbXA7cmVzZXJ2ZWQ9MCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmh0dHBz Oi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC84NzI8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj4NCjxicj4NCiZndDsmZ3Q7Jmd0OyAmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0 OyAmZ3Q7IENoZWVycywgPGJyPg0KJmd0OyZndDsmZ3Q7ICZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7 ICZndDsgUnlhbiA8YnI+DQomZ3Q7Jmd0OyZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZn dDsmZ3Q7IDxicj4NCiZndDsmZ3Q7IDxicj4NCiZndDsgPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR21MB0288008D1302D533FB07C6DFB64C0MWHPR21MB0288namp_-- From nobody Mon Oct 16 19:19: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 1F884132D53 for ; Mon, 16 Oct 2017 19:19:22 -0700 (PDT) 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, 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 7TfU73_fvX7c for ; Mon, 16 Oct 2017 19:19:18 -0700 (PDT) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::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 5C6A91321A4 for ; Mon, 16 Oct 2017 19:19:18 -0700 (PDT) Received: by mail-it0-x22a.google.com with SMTP id n195so670533itg.0 for ; Mon, 16 Oct 2017 19:19:18 -0700 (PDT) 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=/5BHKEl7PrhKo4BNd3lYcoEJoeiepSAbBkr3q+GiTEs=; b=YsvewL00wiMHq3kh6B4rUQxelTiqfuYItLk8d8KRnWa8PasgEFmbIvfJTu6G+Ajrnb SCCr2C212t3uFYb9bG76qFWtV4Ch3Rz2nI4xe71YsdbxEp7X+Hp8NTSDyQ+RkxXRnMxT 7dHH/MWZDriWsEdqlJHAX/Ag0CKsSI3WRbtZUJyemVl0LU/SwbykdeLNVpVxsnFWDA+K Ttj2OBe8Yy7o6fEH9kdfeK3dOxtNw/mAs9gdP9Uhh1/jcZlR5klpR2oBNpbVDfelPKlL a/YA44gesruZV04GLVfZFKyNCsWYOQNMcpLhITabAOO1YRRLLkdbkWuzz/vK6Sw3zXvZ F68Q== 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=/5BHKEl7PrhKo4BNd3lYcoEJoeiepSAbBkr3q+GiTEs=; b=NhL/nw9SPyQgdHmPmGzsOIPM5igdGPgnJYXtUGMxilU9S5M6QmhswQ2PBd9tm7WFVA wts6M3pjTddiyoJ23260GHyz9Xw6Vcoodc0HoGpO+S6kY4f2q+d2cSqCGL2k/0xSESxQ rXyyOBgmroCOlf2xKYC8cj930o3+a+GEXH7HcdVt050PxXnyY1Hv9WmpAW4ORF5iklA9 Q2cg56CxVtTa3iAvYDf5FqR9onwaJMBoOXmKCc+1/LC70T6FqJPw0ZfkxJpzNNJZdS/q dQkl9sawkq8EDngcrsRsAdeaBUuZT1y2Y1fRNnCGZe6a0ak9ybDVwA8yeBlHQQ4zrv5P rtFg== X-Gm-Message-State: AMCzsaWOxUWlCzNJG6hFkEMBWi68ChVe5KSloW2NPoIl8Hd7vHrTiKYv 107o557FdhxwCPJ5CQYKK96IAWcSCV2ttTDbd7FeVA== X-Google-Smtp-Source: ABhQp+SObSxkSr7xL31EGebOS+qys7XrMNpBaLvKuxY+OwsUtALvaLDNIBg+7PPNTqNDhAuhThSCbzN/Za9BHB/PrIc= X-Received: by 10.36.120.136 with SMTP id p130mr3581507itc.54.1508206757280; Mon, 16 Oct 2017 19:19:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.4 with HTTP; Mon, 16 Oct 2017 19:18:56 -0700 (PDT) In-Reply-To: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> From: Ian Swett Date: Mon, 16 Oct 2017 22:18:56 -0400 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: Praveen Balasubramanian Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Martin Thomson , Jana Iyengar , Mike Bishop , "quic@ietf.org" , Hugues Fafard , Roberto Peon Content-Type: multipart/alternative; boundary="001a114ab8e40487a6055bb4c0fe" 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, 17 Oct 2017 02:19:22 -0000 --001a114ab8e40487a6055bb4c0fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On a high level, I 'think' the working group has agreed on three things: 1) The transport needs to support bidirectional streams (Prague) 2) The approach of adding an association stream ID in the first few bytes of the stream adds more complexity than we'd like. (Ekr's prototype in Seattle) 3) There is a lot of interest in having unidirectional streams as a first class transport feature. (I can't call this consensus, but there's certainly lots of interest) This heads us towards an approach where another bit somewhere in the stream frame indicates whether it's unidirectional or bidirectional. One option was my original PR#656 , but that would require changes to remove implicitly opened streams(ie: I receive stream ID 7, indicating 5 must have been opened) from the current QUIC transport. Ryan's PR creates 4 separate namespaces for different types of streams instead of the current two namespaces. There a few ways to move bits around, but I think most end up functionally very similar either to my PR or Ryan's. On Mon, Oct 16, 2017 at 9:41 PM, Praveen Balasubramanian < pravb@microsoft.com> wrote: > I agree that this is adding complexity with four special cases, but I > would actually argue the other way: apps that want uni streams should be > able to use the existing bidi stream mechanism. An API for uni stream can > achieve this by closing the stream in one direction immediately after > opening it so that the very first packet for that stream signals that one > direction is closed and the other end knows that the stream is uni. Bidi > streams are a more general case and if we are going to support them (whic= h > I think we should) then do we need any dedicated transport mechanisms for > uni streams? > > > > Thanks > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=C3= =B8e > J=C3=B8rgensen > *Sent:* Monday, October 16, 2017 6:20 PM > *To:* Martin Thomson ; Jana Iyengar < > jri@google.com> > *Cc:* Mike Bishop ; Ian Swett < > ianswett@google.com>; quic@ietf.org; Hugues Fafard ; > Roberto Peon > > *Subject:* Re: Identify streams unidirectional vs bidirectional based on > stream ID > > > > I=E2=80=99m just wondering why this approach was preferred as opposed to = building > bidi on top of uni. I suppose this must have been discussed at the interi= m > and in part based on the recent experimental implementation of uni stream= s. > > > > A straightforward implementation may not have much difficulty in handling > the implementation either way but when you attempt to achieve low latency > and low memory foot print with shortest possible state life times includi= ng > coordination with application level buffers, then bidi streams are not ve= ry > fun to work with at the transport level. As become more agreeable after i= t > was concluded that teardown did not have to wait for FIN ACK and related, > but it is still a lot of complexity with potential bugs. > > > > One aspect of the complexity is that there are now four special cases > instead of two in the stream identifiers which must be dealt with in > several frame types. Some of this involves flow control per stream type > which bidi on top of uni would not support at the same granularity, but i= s > this really needed? > > > > Adding uni streams in addition to bidi streams is still a lot better than > not having uni streams because they solve problems such as async messagin= g > at high volume and partial reliability via throw away streams. However, > they do nothing to simplify the transport with the current proposal. > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > On 17 October 2017 at 02.49.38, Martin Thomson (martin.thomson@gmail.com) > wrote: > > Those low order bits are important. No need to rush (it's a > relatively small changeset). > > On Tue, Oct 17, 2017 at 10:48 AM, Jana Iyengar wrote: > > Based on what I'm seeing on the PR and on this thread, I think there's > > general agreement on this strategy to go forward. I would like to merge > this > > PR soon, modulo a new revision to address some open comments. (There's > > currently a question about whether to use the high or the low-order bit= s > for > > this, which should also get resolved before merging.) > > > > I'm asking folks to please review and speak up if they have > disagreements > > with the direction or with any specifics. > > > > I'll be away from connectivity for a week, so unless there are > unresolved > > issues then, I'd like to merge this in a week when I return. Martin can > > merge this sooner if there's only agreement. > > > > On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett wrote: > >> > >> I believe the motivation for separate stream limits is to put a > reasonable > >> limit on the number of incoming streams you'll accept. Otherwise, an > >> application could use a very large number of one type(ie: uni) of > stream and > >> almost none of another(ie: bidi), which would allow them to suddenly > open a > >> huge number of the other type(ie: bidi) of stream if they wanted. > >> > >> If we were using H2 style max open streams we could do it either way, > but > >> I think keeping them separate is probably best anyway. > >> > >> On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon wrote: > >>> > >>> In H2, the even/odd thing was just an easy way to encode a unique ID > per > >>> stream while indicating direction. > >>> This proposal seems to do the same thing, and that makes sense to > >>> me=E2=80=94instead of even-odd, we have mod-4-offset. > >>> > >>> I=E2=80=99d ask why bother to have separate stream limits. You could = still > just > >>> have the one limit for the overall space. > >>> With H2, that was part of the point of putting it there (though it wa= s > >>> implit)=E2=80=94it was all part of one space, and thus the space was = singly > >>> countable! > >>> > >>> > >>> > >>> -=3DR > >>> > >>> > >>> > >>> From: QUIC on behalf of Ian Swett > >>> > >>> Date: Friday, October 13, 2017 at 2:05 PM > >>> To: Mike Bishop > >>> Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen , "quic@iet= f.org" > >>> , Hugues Fafard > >>> > >>> > >>> Subject: Re: Identify streams unidirectional vs bidirectional based o= n > >>> stream ID > >>> > >>> > >>> > >>> In many ways, they are 4 independent spaces, but Ryan pointed out to > me > >>> that both for the purposes of draft text and implementation it's very > useful > >>> to have a single unique identifier for a stream, since otherwise you > have to > >>> talk about/pass around (StreamID, Type) everywhere instead of just > StreamID. > >>> > >>> > >>> > >>> Keeping one stream ID avoids creating two of all the stream specific > >>> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET, etc), > one > >>> for each stream space. > >>> > >>> > >>> > >>> Using the two most significant bits would eliminate the usefulness of > any > >>> variable length integer encoding(current or Martin's new proposal), s= o > using > >>> the lower bits makes sense. > >>> > >>> > >>> > >>> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop > >>> wrote: > >>> > >>> Indeed. I almost think it makes more sense to say that there are four > >>> independent stream spaces, each with their own numbers. That does mea= n > that > >>> each side will need to separately manage Max Stream ID for two spaces= , > but > >>> that seems more reasonable than the alternative. In fact, this PR > already > >>> implies that the limits for unidirectional and bidirectional streams > are > >>> handled separately, which gets really weird when the IDs are > interleaved > >>> with each other. > >>> > >>> > >>> > >>> In fact, this plays well with the variable-length encoding idea, sinc= e > >>> the maximum size of a Stream ID would be 62 bits. They could then be > stored > >>> locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits indic= ating which space > they > >>> refer to. > >>> > >>> > >>> > >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3= =B8e > >>> J=C3=B8rgensen > >>> Sent: Friday, October 13, 2017 1:04 PM > >>> To: quic@ietf.org; Hugues Fafard > >>> Subject: Re: Identify streams unidirectional vs bidirectional based o= n > >>> stream ID > >>> > >>> > >>> > >>> Especially with the new variable length encoding proposal, storing th= e > >>> identifiers early makes sense, as you only have to inspect the first > byte. > >>> But it gets complicated, because you don=E2=80=99t want to use 8 byte= s for > some > >>> stream types and you don=E2=80=99t want the bits at some random locat= ion in a > >>> decoded 8 byte representation either. > >>> > >>> > >>> > >>> Regardless of bit placement, encoding state using bits is not ideal > when > >>> considering variable length encoding because you now use two bits for > length > >>> and two bits for stream type, leaving only 16 different streams befor= e > the > >>> stream identifier needs to use two bytes, and so forth. > >>> > >>> > >>> > >>> > >>> > >>> Kind Regards, > >>> > >>> Mikkel Fahn=C3=B8e J=C3=B8rgensen > >>> > >>> > >>> > >>> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) > wrote: > >>> > >>> I see, you used the 2 least significant bits to encode that > >>> information. When only using one bit to indicate the direction, it > >>> boiled down to odd/even which more or less made sense, but when using > >>> 2 bits that breaks apart. > >>> > >>> Why not use the most significant bits instead? That way, getting the > >>> 'clean' stream ID without the flags would be as simple doing a `& > >>> 0x3F...FF` instead of bit-shifting things around. Similarly, encoding > >>> the stream ID would just entail `| 0x?0...00` to set the appropriate > >>> bits and also avoid bit-shifts. > >>> > >>> Regards, > >>> Hugues > >>> > >>> On 2017-10-13 20:51, Ryan Hamilton wrote: > >>> > As I understand the discussions at the interim, we've decided to > >>> > allow streams to be unidirectional or bidirectional. I support this > >>> > idea and was motivated to write up an idea I've been thinking about > >>> > for a while. In the same way that we use a bit in the stream ID to > >>> > identify the client vs server nature of the stream, we can use a > >>> > bit to identify the directionality. This divides the stream ID > >>> > space neatly into 4 distinct spaces (much like the 2 two we have > >>> > today: client/server). In addition this means that a stream ID > >>> > always uniquely identifies a single stream, and frames which > >>> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, > >>> > RST_STREAM, etc) do not need to explicitly convey the > >>> > directionality as fields in those frames (or implicitly based on > >>> > the directionality of the frames themselves). > >>> > > >>> > https://github.com/quicwg/base-drafts/pull/872 > > >>> > > >>> > Cheers, > >>> > > >>> > Ryan > >>> > >>> > >> > >> > > > > --001a114ab8e40487a6055bb4c0fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On a high level, I 'think' the working group = has agreed on three things:
=C2=A01) The transport needs to s= upport bidirectional streams (Prague)
=C2=A02) The approach of ad= ding an association stream ID in the first few bytes of the stream adds mor= e complexity than we'd like. (Ekr's prototype in Seattle)
=C2=A03) There is a lot of interest in having unidirectional streams as a = first class transport feature. (I can't call this consensus, but there&= #39;s certainly lots of interest)



On Mon, Oct 16, 2017 at 9:4= 1 PM, Praveen Balasubramanian <pravb@microsoft.com> wrote:=

I agree that this is adding complexity with four spe= cial cases, but I would actually argue the other way: apps that want uni st= reams should be able to use the existing bidi stream mechanism. An API for = uni stream can achieve this by closing the stream in one direction immediately after opening it so that the very = first packet for that stream signals that one direction is closed and the o= ther end knows that the stream is uni. Bidi streams are a more general case= and if we are going to support them (which I think we should) then do we need any dedicated transport mec= hanisms for uni streams?

=C2=A0

Thanks

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Monday, October 16, 2017 6:20 PM
To: Martin Thomson <martin.thomson@gmail.com>; Jana Iyengar <jri@google.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Ian Swett <= ianswett@google.co= m>; quic@ietf.org= ; Hugues Fafard <fafard@in.tum.de>; Roberto Peon <fenix@fb.com>


Subject: Re: Identify streams unidirectional vs bidirectional based = on stream ID

=C2=A0

I=E2=80=99m just wondering why this approach was = preferred as opposed to building bidi on top of uni. I suppose this must ha= ve been discussed at the interim and in part based on the recent experimental implementation of uni streams.

=C2=A0

A straightforward implementation may not have muc= h difficulty in handling the implementation either way but when you attempt= to achieve low latency and low memory foot print with shortest possible state life times including coordination with applic= ation level buffers, then bidi streams are not very fun to work with at the= transport level. As become more agreeable after it was concluded that tear= down did not have to wait for FIN ACK and related, but it is still a lot of complexity with potential bugs.<= u>

=C2=A0

One aspect of the complexity is that there are no= w four special cases instead of two in the stream identifiers which must be= dealt with in several frame types. Some of this involves flow control per stream type which bidi on top of uni would not s= upport at the same granularity, but is this really needed?

=C2=A0

Adding uni streams in addition to bidi streams is= still a lot better than not having uni streams because they solve problems= such as async messaging at high volume and partial reliability via throw away streams. However, they do nothing to simplify t= he transport with the current proposal.

=C2=A0

Kind Regards,

Mikkel Fahn=C3=B8e= J=C3=B8rgensen

=C2=A0

On 17 October 2017 at 02.49= .38, Martin Thomson (martin.thomson@gmail.com) wrote:

Those low order bits are important. No need to ru= sh (it's a
relatively small changeset).

On Tue, Oct 17, 2017 at 10:48 AM, Jana Iyengar <jri@google.com> wro= te:
> Based on what I'm seeing on the PR and on this thread, I think the= re's
> general agreement on this strategy to go forward. I would like to merg= e this
> PR soon, modulo a new revision to address some open comments. (There&#= 39;s
> currently a question about whether to use the high or the low-order bi= ts for
> this, which should also get resolved before merging.)
>
> I'm asking folks to please review and speak up if they have disagr= eements
> with the direction or with any specifics.
>
> I'll be away from connectivity for a week, so unless there are unr= esolved
> issues then, I'd like to merge this in a week when I return. Marti= n can
> merge this sooner if there's only agreement.
>
> On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett <ianswett@google.com<= span style=3D"font-size:10.0pt;font-family:"Helvetica",sans-serif= ">> wrote:
>>
>> I believe the motivation for separate stream limits is to put a re= asonable
>> limit on the number of incoming streams you'll accept. Otherwi= se, an
>> application could use a very large number of one type(ie: uni) of = stream and
>> almost none of another(ie: bidi), which would allow them to sudden= ly open a
>> huge number of the other type(ie: bidi) of stream if they wanted. =
>>
>> If we were using H2 style max open streams we could do it either w= ay, but
>> I think keeping them separate is probably best anyway.
>>
>> On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon <fenix@fb.com>= ; wrote:
>>>
>>> In H2, the even/odd thing was just an easy way to encode a uni= que ID per
>>> stream while indicating direction.
>>> This proposal seems to do the same thing, and that makes sense= to
>>> me=E2=80=94instead of even-odd, we have mod-4-offset.
>>>
>>> I=E2=80=99d ask why bother to have separate stream limits. You= could still just
>>> have the one limit for the overall space.
>>> With H2, that was part of the point of putting it there (thoug= h it was
>>> implit)=E2=80=94it was all part of one space, and thus the spa= ce was singly
>>> countable!
>>>
>>>
>>>
>>> -=3DR
>>>
>>>
>>>
>>> From: QUIC <quic-bounces@ietf.org> on behalf of = Ian Swett
>>> <ianswett@google.com>
>>> Date: Friday, October 13, 2017 at 2:05 PM
>>> To: Mike Bishop <Michael.Bishop@microsoft.com>
>>> Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com= >, "quic@ietf.org"
>>> <= quic@ietf.org>, Hugues Fafard <fafard@in.tum.de&g= t;
>>>
>>>
>>> Subject: Re: Identify streams unidirectional vs bidirectional = based on
>>> stream ID
>>>
>>>
>>>
>>> In many ways, they are 4 independent spaces, but Ryan pointed = out to me
>>> that both for the purposes of draft text and implementation it= 's very useful
>>> to have a single unique identifier for a stream, since otherwi= se you have to
>>> talk about/pass around (StreamID, Type) everywhere instead of = just StreamID.
>>>
>>>
>>>
>>> Keeping one stream ID avoids creating two of all the stream sp= ecific
>>> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET= , etc), one
>>> for each stream space.
>>>
>>>
>>>
>>> Using the two most significant bits would eliminate the useful= ness of any
>>> variable length integer encoding(current or Martin's new p= roposal), so using
>>> the lower bits makes sense.
>>>
>>>
>>>
>>> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop
>>> <Michael.Bishop@microsoft.com> wrote:
>>>
>>> Indeed. I almost think it makes more sense to say that there a= re four
>>> independent stream spaces, each with their own numbers. That d= oes mean that
>>> each side will need to separately manage Max Stream ID for two= spaces, but
>>> that seems more reasonable than the alternative. In fact, this= PR already
>>> implies that the limits for unidirectional and bidirectional s= treams are
>>> handled separately, which gets really weird when the IDs are i= nterleaved
>>> with each other.
>>>
>>>
>>>
>>> In fact, this plays well with the variable-length encoding ide= a, since
>>> the maximum size of a Stream ID would be 62 bits. They could t= hen be stored
>>> locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bit= s indicating which space they
>>> refer to.
>>>
>>>
>>>
>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of= Mikkel Fahn=C3=B8e
>>> J=C3=B8rgensen
>>> Sent: Friday, October 13, 2017 1:04 PM
>>> To: = quic@ietf.org; Hugues Fafard <fafard@in.tum.de>
>>> Subject: Re: Identify streams unidirectional vs bidirectional = based on
>>> stream ID
>>>
>>>
>>>
>>> Especially with the new variable length encoding proposal, sto= ring the
>>> identifiers early makes sense, as you only have to inspect the= first byte.
>>> But it gets complicated, because you don=E2=80=99t want to use= 8 bytes for some
>>> stream types and you don=E2=80=99t want the bits at some rando= m location in a
>>> decoded 8 byte representation either.
>>>
>>>
>>>
>>> Regardless of bit placement, encoding state using bits is not = ideal when
>>> considering variable length encoding because you now use two b= its for length
>>> and two bits for stream type, leaving only 16 different stream= s before the
>>> stream identifier needs to use two bytes, and so forth.
>>>
>>>
>>>
>>>
>>>
>>> Kind Regards,
>>>
>>> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>>>
>>>
>>>
>>> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote:
>>>
>>> I see, you used the 2 least significant bits to encode that >>> information. When only using one bit to indicate the direction= , it
>>> boiled down to odd/even which more or less made sense, but whe= n using
>>> 2 bits that breaks apart.
>>>
>>> Why not use the most significant bits instead? That way, getti= ng the
>>> 'clean' stream ID without the flags would be as simple= doing a `&
>>> 0x3F...FF` instead of bit-shifting things around. Similarly, e= ncoding
>>> the stream ID would just entail `| 0x?0...00` to set the appro= priate
>>> bits and also avoid bit-shifts.
>>>
>>> Regards,
>>> Hugues
>>>
>>> On 2017-10-13 20:51, Ryan Hamilton wrote:
>>> > As I understand the discussions at the interim, we've= decided to
>>> > allow streams to be unidirectional or bidirectional. I su= pport this
>>> > idea and was motivated to write up an idea I've been = thinking about
>>> > for a while. In the same way that we use a bit in the str= eam ID to
>>> > identify the client vs server nature of the stream, we ca= n use a
>>> > bit to identify the directionality. This divides the stre= am ID
>>> > space neatly into 4 distinct spaces (much like the 2 two = we have
>>> > today: client/server). In addition this means that a stre= am ID
>>> > always uniquely identifies a single stream, and frames wh= ich
>>> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA= ,
>>> > RST_STREAM, etc) do not need to explicitly convey the >>> > directionality as fields in those frames (or implicitly b= ased on
>>> > the directionality of the frames themselves).
>>> >
>>> > https://github.com/quicwg/base-drafts/pull/872
>>> >
>>> > Cheers,
>>> >
>>> > Ryan
>>>
>>>
>>
>>
>


--001a114ab8e40487a6055bb4c0fe-- From nobody Mon Oct 16 20:56:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37D631320D8 for ; Mon, 16 Oct 2017 20:56:23 -0700 (PDT) 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 7G2N-iY1HBYs for ; Mon, 16 Oct 2017 20:56:20 -0700 (PDT) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE030126BF3 for ; Mon, 16 Oct 2017 20:56:19 -0700 (PDT) Received: by mail-qt0-x233.google.com with SMTP id z28so792851qtz.13 for ; Mon, 16 Oct 2017 20:56:19 -0700 (PDT) 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=YRbeCgiYSr3WP5iBGO3uaTYP/+LP0SyRH794oDH8fG0=; b=BuL16WNbyHma3LBSHmihF7IS/UPH7VqdlRe81uGlzP8p+33SA0xYdPbhh/6pjGObDD W/b9lkRLNW+BvcOHiMmOrC6iCDQSBHKJxbzfIobDYjxoVJktLWCqbef8DCVt829COgB6 J2IK+I5FPiOnNXQWlnE2w+F1lNJn6tmMiAOoWWbRh35huZo7DUE4uNBX12RxF044vOTq rr+qsoz9zwmrRRcYxS/PhIHn2qBf6bhxp3LDEELhVPRz4hdhLYJZikqgGzZ41XujqrSM rRMeXZJDs9wSbcLliIGZIY18sPzCr3ySB8f/HuqTiLc9bNol7QN5eA5/S84ghFiio/sQ 5kpA== 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=YRbeCgiYSr3WP5iBGO3uaTYP/+LP0SyRH794oDH8fG0=; b=dPYiunGzKkBpt3NkO8K8KVxmW3eq0YvUZUmLmWr40E2cx9/c1ZO8B9+gD8/7TJsmcD +SZbu+S6Z182qXX/3PRFYZP85cD/RVw7mgK5m9Kk7Q+jrDiLHebg6wCzK0VRQgZl8oMz egim4dN6Ekcf2MSuOmxiieHMXAf8SalhQxs5W5KzL9kdc3C5mzfJ2+Un1Aj1dDmfYsux TUmjv+jGU+4ueaXe2pb4cgdCmrzzWCwFxGDdsAhgPXegGSfpqWuC4iiGiuUuwAlFJzmy CPGrDXq/5WDZJ+C5IjmU3SyHxvLUzf0rmPa3XssO5f7E2molM36fQx56DFwXzhfNkb1b TyAQ== X-Gm-Message-State: AMCzsaW9Qt7M8NXEeUynRSVAmRrUu2BH+c6wWtnL6SBFC1XKiDO5Vn25 CQ1antbyOMcHddSWYefge9ljM/zXShKAvqZd/ksOHA== X-Google-Smtp-Source: ABhQp+RVWtpfNw2u4dfTceiwZ8kK2iHnk+pNy28Tx0ZdeaY8lZqbRNREoSrr3vxGEbt+SPBVJcaa3oKcYQuHwfZ/OXQ= X-Received: by 10.37.186.8 with SMTP id t8mr1886177ybg.91.1508212578555; Mon, 16 Oct 2017 20:56:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.70.5 with HTTP; Mon, 16 Oct 2017 20:56:17 -0700 (PDT) In-Reply-To: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> From: Jana Iyengar Date: Mon, 16 Oct 2017 20:56:17 -0700 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: Praveen Balasubramanian Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Martin Thomson , Mike Bishop , Ian Swett , "quic@ietf.org" , Hugues Fafard , Roberto Peon Content-Type: multipart/alternative; boundary="f403043da404fe5261055bb61ac7" 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, 17 Oct 2017 03:56:23 -0000 --f403043da404fe5261055bb61ac7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Oct 16, 2017 at 6:41 PM, Praveen Balasubramanian < pravb@microsoft.com> wrote: > I agree that this is adding complexity with four special cases, but I > would actually argue the other way: apps that want uni streams should be > able to use the existing bidi stream mechanism. An API for uni stream can > achieve this by closing the stream in one direction immediately after > opening it so that the very first packet for that stream signals that one > direction is closed and the other end knows that the stream is uni. Bidi > streams are a more general case and if we are going to support them (whic= h > I think we should) then do we need any dedicated transport mechanisms for > uni streams? > There's not a lot of dedicated mechanisms; indeed you can implement uni as a special case of bidi streams. The issue was, as Ian summarized nicely here, that implicitly open streams became ambiguous. For instance if stream 15 was opened after stream 11, the spec requires stream 13 to be opened implicitly, but should it be opened as a uni stream or a bidi one? Separating namespaces for uni/bidi means that only streams in that particular namespace are opened implicitly. > > > Thanks > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn=C3= =B8e > J=C3=B8rgensen > *Sent:* Monday, October 16, 2017 6:20 PM > *To:* Martin Thomson ; Jana Iyengar < > jri@google.com> > *Cc:* Mike Bishop ; Ian Swett < > ianswett@google.com>; quic@ietf.org; Hugues Fafard ; > Roberto Peon > > *Subject:* Re: Identify streams unidirectional vs bidirectional based on > stream ID > > > > I=E2=80=99m just wondering why this approach was preferred as opposed to = building > bidi on top of uni. I suppose this must have been discussed at the interi= m > and in part based on the recent experimental implementation of uni stream= s. > > > > A straightforward implementation may not have much difficulty in handling > the implementation either way but when you attempt to achieve low latency > and low memory foot print with shortest possible state life times includi= ng > coordination with application level buffers, then bidi streams are not ve= ry > fun to work with at the transport level. As become more agreeable after i= t > was concluded that teardown did not have to wait for FIN ACK and related, > but it is still a lot of complexity with potential bugs. > > > > One aspect of the complexity is that there are now four special cases > instead of two in the stream identifiers which must be dealt with in > several frame types. Some of this involves flow control per stream type > which bidi on top of uni would not support at the same granularity, but i= s > this really needed? > > > > Adding uni streams in addition to bidi streams is still a lot better than > not having uni streams because they solve problems such as async messagin= g > at high volume and partial reliability via throw away streams. However, > they do nothing to simplify the transport with the current proposal. > > > > Kind Regards, > > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > > On 17 October 2017 at 02.49.38, Martin Thomson (martin.thomson@gmail.com) > wrote: > > Those low order bits are important. No need to rush (it's a > relatively small changeset). > > On Tue, Oct 17, 2017 at 10:48 AM, Jana Iyengar wrote: > > Based on what I'm seeing on the PR and on this thread, I think there's > > general agreement on this strategy to go forward. I would like to merge > this > > PR soon, modulo a new revision to address some open comments. (There's > > currently a question about whether to use the high or the low-order bit= s > for > > this, which should also get resolved before merging.) > > > > I'm asking folks to please review and speak up if they have > disagreements > > with the direction or with any specifics. > > > > I'll be away from connectivity for a week, so unless there are > unresolved > > issues then, I'd like to merge this in a week when I return. Martin can > > merge this sooner if there's only agreement. > > > > On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett wrote: > >> > >> I believe the motivation for separate stream limits is to put a > reasonable > >> limit on the number of incoming streams you'll accept. Otherwise, an > >> application could use a very large number of one type(ie: uni) of > stream and > >> almost none of another(ie: bidi), which would allow them to suddenly > open a > >> huge number of the other type(ie: bidi) of stream if they wanted. > >> > >> If we were using H2 style max open streams we could do it either way, > but > >> I think keeping them separate is probably best anyway. > >> > >> On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon wrote: > >>> > >>> In H2, the even/odd thing was just an easy way to encode a unique ID > per > >>> stream while indicating direction. > >>> This proposal seems to do the same thing, and that makes sense to > >>> me=E2=80=94instead of even-odd, we have mod-4-offset. > >>> > >>> I=E2=80=99d ask why bother to have separate stream limits. You could = still > just > >>> have the one limit for the overall space. > >>> With H2, that was part of the point of putting it there (though it wa= s > >>> implit)=E2=80=94it was all part of one space, and thus the space was = singly > >>> countable! > >>> > >>> > >>> > >>> -=3DR > >>> > >>> > >>> > >>> From: QUIC on behalf of Ian Swett > >>> > >>> Date: Friday, October 13, 2017 at 2:05 PM > >>> To: Mike Bishop > >>> Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen , "quic@iet= f.org" > >>> , Hugues Fafard > >>> > >>> > >>> Subject: Re: Identify streams unidirectional vs bidirectional based o= n > >>> stream ID > >>> > >>> > >>> > >>> In many ways, they are 4 independent spaces, but Ryan pointed out to > me > >>> that both for the purposes of draft text and implementation it's very > useful > >>> to have a single unique identifier for a stream, since otherwise you > have to > >>> talk about/pass around (StreamID, Type) everywhere instead of just > StreamID. > >>> > >>> > >>> > >>> Keeping one stream ID avoids creating two of all the stream specific > >>> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET, etc), > one > >>> for each stream space. > >>> > >>> > >>> > >>> Using the two most significant bits would eliminate the usefulness of > any > >>> variable length integer encoding(current or Martin's new proposal), s= o > using > >>> the lower bits makes sense. > >>> > >>> > >>> > >>> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop > >>> wrote: > >>> > >>> Indeed. I almost think it makes more sense to say that there are four > >>> independent stream spaces, each with their own numbers. That does mea= n > that > >>> each side will need to separately manage Max Stream ID for two spaces= , > but > >>> that seems more reasonable than the alternative. In fact, this PR > already > >>> implies that the limits for unidirectional and bidirectional streams > are > >>> handled separately, which gets really weird when the IDs are > interleaved > >>> with each other. > >>> > >>> > >>> > >>> In fact, this plays well with the variable-length encoding idea, sinc= e > >>> the maximum size of a Stream ID would be 62 bits. They could then be > stored > >>> locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits indic= ating which space > they > >>> refer to. > >>> > >>> > >>> > >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3= =B8e > >>> J=C3=B8rgensen > >>> Sent: Friday, October 13, 2017 1:04 PM > >>> To: quic@ietf.org; Hugues Fafard > >>> Subject: Re: Identify streams unidirectional vs bidirectional based o= n > >>> stream ID > >>> > >>> > >>> > >>> Especially with the new variable length encoding proposal, storing th= e > >>> identifiers early makes sense, as you only have to inspect the first > byte. > >>> But it gets complicated, because you don=E2=80=99t want to use 8 byte= s for > some > >>> stream types and you don=E2=80=99t want the bits at some random locat= ion in a > >>> decoded 8 byte representation either. > >>> > >>> > >>> > >>> Regardless of bit placement, encoding state using bits is not ideal > when > >>> considering variable length encoding because you now use two bits for > length > >>> and two bits for stream type, leaving only 16 different streams befor= e > the > >>> stream identifier needs to use two bytes, and so forth. > >>> > >>> > >>> > >>> > >>> > >>> Kind Regards, > >>> > >>> Mikkel Fahn=C3=B8e J=C3=B8rgensen > >>> > >>> > >>> > >>> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) > wrote: > >>> > >>> I see, you used the 2 least significant bits to encode that > >>> information. When only using one bit to indicate the direction, it > >>> boiled down to odd/even which more or less made sense, but when using > >>> 2 bits that breaks apart. > >>> > >>> Why not use the most significant bits instead? That way, getting the > >>> 'clean' stream ID without the flags would be as simple doing a `& > >>> 0x3F...FF` instead of bit-shifting things around. Similarly, encoding > >>> the stream ID would just entail `| 0x?0...00` to set the appropriate > >>> bits and also avoid bit-shifts. > >>> > >>> Regards, > >>> Hugues > >>> > >>> On 2017-10-13 20:51, Ryan Hamilton wrote: > >>> > As I understand the discussions at the interim, we've decided to > >>> > allow streams to be unidirectional or bidirectional. I support this > >>> > idea and was motivated to write up an idea I've been thinking about > >>> > for a while. In the same way that we use a bit in the stream ID to > >>> > identify the client vs server nature of the stream, we can use a > >>> > bit to identify the directionality. This divides the stream ID > >>> > space neatly into 4 distinct spaces (much like the 2 two we have > >>> > today: client/server). In addition this means that a stream ID > >>> > always uniquely identifies a single stream, and frames which > >>> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, > >>> > RST_STREAM, etc) do not need to explicitly convey the > >>> > directionality as fields in those frames (or implicitly based on > >>> > the directionality of the frames themselves). > >>> > > >>> > https://github.com/quicwg/base-drafts/pull/872 > > >>> > > >>> > Cheers, > >>> > > >>> > Ryan > >>> > >>> > >> > >> > > > > --f403043da404fe5261055bb61ac7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On M= on, Oct 16, 2017 at 6:41 PM, Praveen Balasubramanian <= pravb@microsoft.co= m> wrote:

I agree that this is adding complexity with four spe= cial cases, but I would actually argue the other way: apps that want uni st= reams should be able to use the existing bidi stream mechanism. An API for = uni stream can achieve this by closing the stream in one direction immediately after opening it so that the very = first packet for that stream signals that one direction is closed and the o= ther end knows that the stream is uni. Bidi streams are a more general case= and if we are going to support them (which I think we should) then do we need any dedicated transport mec= hanisms for uni streams?


Th= ere's not a lot of dedicated mechanisms; indeed you can implement uni a= s a special case of bidi streams. The issue was, as Ian summarized nicely h= ere, that implicitly open streams became ambiguous. For instance if stream = 15 was opened after stream 11,=C2=A0 the spec requires stream 13 to be open= ed implicitly, but should it be opened as a uni stream or a bidi one? Separ= ating namespaces for uni/bidi means that only streams in that particular na= mespace are opened implicitly.

=C2=A0
=

=C2= =A0

Thanks

=C2=A0

From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3=B8e J=C3=B8rgensen
Sent: Monday, October 16, 2017 6:20 PM
To: Martin Thomson <martin.thomson@gmail.com>; Jana Iyengar <jri@google.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>; Ian Swett <= ianswett@google.co= m>; quic@ietf.org= ; Hugues Fafard <fafard@in.tum.de>; Roberto Peon <fenix@fb.com>


Subject: Re: Identify streams unidirectional vs bidirectional based = on stream ID

=C2=A0

I=E2=80=99m just wondering why this approach was = preferred as opposed to building bidi on top of uni. I suppose this must ha= ve been discussed at the interim and in part based on the recent experimental implementation of uni streams.

=C2=A0

A straightforward implementation may not have muc= h difficulty in handling the implementation either way but when you attempt= to achieve low latency and low memory foot print with shortest possible state life times including coordination with applic= ation level buffers, then bidi streams are not very fun to work with at the= transport level. As become more agreeable after it was concluded that tear= down did not have to wait for FIN ACK and related, but it is still a lot of complexity with potential bugs.<= u>

=C2=A0

One aspect of the complexity is that there are no= w four special cases instead of two in the stream identifiers which must be= dealt with in several frame types. Some of this involves flow control per stream type which bidi on top of uni would not s= upport at the same granularity, but is this really needed?

=C2=A0

Adding uni streams in addition to bidi streams is= still a lot better than not having uni streams because they solve problems= such as async messaging at high volume and partial reliability via throw away streams. However, they do nothing to simplify t= he transport with the current proposal.

=C2=A0

Kind Regards,

Mikkel Fahn=C3=B8e= J=C3=B8rgensen

=C2=A0

On 17 October 2017 at 02.49.= 38, Martin Thomson (martin.thomson@gmail.com) wrote:

Those low order bits are important. No need to ru= sh (it's a
relatively small changeset).

On Tue, Oct 17, 2017 at 10:48 AM, Jana Iyengar <jri@google.com> wro= te:
> Based on what I'm seeing on the PR and on this thread, I think the= re's
> general agreement on this strategy to go forward. I would like to merg= e this
> PR soon, modulo a new revision to address some open comments. (There&#= 39;s
> currently a question about whether to use the high or the low-order bi= ts for
> this, which should also get resolved before merging.)
>
> I'm asking folks to please review and speak up if they have disagr= eements
> with the direction or with any specifics.
>
> I'll be away from connectivity for a week, so unless there are unr= esolved
> issues then, I'd like to merge this in a week when I return. Marti= n can
> merge this sooner if there's only agreement.
>
> On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett <ianswett@google.com<= span style=3D"font-size:10.0pt;font-family:"Helvetica",sans-serif= ">> wrote:
>>
>> I believe the motivation for separate stream limits is to put a re= asonable
>> limit on the number of incoming streams you'll accept. Otherwi= se, an
>> application could use a very large number of one type(ie: uni) of = stream and
>> almost none of another(ie: bidi), which would allow them to sudden= ly open a
>> huge number of the other type(ie: bidi) of stream if they wanted. =
>>
>> If we were using H2 style max open streams we could do it either w= ay, but
>> I think keeping them separate is probably best anyway.
>>
>> On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon <fenix@fb.com>= ; wrote:
>>>
>>> In H2, the even/odd thing was just an easy way to encode a uni= que ID per
>>> stream while indicating direction.
>>> This proposal seems to do the same thing, and that makes sense= to
>>> me=E2=80=94instead of even-odd, we have mod-4-offset.
>>>
>>> I=E2=80=99d ask why bother to have separate stream limits. You= could still just
>>> have the one limit for the overall space.
>>> With H2, that was part of the point of putting it there (thoug= h it was
>>> implit)=E2=80=94it was all part of one space, and thus the spa= ce was singly
>>> countable!
>>>
>>>
>>>
>>> -=3DR
>>>
>>>
>>>
>>> From: QUIC <quic-bounces@ietf.org> on behalf of = Ian Swett
>>> <ianswett@google.com>
>>> Date: Friday, October 13, 2017 at 2:05 PM
>>> To: Mike Bishop <Michael.Bishop@microsoft.com>
>>> Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com= >, "quic@ietf.org"
>>> <= quic@ietf.org>, Hugues Fafard <fafard@in.tum.de&g= t;
>>>
>>>
>>> Subject: Re: Identify streams unidirectional vs bidirectional = based on
>>> stream ID
>>>
>>>
>>>
>>> In many ways, they are 4 independent spaces, but Ryan pointed = out to me
>>> that both for the purposes of draft text and implementation it= 's very useful
>>> to have a single unique identifier for a stream, since otherwi= se you have to
>>> talk about/pass around (StreamID, Type) everywhere instead of = just StreamID.
>>>
>>>
>>>
>>> Keeping one stream ID avoids creating two of all the stream sp= ecific
>>> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET= , etc), one
>>> for each stream space.
>>>
>>>
>>>
>>> Using the two most significant bits would eliminate the useful= ness of any
>>> variable length integer encoding(current or Martin's new p= roposal), so using
>>> the lower bits makes sense.
>>>
>>>
>>>
>>> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop
>>> <Michael.Bishop@microsoft.com> wrote:
>>>
>>> Indeed. I almost think it makes more sense to say that there a= re four
>>> independent stream spaces, each with their own numbers. That d= oes mean that
>>> each side will need to separately manage Max Stream ID for two= spaces, but
>>> that seems more reasonable than the alternative. In fact, this= PR already
>>> implies that the limits for unidirectional and bidirectional s= treams are
>>> handled separately, which gets really weird when the IDs are i= nterleaved
>>> with each other.
>>>
>>>
>>>
>>> In fact, this plays well with the variable-length encoding ide= a, since
>>> the maximum size of a Stream ID would be 62 bits. They could t= hen be stored
>>> locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bit= s indicating which space they
>>> refer to.
>>>
>>>
>>>
>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of= Mikkel Fahn=C3=B8e
>>> J=C3=B8rgensen
>>> Sent: Friday, October 13, 2017 1:04 PM
>>> To: = quic@ietf.org; Hugues Fafard <fafard@in.tum.de>
>>> Subject: Re: Identify streams unidirectional vs bidirectional = based on
>>> stream ID
>>>
>>>
>>>
>>> Especially with the new variable length encoding proposal, sto= ring the
>>> identifiers early makes sense, as you only have to inspect the= first byte.
>>> But it gets complicated, because you don=E2=80=99t want to use= 8 bytes for some
>>> stream types and you don=E2=80=99t want the bits at some rando= m location in a
>>> decoded 8 byte representation either.
>>>
>>>
>>>
>>> Regardless of bit placement, encoding state using bits is not = ideal when
>>> considering variable length encoding because you now use two b= its for length
>>> and two bits for stream type, leaving only 16 different stream= s before the
>>> stream identifier needs to use two bytes, and so forth.
>>>
>>>
>>>
>>>
>>>
>>> Kind Regards,
>>>
>>> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>>>
>>>
>>>
>>> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote:
>>>
>>> I see, you used the 2 least significant bits to encode that >>> information. When only using one bit to indicate the direction= , it
>>> boiled down to odd/even which more or less made sense, but whe= n using
>>> 2 bits that breaks apart.
>>>
>>> Why not use the most significant bits instead? That way, getti= ng the
>>> 'clean' stream ID without the flags would be as simple= doing a `&
>>> 0x3F...FF` instead of bit-shifting things around. Similarly, e= ncoding
>>> the stream ID would just entail `| 0x?0...00` to set the appro= priate
>>> bits and also avoid bit-shifts.
>>>
>>> Regards,
>>> Hugues
>>>
>>> On 2017-10-13 20:51, Ryan Hamilton wrote:
>>> > As I understand the discussions at the interim, we've= decided to
>>> > allow streams to be unidirectional or bidirectional. I su= pport this
>>> > idea and was motivated to write up an idea I've been = thinking about
>>> > for a while. In the same way that we use a bit in the str= eam ID to
>>> > identify the client vs server nature of the stream, we ca= n use a
>>> > bit to identify the directionality. This divides the stre= am ID
>>> > space neatly into 4 distinct spaces (much like the 2 two = we have
>>> > today: client/server). In addition this means that a stre= am ID
>>> > always uniquely identifies a single stream, and frames wh= ich
>>> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA= ,
>>> > RST_STREAM, etc) do not need to explicitly convey the >>> > directionality as fields in those frames (or implicitly b= ased on
>>> > the directionality of the frames themselves).
>>> >
>>> > https://github.com/quicwg/base-drafts/pull/872
>>> >
>>> > Cheers,
>>> >
>>> > Ryan
>>>
>>>
>>
>>
>


--f403043da404fe5261055bb61ac7-- From nobody Wed Oct 18 17: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 DB736126B6E for ; Wed, 18 Oct 2017 17:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 KBFuZibTWfmT for ; Wed, 18 Oct 2017 17:25:46 -0700 (PDT) Received: from mail-oi0-x235.google.com (mail-oi0-x235.google.com [IPv6:2607:f8b0:4003:c06::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 3B195133528 for ; Wed, 18 Oct 2017 17:25:46 -0700 (PDT) Received: by mail-oi0-x235.google.com with SMTP id c77so11967706oig.0 for ; Wed, 18 Oct 2017 17:25:46 -0700 (PDT) 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=SXqXkxio8J/DmaRe7QAW+YSjvWsRZI+/iXvEduo1gVU=; b=I5X4oxap9a+n2HEXPLWU2gFp3sRJTv9QMIC3I+/ARRwNBL8RwxAR/1RUyJKFiCnYFJ OP+1X2IPXVAGrLOXFMbKE0asicbM4npudgNFNcTOrPJ9/UoRus32MGxPtcAUl5toSD3Q wAQx8g8CroZOIhlvIowaDtc45knGxvSBI0Hque6z/FmtAj3j4Vo9it1pN9gXIq4R3j0L J65ggoOaAT/xrc5bFnidku8HsMS5p568jIh71yfyZloA8BDLBwdneBTUpma0ji0aF9qn 1jAs8hxmeo7zJ9pfYrfrswYtYGQcQHemdvcA36vpv3to6aZkLzkXa0+fa0KDRbmZlPRY mDnA== 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=SXqXkxio8J/DmaRe7QAW+YSjvWsRZI+/iXvEduo1gVU=; b=XlcA1lSMvmjfW9kFz0NqH7uI2EEObQOL9MNoB5LBnMoIH6PRt8UE4slSzwumPjHwdK N9PMBn2EsiF2vRVVM7j8/GexNv369bGfmbRFYUwYp0ga3WJy/6aC8vShiSnYbZIBJGTp bFmlUoDyEjhXKF2q4fPuezLeNCVDGcPiBqajz4jdorXASU2MDQbDbIPzLjDksspJFAgd OfkESRZERaAdoC+cv8YyTLM/M8fvQCcBADGHFtPy+u4DJ+zWVvwYFDoDIbb3REMyVccm gBMvB65DQQcrYkgVXdjvesZtdwf2slXWRPoPAi7T/uVPvHgKygUKAteC2uIbrbnp47ch 4Gmg== X-Gm-Message-State: AMCzsaVXFsvVa+rJTkNxquwwAZskWiGKc0GzHLRtQ8dSVfRaMYj7BtNb giWiLM9X1FqyUtQQf2Awgyo8vqpDmm8v3Ap6rwZVaVGO X-Google-Smtp-Source: ABhQp+SK8LxXsrvkIg7OWFitG1PnJKm0/gvNXiJ0vkNEVURW3ocbHFto3REsFtsevAvZktqzFS9vDT0g2N3G8y2xGPQ= X-Received: by 10.202.217.197 with SMTP id q188mr8577141oig.83.1508372745216; Wed, 18 Oct 2017 17:25:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Wed, 18 Oct 2017 17:25:44 -0700 (PDT) From: Martin Thomson Date: Thu, 19 Oct 2017 11:25:44 +1100 Message-ID: Subject: Integer encodings in QUIC frames 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: Thu, 19 Oct 2017 00:25:48 -0000 Hi All, Some of you might have heard discussion about the difficulty of parsing QUIC frames, or heard me talk about a proposal for reducing the number of different variations. I have a proposal in PR #877 [1] that replaces virtually all of the integer encodings in frames to use the same variable-length encoding. This includes the ACK delay timestamp. That encoding takes two bits to describe the length of the integer (1, 2, 4, or 8 octets) and the remainder is big-endian goodness. This produces ranges that are a bit unusual: 6-, 14-, 30-, or 62-bit. However, this should cover most use cases and is pretty fast to decode and to comprehend. My testing [2] shows that this is about ~50% slower than using a simple htonl or equivalent [3], but it can save a lot of bytes, depending on usage model. This would only affect the insides of frames. No changes are made to the packet header, connection ID, version or error codes, for which fixed-sized fields are convenient for several reasons. The change would mean different limits. We would have 4 times fewer packets and flow control octets, but 2^30 times more streams. This PR doesn't change the HTTP mapping yet. I have two PRs open in addition to this that make a matching change to the HTTP mapping. #887 [4] makes the minimum change, effectively ignoring the changes at the lower layer and sticking to 32-bit identifiers. #888 [5] imports the integer format more widely. I prefer the latter, but want to hear more opinions, because it would have consequences for HTTP/2 compatibility (see the PR for details). I expect that the HTTP working group will also have some things to say about that, so I plan to ask them too. I haven't proposed more significant changes to the ACK frame; the encoding change addresses some of the identified shortcomings, but probably not all of them. More significant changes might be proposed separately. --Martin [1] https://github.com/quicwg/base-drafts/pull/877/files [2] https://github.com/martinthomson/quic-int [3] All the usual caveats apply. Such as, my machine might not be representative, and that I didn't spend any time optimizing. Interesting note though: Feeding my code a counter as input makes it ~35% faster than an simple endian swap, probably because it uses less than one quarter of the number of octets. [4] https://github.com/quicwg/base-drafts/pull/887/files [5] https://github.com/quicwg/base-drafts/pull/888/files From nobody Wed Oct 18 19:29: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 5E31213304B for ; Wed, 18 Oct 2017 19:29:37 -0700 (PDT) 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 rM6lX_PG3JRm for ; Wed, 18 Oct 2017 19:29:35 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id DF214132076 for ; Wed, 18 Oct 2017 19:29:34 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v9J2TTOW006638; Thu, 19 Oct 2017 04:29:29 +0200 Date: Thu, 19 Oct 2017 04:29:29 +0200 From: Willy Tarreau To: Martin Thomson Cc: QUIC WG Subject: Re: Integer encodings in QUIC frames Message-ID: <20171019022929.GB6628@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 19 Oct 2017 02:29:37 -0000 Hi Martin, On Thu, Oct 19, 2017 at 11:25:44AM +1100, Martin Thomson wrote: > Hi All, > > Some of you might have heard discussion about the difficulty of > parsing QUIC frames, or heard me talk about a proposal for reducing > the number of different variations. > > I have a proposal in PR #877 [1] that replaces virtually all of the > integer encodings in frames to use the same variable-length encoding. > This includes the ACK delay timestamp. > > That encoding takes two bits to describe the length of the integer (1, > 2, 4, or 8 octets) and the remainder is big-endian goodness. This > produces ranges that are a bit unusual: 6-, 14-, 30-, or 62-bit. > However, this should cover most use cases and is pretty fast to decode > and to comprehend. > > My testing [2] shows that this is about ~50% slower than using a > simple htonl or equivalent [3], but it can save a lot of bytes, > depending on usage model. > > This would only affect the insides of frames. No changes are made to > the packet header, connection ID, version or error codes, for which > fixed-sized fields are convenient for several reasons. > > The change would mean different limits. We would have 4 times fewer > packets and flow control octets, but 2^30 times more streams. > > This PR doesn't change the HTTP mapping yet. I have two PRs open in > addition to this that make a matching change to the HTTP mapping. > #887 [4] makes the minimum change, effectively ignoring the changes at > the lower layer and sticking to 32-bit identifiers. #888 [5] imports > the integer format more widely. I prefer the latter, but want to hear > more opinions, because it would have consequences for HTTP/2 > compatibility (see the PR for details). I too support such a model, which can even be further optimized. I'd even go a bit further : modern architectures are little endian and support unaligned reads (x86_64, armv7, armv8). By adopting your model and storing the word length in the lower bits of the first byte and by using a little endian representation, you can be much faster on all platforms which matter nowadays (ie: most clients are armv8 and most servers are x86) : word = *(uint64_t *)ptr; len = word & 3; ptr += 1 << len; word >>= 2; word &= (1 << (8 * (1 << len) - 2)) - 1; // &= mask[len] It does not even perform any jump nor comparison. I could include it into your test program but don't have much time at the moment :-/ > [1] https://github.com/quicwg/base-drafts/pull/877/files Just FYI there's an error in the range of values table, the ranges for lengths 2, 4, 8 should be decreased by 1. Cheers, Willy From nobody Wed Oct 18 20:13: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 538F4132D53 for ; Wed, 18 Oct 2017 20:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YXOB5Wy0TSVH for ; Wed, 18 Oct 2017 20:13:24 -0700 (PDT) Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97F011270AE for ; Wed, 18 Oct 2017 20:13:24 -0700 (PDT) Received: by mail-oi0-x22d.google.com with SMTP id g125so12381339oib.12 for ; Wed, 18 Oct 2017 20:13:24 -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=UmYl7N1oTRkleHXAXMPEBicZBfOHV1FzXQjj7qPipNk=; b=uCg1uPalCNfLdxWYh02hl3qhtKkjn9lZMDPan+QE6IbL3eN/5mDSRlBMCBk6Bt/fGj Ux60UbQG1o/sL0Ftdc/XUrW7t/UipnDPsI2Uj0g5Po1LJT6g17jUtR7kTLV0ZOoO9Vej n9L2C8Vl0D/8qu9hoDQNJj8s6jnkIJr4E4I7M59fUeTT7lMyeO19Ij4M8McdTBYTfkH0 K1Ft405vVAnI+wxV2gd7SuPP6xncM6gXFk/j/gijCgu1cMqnApas71MktjCWCcmCRatK /WNvL7SbKqDLpLIieUpn+gAxshjTB6iLBQLYUmTnETe+5xU8jLmNOX2tzkB/X0NZAO6J opzw== 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=UmYl7N1oTRkleHXAXMPEBicZBfOHV1FzXQjj7qPipNk=; b=jSQc06CE11pm0qFEuC3NflQtvJIviRdIiyU4a6tZQdhZlM7EhRQU0Eum2BMjYLVNRq aKzjljbc7MmkCyVwJ/f29I0l975LsoQrlVbrY0l09AH/B9Hpq6JRPpBHr0obu60F40pn YYCN0M+emjERT/VhIkiJXTm2Ij/jrzSKj1++AbQ0JX1xlnPwJyw68ie+Q7KEHedOUgTE s8poo3ucbsMyYC5fVUwyrbW5MRkS0gwzGbZQjcuw6D+/vBT75kvZxoVABrq3KqaTHOhl 4l6NxoHu/FrdsZs7ic7Qcluue62q1eYPSLFEsuAnUaOqLI5DGaDSKRkAO7OhIz873b0k 601A== X-Gm-Message-State: AMCzsaUBGufVHlqOcBowREvudHJbHeVzwgOwA4WB3m/MRwEOV9SmgScm z7tgFYaamSIsWzOrs7VvxTn8hbKyBrtZP29hjb1xA3qw X-Google-Smtp-Source: ABhQp+RlyuOFzzysxTKTOTJqjy6YOeKUpxKNrnCUna8clv69hXvnLQVkCw2B/C7Q9f1x/W5z+FljZL3UyTcpgA+cd5Q= X-Received: by 10.157.37.90 with SMTP id j26mr98509otd.401.1508382803893; Wed, 18 Oct 2017 20:13:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Wed, 18 Oct 2017 20:13:23 -0700 (PDT) In-Reply-To: <20171019022929.GB6628@1wt.eu> References: <20171019022929.GB6628@1wt.eu> From: Martin Thomson Date: Thu, 19 Oct 2017 14:13:23 +1100 Message-ID: Subject: Re: Integer encodings in QUIC frames To: Willy Tarreau 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: Thu, 19 Oct 2017 03:13:26 -0000 On Thu, Oct 19, 2017 at 1:29 PM, Willy Tarreau wrote: > word = *(uint64_t *)ptr; Yeah, we more or less already had that debate and I didn't want a re-run. I do agree that it seems faster in theory (see below), but the law of diminishing returns applies here. Also, that code isn't portable, so it would need a forest of #ifdef statements to safeguard it. > word &= (1 << (8 * (1 << len) - 2)) - 1; // &= mask[len] The one optimization I did do, which made my code about 4 times faster, was to remove this sort of calculation. I don't completely understand why, but a simple if statement was much faster than this. I tried your code and it was a lot slower than my big-endian code on decoding, though encode was maybe a tiny fraction faster). A table lookup (mask[len]) was a small bit faster, but it was still in the order of 2.5 times slower. I think that the branch doesn't cost as much as you think (it could just be that I have a good branch predictor on my 5-year-old CPU). Every time I play with code optimization, I'm surprised by this sort of result. See https://github.com/martinthomson/quic-int/pull/1 > Just FYI there's an error in the range of values table, the ranges for > lengths 2, 4, 8 should be decreased by 1. Thanks, fixed. From nobody Wed Oct 18 20:28: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 44F2B13295C for ; Wed, 18 Oct 2017 20:28:42 -0700 (PDT) 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 wMz5D0eGUQcN for ; Wed, 18 Oct 2017 20:28:41 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 956F6126DD9 for ; Wed, 18 Oct 2017 20:28:40 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v9J3SaBK006722; Thu, 19 Oct 2017 05:28:36 +0200 Date: Thu, 19 Oct 2017 05:28:36 +0200 From: Willy Tarreau To: Martin Thomson Cc: QUIC WG Subject: Re: Integer encodings in QUIC frames Message-ID: <20171019032836.GA6718@1wt.eu> References: <20171019022929.GB6628@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Thu, 19 Oct 2017 03:28:42 -0000 On Thu, Oct 19, 2017 at 02:13:23PM +1100, Martin Thomson wrote: > On Thu, Oct 19, 2017 at 1:29 PM, Willy Tarreau wrote: > > word = *(uint64_t *)ptr; > > Yeah, we more or less already had that debate and I didn't want a > re-run. I do agree that it seems faster in theory (see below), but > the law of diminishing returns applies here. Also, that code isn't > portable, so it would need a forest of #ifdef statements to safeguard > it. Sure but that's an implementation detail, as the portable code should only include byte-per-byte reading. We all have #ifdef for different architectures in our code where that's relevant. > > word &= (1 << (8 * (1 << len) - 2)) - 1; // &= mask[len] > > The one optimization I did do, which made my code about 4 times > faster, was to remove this sort of calculation. I don't completely > understand why, but a simple if statement was much faster than this. It's very possible due to the word length distribution. Branch predictors are pretty good and when you realize that most consecutive words are of the same size, you quickly understand why jumps are cheap. My first attempt which I removed before posting was to use a switch/case, which the compiler easily optimizes as "jmp table[len]". > I tried your code and it was a lot slower than my big-endian code on > decoding, though encode was maybe a tiny fraction faster). A table > lookup (mask[len]) was a small bit faster, but it was still in the > order of 2.5 times slower. I think that the branch doesn't cost as > much as you think (it could just be that I have a good branch > predictor on my 5-year-old CPU). Every time I play with code > optimization, I'm surprised by this sort of result. Oh I'm never surprized, in general I experiment, then tweak and only once it works as expected I figure why I initially took the wrong direction ;-) > See https://github.com/martinthomson/quic-int/pull/1 Ah thanks a lot, when I have time I'll play with it. I'm currently finishing the reimplementation of H2 in haproxy and prefer not to switch to some very addicting stuff before that's done you see ;-) Cheers, Willy From nobody Thu Oct 19 04:42: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 9EE5513331E for ; Thu, 19 Oct 2017 04:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 cHbDKnEFB_Oz for ; Thu, 19 Oct 2017 04:42:00 -0700 (PDT) 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 E6398132025 for ; Thu, 19 Oct 2017 04:41:59 -0700 (PDT) Received: by mail-io0-x22c.google.com with SMTP id i38so9484710iod.2 for ; Thu, 19 Oct 2017 04:41:59 -0700 (PDT) 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=DIvuIJ4GWLB0AJjYlCK9i4/TfZ34zZtwaqm4Rtds6y4=; b=sEK4VZuV3oI1YIUVxer22naNYNY4OoMpVMNVqmNUqMYA1tuO82xQp3scyAgn0dsRMR 2MEHRbEd1YQX2MA5EODvxcyQ2IKuX9rqRNQLVmMfozYcVkiwGxCMxoo8aFioLZ5qDl4e fjEEp16Lj/nGWP1m17wUlppMSbJcAJcbPAXnUKqWpIXrNE+ddIEH958Zn7fYqFBorZ+5 BsTQRL2DEHf6mDbdBJGp/anW4dC+SOIWQ/4xWfZ/TiVKw5pYMSMXmZDoZWWhRN9mWb/r KKN8G3AIDX5bwerNPx3/2BvnCo9NMEtNbTNlvNH+DQBBP7Wg6t2K/q8/eP0OpPxinXe1 +JNQ== 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=DIvuIJ4GWLB0AJjYlCK9i4/TfZ34zZtwaqm4Rtds6y4=; b=cBpFBck6lfUDiGMvpPd/aiZEssMxEi0F/jMtHF1rzsEq2Wj0UIsLz9cniBUzS4NO37 a7zQ6dUVwZ+DmgM+79sI3J4HbDvWjqmsEQgY63N5xhmycPSzNGuAsrf6oIKq0NNPGLyI 7elWMtTCq84odwNNZGBccXPztvKCzZcEDd1QdEf3mJtsMmW2BPIiHixhe4QjVaXH3Ts3 tv1xGDJHiDeot6t8VWu59pkdVUQrhALC9y4Exxm8C/+3ikb+msjxZQ+zYcDgboh8y0Vr vgzDtlk4ib0m9PiJqVf4Hj0hKBWeyZFkenTMX4VKy0hkhOw5w1pczCYqk9wDsXON/o7O sPGw== X-Gm-Message-State: AMCzsaWin+wylZm6vklULimxTvR1s3P/vBOsMxF9QFZa1whHGxyFabm0 imQnf5JCqKKACZQz6isMSqElRiy55Qv+pgK8mHM= X-Google-Smtp-Source: ABhQp+Sh7Ixw02hCkGvBuh+Cy28TeRngzUcy4ky8oLNpN9Fzf6VjsEOWQIdIzZRXu2J6jFYE+N4GeGWbA5xFup8kDXI= X-Received: by 10.107.3.82 with SMTP id 79mr1486219iod.297.1508413319178; Thu, 19 Oct 2017 04:41:59 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 19 Oct 2017 04:41:58 -0700 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <20171019032836.GA6718@1wt.eu> References: <20171019022929.GB6628@1wt.eu> <20171019032836.GA6718@1wt.eu> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 19 Oct 2017 04:41:58 -0700 Message-ID: Subject: Re: Integer encodings in QUIC frames To: Martin Thomson , Willy Tarreau Cc: QUIC WG Content-Type: multipart/alternative; boundary="001a113ebf82106dbf055be4d859" 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, 19 Oct 2017 11:42:03 -0000 --001a113ebf82106dbf055be4d859 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On fast portable unaligned integer access and endian conversion: If you have a C implementation feel free to use the portable library to abstract endian and unaligned read access in a portable manner. It is just a few header files dealing with endian detection, endian conversion, unaligned access, and compiler warnings, and fallbacks to unsupported platforms: https://github.com/dvidelabs/flatcc/tree/master/include/flatcc/portable The interesting file is: https://github.com/dvidelabs/flatcc/blob/master/include/flatcc/portable/pun= aligned.h It is used by the C flatbuffers implementation, but flatcc is not needed to use the portable sub library, nor are all files in the the portable library - just follow the includes. The library is valuable because it is being used by end users on various non-standard platforms, although I cannot tell how many are using it. With the functions unaligned_write_htobe16 unaligned_write_htobe32 unaligned_write_htobe64 unaligned_read_be16toh unaligned_read_be32toh unaligned_read_be64toh I believe I also have other lengths between 8 and 64 bits, but they are not currently in the public library. They are basically wrappers that combine calls to the above, so only the above have direct native implementations. I have some incomplete QUIC implementation that has a switch to read integers based on a length argument. When QUIC changes from little to big endian it was a very trivial change because they are similar functions for other endian conversions. I also use a subset of this in other projects for hash functions where you need fast unaliged access and sometimes platform neutral wireformat. If you have platform where a slow fallback is in effect in the portable library, but you also know of a faster implementation that you are able to test, feel free to add a PR. Notably unaligned reads are a bit conservative while native endian conversion supports many platforms. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 19 October 2017 at 05.28.45, Willy Tarreau (w@1wt.eu) wrote: On Thu, Oct 19, 2017 at 02:13:23PM +1100, Martin Thomson wrote: > On Thu, Oct 19, 2017 at 1:29 PM, Willy Tarreau wrote: > > word =3D *(uint64_t *)ptr; > > Yeah, we more or less already had that debate and I didn't want a > re-run. I do agree that it seems faster in theory (see below), but > the law of diminishing returns applies here. Also, that code isn't > portable, so it would need a forest of #ifdef statements to safeguard > it. Sure but that's an implementation detail, as the portable code should only include byte-per-byte reading. We all have #ifdef for different architectures in our code where that's relevant. > > word &=3D (1 << (8 * (1 << len) - 2)) - 1; // &=3D mask[len] > > The one optimization I did do, which made my code about 4 times > faster, was to remove this sort of calculation. I don't completely > understand why, but a simple if statement was much faster than this. It's very possible due to the word length distribution. Branch predictors are pretty good and when you realize that most consecutive words are of the same size, you quickly understand why jumps are cheap. My first attempt which I removed before posting was to use a switch/case, which the compiler easily optimizes as "jmp table[len]". > I tried your code and it was a lot slower than my big-endian code on > decoding, though encode was maybe a tiny fraction faster). A table > lookup (mask[len]) was a small bit faster, but it was still in the > order of 2.5 times slower. I think that the branch doesn't cost as > much as you think (it could just be that I have a good branch > predictor on my 5-year-old CPU). Every time I play with code > optimization, I'm surprised by this sort of result. Oh I'm never surprized, in general I experiment, then tweak and only once it works as expected I figure why I initially took the wrong direction ;-) > See https://github.com/martinthomson/quic-int/pull/1 Ah thanks a lot, when I have time I'll play with it. I'm currently finishing the reimplementation of H2 in haproxy and prefer not to switch to some very addicting stuff before that's done you see ;-) Cheers, Willy --001a113ebf82106dbf055be4d859 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = On fast portable una= ligned integer access and endian conversion:


If you have a C implementation feel free to use the portabl= e library to abstract endian and unaligned read access in a portable manner= . It is just a few header files dealing with endian detection, endian conve= rsion, unaligned access, and compiler warnings, and fallbacks to unsupporte= d platforms:
=

=
The interesting file is:
It is used by the C= flatbuffers implementation, but flatcc is not needed to use the portable s= ub library, nor are all files in the the portable library - just follow the= includes.

The library is valuable because it is being used by end = users on various non-standard platforms, although I cannot tell how many ar= e using it.
<= br>
With the = functions=C2=A0
unaligned_write_htobe16
unaligned_write_htobe32
unaligned_write= _htobe64
unaligned_read_be16toh
unaligned_read_be32toh
unaligned_read_be= 64toh
=
I believ= e I also have other lengths between 8 and 64 bits, but they are not current= ly in the public library. They are basically wrappers that combine calls to= the above, so only the above have direct native implementations. I have so= me incomplete QUIC implementation that has a switch to read integers based = on a length argument. When QUIC changes from little to big endian it was a = very trivial change because they are similar functions for other endian con= versions.
I also use = a subset of this in other projects for hash functions where you need fast u= naliged access and sometimes platform neutral wireformat.

If you have platform where a slow fall= back is in effect in the portable library, but you also know of a faster im= plementation that you are able to test, feel free to add a PR. Notably unal= igned reads are a bit conservative while native endian conversion supports = many platforms.


Kind Rega= rds,
Mikkel = Fahn=C3=B8e J=C3=B8rgensen


= On 19 October 2017 at 05.28.45, Willy Tarreau (= w@1wt.eu) wrote:

On Thu, Oct 19, 2017 at 02:13:23PM +1100, Martin Thom= son wrote:
> On Thu, Oct 19, 2017 at 1:29 PM, Willy Tarreau <w@1wt.eu> wrote:
> > word =3D *(uint64_t *)ptr;
> =20
> Yeah, we more or less already had that debate and I didn't wan= t a
> re-run. I do agree that it seems faster in theory (see below), bu= t
> the law of diminishing returns applies here. Also, that code isn&= #39;t
> portable, so it would need a forest of #ifdef statements to safegu= ard
> it.

Sure but that's an implementation detail, as the portable code shou= ld
only include byte-per-byte reading. We all have #ifdef for different
architectures in our code where that's relevant.

> > word &=3D (1 << (8 * (1 << len) - 2)) - 1= ; // &=3D mask[len]
> =20
> The one optimization I did do, which made my code about 4 times
> faster, was to remove this sort of calculation. I don't compl= etely
> understand why, but a simple if statement was much faster than thi= s.

It's very possible due to the word length distribution. Branch pred= ictors
are pretty good and when you realize that most consecutive words are of
the same size, you quickly understand why jumps are cheap. My first
attempt which I removed before posting was to use a switch/case, which
the compiler easily optimizes as "jmp table[len]".

> I tried your code and it was a lot slower than my big-endian code = on
> decoding, though encode was maybe a tiny fraction faster). A tabl= e
> lookup (mask[len]) was a small bit faster, but it was still in the
> order of 2.5 times slower. I think that the branch doesn't co= st as
> much as you think (it could just be that I have a good branch
> predictor on my 5-year-old CPU). Every time I play with code
> optimization, I'm surprised by this sort of result.

Oh I'm never surprized, in general I experiment, then tweak and onl= y
once it works as expected I figure why I initially took the wrong
direction ;-)

> See h= ttps://github.com/martinthomson/quic-int/pull/1

Ah thanks a lot, when I have time I'll play with it. I'm curren= tly finishing
the reimplementation of H2 in haproxy and prefer not to switch to some
very addicting stuff before that's done you see ;-)

Cheers,
Willy

--001a113ebf82106dbf055be4d859-- From nobody Thu Oct 19 05:36: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 4147F133343 for ; Thu, 19 Oct 2017 05:36:06 -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, 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 RQf8YuOg5o4s for ; Thu, 19 Oct 2017 05:36:04 -0700 (PDT) Received: from mail-io0-x233.google.com (mail-io0-x233.google.com [IPv6:2607:f8b0:4001:c06::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 6C4F91332CD for ; Thu, 19 Oct 2017 05:36:03 -0700 (PDT) Received: by mail-io0-x233.google.com with SMTP id f20so9625103ioj.9 for ; Thu, 19 Oct 2017 05:36:03 -0700 (PDT) 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=f0Kj9rbbaK+PfhexsJLSb/0Wol0caqsXGhdvJy/wD/8=; b=TNiUXaEWR7FGWccu50qBa6PhZNycyh0AY3SWFW2kDGz0AULoC1yLv9CIDGJPeTJS9M Fpx5Zen5wOOCG7onslFQNbgeuGuJJQGzwQ0EjzClTBFcLHA/yWmyzMDG9yWLW1liLAdV //YTvYNYrHd6/dWbRiRB+PS0+PUHjgfHIkgDcvyPvnM4Eb9YhMGaAlcb6uAlCgm2Wm1I PJq/3/siqg7d1CY1/i3vGQiuYgFpgKx6bkVRqHUoEmqC6GyfTe0i2l1YMO8hOLT2IUDC S0U6K9hWQiqFJS/7kgxoI1+tGbpeFr6yAR8VHz1rGaLqxC4ECbmj1kTjrtdmHtZRijGj Hk9w== 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=f0Kj9rbbaK+PfhexsJLSb/0Wol0caqsXGhdvJy/wD/8=; b=Z2CJpgnkWmFF/Ir6c+1WC2A7QNmYLA+gsAQTARj22TOjuAiw3Z4jLQve418rlTHXB6 cEhTxscPlk6OFc3dVpqQh1LQy/CRL2B1O3j9uwNavcyZlikKuazIJdraFE6liJgL1wET tlFm8Jm8M8T0uQtOAJcZIEGKHJGILNoYIb/+cz7qquNv8Xs+ih5dCAIOVRvWwEMJ90+1 DHOOAla5qixFvinsAWfang6EX3LdkIo6g6rS3RItnRG09X7NmzfEHbIYKLrKFAom04bR nyCwV/mrnVPqQLsdS4vKMJDOCAafdwovwB4tBVhGtBQD4NNLFu3g2B53G8WBCMy8o6vp rQrg== X-Gm-Message-State: AMCzsaVtFGZgBad12mIpDzfXF3v2sE5QMaZP5gej5Ghe1z9jCl8Jt97C zeTmFz7W4Y620A7uLhGE/hnhfwNRCe0XYtK+xh2ztw== X-Google-Smtp-Source: ABhQp+TFQwtRVFOECFAfHELPIiC6XizsUdSlxtxFF0H2tATwE7I+t6EfUOUOP4foLnncq0KOToayXWhJNHNRamMhYmU= X-Received: by 10.107.205.12 with SMTP id d12mr1613716iog.131.1508416562406; Thu, 19 Oct 2017 05:36:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.4 with HTTP; Thu, 19 Oct 2017 05:35:41 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Thu, 19 Oct 2017 08:35:41 -0400 Message-ID: Subject: Re: Integer encodings in QUIC frames To: Martin Thomson Cc: QUIC WG Content-Type: multipart/alternative; boundary="94eb2c18825a60e588055be5993c" 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, 19 Oct 2017 12:36:06 -0000 --94eb2c18825a60e588055be5993c Content-Type: text/plain; charset="UTF-8" I'm supportive of this change as is, though I think we should consider not changing the ACK delay field for now. I heard enough different opinions on what should be done with it that I don't want consensus on that to hold up this PR. That being said, if everyone is now happy with this ack delay format(or not less happy than before), feel free to land it as is. Your more 'maximal' HTTP change(#888) looked fine as well. On Wed, Oct 18, 2017 at 8:25 PM, Martin Thomson wrote: > Hi All, > > Some of you might have heard discussion about the difficulty of > parsing QUIC frames, or heard me talk about a proposal for reducing > the number of different variations. > > I have a proposal in PR #877 [1] that replaces virtually all of the > integer encodings in frames to use the same variable-length encoding. > This includes the ACK delay timestamp. > > That encoding takes two bits to describe the length of the integer (1, > 2, 4, or 8 octets) and the remainder is big-endian goodness. This > produces ranges that are a bit unusual: 6-, 14-, 30-, or 62-bit. > However, this should cover most use cases and is pretty fast to decode > and to comprehend. > > My testing [2] shows that this is about ~50% slower than using a > simple htonl or equivalent [3], but it can save a lot of bytes, > depending on usage model. > > This would only affect the insides of frames. No changes are made to > the packet header, connection ID, version or error codes, for which > fixed-sized fields are convenient for several reasons. > > The change would mean different limits. We would have 4 times fewer > packets and flow control octets, but 2^30 times more streams. > > This PR doesn't change the HTTP mapping yet. I have two PRs open in > addition to this that make a matching change to the HTTP mapping. > #887 [4] makes the minimum change, effectively ignoring the changes at > the lower layer and sticking to 32-bit identifiers. #888 [5] imports > the integer format more widely. I prefer the latter, but want to hear > more opinions, because it would have consequences for HTTP/2 > compatibility (see the PR for details). I expect that the HTTP > working group will also have some things to say about that, so I plan > to ask them too. > > I haven't proposed more significant changes to the ACK frame; the > encoding change addresses some of the identified shortcomings, but > probably not all of them. More significant changes might be proposed > separately. > > --Martin > > [1] https://github.com/quicwg/base-drafts/pull/877/files > [2] https://github.com/martinthomson/quic-int > [3] All the usual caveats apply. Such as, my machine might not be > representative, and that I didn't spend any time optimizing. > Interesting note though: Feeding my code a counter as input makes it > ~35% faster than an simple endian swap, probably because it uses less > than one quarter of the number of octets. > [4] https://github.com/quicwg/base-drafts/pull/887/files > [5] https://github.com/quicwg/base-drafts/pull/888/files > > --94eb2c18825a60e588055be5993c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'm supportive of this change as is, though I think we= should consider not changing the ACK delay field for now.=C2=A0 I heard en= ough different opinions on what should be done with it that I don't wan= t consensus on that to hold up this PR.=C2=A0 That being said, if everyone = is now happy with this ack delay format(or not less happy than before), fee= l free to land it as is.

Your more 'maximal' HTT= P change(#888) looked fine as well.
<= br>
On Wed, Oct 18, 2017 at 8:25 PM, Martin Thoms= on <martin.thomson@gmail.com> wrote:
Hi All,

Some of you might have heard discussion about the difficulty of
parsing QUIC frames, or heard me talk about a proposal for reducing
the number of different variations.

I have a proposal in PR #877 [1] that replaces virtually all of the
integer encodings in frames to use the same variable-length encoding.
This includes the ACK delay timestamp.

That encoding takes two bits to describe the length of the integer (1,
2, 4, or 8 octets) and the remainder is big-endian goodness.=C2=A0 This
produces ranges that are a bit unusual: 6-, 14-, 30-, or 62-bit.
However, this should cover most use cases and is pretty fast to decode
and to comprehend.

My testing [2] shows that this is about ~50% slower than using a
simple htonl or equivalent [3], but it can save a lot of bytes,
depending on usage model.

This would only affect the insides of frames.=C2=A0 No changes are made to<= br> the packet header, connection ID, version or error codes, for which
fixed-sized fields are convenient for several reasons.

The change would mean different limits.=C2=A0 We would have 4 times fewer packets and flow control octets, but 2^30 times more streams.

This PR doesn't change the HTTP mapping yet.=C2=A0 I have two PRs open = in
addition to this that make a matching change to the HTTP mapping.
#887 [4] makes the minimum change, effectively ignoring the changes at
the lower layer and sticking to 32-bit identifiers.=C2=A0 #888 [5] imports<= br> the integer format more widely.=C2=A0 I prefer the latter, but want to hear=
more opinions, because it would have consequences for HTTP/2
compatibility (see the PR for details).=C2=A0 I expect that the HTTP
working group will also have some things to say about that, so I plan
to ask them too.

I haven't proposed more significant changes to the ACK frame; the
encoding change addresses some of the identified shortcomings, but
probably not all of them.=C2=A0 More significant changes might be proposed<= br> separately.

--Martin

[1] https://github.com/quicwg/base-drafts/p= ull/877/files
[2] https://github.com/martinthomson/quic-int
[3] All the usual caveats apply.=C2=A0 Such as, my machine might not be
representative, and that I didn't spend any time optimizing.
Interesting note though: Feeding my code a counter as input makes it
~35% faster than an simple endian swap, probably because it uses less
than one quarter of the number of octets.
[4] https://github.com/quicwg/base-drafts/p= ull/887/files
[5] https://github.com/quicwg/base-drafts/p= ull/888/files


--94eb2c18825a60e588055be5993c-- From nobody Thu Oct 19 13:04: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 9605C129A89 for ; Thu, 19 Oct 2017 13:04:33 -0700 (PDT) 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 IGwwla-1OFd5 for ; Thu, 19 Oct 2017 13:04:31 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 635251270AB for ; Thu, 19 Oct 2017 13:04:30 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v9JK4O8P008608; Thu, 19 Oct 2017 22:04:24 +0200 Date: Thu, 19 Oct 2017 22:04:24 +0200 From: Willy Tarreau To: Martin Thomson Cc: QUIC WG Subject: Re: Integer encodings in QUIC frames Message-ID: <20171019200424.GA8580@1wt.eu> References: <20171019022929.GB6628@1wt.eu> <20171019032836.GA6718@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171019032836.GA6718@1wt.eu> 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: Thu, 19 Oct 2017 20:04:33 -0000 Hi Martin, On Thu, Oct 19, 2017 at 05:28:36AM +0200, Willy Tarreau wrote: > On Thu, Oct 19, 2017 at 02:13:23PM +1100, Martin Thomson wrote: > > On Thu, Oct 19, 2017 at 1:29 PM, Willy Tarreau wrote: > > > word = *(uint64_t *)ptr; > > > > Yeah, we more or less already had that debate and I didn't want a > > re-run. I do agree that it seems faster in theory (see below), but > > the law of diminishing returns applies here. Also, that code isn't > > portable, so it would need a forest of #ifdef statements to safeguard > > it. > > Sure but that's an implementation detail, as the portable code should > only include byte-per-byte reading. We all have #ifdef for different > architectures in our code where that's relevant. > > > > word &= (1 << (8 * (1 << len) - 2)) - 1; // &= mask[len] > > > > The one optimization I did do, which made my code about 4 times > > faster, was to remove this sort of calculation. I don't completely > > understand why, but a simple if statement was much faster than this. > > It's very possible due to the word length distribution. Branch predictors > are pretty good and when you realize that most consecutive words are of > the same size, you quickly understand why jumps are cheap. My first > attempt which I removed before posting was to use a switch/case, which > the compiler easily optimizes as "jmp table[len]". So I found the reason, I managed to rewrite it a bit differently and make it 20-75% faster than the BE code, but there's a fundamental issue in doing it this way. First, a copy-paste of the results before I lose them : willy@pcw:/data/git/mirror/quic-int$ ./bench64 r 2>/dev/null Encoding and decoding 1000 integers over 1000 iterations --- Type --- Encode Decode Length memcpy: 1380 1798 8000 endian: 2197 1650 8000 highbitbe: 19316 15845 8987 highbitle: 20546 19824 8987 quic: 3557 3558 8000 quicle: 3551 2030 8000 willy@pcw:/data/git/mirror/quic-int$ ./bench64 t 2>/dev/null Encoding and decoding 1000 integers over 1000 iterations --- Type --- Encode Decode Length memcpy: 1395 1809 8000 endian: 12651 1640 8000 highbitbe: 14433 8459 4254 highbitle: 13336 10397 4254 quic: 3789 3782 3754 quicle: 3741 3157 3754 willy@pcw:/data/git/mirror/quic-int$ ./bench64 c 2>/dev/null Encoding and decoding 1000 integers over 1000 iterations --- Type --- Encode Decode Length memcpy: 1392 1809 8000 endian: 2313 1642 8000 highbitbe: 10551 4261 1872 highbitle: 5175 5113 1872 quic: 3526 3481 1936 quicle: 2669 2678 1936 So the problem here which doesn't happen with the BE code is that the word has to be shifted whatever its length since we're using the first, hence lower, bits to store the length, causing a bit of serialization in the operations. In the BE case, short values don't even have to have a mask applied since they're lower than the bound. That's one less operation. I also noticed that the compiler didn't decide to use the jump array and produces ugly code (though not necessarily suboptimal). By cutting the evaluation size in to (0..1, and 2..3) it's significantly faster. I tried again by computing the shifts by hand to avoid any jump and we stall the pipeline a lot there due to the many shift that happen and serialize operation again. So on this one I'm convinced, better have sort of a big endian mode for variable length encoding. If you want I can send you the patch for the extra experiments, but I doubt you'll make any use of it. Cheers, Willy From nobody Thu Oct 19 13:16: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 24033129A89 for ; Thu, 19 Oct 2017 13:16:43 -0700 (PDT) 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 (1024-bit key) header.d=fb.com header.b=m1Yg9mU/; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=NLqSJIdT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ig2Z7BUqoYu for ; Thu, 19 Oct 2017 13:16:41 -0700 (PDT) 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 CB679133328 for ; Thu, 19 Oct 2017 13:16:39 -0700 (PDT) Received: from pps.filterd (m0109332.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9JKFiZk007748; Thu, 19 Oct 2017 13:16:15 -0700 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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=0cScgpZMxKov1Sm+gPJJcyhwk18l079eW/O1oKL4vjs=; b=m1Yg9mU//OjkmfzdxEr64MVZhfce6LiASDcwmypxtsjZnJ9C3jjuqzwttlPIkWUE9Bkj fBatCGyaCmqtBXZOrcMtEH3Ap4x847rr35X5UyfObw0HMo8NVQZ4tqWAUcROS1vsYZYO OlsE0moefrjKpaYI3lswUPQKvSV2VeuCKmc= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2dq0w08hhe-8 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2017 13:16:15 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.21) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 19 Oct 2017 13:15:01 -0700 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=0cScgpZMxKov1Sm+gPJJcyhwk18l079eW/O1oKL4vjs=; b=NLqSJIdTUkGO7eAL8XjERf+wsNbvDMaf8TWXIM5d37LOH80T7pc/WmUvNvfplRWz44OfTfyxScQ34wd9ahi9xXFfois9qAD5xR5vgsKkT6QbZeabef7Z4XyupsKMWeaEpex5sSAw3DPWe5ccVEawcvsGpAPCieUeBbP8D97m8LI= Received: from DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) by DM5PR15MB1882.namprd15.prod.outlook.com (10.174.247.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.77.7; Thu, 19 Oct 2017 20:14:44 +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.0077.022; Thu, 19 Oct 2017 20:14:44 +0000 From: Roberto Peon To: Willy Tarreau , Martin Thomson CC: QUIC WG Subject: Re: Integer encodings in QUIC frames Thread-Topic: Integer encodings in QUIC frames Thread-Index: AQHTSHDhy0CUE2r+Qk2MSX/1XR6pbKLqc0uAgAAMRICAAARBAIABFjkAgAAC4oA= Date: Thu, 19 Oct 2017 20:14:44 +0000 Message-ID: <0F7B8AE7-1B63-41DD-AB5E-84B5E3FC4C7E@fb.com> References: <20171019022929.GB6628@1wt.eu> <20171019032836.GA6718@1wt.eu> <20171019200424.GA8580@1wt.eu> In-Reply-To: <20171019200424.GA8580@1wt.eu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2620:10d:c090:200::5:4ebf] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1882; 20:yczpOMG10s4Pb0xsZlMONaDwnw8OUXLP9oHCYwM6+BpDx7SfOhkfBEUzY+zjCR16CBsK6anc2/MFr28SUgSZItj1EdmHAG2N4e+X5Oq+8y1RrFT7eMNy2UlwjyIQoeFPMjgQn85Rr2qVRNh19VmPrn9YCKJJ31FVUCDC5O7Wqgw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: ee5940f3-4719-4fd8-1739-08d5172e09ff x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(201703131423095); SRVR:DM5PR15MB1882; x-ms-traffictypediagnostic: DM5PR15MB1882: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(11241501159)(6040450)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(100000703101)(100105400095)(6041248)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(20161123558100)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR15MB1882; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR15MB1882; x-forefront-prvs: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(39860400002)(346002)(189002)(24454002)(199003)(50986999)(14454004)(68736007)(305945005)(77096006)(33656002)(25786009)(2950100002)(5660300001)(8676002)(6506006)(6246003)(53936002)(6436002)(316002)(478600001)(105586002)(110136005)(36756003)(39060400002)(106356001)(97736004)(189998001)(101416001)(3660700001)(76176999)(8936002)(83716003)(99286003)(6486002)(53546010)(3280700002)(229853002)(6116002)(7736002)(81166006)(86362001)(82746002)(102836003)(4326008)(54356999)(6512007)(93886005)(2906002)(2900100001)(81156014)(781001)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1882; 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: text/plain; charset="utf-8" Content-ID: <23EFA0BA6835E04C8FBC8105F689F08E@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 20:14:44.4409 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1882 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_09:, , signatures=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, 19 Oct 2017 20:16:43 -0000 SeKAmW0gYSBiaXQgd29ycmllZCB0aGF0IHRoaXMgc3BlYyBzaW1wbGlmaWNhdGlvbiB3aWxsIGFj dHVhbGx5IGluY3JlYXNlIHRoZSBjb21wbGV4aXR5IG9mIGEgcGVyZm9ybWFudCBpbXBsZW1lbnRh dGlvbi4NCg0KLT1SDQoNCk9uIDEwLzE5LzE3LCAxOjA1IFBNLCAiUVVJQyBvbiBiZWhhbGYgb2Yg V2lsbHkgVGFycmVhdSIgPHF1aWMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Ygd0Axd3Qu ZXU+IHdyb3RlOg0KDQogICAgSGkgTWFydGluLA0KICAgIA0KICAgIE9uIFRodSwgT2N0IDE5LCAy MDE3IGF0IDA1OjI4OjM2QU0gKzAyMDAsIFdpbGx5IFRhcnJlYXUgd3JvdGU6DQogICAgPiBPbiBU aHUsIE9jdCAxOSwgMjAxNyBhdCAwMjoxMzoyM1BNICsxMTAwLCBNYXJ0aW4gVGhvbXNvbiB3cm90 ZToNCiAgICA+ID4gT24gVGh1LCBPY3QgMTksIDIwMTcgYXQgMToyOSBQTSwgV2lsbHkgVGFycmVh dSA8d0Axd3QuZXU+IHdyb3RlOg0KICAgID4gPiA+ICAgICB3b3JkID0gKih1aW50NjRfdCAqKXB0 cjsNCiAgICA+ID4gDQogICAgPiA+IFllYWgsIHdlIG1vcmUgb3IgbGVzcyBhbHJlYWR5IGhhZCB0 aGF0IGRlYmF0ZSBhbmQgSSBkaWRuJ3Qgd2FudCBhDQogICAgPiA+IHJlLXJ1bi4gIEkgZG8gYWdy ZWUgdGhhdCBpdCBzZWVtcyBmYXN0ZXIgaW4gdGhlb3J5IChzZWUgYmVsb3cpLCBidXQNCiAgICA+ ID4gdGhlIGxhdyBvZiBkaW1pbmlzaGluZyByZXR1cm5zIGFwcGxpZXMgaGVyZS4gIEFsc28sIHRo YXQgY29kZSBpc24ndA0KICAgID4gPiBwb3J0YWJsZSwgc28gaXQgd291bGQgbmVlZCBhIGZvcmVz dCBvZiAjaWZkZWYgc3RhdGVtZW50cyB0byBzYWZlZ3VhcmQNCiAgICA+ID4gaXQuDQogICAgPiAN CiAgICA+IFN1cmUgYnV0IHRoYXQncyBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwsIGFzIHRoZSBw b3J0YWJsZSBjb2RlIHNob3VsZA0KICAgID4gb25seSBpbmNsdWRlIGJ5dGUtcGVyLWJ5dGUgcmVh ZGluZy4gV2UgYWxsIGhhdmUgI2lmZGVmIGZvciBkaWZmZXJlbnQNCiAgICA+IGFyY2hpdGVjdHVy ZXMgaW4gb3VyIGNvZGUgd2hlcmUgdGhhdCdzIHJlbGV2YW50Lg0KICAgID4gDQogICAgPiA+ID4g ICAgIHdvcmQgJj0gKDEgPDwgKDggKiAoMSA8PCBsZW4pIC0gMikpIC0gMTsgIC8vICY9IG1hc2tb bGVuXQ0KICAgID4gPiANCiAgICA+ID4gVGhlIG9uZSBvcHRpbWl6YXRpb24gSSBkaWQgZG8sIHdo aWNoIG1hZGUgbXkgY29kZSBhYm91dCA0IHRpbWVzDQogICAgPiA+IGZhc3Rlciwgd2FzIHRvIHJl bW92ZSB0aGlzIHNvcnQgb2YgY2FsY3VsYXRpb24uICBJIGRvbid0IGNvbXBsZXRlbHkNCiAgICA+ ID4gdW5kZXJzdGFuZCB3aHksIGJ1dCBhIHNpbXBsZSBpZiBzdGF0ZW1lbnQgd2FzIG11Y2ggZmFz dGVyIHRoYW4gdGhpcy4NCiAgICA+IA0KICAgID4gSXQncyB2ZXJ5IHBvc3NpYmxlIGR1ZSB0byB0 aGUgd29yZCBsZW5ndGggZGlzdHJpYnV0aW9uLiBCcmFuY2ggcHJlZGljdG9ycw0KICAgID4gYXJl IHByZXR0eSBnb29kIGFuZCB3aGVuIHlvdSByZWFsaXplIHRoYXQgbW9zdCBjb25zZWN1dGl2ZSB3 b3JkcyBhcmUgb2YNCiAgICA+IHRoZSBzYW1lIHNpemUsIHlvdSBxdWlja2x5IHVuZGVyc3RhbmQg d2h5IGp1bXBzIGFyZSBjaGVhcC4gTXkgZmlyc3QNCiAgICA+IGF0dGVtcHQgd2hpY2ggSSByZW1v dmVkIGJlZm9yZSBwb3N0aW5nIHdhcyB0byB1c2UgYSBzd2l0Y2gvY2FzZSwgd2hpY2gNCiAgICA+ IHRoZSBjb21waWxlciBlYXNpbHkgb3B0aW1pemVzIGFzICJqbXAgdGFibGVbbGVuXSIuDQogICAg DQogICAgU28gSSBmb3VuZCB0aGUgcmVhc29uLCBJIG1hbmFnZWQgdG8gcmV3cml0ZSBpdCBhIGJp dCBkaWZmZXJlbnRseSBhbmQgbWFrZQ0KICAgIGl0IDIwLTc1JSBmYXN0ZXIgdGhhbiB0aGUgQkUg Y29kZSwgYnV0IHRoZXJlJ3MgYSBmdW5kYW1lbnRhbCBpc3N1ZSBpbg0KICAgIGRvaW5nIGl0IHRo aXMgd2F5LiBGaXJzdCwgYSBjb3B5LXBhc3RlIG9mIHRoZSByZXN1bHRzIGJlZm9yZSBJIGxvc2Ug dGhlbSA6DQogICAgDQogICAgd2lsbHlAcGN3Oi9kYXRhL2dpdC9taXJyb3IvcXVpYy1pbnQkIC4v YmVuY2g2NCByIDI+L2Rldi9udWxsIA0KICAgIEVuY29kaW5nIGFuZCBkZWNvZGluZyAxMDAwIGlu dGVnZXJzIG92ZXIgMTAwMCBpdGVyYXRpb25zDQogICAgLS0tIFR5cGUgLS0tICAgICBFbmNvZGUg ICAgICAgICAgRGVjb2RlICAgICAgICAgIExlbmd0aA0KICAgIG1lbWNweTogICAgICAgICAgICAg MTM4MCAgICAgICAgICAgIDE3OTggICAgICAgICAgICA4MDAwDQogICAgZW5kaWFuOiAgICAgICAg ICAgICAyMTk3ICAgICAgICAgICAgMTY1MCAgICAgICAgICAgIDgwMDANCiAgICBoaWdoYml0YmU6 ICAgICAgICAgMTkzMTYgICAgICAgICAgIDE1ODQ1ICAgICAgICAgICAgODk4Nw0KICAgIGhpZ2hi aXRsZTogICAgICAgICAyMDU0NiAgICAgICAgICAgMTk4MjQgICAgICAgICAgICA4OTg3DQogICAg cXVpYzogICAgICAgICAgICAgICAzNTU3ICAgICAgICAgICAgMzU1OCAgICAgICAgICAgIDgwMDAN CiAgICBxdWljbGU6ICAgICAgICAgICAgIDM1NTEgICAgICAgICAgICAyMDMwICAgICAgICAgICAg ODAwMA0KICAgIHdpbGx5QHBjdzovZGF0YS9naXQvbWlycm9yL3F1aWMtaW50JCAuL2JlbmNoNjQg dCAyPi9kZXYvbnVsbCANCiAgICBFbmNvZGluZyBhbmQgZGVjb2RpbmcgMTAwMCBpbnRlZ2VycyBv dmVyIDEwMDAgaXRlcmF0aW9ucw0KICAgIC0tLSBUeXBlIC0tLSAgICAgRW5jb2RlICAgICAgICAg IERlY29kZSAgICAgICAgICBMZW5ndGgNCiAgICBtZW1jcHk6ICAgICAgICAgICAgIDEzOTUgICAg ICAgICAgICAxODA5ICAgICAgICAgICAgODAwMA0KICAgIGVuZGlhbjogICAgICAgICAgICAxMjY1 MSAgICAgICAgICAgIDE2NDAgICAgICAgICAgICA4MDAwDQogICAgaGlnaGJpdGJlOiAgICAgICAg IDE0NDMzICAgICAgICAgICAgODQ1OSAgICAgICAgICAgIDQyNTQNCiAgICBoaWdoYml0bGU6ICAg ICAgICAgMTMzMzYgICAgICAgICAgIDEwMzk3ICAgICAgICAgICAgNDI1NA0KICAgIHF1aWM6ICAg ICAgICAgICAgICAgMzc4OSAgICAgICAgICAgIDM3ODIgICAgICAgICAgICAzNzU0DQogICAgcXVp Y2xlOiAgICAgICAgICAgICAzNzQxICAgICAgICAgICAgMzE1NyAgICAgICAgICAgIDM3NTQNCiAg ICB3aWxseUBwY3c6L2RhdGEvZ2l0L21pcnJvci9xdWljLWludCQgLi9iZW5jaDY0IGMgMj4vZGV2 L251bGwgDQogICAgRW5jb2RpbmcgYW5kIGRlY29kaW5nIDEwMDAgaW50ZWdlcnMgb3ZlciAxMDAw IGl0ZXJhdGlvbnMNCiAgICAtLS0gVHlwZSAtLS0gICAgIEVuY29kZSAgICAgICAgICBEZWNvZGUg ICAgICAgICAgTGVuZ3RoDQogICAgbWVtY3B5OiAgICAgICAgICAgICAxMzkyICAgICAgICAgICAg MTgwOSAgICAgICAgICAgIDgwMDANCiAgICBlbmRpYW46ICAgICAgICAgICAgIDIzMTMgICAgICAg ICAgICAxNjQyICAgICAgICAgICAgODAwMA0KICAgIGhpZ2hiaXRiZTogICAgICAgICAxMDU1MSAg ICAgICAgICAgIDQyNjEgICAgICAgICAgICAxODcyDQogICAgaGlnaGJpdGxlOiAgICAgICAgICA1 MTc1ICAgICAgICAgICAgNTExMyAgICAgICAgICAgIDE4NzINCiAgICBxdWljOiAgICAgICAgICAg ICAgIDM1MjYgICAgICAgICAgICAzNDgxICAgICAgICAgICAgMTkzNg0KICAgIHF1aWNsZTogICAg ICAgICAgICAgMjY2OSAgICAgICAgICAgIDI2NzggICAgICAgICAgICAxOTM2DQogICAgDQogICAg U28gdGhlIHByb2JsZW0gaGVyZSB3aGljaCBkb2Vzbid0IGhhcHBlbiB3aXRoIHRoZSBCRSBjb2Rl IGlzIHRoYXQNCiAgICB0aGUgd29yZCBoYXMgdG8gYmUgc2hpZnRlZCB3aGF0ZXZlciBpdHMgbGVu Z3RoIHNpbmNlIHdlJ3JlIHVzaW5nDQogICAgdGhlIGZpcnN0LCBoZW5jZSBsb3dlciwgYml0cyB0 byBzdG9yZSB0aGUgbGVuZ3RoLCBjYXVzaW5nIGEgYml0IG9mDQogICAgc2VyaWFsaXphdGlvbiBp biB0aGUgb3BlcmF0aW9ucy4gSW4gdGhlIEJFIGNhc2UsIHNob3J0IHZhbHVlcyBkb24ndA0KICAg IGV2ZW4gaGF2ZSB0byBoYXZlIGEgbWFzayBhcHBsaWVkIHNpbmNlIHRoZXkncmUgbG93ZXIgdGhh biB0aGUNCiAgICBib3VuZC4gVGhhdCdzIG9uZSBsZXNzIG9wZXJhdGlvbi4gSSBhbHNvIG5vdGlj ZWQgdGhhdCB0aGUgY29tcGlsZXINCiAgICBkaWRuJ3QgZGVjaWRlIHRvIHVzZSB0aGUganVtcCBh cnJheSBhbmQgcHJvZHVjZXMgdWdseSBjb2RlICh0aG91Z2gNCiAgICBub3QgbmVjZXNzYXJpbHkg c3Vib3B0aW1hbCkuIEJ5IGN1dHRpbmcgdGhlIGV2YWx1YXRpb24gc2l6ZSBpbiB0bw0KICAgICgw Li4xLCBhbmQgMi4uMykgaXQncyBzaWduaWZpY2FudGx5IGZhc3Rlci4NCiAgICANCiAgICBJIHRy aWVkIGFnYWluIGJ5IGNvbXB1dGluZyB0aGUgc2hpZnRzIGJ5IGhhbmQgdG8gYXZvaWQgYW55IGp1 bXANCiAgICBhbmQgd2Ugc3RhbGwgdGhlIHBpcGVsaW5lIGEgbG90IHRoZXJlIGR1ZSB0byB0aGUg bWFueSBzaGlmdCB0aGF0DQogICAgaGFwcGVuIGFuZCBzZXJpYWxpemUgb3BlcmF0aW9uIGFnYWlu Lg0KICAgIA0KICAgIFNvIG9uIHRoaXMgb25lIEknbSBjb252aW5jZWQsIGJldHRlciBoYXZlIHNv cnQgb2YgYSBiaWcgZW5kaWFuDQogICAgbW9kZSBmb3IgdmFyaWFibGUgbGVuZ3RoIGVuY29kaW5n Lg0KICAgIA0KICAgIElmIHlvdSB3YW50IEkgY2FuIHNlbmQgeW91IHRoZSBwYXRjaCBmb3IgdGhl IGV4dHJhIGV4cGVyaW1lbnRzLA0KICAgIGJ1dCBJIGRvdWJ0IHlvdSdsbCBtYWtlIGFueSB1c2Ug b2YgaXQuDQogICAgDQogICAgQ2hlZXJzLA0KICAgIFdpbGx5DQogICAgDQogICAgDQoNCg== From nobody Thu Oct 19 13:24: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 BFDFF13306B for ; Thu, 19 Oct 2017 13:24:22 -0700 (PDT) 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 IVF6xqTnvlDA for ; Thu, 19 Oct 2017 13:24:20 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 6A91E1320C9 for ; Thu, 19 Oct 2017 13:24:20 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v9JKOEN6008672; Thu, 19 Oct 2017 22:24:14 +0200 Date: Thu, 19 Oct 2017 22:24:14 +0200 From: Willy Tarreau To: Roberto Peon Cc: Martin Thomson , QUIC WG Subject: Re: Integer encodings in QUIC frames Message-ID: <20171019202414.GA8669@1wt.eu> References: <20171019022929.GB6628@1wt.eu> <20171019032836.GA6718@1wt.eu> <20171019200424.GA8580@1wt.eu> <0F7B8AE7-1B63-41DD-AB5E-84B5E3FC4C7E@fb.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0F7B8AE7-1B63-41DD-AB5E-84B5E3FC4C7E@fb.com> 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: Thu, 19 Oct 2017 20:24:23 -0000 Hi Roberto, On Thu, Oct 19, 2017 at 08:14:44PM +0000, Roberto Peon wrote: > I'm a bit worried that this spec simplification will actually increase the complexity of a performant implementation. No, Martin's implementation is quite good in fact. I thought that by turning the words to little endian we could go even faster but that's not the case. At least with the big endian version, we have the ability to read a word at once, check it, reverse it and apply the mask if needed. The code remains quite trivial. Willy From nobody Thu Oct 19 13:39: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 AF5F213307F for ; Thu, 19 Oct 2017 13:39:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, 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 ynnJkzihXtPz for ; Thu, 19 Oct 2017 13:39:44 -0700 (PDT) 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 28BEA13306B for ; Thu, 19 Oct 2017 13:39:44 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id o135so11255066itb.0 for ; Thu, 19 Oct 2017 13:39:44 -0700 (PDT) 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=+UxO1XTbeQ0jY2G82/ATeVyewAHMerfbCsvGDh5DIrI=; b=kSHAx0izRwbphtvtik+HqG8XCifzy2V5/vFtXG3CpjmhehzKZakWB6JefuhavVaSY/ iWlJae7v33VsWbFzsdS7CT45tc3tbx2QoTN7LbXixH2jNoRetscETRqkVQmfpaxO5Vu0 7qwwTyMTo/9x/UqXi/Q61FmSRACeefoX41gD+SUhmP4nF4DbwePKU87Sm6aKyeBVz4ht 662+RyVL74KkkcLwqubO1OFiVEUlrOEB7q6dKTMT8biuWoq/sdNie2+BI4hK5kJbs2TS hGwLLiPUyH5H++snij5YHgHYVcPsGSGJnlYKX2jrQMBoHhUAL29zjJWw8UAyUDeHkJ7t 6s8g== 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=+UxO1XTbeQ0jY2G82/ATeVyewAHMerfbCsvGDh5DIrI=; b=bSjYA6ma/kcq57+dbDYQXiJcaNC/A5tXWbpMzTMh20NVyJmKcGvejRs0sbojKiuchb iItOTcqEvg+sYK/0OxYdXKonZq/NRh6lIUMbZTlquEdBi7eqlzP36Pn58r861Udvq090 iPjpM5aN6KFxj1N8rwhwWEOeMi+k9mG4V7WaYpLx4gmXu+3IdXegH4dnW2xduyglC+kl vOMHmZeFuzkv/aG4psX18i71xS0a8qGCvSPUApVb79s4v7qSeF/nnPKf5G/zIoxaX6m7 GpJ5ePgHT/PB1WKZ30IdQN+ABPm3n2oPNsT211HhRJOZYzWgA9Sp1Wi+YZtYM2oMyMdt HMfA== X-Gm-Message-State: AMCzsaV5p5Pnqh2vAEgQWBDN7lGPxVLILD81sfmo3a1WSlRVEqJ+Lwun f2XP20Z6WwlVJjQjGq0BHhaQ2fcMUdL5pdZ8hn9ZNQ== X-Google-Smtp-Source: ABhQp+So5AbX2NPKJJ9ocsSp9YFhn6Lil7VOglBw46Y4wG3THZCSuk5Wq+JItkmTE81BM1BhTyti/5xlYamQUqrEAhk= X-Received: by 10.36.250.4 with SMTP id v4mr4270700ith.31.1508445583477; Thu, 19 Oct 2017 13:39:43 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 19 Oct 2017 16:39:42 -0400 From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= In-Reply-To: <20171019202414.GA8669@1wt.eu> References: <20171019022929.GB6628@1wt.eu> <20171019032836.GA6718@1wt.eu> <20171019200424.GA8580@1wt.eu> <0F7B8AE7-1B63-41DD-AB5E-84B5E3FC4C7E@fb.com> <20171019202414.GA8669@1wt.eu> X-Mailer: Airmail (420) MIME-Version: 1.0 Date: Thu, 19 Oct 2017 16:39:42 -0400 Message-ID: Subject: Re: Integer encodings in QUIC frames To: Willy Tarreau , Roberto Peon Cc: Martin Thomson , QUIC WG Content-Type: multipart/alternative; boundary="94eb2c0354222a9191055bec5bd5" 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, 19 Oct 2017 20:39:46 -0000 --94eb2c0354222a9191055bec5bd5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable There is nothing inherent in the new encoding format that is more difficult than it was before. The length of the stored values was just encoded all over the place. Either way you must deal with unaligned access, endian conversion, and different integer lengths. It is not a simple task, but the the default platform neutral implementation is not very slow in the overall picture, but it can be very fast with the proper native support, and that takes a lot of work to get right. But again, it applies regardless of how integers are encoded. Kind Regards, Mikkel Fahn=C3=B8e J=C3=B8rgensen On 19 October 2017 at 22.24.26, Willy Tarreau (w@1wt.eu) wrote: Hi Roberto, On Thu, Oct 19, 2017 at 08:14:44PM +0000, Roberto Peon wrote: > I'm a bit worried that this spec simplification will actually increase the complexity of a performant implementation. No, Martin's implementation is quite good in fact. I thought that by turning the words to little endian we could go even faster but that's not the case. At least with the big endian version, we have the ability to read a word at once, check it, reverse it and apply the mask if needed. The code remains quite trivial. Willy --94eb2c0354222a9191055bec5bd5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable = There is nothing inh= erent in the new encoding format that is more difficult than it was before.= The length of the stored values was just encoded all over the place. Eithe= r way you must deal with unaligned access, endian conversion, and different= integer lengths.

It = is not a simple task, but the the default platform neutral implementation i= s not very slow in the overall picture, but it can be very fast with the pr= oper native support, and that takes a lot of work to get right. But again, = it applies regardless of how integers are encoded.

Kind Regards,
Mikkel Fahn=C3=B8e J=C3=B8rgensen

On 19 October 2017 at 22.24.26, = Willy Tarreau (w@1wt.eu) wrote:

Hi Roberto= ,

On Thu, Oct 19, 2017 at 08:14:44PM +0000, Roberto Peon wrote:
> I'm a bit worried that this spec simplification will actually = increase the complexity of a performant implementation.

No, Martin's implementation is quite good in fact. I thought that b= y
turning the words to little endian we could go even faster but that'= ;s not
the case. At least with the big endian version, we have the ability to
read a word at once, check it, reverse it and apply the mask if needed.
The code remains quite trivial.

Willy

--94eb2c0354222a9191055bec5bd5-- From nobody Thu Oct 19 14:21: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 849591342D6 for ; Thu, 19 Oct 2017 14:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 zohKnX4NIu08 for ; Thu, 19 Oct 2017 14:21:10 -0700 (PDT) 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 11465133011 for ; Thu, 19 Oct 2017 14:21:10 -0700 (PDT) Received: by mail-qk0-x231.google.com with SMTP id k123so12116990qke.3 for ; Thu, 19 Oct 2017 14:21:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=litespeedtech-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=7Xn12YHdJTMYi96AAR+rpTtKLhuxhz99FpqoAE6oRl4=; b=U/AyYagl6KAg9xi+Lju68p0bubK4a18TDOTbT7e+crEDhZdf3l1WJEqBT/FQiypdf8 O8NVVvCCnKdb7xXthJ1F2NnEzdRlLlW7TmiW/OrrpRdv2u6VhBDkWGild4/K7RwQRLD4 cCTbc8fxiNUefwAMcuS0caNxk4zZiNlRvPKxqJQmL48FsRq5d6mZanLguaj50oJIJzSj ZPisPvVioqxqE97CEnV8bA6pFGOBx+lTIEl8crFRp964giYUDcMxQ4cYcqkd9sQQ8gs2 P3A8rmEFVRLgkxqeNZSKrHXUnFSfWVkzhv3jGyCX5h4qJlbaccMX2+9oTjiz5NFSfb+3 7lzA== 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:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=7Xn12YHdJTMYi96AAR+rpTtKLhuxhz99FpqoAE6oRl4=; b=lyDNk+Sbda28UOasW808AY5pOwhILIvXzL76bJcTUcFqrbIy4ZSaz5TKMIFGfUvg42 3rdHF03hVZQw4IzuKrMb6VkMdGHHDB8Dwrq747AFcIK/tjpP6YKctyyNOt2S+bpOV57j AnBE3F7kNo9yU9tswarQHHOpNHmEBKimZsKex+lVgnSi6fPJfXD5VFgE0rD3GqKte132 eYg9XO4y4ZJq9Qxc6W2iYAkyuTtMhOMMIMO1/Uc0890H+4I5hmyILuPGn/WxHcwgfB+8 2FGpwttXSPijFbbRIfrC3u0GWCdKS2eQ5g0gjKoNu1Yvy3ip5QeNeisC5d2HY6jLR9Dy KC3A== X-Gm-Message-State: AMCzsaUfJxIsiJbsmZ/WVDTv/0tHYOu6l/FE/I8INN299qHt9SV+s0dO KFhUIf4l12k+uiPoNDKO3dkddA== X-Google-Smtp-Source: ABhQp+TxtCHweujdqZfJeM0URKSSEeJopbQRjOiYN8gfRAF6Iva0DGodLpk4e468LEfwyErlxMzo6A== X-Received: by 10.55.114.69 with SMTP id n66mr3795004qkc.306.1508448069225; Thu, 19 Oct 2017 14:21:09 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id p39sm10445780qta.18.2017.10.19.14.21.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Oct 2017 14:21:08 -0700 (PDT) Date: Thu, 19 Oct 2017 17:21:06 -0400 From: Dmitri Tikhonov To: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= Cc: Willy Tarreau , Roberto Peon , QUIC WG , Martin Thomson Subject: Re: Integer encodings in QUIC frames Message-ID: <20171019212105.GB3291@ubuntu-dmitri> References: <20171019022929.GB6628@1wt.eu> <20171019032836.GA6718@1wt.eu> <20171019200424.GA8580@1wt.eu> <0F7B8AE7-1B63-41DD-AB5E-84B5E3FC4C7E@fb.com> <20171019202414.GA8669@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: 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: Thu, 19 Oct 2017 21:21:11 -0000 On Thu, Oct 19, 2017 at 04:39:42PM -0400, Mikkel Fahnøe Jørgensen wrote: > There is nothing inherent in the new encoding format that is more difficult > than it was before. The length of the stored values was just encoded all > over the place. Either way you must deal with unaligned access, endian > conversion, and different integer lengths. I think it will be at least a _little_ more difficult: One advantage of the sizes being encoded in the STREAM type byte is that one can calculate required length and check it quickly, e.g. static int gquic_le_parse_stream_frame (const unsigned char *buf, size_t rem_packet_sz, stream_frame_t *stream_frame) { /* 1fdoooss */ const unsigned char *p = buf; const unsigned char *const pend = p + rem_packet_sz; CHECK_SPACE(1, p, pend); const char type = *p++; const unsigned data_len = (type >> 4) & 2; const unsigned offset_len = ((type >> 2) & 7) + 1 - !((type >> 2) & 7); const unsigned stream_id_len = 1 + (type & 3); const unsigned need = data_len + offset_len + stream_id_len; CHECK_SPACE(need, p, pend); Reading lengths and values of variable-sized integers will be more involved (one must also make sure he does not read past the buffer). I like the consistencly of the proposed approach, though. - Dmitri. From nobody Thu Oct 19 15:21: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 94D86134312 for ; Thu, 19 Oct 2017 15:21:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OKi6goTV-I1r for ; Thu, 19 Oct 2017 15:21:52 -0700 (PDT) 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 1FB3413420D for ; Thu, 19 Oct 2017 15:21:52 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id i124so19067065wmf.3 for ; Thu, 19 Oct 2017 15:21:52 -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=Rzzwb4kuinBkF41n2VyVf2LlpPd2rrn+/93v07DYA4w=; b=Nc/A+sEPRjfk3hpCczqMbHSdm4YSmuKj2z6+Co9ggQelXPduFkjqOK+D5lFMnmi270 miaWWxf/Ux8E9J/VoQMAnF5LSjnHXPSMBfbI43ZpvQiuyGhH6GfrWMLQsFO0pStU/4Ot SM15yww5SjXtCMdPQAQ0bO9qexcqrk5cnWF0Gn4SXeR4pQUs1pnBibp+hcOLvZIqHqBw n3qa2hHvA5GmgSCzpdwVCwPCXtxjvudqNwCTmMYCUuzGTGOVaAkgxCLi8arB9ndA9DCv n59U7+C3hEVbUDGrewKngy3+ovksy4XVvntfK3+Tb6vkhpbSu+vJTa3pMf9bWOwJRs2k 9kpg== 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=Rzzwb4kuinBkF41n2VyVf2LlpPd2rrn+/93v07DYA4w=; b=B3WpPwQXG/D8zwueG+SiIdPxvZqF7r2Le7Yo6XzUOIzY58nkS6zVLNy/2yuxDNvy9+ x8tt4mJiknctcMsLuoLBAjUm15kORFMnuTLWjBleODMAz0rfZFjNDEbDOBDjjIG4w7sr lIsFUC0ksx/M19eY6Pp8OYMIct+i/TUyvaRWlWSgd0nzh+6HTfjxqm1YlYgg94XALcrn 3RLDdErH6KVwpTnzPh9twyLh9Hav82kN6sVybyOfBpnAU04ihT/pvYgn7EQN80C8Ongh 5AGFkfj8eWeoNVTphiZAhKwVQY6Ek//T/Z19rUs0D/QQAilnIm49WvDHAbSJPwpykVIH 3ing== X-Gm-Message-State: AMCzsaWTe+SIvf4gvSELnmho/bCGdNrK1xb6I5gKVipWHnofrJwf8hfP v1aKuuj+vJJsek/sicb8axCIGBg1cY8Sd7gBdJ8= X-Google-Smtp-Source: ABhQp+SrOU1zHjahlHqDAliKall+J9HOcSD1dy1Wycq5hxa6BkohMXPqflucq8QqimY3Ox/jpGsXMa2UkhPARzNVDrs= X-Received: by 10.28.234.197 with SMTP id g66mr2569985wmi.76.1508451710661; Thu, 19 Oct 2017 15:21:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.60 with HTTP; Thu, 19 Oct 2017 15:21:49 -0700 (PDT) In-Reply-To: References: <20171019022929.GB6628@1wt.eu> <20171019032836.GA6718@1wt.eu> <20171019200424.GA8580@1wt.eu> <0F7B8AE7-1B63-41DD-AB5E-84B5E3FC4C7E@fb.com> <20171019202414.GA8669@1wt.eu> From: Martin Duke Date: Thu, 19 Oct 2017 15:21:49 -0700 Message-ID: Subject: Re: Integer encodings in QUIC frames To: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= Cc: Willy Tarreau , Roberto Peon , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="001a11477abc5ff9b9055bedc808" 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, 19 Oct 2017 22:21:53 -0000 --001a11477abc5ff9b9055bedc808 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's important to be clear that length of stored values is *still* "encoded all over the place". Some fields have length encoded into the first two bits, while others still use flags in the frame header. I would argue that this change actually makes things more complicated. However, it is strictly superior in addressing particular issues in the ack frame, like gaps of more than 255 packet numbers. On Thu, Oct 19, 2017 at 1:39 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen wrote: > There is nothing inherent in the new encoding format that is more > difficult than it was before. The length of the stored values was just > encoded all over the place. Either way you must deal with unaligned acces= s, > endian conversion, and different integer lengths. > > It is not a simple task, but the the default platform neutral > implementation is not very slow in the overall picture, but it can be ver= y > fast with the proper native support, and that takes a lot of work to get > right. But again, it applies regardless of how integers are encoded. > > Kind Regards, > Mikkel Fahn=C3=B8e J=C3=B8rgensen > > > On 19 October 2017 at 22.24.26, Willy Tarreau (w@1wt.eu) wrote: > > Hi Roberto, > > On Thu, Oct 19, 2017 at 08:14:44PM +0000, Roberto Peon wrote: > > I'm a bit worried that this spec simplification will actually increase > the complexity of a performant implementation. > > No, Martin's implementation is quite good in fact. I thought that by > turning the words to little endian we could go even faster but that's not > the case. At least with the big endian version, we have the ability to > read a word at once, check it, reverse it and apply the mask if needed. > The code remains quite trivial. > > Willy > > --001a11477abc5ff9b9055bedc808 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's important to be clear that length of stored value= s is *still* "encoded all over the place". Some fields have lengt= h encoded into the first two bits, while others still use flags in the fram= e header.

I would argue that this change actually makes = things more complicated. However, it is strictly superior in addressing par= ticular issues in the ack frame, like gaps of more than 255 packet numbers.=

On Th= u, Oct 19, 2017 at 1:39 PM, Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@g= mail.com> wrote:
There is nothi= ng inherent in the new encoding format that is more difficult than it was b= efore. The length of the stored values was just encoded all over the place.= Either way you must deal with unaligned access, endian conversion, and dif= ferent integer lengths.

It is not a simple task, but= the the default platform neutral implementation is not very slow in the ov= erall picture, but it can be very fast with the proper native support, and = that takes a lot of work to get right. But again, it applies regardless of = how integers are encoded.

Kind = Regards,
Mik= kel Fahn=C3=B8e J=C3=B8rgensen


On 19 October 2017 = at 22.24.26, Willy Tarreau (w= @1wt.eu) wrote:

Hi Roberto,

On Thu, Oct 19, 2017 at 08:14:44PM +0000, Roberto Peon wrote:
> I'm a bit worried that this spec simplification will actually = increase the complexity of a performant implementation.

No, Martin's implementation is quite good in fact. I thought that b= y
turning the words to little endian we could go even faster but that'= ;s not
the case. At least with the big endian version, we have the ability to
read a word at once, check it, reverse it and apply the mask if needed.
The code remains quite trivial.

Willy


--001a11477abc5ff9b9055bedc808-- From nobody Thu Oct 19 15:50: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 F0164132355 for ; Thu, 19 Oct 2017 15:50:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ogre.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fybNTVwoauH1 for ; Thu, 19 Oct 2017 15:50:17 -0700 (PDT) Received: from cosmo.ogre.com (cosmo4.ogre.com [71.6.165.248]) (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 F16F81320DC for ; Thu, 19 Oct 2017 15:50:16 -0700 (PDT) Received: by cosmo.ogre.com (8.15.2/8.15.2) with ESMTPSA id v9JMoFMu003195 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 15:50:15 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ogre.com; s=03062012; t=1508453416; bh=xNCEc4F5c4lrFYojY325uXaqfrD+iuY079SzHPYsPps=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=NKo/v+oebOBwfAheKrnvFnQdeZzNYXlyDFx27jQEqy1Sl47PKUIpAuLAzwCY2n74E v58aadsAhP8BFW7ho6QcVD2aER+j1eujyKb/C7rDrsAee0WbF2pyVVZjwa5GosBzrB 2aBllpsVQV/VGE/tKYol/v/mHgfzY5Hswz4Isx9Q= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: Integer encodings in QUIC frames From: Leif Hedstrom In-Reply-To: Date: Thu, 19 Oct 2017 16:50:14 -0600 Cc: QUIC WG Content-Transfer-Encoding: quoted-printable Message-Id: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> References: To: Martin Thomson X-Mailer: Apple Mail (2.3445.1.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, 19 Oct 2017 22:50:18 -0000 > On Oct 18, 2017, at 6:25 PM, Martin Thomson = wrote: >=20 > Hi All, >=20 > Some of you might have heard discussion about the difficulty of > parsing QUIC frames, or heard me talk about a proposal for reducing > the number of different variations. >=20 > I have a proposal in PR #877 [1] that replaces virtually all of the > integer encodings in frames to use the same variable-length encoding. > This includes the ACK delay timestamp. >=20 > That encoding takes two bits to describe the length of the integer (1, > 2, 4, or 8 octets) and the remainder is big-endian goodness. This > produces ranges that are a bit unusual: 6-, 14-, 30-, or 62-bit. > However, this should cover most use cases and is pretty fast to decode > and to comprehend. I always wondered what sort of real-world impact this micro optimization = of variable integer length actually has. Do we have numbers on that? It = seems like a complicated implementation in general, with perhaps = questionable benefits? Cheers, =E2=80=94 leif From nobody Thu Oct 19 16: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 5ECA31330B0 for ; Thu, 19 Oct 2017 16:43:20 -0700 (PDT) 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=jKsuzJlN; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=DWMjeUcj Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6WPF03xetW3K for ; Thu, 19 Oct 2017 16:43:18 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 6EAF31320DC for ; Thu, 19 Oct 2017 16:43:18 -0700 (PDT) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9JNZC0S020770; Thu, 19 Oct 2017 16:42:53 -0700 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=4K2SfVwjRH8UQIM/JrWmUJlvkluoQIjlwJGnjzxUSds=; b=jKsuzJlNG0xjYqnugdPrEAfcpEc4QpYpq0Gs5IeDTyH4ajXi6hq3Mn7mDHofGuiExyco zXc1rwaEfEiHqZM7Lb1q8u4FgFslxsOVaTJdCk08mD6aSEFXsESi6oU6TeDIBMqWmnMx HHcEYgxBnRz48XEvYrjC3PCYwKYqpjSAZMg= Received: from mail.thefacebook.com ([199.201.64.23]) by mx0a-00082601.pphosted.com with ESMTP id 2dq3t90hgs-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 19 Oct 2017 16:42:53 -0700 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (192.168.54.28) by o365-in.thefacebook.com (192.168.16.19) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 19 Oct 2017 16:42:51 -0700 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=4K2SfVwjRH8UQIM/JrWmUJlvkluoQIjlwJGnjzxUSds=; b=DWMjeUcjZXnyibunIZkfiiU7+Af9AXoJJ2k9dkvSJAYNQRwj/SsxZjDoXyLlV7WpzlgevC0ye1qIPTw0FEEHXFymVuF9C/s4RWZZTuBR1nmOtq9iklzRqTfBIL3/HA9WOCd8ivgkQpR1a9+ialfEIi7oEKf0GMDeh8KOOXuPwSE= 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.77.7; Thu, 19 Oct 2017 23:42:50 +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.0077.022; Thu, 19 Oct 2017 23:42:50 +0000 From: Roberto Peon To: =?utf-8?B?TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbg==?= , Willy Tarreau CC: Martin Thomson , QUIC WG Subject: Re: Integer encodings in QUIC frames Thread-Topic: Integer encodings in QUIC frames Thread-Index: AQHTSHDhy0CUE2r+Qk2MSX/1XR6pbKLqc0uAgAAMRICAAARBAIABFjkAgAAC4oCAAAKpAIAABFIAgAAzKYA= Date: Thu, 19 Oct 2017 23:42:50 +0000 Message-ID: References: <20171019022929.GB6628@1wt.eu> <20171019032836.GA6718@1wt.eu> <20171019200424.GA8580@1wt.eu> <0F7B8AE7-1B63-41DD-AB5E-84B5E3FC4C7E@fb.com> <20171019202414.GA8669@1wt.eu> 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::5:4ebf] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1883; 20:RXIP/I/LPb1J/+iUOyfnWVQ6+YeRNWif0GJmmjxTsea2jft5blgQrzpl1g8M+PtL/b+80m/4WKFCBve3PBVvbSBsDBnIkt99sTFfbpVV2C3G4bit0mvXJ27QYjYIeYm3dTvzSUvcY8PT7tQqDAz5CfKTF+rfxwPSc1VH37d+TNw= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 1385053a-22b7-46ad-ad60-08d5174b1c3f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254172)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(201703131423095); SRVR:DM5PR15MB1883; x-ms-traffictypediagnostic: DM5PR15MB1883: x-exchange-antispam-report-test: UriScan:(67672495146484)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(11241501159)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(93006095)(93001095)(3002001)(10201501046)(6041248)(20161123562025)(20161123560025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(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: 0465429B7F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(346002)(376002)(189002)(24454002)(199003)(68736007)(4326008)(97736004)(77096006)(8936002)(6246003)(6486002)(316002)(2950100002)(83716003)(8676002)(53546010)(189998001)(6436002)(478600001)(36756003)(25786009)(86362001)(6506006)(54906003)(110136005)(82746002)(81166006)(81156014)(39060400002)(6116002)(54356999)(76176999)(236005)(3280700002)(229853002)(99286003)(2906002)(5660300001)(50986999)(33656002)(102836003)(6512007)(14454004)(54896002)(7736002)(106356001)(2900100001)(101416001)(53936002)(3660700001)(105586002)(93886005)(6306002)(781001)(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_E84C1B08FA3E40DC8148D61DC3E8D36Efbcom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Oct 2017 23:42:50.6089 (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-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-19_12:, , signatures=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, 19 Oct 2017 23:43:20 -0000 --_000_E84C1B08FA3E40DC8148D61DC3E8D36Efbcom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RmFpciBlbm91Z2guIFdvcnJ5aW5nIGFib3V0IG5vdGhpbmcgaXMgbXkgZmF2b3JpdGUga2luZC4N Ci09Ug0KDQpGcm9tOiBNaWtrZWwgRmFobsO4ZSBKw7hyZ2Vuc2VuIDxtaWtrZWxmakBnbWFpbC5j b20+DQpEYXRlOiBUaHVyc2RheSwgT2N0b2JlciAxOSwgMjAxNyBhdCAxOjQwIFBNDQpUbzogV2ls bHkgVGFycmVhdSA8d0Axd3QuZXU+LCBSb2JlcnRvIFBlb24gPGZlbml4QGZiLmNvbT4NCkNjOiBN YXJ0aW4gVGhvbXNvbiA8bWFydGluLnRob21zb25AZ21haWwuY29tPiwgUVVJQyBXRyA8cXVpY0Bp ZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBJbnRlZ2VyIGVuY29kaW5ncyBpbiBRVUlDIGZyYW1lcw0K DQpUaGVyZSBpcyBub3RoaW5nIGluaGVyZW50IGluIHRoZSBuZXcgZW5jb2RpbmcgZm9ybWF0IHRo YXQgaXMgbW9yZSBkaWZmaWN1bHQgdGhhbiBpdCB3YXMgYmVmb3JlLiBUaGUgbGVuZ3RoIG9mIHRo ZSBzdG9yZWQgdmFsdWVzIHdhcyBqdXN0IGVuY29kZWQgYWxsIG92ZXIgdGhlIHBsYWNlLiBFaXRo ZXIgd2F5IHlvdSBtdXN0IGRlYWwgd2l0aCB1bmFsaWduZWQgYWNjZXNzLCBlbmRpYW4gY29udmVy c2lvbiwgYW5kIGRpZmZlcmVudCBpbnRlZ2VyIGxlbmd0aHMuDQoNCkl0IGlzIG5vdCBhIHNpbXBs ZSB0YXNrLCBidXQgdGhlIHRoZSBkZWZhdWx0IHBsYXRmb3JtIG5ldXRyYWwgaW1wbGVtZW50YXRp b24gaXMgbm90IHZlcnkgc2xvdyBpbiB0aGUgb3ZlcmFsbCBwaWN0dXJlLCBidXQgaXQgY2FuIGJl IHZlcnkgZmFzdCB3aXRoIHRoZSBwcm9wZXIgbmF0aXZlIHN1cHBvcnQsIGFuZCB0aGF0IHRha2Vz IGEgbG90IG9mIHdvcmsgdG8gZ2V0IHJpZ2h0LiBCdXQgYWdhaW4sIGl0IGFwcGxpZXMgcmVnYXJk bGVzcyBvZiBob3cgaW50ZWdlcnMgYXJlIGVuY29kZWQuDQoNCktpbmQgUmVnYXJkcywNCk1pa2tl bCBGYWhuw7hlIErDuHJnZW5zZW4NCg0KDQpPbiAxOSBPY3RvYmVyIDIwMTcgYXQgMjIuMjQuMjYs IFdpbGx5IFRhcnJlYXUgKHdAMXd0LmV1PG1haWx0bzp3QDF3dC5ldT4pIHdyb3RlOg0KSGkgUm9i ZXJ0bywNCg0KT24gVGh1LCBPY3QgMTksIDIwMTcgYXQgMDg6MTQ6NDRQTSArMDAwMCwgUm9iZXJ0 byBQZW9uIHdyb3RlOg0KPiBJJ20gYSBiaXQgd29ycmllZCB0aGF0IHRoaXMgc3BlYyBzaW1wbGlm aWNhdGlvbiB3aWxsIGFjdHVhbGx5IGluY3JlYXNlIHRoZSBjb21wbGV4aXR5IG9mIGEgcGVyZm9y bWFudCBpbXBsZW1lbnRhdGlvbi4NCg0KTm8sIE1hcnRpbidzIGltcGxlbWVudGF0aW9uIGlzIHF1 aXRlIGdvb2QgaW4gZmFjdC4gSSB0aG91Z2h0IHRoYXQgYnkNCnR1cm5pbmcgdGhlIHdvcmRzIHRv IGxpdHRsZSBlbmRpYW4gd2UgY291bGQgZ28gZXZlbiBmYXN0ZXIgYnV0IHRoYXQncyBub3QNCnRo ZSBjYXNlLiBBdCBsZWFzdCB3aXRoIHRoZSBiaWcgZW5kaWFuIHZlcnNpb24sIHdlIGhhdmUgdGhl IGFiaWxpdHkgdG8NCnJlYWQgYSB3b3JkIGF0IG9uY2UsIGNoZWNrIGl0LCByZXZlcnNlIGl0IGFu ZCBhcHBseSB0aGUgbWFzayBpZiBuZWVkZWQuDQpUaGUgY29kZSByZW1haW5zIHF1aXRlIHRyaXZp YWwuDQoNCldpbGx5DQo= --_000_E84C1B08FA3E40DC8148D61DC3E8D36Efbcom_ 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 ZTt9DQpwLmFpcm1haWxvbiwgbGkuYWlybWFpbG9uLCBkaXYuYWlybWFpbG9uDQoJe21zby1zdHls ZS1uYW1lOmFpcm1haWxfb247DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9 IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0 aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GYWlyIGVub3VnaC4gV29ycnlpbmcgYWJvdXQg bm90aGluZyBpcyBteSBmYXZvcml0ZSBraW5kLjxicj4NCi09UjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4g MGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbiAmbHQ7bWlr a2VsZmpAZ21haWwuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgT2N0b2JlciAx OSwgMjAxNyBhdCAxOjQwIFBNPGJyPg0KPGI+VG86IDwvYj5XaWxseSBUYXJyZWF1ICZsdDt3QDF3 dC5ldSZndDssIFJvYmVydG8gUGVvbiAmbHQ7ZmVuaXhAZmIuY29tJmd0Ozxicj4NCjxiPkNjOiA8 L2I+TWFydGluIFRob21zb24gJmx0O21hcnRpbi50aG9tc29uQGdtYWlsLmNvbSZndDssIFFVSUMg V0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBJbnRlZ2Vy IGVuY29kaW5ncyBpbiBRVUlDIGZyYW1lczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2IGlkPSJibG9vcF9jdXN0b21mb250Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90 OyxzYW5zLXNlcmlmIj5UaGVyZSBpcyBub3RoaW5nIGluaGVyZW50IGluIHRoZSBuZXcgZW5jb2Rp bmcgZm9ybWF0IHRoYXQgaXMgbW9yZSBkaWZmaWN1bHQgdGhhbiBpdCB3YXMgYmVmb3JlLiBUaGUg bGVuZ3RoIG9mIHRoZSBzdG9yZWQgdmFsdWVzIHdhcyBqdXN0IGVuY29kZWQgYWxsIG92ZXIgdGhl IHBsYWNlLiBFaXRoZXINCiB3YXkgeW91IG11c3QgZGVhbCB3aXRoIHVuYWxpZ25lZCBhY2Nlc3Ms IGVuZGlhbiBjb252ZXJzaW9uLCBhbmQgZGlmZmVyZW50IGludGVnZXIgbGVuZ3Rocy48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXYgaWQ9ImJsb29wX2N1c3RvbWZvbnQiPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBpZD0iYmxvb3BfY3VzdG9tZm9udCI+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SXQgaXMgbm90IGEgc2ltcGxlIHRhc2ssIGJ1 dCB0aGUgdGhlIGRlZmF1bHQgcGxhdGZvcm0gbmV1dHJhbCBpbXBsZW1lbnRhdGlvbiBpcyBub3Qg dmVyeSBzbG93IGluIHRoZSBvdmVyYWxsIHBpY3R1cmUsIGJ1dCBpdCBjYW4gYmUgdmVyeSBmYXN0 IHdpdGggdGhlIHByb3BlciBuYXRpdmUgc3VwcG9ydCwNCiBhbmQgdGhhdCB0YWtlcyBhIGxvdCBv ZiB3b3JrIHRvIGdldCByaWdodC4gQnV0IGFnYWluLCBpdCBhcHBsaWVzIHJlZ2FyZGxlc3Mgb2Yg aG93IGludGVnZXJzIGFyZSBlbmNvZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IGlkPSJibG9v cF9zaWduXzE1MDg0NDU0MjYxMTMxMDI4NDgiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5LaW5kIFJlZ2FyZHMsPG86cD48L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206 MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TWlra2VsIEZhaG7DuGUgSsO4cmdlbnNlbjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJhaXJtYWlsb24iPk9uIDE5IE9jdG9iZXIg MjAxNyBhdCAyMi4yNC4yNiwgV2lsbHkgVGFycmVhdSAoPGEgaHJlZj0ibWFpbHRvOndAMXd0LmV1 Ij53QDF3dC5ldTwvYT4pIHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9 Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+SGkgUm9iZXJ0 bywgPGJyPg0KPGJyPg0KT24gVGh1LCBPY3QgMTksIDIwMTcgYXQgMDg6MTQ6NDRQTSAmIzQzOzAw MDAsIFJvYmVydG8gUGVvbiB3cm90ZTogPGJyPg0KJmd0OyBJJ20gYSBiaXQgd29ycmllZCB0aGF0 IHRoaXMgc3BlYyBzaW1wbGlmaWNhdGlvbiB3aWxsIGFjdHVhbGx5IGluY3JlYXNlIHRoZSBjb21w bGV4aXR5IG9mIGEgcGVyZm9ybWFudCBpbXBsZW1lbnRhdGlvbi4NCjxicj4NCjxicj4NCk5vLCBN YXJ0aW4ncyBpbXBsZW1lbnRhdGlvbiBpcyBxdWl0ZSBnb29kIGluIGZhY3QuIEkgdGhvdWdodCB0 aGF0IGJ5IDxicj4NCnR1cm5pbmcgdGhlIHdvcmRzIHRvIGxpdHRsZSBlbmRpYW4gd2UgY291bGQg Z28gZXZlbiBmYXN0ZXIgYnV0IHRoYXQncyBub3QgPGJyPg0KdGhlIGNhc2UuIEF0IGxlYXN0IHdp dGggdGhlIGJpZyBlbmRpYW4gdmVyc2lvbiwgd2UgaGF2ZSB0aGUgYWJpbGl0eSB0byA8YnI+DQpy ZWFkIGEgd29yZCBhdCBvbmNlLCBjaGVjayBpdCwgcmV2ZXJzZSBpdCBhbmQgYXBwbHkgdGhlIG1h c2sgaWYgbmVlZGVkLiA8YnI+DQpUaGUgY29kZSByZW1haW5zIHF1aXRlIHRyaXZpYWwuIDxicj4N Cjxicj4NCldpbGx5IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90 ZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E84C1B08FA3E40DC8148D61DC3E8D36Efbcom_-- From nobody Thu Oct 19 19:15: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 E5F4E133061 for ; Thu, 19 Oct 2017 19:15:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.811 X-Spam-Level: X-Spam-Status: No, score=-2.811 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, 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=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 IFvvr38bQ2BH for ; Thu, 19 Oct 2017 19:15:07 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0128.outbound.protection.outlook.com [104.47.41.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 A2ED7132403 for ; Thu, 19 Oct 2017 19:15:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=dPMkIcvkuwDZ1HjkPILRHwK0/juBqBRogF3y9QSV664=; b=AuvPnPZqROt8GMYtZzuGCCNXQhH8TuncoF1aChxRRtROcD53a1OfImkii76k4vQB/4aJUZljST5SyMkd42VCSlFD6PplIg0RtzzJa+aHiF7d9f4hhlWf1W7tA55PgeZWfqz2R6yofPjlOa8SYJSBX2nNmtcX3qsvexYQN28ldBE= Received: from CY4PR21MB0277.namprd21.prod.outlook.com (10.173.193.143) by CY4PR21MB0151.namprd21.prod.outlook.com (10.173.189.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.178.1; Fri, 20 Oct 2017 02:15:06 +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.0178.002; Fri, 20 Oct 2017 02:15:06 +0000 From: Praveen Balasubramanian To: Ian Swett , Martin Thomson CC: QUIC WG Subject: RE: Integer encodings in QUIC frames Thread-Topic: Integer encodings in QUIC frames Thread-Index: AQHTSHDTHb8aKdb5D0uEaEIROXIXKKLrHKqAgADjxpA= Date: Fri, 20 Oct 2017 02:15:05 +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: [2001:4898:80e8:4::4e4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR21MB0151; 6:u47A9nxJuvywXJZZb8LpbDNREF+ZRz1llFpE61GLioDYywuKuGZimoNL3Hu0xoQaKhcmKC28Jw0D8G/MUWBzpeGlNUIDNE7gKLBYLkeqND7Amr4BURG56y45HKJfKL85d+sVIXmpP7+/Bnf4lUmOrluSg7n9eXQOhWK11pincbz2qN08CP99EW2R2ixkERRaXKwThmRJu5qI9LK9cQ1n9tZgzK4Jzkeqvg7G3FWY08nQjZQhqFkrIO6qZ22fcLSGd90AYMMwseDE4mpAroxALDbIrWja7CC9Xg6Utbr606qAoWG8n8svSfXkyn9J6s1I0Q61vq3CShUcoWb9WNy99fJVZ0Kn3J6jSKCstZucUno=; 5:Aec74k+uZ8KRS6mJHbX2Im22WRVOnMrrmlWkyd+LBeQ7CzwL2FPi4cyq7XfDm6EmwjgXw7/nqJVq/cchQVLRf65HM6YCsh9ItTHXqmEqLQKnQpzyaBQr3nR3ZC0RoSsD8amDMIiHD42Mk/0ZjcBZBGBeyOn1PCBJcBgSDBJqL4I=; 24:OnUBCw5X4tiVNRg4uJfMKz8uVG+W7+NR1IDW5JGUUw5vALNiQ7Mpyny3UkSA1TQ0g0VvPLygCrIJ6/Z4g0GMEqW1kAHHj0XBckNSKm2dJFA=; 7:TKZ+KgdKnzL08fx4ePaOBMTZiAf1nFwFibeWU+MVPNSmFSzdSP4aHiCLOfjTwMjD6Du8enS/hyyureUQmLy8HJLeJhoE9syezo9XdUPmjCn7nIFj8XZIDPx+GRkikjFQnSV4JiaVR7l4uKLjScUASQKWj1aJNZd4rWcntMFoC83oue1pjSyRm+G2FAocVWh/JCUi45N6LYBIQgoMdNtaZphePbmce+cmuNBbuAlgxH3j18+rv1cMps4oBSuc9Orz x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 633019ec-0f2c-4487-2429-08d51760615b x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603229); SRVR:CY4PR21MB0151; x-ms-traffictypediagnostic: CY4PR21MB0151: x-exchange-antispam-report-test: UriScan:(166708455590820)(189930954265078)(100405760836317)(219752817060721)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(8121501046)(5005006)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(3231020)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR21MB0151; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR21MB0151; x-forefront-prvs: 0466CA5A45 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39860400002)(376002)(47760400005)(199003)(53754006)(189002)(24454002)(77096006)(86612001)(6506006)(97736004)(86362001)(229853002)(8676002)(81156014)(3660700001)(81166006)(6436002)(54896002)(3280700002)(236005)(53936002)(99286003)(10090500001)(19609705001)(55016002)(7696004)(2950100002)(5660300001)(9686003)(6306002)(6246003)(110136005)(4326008)(39060400002)(22452003)(101416001)(189998001)(14454004)(53546010)(8990500004)(561944003)(74316002)(25786009)(54356999)(76176999)(50986999)(606006)(7736002)(33656002)(316002)(2906002)(966005)(102836003)(790700001)(2900100001)(106356001)(105586002)(478600001)(10290500003)(8936002)(6116002)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0151; H:CY4PR21MB0277.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=pravb@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR21MB02771FF7D12D9E684C372A99B6430CY4PR21MB0277namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 633019ec-0f2c-4487-2429-08d51760615b X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Oct 2017 02:15:05.9544 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0151 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, 20 Oct 2017 02:15:10 -0000 --_000_CY4PR21MB02771FF7D12D9E684C372A99B6430CY4PR21MB0277namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGFwcHkgd2l0aCB0aGUgbmV3IGZvcm1hdCBmb3IgdGhlIEFDSyBkZWxheSBmaWVsZC4gQW55dGhp bmcgb3RoZXIgdGhhbiB0aGUgKGN1cnJlbnQpIGN1c3RvbSBmbG9hdGluZyBwb2ludCBmb3JtYXQg aXMgZm9yd2FyZCBwcm9ncmVzcyBldmVuIGlmIHRlbXBvcmFyeS4NCg0KRnJvbTogUVVJQyBbbWFp bHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElhbiBTd2V0dA0KU2VudDog VGh1cnNkYXksIE9jdG9iZXIgMTksIDIwMTcgNTozNiBBTQ0KVG86IE1hcnRpbiBUaG9tc29uIDxt YXJ0aW4udGhvbXNvbkBnbWFpbC5jb20+DQpDYzogUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz4NClN1 YmplY3Q6IFJlOiBJbnRlZ2VyIGVuY29kaW5ncyBpbiBRVUlDIGZyYW1lcw0KDQpJJ20gc3VwcG9y dGl2ZSBvZiB0aGlzIGNoYW5nZSBhcyBpcywgdGhvdWdoIEkgdGhpbmsgd2Ugc2hvdWxkIGNvbnNp ZGVyIG5vdCBjaGFuZ2luZyB0aGUgQUNLIGRlbGF5IGZpZWxkIGZvciBub3cuICBJIGhlYXJkIGVu b3VnaCBkaWZmZXJlbnQgb3BpbmlvbnMgb24gd2hhdCBzaG91bGQgYmUgZG9uZSB3aXRoIGl0IHRo YXQgSSBkb24ndCB3YW50IGNvbnNlbnN1cyBvbiB0aGF0IHRvIGhvbGQgdXAgdGhpcyBQUi4gIFRo YXQgYmVpbmcgc2FpZCwgaWYgZXZlcnlvbmUgaXMgbm93IGhhcHB5IHdpdGggdGhpcyBhY2sgZGVs YXkgZm9ybWF0KG9yIG5vdCBsZXNzIGhhcHB5IHRoYW4gYmVmb3JlKSwgZmVlbCBmcmVlIHRvIGxh bmQgaXQgYXMgaXMuDQoNCllvdXIgbW9yZSAnbWF4aW1hbCcgSFRUUCBjaGFuZ2UoIzg4OCkgbG9v a2VkIGZpbmUgYXMgd2VsbC4NCg0KT24gV2VkLCBPY3QgMTgsIDIwMTcgYXQgODoyNSBQTSwgTWFy dGluIFRob21zb24gPG1hcnRpbi50aG9tc29uQGdtYWlsLmNvbTxtYWlsdG86bWFydGluLnRob21z b25AZ21haWwuY29tPj4gd3JvdGU6DQpIaSBBbGwsDQoNClNvbWUgb2YgeW91IG1pZ2h0IGhhdmUg aGVhcmQgZGlzY3Vzc2lvbiBhYm91dCB0aGUgZGlmZmljdWx0eSBvZg0KcGFyc2luZyBRVUlDIGZy YW1lcywgb3IgaGVhcmQgbWUgdGFsayBhYm91dCBhIHByb3Bvc2FsIGZvciByZWR1Y2luZw0KdGhl IG51bWJlciBvZiBkaWZmZXJlbnQgdmFyaWF0aW9ucy4NCg0KSSBoYXZlIGEgcHJvcG9zYWwgaW4g UFIgIzg3NyBbMV0gdGhhdCByZXBsYWNlcyB2aXJ0dWFsbHkgYWxsIG9mIHRoZQ0KaW50ZWdlciBl bmNvZGluZ3MgaW4gZnJhbWVzIHRvIHVzZSB0aGUgc2FtZSB2YXJpYWJsZS1sZW5ndGggZW5jb2Rp bmcuDQpUaGlzIGluY2x1ZGVzIHRoZSBBQ0sgZGVsYXkgdGltZXN0YW1wLg0KDQpUaGF0IGVuY29k aW5nIHRha2VzIHR3byBiaXRzIHRvIGRlc2NyaWJlIHRoZSBsZW5ndGggb2YgdGhlIGludGVnZXIg KDEsDQoyLCA0LCBvciA4IG9jdGV0cykgYW5kIHRoZSByZW1haW5kZXIgaXMgYmlnLWVuZGlhbiBn b29kbmVzcy4gIFRoaXMNCnByb2R1Y2VzIHJhbmdlcyB0aGF0IGFyZSBhIGJpdCB1bnVzdWFsOiA2 LSwgMTQtLCAzMC0sIG9yIDYyLWJpdC4NCkhvd2V2ZXIsIHRoaXMgc2hvdWxkIGNvdmVyIG1vc3Qg dXNlIGNhc2VzIGFuZCBpcyBwcmV0dHkgZmFzdCB0byBkZWNvZGUNCmFuZCB0byBjb21wcmVoZW5k Lg0KDQpNeSB0ZXN0aW5nIFsyXSBzaG93cyB0aGF0IHRoaXMgaXMgYWJvdXQgfjUwJSBzbG93ZXIg dGhhbiB1c2luZyBhDQpzaW1wbGUgaHRvbmwgb3IgZXF1aXZhbGVudCBbM10sIGJ1dCBpdCBjYW4g c2F2ZSBhIGxvdCBvZiBieXRlcywNCmRlcGVuZGluZyBvbiB1c2FnZSBtb2RlbC4NCg0KVGhpcyB3 b3VsZCBvbmx5IGFmZmVjdCB0aGUgaW5zaWRlcyBvZiBmcmFtZXMuICBObyBjaGFuZ2VzIGFyZSBt YWRlIHRvDQp0aGUgcGFja2V0IGhlYWRlciwgY29ubmVjdGlvbiBJRCwgdmVyc2lvbiBvciBlcnJv ciBjb2RlcywgZm9yIHdoaWNoDQpmaXhlZC1zaXplZCBmaWVsZHMgYXJlIGNvbnZlbmllbnQgZm9y IHNldmVyYWwgcmVhc29ucy4NCg0KVGhlIGNoYW5nZSB3b3VsZCBtZWFuIGRpZmZlcmVudCBsaW1p dHMuICBXZSB3b3VsZCBoYXZlIDQgdGltZXMgZmV3ZXINCnBhY2tldHMgYW5kIGZsb3cgY29udHJv bCBvY3RldHMsIGJ1dCAyXjMwIHRpbWVzIG1vcmUgc3RyZWFtcy4NCg0KVGhpcyBQUiBkb2Vzbid0 IGNoYW5nZSB0aGUgSFRUUCBtYXBwaW5nIHlldC4gIEkgaGF2ZSB0d28gUFJzIG9wZW4gaW4NCmFk ZGl0aW9uIHRvIHRoaXMgdGhhdCBtYWtlIGEgbWF0Y2hpbmcgY2hhbmdlIHRvIHRoZSBIVFRQIG1h cHBpbmcuDQojODg3IFs0XSBtYWtlcyB0aGUgbWluaW11bSBjaGFuZ2UsIGVmZmVjdGl2ZWx5IGln bm9yaW5nIHRoZSBjaGFuZ2VzIGF0DQp0aGUgbG93ZXIgbGF5ZXIgYW5kIHN0aWNraW5nIHRvIDMy LWJpdCBpZGVudGlmaWVycy4gICM4ODggWzVdIGltcG9ydHMNCnRoZSBpbnRlZ2VyIGZvcm1hdCBt b3JlIHdpZGVseS4gIEkgcHJlZmVyIHRoZSBsYXR0ZXIsIGJ1dCB3YW50IHRvIGhlYXINCm1vcmUg b3BpbmlvbnMsIGJlY2F1c2UgaXQgd291bGQgaGF2ZSBjb25zZXF1ZW5jZXMgZm9yIEhUVFAvMg0K Y29tcGF0aWJpbGl0eSAoc2VlIHRoZSBQUiBmb3IgZGV0YWlscykuICBJIGV4cGVjdCB0aGF0IHRo ZSBIVFRQDQp3b3JraW5nIGdyb3VwIHdpbGwgYWxzbyBoYXZlIHNvbWUgdGhpbmdzIHRvIHNheSBh Ym91dCB0aGF0LCBzbyBJIHBsYW4NCnRvIGFzayB0aGVtIHRvby4NCg0KSSBoYXZlbid0IHByb3Bv c2VkIG1vcmUgc2lnbmlmaWNhbnQgY2hhbmdlcyB0byB0aGUgQUNLIGZyYW1lOyB0aGUNCmVuY29k aW5nIGNoYW5nZSBhZGRyZXNzZXMgc29tZSBvZiB0aGUgaWRlbnRpZmllZCBzaG9ydGNvbWluZ3Ms IGJ1dA0KcHJvYmFibHkgbm90IGFsbCBvZiB0aGVtLiAgTW9yZSBzaWduaWZpY2FudCBjaGFuZ2Vz IG1pZ2h0IGJlIHByb3Bvc2VkDQpzZXBhcmF0ZWx5Lg0KDQotLU1hcnRpbg0KDQpbMV0gaHR0cHM6 Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzg3Ny9maWxlczxodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdp dGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRnB1bGwlMkY4NzclMkZmaWxlcyZkYXRh PTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NiMDc0Nzc5MjAwZjM0ZjkyNGUzNzA4 ZDUxNmVkZmE1OSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFkYjQ3JTdDMSU3QzAlN0M2 MzY0NDAxMzM3MjYyMzE3MjAmc2RhdGE9JTJCbXU2cXdpZXlncFhwZXY2JTJGWGg5ajFlY0NtVGVU bjU0cVNrNGV6WTJTR1UlM0QmcmVzZXJ2ZWQ9MD4NClsyXSBodHRwczovL2dpdGh1Yi5jb20vbWFy dGludGhvbXNvbi9xdWljLWludDxodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZtYXJ0aW50aG9tc29uJTJG cXVpYy1pbnQmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYjA3NDc3OTIw MGYzNGY5MjRlMzcwOGQ1MTZlZGZhNTklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0 NyU3QzElN0MwJTdDNjM2NDQwMTMzNzI2MjQxNzI4JnNkYXRhPVV5R1FpZUl3THNJa0dTVmZTcnhS JTJGYXRuQ0JMRlJNcEJvUUZOV0lEJTJGJTJGajglM0QmcmVzZXJ2ZWQ9MD4NClszXSBBbGwgdGhl IHVzdWFsIGNhdmVhdHMgYXBwbHkuICBTdWNoIGFzLCBteSBtYWNoaW5lIG1pZ2h0IG5vdCBiZQ0K cmVwcmVzZW50YXRpdmUsIGFuZCB0aGF0IEkgZGlkbid0IHNwZW5kIGFueSB0aW1lIG9wdGltaXpp bmcuDQpJbnRlcmVzdGluZyBub3RlIHRob3VnaDogRmVlZGluZyBteSBjb2RlIGEgY291bnRlciBh cyBpbnB1dCBtYWtlcyBpdA0KfjM1JSBmYXN0ZXIgdGhhbiBhbiBzaW1wbGUgZW5kaWFuIHN3YXAs IHByb2JhYmx5IGJlY2F1c2UgaXQgdXNlcyBsZXNzDQp0aGFuIG9uZSBxdWFydGVyIG9mIHRoZSBu dW1iZXIgb2Ygb2N0ZXRzLg0KWzRdIGh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFm dHMvcHVsbC84ODcvZmlsZXM8aHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGcXVpY3dnJTJGYmFzZS1kcmFm dHMlMkZwdWxsJTJGODg3JTJGZmlsZXMmZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQu Y29tJTdDYjA3NDc3OTIwMGYzNGY5MjRlMzcwOGQ1MTZlZGZhNTklN0M3MmY5ODhiZjg2ZjE0MWFm OTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NDQwMTMzNzI2MjQxNzI4JnNkYXRhPTd3cWtl VDl6TlByNXFOdXczVEJObTJSUE5GcDhjVGdwU2Y5SlUwY1ZkNUklM0QmcmVzZXJ2ZWQ9MD4NCls1 XSBodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jhc2UtZHJhZnRzL3B1bGwvODg4L2ZpbGVzPGh0 dHBzOi8vbmEwMS5zYWZlbGlua3MucHJvdGVjdGlvbi5vdXRsb29rLmNvbS8/dXJsPWh0dHBzJTNB JTJGJTJGZ2l0aHViLmNvbSUyRnF1aWN3ZyUyRmJhc2UtZHJhZnRzJTJGcHVsbCUyRjg4OCUyRmZp bGVzJmRhdGE9MDIlN0MwMSU3Q3ByYXZiJTQwbWljcm9zb2Z0LmNvbSU3Q2IwNzQ3NzkyMDBmMzRm OTI0ZTM3MDhkNTE2ZWRmYTU5JTdDNzJmOTg4YmY4NmYxNDFhZjkxYWIyZDdjZDAxMWRiNDclN0Mx JTdDMCU3QzYzNjQ0MDEzMzcyNjI0MTcyOCZzZGF0YT1VNzFleHM2eDBkWGxsSTIlMkJaY2x3bEJ1 WTZZaFJmS3BqUXBWbzNra1o3V1UlM0QmcmVzZXJ2ZWQ9MD4NCg0K --_000_CY4PR21MB02771FF7D12D9E684C372A99B6430CY4PR21MB0277namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5I YXBweSB3aXRoIHRoZSBuZXcgZm9ybWF0IGZvciB0aGUgQUNLIGRlbGF5IGZpZWxkLiBBbnl0aGlu ZyBvdGhlciB0aGFuIHRoZSAoY3VycmVudCkgY3VzdG9tIGZsb2F0aW5nIHBvaW50IGZvcm1hdCBp cyBmb3J3YXJkIHByb2dyZXNzIGV2ZW4gaWYgdGVtcG9yYXJ5LjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj5Gcm9tOjwvYj4gUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gPGI+ T24gQmVoYWxmIE9mDQo8L2I+SWFuIFN3ZXR0PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBP Y3RvYmVyIDE5LCAyMDE3IDU6MzYgQU08YnI+DQo8Yj5Ubzo8L2I+IE1hcnRpbiBUaG9tc29uICZs dDttYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBRVUlDIFdHICZs dDtxdWljQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogSW50ZWdlciBlbmNv ZGluZ3MgaW4gUVVJQyBmcmFtZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkknbSBz dXBwb3J0aXZlIG9mIHRoaXMgY2hhbmdlIGFzIGlzLCB0aG91Z2ggSSB0aGluayB3ZSBzaG91bGQg Y29uc2lkZXIgbm90IGNoYW5naW5nIHRoZSBBQ0sgZGVsYXkgZmllbGQgZm9yIG5vdy4mbmJzcDsg SSBoZWFyZCBlbm91Z2ggZGlmZmVyZW50IG9waW5pb25zIG9uIHdoYXQgc2hvdWxkIGJlIGRvbmUg d2l0aCBpdCB0aGF0IEkgZG9uJ3Qgd2FudCBjb25zZW5zdXMgb24gdGhhdCB0byBob2xkIHVwIHRo aXMgUFIuJm5ic3A7DQogVGhhdCBiZWluZyBzYWlkLCBpZiBldmVyeW9uZSBpcyBub3cgaGFwcHkg d2l0aCB0aGlzIGFjayBkZWxheSBmb3JtYXQob3Igbm90IGxlc3MgaGFwcHkgdGhhbiBiZWZvcmUp LCBmZWVsIGZyZWUgdG8gbGFuZCBpdCBhcyBpcy48bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPllvdXIgbW9yZSAnbWF4aW1hbCcgSFRUUCBjaGFuZ2UoIzg4OCkg bG9va2VkIGZpbmUgYXMgd2VsbC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gV2VkLCBPY3QgMTgsIDIwMTcgYXQgODoyNSBQTSwgTWFydGlu IFRob21zb24gJmx0OzxhIGhyZWY9Im1haWx0bzptYXJ0aW4udGhvbXNvbkBnbWFpbC5jb20iIHRh cmdldD0iX2JsYW5rIj5tYXJ0aW4udGhvbXNvbkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpz b2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6 NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWJvdHRvbToxMi4wcHQiPkhpIEFsbCw8YnI+DQo8YnI+DQpTb21lIG9mIHlvdSBtaWdodCBo YXZlIGhlYXJkIGRpc2N1c3Npb24gYWJvdXQgdGhlIGRpZmZpY3VsdHkgb2Y8YnI+DQpwYXJzaW5n IFFVSUMgZnJhbWVzLCBvciBoZWFyZCBtZSB0YWxrIGFib3V0IGEgcHJvcG9zYWwgZm9yIHJlZHVj aW5nPGJyPg0KdGhlIG51bWJlciBvZiBkaWZmZXJlbnQgdmFyaWF0aW9ucy48YnI+DQo8YnI+DQpJ IGhhdmUgYSBwcm9wb3NhbCBpbiBQUiAjODc3IFsxXSB0aGF0IHJlcGxhY2VzIHZpcnR1YWxseSBh bGwgb2YgdGhlPGJyPg0KaW50ZWdlciBlbmNvZGluZ3MgaW4gZnJhbWVzIHRvIHVzZSB0aGUgc2Ft ZSB2YXJpYWJsZS1sZW5ndGggZW5jb2RpbmcuPGJyPg0KVGhpcyBpbmNsdWRlcyB0aGUgQUNLIGRl bGF5IHRpbWVzdGFtcC48YnI+DQo8YnI+DQpUaGF0IGVuY29kaW5nIHRha2VzIHR3byBiaXRzIHRv IGRlc2NyaWJlIHRoZSBsZW5ndGggb2YgdGhlIGludGVnZXIgKDEsPGJyPg0KMiwgNCwgb3IgOCBv Y3RldHMpIGFuZCB0aGUgcmVtYWluZGVyIGlzIGJpZy1lbmRpYW4gZ29vZG5lc3MuJm5ic3A7IFRo aXM8YnI+DQpwcm9kdWNlcyByYW5nZXMgdGhhdCBhcmUgYSBiaXQgdW51c3VhbDogNi0sIDE0LSwg MzAtLCBvciA2Mi1iaXQuPGJyPg0KSG93ZXZlciwgdGhpcyBzaG91bGQgY292ZXIgbW9zdCB1c2Ug Y2FzZXMgYW5kIGlzIHByZXR0eSBmYXN0IHRvIGRlY29kZTxicj4NCmFuZCB0byBjb21wcmVoZW5k Ljxicj4NCjxicj4NCk15IHRlc3RpbmcgWzJdIHNob3dzIHRoYXQgdGhpcyBpcyBhYm91dCB+NTAl IHNsb3dlciB0aGFuIHVzaW5nIGE8YnI+DQpzaW1wbGUgaHRvbmwgb3IgZXF1aXZhbGVudCBbM10s IGJ1dCBpdCBjYW4gc2F2ZSBhIGxvdCBvZiBieXRlcyw8YnI+DQpkZXBlbmRpbmcgb24gdXNhZ2Ug bW9kZWwuPGJyPg0KPGJyPg0KVGhpcyB3b3VsZCBvbmx5IGFmZmVjdCB0aGUgaW5zaWRlcyBvZiBm cmFtZXMuJm5ic3A7IE5vIGNoYW5nZXMgYXJlIG1hZGUgdG88YnI+DQp0aGUgcGFja2V0IGhlYWRl ciwgY29ubmVjdGlvbiBJRCwgdmVyc2lvbiBvciBlcnJvciBjb2RlcywgZm9yIHdoaWNoPGJyPg0K Zml4ZWQtc2l6ZWQgZmllbGRzIGFyZSBjb252ZW5pZW50IGZvciBzZXZlcmFsIHJlYXNvbnMuPGJy Pg0KPGJyPg0KVGhlIGNoYW5nZSB3b3VsZCBtZWFuIGRpZmZlcmVudCBsaW1pdHMuJm5ic3A7IFdl IHdvdWxkIGhhdmUgNCB0aW1lcyBmZXdlcjxicj4NCnBhY2tldHMgYW5kIGZsb3cgY29udHJvbCBv Y3RldHMsIGJ1dCAyXjMwIHRpbWVzIG1vcmUgc3RyZWFtcy48YnI+DQo8YnI+DQpUaGlzIFBSIGRv ZXNuJ3QgY2hhbmdlIHRoZSBIVFRQIG1hcHBpbmcgeWV0LiZuYnNwOyBJIGhhdmUgdHdvIFBScyBv cGVuIGluPGJyPg0KYWRkaXRpb24gdG8gdGhpcyB0aGF0IG1ha2UgYSBtYXRjaGluZyBjaGFuZ2Ug dG8gdGhlIEhUVFAgbWFwcGluZy48YnI+DQojODg3IFs0XSBtYWtlcyB0aGUgbWluaW11bSBjaGFu Z2UsIGVmZmVjdGl2ZWx5IGlnbm9yaW5nIHRoZSBjaGFuZ2VzIGF0PGJyPg0KdGhlIGxvd2VyIGxh eWVyIGFuZCBzdGlja2luZyB0byAzMi1iaXQgaWRlbnRpZmllcnMuJm5ic3A7ICM4ODggWzVdIGlt cG9ydHM8YnI+DQp0aGUgaW50ZWdlciBmb3JtYXQgbW9yZSB3aWRlbHkuJm5ic3A7IEkgcHJlZmVy IHRoZSBsYXR0ZXIsIGJ1dCB3YW50IHRvIGhlYXI8YnI+DQptb3JlIG9waW5pb25zLCBiZWNhdXNl IGl0IHdvdWxkIGhhdmUgY29uc2VxdWVuY2VzIGZvciBIVFRQLzI8YnI+DQpjb21wYXRpYmlsaXR5 IChzZWUgdGhlIFBSIGZvciBkZXRhaWxzKS4mbmJzcDsgSSBleHBlY3QgdGhhdCB0aGUgSFRUUDxi cj4NCndvcmtpbmcgZ3JvdXAgd2lsbCBhbHNvIGhhdmUgc29tZSB0aGluZ3MgdG8gc2F5IGFib3V0 IHRoYXQsIHNvIEkgcGxhbjxicj4NCnRvIGFzayB0aGVtIHRvby48YnI+DQo8YnI+DQpJIGhhdmVu J3QgcHJvcG9zZWQgbW9yZSBzaWduaWZpY2FudCBjaGFuZ2VzIHRvIHRoZSBBQ0sgZnJhbWU7IHRo ZTxicj4NCmVuY29kaW5nIGNoYW5nZSBhZGRyZXNzZXMgc29tZSBvZiB0aGUgaWRlbnRpZmllZCBz aG9ydGNvbWluZ3MsIGJ1dDxicj4NCnByb2JhYmx5IG5vdCBhbGwgb2YgdGhlbS4mbmJzcDsgTW9y ZSBzaWduaWZpY2FudCBjaGFuZ2VzIG1pZ2h0IGJlIHByb3Bvc2VkPGJyPg0Kc2VwYXJhdGVseS48 YnI+DQo8YnI+DQotLU1hcnRpbjxicj4NCjxicj4NClsxXSA8YSBocmVmPSJodHRwczovL25hMDEu c2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1 Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRnB1bGwlMkY4NzclMkZmaWxlcyZhbXA7ZGF0 YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYjA3NDc3OTIwMGYzNGY5MjRlMzcw OGQ1MTZlZGZhNTklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdD NjM2NDQwMTMzNzI2MjMxNzIwJmFtcDtzZGF0YT0lMkJtdTZxd2lleWdwWHBldjYlMkZYaDlqMWVj Q21UZVRuNTRxU2s0ZXpZMlNHVSUzRCZhbXA7cmVzZXJ2ZWQ9MCIgdGFyZ2V0PSJfYmxhbmsiPg0K aHR0cHM6Ly9naXRodWIuY29tL3F1aWN3Zy9iYXNlLWRyYWZ0cy9wdWxsLzg3Ny9maWxlczwvYT48 YnI+DQpbMl0gPGEgaHJlZj0iaHR0cHM6Ly9uYTAxLnNhZmVsaW5rcy5wcm90ZWN0aW9uLm91dGxv b2suY29tLz91cmw9aHR0cHMlM0ElMkYlMkZnaXRodWIuY29tJTJGbWFydGludGhvbXNvbiUyRnF1 aWMtaW50JmFtcDtkYXRhPTAyJTdDMDElN0NwcmF2YiU0MG1pY3Jvc29mdC5jb20lN0NiMDc0Nzc5 MjAwZjM0ZjkyNGUzNzA4ZDUxNmVkZmE1OSU3QzcyZjk4OGJmODZmMTQxYWY5MWFiMmQ3Y2QwMTFk YjQ3JTdDMSU3QzAlN0M2MzY0NDAxMzM3MjYyNDE3MjgmYW1wO3NkYXRhPVV5R1FpZUl3THNJa0dT VmZTcnhSJTJGYXRuQ0JMRlJNcEJvUUZOV0lEJTJGJTJGajglM0QmYW1wO3Jlc2VydmVkPTAiIHRh cmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vZ2l0aHViLmNvbS9tYXJ0aW50aG9tc29uL3F1aWMtaW50 PC9hPjxicj4NClszXSBBbGwgdGhlIHVzdWFsIGNhdmVhdHMgYXBwbHkuJm5ic3A7IFN1Y2ggYXMs IG15IG1hY2hpbmUgbWlnaHQgbm90IGJlPGJyPg0KcmVwcmVzZW50YXRpdmUsIGFuZCB0aGF0IEkg ZGlkbid0IHNwZW5kIGFueSB0aW1lIG9wdGltaXppbmcuPGJyPg0KSW50ZXJlc3Rpbmcgbm90ZSB0 aG91Z2g6IEZlZWRpbmcgbXkgY29kZSBhIGNvdW50ZXIgYXMgaW5wdXQgbWFrZXMgaXQ8YnI+DQp+ MzUlIGZhc3RlciB0aGFuIGFuIHNpbXBsZSBlbmRpYW4gc3dhcCwgcHJvYmFibHkgYmVjYXVzZSBp dCB1c2VzIGxlc3M8YnI+DQp0aGFuIG9uZSBxdWFydGVyIG9mIHRoZSBudW1iZXIgb2Ygb2N0ZXRz Ljxicj4NCls0XSA8YSBocmVmPSJodHRwczovL25hMDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0 bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdpdGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRy YWZ0cyUyRnB1bGwlMkY4ODclMkZmaWxlcyZhbXA7ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNy b3NvZnQuY29tJTdDYjA3NDc3OTIwMGYzNGY5MjRlMzcwOGQ1MTZlZGZhNTklN0M3MmY5ODhiZjg2 ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0MwJTdDNjM2NDQwMTMzNzI2MjQxNzI4JmFtcDtz ZGF0YT03d3FrZVQ5ek5QcjVxTnV3M1RCTm0yUlBORnA4Y1RncFNmOUpVMGNWZDVJJTNEJmFtcDty ZXNlcnZlZD0wIiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jh c2UtZHJhZnRzL3B1bGwvODg3L2ZpbGVzPC9hPjxicj4NCls1XSA8YSBocmVmPSJodHRwczovL25h MDEuc2FmZWxpbmtzLnByb3RlY3Rpb24ub3V0bG9vay5jb20vP3VybD1odHRwcyUzQSUyRiUyRmdp dGh1Yi5jb20lMkZxdWljd2clMkZiYXNlLWRyYWZ0cyUyRnB1bGwlMkY4ODglMkZmaWxlcyZhbXA7 ZGF0YT0wMiU3QzAxJTdDcHJhdmIlNDBtaWNyb3NvZnQuY29tJTdDYjA3NDc3OTIwMGYzNGY5MjRl MzcwOGQ1MTZlZGZhNTklN0M3MmY5ODhiZjg2ZjE0MWFmOTFhYjJkN2NkMDExZGI0NyU3QzElN0Mw JTdDNjM2NDQwMTMzNzI2MjQxNzI4JmFtcDtzZGF0YT1VNzFleHM2eDBkWGxsSTIlMkJaY2x3bEJ1 WTZZaFJmS3BqUXBWbzNra1o3V1UlM0QmYW1wO3Jlc2VydmVkPTAiIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHBzOi8vZ2l0aHViLmNvbS9xdWljd2cvYmFzZS1kcmFmdHMvcHVsbC84ODgvZmlsZXM8L2E+ PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt bD4NCg== --_000_CY4PR21MB02771FF7D12D9E684C372A99B6430CY4PR21MB0277namp_-- From nobody Thu Oct 19 19:58: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 814BF13208E for ; Thu, 19 Oct 2017 19:58:50 -0700 (PDT) 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 5CUgCxubJ93p for ; Thu, 19 Oct 2017 19:58:48 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 40A6D126BF0 for ; Thu, 19 Oct 2017 19:58:48 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v9K2weuV008880; Fri, 20 Oct 2017 04:58:40 +0200 Date: Fri, 20 Oct 2017 04:58:40 +0200 From: Willy Tarreau To: Dmitri Tikhonov Cc: Mikkel =?iso-8859-1?Q?Fahn=F8e_J=F8rgensen?= , Roberto Peon , QUIC WG , Martin Thomson Subject: Re: Integer encodings in QUIC frames Message-ID: <20171020025840.GB8797@1wt.eu> References: <20171019022929.GB6628@1wt.eu> <20171019032836.GA6718@1wt.eu> <20171019200424.GA8580@1wt.eu> <0F7B8AE7-1B63-41DD-AB5E-84B5E3FC4C7E@fb.com> <20171019202414.GA8669@1wt.eu> <20171019212105.GB3291@ubuntu-dmitri> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20171019212105.GB3291@ubuntu-dmitri> 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, 20 Oct 2017 02:58:50 -0000 On Thu, Oct 19, 2017 at 05:21:06PM -0400, Dmitri Tikhonov wrote: > On Thu, Oct 19, 2017 at 04:39:42PM -0400, Mikkel Fahnøe Jørgensen wrote: > > There is nothing inherent in the new encoding format that is more difficult > > than it was before. The length of the stored values was just encoded all > > over the place. Either way you must deal with unaligned access, endian > > conversion, and different integer lengths. > > I think it will be at least a _little_ more difficult: One advantage > of the sizes being encoded in the STREAM type byte is that one can > calculate required length and check it quickly, e.g. > > static int > gquic_le_parse_stream_frame (const unsigned char *buf, > size_t rem_packet_sz, stream_frame_t *stream_frame) > { > /* 1fdoooss */ > const unsigned char *p = buf; > const unsigned char *const pend = p + rem_packet_sz; > CHECK_SPACE(1, p, pend); > const char type = *p++; > const unsigned data_len = (type >> 4) & 2; > const unsigned offset_len = ((type >> 2) & 7) + 1 - !((type >> 2) & 7); > const unsigned stream_id_len = 1 + (type & 3); > const unsigned need = data_len + offset_len + stream_id_len; > CHECK_SPACE(need, p, pend); > > Reading lengths and values of variable-sized integers will be more > involved (one must also make sure he does not read past the buffer). In fact what matters to me is that a naive approach is reasonably easy to implement, and that given some efforts, it's possible to implement a very efficient version where needed. For example, dealing with reading past the buffer is never easy when you deal with multi-byte reads at once, but in practice when you do this, your code will check if there's a *risk* of getting there and will fall back to the one byte at a time code in such conditions. When you parse a 16kB buffer and only the 7 last bytes are processed this way, it means it's fast 99.95% of the time. > I like the consistencly of the proposed approach, though. Same for me. If we could ensure that there's a single method to emit and parse any integer, it would be nice. That's definitely part of a nicely designed protocol. Willy From nobody Thu Oct 19 20:17: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 2BA8913431C for ; Thu, 19 Oct 2017 20:17:17 -0700 (PDT) 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 T2D0cupfk0en for ; Thu, 19 Oct 2017 20:17:16 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id AE2DB132076 for ; Thu, 19 Oct 2017 20:17:15 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v9K3HDE1009337; Fri, 20 Oct 2017 05:17:13 +0200 Date: Fri, 20 Oct 2017 05:17:13 +0200 From: Willy Tarreau To: Leif Hedstrom Cc: Martin Thomson , QUIC WG Subject: Re: Integer encodings in QUIC frames Message-ID: <20171020031713.GE8797@1wt.eu> References: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> 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, 20 Oct 2017 03:17:17 -0000 On Thu, Oct 19, 2017 at 04:50:14PM -0600, Leif Hedstrom wrote: > > On Oct 18, 2017, at 6:25 PM, Martin Thomson wrote: > > > > Hi All, > > > > Some of you might have heard discussion about the difficulty of > > parsing QUIC frames, or heard me talk about a proposal for reducing > > the number of different variations. > > > > I have a proposal in PR #877 [1] that replaces virtually all of the > > integer encodings in frames to use the same variable-length encoding. > > This includes the ACK delay timestamp. > > > > That encoding takes two bits to describe the length of the integer (1, > > 2, 4, or 8 octets) and the remainder is big-endian goodness. This > > produces ranges that are a bit unusual: 6-, 14-, 30-, or 62-bit. > > However, this should cover most use cases and is pretty fast to decode > > and to comprehend. > > I always wondered what sort of real-world impact this micro optimization of > variable integer length actually has. Do we have numbers on that? It seems > like a complicated implementation in general, with perhaps questionable > benefits? you can easily spend 10-20% of your program's time processing frame fields, so it can be very important especially on the server side, to maintain a good scalability. Reducing the *minimum* time needed to process a frame is also important to better resist DDoS. I just ran a quick test on my H2 implementation in haproxy, and by disabling similar optimizations on int32 processing (ie reading the stream ID one byte at a time instead of one word at a time), the performance drops from 860k req/s to 840k/s. At such loads, every cycle counts when it's repeated a lot. Willy From nobody Thu Oct 19 20:50: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 09A0212ECEC for ; Thu, 19 Oct 2017 20:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ogre.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ARgfV-W6smTW for ; Thu, 19 Oct 2017 20:50:14 -0700 (PDT) Received: from cosmo.ogre.com (cosmo4.ogre.com [71.6.165.248]) (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 ABEBC126BF0 for ; Thu, 19 Oct 2017 20:50:13 -0700 (PDT) Received: by cosmo.ogre.com (8.15.2/8.15.2) with ESMTPSA id v9K3nnr2018158 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 19 Oct 2017 20:49:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ogre.com; s=03062012; t=1508471390; bh=/NjS8CWFS1fHsgIKL+Lg9JT3MC4eFUnvdpAPzFAD1Ow=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=N5uE8RsWb/1UgwAd/4KavuniSs4qRjEX0UHnIeZyiJMzyFdGdAvZJjqK2bBwpicP2 ZFOK6K2O9Qsm+1wlPKXqryEd2Onj2ppRds7jbnuWFdqSJEL+Uz3TrANHDSGIePpbAU vPeB0Pz6en0PqUM4qpqeUAk/qAcCaE0MuOBQ5Sxo= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: Integer encodings in QUIC frames From: Leif Hedstrom X-Mailer: iPad Mail (15A432) In-Reply-To: <20171020031713.GE8797@1wt.eu> Date: Thu, 19 Oct 2017 21:49:48 -0600 Cc: QUIC WG , Martin Thomson Content-Transfer-Encoding: quoted-printable Message-Id: <66ECF599-F5A7-4D85-8A04-4518E0220CDF@ogre.com> References: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> <20171020031713.GE8797@1wt.eu> To: Willy Tarreau 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, 20 Oct 2017 03:50:15 -0000 > On Oct 19, 2017, at 9:17 PM, Willy Tarreau wrote: >=20 > On Thu, Oct 19, 2017 at 04:50:14PM -0600, Leif Hedstrom wrote: >>> On Oct 18, 2017, at 6:25 PM, Martin Thomson w= rote: >>>=20 >>> Hi All, >>>=20 >>> Some of you might have heard discussion about the difficulty of >>> parsing QUIC frames, or heard me talk about a proposal for reducing >>> the number of different variations. >>>=20 >>> I have a proposal in PR #877 [1] that replaces virtually all of the >>> integer encodings in frames to use the same variable-length encoding. >>> This includes the ACK delay timestamp. >>>=20 >>> That encoding takes two bits to describe the length of the integer (1, >>> 2, 4, or 8 octets) and the remainder is big-endian goodness. This >>> produces ranges that are a bit unusual: 6-, 14-, 30-, or 62-bit. >>> However, this should cover most use cases and is pretty fast to decode >>> and to comprehend. >>=20 >> I always wondered what sort of real-world impact this micro optimization o= f >> variable integer length actually has. Do we have numbers on that? It seem= s >> like a complicated implementation in general, with perhaps questionable >> benefits? >=20 > you can easily spend 10-20% of your program's time processing frame fields= , > so it can be very important especially on the server side, to maintain a > good scalability. Reducing the *minimum* time needed to process a frame is= > also important to better resist DDoS. Right. I probably didn=E2=80=99t word my question well. What am asking is, i= s it worth the complexity of this at all, to save a few bytes on the wires? Cheers, =E2=80=94 Leif=20 >=20 > I just ran a quick test on my H2 implementation in haproxy, and by disabli= ng > similar optimizations on int32 processing (ie reading the stream ID one by= te > at a time instead of one word at a time), the performance drops from 860k > req/s to 840k/s. At such loads, every cycle counts when it's repeated a lo= t. >=20 > Willy >=20 From nobody Thu Oct 19 21:12: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 8B39812ECEC for ; Thu, 19 Oct 2017 21:12:33 -0700 (PDT) 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 znygR8uArgpi for ; Thu, 19 Oct 2017 21:12:32 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id EBB8D126BF0 for ; Thu, 19 Oct 2017 21:12:31 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v9K4CQxb009426; Fri, 20 Oct 2017 06:12:26 +0200 Date: Fri, 20 Oct 2017 06:12:26 +0200 From: Willy Tarreau To: Leif Hedstrom Cc: QUIC WG , Martin Thomson Subject: Re: Integer encodings in QUIC frames Message-ID: <20171020041226.GA9423@1wt.eu> References: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> <20171020031713.GE8797@1wt.eu> <66ECF599-F5A7-4D85-8A04-4518E0220CDF@ogre.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66ECF599-F5A7-4D85-8A04-4518E0220CDF@ogre.com> 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, 20 Oct 2017 04:12:33 -0000 On Thu, Oct 19, 2017 at 09:49:48PM -0600, Leif Hedstrom wrote: > Right. I probably didn't word my question well. What am asking is, is it > worth the complexity of this at all, to save a few bytes on the wires? Very often, yes. Saving bytes on the wire is mainly what makes H2 much faster than H1. Willy From nobody Fri Oct 20 05:38: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 997391331C1 for ; Fri, 20 Oct 2017 05:38:22 -0700 (PDT) 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=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 Sk0jCcCCQFIK for ; Fri, 20 Oct 2017 05:38:21 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5779513318C for ; Fri, 20 Oct 2017 05:38:21 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id p186so13039925ioe.12 for ; Fri, 20 Oct 2017 05:38:21 -0700 (PDT) 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=NOK7O9zhM4a1e5K0AGsCk4uoM7gPo6pGTfwUMZYHp/o=; b=dmljLg8Bzhiq/vYuGIe6F7blqaQea87ChNSEWn7CesRTxx41onkFkdfXt+Lt38/MVk uPlcWc5rr/BH1rEgahtPRtkJf7k3uu8hCJXodqT5fGs9d6UcucP/HPdchZxQ50BE0HNK ZbcOQjXy48pOQTfWXyTiY8lDNppbMMuTOwppW1eoyuvv+o9em6wLoLX5mCpGXKrPU072 eSl7ebF42eZL4w/X8pL4kQfM+lThLW7ZBAmj2czltKjOHEWpVNmVRUNICPVJAwFf79Iv MnvoJZNXwrD6xgv58Xnj+axhtPKY4YSFVXTLRntIIiJVkEhzVw6y20g33FYqW71J8O4T 5r9A== 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=NOK7O9zhM4a1e5K0AGsCk4uoM7gPo6pGTfwUMZYHp/o=; b=Imu/e5s6iovPdjl39kvQr+C9p13VTd3mxXeGSf5ZbZ5NbUfMr0kmowD3AiiBbV3Rnb dOPZ+8nOPPElni3QeBj0srTPkeAQaTGO93K2YRxT62Xe9TnqgS7hTALW+2Y7w4I94kOJ RAeKSF9HGMcvIES8n1C8S21/f4vN8Xg3XFOqLNqJr39z8SvWqYWDYAEpPg/rOab3TE0c VAdLc0gTIhR8ikb2ymhGKEsTGIvNRuUmSHnDlCYe9HLklFKGhGJVFQmE0xYmVYfweQ/w 2WvUlc3TI23684aPkg3B5RxvV37elFCDTkLr3GKHifT1i8wcjAqXch/U9n2JqHTkUejP OJ4g== X-Gm-Message-State: AMCzsaUYs0Crh6+kGT3W1xaIJibElKsVAERxVAIvqXx/Yj+xgnwVHb8z RrO3oX1K8KmWW7q1lwWeeuVw3WebQqQsNvLPuhHCroB9 X-Google-Smtp-Source: ABhQp+QSAOmT8ih1RaINOx7qxqs4F0zWWTuXVzujqyaFNdKF+Q5WtyZte9H54i+Ewsf/gOIJjkAO+SkAEV0Y5kyJiiY= X-Received: by 10.107.163.15 with SMTP id m15mr6075998ioe.61.1508503099929; Fri, 20 Oct 2017 05:38:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.142.4 with HTTP; Fri, 20 Oct 2017 05:37:59 -0700 (PDT) In-Reply-To: <20171020041226.GA9423@1wt.eu> References: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> <20171020031713.GE8797@1wt.eu> <66ECF599-F5A7-4D85-8A04-4518E0220CDF@ogre.com> <20171020041226.GA9423@1wt.eu> From: Ian Swett Date: Fri, 20 Oct 2017 08:37:59 -0400 Message-ID: Subject: Re: Integer encodings in QUIC frames To: Willy Tarreau Cc: Leif Hedstrom , QUIC WG , Martin Thomson Content-Type: multipart/alternative; boundary="001a11402f146a8681055bf9bfd0" 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, 20 Oct 2017 12:38:22 -0000 --001a11402f146a8681055bf9bfd0 Content-Type: text/plain; charset="UTF-8" I would agree it's definitely valuable. Also, even if variable length coding costs a bit of framing CPU, it's that many fewer bytes to send/receive, decrypt/encrypt and move into CPU cache. In the typical case, I would guess it's a net CPU savings, at least for this type of varint. In the case of a single stream frame, using varints for stream ids and offsets saves ~12 bytes, which is ~1% overhead for full sized packets and more for smaller payloads. On Fri, Oct 20, 2017 at 12:12 AM, Willy Tarreau wrote: > On Thu, Oct 19, 2017 at 09:49:48PM -0600, Leif Hedstrom wrote: > > Right. I probably didn't word my question well. What am asking is, is it > > worth the complexity of this at all, to save a few bytes on the wires? > > Very often, yes. Saving bytes on the wire is mainly what makes H2 much > faster than H1. > > Willy > > --001a11402f146a8681055bf9bfd0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I would agree it's definitely valuable.=C2=A0 Also, ev= en if variable length coding costs a bit of framing CPU, it's that many= fewer bytes to send/receive, decrypt/encrypt and move into CPU cache.=C2= =A0 In the typical case, I would guess it's a net CPU savings, at least= for this type of varint.=C2=A0 In the case of a single stream frame, using= varints for stream ids and offsets saves ~12 bytes, which is ~1% overhead = for full sized packets and more for smaller payloads.

On Fri, Oct 20, 2017 at 12:12 AM,= Willy Tarreau <w@1wt.eu> wrote:
On Thu, Oct 19, 2017 at 09:49:48PM -0600, Leif Hedstrom wrot= e:
> Right. I probably didn't word my question well. What am asking is,= is it
> worth the complexity of this at all, to save a few bytes on the wires?=

Very often, yes. Saving bytes on the wire is mainly what makes H2 mu= ch
faster than H1.

Willy


--001a11402f146a8681055bf9bfd0-- From nobody Fri Oct 20 17:26:15 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 9C2BB1344AF; Fri, 20 Oct 2017 17:24:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: quic@ietf.org, spencerdawkins.ietf@gmail.com Subject: quic - Requested sessions have been scheduled for IETF 100 X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150854545663.20809.17231510327339266549.idtracker@ietfa.amsl.com> Date: Fri, 20 Oct 2017 17:24:16 -0700 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: Sat, 21 Oct 2017 00:24:17 -0000 Dear Mark Nottingham, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. quic Session 1 (2:30:00) Tuesday, Afternoon Session I 1330-1530 Room Name: Padang size: 300 --------------------------------------------- quic Session 2 (2:30:00) Wednesday, Morning Session I 0930-1200 Room Name: Collyer size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: QUIC Area Name: Transport Area Session Requester: Mark Nottingham Number of Sessions: 2 Length of Session(s): 2.5 Hours, 2.5 Hours Number of Attendees: 175 Conflicts to Avoid: First Priority: tsvarea tsvwg httpbis tls dispatch Second Priority: iccrg irtfopen mptcp saag maprg Third Priority: hrpc People who must be present: Mark Nottingham Patrick R. McManus Janardhan Iyengar Martin Thomson Spencer Dawkins Lars Eggert Resources Requested: Experimental Room Setup (U-Shape and classroom, subject to availability) Special Requests: Two consecutive days if possible; 2 hour slot(s) fine too, if that makes it easier. --------------------------------------------------------- From nobody Sun Oct 22 20:23: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 4B9B013CFC3 for ; Sun, 22 Oct 2017 20:23:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.821 X-Spam-Level: X-Spam-Status: No, score=-0.821 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 (2048-bit key) header.d=mnot.net header.b=ciX759xO; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=nzDLhzc+ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-z29RY7bEVd for ; Sun, 22 Oct 2017 20:23:04 -0700 (PDT) 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 019DF13CFC2 for ; Sun, 22 Oct 2017 20:23:04 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 6132E2080E; Sun, 22 Oct 2017 23:23:03 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Sun, 22 Oct 2017 23:23:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :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=g5R6ReVWcG4JMniLgIFppnGF0cubEykAzKisxeSvzCk=; b=ciX759xO OCTANGn1WbnHCGv/NvAHaH5SQoWtrCSD6fgohSZha12W7JydgE0OpWjnKkGZTymf +qywcewZtkSicsGgc7aKT1Qq2jaZ5nX9nrApMy1EWrcTuqpGO5f7F1HO8aa22L3Q twXjDrV68zfYYuX1TPP+EPmm5eIGW7UMAlM2RdN70ZpABStDw/UDel0SRJNaEXd9 Wj2UWUBepbvfmyoaRrDf+Ok1XY/gUkM+m7OvTkGCZJjP45yc27TacIbn0Teh54sg X9qIVNJYxvKcZKHP+RZn+HYTIOBiQUtqRsulEQK0mlThfrJRepsM2NsrMp3GUcp2 odTtSDoMd4lh0g== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc: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=g5R6ReVWcG4JMniLgIFppnGF0cubE ykAzKisxeSvzCk=; b=nzDLhzc+BUZWKV5p//oIjg0qySMKmmDcQQvkNBYJACkcx bM0zVkXUJ1wdZnMXIu1q+z4J+fGSXZdvxxEIppSASPymsGFj2EkWvVlEFts3v4YR lXk6MXXh2VBthj58yqQhjrTSyMfsvD0bdxIrCeXQDWnOijO7a+qXverbGDCk1mxm qU5TxBWAVC5CpeQasQO59gvhZAFX/sXhNveGqcnINF52Cs4DTh+QI8n5eiy9fcDM Btm+z0raQsil9h3AfEuU5CYsm+1cyPUyUhugUddj11FLbOeYyhydWqRKaIor0DBE G6yQ4MuLbyIaL0lQ+5NJ4QCHV3djA6G/06Wd7Enlg== 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 693247F91E; Sun, 22 Oct 2017 23:23:02 -0400 (EDT) From: Mark Nottingham Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_667CB237-C62B-4159-9A37-AE35085557CF" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: QUIC (quic) WG Interim Meeting: 2018-01-23 Date: Mon, 23 Oct 2017 14:22:59 +1100 In-Reply-To: <150712475270.24252.1965027482254580403@ietfa.amsl.com> Cc: Lars Eggert To: QUIC WG References: <150712475270.24252.1965027482254580403@ietfa.amsl.com> X-Mailer: Apple Mail (2.3445.1.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, 23 Oct 2017 03:23:07 -0000 --Apple-Mail=_667CB237-C62B-4159-9A37-AE35085557CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Reminder - registration for this interim closes a bit earlier, on 8 = December. Cheers, > 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 -- Mark Nottingham https://www.mnot.net/ --Apple-Mail=_667CB237-C62B-4159-9A37-AE35085557CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Reminder - registration for this interim closes a bit = earlier, on 8 December.

Cheers,


On 5 Oct = 2017, at 12:45 am, IESG Secretary <iesg-secretary@ietf.org> 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-0= 1/arrangements.md


--
Mark Nottingham  =  https://www.mnot.net/

= --Apple-Mail=_667CB237-C62B-4159-9A37-AE35085557CF-- From nobody Sun Oct 22 20:23: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 C262013CFCF for ; Sun, 22 Oct 2017 20:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6nQhDFFD2o0 for ; Sun, 22 Oct 2017 20:23:21 -0700 (PDT) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003: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 6D6E813CFC9 for ; Sun, 22 Oct 2017 20:23:21 -0700 (PDT) Received: by mail-oi0-x22c.google.com with SMTP id n82so28584328oig.3 for ; Sun, 22 Oct 2017 20:23:21 -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=TV1pocVAk+bpWfrXTpQpMp5/fxtr4ZaHQ++N/aUGno0=; b=L5g4pJvE9qTmGMhOgVKYRysdUQA6ciNx7Zdqb66bNzPZYPyoS/OYWxjpIAXBxpoMCS PuyDxFS2S0mapcI+rJVFVvasY9Idp4DwihuEuM0LrDbkdVKg3Izu9E/Qj1B9SHe/l/oJ BcPs0900QUeH4HEi3oocXkzL0c1Q5HJsemSVSRPauJCOuZIVj1ml01kTXQ1tchXyM+Y1 JksDYvxiQdBVQQJQR77uXsAFRmMCei7N6QTXe+0KTOoN5w99LHsS4v3vBggH9GrobMUI W+OkoFw4EHkMexT88zeuEytu/ZoIQlI23zVbiD4UidOdorQEkNMnHo1utaMb0jl0vMbB S8bg== 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=TV1pocVAk+bpWfrXTpQpMp5/fxtr4ZaHQ++N/aUGno0=; b=Tn659xzTRL9NEgVeXd30YQ8Azt4zyxGMf/LBBgDt0bYqZ/+6odTw0GxBq2oXCQbeex Tbuk4SzgTqHidCIEFgLXkBHYBOpdF3uZdvNCYPW4TyeRlfzSKpxMn82Y+pLsODYSSntd 4fmfJzYtHl4W6Mj4mWBqz+L45Nu8APUXLOSGsLcOj/PadncjWKF8K0ckJpPemNYIfdYH sJrZe41GVrE73H/K906InbKHDrIQvSF2AWPemHsSJkg8zRHn5jWufu7tRiR+YVvNY5nf DNH4LBcs6u954fCQq56i2BhzDtHoB4iEAYntLV79lqBw7BhIt8lAGihDRzLj3YIYu5Sq 69xg== X-Gm-Message-State: AMCzsaWv0B61SkAaB9USyOAJn3PVkPf7bkKAdI8EoJ7foUZSW2/RBwS0 sTmNJQELq5dwbyZ03Zv8It2IfqKIsydcZ2EEXmc= X-Google-Smtp-Source: ABhQp+R7au+aCMzYtHKDVYyuysPDtNs8lKUte9ANnhN3M77E4pP367/1uNvPvFd67zSLnPNYFZKTw+k8OuNTcas0gOM= X-Received: by 10.202.166.141 with SMTP id t13mr6739329oij.392.1508729000758; Sun, 22 Oct 2017 20:23:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Sun, 22 Oct 2017 20:23:20 -0700 (PDT) In-Reply-To: References: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> <20171020031713.GE8797@1wt.eu> <66ECF599-F5A7-4D85-8A04-4518E0220CDF@ogre.com> <20171020041226.GA9423@1wt.eu> From: Martin Thomson Date: Mon, 23 Oct 2017 14:23:20 +1100 Message-ID: Subject: Re: Integer encodings in QUIC frames To: Ian Swett Cc: Willy Tarreau , Leif Hedstrom , 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: Mon, 23 Oct 2017 03:23:23 -0000 One thing we learned from SPDY and HTTP/2 was that the first few round trips are critical to performance. If requests in particular can be made smaller, you avoid running into the limit that the congestion controller places on your total outbound bandwidth. Making integers one octet rather than 8 makes a big difference. In web tests, this limit often hits hardest on the second flight of messages, after the single request turns into hundreds. With 0-RTT that happens after just a single RTT, so the congestion controller probably still has the tap set to a pretty narrow setting. (I tried looking for a good citation, but I couldn't find one. Maybe others have pointers at the ready.) On Fri, Oct 20, 2017 at 11:37 PM, Ian Swett wrote: > I would agree it's definitely valuable. Also, even if variable length > coding costs a bit of framing CPU, it's that many fewer bytes to > send/receive, decrypt/encrypt and move into CPU cache. In the typical case, > I would guess it's a net CPU savings, at least for this type of varint. In > the case of a single stream frame, using varints for stream ids and offsets > saves ~12 bytes, which is ~1% overhead for full sized packets and more for > smaller payloads. > > On Fri, Oct 20, 2017 at 12:12 AM, Willy Tarreau wrote: >> >> On Thu, Oct 19, 2017 at 09:49:48PM -0600, Leif Hedstrom wrote: >> > Right. I probably didn't word my question well. What am asking is, is it >> > worth the complexity of this at all, to save a few bytes on the wires? >> >> Very often, yes. Saving bytes on the wire is mainly what makes H2 much >> faster than H1. >> >> Willy >> > From nobody Sun Oct 22 20:38: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 3483D13D0D2 for ; Sun, 22 Oct 2017 20:38:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.702 X-Spam-Level: X-Spam-Status: No, score=-0.702 tagged_above=-999 required=5 tests=[BAYES_20=-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 g0narrqKteuu for ; Sun, 22 Oct 2017 20:38:50 -0700 (PDT) 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 B51C213D06D for ; Sun, 22 Oct 2017 20:38:50 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx5.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e6TZf-0004E1-TP for quic@ietf.org; Mon, 23 Oct 2017 05:38:48 +0200 Received: from [10.5.2.52] (helo=xmail12.myhosting.com) by xsmtp01.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1e6TZd-0008HP-Hd for quic@ietf.org; Sun, 22 Oct 2017 23:38:46 -0400 Received: (qmail 8738 invoked from network); 23 Oct 2017 03:38:43 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.162]) (envelope-sender ) by xmail12.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 23 Oct 2017 03:38:42 -0000 To: quic@ietf.org References: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> <20171020031713.GE8797@1wt.eu> <66ECF599-F5A7-4D85-8A04-4518E0220CDF@ogre.com> <20171020041226.GA9423@1wt.eu> From: Christian Huitema Message-ID: Date: Sun, 22 Oct 2017 20:38:40 -0700 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: Integer encodings in QUIC frames 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.35) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5rsBmrkgjQq9ESxb0WFTCI0Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59ftj/4KCiUcFcbis7tsCXApMB98yDTitFWvbHwz9vKZpm+Fv CFr9jpJ2kLwf6AsfyQqZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA/itEW1aHIJYDvx6uGLOm1Bi99Or0uXh6FskGQ3mtr4LUU/Qweyn+lg7TbDa2rNOWNaHCnN rMSSA7xor9tnUlOY8pSJo/Vkdr+FbBdda40x5B/NGyVcjXsZLVHUb2pmaEmDh4PRiBbRliPgaurB TRjstfheF24EjrGuHVHIMu1lYZhMr2sR3cQs/oU/axm99b2jdwip2wrbEvxHA2swIjN6PhFSfsse t38tyDP81cDf6vvg7iEFLP+SSY+Av5+AiC4+FlPRM1XDL9X8GH7hq4bs/kgegmhiiTgviqrs8UIa MCP8nlHTeVjhC21V3h7UCmtZ0VwEd+iNUj65ezw/iijHw95cPWLsHiU6tFs2fFlaJuRMyksc0Dx4 iQa9AzGuG3nTPpuFqUUQz+mM8JAD4ECWQ8DWpNApCszClmRRuSyy/Kf4b0gaZx7Nq9QqOn1O3qTv 8pM0QTzDpjTiCIe+q8zOcPEfRhXD+cB0NOSGIfR6ESG7X+t1TW39Ja77LGPpOwDCYR4kEX6t994C WVS20AAhX18KdtpUm+hN/W/Os4vpuFAxXqQU4SUCmX1X8Fu4HDH1rYsclUPWfsYbR8/iz5oiQk2H BukllN/eBZD4GGbFsCT/dtMIs/LqOU9hZ/v31oRzg7QgpumQxgT4IcKeAlfy/bB/laLK9WZp+I7d gzC3lLdvK/cKOEqlCIPGIfYQDNKLLI6rY1d8Qdsix0hWyXbo 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, 23 Oct 2017 03:38:52 -0000 On 10/22/2017 8:23 PM, Martin Thomson wrote: > One thing we learned from SPDY and HTTP/2 was that the first few round > trips are critical to performance. If requests in particular can be > made smaller, you avoid running into the limit that the congestion > controller places on your total outbound bandwidth. Making integers > one octet rather than 8 makes a big difference. > > In web tests, this limit often hits hardest on the second flight of > messages, after the single request turns into hundreds. With 0-RTT > that happens after just a single RTT, so the congestion controller > probably still has the tap set to a pretty narrow setting. There is another reason -- encryption. One byte compressed away is one fewer byte to encrypt. So as long as your compression system costs less CPU than the encryption, you win. -- Christian Huitema From nobody Mon Oct 23 03:14: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 5CC4B13F3B2 for ; Mon, 23 Oct 2017 03:14:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 4xJmuB_0dTJr for ; Mon, 23 Oct 2017 03:14:15 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::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 110DF137A70 for ; Mon, 23 Oct 2017 03:14:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1508753652; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=WTgWp7o66mcTfxdCsWfUk1YPXRd7aekXDMPGf+gHex8=; b=g6rFtWEknLZaPh0anhWSk1AjeDs93afhcchibfz+E1yrHtFqlHFyEawnxVF06niV+G SE+DQqXWqKVWvdG3/AZatDYs6iJ0fJu6vosZQDzY31cq6r+lGq3DrQx0ZGFJds1Xw6cF kqfdpZ/fzRFMw6MGaQctt0nwnmwfWhylDKxfE= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKm0oaa3tXPmX/k4b6Gvg== X-RZG-CLASS-ID: mo00 Received: from [10.10.10.82] (p5DCF5CF7.dip0.t-ipconnect.de [93.207.92.247]) by smtp.strato.de (RZmta 42.8 DYNA|AUTH) with ESMTPSA id Y0538ft9NAEChJF (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, 23 Oct 2017 12:14:12 +0200 (CEST) Subject: Re: Integer encodings in QUIC frames To: quic@ietf.org References: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> <20171020031713.GE8797@1wt.eu> <66ECF599-F5A7-4D85-8A04-4518E0220CDF@ogre.com> <20171020041226.GA9423@1wt.eu> From: Roland Zink Message-ID: Date: Mon, 23 Oct 2017 12:14:12 +0200 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, 23 Oct 2017 10:14:17 -0000 Compression together with encryption also sounds somewhat dangerous. An attacker may learn something by monitoring when length changes are happening. Roland Am 23.10.2017 um 05:38 schrieb Christian Huitema: > On 10/22/2017 8:23 PM, Martin Thomson wrote: > >> One thing we learned from SPDY and HTTP/2 was that the first few round >> trips are critical to performance. If requests in particular can be >> made smaller, you avoid running into the limit that the congestion >> controller places on your total outbound bandwidth. Making integers >> one octet rather than 8 makes a big difference. >> >> In web tests, this limit often hits hardest on the second flight of >> messages, after the single request turns into hundreds. With 0-RTT >> that happens after just a single RTT, so the congestion controller >> probably still has the tap set to a pretty narrow setting. > There is another reason -- encryption. One byte compressed away is one > fewer byte to encrypt. So as long as your compression system costs less > CPU than the encryption, you win. > From nobody Mon Oct 23 04:08: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 313D0137ED6 for ; Mon, 23 Oct 2017 04:08:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SvNQQs0yThaB for ; Mon, 23 Oct 2017 04:08:03 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 67D1D13F3A5 for ; Mon, 23 Oct 2017 04:08:03 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v9NB7w3j030475; Mon, 23 Oct 2017 13:07:58 +0200 Date: Mon, 23 Oct 2017 13:07:58 +0200 From: Willy Tarreau To: Roland Zink Cc: quic@ietf.org Subject: Re: Integer encodings in QUIC frames Message-ID: <20171023110758.GE30355@1wt.eu> References: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> <20171020031713.GE8797@1wt.eu> <66ECF599-F5A7-4D85-8A04-4518E0220CDF@ogre.com> <20171020041226.GA9423@1wt.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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: Mon, 23 Oct 2017 11:08:05 -0000 On Mon, Oct 23, 2017 at 12:14:12PM +0200, Roland Zink wrote: > Compression together with encryption also sounds somewhat dangerous. An > attacker may learn something by monitoring when length changes are > happening. Here it's quite different from dictionary-based compression which is brute-forceable to disclose exact contents, in the worst case you don't disclose contents, just basic approximate of magnitude which tells you a quantity is multiplied by 256 when you see an extra byte. Given that often this may be used for stuff like content sizes, stream IDs and such elements, it hardly discloses anything of interest. However it's true that if some sensitive parts must really be kept secret, it might be better to avoid using variable length encoding for them. Willy From nobody Mon Oct 23 05:08: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 2D60B13D0B6 for ; Mon, 23 Oct 2017 05:08:00 -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] 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 y_vtY8eWh3Uf for ; Mon, 23 Oct 2017 05:07:58 -0700 (PDT) Received: from mo6-p00-ob.smtp.rzone.de (mo6-p00-ob.smtp.rzone.de [IPv6:2a01:238:20a:202:5300::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A95D138351 for ; Mon, 23 Oct 2017 05:07:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1508760476; s=domk; d=zinks.de; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version: Date:From:References:To:Subject; bh=2tuY5mNOk8bV3NyLQhsq91ezVNQ1VeJ3Yo+T7sZwaJE=; b=bjwGRNwjmb4Dd39skK9zlH/OQ2WjM787xUnCxV0pYHstTGX5BGTVMIthM6Zui5ArPW O6VjicQEXCf/3hHexTtZhSI2UOa+ggL2kR5QScDXcJkB53+KhuB0qKB9IlvpIxHlundH KiUUPyb6FEjpcNWBMy53ShMAkVkeyS+XuwvdQ= X-RZG-AUTH: :PmMIdE6sW+WWP9q/oR3Lt+I+9LAZzXrcq8knhvfmBiJzkmKm0oaa3tXPmX/k4b6Gvg== X-RZG-CLASS-ID: mo00 Received: from [10.10.10.82] (p5DCF5CF7.dip0.t-ipconnect.de [93.207.92.247]) by smtp.strato.de (RZmta 42.8 DYNA|AUTH) with ESMTPSA id Y0538ft9NC7tlqI (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, 23 Oct 2017 14:07:55 +0200 (CEST) Subject: Re: Integer encodings in QUIC frames To: quic@ietf.org References: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> <20171020031713.GE8797@1wt.eu> <66ECF599-F5A7-4D85-8A04-4518E0220CDF@ogre.com> <20171020041226.GA9423@1wt.eu> <20171023110758.GE30355@1wt.eu> From: Roland Zink Message-ID: <35303cd0-0867-3ab4-18c0-758969c3d1fc@zinks.de> Date: Mon, 23 Oct 2017 14:07:56 +0200 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: <20171023110758.GE30355@1wt.eu> 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, 23 Oct 2017 12:08:00 -0000 Not sure if those things are really of no interest. Assuming for a moment that it is possible to detect the size of the stream ID and there is a single short stream ID for a long living stream then it is possible to follow the stream after all other streams are using longer stream IDs. In most cases this shouldn't be possible but there might be some corner cases. When necessary there should be the mitigation to use some padding or use longer than necessary encodings. Regards, Roland Am 23.10.2017 um 13:07 schrieb Willy Tarreau: > On Mon, Oct 23, 2017 at 12:14:12PM +0200, Roland Zink wrote: >> Compression together with encryption also sounds somewhat dangerous. An >> attacker may learn something by monitoring when length changes are >> happening. > Here it's quite different from dictionary-based compression which > is brute-forceable to disclose exact contents, in the worst case > you don't disclose contents, just basic approximate of magnitude > which tells you a quantity is multiplied by 256 when you see an > extra byte. Given that often this may be used for stuff like content > sizes, stream IDs and such elements, it hardly discloses anything of > interest. However it's true that if some sensitive parts must really > be kept secret, it might be better to avoid using variable length > encoding for them. > > Willy > From nobody Mon Oct 23 10:58: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 AD73A139963 for ; Mon, 23 Oct 2017 10:58:58 -0700 (PDT) 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 (1024-bit key) header.d=fb.com header.b=ZVBu722X; dkim=pass (1024-bit key) header.d=fb.onmicrosoft.com header.b=g5pMvqCC Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l-BZbAMUbblb for ; Mon, 23 Oct 2017 10:58:57 -0700 (PDT) Received: from mx0a-00082601.pphosted.com (mx0a-00082601.pphosted.com [67.231.145.42]) (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 A600E139976 for ; Mon, 23 Oct 2017 10:58:55 -0700 (PDT) Received: from pps.filterd (m0044010.ppops.net [127.0.0.1]) by mx0a-00082601.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id v9NHtLKW011562; Mon, 23 Oct 2017 10:58:30 -0700 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 : content-id : content-transfer-encoding : mime-version; s=facebook; bh=GnJCgi5LIOtzhjL+Q059LjwFHJcPue+DqWjtlFeDj/I=; b=ZVBu722XBfQJPxXBJZE3rXUJStgvpEsyUp+BtRE+NVWibEW8B2gEf1oaoBTxzmCyAVMz vNON0N8xJWeobWfgeNkKWfutYU+UNQtO01TDldasUPbiL/7NjoG+Eyna3Q3Fe0eO7zKz JY3GzaimknA4VGNCJ4goIpgHUlmmxBea9xk= Received: from maileast.thefacebook.com ([199.201.65.23]) by mx0a-00082601.pphosted.com with ESMTP id 2dsj8mrqyr-1 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 23 Oct 2017 10:58:30 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (192.168.183.28) by o365-in.thefacebook.com (192.168.177.29) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 23 Oct 2017 13:58:29 -0400 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=GnJCgi5LIOtzhjL+Q059LjwFHJcPue+DqWjtlFeDj/I=; b=g5pMvqCCGyar+WW2xguwy/XHcnMhCD99RcN1BSFlW8OC0eQnw3OJaQYJfj4bkwgnLIC+r+pxz/me+r9mNJzElFwl5zmqTNMqgAASFZuLr2XttI+mokJrhsd01mDeF3CfeUJSm8KYgjfUEZK6aH5KyB98VXsUwrnExyOPiqFX3mA= Received: from DM5PR15MB1883.namprd15.prod.outlook.com (10.174.247.135) by DM5PR15MB1882.namprd15.prod.outlook.com (10.174.247.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Mon, 23 Oct 2017 17:58:27 +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.0156.007; Mon, 23 Oct 2017 17:58:27 +0000 From: Roberto Peon To: Martin Thomson , Ian Swett CC: Leif Hedstrom , QUIC WG , Willy Tarreau Subject: Re: Integer encodings in QUIC frames Thread-Topic: Integer encodings in QUIC frames Thread-Index: AQHTSHDhy0CUE2r+Qk2MSX/1XR6pbKLryF4AgABKmICAAAkbAIAABlMAgACNQICABBwGAIAA9IAA Date: Mon, 23 Oct 2017 17:58:27 +0000 Message-ID: <96007F7E-A158-483F-B4EA-C9C504794AAD@fb.com> References: <972CF01A-3791-4303-AC39-CD41540E386C@ogre.com> <20171020031713.GE8797@1wt.eu> <66ECF599-F5A7-4D85-8A04-4518E0220CDF@ogre.com> <20171020041226.GA9423@1wt.eu> 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::5:27e] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR15MB1882; 20:usu8nIkPz3Ys9Ph0KJ2Ih+L6fEiOFknSfJ70UoskA2xRCsKQcYeiThq+bvaM4mxSdyv3Mt1+YaWXgpVoKkhJTLsVSQrWWCQUJ320PY9AO5CgN2uhu/1XztL3fgrcOIPF/eLTNMarkgST7eX8y8Ttksk0pDooQyQXZg885hM7szs= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 50cc2704-5f97-4c4f-2415-08d51a3fa9c5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR15MB1882; x-ms-traffictypediagnostic: DM5PR15MB1882: x-exchange-antispam-report-test: UriScan:(211936372134217)(153496737603132); x-microsoft-antispam-prvs: 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)(10201501046)(3231020)(3002001)(920507026)(6041248)(20161123558100)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR15MB1882; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR15MB1882; x-forefront-prvs: 046985391D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(376002)(346002)(199003)(189002)(24454002)(33656002)(68736007)(2950100002)(6506006)(14454004)(25786009)(50986999)(54356999)(76176999)(305945005)(229853002)(97736004)(6486002)(34040400001)(36756003)(101416001)(53546010)(3660700001)(105586002)(2906002)(106356001)(86362001)(5660300001)(77096006)(3280700002)(82746002)(2900100001)(7736002)(6436002)(102836003)(6116002)(93886005)(83716003)(99286003)(478600001)(6246003)(39060400002)(53936002)(54906003)(8936002)(110136005)(81156014)(4326008)(6512007)(316002)(189998001)(8676002)(81166006)(42262002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR15MB1882; 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: text/plain; charset="utf-8" Content-ID: <76FE62E8D10D6644968E047E4C517AB7@namprd15.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 50cc2704-5f97-4c4f-2415-08d51a3fa9c5 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Oct 2017 17:58:27.4449 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8ae927fe-1255-47a7-a2af-5f3a069daaa2 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR15MB1882 X-OriginatorOrg: fb.com X-Proofpoint-Spam-Reason: safe X-FB-Internal: Safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-23_08:, , signatures=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: Mon, 23 Oct 2017 17:58:59 -0000 VHJ1ZSEgDQoNCi09Ug0KDQpPbiAxMC8yMi8xNywgODoyMyBQTSwgIlFVSUMgb24gYmVoYWxmIG9m IE1hcnRpbiBUaG9tc29uIiA8cXVpYy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBtYXJ0 aW4udGhvbXNvbkBnbWFpbC5jb20+IHdyb3RlOg0KDQogICAgT25lIHRoaW5nIHdlIGxlYXJuZWQg ZnJvbSBTUERZIGFuZCBIVFRQLzIgd2FzIHRoYXQgdGhlIGZpcnN0IGZldyByb3VuZA0KICAgIHRy aXBzIGFyZSBjcml0aWNhbCB0byBwZXJmb3JtYW5jZS4gIElmIHJlcXVlc3RzIGluIHBhcnRpY3Vs YXIgY2FuIGJlDQogICAgbWFkZSBzbWFsbGVyLCB5b3UgYXZvaWQgcnVubmluZyBpbnRvIHRoZSBs aW1pdCB0aGF0IHRoZSBjb25nZXN0aW9uDQogICAgY29udHJvbGxlciBwbGFjZXMgb24geW91ciB0 b3RhbCBvdXRib3VuZCBiYW5kd2lkdGguICBNYWtpbmcgaW50ZWdlcnMNCiAgICBvbmUgb2N0ZXQg cmF0aGVyIHRoYW4gOCBtYWtlcyBhIGJpZyBkaWZmZXJlbmNlLg0KICAgIA0KICAgIEluIHdlYiB0 ZXN0cywgdGhpcyBsaW1pdCBvZnRlbiBoaXRzIGhhcmRlc3Qgb24gdGhlIHNlY29uZCBmbGlnaHQg b2YNCiAgICBtZXNzYWdlcywgYWZ0ZXIgdGhlIHNpbmdsZSByZXF1ZXN0IHR1cm5zIGludG8gaHVu ZHJlZHMuICBXaXRoIDAtUlRUDQogICAgdGhhdCBoYXBwZW5zIGFmdGVyIGp1c3QgYSBzaW5nbGUg UlRULCBzbyB0aGUgY29uZ2VzdGlvbiBjb250cm9sbGVyDQogICAgcHJvYmFibHkgc3RpbGwgaGFz IHRoZSB0YXAgc2V0IHRvIGEgcHJldHR5IG5hcnJvdyBzZXR0aW5nLg0KICAgIA0KICAgIChJIHRy aWVkIGxvb2tpbmcgZm9yIGEgZ29vZCBjaXRhdGlvbiwgYnV0IEkgY291bGRuJ3QgZmluZCBvbmUu ICBNYXliZQ0KICAgIG90aGVycyBoYXZlIHBvaW50ZXJzIGF0IHRoZSByZWFkeS4pDQogICAgDQog ICAgT24gRnJpLCBPY3QgMjAsIDIwMTcgYXQgMTE6MzcgUE0sIElhbiBTd2V0dCA8aWFuc3dldHRA Z29vZ2xlLmNvbT4gd3JvdGU6DQogICAgPiBJIHdvdWxkIGFncmVlIGl0J3MgZGVmaW5pdGVseSB2 YWx1YWJsZS4gIEFsc28sIGV2ZW4gaWYgdmFyaWFibGUgbGVuZ3RoDQogICAgPiBjb2RpbmcgY29z dHMgYSBiaXQgb2YgZnJhbWluZyBDUFUsIGl0J3MgdGhhdCBtYW55IGZld2VyIGJ5dGVzIHRvDQog ICAgPiBzZW5kL3JlY2VpdmUsIGRlY3J5cHQvZW5jcnlwdCBhbmQgbW92ZSBpbnRvIENQVSBjYWNo ZS4gIEluIHRoZSB0eXBpY2FsIGNhc2UsDQogICAgPiBJIHdvdWxkIGd1ZXNzIGl0J3MgYSBuZXQg Q1BVIHNhdmluZ3MsIGF0IGxlYXN0IGZvciB0aGlzIHR5cGUgb2YgdmFyaW50LiAgSW4NCiAgICA+ IHRoZSBjYXNlIG9mIGEgc2luZ2xlIHN0cmVhbSBmcmFtZSwgdXNpbmcgdmFyaW50cyBmb3Igc3Ry ZWFtIGlkcyBhbmQgb2Zmc2V0cw0KICAgID4gc2F2ZXMgfjEyIGJ5dGVzLCB3aGljaCBpcyB+MSUg b3ZlcmhlYWQgZm9yIGZ1bGwgc2l6ZWQgcGFja2V0cyBhbmQgbW9yZSBmb3INCiAgICA+IHNtYWxs ZXIgcGF5bG9hZHMuDQogICAgPg0KICAgID4gT24gRnJpLCBPY3QgMjAsIDIwMTcgYXQgMTI6MTIg QU0sIFdpbGx5IFRhcnJlYXUgPHdAMXd0LmV1PiB3cm90ZToNCiAgICA+Pg0KICAgID4+IE9uIFRo dSwgT2N0IDE5LCAyMDE3IGF0IDA5OjQ5OjQ4UE0gLTA2MDAsIExlaWYgSGVkc3Ryb20gd3JvdGU6 DQogICAgPj4gPiBSaWdodC4gSSBwcm9iYWJseSBkaWRuJ3Qgd29yZCBteSBxdWVzdGlvbiB3ZWxs LiBXaGF0IGFtIGFza2luZyBpcywgaXMgaXQNCiAgICA+PiA+IHdvcnRoIHRoZSBjb21wbGV4aXR5 IG9mIHRoaXMgYXQgYWxsLCB0byBzYXZlIGEgZmV3IGJ5dGVzIG9uIHRoZSB3aXJlcz8NCiAgICA+ Pg0KICAgID4+IFZlcnkgb2Z0ZW4sIHllcy4gU2F2aW5nIGJ5dGVzIG9uIHRoZSB3aXJlIGlzIG1h aW5seSB3aGF0IG1ha2VzIEgyIG11Y2gNCiAgICA+PiBmYXN0ZXIgdGhhbiBIMS4NCiAgICA+Pg0K ICAgID4+IFdpbGx5DQogICAgPj4NCiAgICA+DQogICAgDQogICAgDQoNCg== From nobody Tue Oct 24 01:17: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 5DE5D13E196 for ; Tue, 24 Oct 2017 01:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 UBPt7F9oZgej for ; Tue, 24 Oct 2017 01:17:37 -0700 (PDT) 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 F406613E167 for ; Tue, 24 Oct 2017 01:17:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.43,427,1503385200"; d="asc'?scan'208";a="235347148" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx141-out.netapp.com with ESMTP; 24 Oct 2017 00:51:12 -0700 Received: from VMWEXCCAS02-PRD.hq.netapp.com (10.122.105.18) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 24 Oct 2017 01:17:35 -0700 Received: from NAM01-BY2-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; Tue, 24 Oct 2017 01:17:35 -0700 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=zrbb+270Q9cyXHcJr46PZTqeW8oZG5lrjUOUQBBOAmo=; b=f9MjuFYuC0FCbw9o69pekQTKwvr3+107CB5lRPFIWENKUullPohfCLpAqEstbpGA4NCUqrwxge7N2vNLlHdczEy1mvE2Ax2GbFSU2SAYX7CkHWSKE5nntC0lwWPqNY5P3mRFyG8md9gHpCdp1yDonESFSySaN1Mkb90rQAOBsHU= 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.156.4; Tue, 24 Oct 2017 08:17:33 +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.0156.007; Tue, 24 Oct 2017 08:17:33 +0000 From: "Eggert, Lars" To: IETF QUIC WG Subject: Re: QUIC interop at IETF-100 hackathon Thread-Topic: QUIC interop at IETF-100 hackathon Thread-Index: AQHTPT6ZUK9irHC3nEOCILSKa7KrKKLyxpcA Date: Tue, 24 Oct 2017 08:17:33 +0000 Message-ID: <05B8FFE7-F6F3-4CF4-912C-2464DC1306F6@netapp.com> References: <61671212-35D2-46A4-8CD3-D7E2102ED312@netapp.com> In-Reply-To: <61671212-35D2-46A4-8CD3-D7E2102ED312@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.1.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:plouyvoR8zp2pjpqp7YRYFJUtpUB6PeXXoWRsAdsNCWFWPomaUniV+jCS0AHqTVVPYpuZU0oCnMwKeZ/cPLdUZrJXEiv2pzL3aGAOxpQ8WkhX7atZOZG9kJRMEBW/gQHzI/hs1Ei2eYN2iuIRmm4CgUdYFZgHX/aB6bZmnhZjOBMB6p+ix7lpCL1oQU0zo/auMbvrpl0g8D/My7WEvhIzkSms8sXdoxzOJvGzDQbfnBUYMUVEa2RiEbY9Shpx/JQxs0VWb4qCBSQGxUXSuieKZkxdhvnZwlWEARXp+q0AhZg6riAPLHu2Yc70kC7WO07FN71RLKT5UL38UOvmzCPUA==; 5:/5w84Zedc+TukFetgV5tQBUoM0YaYF+tG7qUSqYIHunP5zTY6PWTkK8C4tebzIDOLEletV6v2I7mmiD+biLBjGvfAsMCMo1HVqlfDd4gUxwczYnZ/NiAapUCrxBnvJcY5brkzbbWD2GWpq6KCsP7og==; 24:aylaPZmh+lpQq0yblXQHqYt5MUGjye1xDN77vmrAfvoDYxpBmXmHdKh8gukomqvUlsctpVMyPVoceNMrkaScm3kh9Y/VsTMTkQE3LmyuUkc=; 7:1ip970eano7bqKLRyQNk/t+iinvA10jYtiVkNijsv3UOWYqAb3dm1fdSyMrmpchxk0niYuoXuzT0FLXnld4Mdwkg9SESu3Coizun6hxtvbc8NTwEEUFZXwlr9RcjjuQykchg4hs3u4AkjWkRFdB6u3b4zZs/vfYBxgAiLj/I2OQ11F/v28hiQt36iAw+ntb7drtku8tImDu97DH7zV01g9iJRBItdOtIptmeXoXPA8w= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: cfbe950b-f5e3-488d-0010-08d51ab7ad5b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627075)(201703031133081)(201702281549075)(2017052603199)(49563074); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-exchange-antispam-report-test: UriScan:(222300048226458); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(100000703101)(100105400095)(3231020)(6055026)(6041248)(20161123562025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(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: 047001DADA x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(24454002)(189002)(377424004)(199003)(2900100001)(14454004)(86362001)(966005)(4001150100001)(7736002)(97736004)(36756003)(50986999)(99936001)(76176999)(316002)(99286003)(3846002)(6116002)(102836003)(189998001)(101416001)(8936002)(106356001)(229853002)(8676002)(6436002)(77096006)(25786009)(6486002)(6246003)(50226002)(81156014)(81166006)(53936002)(6306002)(6512007)(68736007)(5660300001)(6506006)(33656002)(83716003)(82746002)(2950100002)(66066001)(305945005)(53546010)(3280700002)(6916009)(57306001)(2906002)(3660700001)(105586002)(478600001); 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=_602E0938-D97F-4C4F-973E-AAB53578B759"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: cfbe950b-f5e3-488d-0010-08d51ab7ad5b X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2017 08:17:33.1302 (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, 24 Oct 2017 08:17:38 -0000 --Apple-Mail=_602E0938-D97F-4C4F-973E-AAB53578B759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-10-4, at 20:28, Eggert, Lars wrote: > I have registered a QUIC interop as a topic for the hackathon at = IETF-100. You need to please sign up (free) if you are planning on = attending, so that space and food can be provisioned accordingly: = https://www.ietf.org/registration/MeetingWiki/wiki/100hackathon we have 13 registrations - if you are coming, please register soon! (And get on the Slack beforehand, per the instructions below.) Lars > PS: The QUIC implementers are using a Slack channel at = https://quicdev.slack.com/ for coordination/discussion. Anyone can join, = but joining requires an invite - contact your chairs if you want to = join. (FWIW, the Slack channels are *not* covered under the IETF Note = Well, since the interop events aren't either.) --Apple-Mail=_602E0938-D97F-4C4F-973E-AAB53578B759 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlnu9xwACgkQVLXDCb9w wVejCw//Xl9eGpfV5Zm47A6OgJUue2LwzcKaNUpkQhqQ3ft9CSOtsF+XvCCqIK82 wjd3hX5pmX/xJ3sZldX7TEeR77K0KVqnZoHa2zocsqlvir+C+To2V1GOzruQFOFO uMym9vICHAZfIgslYiEHnHKQ+fIvBQ+2WcVs5FwJheZQOFks3zcy8enhQzqSP25e IMU428TFXKOrcp7hv4WekV1jZzC0+Iiszs/H8XOPnzXAuZpqXOr9mw3O+HaZ0oFk y6xwOATvXOwwEbDcXkqWKx2Uem2QhhwpPqPHdLmGdZOwsnVP/wAh/GqEZV4k1rXQ I40ywqw9YZSxClV1SPD5VqKqW6o6EeOQV2uAoZiccUWh0SFdNAPiMn7p/n4s5npX WtqFOc1wK4wdapvvkzcSA/Vl2ONR06QFwvAwGoTJYHyfVlbc53yyWK591YFHUYBB Ys8xTe2VQ5RvV81NpB/L+1/li9QKfejeTfgQe2WrZP3YH036QgPv5cvR3RA4JOEf 3x6Rsal1o/Vii1knx1hCOYTkwMLR9OJoh5tlOv9XThavQQGo1vLTMMpa/JKVRMGl JyLEyN6TNnzJcSaCqxA+CaI6wKf3mFskzM4AgvZaA0oWQ7ksjIywGHtBePLCn6vF vp2T3cSkfKlZ/zJjKQD+UrmWVaVaSS/g85IOs1P1bRX+b+RM1Ik= =hTo6 -----END PGP SIGNATURE----- --Apple-Mail=_602E0938-D97F-4C4F-973E-AAB53578B759-- From nobody Wed Oct 25 01:11:51 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 5FE1213AAFF; Wed, 25 Oct 2017 01:11:44 -0700 (PDT) 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-applicability-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150891910433.4870.3011696227680449849@ietfa.amsl.com> Date: Wed, 25 Oct 2017 01:11:44 -0700 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, 25 Oct 2017 08:11:44 -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 : Applicability of the QUIC Transport Protocol Authors : Mirja Kuehlewind Brian Trammell Filename : draft-ietf-quic-applicability-01.txt Pages : 10 Date : 2017-10-25 Abstract: This document discusses the applicability of the QUIC transport protocol, focusing on caveats impacting application protocol development and deployment over QUIC. Its intended audience is designers of application protocol mappings to QUIC, and implementors of these application protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-quic-applicability-01 https://datatracker.ietf.org/doc/html/draft-ietf-quic-applicability-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-applicability-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Oct 25 01:12:09 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 A4B4113B191; Wed, 25 Oct 2017 01:11:58 -0700 (PDT) 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-manageability-01.txt X-Test-IDTracker: no X-IETF-IDTracker: 6.63.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150891911863.4826.10526078019068901313@ietfa.amsl.com> Date: Wed, 25 Oct 2017 01:11:58 -0700 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, 25 Oct 2017 08:11:59 -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 : 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=draft-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/ From nobody Wed Oct 25 10:24: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 A690313F43D for ; Wed, 25 Oct 2017 10:24:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 WIc8u-nx7B0g for ; Wed, 25 Oct 2017 10:24:42 -0700 (PDT) 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 E592013F439 for ; Wed, 25 Oct 2017 10:24:41 -0700 (PDT) Received: from xsmtp01.mail2web.com ([168.144.250.230]) by mx6.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e7PPv-0003E1-5w for quic@ietf.org; Wed, 25 Oct 2017 19:24:38 +0200 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 1e7PPH-0005zT-EM for quic@ietf.org; Wed, 25 Oct 2017 13:24:32 -0400 Received: (qmail 10410 invoked from network); 25 Oct 2017 17:23:53 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.162]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 25 Oct 2017 17:23:52 -0000 Cc: quic@ietf.org References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> To: =?UTF-8?Q?Mirja_K=c3=bchlewind?= , "Brian Trammell (IETF)" From: Christian Huitema Message-ID: <5f26e9bd-a154-ad27-8a55-00c14adf927e@huitema.net> Date: Wed, 25 Oct 2017 10:23:51 -0700 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: <150891911863.4826.10526078019068901313@ietfa.amsl.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Subject: RTT measurement in draft-ietf-quic-manageability-01.txt 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.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5sEMjUXIkqw5yY4eLIECj28Xv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fswPlyfRcv6yniMIkk2zPQqB98yDTitFWvbHwz9vKZpm2Ea bzmM/1VynIZUVImbQiuZ3JKVmi72ocgY5kMQSjs7Pk8VxOtUn7O9m8cCuN8HIa1B2N+xwNIm4bky rJMaAA/itEW1aHIJYDvx6uGLOm1Bi99Or0uXh6FskGQ3mtr4LUU/Qweyn+lg7TbDa2rNOWNaHCnN rMSSA7xor9tnUlOY8pSJo/Vkdr+FbBdda40x5B/NGyVcjXsZLVHUb2pmaEmDh4PRiBbRliPgaurB TRjstfheF24EjrGuHVHIMu1lYZhMr2sR3cQs/oU/axm99b2jdwip2wrbEvxHA2swIjN6PhFSfsse t38tyDP81cDf6vvg7iEFLP+SSY+Av5+AiC6HKG4YWo9bkyihLkdeUhghBwv09tenNPj7VSxFDx7I Q2cyTCuZfOM8Zl5jNWMMdPb+T9qKOv0z7nCHc/5d+MbcfJlbZZh01urflxdd2g4lVOY9YUFS+gfc BkEmyHl54sn3Y80OmAux3oN13+ztUznenaTY3ZroUOwdqBPQAqZRKbrGhxr0ZQNhHrBZkFm8VpZ2 Yl8zJmcAH5ay6yGU7E6A9zlhVHWcczlfu7uRBD7T6VFfEoXm0/FPF8PR0w363lnt6T5WeMaFYj2j FLtCivZ6T4NLI6gUHn0IzmqIO+zP0O8VjNzz0BoRxXlr+NDM3A9AmFJzdhFGa0lcgrZpwN1r3jR5 NeVaJQBh0uawl0Cg8rdbWpE2ux+VrvYecZwKGQXQngcHaWeBIrVwdQfI6RxMYKPh1lHgUEF4t8hJ zRZ/yYkd2x35zAiBFPp64JaIysAhPltDTcKNRvi2K+1UJ6NK 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, 25 Oct 2017 17:24:44 -0000 On 10/25/2017 1:11 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories. > This draft is a work item of the 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 I am reading your draft, and it seems that you are of two minds about RTT measurements. On one hand, in section 3.5 about Round-trip time measurement, you write: =C2=A0=C2=A0 The lack of any acknowledgement information or timestamping =C2=A0=C2=A0 information in the QUIC wire image makes running passive RTT= =C2=A0=C2=A0 estimation impossible. On the other hand, in section 4.2 about Passive network performance measurement and troubleshooting, you write: =C2=A0=C2=A0 Extremely limited loss and RTT measurement are possible by p= assive =C2=A0=C2=A0 observation of QUIC traffic; see Section 3.5 and Section 3.6= =2E Which is somewhat contradictory. Either the measurement is "impossible", or it is "extremely limited". We had lots of discussion about that in the ad hoc RTT measurement team, and the conclusion was that measurement is limited, but by no means impossible. In particular, it is trivially possible to estimate RTT during the handshake period. This is limited when you consider an individual connection, but it does provide a steady stream of measurements when observing an aggregate of multiple connections. That alone means that the word "impossible" is too strong. Another outcome of the discussion in the ad hoc team was that any measurement scheme requires some guessing about the behavior of the application. This is also true for marking schemes like the spinning bit or even the comparison of TCP sequence numbers and ACK numbers. One end of the connection will send some data, and the other end will respond after a delay. The observed end-to-end delay will encompass both the RTT and the "response delay" by the application. That response delay can be quite large when the application traffic is "sparse", such as for example the RTCP stream in an RTP application. Even when one end is sending continuously, the response delay is affected by "delayed ACK" strategies. So any measurement scheme has to include some kind of "application classifier" to guess the behavior of the application. I believe that if you do include an application classifier, then you can obtain RTT information by passive observation of encrypted traffic. You can explore single stream time correlations as explained in the INRIA paper, and you may also isolate question/response patterns. Granted, this is a bit of research issue. But flatly saying that this is impossible seems wrong. -- Christian Huitema --=20 Christian Huitema From nobody Wed Oct 25 13:17: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 69F4A1398C7 for ; Wed, 25 Oct 2017 13:17:47 -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 RExuCWdzncwT for ; Wed, 25 Oct 2017 13:17: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 9989A1398C0 for ; Wed, 25 Oct 2017 13:17:44 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 8270A340F33; Wed, 25 Oct 2017 22:17:42 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.32279); Wed, 25 Oct 2017 22:17:41 +0200 (CEST) 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, 25 Oct 2017 22:17:41 +0200 (CEST) Received: from [91.73.131.234] (account ietf@trammell.ch HELO [10.235.226.66]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 33915205; Wed, 25 Oct 2017 22:17:41 +0200 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_C51322FA-2338-4445-90FB-609955D416D6"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: RTT measurement in draft-ietf-quic-manageability-01.txt Date: Thu, 26 Oct 2017 00:17:38 +0400 In-Reply-To: <5f26e9bd-a154-ad27-8a55-00c14adf927e@huitema.net> Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , quic@ietf.org To: Christian Huitema References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> <5f26e9bd-a154-ad27-8a55-00c14adf927e@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, 25 Oct 2017 20:17:47 -0000 --Apple-Mail=_C51322FA-2338-4445-90FB-609955D416D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On 25 Oct 2017, at 21:23, Christian Huitema = wrote: >=20 >=20 >=20 > On 10/25/2017 1:11 AM, 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. >>=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 > I am reading your draft, and it seems that you are of two minds about > RTT measurements. On one hand, in section 3.5 about Round-trip time > measurement, you write: >=20 > The lack of any acknowledgement information or timestamping > information in the QUIC wire image makes running passive RTT > estimation impossible. >=20 > On the other hand, in section 4.2 about Passive network performance > measurement and troubleshooting, you write: >=20 > Extremely limited loss and RTT measurement are possible by passive > observation of QUIC traffic; see Section 3.5 and Section 3.6. >=20 > Which is somewhat contradictory. Either the measurement is = "impossible", > or it is "extremely limited". Very briefly, in transit: "running measurement" -> more than one sample = per flow. Measurement of this remains impossible, though you can = probably guess, and there might be work to do on the size of the error = bars on that guess. Maybe we can use better wording for "running" but I = believe the statement to be sound. Cheers, Brian >=20 > We had lots of discussion about that in the ad hoc RTT measurement = team, > and the conclusion was that measurement is limited, but by no means > impossible. In particular, it is trivially possible to estimate RTT > during the handshake period. This is limited when you consider an > individual connection, but it does provide a steady stream of > measurements when observing an aggregate of multiple connections. That > alone means that the word "impossible" is too strong. >=20 > Another outcome of the discussion in the ad hoc team was that any > measurement scheme requires some guessing about the behavior of the > application. This is also true for marking schemes like the spinning = bit > or even the comparison of TCP sequence numbers and ACK numbers. One = end > of the connection will send some data, and the other end will respond > after a delay. The observed end-to-end delay will encompass both the = RTT > and the "response delay" by the application. That response delay can = be > quite large when the application traffic is "sparse", such as for > example the RTCP stream in an RTP application. Even when one end is > sending continuously, the response delay is affected by "delayed ACK" > strategies. So any measurement scheme has to include some kind of > "application classifier" to guess the behavior of the application. >=20 > I believe that if you do include an application classifier, then you = can > obtain RTT information by passive observation of encrypted traffic. = You > can explore single stream time correlations as explained in the INRIA > paper, and you may also isolate question/response patterns. Granted, > this is a bit of research issue. But flatly saying that this is > impossible seems wrong. >=20 > -- Christian Huitema >=20 > -- > Christian Huitema >=20 >=20 --Apple-Mail=_C51322FA-2338-4445-90FB-609955D416D6 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAlnw8WIACgkQihK3vwvq RqPgjhAAho1cnMTwGjvuDpndRqmQe/b1l0gu+MLq2JDuoPiTq88nzkF8U0WFP0J6 IdRIdRFMpVzW89K+TvKQNiTLqR/MUBNyRTt76tEGSNvAIXAd08LQ0Mo9Mn19YzmH yQIJkJSM7huPOiRV9y//L82AzGX5yniG5a1MygjPQ/mH5BW2nr5KzzGECMhoFqfs EF/to+QqKbCKHV+/iye18JPWInK18YwCJFxAdW+OQoq2gJ3FJXw94xDnJkwPczfx xj09hgp2xxo8W3Dtdlm6BsCw51NxS+NKilOXONRf+fwolK98FlAh5HEXjDQFlmwg G4wvAMv3XFZs33GYKt/iC0h5W5Ln6DYj981eodn6nWxQTZFEe2pSWv1+LooLMfIT U1gxwQ503IuLrMrF7ASMEprFpH0rCuXolllvrHoUoyrKjDwpVXfO4WfgNwgr6JY0 hDt/leYjRKR+6gi2PGMStoKgG/aa5t3308y9w82MynTXLq1JHmT8DFsTyTTQ2jnn U+5rzb17X5fJGa0emCwii+4Ff2uThdtwK5fslCmK7H3QCHus9HeqkqjG1TUKHTNt b0pBeRr7wloCsLN+bIFHW2HsPPP1877E5qm+ClzWtawByXr7l261OWInrTOBoNVh NwqC29ak3h/QLdghC2qYl1Tjv/Di9yNPnIqg2fJBSXCsB98LwZo= =D7I2 -----END PGP SIGNATURE----- --Apple-Mail=_C51322FA-2338-4445-90FB-609955D416D6-- From nobody Wed Oct 25 13:52: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 5040F1394FB for ; Wed, 25 Oct 2017 13:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JnhdodJLxYvP for ; Wed, 25 Oct 2017 13:52:36 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::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 30D85137C4A for ; Wed, 25 Oct 2017 13:52:36 -0700 (PDT) Received: by mail-oi0-x229.google.com with SMTP id f66so2285010oib.2 for ; Wed, 25 Oct 2017 13:52:36 -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:content-transfer-encoding; bh=BzqQfuj80dQzhMppd2I2Q8lkI8IRJ7B5qxidTNsC0zc=; b=XFXD+qTTgsEw2gE/c9nLV492m3eHRiBhJYzdJR09ov9u2spYdwUx6cgMas6B4nodNO Q8WvjCKiXy1JyKQz2/Arnx9+UWr8jPD8BF4+O+0s78Pb6/7WBYQJx16Di/+whSCEnzi7 PiS4GkEMhJHi5jutS83X0piDSTU5d4XsFa7radUcN+/knpafL0dALTflQJm9wn+q6L7E 88UOIoLAAUteW2uzCMZQ4eE5y3u43I4deAbhjnOng4PhlVa+pjFD1ktrs/MPU1acbUE0 rJ8YqwdOPoGSDei4+H8j9ZtUNnmrPjKsivLJUTBGNdOzFtDi1BgJJmoQ9Ljynk+vvWss 1dkg== 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=BzqQfuj80dQzhMppd2I2Q8lkI8IRJ7B5qxidTNsC0zc=; b=HmsHj4Vh3dzD0+xnvfKPlYNunpxKroPQkMi9g8b/w6J3rFXO+O+rIQyR//l+kuBm3O 9GF6Mko4Qeoc5vGeBf6TVEEzbl2k8Xh3bvpBPxksANBwr6vuwH9KdgHEKHYe7QUrduNB OitZE0S2gU4AsWQwqfTMkToJ/wz82bGpSPBNYTw38CnjpnXjiQtRR3hyEBbH9U3l6xgx CzwxyRcTKuqbkhTp/eADnjG0QyW3t2n2zas+IJNyOcxNqeQ/v0fVz4tIREXyv/cxHli3 UAKu5b2/kZhvYu6VxtHph1xSvT/Lmgqrc+eTKYTAI8BdeqTVNvSoraav6NE6tcvgOEl7 wi7A== X-Gm-Message-State: AMCzsaVfo85omyQirMJw1z79rmwvaGSdkbX67TbT2S4W3dS9O+7dYlKx ZgT/E+qSXmrtgyPANBOzCP63ahO32VmEWqaPfMI= X-Google-Smtp-Source: ABhQp+Tdxsy0mKhqU/3OmB5U3932JIbwZxMVeLqROuMLBapDcSpR49wTn0QDni0U1OyAYcs8hN9NsFRR+QgxINbpgYI= X-Received: by 10.202.75.216 with SMTP id y207mr1760584oia.282.1508964755461; Wed, 25 Oct 2017 13:52:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Wed, 25 Oct 2017 13:52:34 -0700 (PDT) In-Reply-To: References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> <5f26e9bd-a154-ad27-8a55-00c14adf927e@huitema.net> From: Martin Thomson Date: Thu, 26 Oct 2017 07:52:34 +1100 Message-ID: Subject: Re: RTT measurement in draft-ietf-quic-manageability-01.txt To: "Brian Trammell (IETF)" Cc: Christian Huitema , QUIC WG , =?UTF-8?Q?Mirja_K=C3=BChlewind?= 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, 25 Oct 2017 20:52:37 -0000 On Thu, Oct 26, 2017 at 7:17 AM, Brian Trammell (IETF) w= rote: > Very briefly, in transit: "running measurement" -> more than one sample p= er flow. Measurement of this remains impossible, though you can probably gu= ess, and there might be work to do on the size of the error bars on that gu= ess. Maybe we can use better wording for "running" but I believe the statem= ent to be sound. It sounds like there is an opportunity for improvement. You could say that it is possible to acquire round trip time measurements during the initial connection setup, but (some measure of difficulty, maybe impossible) to do that on an ongoing basis for an established connection without significant additional information about the nature of the application protocol and possibly the specific implementation of endpoints. Correct is necessary here, but not always sufficient. From nobody Wed Oct 25 14:14: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 3D7AB137C4A for ; Wed, 25 Oct 2017 14:14:07 -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 vsI_CkRgBAlf for ; Wed, 25 Oct 2017 14:14:04 -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 59307137ED6 for ; Wed, 25 Oct 2017 14:14:04 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id A408534051D; Wed, 25 Oct 2017 23:14:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.16172); Wed, 25 Oct 2017 23:14:02 +0200 (CEST) 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, 25 Oct 2017 23:14:02 +0200 (CEST) Received: from [87.200.50.34] (account ietf@trammell.ch HELO [10.234.105.97]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 33917869; Wed, 25 Oct 2017 23:14:01 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: RTT measurement in draft-ietf-quic-manageability-01.txt From: "Brian Trammell (IETF)" X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Thu, 26 Oct 2017 01:13:57 +0400 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , QUIC WG , Christian Huitema Content-Transfer-Encoding: quoted-printable Message-Id: References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> <5f26e9bd-a154-ad27-8a55-00c14adf927e@huitema.net> To: Martin Thomson 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, 25 Oct 2017 21:14:07 -0000 Sent from my iPhone > On 26 Oct 2017, at 00:52, Martin Thomson wrote:= >=20 >> On Thu, Oct 26, 2017 at 7:17 AM, Brian Trammell (IETF) = wrote: >> Very briefly, in transit: "running measurement" -> more than one sample p= er flow. Measurement of this remains impossible, though you can probably gue= ss, and there might be work to do on the size of the error bars on that gues= s. Maybe we can use better wording for "running" but I believe the statement= to be sound. >=20 > It sounds like there is an opportunity for improvement. You could say > that it is possible to acquire round trip time measurements during the > initial connection setup, but (some measure of difficulty, maybe > impossible) to do that on an ongoing basis for an established > connection without significant additional information about the nature > of the application protocol and possibly the specific implementation > of endpoints. =20 That seems like a better phrasing. But there is a tradeoff here: the point o= f favoring explicit measurement over implicit is to keep something simple li= ke basic performance measurement from having an otherwise unnecessary =E2=80= =9Cclassify traffic=E2=80=9D or =E2=80=9Ccharacterize application=E2=80=9D s= tep.=20 > Correct is necessary here, but not always sufficient. From nobody Wed Oct 25 14:19: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 42D2513F472 for ; Wed, 25 Oct 2017 14:19:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ky0Gnm9MltH for ; Wed, 25 Oct 2017 14:19:09 -0700 (PDT) Received: from mail-oi0-x233.google.com (mail-oi0-x233.google.com [IPv6:2607:f8b0:4003:c06::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 1573213F467 for ; Wed, 25 Oct 2017 14:19:09 -0700 (PDT) Received: by mail-oi0-x233.google.com with SMTP id c77so2408094oig.0 for ; Wed, 25 Oct 2017 14:19:09 -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:content-transfer-encoding; bh=l/5wcjPndid+BkBU5zasBZHyuqSVKHqLdaor1GAVlF4=; b=ZCs9uh9R2MXhkV5Cja5OZjJQ0hKpeHn8DbOPtK0bGaWS+lrqwUuGUAG91cCo5py3wL IiSPOPwYjNuekBMtRdWu5894GbYbSaW5igvwFLJDDBZ0+H5dqCzgQOX/a9L6Jdd3i9aw rYo9p9z9X36F0v7JBRU2yfhMBsa3KHuhS1tbb4L6PoDSq6wa9m/bJlZZ9dknZdcP2TtG 1wetkE34xf84kkw7oHTV9cV5Kg87c6VfQklJxEorl6RSGTTqpFMfhiqbjDKF6zpm18Y0 ElVfsZWRRuIPy9OYgEGX2A7Bt7ouCoLvvG9G7XEJ6bllg/OoUsmHorEcntbfs8kmwitp 8npw== 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=l/5wcjPndid+BkBU5zasBZHyuqSVKHqLdaor1GAVlF4=; b=gzbnSCe4Kk/pDzzHfLQ0cxSs6YXr+1vgJao2IAvkMo2kdCfZAwip40F4gvX60reWJm OPetMHl78yyfrP6HgZcb3RmPtWcXYwmCEW8guUq7KzXzWITtYGMfago2fZDEsU3+fHEA D7P7y028Tp6f2mXI/Cle6XbQkBsHeYwcMFb3A7sT2zUwWnjX8QIAmisKFMqL7SVojPzP kPCAdT7R62dZbUGKAzszgH5oI0V2YtjpwBTJlPscDmOMB6R0dXmQ9s2el6rxNWsk68ra wy2wySBC9FytHrfB4rt3HospsUazidFKKycDV+XeyvwALCiPaDO/WSO75sEGXvJZslGr Wzug== X-Gm-Message-State: AMCzsaVLTW0ZRE4hBBTtb8VZHkTgNHknFPhMOJtZ5G+Bs9nLXv/rRZ1n hrzWBWVPpFA7hizkgXq0B87Au7dH4u4h8MIG1cw= X-Google-Smtp-Source: ABhQp+QsehzLZW+KB437O8DysOCyXlz1FhSMh3qSkwFzXzSEqyH4awkq8YOu7SFZHUr3MIjemwQmeGRwoHEyTYePng4= X-Received: by 10.157.37.90 with SMTP id j26mr2106730otd.401.1508966348411; Wed, 25 Oct 2017 14:19:08 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Wed, 25 Oct 2017 14:19:07 -0700 (PDT) In-Reply-To: References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> <5f26e9bd-a154-ad27-8a55-00c14adf927e@huitema.net> From: Martin Thomson Date: Thu, 26 Oct 2017 08:19:07 +1100 Message-ID: Subject: Re: RTT measurement in draft-ietf-quic-manageability-01.txt To: "Brian Trammell (IETF)" Cc: =?UTF-8?Q?Mirja_K=C3=BChlewind?= , QUIC WG , Christian Huitema 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, 25 Oct 2017 21:19:10 -0000 On Thu, Oct 26, 2017 at 8:13 AM, Brian Trammell (IETF) w= rote: >> It sounds like there is an opportunity for improvement. You could say >> that it is possible to acquire round trip time measurements during the >> initial connection setup, but (some measure of difficulty, maybe >> impossible) to do that on an ongoing basis for an established >> connection without significant additional information about the nature >> of the application protocol and possibly the specific implementation >> of endpoints. > > That seems like a better phrasing. But there is a tradeoff here: the poin= t of favoring explicit measurement over implicit is to keep something simpl= e like basic performance measurement from having an otherwise unnecessary = =E2=80=9Cclassify traffic=E2=80=9D or =E2=80=9Ccharacterize application=E2= =80=9D step. Hmm, reading this again it almost reads like an exhortation to traffic analysis. Maybe I could be uncharitable and say that that is what people will do, but maybe also that doesn't need to be written down. "It's hard" might be enough. From nobody Wed Oct 25 15: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 138F51394F2 for ; Wed, 25 Oct 2017 15:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wuu65lDyazSb for ; Wed, 25 Oct 2017 15:01:20 -0700 (PDT) Received: from mail.strugglingcoder.info (strugglingcoder.info [104.236.146.68]) by ietfa.amsl.com (Postfix) with ESMTP id B699C139F44 for ; Wed, 25 Oct 2017 15:01:20 -0700 (PDT) Received: from localhost (unknown [10.1.1.3]) (Authenticated sender: hiren@strugglingcoder.info) by mail.strugglingcoder.info (Postfix) with ESMTPA id E78E6177CE; Wed, 25 Oct 2017 15:01:23 -0700 (PDT) Date: Wed, 25 Oct 2017 15:01:23 -0700 From: hiren panchasara To: mirja.kuehlewind@tik.ee.ethz.ch, ietf@trammell.ch Cc: quic@ietf.org Subject: Re: I-D Action: draft-ietf-quic-applicability-01.txt Message-ID: <20171025220123.GZ47441@strugglingcoder.info> References: <150891910433.4870.3011696227680449849@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="6WmFnK5hpO10R5Wg" Content-Disposition: inline In-Reply-To: <150891910433.4870.3011696227680449849@ietfa.amsl.com> User-Agent: Mutt/1.5.23 (2014-03-12) 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, 25 Oct 2017 22:01:22 -0000 --6WmFnK5hpO10R5Wg Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 10/25/17 at 01:11P, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the QUIC WG of the IETF. >=20 > Title : Applicability of the QUIC Transport Protocol > Authors : Mirja Kuehlewind > Brian Trammell > Filename : draft-ietf-quic-applicability-01.txt > Pages : 10 > Date : 2017-10-25 >=20 > Abstract: > This document discusses the applicability of the QUIC transport > protocol, focusing on caveats impacting application protocol > development and deployment over QUIC. Its intended audience is > designers of application protocol mappings to QUIC, and implementors > of these application protocols. Thank you for your work! I've suggested a few very minor changes via github PR. Hope that's okay.=20 Cheers, Hiren --6WmFnK5hpO10R5Wg Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQF8BAABCgBmBQJZ8QmwXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lvxsH/inqSigvN69iplFaMkLd3C0c K4otar/UAo+szwRAkV8FJcd/QH/MFzvnhCmnp9CQQmX1vUdJ2J817Rh5geNv0nV0 AKeBlANEK5opaHTvF8rnYJl+IMqtLX5JLpUvIC+rk5SqHstkQwrC9p2KR8MmZRtG XzLxg9ZPgR83Xjzx1wvU9LSUlS6qrqo7aHd3q+uT+3/yBX4TlzW5xGz+8nEUfhyc s3wWXtc/0zuPeXSjmmHQz/AR//saPhqIKtfCn7EYFHlFVMEOnovAxg7lw1gVdPTF 6nAe1mTEvr+qKcoPqs8yGDyx4WRAPT0ewsC/pb1BCbCno8wuI/PXDV3JnLlW058= =NBCn -----END PGP SIGNATURE----- --6WmFnK5hpO10R5Wg-- From nobody Wed Oct 25 15:45: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 64A4713AB2F for ; Wed, 25 Oct 2017 15:45:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ywId5S7VK_2Q for ; Wed, 25 Oct 2017 15:45:28 -0700 (PDT) Received: from virgo01.ee.ethz.ch (virgo01.ee.ethz.ch [129.132.2.226]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BDC1396DD for ; Wed, 25 Oct 2017 15:45:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by virgo01.ee.ethz.ch (Postfix) with ESMTP id 3yMlbC0LFrzMn39; Thu, 26 Oct 2017 00:45:27 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at virgo01.ee.ethz.ch Received: from virgo01.ee.ethz.ch ([127.0.0.1]) by localhost (virgo01.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOdY_OSYQn9O; Thu, 26 Oct 2017 00:45:26 +0200 (CEST) X-MtScore: NO score=0 Received: from [192.168.178.33] (p5DEC26AD.dip0.t-ipconnect.de [93.236.38.173]) by virgo01.ee.ethz.ch (Postfix) with ESMTPSA; Thu, 26 Oct 2017 00:45:25 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: I-D Action: draft-ietf-quic-applicability-01.txt From: =?utf-8?Q?Mirja_K=C3=BChlewind?= In-Reply-To: <20171025220123.GZ47441@strugglingcoder.info> Date: Thu, 26 Oct 2017 00:45:24 +0200 Cc: ietf@trammell.ch, quic@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <945EB932-B7A3-47BC-A7C1-17B85007FAA0@tik.ee.ethz.ch> References: <150891910433.4870.3011696227680449849@ietfa.amsl.com> <20171025220123.GZ47441@strugglingcoder.info> To: hiren panchasara 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, 25 Oct 2017 22:45:30 -0000 Yes, thanks! > Am 26.10.2017 um 00:01 schrieb hiren panchasara = : >=20 > On 10/25/17 at 01:11P, internet-drafts@ietf.org wrote: >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the QUIC WG of the IETF. >>=20 >> Title : Applicability of the QUIC Transport Protocol >> Authors : Mirja Kuehlewind >> Brian Trammell >> Filename : draft-ietf-quic-applicability-01.txt >> Pages : 10 >> Date : 2017-10-25 >>=20 >> Abstract: >> This document discusses the applicability of the QUIC transport >> protocol, focusing on caveats impacting application protocol >> development and deployment over QUIC. Its intended audience is >> designers of application protocol mappings to QUIC, and = implementors >> of these application protocols. >=20 > Thank you for your work! >=20 > I've suggested a few very minor changes via github PR. > Hope that's okay.=20 >=20 > Cheers, > Hiren From nobody Wed Oct 25 19:19: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 5CDE01387BC for ; Wed, 25 Oct 2017 19:19:19 -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 3-vTbnWX0kAS for ; Wed, 25 Oct 2017 19:19:18 -0700 (PDT) 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 164BF13955B for ; Wed, 25 Oct 2017 19:19:18 -0700 (PDT) Received: by mail-ua0-x236.google.com with SMTP id u32so1444789uau.0 for ; Wed, 25 Oct 2017 19:19:18 -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; bh=1FIxcrooE1S0gqKu6KUhZMilmFcFqrS5LuVTK08x1T4=; b=aV4P7jwgYoYQ9NRA2s4l+Qhm1qh5R1+LHdLwTgEO8ZsCFUTGicR4d8j1jKtECNNXzr RCoGRMvpU7G6RUNzlaxX6Vho9ps2BayKUjuS0dp2XUGCkfmFmerLqqLUoorFsRiUAdiu kXwrQhvC9v8j21L+aaddBs+LL6flrlDTKAZCTO+E6fd3rKLUv2o0Lc1urehAnMFUk4Bc uhXyc7xtnLLsJdp3lnrOGWLUa9YBN0bnE0q9loIU1yI8QYIwhyowcagbZitPiDrgiSL2 Bco79bAlo6twMYJx3eEx2qV3ZjfBO6M/qaEPdX4FdXjt3F0KF6Yd6RFGzQK7zSuu8USx RWlQ== 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=1FIxcrooE1S0gqKu6KUhZMilmFcFqrS5LuVTK08x1T4=; b=FS7o2z1I1O5Hk4EkbBwmbVT/yUl5aaLJyX+vScc14F8yd7c9MHH7IqioTrVCbqVzr4 V6IVCi1+9V9HAxslBx3+UQYtrRQtVpNL7M+Wkv5SQ9Wr1EnYAdsYT9+7wMR9703anUcK Xbvf63i0pBwZW5ZbIkRakZk1vodl9yshvEnur/izxQJbWWgSTblOxwyNn7kK/610mC4A mpMAHHqKhPV81Az4WZxwlL/RjVqRsmys2cJ1hMMWmYu+tF6s8UMhL6ONiDBxgeG7nOFg 13pFZWTA/cK00OvlLc3TOHx2gcHBfQbtBcXH+iG96H2/HZdHu7fic8VWh3l8MHO6PkqS q5Jw== X-Gm-Message-State: AMCzsaXi+LAZJpsAXIwx3HA16AgUFosQUfM4VmOmy8cSn99/V+B5RVHV UMGscNswHBUppc0uU9npP+BBOnhvilLiccvGUPFK4Q== X-Google-Smtp-Source: ABhQp+SEWOtC68ithDda30kTE09KYyfWb67YD+vGMOEcfeDNaOEorNXLLoHvJS/FwqDHzMOZJipR8kEahOkRdDCMKw8= X-Received: by 10.176.73.72 with SMTP id a8mr3216593uad.65.1508984356918; Wed, 25 Oct 2017 19:19:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Wed, 25 Oct 2017 19:18:56 -0700 (PDT) In-Reply-To: <150880044283.25241.5162965282478482032.idtracker@ietfa.amsl.com> References: <150880044283.25241.5162965282478482032.idtracker@ietfa.amsl.com> From: Bernard Aboba Date: Wed, 25 Oct 2017 19:18:56 -0700 Message-ID: Subject: Fwd: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt To: quic@ietf.org Content-Type: multipart/alternative; boundary="001a1145375490da35055c69cc6e" 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, 26 Oct 2017 02:19:19 -0000 --001a1145375490da35055c69cc6e Content-Type: text/plain; charset="UTF-8" A new version of I-D, draft-aboba-avtcore-quic-multiplexing-00.txt has been successfully submitted by and posted to the IETF repository. Name: draft-aboba-avtcore-quic-multiplexing Revision: 00 Title: QUIC Multiplexing Document date: 2017-10-23 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-aboba-avtcore- quic-multiplexing-00.txt Status: https://datatracker.ietf.org/doc/draft-aboba-avtcore-quic- multiplexing/ Htmlized: https://tools.ietf.org/html/draft-aboba-avtcore-quic- multiplexing-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-aboba-avtcore- quic-multiplexing-00 Abstract: This document describes potential approaches to multiplexing of QUIC along with RTP, RTCP, DTLS, STUN, TURN and ZRTP in WebRTC peer-to- peer data exchange. --001a1145375490da35055c69cc6e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

A new version of I-D, draft-aboba-avtcore-quic-multiplexing-00.txt
has been successfully submitted by and posted to the IETF
repository.
Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-aboba-avtcore-quic-multiplexing
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 QUIC Multiplexing
Document date:=C2=A0 2017-10-23
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-= aboba-avtcore-quic-multiplexing-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-aboba-avtcore-quic-= multiplexing/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiple= xing-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-aboba-avtcor= e-quic-multiplexing-00


Abstract:
=C2=A0 =C2=A0This document describes potential approaches to multiplexing o= f QUIC
=C2=A0 =C2=A0along with RTP, RTCP, DTLS, STUN, TURN and ZRTP in WebRTC peer= -to-
=C2=A0 =C2=A0peer data exchange.


--001a1145375490da35055c69cc6e-- From nobody Wed Oct 25 22:06: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 6080C13A214 for ; Wed, 25 Oct 2017 22:06:29 -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 Y9lF5mng36Gk for ; Wed, 25 Oct 2017 22:06:27 -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 924C4138BE2 for ; Wed, 25 Oct 2017 22:06:26 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id 07B8A340D5B; Thu, 26 Oct 2017 07:06:24 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.6590); Thu, 26 Oct 2017 07:06:23 +0200 (CEST) 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, 26 Oct 2017 07:06:23 +0200 (CEST) Received: from [213.55.176.224] (account ietf@trammell.ch HELO [10.162.87.43]) by switchplus-mail.ch (CommuniGate Pro SMTP 6.1.18) with ESMTPSA id 33935090; Thu, 26 Oct 2017 07:06:23 +0200 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: RTT measurement in draft-ietf-quic-manageability-01.txt From: "Brian Trammell (IETF)" X-Mailer: iPhone Mail (15A432) In-Reply-To: Date: Thu, 26 Oct 2017 07:04:56 +0200 Cc: =?utf-8?Q?Mirja_K=C3=BChlewind?= , QUIC WG , Christian Huitema Content-Transfer-Encoding: quoted-printable Message-Id: <30D7E8E3-BE3C-4EE8-9170-D159FF788BF5@trammell.ch> References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> <5f26e9bd-a154-ad27-8a55-00c14adf927e@huitema.net> To: Martin Thomson 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, 26 Oct 2017 05:06:29 -0000 Agreed. after a flight to think about it: if after the DT comes back in Sing= apore we end up with no signal that facilitates other-than-handshake RTT, it= =E2=80=99s probably just best to point out handshake RTT measurement, and t= o note that QUIC has no facility equivalent to seq/tsopt full stop, without a= ny further commentary. Sent from my iPhone > On 25 Oct 2017, at 23:19, Martin Thomson wrote:= >=20 > On Thu, Oct 26, 2017 at 8:13 AM, Brian Trammell (IETF) w= rote: >>> It sounds like there is an opportunity for improvement. You could say >>> that it is possible to acquire round trip time measurements during the >>> initial connection setup, but (some measure of difficulty, maybe >>> impossible) to do that on an ongoing basis for an established >>> connection without significant additional information about the nature >>> of the application protocol and possibly the specific implementation >>> of endpoints. >>=20 >> That seems like a better phrasing. But there is a tradeoff here: the poin= t of favoring explicit measurement over implicit is to keep something simple= like basic performance measurement from having an otherwise unnecessary =E2= =80=9Cclassify traffic=E2=80=9D or =E2=80=9Ccharacterize application=E2=80=9D= step. >=20 > Hmm, reading this again it almost reads like an exhortation to traffic > analysis. Maybe I could be uncharitable and say that that is what > people will do, but maybe also that doesn't need to be written down. > "It's hard" might be enough. From nobody Wed Oct 25 23:47: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 56F44138FA0 for ; Wed, 25 Oct 2017 23:47:51 -0700 (PDT) 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 TG-HtZkLtxnE for ; Wed, 25 Oct 2017 23:47:49 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C269D1398CA for ; Wed, 25 Oct 2017 23:47:48 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRI64308; Thu, 26 Oct 2017 06:47:46 +0000 (GMT) Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 26 Oct 2017 07:47:45 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.154]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0301.000; Thu, 26 Oct 2017 14:47:42 +0800 From: Roni Even To: Bernard Aboba , "quic@ietf.org" Subject: RE: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt Thread-Topic: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt Thread-Index: AQHTTgDcAGdGWYIOLEKJouy2FztFk6L1qzFg Date: Thu, 26 Oct 2017 06:47:41 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD82187C@DGGEMM506-MBX.china.huawei.com> References: <150880044283.25241.5162965282478482032.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.202.65] Content-Type: multipart/alternative; boundary="_000_6E58094ECC8D8344914996DAD28F1CCD82187CDGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59F18513.000F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.154, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 9e78146070efd980c334c8ea3a474af9 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, 26 Oct 2017 06:47:51 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD82187CDGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpXaGVuIGxvb2tpbmcgYXQgdGhlIHByb2JsZW0gaW4gdGhlIFdFQlJUQyBjb250ZW50cyBJ IGFtIHdvbmRlcmluZyBpZiB3ZSBjYW5ub3QgYWRkcmVzcyBpdCB3aXRob3V0IG11bHRpcGxleGlu Zy4NClRoZSB1c2UgY2FzZSBpcyB3aGVuIGJ1bmRsaW5nIHRoZSBSVFAgbWVkaWEgc3RyZWFtcyB3 aXRoIHRoZSBEYXRhIGNoYW5uZWwuDQoNCjEuICAgICAgIElmIHdlIGJ1bmRsZSBSVFAgb3ZlciBR VUlDIGFuZCBEYXRhIGNoYW5uZWwgb3ZlciBRVUlDIHVzaW5nIHRoZSBzYW1lIFFVSUMgY29ubmVj dGlvbiB0aGVyZSBpcyBubyBwcm9ibGVtLg0KDQoyLiAgICAgICBJZiB3ZSB1c2UgUlRQIG92ZXIg UVVJQyBpcyB0aGVyZSBhbnkgcmVhc29uIHRvIHJ1biB0aGUgZGF0YSBjaGFubmVsIG92ZXIgVURQ L0RUTFMvU0NUUD8gSWYgeWVzIHdlIG5lZWQgdG8gYWRkcmVzcyBpdCBhbHNvIGluIHRoZSBIZXVy aXN0aWMgb3B0aW9uDQoNCjMuICAgICAgIElmIHdlIHVzZSBSVFAgb3ZlciBVRFAvRFRMUyBhbmQg dGhlIERhdGEgY2hhbm5lbCBvdmVyIFFVSUMgaXQgaXMgZGlzY3Vzc2VkIGluIHRoZSBIZXVyaXN0 aWMgc2VjdGlvbiBidXQgaXQgc2VlbXMgbGlrZSB0aGUgcmVjb21tZW5kYXRpb24gdGhlcmUgaXMg IGZvciBXRUJSVEMgdG8gbWFuZGF0ZSB0aGF0IHRoZSBEYXRhIGNoYW5uZWwgaW4gdGhpcyBjYXNl IHdpbGwgdXNlIFVEUC9EVExTL1NDVFAgLiBJIHRoaW5rIHRoYXQgVURQL0RUTFMvU0NUUCBwcm92 aWRlcyBzaW1pbGFyIGZ1bmN0aW9uYWxpdHkgdG8gUVVJQw0KDQpJIHRoaW5rIHRoYXQgdGhpcyBk b2N1bWVudCBpcyBzdGlsbCBuZWVkZWQgZm9yIGEgZ2VuZXJhbCBjYXNlIHdoZW4gd2UgYnVuZGxl IFJUUCB3aXRoIFFVSUMgbm90IGZvciB0aGUgV0VCUlRDIGNhc2UgYnV0IHN0aWxsIHdvbmRlciBp ZiB3aGVuIFJUUCBpcyBvdmVyIFVEUC9EVExTIHdoeSB1c2UgUVVJQyBmb3IgYSBidW5kbGVkIG5v biBSVFAgZGF0YSBhbmQgbm90IGxldmVyYWdlIHRoZSBVRFAvRFRMUyBjb25uZWN0aW9uIG9yIHdo eSBub3QgcnVuIFJUUCBvdmVyIFFVSUMgaW4gdGhpcyBjYXNlLg0KDQpSb25pIEV2ZW4NCg0KRnJv bTogUVVJQyBbbWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlcm5h cmQgQWJvYmENClNlbnQ6INeZ15XXnSDXlCAyNiDXkNeV16fXmNeV15HXqCAyMDE3IDA1OjE5DQpU bzogcXVpY0BpZXRmLm9yZw0KU3ViamVjdDogRndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g Zm9yIGRyYWZ0LWFib2JhLWF2dGNvcmUtcXVpYy1tdWx0aXBsZXhpbmctMDAudHh0DQoNCg0KQSBu ZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFib2JhLWF2dGNvcmUtcXVpYy1tdWx0aXBsZXhpbmct MDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYNCnJlcG9zaXRvcnkuDQoNCk5hbWU6ICAgICAgICAgICBkcmFmdC1hYm9iYS1hdnRj b3JlLXF1aWMtbXVsdGlwbGV4aW5nDQpSZXZpc2lvbjogICAgICAgMDANClRpdGxlOiAgICAgICAg ICBRVUlDIE11bHRpcGxleGluZw0KRG9jdW1lbnQgZGF0ZTogIDIwMTctMTAtMjMNCkdyb3VwOiAg ICAgICAgICBJbmRpdmlkdWFsIFN1Ym1pc3Npb24NClBhZ2VzOiAgICAgICAgICA5DQpVUkw6ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFib2Jh LWF2dGNvcmUtcXVpYy1tdWx0aXBsZXhpbmctMDAudHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6 Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYWJvYmEtYXZ0Y29yZS1xdWljLW11bHRp cGxleGluZy8NCkh0bWxpemVkOiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtYWJvYmEtYXZ0Y29yZS1xdWljLW11bHRpcGxleGluZy0wMA0KSHRtbGl6ZWQ6ICAgICAgIGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYWJvYmEtYXZ0Y29yZS1x dWljLW11bHRpcGxleGluZy0wMA0KDQoNCkFic3RyYWN0Og0KICAgVGhpcyBkb2N1bWVudCBkZXNj cmliZXMgcG90ZW50aWFsIGFwcHJvYWNoZXMgdG8gbXVsdGlwbGV4aW5nIG9mIFFVSUMNCiAgIGFs b25nIHdpdGggUlRQLCBSVENQLCBEVExTLCBTVFVOLCBUVVJOIGFuZCBaUlRQIGluIFdlYlJUQyBw ZWVyLXRvLQ0KICAgcGVlciBkYXRhIGV4Y2hhbmdlLg0KDQo= --_000_6E58094ECC8D8344914996DAD28F1CCD82187CDGGEMM506MBXchina_ 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 Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltYXJnaW4tYm90 dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsInNlcmlm Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0K Lk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjc0MDM3MTI1MTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTEzMTU1NDU2NDIgNjc2OTg3MDMgNjc2 OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3 MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0 O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7 fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4t bG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTow Y207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBt c28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYi IC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBl bGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0K PC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+V2hlbiBsb29r aW5nIGF0IHRoZSBwcm9ibGVtIGluIHRoZSBXRUJSVEMgY29udGVudHMgSSBhbSB3b25kZXJpbmcg aWYgd2UgY2Fubm90IGFkZHJlc3MgaXQgd2l0aG91dCBtdWx0aXBsZXhpbmcuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSB1c2UgY2FzZSBpcyB3aGVuIGJ1bmRsaW5nIHRoZSBSVFAg bWVkaWEgc3RyZWFtcyB3aXRoIHRoZSBEYXRhIGNoYW5uZWwuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0 O21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Okln bm9yZSI+MS48c3BhbiBzdHlsZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv dDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48 L3NwYW4+PCFbZW5kaWZdPjxzcGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPklmIHdlIGJ1bmRsZSBSVFAgb3ZlciBRVUlDIGFuZCBE YXRhIGNoYW5uZWwgb3ZlciBRVUlDIHVzaW5nIHRoZSBzYW1lIFFVSUMgY29ubmVjdGlvbiB0aGVy ZSBpcyBubyBwcm9ibGVtLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb0xp c3RQYXJhZ3JhcGgiIHN0eWxlPSJ0ZXh0LWluZGVudDotMTguMHB0O21zby1saXN0OmwwIGxldmVs MSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+Mi48c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxz cGFuIGRpcj0iTFRSIj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPklmIHdlIHVzZSBSVFAgb3ZlciBRVUlDIGlzIHRoZXJlIGFueSByZWFzb24gdG8gcnVu IHRoZSBkYXRhIGNoYW5uZWwgb3ZlciBVRFAvRFRMUy9TQ1RQPyBJZiB5ZXMgd2UgbmVlZCB0byBh ZGRyZXNzIGl0IGFsc28gaW4NCiB0aGUgSGV1cmlzdGljIG9wdGlvbjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4 LjBwdDttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tbGlz dDpJZ25vcmUiPjMuPHNwYW4gc3R5bGU9ImZvbnQ6Ny4wcHQgJnF1b3Q7VGltZXMgTmV3IFJvbWFu JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj48L3Nw YW4+PC9zcGFuPjwhW2VuZGlmXT48c3BhbiBkaXI9IkxUUiI+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JZiB3ZSB1c2UgUlRQIG92ZXIgVURQL0RUTFMg YW5kIHRoZSBEYXRhIGNoYW5uZWwgb3ZlciBRVUlDIGl0IGlzIGRpc2N1c3NlZCBpbiB0aGUgSGV1 cmlzdGljIHNlY3Rpb24gYnV0IGl0IHNlZW1zIGxpa2UgdGhlIHJlY29tbWVuZGF0aW9uDQogdGhl cmUgaXMmbmJzcDsgZm9yIFdFQlJUQyB0byBtYW5kYXRlIHRoYXQgdGhlIERhdGEgY2hhbm5lbCBp biB0aGlzIGNhc2Ugd2lsbCB1c2UgVURQL0RUTFMvU0NUUCAuIEkgdGhpbmsgdGhhdCBVRFAvRFRM Uy9TQ1RQIHByb3ZpZGVzIHNpbWlsYXIgZnVuY3Rpb25hbGl0eSB0byBRVUlDDQo8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PkkgdGhpbmsgdGhhdCB0aGlzIGRvY3VtZW50IGlzIHN0aWxsIG5lZWRlZCBmb3IgYSBnZW5lcmFs IGNhc2Ugd2hlbiB3ZSBidW5kbGUgUlRQIHdpdGggUVVJQyBub3QgZm9yIHRoZSBXRUJSVEMgY2Fz ZSBidXQgc3RpbGwgd29uZGVyIGlmIHdoZW4gUlRQIGlzIG92ZXIgVURQL0RUTFMNCiB3aHkgdXNl IFFVSUMgZm9yIGEgYnVuZGxlZCBub24gUlRQIGRhdGEgYW5kIG5vdCBsZXZlcmFnZSB0aGUgVURQ L0RUTFMgY29ubmVjdGlvbiBvciB3aHkgbm90IHJ1biBSVFAgb3ZlciBRVUlDIGluIHRoaXMgY2Fz ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPlJvbmkgRXZlbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt bGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4N CjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtw YWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDsiPiBRVUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVo YWxmIE9mIDwvYj5CZXJuYXJkIEFib2JhPGJyPg0KPGI+U2VudDo8L2I+IDxzcGFuIGxhbmc9IkhF IiBkaXI9IlJUTCI+15nXldedJm5ic3A715QgMjYg15DXlden15jXldeR16ggMjAxNyAwNToxOTwv c3Bhbj48YnI+DQo8Yj5Ubzo8L2I+IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g RndkOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWFib2JhLWF2dGNvcmUtcXVp Yy1tdWx0aXBsZXhpbmctMDAudHh0PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxi cj4NCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVsdGlw bGV4aW5nLTAwLnR4dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgYW5k IHBvc3RlZCB0byB0aGUgSUVURjxicj4NCnJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWFib2JhLWF2dGNvcmUt cXVpYy1tdWx0aXBsZXhpbmc8YnI+DQpSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDswMDxicj4NClRpdGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUVVJQyBN dWx0aXBsZXhpbmc8YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE3LTEwLTIzPGJyPg0KR3Jv dXA6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Np b248YnI+DQpQYWdlczombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDk8YnI+DQpV Ukw6Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGEgaHJlZj0iaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFib2JhLWF2dGNvcmUtcXVp Yy1tdWx0aXBsZXhpbmctMDAudHh0IiB0YXJnZXQ9Il9ibGFuayI+DQpodHRwczovL3d3dy5pZXRm Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtYWJvYmEtYXZ0Y29yZS1xdWljLW11bHRpcGxleGlu Zy0wMC50eHQ8L2E+PGJyPg0KU3RhdHVzOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDs8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1hYm9iYS1h dnRjb3JlLXF1aWMtbXVsdGlwbGV4aW5nLyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFib2JhLWF2dGNvcmUtcXVpYy1tdWx0aXBsZXhpbmcv PC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0 dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVsdGlw bGV4aW5nLTAwIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWFib2JhLWF2dGNvcmUtcXVpYy1tdWx0aXBsZXhpbmctMDA8L2E+PGJyPg0KSHRtbGl6ZWQ6 Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVsdGlwbGV4aW5nLTAw IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9k cmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVsdGlwbGV4aW5nLTAwPC9hPjxicj4NCjxicj4NCjxi cj4NCkFic3RyYWN0Ojxicj4NCiZuYnNwOyAmbmJzcDtUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBw b3RlbnRpYWwgYXBwcm9hY2hlcyB0byBtdWx0aXBsZXhpbmcgb2YgUVVJQzxicj4NCiZuYnNwOyAm bmJzcDthbG9uZyB3aXRoIFJUUCwgUlRDUCwgRFRMUywgU1RVTiwgVFVSTiBhbmQgWlJUUCBpbiBX ZWJSVEMgcGVlci10by08YnI+DQombmJzcDsgJm5ic3A7cGVlciBkYXRhIGV4Y2hhbmdlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_6E58094ECC8D8344914996DAD28F1CCD82187CDGGEMM506MBXchina_-- From nobody Thu Oct 26 04:03:42 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 071041387BC for ; Thu, 26 Oct 2017 04:03:41 -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 glz0XbQmamoS for ; Thu, 26 Oct 2017 04:03:38 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86: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 AC15B13AF23 for ; Thu, 26 Oct 2017 04:03:37 -0700 (PDT) Received: from [81.187.2.149] (port=44686 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1e7fwl-0002H7-Cq; Thu, 26 Oct 2017 12:03:35 +0100 From: Colin Perkins Message-Id: <8B7FC28B-ECA8-4C91-8AA2-94429767C59D@csperkins.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_8E30F867-1810-4515-A6C3-A9E92DC9BE6E" Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt Date: Thu, 26 Oct 2017 12:03:25 +0100 In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD82187C@DGGEMM506-MBX.china.huawei.com> Cc: Bernard Aboba , "quic@ietf.org" To: Roni Even References: <150880044283.25241.5162965282478482032.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD82187C@DGGEMM506-MBX.china.huawei.com> 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: Thu, 26 Oct 2017 11:03:41 -0000 --Apple-Mail=_8E30F867-1810-4515-A6C3-A9E92DC9BE6E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Roni, It would be possible to run RTP and/or the data channel over QUIC, I = agree (although we haven=E2=80=99t yet specified how to do so).=20 We still need to either de-multiplex STUN and QUIC on the same port, or = re-invent STUN within QUIC, if we want to run peer-to-peer QUIC. Colin > On 26 Oct 2017, at 07:47, Roni Even wrote: >=20 > Hi, > When looking at the problem in the WEBRTC contents I am wondering if = we cannot address it without multiplexing. > The use case is when bundling the RTP media streams with the Data = channel. > 1. If we bundle RTP over QUIC and Data channel over QUIC using = the same QUIC connection there is no problem. > 2. If we use RTP over QUIC is there any reason to run the data = channel over UDP/DTLS/SCTP? If yes we need to address it also in the = Heuristic option > 3. If we use RTP over UDP/DTLS and the Data channel over QUIC it = is discussed in the Heuristic section but it seems like the = recommendation there is for WEBRTC to mandate that the Data channel in = this case will use UDP/DTLS/SCTP . I think that UDP/DTLS/SCTP provides = similar functionality to QUIC > =20 > I think that this document is still needed for a general case when we = bundle RTP with QUIC not for the WEBRTC case but still wonder if when = RTP is over UDP/DTLS why use QUIC for a bundled non RTP data and not = leverage the UDP/DTLS connection or why not run RTP over QUIC in this = case. > =20 > Roni Even > =20 > From: QUIC [mailto:quic-bounces@ietf.org = ] On Behalf Of Bernard Aboba > Sent: =D7=99=D7=95=D7=9D =D7=94 26 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91=D7= =A8 2017 05:19 > To: quic@ietf.org > Subject: Fwd: New Version Notification for = draft-aboba-avtcore-quic-multiplexing-00.txt > =20 >=20 > A new version of I-D, draft-aboba-avtcore-quic-multiplexing-00.txt > has been successfully submitted by and posted to the IETF > repository. >=20 > Name: draft-aboba-avtcore-quic-multiplexing > Revision: 00 > Title: QUIC Multiplexing > Document date: 2017-10-23 > Group: Individual Submission > Pages: 9 > URL: = https://www.ietf.org/internet-drafts/draft-aboba-avtcore-quic-multiplexing= -00.txt = > Status: = https://datatracker.ietf.org/doc/draft-aboba-avtcore-quic-multiplexing/ = > Htmlized: = https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexing-00 = > Htmlized: = https://datatracker.ietf.org/doc/html/draft-aboba-avtcore-quic-multiplexin= g-00 = >=20 >=20 > Abstract: > This document describes potential approaches to multiplexing of = QUIC > along with RTP, RTCP, DTLS, STUN, TURN and ZRTP in WebRTC peer-to- > peer data exchange. >=20 --=20 Colin Perkins https://csperkins.org/ --Apple-Mail=_8E30F867-1810-4515-A6C3-A9E92DC9BE6E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Roni,

It= would be possible to run RTP and/or the data channel over QUIC, I agree = (although we haven=E2=80=99t yet specified how to do = so). 

We = still need to either de-multiplex STUN and QUIC on the same port, or = re-invent STUN within QUIC, if we want  to run peer-to-peer = QUIC.

Colin



On = 26 Oct 2017, at 07:47, Roni Even <roni.even@huawei.com> wrote:

Hi,
When looking at the problem in the WEBRTC = contents I am wondering if we cannot address it without = multiplexing.
The use case is when = bundling the RTP media streams with the Data channel.
1.       If = we bundle RTP over QUIC and Data channel over QUIC using the same QUIC = connection there is no problem.
2.       If = we use RTP over QUIC is there any reason to run the data channel over = UDP/DTLS/SCTP? If yes we need to address it also in the Heuristic = option
3.       If = we use RTP over UDP/DTLS and the Data channel over QUIC it is discussed = in the Heuristic section but it seems like the recommendation there = is  for WEBRTC to mandate that the Data channel in this case will = use UDP/DTLS/SCTP . I think that UDP/DTLS/SCTP provides similar = functionality to QUIC
 
I think that this = document is still needed for a general case when we bundle RTP with QUIC = not for the WEBRTC case but still wonder if when RTP is over UDP/DTLS = why use QUIC for a bundled non RTP data and not leverage the UDP/DTLS = connection or why not run RTP over QUIC in this case.
 
Roni Even
 
From: QUIC [mailto:quic-bounces@ietf.org] On Behalf = Of Bernard = Aboba
Sent: =D7=99=D7=95=D7=9D =D7=94 26 =D7=90=D7=95=D7=A7=D7=98=D7=95= =D7=91=D7=A8 2017 05:19
To: quic@ietf.org
Subject: Fwd: New Version = Notification for draft-aboba-avtcore-quic-multiplexing-00.txt
 


A = new version of I-D, draft-aboba-avtcore-quic-multiplexing-00.txt
has been successfully submitted by and posted to the IETF
repository.

Name:    =        draft-aboba-avtcore-quic-multiplexing
Revision:       00
Title:          QUIC Multiplexing
Document date:  2017-10-23
Group:  =         Individual Submission
Pages:          9
URL:            https://www.ietf.org/internet-drafts/draft-aboba-avtcore-quic-m= ultiplexing-00.txt
Status:        =  https://datatracker.ietf.org/doc/draft-aboba-avtcore-quic-multi= plexing/
Htmlized:       https://tools.ietf.org/html/draft-aboba-avtcore-quic-multiplexi= ng-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-aboba-avtcore-quic-= multiplexing-00


Abstract:
   This document describes = potential approaches to multiplexing of QUIC
  =  along with RTP, RTCP, DTLS, STUN, TURN and ZRTP in WebRTC = peer-to-
   peer data = exchange.




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




= --Apple-Mail=_8E30F867-1810-4515-A6C3-A9E92DC9BE6E-- From nobody Thu Oct 26 04:43: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 06F2E13B278 for ; Thu, 26 Oct 2017 04:43:50 -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 BsVvhrVRVqFF for ; Thu, 26 Oct 2017 04:43:48 -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 20E6B13836B for ; Thu, 26 Oct 2017 04:43:46 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYM22729; Thu, 26 Oct 2017 11:43:45 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Thu, 26 Oct 2017 12:43:30 +0100 Received: from DGGEMM506-MBX.china.huawei.com ([169.254.3.154]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0301.000; Thu, 26 Oct 2017 19:43:26 +0800 From: Roni Even To: Colin Perkins CC: Bernard Aboba , "quic@ietf.org" Subject: RE: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt Thread-Topic: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt Thread-Index: AQHTTkoWtGQxStBH9UeV3bGMfPquY6L1+zUA Date: Thu, 26 Oct 2017 11:43:26 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD821980@DGGEMM506-MBX.china.huawei.com> References: <150880044283.25241.5162965282478482032.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD82187C@DGGEMM506-MBX.china.huawei.com> <8B7FC28B-ECA8-4C91-8AA2-94429767C59D@csperkins.org> In-Reply-To: <8B7FC28B-ECA8-4C91-8AA2-94429767C59D@csperkins.org> 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_6E58094ECC8D8344914996DAD28F1CCD821980DGGEMM506MBXchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.59F1CA71.00C4, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.3.154, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0c67c849cecdd0a07f3b5843d14e95e2 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, 26 Oct 2017 11:43:50 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD821980DGGEMM506MBXchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQ29saW4sDQpTbyB0aGVyZSBpcyBhIGNhc2Ugb2YgU1RVTiBhbmQgUVVJQyBidXQgd2l0aG91 dCBSVFAgZm9yIGVzdGFibGlzaGluZyB0aGUgUVVJQyBwZWVyIHRvIHBlZXIuIEl0IGJlY29tZXMg YSBzaW1wbGVyIHByb2JsZW0gaWYgd2UgcmVjb21tZW5kIHRvIG5vdCBtdWx0aXBsZXggUlRQIGFu ZCBRVUlDICh1c2luZyBSVFAgb3ZlciBRVUlDIHdoaWNoIHdlIHN0YXJ0ZWQgdG8gc3BlY2lmeSku ICBUaGlzIGlzIG5vdCBhIHByb2JsZW0gaWYgU1RVTiBpcyBiZWZvcmUgUVVJQyBzdGFydHMgb3Ig d2l0aCBRVUlDIGxvbmcgaGVhZGVyLg0KDQpUaGUgbWFqb3IgcmVhc29uIEkgc2VlIGZvciBub3Qg bXVsdGlwbGV4aW5nIFJUUCBhbmQgUVVJQyBpcyB0aGUgbmVlZCBoYXZlIHR3byBzZWN1cml0eSBj b250ZXh0IG9uZSBmb3IgUlRQIGFuZCBvbmUgZm9yIFFVSUMgIHNvIGluIHRoaXMgY2FzZSBpZiBS VFAgaXMgdXNlZCBJIHN1Z2dlc3RlZCBhcyBhbHNvIG1lbnRpb25lZCBpbiB0aGUgZG9jdW1lbnQg dG8gdXNlIFVEUC9EVExTL1NDVFAgZm9yIHRoZSBkYXRhIGNoYW5uZWwgYW5kIG5vdCBRVUlDIHNp bmNlIFNDVFAgb3ZlciBVRFAvRFRMUyAgaXMgcXVpZXQgc2ltaWxhciB0byBRVUlDICAuDQoNCg0K U28gdGhlIHF1ZXN0aW9uIGlzIHdoYXQgd2Ugd2FudCB0byBhZGRyZXNzIGluIHRoZSBtdWx0aXBs ZXhpbmcsIGRvIHdlIG5lZWQgdG8gbXVsdGlwbGV4IGV2ZXJ5dGhpbmcgb3IgY2FuIHdlIGRlZmlu ZSB0aGUgcmVsZXZhbnQgc3Vic2V0IChSVFAgYW5kIGRhdGEgbXVsdGlwbGV4ZWQgb3ZlciBRVUlD IG9yIFJUUCBhbmQgZGF0YSBtdWx0aXBsZXhlZCB3aXRob3V0IFFVSUMpIGJlZm9yZSBnb2luZyB0 byBhIHNvbHV0aW9uLiBJdCBtYXkgbWFrZSB0aGUgc29sdXRpb24gc2ltcGxlci4NCg0KSSBjYW4g YWdyZWUgdGhhdCB3ZSBtYXkgZmFpbCBpbiBwcm92aWRpbmcgYSBnb29kIHNvbHV0aW9uIGZvciBS VFAgb3ZlciBRVUlDIGJ1dCB0aGF0IGNhbiBsZWFkIHRvIHRoZSBSVFAgb3ZlciBVRFAvVExTIGFu ZCBkYXRhIG92ZXIgdWRwL2R0bHMvc2N0cCBvcHRpb24gbGVhdmluZyB0aGUgbmVlZCBmb3IgU1RV TiBhbmQgUVVJQyBmb3IgcGVlciB0byBwZWVyIGNvbm5lY3Rpb24uDQoNClJvbmkNCg0KRnJvbTog Q29saW4gUGVya2lucyBbbWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnXQ0KU2VudDog15nXldedINeU IDI2INeQ15XXp9eY15XXkdeoIDIwMTcgMTQ6MDMNClRvOiBSb25pIEV2ZW4NCkNjOiBCZXJuYXJk IEFib2JhOyBxdWljQGlldGYub3JnDQpTdWJqZWN0OiBSZTogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVsdGlwbGV4aW5nLTAwLnR4dA0KDQpI aSBSb25pLA0KDQpJdCB3b3VsZCBiZSBwb3NzaWJsZSB0byBydW4gUlRQIGFuZC9vciB0aGUgZGF0 YSBjaGFubmVsIG92ZXIgUVVJQywgSSBhZ3JlZSAoYWx0aG91Z2ggd2UgaGF2ZW7igJl0IHlldCBz cGVjaWZpZWQgaG93IHRvIGRvIHNvKS4NCg0KV2Ugc3RpbGwgbmVlZCB0byBlaXRoZXIgZGUtbXVs dGlwbGV4IFNUVU4gYW5kIFFVSUMgb24gdGhlIHNhbWUgcG9ydCwgb3IgcmUtaW52ZW50IFNUVU4g d2l0aGluIFFVSUMsIGlmIHdlIHdhbnQgIHRvIHJ1biBwZWVyLXRvLXBlZXIgUVVJQy4NCg0KQ29s aW4NCg0KDQoNCk9uIDI2IE9jdCAyMDE3LCBhdCAwNzo0NywgUm9uaSBFdmVuIDxyb25pLmV2ZW5A aHVhd2VpLmNvbTxtYWlsdG86cm9uaS5ldmVuQGh1YXdlaS5jb20+PiB3cm90ZToNCg0KSGksDQpX aGVuIGxvb2tpbmcgYXQgdGhlIHByb2JsZW0gaW4gdGhlIFdFQlJUQyBjb250ZW50cyBJIGFtIHdv bmRlcmluZyBpZiB3ZSBjYW5ub3QgYWRkcmVzcyBpdCB3aXRob3V0IG11bHRpcGxleGluZy4NClRo ZSB1c2UgY2FzZSBpcyB3aGVuIGJ1bmRsaW5nIHRoZSBSVFAgbWVkaWEgc3RyZWFtcyB3aXRoIHRo ZSBEYXRhIGNoYW5uZWwuDQoxLiAgICAgICBJZiB3ZSBidW5kbGUgUlRQIG92ZXIgUVVJQyBhbmQg RGF0YSBjaGFubmVsIG92ZXIgUVVJQyB1c2luZyB0aGUgc2FtZSBRVUlDIGNvbm5lY3Rpb24gdGhl cmUgaXMgbm8gcHJvYmxlbS4NCjIuICAgICAgIElmIHdlIHVzZSBSVFAgb3ZlciBRVUlDIGlzIHRo ZXJlIGFueSByZWFzb24gdG8gcnVuIHRoZSBkYXRhIGNoYW5uZWwgb3ZlciBVRFAvRFRMUy9TQ1RQ PyBJZiB5ZXMgd2UgbmVlZCB0byBhZGRyZXNzIGl0IGFsc28gaW4gdGhlIEhldXJpc3RpYyBvcHRp b24NCjMuICAgICAgIElmIHdlIHVzZSBSVFAgb3ZlciBVRFAvRFRMUyBhbmQgdGhlIERhdGEgY2hh bm5lbCBvdmVyIFFVSUMgaXQgaXMgZGlzY3Vzc2VkIGluIHRoZSBIZXVyaXN0aWMgc2VjdGlvbiBi dXQgaXQgc2VlbXMgbGlrZSB0aGUgcmVjb21tZW5kYXRpb24gdGhlcmUgaXMgIGZvciBXRUJSVEMg dG8gbWFuZGF0ZSB0aGF0IHRoZSBEYXRhIGNoYW5uZWwgaW4gdGhpcyBjYXNlIHdpbGwgdXNlIFVE UC9EVExTL1NDVFAgLiBJIHRoaW5rIHRoYXQgVURQL0RUTFMvU0NUUCBwcm92aWRlcyBzaW1pbGFy IGZ1bmN0aW9uYWxpdHkgdG8gUVVJQw0KDQpJIHRoaW5rIHRoYXQgdGhpcyBkb2N1bWVudCBpcyBz dGlsbCBuZWVkZWQgZm9yIGEgZ2VuZXJhbCBjYXNlIHdoZW4gd2UgYnVuZGxlIFJUUCB3aXRoIFFV SUMgbm90IGZvciB0aGUgV0VCUlRDIGNhc2UgYnV0IHN0aWxsIHdvbmRlciBpZiB3aGVuIFJUUCBp cyBvdmVyIFVEUC9EVExTIHdoeSB1c2UgUVVJQyBmb3IgYSBidW5kbGVkIG5vbiBSVFAgZGF0YSBh bmQgbm90IGxldmVyYWdlIHRoZSBVRFAvRFRMUyBjb25uZWN0aW9uIG9yIHdoeSBub3QgcnVuIFJU UCBvdmVyIFFVSUMgaW4gdGhpcyBjYXNlLg0KDQpSb25pIEV2ZW4NCg0KRnJvbTogUVVJQyBbbWFp bHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEJlcm5hcmQgQWJvYmENClNl bnQ6INeZ15XXnSDXlCAyNiDXkNeV16fXmNeV15HXqCAyMDE3IDA1OjE5DQpUbzogcXVpY0BpZXRm Lm9yZzxtYWlsdG86cXVpY0BpZXRmLm9yZz4NClN1YmplY3Q6IEZ3ZDogTmV3IFZlcnNpb24gTm90 aWZpY2F0aW9uIGZvciBkcmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVsdGlwbGV4aW5nLTAwLnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVs dGlwbGV4aW5nLTAwLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBhbmQg cG9zdGVkIHRvIHRoZSBJRVRGDQpyZXBvc2l0b3J5Lg0KDQpOYW1lOiAgICAgICAgICAgZHJhZnQt YWJvYmEtYXZ0Y29yZS1xdWljLW11bHRpcGxleGluZw0KUmV2aXNpb246ICAgICAgIDAwDQpUaXRs ZTogICAgICAgICAgUVVJQyBNdWx0aXBsZXhpbmcNCkRvY3VtZW50IGRhdGU6ICAyMDE3LTEwLTIz DQpHcm91cDogICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQpQYWdlczogICAgICAgICAg OQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9k cmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVsdGlwbGV4aW5nLTAwLnR4dA0KU3RhdHVzOiAgICAg ICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWFib2JhLWF2dGNvcmUt cXVpYy1tdWx0aXBsZXhpbmcvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LWFib2JhLWF2dGNvcmUtcXVpYy1tdWx0aXBsZXhpbmctMDANCkh0bWxpemVk OiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWFib2Jh LWF2dGNvcmUtcXVpYy1tdWx0aXBsZXhpbmctMDANCg0KDQpBYnN0cmFjdDoNCiAgIFRoaXMgZG9j dW1lbnQgZGVzY3JpYmVzIHBvdGVudGlhbCBhcHByb2FjaGVzIHRvIG11bHRpcGxleGluZyBvZiBR VUlDDQogICBhbG9uZyB3aXRoIFJUUCwgUlRDUCwgRFRMUywgU1RVTiwgVFVSTiBhbmQgWlJUUCBp biBXZWJSVEMgcGVlci10by0NCiAgIHBlZXIgZGF0YSBleGNoYW5nZS4NCg0KDQoNCi0tDQpDb2xp biBQZXJraW5zDQpodHRwczovL2NzcGVya2lucy5vcmcvDQoNCg0KDQo= --_000_6E58094ECC8D8344914996DAD28F1CCD821980DGGEMM506MBXchina_ 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 c2VyaWYiO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFw cGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUt bmFtZToiQmFsbG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28t c3R5bGUtbGluazoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1z ZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt c2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0 Ow0KCW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9u MQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwv eG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hh cGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIg bGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPkhpIENvbGluLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyB0aGVyZSBp cyBhIGNhc2Ugb2YgU1RVTiBhbmQgUVVJQyBidXQgd2l0aG91dCBSVFAgZm9yIGVzdGFibGlzaGlu ZyB0aGUgUVVJQyBwZWVyIHRvIHBlZXIuIEl0IGJlY29tZXMgYSBzaW1wbGVyIHByb2JsZW0gaWYg d2UgcmVjb21tZW5kIHRvIG5vdCBtdWx0aXBsZXggUlRQDQogYW5kIFFVSUMgKHVzaW5nIFJUUCBv dmVyIFFVSUMgd2hpY2ggd2Ugc3RhcnRlZCB0byBzcGVjaWZ5KS4gJm5ic3A7VGhpcyBpcyBub3Qg YSBwcm9ibGVtIGlmIFNUVU4gaXMgYmVmb3JlIFFVSUMgc3RhcnRzIG9yIHdpdGggUVVJQyBsb25n IGhlYWRlci48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPlRoZSBtYWpvciByZWFzb24gSSBzZWUgZm9yIG5vdCBtdWx0aXBs ZXhpbmcgUlRQIGFuZCBRVUlDIGlzIHRoZSBuZWVkIGhhdmUgdHdvIHNlY3VyaXR5IGNvbnRleHQg b25lIGZvciBSVFAgYW5kIG9uZSBmb3IgUVVJQyAmbmJzcDtzbyBpbiB0aGlzIGNhc2UgaWYgUlRQ IGlzIHVzZWQNCiBJIHN1Z2dlc3RlZCBhcyBhbHNvIG1lbnRpb25lZCBpbiB0aGUgZG9jdW1lbnQg dG8gdXNlIFVEUC9EVExTL1NDVFAgZm9yIHRoZSBkYXRhIGNoYW5uZWwgYW5kIG5vdCBRVUlDIHNp bmNlIFNDVFAgb3ZlciBVRFAvRFRMUyAmbmJzcDtpcyBxdWlldCBzaW1pbGFyIHRvIFFVSUMgJm5i c3A7LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPlNvIHRo ZSBxdWVzdGlvbiBpcyB3aGF0IHdlIHdhbnQgdG8gYWRkcmVzcyBpbiB0aGUgbXVsdGlwbGV4aW5n LCBkbyB3ZSBuZWVkIHRvIG11bHRpcGxleCBldmVyeXRoaW5nIG9yIGNhbiB3ZSBkZWZpbmUgdGhl IHJlbGV2YW50IHN1YnNldCAoUlRQIGFuZCBkYXRhIG11bHRpcGxleGVkDQogb3ZlciBRVUlDIG9y IFJUUCBhbmQgZGF0YSBtdWx0aXBsZXhlZCB3aXRob3V0IFFVSUMpIGJlZm9yZSBnb2luZyB0byBh IHNvbHV0aW9uLiBJdCBtYXkgbWFrZSB0aGUgc29sdXRpb24gc2ltcGxlci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkkg Y2FuIGFncmVlIHRoYXQgd2UgbWF5IGZhaWwgaW4gcHJvdmlkaW5nIGEgZ29vZCBzb2x1dGlvbiBm b3IgUlRQIG92ZXIgUVVJQyBidXQgdGhhdCBjYW4gbGVhZCB0byB0aGUgUlRQIG92ZXIgVURQL1RM UyBhbmQgZGF0YSBvdmVyIHVkcC9kdGxzL3NjdHAgb3B0aW9uIGxlYXZpbmcNCiB0aGUgbmVlZCBm b3IgU1RVTiBhbmQgUVVJQyBmb3IgcGVlciB0byBwZWVyIGNvbm5lY3Rpb24uPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1 b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5S b25pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBj bSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZh bWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IENvbGluIFBl cmtpbnMgW21haWx0bzpjc3BAY3NwZXJraW5zLm9yZ10NCjxicj4NCjxiPlNlbnQ6PC9iPiA8c3Bh biBsYW5nPSJIRSIgZGlyPSJSVEwiPteZ15XXnSZuYnNwO9eUIDI2INeQ15XXp9eY15XXkdeoIDIw MTcgMTQ6MDM8L3NwYW4+PGJyPg0KPGI+VG86PC9iPiBSb25pIEV2ZW48YnI+DQo8Yj5DYzo8L2I+ IEJlcm5hcmQgQWJvYmE7IHF1aWNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IE5l dyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtYWJvYmEtYXZ0Y29yZS1xdWljLW11bHRp cGxleGluZy0wMC50eHQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSBSb25pLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SXQgd291bGQgYmUgcG9zc2libGUgdG8gcnVuIFJUUCBhbmQvb3IgdGhlIGRhdGEgY2hhbm5l bCBvdmVyIFFVSUMsIEkgYWdyZWUgKGFsdGhvdWdoIHdlIGhhdmVu4oCZdCB5ZXQgc3BlY2lmaWVk IGhvdyB0byBkbyBzbykuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPldlIHN0aWxsIG5lZWQgdG8gZWl0aGVyIGRlLW11bHRpcGxleCBT VFVOIGFuZCBRVUlDIG9uIHRoZSBzYW1lIHBvcnQsIG9yIHJlLWludmVudCBTVFVOIHdpdGhpbiBR VUlDLCBpZiB3ZSB3YW50ICZuYnNwO3RvIHJ1biBwZWVyLXRvLXBlZXIgUVVJQy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q29saW48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBw dDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiAy NiBPY3QgMjAxNywgYXQgMDc6NDcsIFJvbmkgRXZlbiAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbmku ZXZlbkBodWF3ZWkuY29tIj5yb25pLmV2ZW5AaHVhd2VpLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90Oztjb2xvcjojMUY0OTdEIj5XaGVuIGxvb2tpbmcgYXQgdGhlIHByb2JsZW0gaW4gdGhlIFdF QlJUQyBjb250ZW50cyBJIGFtIHdvbmRlcmluZyBpZiB3ZSBjYW5ub3QgYWRkcmVzcyBpdCB3aXRo b3V0IG11bHRpcGxleGluZy48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+VGhlIHVzZSBjYXNlIGlzIHdoZW4gYnVuZGxpbmcgdGhlIFJUUCBtZWRpYSBzdHJlYW1z IHdpdGggdGhlIERhdGEgY2hhbm5lbC48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXYgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0idGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9y OiMxRjQ5N0QiPjEuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFG NDk3RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYNCiB3ZSBidW5kbGUgUlRQIG92ZXIgUVVJQyBh bmQgRGF0YSBjaGFubmVsIG92ZXIgUVVJQyB1c2luZyB0aGUgc2FtZSBRVUlDIGNvbm5lY3Rpb24g dGhlcmUgaXMgbm8gcHJvYmxlbS48L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXYg c3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i dGV4dC1pbmRlbnQ6LTE4LjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMx RjQ5N0QiPjIuPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7Y29sb3I6IzFGNDk3 RCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SWYNCiB3ZSB1c2UgUlRQIG92ZXIgUVVJQyBpcyB0aGVy ZSBhbnkgcmVhc29uIHRvIHJ1biB0aGUgZGF0YSBjaGFubmVsIG92ZXIgVURQL0RUTFMvU0NUUD8g SWYgeWVzIHdlIG5lZWQgdG8gYWRkcmVzcyBpdCBhbHNvIGluIHRoZSBIZXVyaXN0aWMgb3B0aW9u PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2IHN0eWxlPSJtYXJnaW4tbGVmdDoz Ni4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9InRleHQtaW5kZW50Oi0xOC4wcHQi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4zLjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjcuMHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5 N0QiPklmDQogd2UgdXNlIFJUUCBvdmVyIFVEUC9EVExTIGFuZCB0aGUgRGF0YSBjaGFubmVsIG92 ZXIgUVVJQyBpdCBpcyBkaXNjdXNzZWQgaW4gdGhlIEhldXJpc3RpYyBzZWN0aW9uIGJ1dCBpdCBz ZWVtcyBsaWtlIHRoZSByZWNvbW1lbmRhdGlvbiB0aGVyZSBpcyZuYnNwOyBmb3IgV0VCUlRDIHRv IG1hbmRhdGUgdGhhdCB0aGUgRGF0YSBjaGFubmVsIGluIHRoaXMgY2FzZSB3aWxsIHVzZSBVRFAv RFRMUy9TQ1RQIC4gSSB0aGluayB0aGF0IFVEUC9EVExTL1NDVFAgcHJvdmlkZXMNCiBzaW1pbGFy IGZ1bmN0aW9uYWxpdHkgdG8gUVVJQzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFG NDk3RCI+SSB0aGluayB0aGF0IHRoaXMgZG9jdW1lbnQgaXMgc3RpbGwgbmVlZGVkIGZvciBhIGdl bmVyYWwgY2FzZSB3aGVuIHdlIGJ1bmRsZSBSVFAgd2l0aCBRVUlDIG5vdCBmb3IgdGhlIFdFQlJU QyBjYXNlIGJ1dCBzdGlsbCB3b25kZXIgaWYgd2hlbiBSVFAgaXMgb3ZlciBVRFAvRFRMUw0KIHdo eSB1c2UgUVVJQyBmb3IgYSBidW5kbGVkIG5vbiBSVFAgZGF0YSBhbmQgbm90IGxldmVyYWdlIHRo ZSBVRFAvRFRMUyBjb25uZWN0aW9uIG9yIHdoeSBub3QgcnVuIFJUUCBvdmVyIFFVSUMgaW4gdGhp cyBjYXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj4mbmJz cDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Um9uaSBFdmVu PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVy LWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7 cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBjbGFz cz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWls eTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+UVVJQw0KIFs8YSBo cmVmPSJtYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iY29sb3I6cHVy cGxlIj5tYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT5dPHNwYW4gY2xhc3M9 ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxiPk9uIEJlaGFsZiBPZjxzcGFu IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L2I+QmVybmFyZCBB Ym9iYTxicj4NCjxiPlNlbnQ6PC9iPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJIRSIgZGlyPSJSVEwiPteZ15XXnSZuYnNwO9eUIDI2 INeQ15XXp9eY15XXkdeoIDIwMTcgMDU6MTk8L3NwYW4+PGJyPg0KPGI+VG86PC9iPjxzcGFuIGNs YXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YSBocmVmPSJtYWlsdG86 cXVpY0BpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+cXVpY0BpZXRmLm9yZzwv c3Bhbj48L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPkZ3ZDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBk cmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVsdGlwbGV4aW5nLTAwLnR4dDwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCkEgbmV3IHZl cnNpb24gb2YgSS1ELCBkcmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVsdGlwbGV4aW5nLTAwLnR4 dDxicj4NCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgYW5kIHBvc3RlZCB0byB0 aGUgSUVURjxicj4NCnJlcG9zaXRvcnkuPGJyPg0KPGJyPg0KTmFtZTombmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO2RyYWZ0LWFib2JhLWF2dGNvcmUtcXVpYy1tdWx0aXBs ZXhpbmc8YnI+DQpSZXZpc2lvbjombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDswMDxicj4NClRp dGxlOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUVVJQyBNdWx0aXBsZXhpbmc8 YnI+DQpEb2N1bWVudCBkYXRlOiZuYnNwOyAyMDE3LTEwLTIzPGJyPg0KR3JvdXA6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBJbmRpdmlkdWFsIFN1Ym1pc3Npb248YnI+DQpQYWdl czombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDk8YnI+DQpVUkw6Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50 ZXJuZXQtZHJhZnRzL2RyYWZ0LWFib2JhLWF2dGNvcmUtcXVpYy1tdWx0aXBsZXhpbmctMDAudHh0 IiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWFib2JhLWF2dGNvcmUtcXVpYy1tdWx0aXBs ZXhpbmctMDAudHh0PC9zcGFuPjwvYT48YnI+DQpTdGF0dXM6Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWFib2JhLWF2dGNvcmUtcXVpYy1tdWx0aXBsZXhpbmcvIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYWJvYmEtYXZ0Y29yZS1xdWljLW11bHRpcGxleGluZy88L3NwYW4+PC9hPjxicj4NCkh0 bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVsdGlwbGV4aW5nLTAwIiB0 YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNvbG9yOnB1cnBsZSI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL2RyYWZ0LWFib2JhLWF2dGNvcmUtcXVpYy1tdWx0aXBsZXhpbmctMDA8L3Nw YW4+PC9hPjxicj4NCkh0bWxpemVkOiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYWJvYmEtYXZ0Y29y ZS1xdWljLW11bHRpcGxleGluZy0wMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xv cjpwdXJwbGUiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtYWJv YmEtYXZ0Y29yZS1xdWljLW11bHRpcGxleGluZy0wMDwvc3Bhbj48L2E+PGJyPg0KPGJyPg0KPGJy Pg0KQWJzdHJhY3Q6PGJyPg0KJm5ic3A7ICZuYnNwO1RoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHBv dGVudGlhbCBhcHByb2FjaGVzIHRvIG11bHRpcGxleGluZyBvZiBRVUlDPGJyPg0KJm5ic3A7ICZu YnNwO2Fsb25nIHdpdGggUlRQLCBSVENQLCBEVExTLCBTVFVOLCBUVVJOIGFuZCBaUlRQIGluIFdl YlJUQyBwZWVyLXRvLTxicj4NCiZuYnNwOyAmbmJzcDtwZWVyIGRhdGEgZXhjaGFuZ2UuPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+ DQo8YnI+DQotLSZuYnNwOzxicj4NCkNvbGluIFBlcmtpbnM8YnI+DQo8YSBocmVmPSJodHRwczov L2NzcGVya2lucy5vcmcvIj5odHRwczovL2NzcGVya2lucy5vcmcvPC9hPjxicj4NCjxicj4NCjxi cj4NCjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4N Cg== --_000_6E58094ECC8D8344914996DAD28F1CCD821980DGGEMM506MBXchina_-- From nobody Thu Oct 26 05:38: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 4CBB813AD2D for ; Thu, 26 Oct 2017 05:38: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, 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 YJcsqSimQg06 for ; Thu, 26 Oct 2017 05:38:28 -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 E69D5137A70 for ; Thu, 26 Oct 2017 05:38:26 -0700 (PDT) X-Envelope-From: phils@in-panik.de X-Envelope-To: 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 v9QCc38n002200 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 26 Oct 2017 14:38:03 +0200 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 1e7hPk-00056x-N9 for quic@ietf.org; Thu, 26 Oct 2017 14:37:36 +0200 From: "Philipp S. Tiesel" Content-Type: multipart/alternative; boundary="Apple-Mail=_1073CDDB-4EF6-452D-AC59-2D5CF31B47BC" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: I-D Action: draft-ietf-quic-manageability-01.txt Date: Thu, 26 Oct 2017 14:38:02 +0200 References: <150891911863.4826.10526078019068901313@ietfa.amsl.com> To: QUIC WG In-Reply-To: <150891911863.4826.10526078019068901313@ietfa.amsl.com> Message-Id: <6D868BC1-8BE5-4CAA-BEFC-79046C887505@in-panik.de> X-Mailer: Apple Mail (2.3445.1.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, 26 Oct 2017 12:38:30 -0000 --Apple-Mail=_1073CDDB-4EF6-452D-AC59-2D5CF31B47BC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 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? AFAIK, the TLS handshake exposes the application protocol and host name = in clear. I am not sure whether it also exposes the initial QUIC connection = parameters in clear. =20 AVE! Philipp S. Tiesel / phils=E2=80=A6 > 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 --Apple-Mail=_1073CDDB-4EF6-452D-AC59-2D5CF31B47BC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 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?
AFAIK, the TLS handshake exposes = the application protocol and host name in clear.
I am not sure = whether it also exposes the initial QUIC connection parameters in = clear.
 
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
=             &n= bsp;           &nbs= p;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-01https://datatracker.ietf.org/doc/html/draft-ietf-quic-manageabi= lity-01

A diff from the previous version is = available at:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-quic-manageabili= ty-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/




= --Apple-Mail=_1073CDDB-4EF6-452D-AC59-2D5CF31B47BC-- From nobody Thu Oct 26 06:36: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 B4BCC13F59D for ; Thu, 26 Oct 2017 06:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, 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 0c77wO46NtYx for ; Thu, 26 Oct 2017 06:36:32 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6CDF13F588 for ; Thu, 26 Oct 2017 06:36:31 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id 31so4258268qtz.9 for ; Thu, 26 Oct 2017 06:36:31 -0700 (PDT) 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=gZbm/nQtRBcU1VYWgk/RJDlm001N+qCluL9vhr+ZH6k=; b=r/s1K6FINfFehhOlhPbD9d/+OHpsW8okLBwNVlmmy7MSA+7dE0knEHV1FE/di+H+NS n5p/oLsaITK5wqnZ/qUs+5pKmK09KsNiWhCCEhZ7tSG3YftkX1JJZpBun4LC8dU3/NS8 QsAgnsxtYpK8DsSw1XyHjJ6C7wofYQlXfmO/F6r63haFlrlIkwV1a2UWkds+w4M/MySm 3/SUxMSe4J0LYbi2MLVm9KMZn1A92CkJ5UufTnZFlABmnZNoQAyWFLHW+bIV8vo5UEUr cBkEBeTAZhY4yxOrl2YzW4gwhxC4sLS9CMc6hGGKbom6Iu0zckXJ+OyoS9KMIMIIJtog VfVw== 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=gZbm/nQtRBcU1VYWgk/RJDlm001N+qCluL9vhr+ZH6k=; b=L9Zqj814nKRAY4jq78izasWMVUz3pJYgvD1u8afUGMLKV/VNwqGGaWAi1G+26zglvr aQGLM8PE4zwomtrANeza9mUSd3OdP0DiyV5pc/Uezqa71gvKhY9VIQJYmjQUaiDrquXd GCsinTeCudSQUeqRk9PZbIlgOO9mZoNX6cM5BGToNnMqZ8vznzf2Zfzok4F7KYXkoHXj ILoc20TsUBt5MIqAtf3aUOPJ0z7HCTT4uxqqJl2cVmVvAEl3i5edf5yufr3E/YrpViq0 b9heD4iYsi5ypBAAmAIGdNvFjmncRjZYLGUSKftyfGEAG71YHb/SlaSknT/TL0hUJ6Ng zRQg== X-Gm-Message-State: AMCzsaX7+hxtLRn8p07x8lOrN9aZKwOFhGN94xF4NR/iBhhkIwue6zZs oD1vzJ6BzXet1Z3Zd7neTBr9UY+C X-Google-Smtp-Source: ABhQp+RqpibXJzECGBM1mUdK8uRoGW+6NmET2PioWvBkF5KKEtcJLImIE95JOCBquXGmMBBcb0Do4w== X-Received: by 10.200.8.74 with SMTP id x10mr35706136qth.31.1509024990782; Thu, 26 Oct 2017 06:36:30 -0700 (PDT) Received: from ubuntu-dmitri (ool-2f1636b6.static.optonline.net. [47.22.54.182]) by smtp.gmail.com with ESMTPSA id c16sm3593783qtd.57.2017.10.26.06.36.30 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 26 Oct 2017 06:36:30 -0700 (PDT) Date: Thu, 26 Oct 2017 09:36:25 -0400 From: Dmitri Tikhonov To: IETF QUIC WG Subject: Re: I-D Action: draft-ietf-quic-applicability-01.txt Message-ID: <20171026133625.GA18560@ubuntu-dmitri> Mail-Followup-To: IETF QUIC WG References: <150891910433.4870.3011696227680449849@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <150891910433.4870.3011696227680449849@ietfa.amsl.com> 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: Thu, 26 Oct 2017 13:36:34 -0000 A comment regarding stream reuse: " Mapping of application data to streams is application-specific and " described for HTTP/s in [QUIC-HTTP]. In general data that can be " processed independently, and therefore would suffer from head of line " blocking, if forced to be received in order, should be transmitted " over different streams. If there is a logical grouping of those data " chunks or messages, stream can be reused, or a new stream can be ^^^^^^^^^^^^^^^^^^^^ " opened for each chunk/message. Compare this with [draft-ietf-quic-transport], which states that a "QUIC endpoint MUST NOT reuse a Stream ID." To avoid any confusion, should this be reworded? Perhaps something like this: If data chunks or messages belong to the same logical group, they can be placed onto the same stream; or a new stream can be opened for each chunk/message. - Dmitri. On Wed, Oct 25, 2017 at 01:11:44AM -0700, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the QUIC WG of the IETF. > > Title : Applicability of the QUIC Transport Protocol > Authors : Mirja Kuehlewind > Brian Trammell > Filename : draft-ietf-quic-applicability-01.txt > Pages : 10 > Date : 2017-10-25 > > Abstract: > This document discusses the applicability of the QUIC transport > protocol, focusing on caveats impacting application protocol > development and deployment over QUIC. Its intended audience is > designers of application protocol mappings to QUIC, and implementors > of these application protocols. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-quic-applicability/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-quic-applicability-01 > https://datatracker.ietf.org/doc/html/draft-ietf-quic-applicability-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-quic-applicability-01 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > From nobody Thu Oct 26 08:47: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 0E388137C2E for ; Thu, 26 Oct 2017 08:47:32 -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 ZudNOONWeMyL for ; Thu, 26 Oct 2017 08:47:29 -0700 (PDT) Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F306138D8F for ; Thu, 26 Oct 2017 08:47:29 -0700 (PDT) Received: by mail-ua0-x22a.google.com with SMTP id b11so2781694uae.12 for ; Thu, 26 Oct 2017 08:47:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bUkm+IdsuIWcYgFd6aktSs02lNOhhf9rt09aQzniw64=; b=daIxUP2QSmiB4ahNIDCkSVC3ij+WpuR/vZdlAhw2P/GYXW0NBgB/JGhh/Dc7kCPDLf Fc88mxkUqSoR87XzC13ZQo0qOV1gp/0of9K1sq9fEAho+5Hxkw4BWcZNp3kvweDv67G8 xc8qvZ+G+relDxQUJgA7OQVEI8a0JJBbUvQercpoR6ixR9CR/BKKp2ZLOIWOMg2UBAaw IQITvwKgNDsPdP2GRF6BE3QJNwykb5t47I3Q4AcUBzahBfRI8RRt3Ar6gHnxkiyNG5pK qe6hBJ9tnLK0LYIBVcvTtq1OnJd+iEKW58kU0v3IqSSzOkCT9GcVObtbLWlpVlPuXPqw dqbw== 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=bUkm+IdsuIWcYgFd6aktSs02lNOhhf9rt09aQzniw64=; b=kJCkDj4Uj6HgtAIMBI85uX8M11T6BHnGxFDDRChhDs0+e4XfmTsHHhDUnWb2/9OGEK uXbgKUidb9bP6pMaqd/G4C9HnGr+wmFN/2hxzXxSNaOFLV7JG8Lcxcm8Aavi09wCZwRk nt9c8FG2s0XU9UIJCEYqnvT0hlmz+3mbT8BGxcFD6fhyao2gFztPXHP2MvB7WYjaM12Z vpu4qOav3OUtdK+kfP59MWcSOszodsUeFZ2/cdVPegYN8hJuB9ESe3+N+P1GHh8beXvv 9ZFcRQ5OYvcmeAjW45GwfvnbSbTgsV7K8+iO4sEU1FQ2KCO6xh6PfEghSXkzIB9hKSCi 7SQQ== X-Gm-Message-State: AMCzsaUzTo4VARZNKhmym77/pc/LvoSOgAKuV/CIRDd2xfFiUhHJLxMS XEx2Q5tPw4Woyq8IKy5h6WmwYDdJIk5H2y2Qb0Xj5A== X-Google-Smtp-Source: ABhQp+RZreS4vipZXs2z1BF/yBAFzy37bmHYEj6I4rGH5qrkemP17xTqcVmXRFNR/UHsQOclaLkpuTNnc6MUhI3Jkg8= X-Received: by 10.176.19.175 with SMTP id m44mr4063077uae.68.1509032848417; Thu, 26 Oct 2017 08:47:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.159.38.130 with HTTP; Thu, 26 Oct 2017 08:47:07 -0700 (PDT) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD82187C@DGGEMM506-MBX.china.huawei.com> References: <150880044283.25241.5162965282478482032.idtracker@ietfa.amsl.com> <6E58094ECC8D8344914996DAD28F1CCD82187C@DGGEMM506-MBX.china.huawei.com> From: Bernard Aboba Date: Thu, 26 Oct 2017 08:47:07 -0700 Message-ID: Subject: Re: New Version Notification for draft-aboba-avtcore-quic-multiplexing-00.txt To: Roni Even Cc: "quic@ietf.org" Content-Type: multipart/alternative; boundary="001a1144168ae26945055c7516ea" 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, 26 Oct 2017 15:47:32 -0000 --001a1144168ae26945055c7516ea Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In the short term, the most likely utilization of QUIC in WebRTC (other than signaling) would be data exchange. In that scenario, RTP/RTCP/STUN/TURN would need to be multiplexed with QUIC, as would DTLS (used for DTLS-SRTP, even if there was no usage of the SCTP data channel). So while RTP over QUIC is certainly possible in the long-term, the multiplexing problem still exists in the short term. On Wed, Oct 25, 2017 at 11:47 PM, Roni Even wrote: > Hi, > > When looking at the problem in the WEBRTC contents I am wondering if we > cannot address it without multiplexing. > > The use case is when bundling the RTP media streams with the Data channel= . > > 1. If we bundle RTP over QUIC and Data channel over QUIC using the > same QUIC connection there is no problem. > > 2. If we use RTP over QUIC is there any reason to run the data > channel over UDP/DTLS/SCTP? If yes we need to address it also in the > Heuristic option > > 3. If we use RTP over UDP/DTLS and the Data channel over QUIC it is > discussed in the Heuristic section but it seems like the recommendation > there is for WEBRTC to mandate that the Data channel in this case will u= se > UDP/DTLS/SCTP . I think that UDP/DTLS/SCTP provides similar functionality > to QUIC > > > > I think that this document is still needed for a general case when we > bundle RTP with QUIC not for the WEBRTC case but still wonder if when RTP > is over UDP/DTLS why use QUIC for a bundled non RTP data and not leverage > the UDP/DTLS connection or why not run RTP over QUIC in this case. > > > > Roni Even > > > > *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Bernard Aboba > *Sent:* =D7=99=D7=95=D7=9D =D7=94 26 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91= =D7=A8 2017 05:19 > *To:* quic@ietf.org > *Subject:* Fwd: New Version Notification for draft-aboba-avtcore-quic- > multiplexing-00.txt > > > > > A new version of I-D, draft-aboba-avtcore-quic-multiplexing-00.txt > has been successfully submitted by and posted to the IETF > repository. > > Name: draft-aboba-avtcore-quic-multiplexing > Revision: 00 > Title: QUIC Multiplexing > Document date: 2017-10-23 > Group: Individual Submission > Pages: 9 > URL: https://www.ietf.org/internet-drafts/draft-aboba-avtcore- > quic-multiplexing-00.txt > Status: https://datatracker.ietf.org/doc/draft-aboba-avtcore-quic= - > multiplexing/ > Htmlized: https://tools.ietf.org/html/draft-aboba-avtcore-quic- > multiplexing-00 > Htmlized: https://datatracker.ietf.org/doc/html/draft-aboba-avtcore= - > quic-multiplexing-00 > > > Abstract: > This document describes potential approaches to multiplexing of QUIC > along with RTP, RTCP, DTLS, STUN, TURN and ZRTP in WebRTC peer-to- > peer data exchange. > > > --001a1144168ae26945055c7516ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
In the short term, the most likely utilization of QUIC in = WebRTC (other than signaling) would be data exchange.=C2=A0 In that scenari= o, RTP/RTCP/STUN/TURN would need to be multiplexed with QUIC, as would DTLS= (used for DTLS-SRTP, even if there was no usage of the SCTP data channel).= =C2=A0

So while RTP over QUIC is certainly possible in t= he long-term, the multiplexing problem still exists in the short term.

On Wed, Oc= t 25, 2017 at 11:47 PM, Roni Even <roni.even@huawei.com> = wrote:

Hi,<= /p>

When looking at the probl= em in the WEBRTC contents I am wondering if we cannot address it without mu= ltiplexing.

The use case is when bund= ling the RTP media streams with the Data channel.

1.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If we bundle RTP over QUIC and Data channel over QUIC using the same Q= UIC connection there is no problem.

2.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If we use RTP over QUIC is there any reason to run the data channel ov= er UDP/DTLS/SCTP? If yes we need to address it also in the Heuristic option

3.= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 If we use RTP over UDP/DTLS and the Data channel over QUIC it is discu= ssed in the Heuristic section but it seems like the recommendation there is=C2=A0 for WEBRTC to mandate that the Data channel in this case wi= ll use UDP/DTLS/SCTP . I think that UDP/DTLS/SCTP provides similar function= ality to QUIC

=C2=A0

I think that this documen= t is still needed for a general case when we bundle RTP with QUIC not for t= he WEBRTC case but still wonder if when RTP is over UDP/DTLS why use QUIC for a bundled non RTP data and not leverage the UDP/DTLS conn= ection or why not run RTP over QUIC in this case.

=C2=A0

Roni Even

=C2=A0

From: QUIC [ma= ilto:quic-bounce= s@ietf.org] On Behalf Of Bernard Aboba
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=94 2= 6 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91=D7=A8 2017 05:19
To: quic@ietf.org=
Subject: Fwd: New Version Notification for draft-aboba-avtcore-quic-= multiplexing-00.txt

=C2=A0


A new version of I-D, draft-aboba-avtcore-quic-multiplexing-00.txt
has been successfully submitted by and posted to the IETF
repository.

Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-aboba-avtcore-quic-multiplexing
Revision:=C2=A0 =C2=A0 =C2=A0 =C2=A000
Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 QUIC Multiplexing
Document date:=C2=A0 2017-10-23
Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individual Submission
Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 9
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-aboba-avtcore-quic-mul= tiplexing-00.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https:/= /datatracker.ietf.org/doc/draft-aboba-avtcore-quic-multiplexing/<= /a>
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.i= etf.org/html/draft-aboba-avtcore-quic-multiplexing-00
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https= ://datatracker.ietf.org/doc/html/draft-aboba-avtcore-quic-multipl= exing-00


Abstract:
=C2=A0 =C2=A0This document describes potential approaches to multiplexing o= f QUIC
=C2=A0 =C2=A0along with RTP, RTCP, DTLS, STUN, TURN and ZRTP in WebRTC peer= -to-
=C2=A0 =C2=A0peer data exchange.

=C2=A0


--001a1144168ae26945055c7516ea-- From nobody Thu Oct 26 12:42: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 7659213F5F2 for ; Thu, 26 Oct 2017 12:42:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.71 X-Spam-Level: X-Spam-Status: No, score=-0.71 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, 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 j7A9cazcNEwU for ; Thu, 26 Oct 2017 12:42:09 -0700 (PDT) Received: from mail-yw0-x244.google.com (mail-yw0-x244.google.com [IPv6:2607:f8b0:4002:c05::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 3454613F43D for ; Thu, 26 Oct 2017 12:42:09 -0700 (PDT) Received: by mail-yw0-x244.google.com with SMTP id w5so3892149ywg.11 for ; Thu, 26 Oct 2017 12:42:09 -0700 (PDT) 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=e/o+59uqXyAS0qvbU54ambC8PhWaDRVB30lH4Y541Cg=; b=ltoDBWf47KMxqJuj8mA/B0ZExt1WLmvZZ8ZDVm0n/UUx8tiettShe0CcWkKwPtjK2e xn86F+/Yi+GTmC1uaoxRVABztmRbTJOYfOdDf2jbIgJGbuXemOBl33iAt/O7fXq01+Ud UXNrV4iulAI8NEcYh0mV/IeVd4B1pRdkrONsJk74ZFkj6o5StUWAGHUkxypJt8q0VuD7 bfq5JQzJ2d0S/XP5OVSue0h3U4WvH3KzUuh7mPGw980d2JLVgDGou9eKFJoey03wTB+u wj5pCIFt6KG6kKmbD7iWmZaVpvJjQMwLv05yqUWs1pYZUnI44dQGuL208aD3rtKfcvny +r0Q== 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=e/o+59uqXyAS0qvbU54ambC8PhWaDRVB30lH4Y541Cg=; b=aOOr/nXPwSSSLyRAeueY1PBhhDf1Ni7cId8+TTdGYSWmIcryL/2agYe2r8iD/GwYvr IztSEaIT+MPd5GGxIgzxgNP9hp2nUiZ9ufsfSfEemDmIhTFuJv3gHx/ciHXPnT+j4Xm3 AsBcCDH+YP4qVD7+F9AmfAXtqHNLRZqmUK7KuLu/dOcTHl5xhsC3rZsGQdBhRcg057Ep woUR2wuZFU6YWSLuejJh29WcXTZ6KzTP9J5ghvDKeymYgcLhALCxUVLOi/sbfTnULiwz R6pM6YL7awUUg/ooGHfhAt7gIrUWEzwuYC6F/aXlaIKMecewA1YaotH0gDiy9N6jJj8C 8Prg== X-Gm-Message-State: AMCzsaWHncG+fNk86jFxbi+xzbwo56RRzB0pyFrAPKCjR4sn6KEq0794 yOJDTqDqRFp4zqVZ4jd41jQi/qlgBRRvUEfT4lBWPg== X-Google-Smtp-Source: ABhQp+Qs8n+ShcaAWc54yLolFFD4/XT0swiZVTtpVCvR8zTHnMCTfdZOAxP8Y/IcXARjIawAhQ2HYIBEA44UB2ILQeg= X-Received: by 10.129.226.6 with SMTP id p6mr10824914ywl.72.1509046927900; Thu, 26 Oct 2017 12:42:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.70.5 with HTTP; Thu, 26 Oct 2017 12:42:06 -0700 (PDT) In-Reply-To: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> From: Jana Iyengar Date: Thu, 26 Oct 2017 15:42:06 -0400 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: Praveen Balasubramanian Cc: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Martin Thomson , Mike Bishop , Ian Swett , "quic@ietf.org" , Hugues Fafard , Roberto Peon Content-Type: multipart/alternative; boundary="f403043eca7817257d055c785e47" 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, 26 Oct 2017 19:42:13 -0000 --f403043eca7817257d055c785e47 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I'd like to merge #872 . If I don't hear any serious issues I'll merge it tomorrow. On Mon, Oct 16, 2017 at 11:56 PM, Jana Iyengar wrote: > On Mon, Oct 16, 2017 at 6:41 PM, Praveen Balasubramanian < > pravb@microsoft.com> wrote: > >> I agree that this is adding complexity with four special cases, but I >> would actually argue the other way: apps that want uni streams should be >> able to use the existing bidi stream mechanism. An API for uni stream ca= n >> achieve this by closing the stream in one direction immediately after >> opening it so that the very first packet for that stream signals that on= e >> direction is closed and the other end knows that the stream is uni. Bidi >> streams are a more general case and if we are going to support them (whi= ch >> I think we should) then do we need any dedicated transport mechanisms fo= r >> uni streams? >> > > There's not a lot of dedicated mechanisms; indeed you can implement uni a= s > a special case of bidi streams. The issue was, as Ian summarized nicely > here, that implicitly open streams became ambiguous. For instance if stre= am > 15 was opened after stream 11, the spec requires stream 13 to be opened > implicitly, but should it be opened as a uni stream or a bidi one? > Separating namespaces for uni/bidi means that only streams in that > particular namespace are opened implicitly. > > > >> >> >> Thanks >> >> >> >> *From:* QUIC [mailto:quic-bounces@ietf.org] *On Behalf Of *Mikkel Fahn= =C3=B8e >> J=C3=B8rgensen >> *Sent:* Monday, October 16, 2017 6:20 PM >> *To:* Martin Thomson ; Jana Iyengar < >> jri@google.com> >> *Cc:* Mike Bishop ; Ian Swett < >> ianswett@google.com>; quic@ietf.org; Hugues Fafard ; >> Roberto Peon >> >> *Subject:* Re: Identify streams unidirectional vs bidirectional based on >> stream ID >> >> >> >> I=E2=80=99m just wondering why this approach was preferred as opposed to= building >> bidi on top of uni. I suppose this must have been discussed at the inter= im >> and in part based on the recent experimental implementation of uni strea= ms. >> >> >> >> A straightforward implementation may not have much difficulty in handlin= g >> the implementation either way but when you attempt to achieve low latenc= y >> and low memory foot print with shortest possible state life times includ= ing >> coordination with application level buffers, then bidi streams are not v= ery >> fun to work with at the transport level. As become more agreeable after = it >> was concluded that teardown did not have to wait for FIN ACK and related= , >> but it is still a lot of complexity with potential bugs. >> >> >> >> One aspect of the complexity is that there are now four special cases >> instead of two in the stream identifiers which must be dealt with in >> several frame types. Some of this involves flow control per stream type >> which bidi on top of uni would not support at the same granularity, but = is >> this really needed? >> >> >> >> Adding uni streams in addition to bidi streams is still a lot better tha= n >> not having uni streams because they solve problems such as async messagi= ng >> at high volume and partial reliability via throw away streams. However, >> they do nothing to simplify the transport with the current proposal. >> >> >> >> Kind Regards, >> >> Mikkel Fahn=C3=B8e J=C3=B8rgensen >> >> >> >> On 17 October 2017 at 02.49.38, Martin Thomson (martin.thomson@gmail.com= ) >> wrote: >> >> Those low order bits are important. No need to rush (it's a >> relatively small changeset). >> >> On Tue, Oct 17, 2017 at 10:48 AM, Jana Iyengar wrote: >> > Based on what I'm seeing on the PR and on this thread, I think there's >> > general agreement on this strategy to go forward. I would like to merg= e >> this >> > PR soon, modulo a new revision to address some open comments. (There's >> > currently a question about whether to use the high or the low-order >> bits for >> > this, which should also get resolved before merging.) >> > >> > I'm asking folks to please review and speak up if they have >> disagreements >> > with the direction or with any specifics. >> > >> > I'll be away from connectivity for a week, so unless there are >> unresolved >> > issues then, I'd like to merge this in a week when I return. Martin ca= n >> > merge this sooner if there's only agreement. >> > >> > On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett >> wrote: >> >> >> >> I believe the motivation for separate stream limits is to put a >> reasonable >> >> limit on the number of incoming streams you'll accept. Otherwise, an >> >> application could use a very large number of one type(ie: uni) of >> stream and >> >> almost none of another(ie: bidi), which would allow them to suddenly >> open a >> >> huge number of the other type(ie: bidi) of stream if they wanted. >> >> >> >> If we were using H2 style max open streams we could do it either way, >> but >> >> I think keeping them separate is probably best anyway. >> >> >> >> On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon wrote: >> >>> >> >>> In H2, the even/odd thing was just an easy way to encode a unique ID >> per >> >>> stream while indicating direction. >> >>> This proposal seems to do the same thing, and that makes sense to >> >>> me=E2=80=94instead of even-odd, we have mod-4-offset. >> >>> >> >>> I=E2=80=99d ask why bother to have separate stream limits. You could= still >> just >> >>> have the one limit for the overall space. >> >>> With H2, that was part of the point of putting it there (though it >> was >> >>> implit)=E2=80=94it was all part of one space, and thus the space was= singly >> >>> countable! >> >>> >> >>> >> >>> >> >>> -=3DR >> >>> >> >>> >> >>> >> >>> From: QUIC on behalf of Ian Swett >> >>> >> >>> Date: Friday, October 13, 2017 at 2:05 PM >> >>> To: Mike Bishop >> >>> Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen , "quic@ie= tf.org" >> >>> , Hugues Fafard >> >>> >> >>> >> >>> Subject: Re: Identify streams unidirectional vs bidirectional based >> on >> >>> stream ID >> >>> >> >>> >> >>> >> >>> In many ways, they are 4 independent spaces, but Ryan pointed out to >> me >> >>> that both for the purposes of draft text and implementation it's ver= y >> useful >> >>> to have a single unique identifier for a stream, since otherwise you >> have to >> >>> talk about/pass around (StreamID, Type) everywhere instead of just >> StreamID. >> >>> >> >>> >> >>> >> >>> Keeping one stream ID avoids creating two of all the stream specific >> >>> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET, etc)= , >> one >> >>> for each stream space. >> >>> >> >>> >> >>> >> >>> Using the two most significant bits would eliminate the usefulness o= f >> any >> >>> variable length integer encoding(current or Martin's new proposal), >> so using >> >>> the lower bits makes sense. >> >>> >> >>> >> >>> >> >>> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop >> >>> wrote: >> >>> >> >>> Indeed. I almost think it makes more sense to say that there are fou= r >> >>> independent stream spaces, each with their own numbers. That does >> mean that >> >>> each side will need to separately manage Max Stream ID for two >> spaces, but >> >>> that seems more reasonable than the alternative. In fact, this PR >> already >> >>> implies that the limits for unidirectional and bidirectional streams >> are >> >>> handled separately, which gets really weird when the IDs are >> interleaved >> >>> with each other. >> >>> >> >>> >> >>> >> >>> In fact, this plays well with the variable-length encoding idea, >> since >> >>> the maximum size of a Stream ID would be 62 bits. They could then be >> stored >> >>> locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits indi= cating which >> space they >> >>> refer to. >> >>> >> >>> >> >>> >> >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn= =C3=B8e >> >>> J=C3=B8rgensen >> >>> Sent: Friday, October 13, 2017 1:04 PM >> >>> To: quic@ietf.org; Hugues Fafard >> >>> Subject: Re: Identify streams unidirectional vs bidirectional based >> on >> >>> stream ID >> >>> >> >>> >> >>> >> >>> Especially with the new variable length encoding proposal, storing >> the >> >>> identifiers early makes sense, as you only have to inspect the first >> byte. >> >>> But it gets complicated, because you don=E2=80=99t want to use 8 byt= es for >> some >> >>> stream types and you don=E2=80=99t want the bits at some random loca= tion in a >> >>> decoded 8 byte representation either. >> >>> >> >>> >> >>> >> >>> Regardless of bit placement, encoding state using bits is not ideal >> when >> >>> considering variable length encoding because you now use two bits fo= r >> length >> >>> and two bits for stream type, leaving only 16 different streams >> before the >> >>> stream identifier needs to use two bytes, and so forth. >> >>> >> >>> >> >>> >> >>> >> >>> >> >>> Kind Regards, >> >>> >> >>> Mikkel Fahn=C3=B8e J=C3=B8rgensen >> >>> >> >>> >> >>> >> >>> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) >> wrote: >> >>> >> >>> I see, you used the 2 least significant bits to encode that >> >>> information. When only using one bit to indicate the direction, it >> >>> boiled down to odd/even which more or less made sense, but when usin= g >> >>> 2 bits that breaks apart. >> >>> >> >>> Why not use the most significant bits instead? That way, getting the >> >>> 'clean' stream ID without the flags would be as simple doing a `& >> >>> 0x3F...FF` instead of bit-shifting things around. Similarly, encodin= g >> >>> the stream ID would just entail `| 0x?0...00` to set the appropriate >> >>> bits and also avoid bit-shifts. >> >>> >> >>> Regards, >> >>> Hugues >> >>> >> >>> On 2017-10-13 20:51, Ryan Hamilton wrote: >> >>> > As I understand the discussions at the interim, we've decided to >> >>> > allow streams to be unidirectional or bidirectional. I support thi= s >> >>> > idea and was motivated to write up an idea I've been thinking abou= t >> >>> > for a while. In the same way that we use a bit in the stream ID to >> >>> > identify the client vs server nature of the stream, we can use a >> >>> > bit to identify the directionality. This divides the stream ID >> >>> > space neatly into 4 distinct spaces (much like the 2 two we have >> >>> > today: client/server). In addition this means that a stream ID >> >>> > always uniquely identifies a single stream, and frames which >> >>> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, >> >>> > RST_STREAM, etc) do not need to explicitly convey the >> >>> > directionality as fields in those frames (or implicitly based on >> >>> > the directionality of the frames themselves). >> >>> > >> >>> > https://github.com/quicwg/base-drafts/pull/872 >> >> >>> > >> >>> > Cheers, >> >>> > >> >>> > Ryan >> >>> >> >>> >> >> >> >> >> > >> >> > --f403043eca7817257d055c785e47 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I'd like to merge #872. If I don't hear any serious issues I&#= 39;ll merge it tomorrow.

On Mon, Oct 16, 2017 at 11:56 PM, Jana Iyengar <jri@google.com> wrote:
On Mon,= Oct 16, 2017 at 6:41 PM, Praveen Balasubramanian <pravb@microsoft.com> wrote:

I agree that this is adding complexity with four spe= cial cases, but I would actually argue the other way: apps that want uni st= reams should be able to use the existing bidi stream mechanism. An API for = uni stream can achieve this by closing the stream in one direction immediately after opening it so that the very = first packet for that stream signals that one direction is closed and the o= ther end knows that the stream is uni. Bidi streams are a more general case= and if we are going to support them (which I think we should) then do we need any dedicated transport mec= hanisms for uni streams?


=
There's not a lot of dedicated mechanisms; indeed you can implemen= t uni as a special case of bidi streams. The issue was, as Ian summarized n= icely here, that implicitly open streams became ambiguous. For instance if = stream 15 was opened after stream 11,=C2=A0 the spec requires stream 13 to = be opened implicitly, but should it be opened as a uni stream or a bidi one= ? Separating namespaces for uni/bidi means that only streams in that partic= ular namespace are opened implicitly.

=
=C2=A0

=C2=A0

Thanks

=C2=A0

=C2=A0

I=E2=80=99m just wondering why this approach was = preferred as opposed to building bidi on top of uni. I suppose this must ha= ve been discussed at the interim and in part based on the recent experimental implementation of uni streams.

=C2=A0

A straightforward implementation may not have muc= h difficulty in handling the implementation either way but when you attempt= to achieve low latency and low memory foot print with shortest possible state life times including coordination with applic= ation level buffers, then bidi streams are not very fun to work with at the= transport level. As become more agreeable after it was concluded that tear= down did not have to wait for FIN ACK and related, but it is still a lot of complexity with potential bugs.<= u>

=C2=A0

One aspect of the complexity is that there are no= w four special cases instead of two in the stream identifiers which must be= dealt with in several frame types. Some of this involves flow control per stream type which bidi on top of uni would not s= upport at the same granularity, but is this really needed?

=C2=A0

Adding uni streams in addition to bidi streams is= still a lot better than not having uni streams because they solve problems= such as async messaging at high volume and partial reliability via throw away streams. However, they do nothing to simplify t= he transport with the current proposal.

=C2=A0

Kind Regards,

Mikkel Fahn=C3=B8e= J=C3=B8rgensen

=C2=A0

On 17 = October 2017 at 02.49.38, Martin Thomson (martin.thomson@gmail.com<= span style=3D"font-size:10.0pt;font-family:"Helvetica",sans-serif= ">) wrote:

Those low order bits are important. No need to ru= sh (it's a
relatively small changeset).

On Tue, Oct 17, 2017 at 10:48 AM, Jana Iyengar <jri@google.com> wro= te:
> Based on what I'm seeing on the PR and on this thread, I think the= re's
> general agreement on this strategy to go forward. I would like to merg= e this
> PR soon, modulo a new revision to address some open comments. (There&#= 39;s
> currently a question about whether to use the high or the low-order bi= ts for
> this, which should also get resolved before merging.)
>
> I'm asking folks to please review and speak up if they have disagr= eements
> with the direction or with any specifics.
>
> I'll be away from connectivity for a week, so unless there are unr= esolved
> issues then, I'd like to merge this in a week when I return. Marti= n can
> merge this sooner if there's only agreement.
>
> On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett <ianswett@google.com<= span style=3D"font-size:10.0pt;font-family:"Helvetica",sans-serif= ">> wrote:
>>
>> I believe the motivation for separate stream limits is to put a re= asonable
>> limit on the number of incoming streams you'll accept. Otherwi= se, an
>> application could use a very large number of one type(ie: uni) of = stream and
>> almost none of another(ie: bidi), which would allow them to sudden= ly open a
>> huge number of the other type(ie: bidi) of stream if they wanted. =
>>
>> If we were using H2 style max open streams we could do it either w= ay, but
>> I think keeping them separate is probably best anyway.
>>
>> On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon <fenix@fb.com>= ; wrote:
>>>
>>> In H2, the even/odd thing was just an easy way to encode a uni= que ID per
>>> stream while indicating direction.
>>> This proposal seems to do the same thing, and that makes sense= to
>>> me=E2=80=94instead of even-odd, we have mod-4-offset.
>>>
>>> I=E2=80=99d ask why bother to have separate stream limits. You= could still just
>>> have the one limit for the overall space.
>>> With H2, that was part of the point of putting it there (thoug= h it was
>>> implit)=E2=80=94it was all part of one space, and thus the spa= ce was singly
>>> countable!
>>>
>>>
>>>
>>> -=3DR
>>>
>>>
>>>
>>> From: QUIC <quic-bounces@ietf.org> on behalf of = Ian Swett
>>> <ianswett@google.com>
>>> Date: Friday, October 13, 2017 at 2:05 PM
>>> To: Mike Bishop <Michael.Bishop@microsoft.com>
>>> Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen <mikkelfj@gmail.com= >, "quic@ietf.org"
>>> <= quic@ietf.org>, Hugues Fafard <fafard@in.tum.de&g= t;
>>>
>>>
>>> Subject: Re: Identify streams unidirectional vs bidirectional = based on
>>> stream ID
>>>
>>>
>>>
>>> In many ways, they are 4 independent spaces, but Ryan pointed = out to me
>>> that both for the purposes of draft text and implementation it= 's very useful
>>> to have a single unique identifier for a stream, since otherwi= se you have to
>>> talk about/pass around (StreamID, Type) everywhere instead of = just StreamID.
>>>
>>>
>>>
>>> Keeping one stream ID avoids creating two of all the stream sp= ecific
>>> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET= , etc), one
>>> for each stream space.
>>>
>>>
>>>
>>> Using the two most significant bits would eliminate the useful= ness of any
>>> variable length integer encoding(current or Martin's new p= roposal), so using
>>> the lower bits makes sense.
>>>
>>>
>>>
>>> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop
>>> <Michael.Bishop@microsoft.com> wrote:
>>>
>>> Indeed. I almost think it makes more sense to say that there a= re four
>>> independent stream spaces, each with their own numbers. That d= oes mean that
>>> each side will need to separately manage Max Stream ID for two= spaces, but
>>> that seems more reasonable than the alternative. In fact, this= PR already
>>> implies that the limits for unidirectional and bidirectional s= treams are
>>> handled separately, which gets really weird when the IDs are i= nterleaved
>>> with each other.
>>>
>>>
>>>
>>> In fact, this plays well with the variable-length encoding ide= a, since
>>> the maximum size of a Stream ID would be 62 bits. They could t= hen be stored
>>> locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bit= s indicating which space they
>>> refer to.
>>>
>>>
>>>
>>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of= Mikkel Fahn=C3=B8e
>>> J=C3=B8rgensen
>>> Sent: Friday, October 13, 2017 1:04 PM
>>> To: = quic@ietf.org; Hugues Fafard <fafard@in.tum.de>
>>> Subject: Re: Identify streams unidirectional vs bidirectional = based on
>>> stream ID
>>>
>>>
>>>
>>> Especially with the new variable length encoding proposal, sto= ring the
>>> identifiers early makes sense, as you only have to inspect the= first byte.
>>> But it gets complicated, because you don=E2=80=99t want to use= 8 bytes for some
>>> stream types and you don=E2=80=99t want the bits at some rando= m location in a
>>> decoded 8 byte representation either.
>>>
>>>
>>>
>>> Regardless of bit placement, encoding state using bits is not = ideal when
>>> considering variable length encoding because you now use two b= its for length
>>> and two bits for stream type, leaving only 16 different stream= s before the
>>> stream identifier needs to use two bytes, and so forth.
>>>
>>>
>>>
>>>
>>>
>>> Kind Regards,
>>>
>>> Mikkel Fahn=C3=B8e J=C3=B8rgensen
>>>
>>>
>>>
>>> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) wrote:
>>>
>>> I see, you used the 2 least significant bits to encode that >>> information. When only using one bit to indicate the direction= , it
>>> boiled down to odd/even which more or less made sense, but whe= n using
>>> 2 bits that breaks apart.
>>>
>>> Why not use the most significant bits instead? That way, getti= ng the
>>> 'clean' stream ID without the flags would be as simple= doing a `&
>>> 0x3F...FF` instead of bit-shifting things around. Similarly, e= ncoding
>>> the stream ID would just entail `| 0x?0...00` to set the appro= priate
>>> bits and also avoid bit-shifts.
>>>
>>> Regards,
>>> Hugues
>>>
>>> On 2017-10-13 20:51, Ryan Hamilton wrote:
>>> > As I understand the discussions at the interim, we've= decided to
>>> > allow streams to be unidirectional or bidirectional. I su= pport this
>>> > idea and was motivated to write up an idea I've been = thinking about
>>> > for a while. In the same way that we use a bit in the str= eam ID to
>>> > identify the client vs server nature of the stream, we ca= n use a
>>> > bit to identify the directionality. This divides the stre= am ID
>>> > space neatly into 4 distinct spaces (much like the 2 two = we have
>>> > today: client/server). In addition this means that a stre= am ID
>>> > always uniquely identifies a single stream, and frames wh= ich
>>> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA= ,
>>> > RST_STREAM, etc) do not need to explicitly convey the >>> > directionality as fields in those frames (or implicitly b= ased on
>>> > the directionality of the frames themselves).
>>> >
>>> > https://github.com/quicwg/base-drafts/pull/872
>>> >
>>> > Cheers,
>>> >
>>> > Ryan
>>>
>>>
>>
>>
>



--f403043eca7817257d055c785e47-- From nobody Thu Oct 26 21:55: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 B1BF11389BC for ; Thu, 26 Oct 2017 21:55:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_mGR55BwCmZ for ; Thu, 26 Oct 2017 21:55:24 -0700 (PDT) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16559137C4A for ; Thu, 26 Oct 2017 21:55:24 -0700 (PDT) Received: by mail-oi0-x22a.google.com with SMTP id j126so9180070oib.8 for ; Thu, 26 Oct 2017 21:55:23 -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:content-transfer-encoding; bh=lEi5rwlpWzSftjzg43h0pEuexBB1KPxYR4FqkVJt7og=; b=k8xSrOjk/6JwwI2NtBpsdyY0fauaqwyDFafH7GG7OW5SGTLXbtntdVvjkXiCBZ3V0s uSQLlgcAVMcOndEeH8/G242cprc1fWBn66a1GOC77cRNz4oSApzhGv0zAnikeKUyb/CS 6LumdFgbChrOxSJ4Q/EB0i1Hqm7AYIsy8B62hgrNUxhPSkPr5f5Qa90zYPJXXtEfghFe 8l0+u/z/UmjDjO2tYIbIX4WmOpD9yUQC6d8OZhDhXPV1W9OlW89UAq0o7iCLNQ3d0FQ6 9KW5GlwiAPqSr/mseKKzku7i9z7+cLnfYXlqythXFjzfmMBP4PbO7I62zFlwLyQHPH4e dASA== 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=lEi5rwlpWzSftjzg43h0pEuexBB1KPxYR4FqkVJt7og=; b=bQDVTQteGtDOrFvcZlOSPPNXqoxmkOtbkvso7s2qMupAfidloihNVTgRIQpuzC9uHi WY+RbG4dEcU407ZVSwZEeLx2bCUA/SAjG8CBIqltRwOGE0BICReWK/2p90KyJ4yR18+x rvROp7yxOKwfMCt5e5gLeA6aqlypcn/qGWDB8Y1Dfpv8YAlkBo2ZHp4Z6bSo+eJJme3D xD96JGGqXXVgugleO3LSpu9kZmzPfNys6AnFjSfIaiXzTa1CLTF76eEDkNP+oBcLQgea 4NcHDaIYPpIXenNpLeST+zu6DavnflE2Ulp40B73ooXSvfK3ic+hnAcBhjgKnoVo7wyp KHQQ== X-Gm-Message-State: AMCzsaUStj+pbgIMYt6/UJ6RbDzVNoIuh662l3yAEl936NMILlxSWDlg Epo7cTiZwFjfzWBwoy6MH5RuYwCsbPHxEWBD1Jl9ag== X-Google-Smtp-Source: ABhQp+QhdT59mSe7daC+iYE2E+ZwattYpi2NYI6pnvbe603s/h1PkAiu4x55AAC1kI+8LW4c7yrlZN/bKfKJuLenVi8= X-Received: by 10.157.53.17 with SMTP id o17mr2566856otc.35.1509080123209; Thu, 26 Oct 2017 21:55:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.72.178 with HTTP; Thu, 26 Oct 2017 21:55:22 -0700 (PDT) In-Reply-To: References: <0ffd80fd-d6a9-5df4-2128-d304b65dedf4@in.tum.de> From: Martin Thomson Date: Fri, 27 Oct 2017 15:55:22 +1100 Message-ID: Subject: Re: Identify streams unidirectional vs bidirectional based on stream ID To: Jana Iyengar Cc: Praveen Balasubramanian , =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= , Mike Bishop , Ian Swett , "quic@ietf.org" , Hugues Fafard , Roberto Peon 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: Fri, 27 Oct 2017 04:55:27 -0000 Please note that #885 is the same patch with additional changes. #872 has bugs with stream identifiers that #885 corrects. (#885 also says what a unidirectional and bidirectional stream is more clearly.) On Fri, Oct 27, 2017 at 6:42 AM, Jana Iyengar wrote: > I'd like to merge #872. If I don't hear any serious issues I'll merge it > tomorrow. > > On Mon, Oct 16, 2017 at 11:56 PM, Jana Iyengar wrote: >> >> On Mon, Oct 16, 2017 at 6:41 PM, Praveen Balasubramanian >> wrote: >>> >>> I agree that this is adding complexity with four special cases, but I >>> would actually argue the other way: apps that want uni streams should b= e >>> able to use the existing bidi stream mechanism. An API for uni stream c= an >>> achieve this by closing the stream in one direction immediately after >>> opening it so that the very first packet for that stream signals that o= ne >>> direction is closed and the other end knows that the stream is uni. Bid= i >>> streams are a more general case and if we are going to support them (wh= ich I >>> think we should) then do we need any dedicated transport mechanisms for= uni >>> streams? >> >> >> There's not a lot of dedicated mechanisms; indeed you can implement uni = as >> a special case of bidi streams. The issue was, as Ian summarized nicely >> here, that implicitly open streams became ambiguous. For instance if str= eam >> 15 was opened after stream 11, the spec requires stream 13 to be opened >> implicitly, but should it be opened as a uni stream or a bidi one? >> Separating namespaces for uni/bidi means that only streams in that >> particular namespace are opened implicitly. >> >> >>> >>> >>> >>> Thanks >>> >>> >>> >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn=C3= =B8e >>> J=C3=B8rgensen >>> Sent: Monday, October 16, 2017 6:20 PM >>> To: Martin Thomson ; Jana Iyengar >>> >>> Cc: Mike Bishop ; Ian Swett >>> ; quic@ietf.org; Hugues Fafard ; >>> Roberto Peon >>> >>> >>> Subject: Re: Identify streams unidirectional vs bidirectional based on >>> stream ID >>> >>> >>> >>> I=E2=80=99m just wondering why this approach was preferred as opposed t= o building >>> bidi on top of uni. I suppose this must have been discussed at the inte= rim >>> and in part based on the recent experimental implementation of uni stre= ams. >>> >>> >>> >>> A straightforward implementation may not have much difficulty in handli= ng >>> the implementation either way but when you attempt to achieve low laten= cy >>> and low memory foot print with shortest possible state life times inclu= ding >>> coordination with application level buffers, then bidi streams are not = very >>> fun to work with at the transport level. As become more agreeable after= it >>> was concluded that teardown did not have to wait for FIN ACK and relate= d, >>> but it is still a lot of complexity with potential bugs. >>> >>> >>> >>> One aspect of the complexity is that there are now four special cases >>> instead of two in the stream identifiers which must be dealt with in se= veral >>> frame types. Some of this involves flow control per stream type which b= idi >>> on top of uni would not support at the same granularity, but is this re= ally >>> needed? >>> >>> >>> >>> Adding uni streams in addition to bidi streams is still a lot better th= an >>> not having uni streams because they solve problems such as async messag= ing >>> at high volume and partial reliability via throw away streams. However,= they >>> do nothing to simplify the transport with the current proposal. >>> >>> >>> >>> Kind Regards, >>> >>> Mikkel Fahn=C3=B8e J=C3=B8rgensen >>> >>> >>> >>> On 17 October 2017 at 02.49.38, Martin Thomson (martin.thomson@gmail.co= m) >>> wrote: >>> >>> Those low order bits are important. No need to rush (it's a >>> relatively small changeset). >>> >>> On Tue, Oct 17, 2017 at 10:48 AM, Jana Iyengar wrote: >>> > Based on what I'm seeing on the PR and on this thread, I think there'= s >>> > general agreement on this strategy to go forward. I would like to mer= ge >>> > this >>> > PR soon, modulo a new revision to address some open comments. (There'= s >>> > currently a question about whether to use the high or the low-order >>> > bits for >>> > this, which should also get resolved before merging.) >>> > >>> > I'm asking folks to please review and speak up if they have >>> > disagreements >>> > with the direction or with any specifics. >>> > >>> > I'll be away from connectivity for a week, so unless there are >>> > unresolved >>> > issues then, I'd like to merge this in a week when I return. Martin c= an >>> > merge this sooner if there's only agreement. >>> > >>> > On Mon, Oct 16, 2017 at 8:15 AM, Ian Swett wrot= e: >>> >> >>> >> I believe the motivation for separate stream limits is to put a >>> >> reasonable >>> >> limit on the number of incoming streams you'll accept. Otherwise, an >>> >> application could use a very large number of one type(ie: uni) of >>> >> stream and >>> >> almost none of another(ie: bidi), which would allow them to suddenly >>> >> open a >>> >> huge number of the other type(ie: bidi) of stream if they wanted. >>> >> >>> >> If we were using H2 style max open streams we could do it either way= , >>> >> but >>> >> I think keeping them separate is probably best anyway. >>> >> >>> >> On Mon, Oct 16, 2017 at 11:01 AM, Roberto Peon wrote: >>> >>> >>> >>> In H2, the even/odd thing was just an easy way to encode a unique I= D >>> >>> per >>> >>> stream while indicating direction. >>> >>> This proposal seems to do the same thing, and that makes sense to >>> >>> me=E2=80=94instead of even-odd, we have mod-4-offset. >>> >>> >>> >>> I=E2=80=99d ask why bother to have separate stream limits. You coul= d still >>> >>> just >>> >>> have the one limit for the overall space. >>> >>> With H2, that was part of the point of putting it there (though it >>> >>> was >>> >>> implit)=E2=80=94it was all part of one space, and thus the space wa= s singly >>> >>> countable! >>> >>> >>> >>> >>> >>> >>> >>> -=3DR >>> >>> >>> >>> >>> >>> >>> >>> From: QUIC on behalf of Ian Swett >>> >>> >>> >>> Date: Friday, October 13, 2017 at 2:05 PM >>> >>> To: Mike Bishop >>> >>> Cc: Mikkel Fahn=C3=B8e J=C3=B8rgensen , "quic@i= etf.org" >>> >>> , Hugues Fafard >>> >>> >>> >>> >>> >>> Subject: Re: Identify streams unidirectional vs bidirectional based >>> >>> on >>> >>> stream ID >>> >>> >>> >>> >>> >>> >>> >>> In many ways, they are 4 independent spaces, but Ryan pointed out t= o >>> >>> me >>> >>> that both for the purposes of draft text and implementation it's ve= ry >>> >>> useful >>> >>> to have a single unique identifier for a stream, since otherwise yo= u >>> >>> have to >>> >>> talk about/pass around (StreamID, Type) everywhere instead of just >>> >>> StreamID. >>> >>> >>> >>> >>> >>> >>> >>> Keeping one stream ID avoids creating two of all the stream specifi= c >>> >>> frames(STOP_SENDING, RST_STREAM, STREAM_FRAME, MAX_DATA_OFFSET, etc= ), >>> >>> one >>> >>> for each stream space. >>> >>> >>> >>> >>> >>> >>> >>> Using the two most significant bits would eliminate the usefulness = of >>> >>> any >>> >>> variable length integer encoding(current or Martin's new proposal), >>> >>> so using >>> >>> the lower bits makes sense. >>> >>> >>> >>> >>> >>> >>> >>> On Fri, Oct 13, 2017 at 4:56 PM, Mike Bishop >>> >>> wrote: >>> >>> >>> >>> Indeed. I almost think it makes more sense to say that there are fo= ur >>> >>> independent stream spaces, each with their own numbers. That does >>> >>> mean that >>> >>> each side will need to separately manage Max Stream ID for two >>> >>> spaces, but >>> >>> that seems more reasonable than the alternative. In fact, this PR >>> >>> already >>> >>> implies that the limits for unidirectional and bidirectional stream= s >>> >>> are >>> >>> handled separately, which gets really weird when the IDs are >>> >>> interleaved >>> >>> with each other. >>> >>> >>> >>> >>> >>> >>> >>> In fact, this plays well with the variable-length encoding idea, >>> >>> since >>> >>> the maximum size of a Stream ID would be 62 bits. They could then b= e >>> >>> stored >>> >>> locally as a 64-bit value with the =E2=80=9Cextra=E2=80=9D bits ind= icating which >>> >>> space they >>> >>> refer to. >>> >>> >>> >>> >>> >>> >>> >>> From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mikkel Fahn= =C3=B8e >>> >>> J=C3=B8rgensen >>> >>> Sent: Friday, October 13, 2017 1:04 PM >>> >>> To: quic@ietf.org; Hugues Fafard >>> >>> Subject: Re: Identify streams unidirectional vs bidirectional based >>> >>> on >>> >>> stream ID >>> >>> >>> >>> >>> >>> >>> >>> Especially with the new variable length encoding proposal, storing >>> >>> the >>> >>> identifiers early makes sense, as you only have to inspect the firs= t >>> >>> byte. >>> >>> But it gets complicated, because you don=E2=80=99t want to use 8 by= tes for >>> >>> some >>> >>> stream types and you don=E2=80=99t want the bits at some random loc= ation in a >>> >>> decoded 8 byte representation either. >>> >>> >>> >>> >>> >>> >>> >>> Regardless of bit placement, encoding state using bits is not ideal >>> >>> when >>> >>> considering variable length encoding because you now use two bits f= or >>> >>> length >>> >>> and two bits for stream type, leaving only 16 different streams >>> >>> before the >>> >>> stream identifier needs to use two bytes, and so forth. >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Kind Regards, >>> >>> >>> >>> Mikkel Fahn=C3=B8e J=C3=B8rgensen >>> >>> >>> >>> >>> >>> >>> >>> On 13 October 2017 at 21.50.06, Hugues Fafard (fafard@in.tum.de) >>> >>> wrote: >>> >>> >>> >>> I see, you used the 2 least significant bits to encode that >>> >>> information. When only using one bit to indicate the direction, it >>> >>> boiled down to odd/even which more or less made sense, but when usi= ng >>> >>> 2 bits that breaks apart. >>> >>> >>> >>> Why not use the most significant bits instead? That way, getting th= e >>> >>> 'clean' stream ID without the flags would be as simple doing a `& >>> >>> 0x3F...FF` instead of bit-shifting things around. Similarly, encodi= ng >>> >>> the stream ID would just entail `| 0x?0...00` to set the appropriat= e >>> >>> bits and also avoid bit-shifts. >>> >>> >>> >>> Regards, >>> >>> Hugues >>> >>> >>> >>> On 2017-10-13 20:51, Ryan Hamilton wrote: >>> >>> > As I understand the discussions at the interim, we've decided to >>> >>> > allow streams to be unidirectional or bidirectional. I support th= is >>> >>> > idea and was motivated to write up an idea I've been thinking abo= ut >>> >>> > for a while. In the same way that we use a bit in the stream ID t= o >>> >>> > identify the client vs server nature of the stream, we can use a >>> >>> > bit to identify the directionality. This divides the stream ID >>> >>> > space neatly into 4 distinct spaces (much like the 2 two we have >>> >>> > today: client/server). In addition this means that a stream ID >>> >>> > always uniquely identifies a single stream, and frames which >>> >>> > mention stream ID (STREAM, MAX_STREAM_ID, MAX_STREAM_DATA, >>> >>> > RST_STREAM, etc) do not need to explicitly convey the >>> >>> > directionality as fields in those frames (or implicitly based on >>> >>> > the directionality of the frames themselves). >>> >>> > >>> >>> > https://github.com/quicwg/base-drafts/pull/872 >>> >>> > >>> >>> > Cheers, >>> >>> > >>> >>> > Ryan >>> >>> >>> >>> >>> >> >>> >> >>> > >> >> > From nobody Thu Oct 26 23:27: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 54B7513B105 for ; Thu, 26 Oct 2017 23:27:05 -0700 (PDT) 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=KbuMhiZ6; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=NdpywrPx Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7U-fJqfFwSh2 for ; Thu, 26 Oct 2017 23:27:03 -0700 (PDT) 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 EB544139B9F for ; Thu, 26 Oct 2017 23:27:02 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3AB7420A5D; Fri, 27 Oct 2017 02:27:02 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 27 Oct 2017 02:27:02 -0400 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=zUxxHDZQ7l80G64Sx3M5wD3ePND2Iest5gm5Z7rW390=; b=KbuMhiZ6 S0vji5IcQPsZAqDVNCC2UFdifOY6JLPsNx/1pMoRZ8+xP4cUoIfw5FV2UWHMq6Du C0JBCL7VnVG9MB1tiHuRjJn9nL/6nKQaQK5GqjPkbEZtNkRHg4UosTzKExOXytBh SEMDtruA4pGIUeGO8cj/mhPNOEyPqvoLM+hJbLFpa5PPNJIRoIT0PKCzQaCsCbTE rNTVBkC7KqFNhKGid84/AqZHnzu9CpqfelvjibRzxlPELeANT4yIfl8fWThLMyWU ttd1s7AMUW9zVZb63WVkHovuXhTsvbCms6irOHL8FCc7uoLSTxD/fjEE7hCyI6/Y 1yKP5s44qpN+eQ== 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=zUxxHDZQ7l80G64Sx3M5wD3ePND2I est5gm5Z7rW390=; b=NdpywrPxc6J4GleHK/wq+MRbn6A3X/NC1oldtx+7k6A85 yOKFh7O3ScQsS66e2t2jlIsV4rM7FaGMzDThbO8Zybh2BZS3Q3bbQV7r3DY5gF5h sUWzMatGboBmgWm8q6HhabUFtI7ZJrxuFOzjPccRQor9+iWPJB0bRtGh//8v1mmS OQPhV3h3zu3pO26QLxPLH1xh00FHzqy6fk9z5KbhMBtOaIFZsAynWVibpHxrEkQ4 9fPXuPLXxbMPCZPBl8S/dKy9aTrVk4QhJWPKHNRoa8waJKgtySSjUX3lUO0B8/FL JpisaJk45tqa419BQuccbjQF7IX+xO/GBeH27y72A== 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 190BA7E139; Fri, 27 Oct 2017 02:27:00 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: QUIC - Our schedule and scope Message-Id: Date: Fri, 27 Oct 2017 17:26:58 +1100 Cc: Lars Eggert , Spencer Dawkins at IETF To: QUIC WG X-Mailer: Apple Mail (2.3445.1.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: Fri, 27 Oct 2017 06:27:05 -0000 Working Group Participants, Since the Working Group is now approximately one year old, it's a good = time to step back and consider how well our work is proceeding. As chairs, we've been concerned about successfully delivering QUIC since = we started this effort. Introducing what is effectively a new transport = protocol for the Internet that incorporates not only reliability, = congestion control and multiplexing, but also encryption and key = exchange, 0RTT handshakes, and what is effectively yet another version = of HTTP is a tall order, especially when we started without broad = implementation or deployment experience beyond a single vendor. The nature of our discussions has also caused us some concern, since we = seem to range over a variety of topics that are difficult to pin down, = thanks to the interdependencies between them. We've explicitly given the = editors license to make bold changes in this start-up period as a way to = move forward, but even with that, we've struggled to manage our workload = -- currently at 170 open issues, with every sign of growing. Our charter instructs us to deliver the "core" four documents in March = 2018, five months away. Many in the Working Group have viewed that = milestone as aspirational, but it's becoming clear that on our current = course, we'll be lucky to deliver QUIC in 2019. In our considered view that is unacceptable, because it requires a = commitment (in time and effort) that many implementers and engineers = will be unwilling to make -- thus impacting the quality of participation = we see, and therefore the quality (and success) of QUIC. To address this, we think two things are necessary: 1) Our Milestone for delivering the "core" QUIC documents (plus = applicability and manageability statements) to the IESG should be moved = to December 2018, with the understanding that this is a deadline we = intend to meet. 2) V1 of QUIC should *only* address the use case of HTTP. This has a few implications: * Proposals for changes that are not realistically achievable in the = timeline of #1 will be rejected on that basis, because the WG has = consensus that the schedule is important. * 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. * Discussion of anything else (including issues, drafts, proposals) that = doesn't address the needs of HTTP-over-QUIC will be postponed until = after V1 has shipped.=20 It's important to understand that this approach is predicated on the = notion that QUIC is not the one chance that we have to evolve transport = protocols; rather, it represents the start of an evolution, to be = followed by any number of new versions that are enabled by assuring that = the extensibility and versioning mechanisms are appropriately "greased" = (i.e., we take measures to assure that they are available in the future; = in other words, counter-ossification). Please discuss on-list; we'll also be covering this in Singapore, and = will call for consensus after gathering further input there. Regards, - Your Chairs, Lars Eggert and Mark Nottingham= From nobody Fri Oct 27 06:50: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 C527313F554 for ; Fri, 27 Oct 2017 06:50:10 -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, 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 cFJGzZPjb8zP for ; Fri, 27 Oct 2017 06:50:04 -0700 (PDT) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 798DC13F516 for ; Fri, 27 Oct 2017 06:50:04 -0700 (PDT) Received: by mail-io0-x22e.google.com with SMTP id 134so12828100ioo.0 for ; Fri, 27 Oct 2017 06:50:04 -0700 (PDT) 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=gwCDVj23rYmrKPr1HFC9q2zG7IfbT2cbbqvplOltdAo=; b=rX3KGOmWn2NYb4uhGAOZj/O9rhaI+m9SYSxlKu+dckX3+1H0yyXzg7f+gHIup6k1RI aA8qpgcHV58dia836fRzF+uSqsA3DmFe1NlfdMhcvJTfmHK+lS94150GI6mjDkfy8mrr 1ZH0E7EcMAGU62p6niYJafpPA4BOvl5AnSlEzBNRYW8teDZV3oFj8t+s1Kv6zhIQSmmg isz2xK5c4Ozk9xbq9asXRwgWLQ5Iuui2XdY2oGc1h/b8Tncz04HNY5qPlQKWJw/QkrOM ki+HVNziImVBdkRTYWWYEbl2hOlwhHcxq42F/ZIerLHjqmJTosakEY5YqdjBphL/DPUz Yt6g== 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=gwCDVj23rYmrKPr1HFC9q2zG7IfbT2cbbqvplOltdAo=; b=VhrZVkJmPXbwEWvjkTCezF3seYGO16MtptO1T+vtQKBBEMKzwICCUBi57iA+eHsI6d 11usScE88nNgweI0yNFmnCYA4EDuIqV8IDcJ2qPd3uzmEHIKbsQtN1whRuIKJ6sNJpzh wx88QxSSGZJwX2pMiLzK771Th+ZCWJsAmiQklDbt3E9FDVayXjPYi0SlfgIzNq6RnVUl 5zTvbK3T5Dopw5mvvY+L1QY+PLh/48HG3u0sv2h5L+Fst+S4/cqnpe+aBqx4oFbH2TIH hvw9h6XnUtmphO290Jz9r8CHYmyUwblWsQav+MGRAFYXDc5fKoTTuU5olqbZ2N2D5cC6 cLwA== X-Gm-Message-State: AMCzsaXA1a37xyvad1r0FGJkTW7rc4L3MvxGyF40Hu4ZP2FVmD8gJrIu 0PudVJIarO2CnsiLtV5TsP0mwnh+VY7jgs8BgHd4Jegs X-Google-Smtp-Source: ABhQp+QQglbZIJXQCkeNzIRkJvQ7sWIuZMBkG4C4YVbPRKLPzIlLm6AXV8UvVP0wGjGbe2niJMQI8TaleBMREOKClCI= X-Received: by 10.107.30.81 with SMTP id e78mr700681ioe.65.1509112203572; Fri, 27 Oct 2017 06:50:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.221 with HTTP; Fri, 27 Oct 2017 06:49:43 -0700 (PDT) In-Reply-To: References: From: Ian Swett Date: Fri, 27 Oct 2017 09:49:43 -0400 Message-ID: Subject: Re: QUIC - Our schedule and scope To: Mark Nottingham Cc: QUIC WG , Lars Eggert , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="001a11418b8cd2deb6055c8790b8" 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, 27 Oct 2017 13:50:11 -0000 --001a11418b8cd2deb6055c8790b8 Content-Type: text/plain; charset="UTF-8" I think pushing back the date for the core documents to December 2018 and focusing on finishing HTTP-over-QUIC is the right choice for all the reasons you outline above. On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham wrote: > Working Group Participants, > > Since the Working Group is now approximately one year old, it's a good > time to step back and consider how well our work is proceeding. > > As chairs, we've been concerned about successfully delivering QUIC since > we started this effort. Introducing what is effectively a new transport > protocol for the Internet that incorporates not only reliability, > congestion control and multiplexing, but also encryption and key exchange, > 0RTT handshakes, and what is effectively yet another version of HTTP is a > tall order, especially when we started without broad implementation or > deployment experience beyond a single vendor. > > The nature of our discussions has also caused us some concern, since we > seem to range over a variety of topics that are difficult to pin down, > thanks to the interdependencies between them. We've explicitly given the > editors license to make bold changes in this start-up period as a way to > move forward, but even with that, we've struggled to manage our workload -- > currently at 170 open issues, with every sign of growing. > > Our charter instructs us to deliver the "core" four documents in March > 2018, five months away. Many in the Working Group have viewed that > milestone as aspirational, but it's becoming clear that on our current > course, we'll be lucky to deliver QUIC in 2019. > > In our considered view that is unacceptable, because it requires a > commitment (in time and effort) that many implementers and engineers will > be unwilling to make -- thus impacting the quality of participation we see, > and therefore the quality (and success) of QUIC. > > To address this, we think two things are necessary: > > 1) Our Milestone for delivering the "core" QUIC documents (plus > applicability and manageability statements) to the IESG should be moved to > December 2018, with the understanding that this is a deadline we intend to > meet. > > 2) V1 of QUIC should *only* address the use case of HTTP. > > This has a few implications: > > * Proposals for changes that are not realistically achievable in the > timeline of #1 will be rejected on that basis, because the WG has consensus > that the schedule is important. > > * 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. > > * Discussion of anything else (including issues, drafts, proposals) that > doesn't address the needs of HTTP-over-QUIC will be postponed until after > V1 has shipped. > > It's important to understand that this approach is predicated on the > notion that QUIC is not the one chance that we have to evolve transport > protocols; rather, it represents the start of an evolution, to be followed > by any number of new versions that are enabled by assuring that the > extensibility and versioning mechanisms are appropriately "greased" (i.e., > we take measures to assure that they are available in the future; in other > words, counter-ossification). > > Please discuss on-list; we'll also be covering this in Singapore, and will > call for consensus after gathering further input there. > > Regards, > > - Your Chairs, Lars Eggert and Mark Nottingham > --001a11418b8cd2deb6055c8790b8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think pushing back the date for the core documents to De= cember 2018 and focusing on finishing HTTP-over-QUIC is the right choice fo= r all the reasons you outline above.

On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham <mnot@mnot= .net> wrote:
Working Group = Participants,

Since the Working Group is now approximately one year old, it's a good = time to step back and consider how well our work is proceeding.

As chairs, we've been concerned about successfully delivering QUIC sinc= e we started this effort. Introducing what is effectively a new transport p= rotocol for the Internet that incorporates not only reliability, congestion= control and multiplexing, but also encryption and key exchange, 0RTT hands= hakes, and what is effectively yet another version of HTTP is a tall order,= especially when we started without broad implementation or deployment expe= rience beyond a single vendor.

The nature of our discussions has also caused us some concern, since we see= m to range over a variety of topics that are difficult to pin down, thanks = to the interdependencies between them. We've explicitly given the edito= rs license to make bold changes in this start-up period as a way to move fo= rward, but even with that, we've struggled to manage our workload -- cu= rrently at 170 open issues, with every sign of growing.

Our charter instructs us to deliver the "core" four documents in = March 2018, five months away. Many in the Working Group have viewed that mi= lestone as aspirational, but it's becoming clear that on our current co= urse, we'll be lucky to deliver QUIC in 2019.

In our considered view that is unacceptable, because it requires a commitme= nt (in time and effort) that many implementers and engineers will be unwill= ing to make -- thus impacting the quality of participation we see, and ther= efore the quality (and success) of QUIC.

To address this, we think two things are necessary:

1) Our Milestone for delivering the "core" QUIC documents (plus a= pplicability and manageability statements) to the IESG should be moved to D= ecember 2018, with the understanding that this is a deadline we intend to m= eet.

2) V1 of QUIC should *only* address the use case of HTTP.

This has a few implications:

* Proposals for changes that are not realistically achievable in the timeli= ne of #1 will be rejected on that basis, because the WG has consensus that = the schedule is important.

* 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 ad= dressed by V2 and beyond.

* Discussion of anything else (including issues, drafts, proposals) that do= esn't address the needs of HTTP-over-QUIC will be postponed until after= V1 has shipped.

It's important to understand that this approach is predicated on the no= tion that QUIC is not the one chance that we have to evolve transport proto= cols; rather, it represents the start of an evolution, to be followed by an= y number of new versions that are enabled by assuring that the extensibilit= y and versioning mechanisms are appropriately "greased" (i.e., we= take measures to assure that they are available in the future; in other wo= rds, counter-ossification).

Please discuss on-list; we'll also be covering this in Singapore, and w= ill call for consensus after gathering further input there.

Regards,

- Your Chairs, Lars Eggert and Mark Nottingham

--001a11418b8cd2deb6055c8790b8-- From nobody Fri Oct 27 08:13: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 ED28C13B42C for ; Fri, 27 Oct 2017 08:13:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.734 X-Spam-Level: X-Spam-Status: No, score=-0.734 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_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 rUQN04XQgDg5 for ; Fri, 27 Oct 2017 08:13:45 -0700 (PDT) Received: from linode64.ducksong.com (linode6only.ducksong.com [IPv6:2600:3c02::f03c:91ff:fe6e:e8da]) by ietfa.amsl.com (Postfix) with ESMTP id B7A7E1386DE for ; Fri, 27 Oct 2017 08:13:45 -0700 (PDT) Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by linode64.ducksong.com (Postfix) with ESMTPSA id CD3573A0A4 for ; Fri, 27 Oct 2017 11:13:44 -0400 (EDT) Received: by mail-lf0-f50.google.com with SMTP id 90so7770396lfs.13 for ; Fri, 27 Oct 2017 08:13:44 -0700 (PDT) X-Gm-Message-State: AMCzsaV6sWaKrkifzE95X1An3ERoKMy/vxE9FzDCM90yHY1ahNYYvE0C w84cK6I/BPkV+f3Q0bd5g49zQCRC2oCyqu5m5zs= X-Google-Smtp-Source: ABhQp+QWHdGYgqm4Rw2t2IZDvD7YJ6E/0F5pqfwwNRWaqDQu2JLzJeKqz+SaVVb8qMJhD6k48li/N8Eab1GNdsU3oNQ= X-Received: by 10.25.23.214 with SMTP id 83mr271241lfx.213.1509117222950; Fri, 27 Oct 2017 08:13:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.21.22 with HTTP; Fri, 27 Oct 2017 08:13:42 -0700 (PDT) In-Reply-To: References: From: Patrick McManus Date: Fri, 27 Oct 2017 11:13:42 -0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: QUIC - Our schedule and scope To: Mark Nottingham Cc: QUIC WG , Lars Eggert , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="001a1142cb34ff9e32055c88bb8e" 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, 27 Oct 2017 15:13:48 -0000 --001a1142cb34ff9e32055c88bb8e Content-Type: text/plain; charset="UTF-8" Hi All, First, the observation that elapsed time impacts participation and participation impacts quality is a good observation. Finishing faster (I personally want to go way way faster) is consistent with that and we should look at how we're organized to help make that a reality. Thanks for doing that. I'm also not quite as pessimistic as the chairs are. I don't really think this is a linear process - as we get more input from more implementations I think the process will naturally accelerate. The challenge at that later stage will be on not re-opening issues that we have reached consensus on. That's different than the challenge we've been going through for the last year; for the last year we've been building up the basic blocks from an explicitly 0-consensus starting point. Its both not surprising, and a good thing, that many issues have been given scrutiny during that phase. On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham wrote: > > To address this, we think two things are necessary: > > Just for clarification, you're suggesting these 2 bullets as updates in some form to the wg charter? > 1) Our Milestone for delivering the "core" QUIC documents (plus > applicability and manageability statements) to the IESG should be moved to > December 2018, with the understanding that this is a deadline we intend to > meet. > > 2) V1 of QUIC should *only* address the use case of HTTP. > > This has a few implications: > > * Proposals for changes that are not realistically achievable in the > timeline of #1 will be rejected on that basis, because the WG has consensus > that the schedule is important. > > This needs to be severely unpacked and I do not support it in the way I'm interpreting it. I think the only way we're going to finish quickly and still create a good product is if all the participants are focused on getting to yes. A shot clock process fix isn't going to get a high quality result - we need an attitude fix :) The current charter says "Note that consensus is required both for changes to the current protocol mechanisms and retention of current mechanisms. In particular, because something is in the initial document set does not imply that there is consensus around the feature or around how it is specified." This remains an important property for the evolution of IETF QUIC. We need to work through all the details as a working group.. I think we can do it faster, but not by inventing an arbitrary forcing function. A firm timebox severely undermines the consensus process via simple gamificiation to 'run out the clock' in favor of existing text. That is not in the interest of the end result or getting consensus in a multi-stakeholder process. Indeed it probably increases the chances for a disastrous last call period. However, getting to yes is in everybody's interest. That's a much better motivator. I think a better path would be for the chairs to more aggressively declare rough consensus at an earlier stage of discussion than is typically done. I'm not suggesting a different threshold of consensus, just less indulgence in letting issues play all the way out in hopes of convergence. Perhaps also an appeal to all WG members to consider the implications of expressing an opinion on a topic .. Every issue does not need to be a poll for everyone's opinion.. save it for places where your opinion makes a material difference to you. (i.e. acknowledge that two people will disagree on what is a bikeshed vs what is meaningful and stay out of it in the name of progress if you are on the bikeshed side). I have no objection to updating the milestone delivery date to something more reasonable, but I do think elevating schedule to be a higher order concern than consensus on the RFC content is wrong. I think your second suggestion, scoping around HTTP for v1, is more likely to get us to a successful finish. As we get later in this process, it will be more important. > * Discussion of anything else (including issues, drafts, proposals) that > doesn't address the needs of HTTP-over-QUIC will be postponed until after > V1 has shipped. > > Browsing through the archives I actually don't see very many issues that are totally non-http (certainly < 10%). But there probably are quite a few that are simpler to resolve if only http is taken into account. -P --001a1142cb34ff9e32055c88bb8e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi All,

First, the obse= rvation that elapsed time impacts participation and=20 participation impacts quality is a good observation. Finishing faster (I personally want to go way way faster) is consistent with that and we=20 should look at how we're organized to help make that a reality. Thanks= =20 for doing that.

I'm also not quite as pess= imistic as the chairs are. I don't really think this is a linear proces= s - as we get more input from more implementations I think the process will= naturally accelerate. The challenge at that later stage will be on not re-= opening issues that we have reached consensus on. That's different than= the challenge we've been going through for the last year; for the last= year we've been building up the basic blocks from an explicitly 0-cons= ensus starting point. Its both not surprising, and a good thing, that many = issues have been given scrutiny during that phase.

=

On Fri= , Oct 27, 2017 at 2:26 AM, Mark Nottingham <mnot@mnot.net> wrote= :

To address this, we think two things are necessary:


Just for clarification, you're sug= gesting these 2 bullets as updates in some form to the wg charter?
=C2=A0
1) Our Milestone for delivering the "core" QUIC documents (plus a= pplicability and manageability statements) to the IESG should be moved to D= ecember 2018, with the understanding that this is a deadline we intend to m= eet.

2) V1 of QUIC should *only* address the use case of HTTP.

This has a few implications:

* Proposals for changes that are not realistically achievable in the timeli= ne of #1 will be rejected on that basis, because the WG has consensus that = the schedule is important.


This needs to be severely unpacked and= I do not support it in the way I'm interpreting it.

= I think the only way we're going to finish quickly and still create a g= ood product is if all the participants are focused on getting to yes. A sho= t clock process fix isn't going to get a high quality result - we need = an attitude fix :)

The current charter says "= Note that consensus is required both for changes to the current protocol me= chanisms and retention of current mechanisms. In particular, because someth= ing is in the initial document set does not imply that there is consensus= =C2=A0 around the feature or around how it is specified." This remains= an important property for the evolution of IETF QUIC. We need to work thr= ough all the details as a working group.. I think we can do it faster, but = not by inventing an arbitrary forcing function.

A firm timebox severely undermines the consensus process via simple gamif= iciation to 'run out the clock' in favor of existing text. That is = not in the interest of the end result or getting consensus in a multi-stake= holder process. Indeed it probably increases the chances for a disastrous l= ast call period. However, getting to yes is in everybody's interest. Th= at's a much better motivator.

I think a be= tter path would be for the chairs to more aggressively declare rough consen= sus at an earlier stage of discussion than is typically done. I'm not s= uggesting a different threshold of consensus, just less indulgence in letti= ng issues play all the way out in hopes of convergence. Perhaps also an app= eal to all WG members to consider the implications of expressing an opinion= on a topic .. Every issue does not need to be a poll for everyone's op= inion.. save it for places where your opinion makes a material difference t= o you. (i.e. acknowledge that two people will disagree on what is a bikeshe= d vs what is meaningful and stay out of it in the name of progress if you a= re on the bikeshed side).

I have no objection = to updating the milestone delivery date to something more reasonable, but I= do think elevating schedule to be a higher order concern than consensus on= the RFC content is wrong.

I think your second sug= gestion, scoping around HTTP for v1, is more likely to get us to a successf= ul finish. As we get later in this process, it will be more important.
<= /div>

=C2=A0
* Discussion of anything else (including issues, drafts, proposals) that do= esn't address the needs of HTTP-over-QUIC will be postponed until after= V1 has shipped.


Browsing through the archives I actual= ly don't see very many issues that are totally non-http (certainly <= 10%). But there probably are quite a few that are simpler to resolve if on= ly http is taken into account.

-P

--001a1142cb34ff9e32055c88bb8e-- From nobody Fri Oct 27 09:20:24 2017 Return-Path: X-Original-To: quic@ietfa.amsl.com Delivered-To: quic@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6118C13EDE3 for ; Fri, 27 Oct 2017 09:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 tEyZUyRSnzMq for ; Fri, 27 Oct 2017 09:20:21 -0700 (PDT) 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 383011389E6 for ; Fri, 27 Oct 2017 09:20:21 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9RGJYVK012904; Fri, 27 Oct 2017 17:20:17 +0100 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=sZdwHHj2e44yMnXYzfK58Trfa0TGdVq397GChGXc7Nk=; b=kcFL/SZLG4L1ImwSdFAOjM5Cq80EG9Xq5bz4ELFWqawnOR2bjZI2JmrupePiWz2nu+tW PCZ0j5Z3blP0oRvVvOLoqlvyFHGrtIYo4KBqHbS9FuVbQuUPNNIOcHbZvieEkFPU5+rx rrc7yLpE+KvNwN+jXPxTTglVBjYtUdHN1ucjZ7Tq/AfzjOhLY9dfQXmCsuqIFQ78zi5c vPHhh8HE/S90AOyE+TL0QWiUt+VlHDyLGnCSlz/YBQFBFdTR4xvZHB7/gaFwHAcPNzk+ gcTukUDHqy9q1iWZpTckKBkYY5vEOaUPCA4Y90/TFfN0QnAd+10xBpEJm7et1NdiLoR9 EQ== Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050102.ppops.net-00190b01. with ESMTP id 2dv0ym19jm-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Oct 2017 17:20:17 +0100 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 v9RGFoVs031121; Fri, 27 Oct 2017 12:20:16 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint1.akamai.com with ESMTP id 2dr1juu7fe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 27 Oct 2017 12:20:16 -0400 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 27 Oct 2017 12:20:15 -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; Fri, 27 Oct 2017 12:20:15 -0400 From: "Salz, Rich" To: Mark Nottingham CC: QUIC WG , Lars Eggert , "Spencer Dawkins at IETF" Subject: Re: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuyfJxlFlbUFqEOgvVjbtyLRUqL4EY4AgAASmIA= Date: Fri, 27 Oct 2017 16:20:15 +0000 Message-ID: <17E462A6-FC87-47BA-8B31-88D47F8378E9@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.233] Content-Type: multipart/alternative; boundary="_000_17E462A6FC8747BA8B3188D47F8378E9akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-27_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-1710270214 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-27_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-1710270215 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, 27 Oct 2017 16:20:22 -0000 --_000_17E462A6FC8747BA8B3188D47F8378E9akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WW91IG1pZ2h0IGFsc28gd2FudCB0byBjb25zaWRlciB3aGF0IFRMUyAxLjMgaXMgZ29pbmcgdGhy b3VnaCBhbmQgYWxsb3cgYW4gZXNjYXBlIGhhdGNoIGlmIHlvdeKAmXZlIGdvdCBhIGdvb2QgcHJv dG9jb2wgYnV0IGN1cnJlbnQgSW50ZXJuZXQgY29uZGl0aW9ucyBwcmV2ZW50IGl0IGZyb20gZ2V0 dGluZyBhY2NlcHRhYmx5LXdpZGUgZGVwbG95bWVudC4gIEFuZCB0aGVuLCB0aGUgZm9sbG93LW9u IHF1ZXN0aW9uOiB3aGF0ICp3b3VsZCogYmUgYW4gYWNjZXB0YWJsZSBsZXZlbCBvZiBpbnRlcmZl cmVuY2UvYmxvY2thZ2Ug4oCTIDEsIDUsIDEwJT8NCg0K --_000_17E462A6FC8747BA8B3188D47F8378E9akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <91D9988AFBADFE48AD7B79E58A1BAD4A@akamai.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHls ZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N CnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1u YW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxh bmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRT ZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Zb3UgbWlnaHQgYWxzbyB3YW50IHRvIGNv bnNpZGVyIHdoYXQgVExTIDEuMyBpcyBnb2luZyB0aHJvdWdoIGFuZCBhbGxvdyBhbiBlc2NhcGUg aGF0Y2ggaWYgeW914oCZdmUgZ290IGEgZ29vZCBwcm90b2NvbCBidXQgY3VycmVudCBJbnRlcm5l dCBjb25kaXRpb25zIHByZXZlbnQgaXQgZnJvbSBnZXR0aW5nIGFjY2VwdGFibHktd2lkZSBkZXBs b3ltZW50LiZuYnNwOyBBbmQgdGhlbiwgdGhlIGZvbGxvdy1vbiBxdWVzdGlvbjoNCiB3aGF0ICo8 Yj53b3VsZDwvYj4qIGJlIGFuIGFjY2VwdGFibGUgbGV2ZWwgb2YgaW50ZXJmZXJlbmNlL2Jsb2Nr YWdlIOKAkyAxLCA1LCAxMCU/PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_17E462A6FC8747BA8B3188D47F8378E9akamaicom_-- From nobody Fri Oct 27 09:24: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 649EE13F5AB for ; Fri, 27 Oct 2017 09:24:08 -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, 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=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 dZ7c74OK7OMW for ; Fri, 27 Oct 2017 09:24:07 -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 5A49713EDE3 for ; Fri, 27 Oct 2017 09:24:07 -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 v9RGJZJv029926; Fri, 27 Oct 2017 17:24:04 +0100 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=lXWFWQPiqs6Fhbvu2X3EX9UVawr/xy/yumlyZ3AZPlU=; b=atMAJi2usVaBWFvFFLIPf3tvP5Gwc099ty/thzu2FzyHStsled18CQZFp45SDCFj9fF1 /UQoAQ0Fv4lUWKkMvpW1MdSxTcwlvckDCMYttLcQbOyXP15AA+mYMkzDPaydYnUx8FGh meZ6N1W/E0Ez+/0IMkXtFkAmYb+Yz7QqHlDNN2R26TjuXxRsxkjqo+K6zKWh9YXlSIBl iMaFpIecD0kqOoUOmiZ1Lz7sX12v5Rk2eYzjh35Q0BgHze88TwOz2HbYUG7QcOpNKsg1 Ps5Vebijme8YZ3kb9YqL9iHQgfTpLToXMkQE69cYVffjq6z74qEbKJVp3S3onJg0d/Ii 2g== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2du4hqnppe-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 27 Oct 2017 17:24:04 +0100 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 v9RGKjLk026391; Fri, 27 Oct 2017 12:23:59 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.33]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dr1juka6b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 27 Oct 2017 12:23:59 -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 Microsoft SMTP Server (TLS) id 15.0.1263.5; Fri, 27 Oct 2017 12:23:58 -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; Fri, 27 Oct 2017 12:23:58 -0400 From: "Salz, Rich" To: Patrick McManus , Mark Nottingham CC: QUIC WG , Lars Eggert , "Spencer Dawkins at IETF" Subject: Re: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuyfJxlFlbUFqEOgvVjbtyLRUqL4EY4AgAATogA= Date: Fri, 27 Oct 2017 16:23:58 +0000 Message-ID: <103AEBDF-49F7-4114-BBEC-076806B49460@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.27.0.171010 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.233] Content-Type: multipart/alternative; boundary="_000_103AEBDF49F74114BBEC076806B49460akamaicom_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-27_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-1710270215 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-27_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-1710270215 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, 27 Oct 2017 16:24:08 -0000 --_000_103AEBDF49F74114BBEC076806B49460akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgSSBoYXZlIG5vIG9iamVjdGlvbiB0byB1cGRhdGluZyB0aGUgbWlsZXN0b25lIGRlbGl2 ZXJ5IGRhdGUgdG8gc29tZXRoaW5nIG1vcmUgcmVhc29uYWJsZSwgYnV0IEkgZG8gdGhpbmsgZWxl dmF0aW5nIHNjaGVkdWxlIHRvIGJlIGEgaGlnaGVyIG9yZGVyIGNvbmNlcm4gdGhhbiBjb25zZW5z dXMgb24gdGhlIFJGQyBjb250ZW50IGlzIHdyb25nLg0KDQpJIHZlcnkgc3Ryb25nbHkgYWdyZWUg d2l0aCB0aGlzIQ0KDQo= --_000_103AEBDF49F74114BBEC076806B49460akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlzdFBhcmFncmFwaCwg bGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7bXNvLXN0eWxlLXBy aW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbWFyZ2lu LWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7 DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9 DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw YW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1l OiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hw RGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0 O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4w aW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDo5 NDMxNDU5NDY7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xMTM4ODU2MTE4IC0xMzg2MzkzMjggNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwx DQoJe21zby1sZXZlbC1zdGFydC1hdDowOw0KCW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczsNCgltc28tZmFy ZWFzdC1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgltc28tYmlkaS1mb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xvcjpibGFjazsNCgltc28tYW5zaS1mb250LXdlaWdo dDpib2xkO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyIsc2VyaWY7fQ0KQGxpc3QgbDA6bGV2ZWwzDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3IixzZXJpZjt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciLHNlcmlmO30NCkBs aXN0IGwwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206 MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp b24xIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz PSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxl dmVsMSBsZm8xIj5JIGhhdmUgbm8gb2JqZWN0aW9uIHRvIHVwZGF0aW5nIHRoZSBtaWxlc3RvbmUg ZGVsaXZlcnkgZGF0ZSB0byBzb21ldGhpbmcgbW9yZSByZWFzb25hYmxlLCBidXQgSSBkbyB0aGlu ayBlbGV2YXRpbmcgc2NoZWR1bGUgdG8gYmUgYSBoaWdoZXIgb3JkZXIgY29uY2VybiB0aGFuIGNv bnNlbnN1cyBvbiB0aGUgUkZDIGNvbnRlbnQNCiBpcyB3cm9uZy48bzpwPjwvbzpwPjwvbGk+PC91 bD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgdmVyeSBzdHJvbmdseSBhZ3JlZSB3aXRoIHRoaXMhPG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_103AEBDF49F74114BBEC076806B49460akamaicom_-- From nobody Fri Oct 27 09:26: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 3A0F613F5AB for ; Fri, 27 Oct 2017 09:26:20 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uCB3JapG3zeN for ; Fri, 27 Oct 2017 09:26:18 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6FD13EDE3 for ; Fri, 27 Oct 2017 09:26:18 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id k11so6217553ywh.1 for ; Fri, 27 Oct 2017 09:26:18 -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=/VbGXs5w9dQNhokkGMhjY1oMwg2DH9HVtJNz15xhGxY=; b=pFhgAEouiCkWw+yhiRxC9SF9Wlwbv3W1ttpV4lYhdL+n//AFctlO2877wzxNQC289q v4nfHQXtxL3dVNSlXyHE9I4e/pkOdoKkvXOKqZg50RY7XgWs0tZ+qz3JorKn6vV4XBDw yIhxkxO8VL1j2BZSO2l1iim0zVrOvfy5aZTlqeGoz5396Af53iburYJh0L27anJdTr7j 0JpuwtwLDz3sE3F0AE1lJuHBfzh7FxRRPI3Z9/iFI+WVw8phm6clKHFa/pLBwAX0KuCY vkGwvHWBIIvH2gSKaaxEsYuUxoRpLYh91ogdKqVijvOTsf4nqjT6uJHQtRDel56C3t0H /t0A== 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=/VbGXs5w9dQNhokkGMhjY1oMwg2DH9HVtJNz15xhGxY=; b=uSNTbvILo5UCPs3H0jj+k/xXj36y48lse5rJRYoyrKPwz3CcvBTizrPQiSuf2HlRSV DHcoTN+m045ujYriAwnYmlwhWi7RMSKemHWo61P4lzNXEDUwzf5G4R3/DQJBSI50AFUi 7py8X6lH7JfMejHrmcYmzGcvrcmSQgzm2EeXrKeuI4IVw1Mnfet+lOheDAzLo6jFxbif O1ShJay0cpCY8Rm6K1ZuAifFu9fDPdX6MnhU4OwTYlpJae4L3rfOrUG7ALXgYpn9/ZO5 hLfgHOKHb3SQkObKswiDeKE8Vg6NFHVW1IG7MzCYqurTBa57Nvg41inZiZzmEkSSG4XT LAuw== X-Gm-Message-State: AMCzsaUT6tB/4yp/p4G2EZOhkpmeWJ4lQJg5UzFTDIOp0b1eXTeTtjNj UWwEautcmKqzozvaTGlCHljrbeWUsnTd2YtjzdTC3g== X-Google-Smtp-Source: ABhQp+SDjOShbTqsHYeUQHK4Kq94raIkW5WN5fgqzOLOZxF3oQH7fjylOf57GAhUgMExWOuhmvGaNjrrrb/LfMUYUf8= X-Received: by 10.37.22.8 with SMTP id 8mr745542ybw.353.1509121577536; Fri, 27 Oct 2017 09:26:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.75.194 with HTTP; Fri, 27 Oct 2017 09:25:37 -0700 (PDT) In-Reply-To: <17E462A6-FC87-47BA-8B31-88D47F8378E9@akamai.com> References: <17E462A6-FC87-47BA-8B31-88D47F8378E9@akamai.com> From: Eric Rescorla Date: Fri, 27 Oct 2017 09:25:37 -0700 Message-ID: Subject: Re: QUIC - Our schedule and scope To: "Salz, Rich" Cc: Mark Nottingham , QUIC WG , Lars Eggert , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="001a114167188d64b5055c89bf40" 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, 27 Oct 2017 16:26:20 -0000 --001a114167188d64b5055c89bf40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Oct 27, 2017 at 9:20 AM, Salz, Rich wrote: > You might also want to consider what TLS 1.3 is going through and allow a= n > escape hatch if you=E2=80=99ve got a good protocol but current Internet c= onditions > prevent it from getting acceptably-wide deployment. And then, the > follow-on question: what **would** be an acceptable level of > interference/blockage =E2=80=93 1, 5, 10%? > Well, we already know there's going to be a fair amount of blockage because lots of firewalls block UDP entirely. Estimates vary, but generally what I've seen is on the order of low single digit %ages. Any deployment of QUIC is going to need some way to fall back to TLS over TCP. So, it's kind of a cost benefit calculation of are you getting enough QUIC penetration to make it worth it. The public experience with WebRTC suggests that the answer will be yes, though... -Ekr --001a114167188d64b5055c89bf40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Fri, Oct 27, 2017 at 9:20 AM, Salz, Rich <rsalz@akamai.com> wrote:

You might also want to consider what TLS 1.3 is goin= g through and allow an escape hatch if you=E2=80=99ve got a good protocol b= ut current Internet conditions prevent it from getting acceptably-wide depl= oyment.=C2=A0 And then, the follow-on question: what *would* be an acceptable level of interference/blockage =E2=80= =93 1, 5, 10%?


Well, we alr= eady know there's going to be a fair amount of blockage because lots of= firewalls block UDP entirely. Estimates vary, but generally what I've = seen is on the order of low single digit %ages. Any deployment of QUIC is g= oing to need some way to fall back to TLS over TCP. So, it's kind of a = cost benefit calculation of are you getting enough QUIC penetration to make= it worth it. The public experience with WebRTC suggests that the answer wi= ll be yes, though...

-Ekr


--001a114167188d64b5055c89bf40-- From nobody Fri Oct 27 09: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 91AFC13F3FF for ; Fri, 27 Oct 2017 09:37:03 -0700 (PDT) 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 YF8IRUDZFTy9 for ; Fri, 27 Oct 2017 09:36:55 -0700 (PDT) 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 F3C2F133047 for ; Fri, 27 Oct 2017 09:36:54 -0700 (PDT) Received: from BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) by mailout1.telhc.bbc.co.uk (8.15.2/8.15.2) with ESMTP id v9RGaqMu025601; Fri, 27 Oct 2017 17:36:52 +0100 (BST) Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1005.national.core.bbc.co.uk ([10.184.50.55]) with mapi id 14.03.0361.001; Fri, 27 Oct 2017 17:36:52 +0100 From: Lucas Pardue To: Mark Nottingham , QUIC WG CC: Lars Eggert , Spencer Dawkins at IETF Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuygoRyfQK5nH0aqrxlKAhFp4aL34mwg Date: Fri, 27 Oct 2017 16:36:51 +0000 Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> References: 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: 1cd3ac1c-62e5-43f2-8404-6b688271c769 x-tm-as-product-ver: SMEX-11.0.0.4255-8.100.1062-23422.000 x-tm-as-result: No--19.238400-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: Fri, 27 Oct 2017 16:37:03 -0000 Hi Mark, > Our charter instructs us to deliver the "core" four documents in March 20= 18, > five months away. > To address this, we think two things are necessary: > > 1) Our Milestone for delivering the "core" QUIC documents (plus applicabi= lity > and manageability statements) to the IESG should be moved to December > 2018, with the understanding that this is a deadline we intend to meet. > > 2) V1 of QUIC should *only* address the use case of HTTP. > > This has a few implications: > > * Proposals for changes that are not realistically achievable in the time= line of > #1 will be rejected on that basis, because the WG has consensus that the > schedule is important. > > * 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. > > * Discussion of anything else (including issues, drafts, proposals) that = doesn't > address the needs of HTTP-over-QUIC will be postponed until after V1 has > shipped. > To date, I've tried to avoid mentioning Multipath on list and bring it up n= ow only as it relates to the WG Charter Milestones. Can you be more explicit on how your proposals affect the current Multipath= extension document dates? I could infer that the proposed changes to the c= ore docs are independent of the extension doc, or more realistically the re= scheduling also punts Multipath off another ~6 months (minimum) or until QU= IC V2. What is more aligned with your current thinking? Kind regards Lucas ----------------------------- 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 Fri Oct 27 11:30: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 1ACE613F42F for ; Fri, 27 Oct 2017 11:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 wUBDiNzVKWDp for ; Fri, 27 Oct 2017 11:30:08 -0700 (PDT) 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 D34A213A65C for ; Fri, 27 Oct 2017 11:30:07 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.44,304,1505804400"; d="asc'?scan'208,217";a="224550505" Received: from hioexcmbx08-prd.hq.netapp.com ([10.122.105.41]) by mx143-out.netapp.com with ESMTP; 27 Oct 2017 11:00:03 -0700 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx08-prd.hq.netapp.com (10.122.105.41) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 27 Oct 2017 11:30:06 -0700 Received: from NAM01-SN1-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; Fri, 27 Oct 2017 11:30:06 -0700 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=l0UbUlZOvXU6fNpCzJd3LMXRutxJvW9g10kh3xr+atM=; b=oIwEb2eXY1JqFLCiVnziOZYi7dwpdsigi/PCkGwI+En4qRg/aNsWhJUCxU+OvosD2Nzf8h/HD9OkSBnzBeDqQFsez+wYaqVxh6bvaMiR6ddOJTAjHRGrE6COxj0vfGiUSWYbIE10bXvGHgLlOuybmxGBGLxkIkzzndLPLTI9EF0= 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.178.6; Fri, 27 Oct 2017 18:30:05 +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.0178.007; Fri, 27 Oct 2017 18:30:04 +0000 From: "Eggert, Lars" To: Patrick McManus CC: Mark Nottingham , QUIC WG , "Spencer Dawkins at IETF" Subject: Re: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuylSIJRNvocE0WivHlzUsNNn6L3zoAAgAA23IA= Date: Fri, 27 Oct 2017 18:30:04 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.1.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:3189:6f01:40c:53bf:cda8:32b4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:oYYTaYtzOpgI1cIAaMrWFmGbmiX7H5NSMPz5GD2eRociWGZz/D+LuIOiVR+mqo8C8XvPMsAfrKd8vT/hY9MTHxOAbuRBsXYMmbns7oI6zK6sM1hw+dExgR9EgdIZGU4S7RL4B6OrTUDwBzkbbUJ7AN1izwZ44jzuXkKyvBjMo8bvRsg43dSP09dk+7pb7IQRDQrPthw2UdsNgTBbA/Bb15ibWaJZWl1vfCg/zeMOMbypI0DV8aK5snLSoAaUEYSS/8cJzI8WtuIyIn46+xElXPNp77+Hspz3y6eqy/LUzSwg4qUIHrtkkbqE/2ktOOKg0ejTOSjDmbKNY/Sq8Ag5NKnkforr1niU8X2a9rqpOYM=; 5:P0eIo9V8qmNI/YbdLJna54ktejH4EVr5xBW1aQXz0N2SAFEMY2MSJZnmjLV8SZuHsBAlY6v4aEDg4g6w4WCAa+Mk9HvYhsMo1PP1cux34iQRskErJWpdDEt1AkDBr+Dvq8zjwDTfa7zxouST2STwQBqDJZmuXGmAA04IyWZQb4Q=; 24:R+N/SO68roEACa9K/mIISBxhPqYCdj7OkbPfL5Mir/JArR1LXITNrA1IGYPkJVxzKWGrfl1BNSaiPmBXmMSh1M2/kXbCLrt2tGaNzYxAPGA=; 7:EJgTewNyw/S/P8j/3CYnyyJtKR/QEPmk8WQvOCf2Tl0ySkq5QlylUYm+0igMM+QxBmYeDtjbZq9kC8RV7uzRnA2Scy/Hx6uUiYE3Gp9g+3KraWGVRqy3ex0HXEDE0lSCE2HNs4gRf0amR+TfhodwSGGTRbLP+YE3i1Ng5wS5E6as0fefqjP/kzYixFFoiWMuwwH2vWe/V9JWdpFLkzccxDS8+NTKf8HcYvk5tfp9dVh7FCXMI9B30B7EbT0o2+p9 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 2130ff29-b6ad-4426-fc1e-08d51d68be54 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199)(49563074); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-exchange-antispam-report-test: UriScan:(278428928389397)(100405760836317); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(100000703101)(100105400095)(10201501046)(3002001)(93006095)(93001095)(3231020)(6055026)(6041248)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123564025)(20161123558100)(20161123562025)(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: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(24454002)(377424004)(199003)(189002)(189998001)(39060400002)(6246003)(7736002)(4326008)(76176999)(3280700002)(3660700001)(50986999)(57306001)(478600001)(6512007)(8936002)(2906002)(53936002)(316002)(81156014)(99936001)(54896002)(236005)(106356001)(8676002)(101416001)(105586002)(81166006)(33656002)(99286003)(25786009)(6506006)(6486002)(2900100001)(77096006)(68736007)(50226002)(6916009)(83716003)(6436002)(6116002)(102836003)(4001150100001)(14454004)(36756003)(97736004)(86362001)(53546010)(229853002)(54906003)(82746002)(5660300001)(2950100002); 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=_05D63C3E-DC0C-4581-AB63-5F78324A0029"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2130ff29-b6ad-4426-fc1e-08d51d68be54 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 18:30:04.7650 (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: Fri, 27 Oct 2017 18:30:10 -0000 --Apple-Mail=_05D63C3E-DC0C-4581-AB63-5F78324A0029 Content-Type: multipart/alternative; boundary="Apple-Mail=_9BAEAC02-3691-46D6-8560-CB8D5515516E" --Apple-Mail=_9BAEAC02-3691-46D6-8560-CB8D5515516E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-10-27, at 17:13, Patrick McManus wrote: > On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham > wrote: >=20 > To address this, we think two things are necessary: >=20 > Just for clarification, you're suggesting these 2 bullets as updates = in some form to the wg charter? >=20 > 1) Our Milestone for delivering the "core" QUIC documents (plus = applicability and manageability statements) to the IESG should be moved = to December 2018, with the understanding that this is a deadline we = intend to meet. >=20 > 2) V1 of QUIC should *only* address the use case of HTTP. I haven't synced with Mark on this, but my personal view is that neither = of these affect the charter text. (1) changes the date of our = milestones. (2) is - in my view at least - already what the charter = expresses: it doesn't talk about applications other than HTTP as = something that work is occurring on. > This has a few implications: >=20 > * Proposals for changes that are not realistically achievable in the = timeline of #1 will be rejected on that basis, because the WG has = consensus that the schedule is important. >=20 > This needs to be severely unpacked and I do not support it in the way = I'm interpreting it. >=20 > I think the only way we're going to finish quickly and still create a = good product is if all the participants are focused on getting to yes. A = shot clock process fix isn't going to get a high quality result - we = need an attitude fix :) Agreed. > The current charter says "Note that consensus is required both for = changes to the current protocol mechanisms and retention of current = mechanisms. In particular, because something is in the initial document = set does not imply that there is consensus around the feature or around = how it is specified." This remains an important property for the = evolution of IETF QUIC. We need to work through all the details as a = working group.. I think we can do it faster, but not by inventing an = arbitrary forcing function. Reading your comment, I can now see how the original text could be = interpreted this way. However, at least my understanding of what we were = trying to express that there is an urgency to deliver, and we hope that = by narrowing the discussion on what is important for H2 we can avoid = going down some ratholes that are unrelated, or at least avoid going = down them quite as deeply. But if there are design choices that the WG has consensus on that are = important for H2, and they would postpone shipping v1 *and* the WG is OK = with that, too, then that's what it'll be. But we should all be = conscious of the quality vs. time tradeoff. > A firm timebox severely undermines the consensus process via simple = gamificiation to 'run out the clock' in favor of existing text. That is = not in the interest of the end result or getting consensus in a = multi-stakeholder process. Indeed it probably increases the chances for = a disastrous last call period. However, getting to yes is in everybody's = interest. That's a much better motivator. Full agreement. > I think a better path would be for the chairs to more aggressively = declare rough consensus at an earlier stage of discussion than is = typically done. I'm not suggesting a different threshold of consensus, = just less indulgence in letting issues play all the way out in hopes of = convergence. Perhaps also an appeal to all WG members to consider the = implications of expressing an opinion on a topic .. Every issue does not = need to be a poll for everyone's opinion.. save it for places where your = opinion makes a material difference to you. (i.e. acknowledge that two = people will disagree on what is a bikeshed vs what is meaningful and = stay out of it in the name of progress if you are on the bikeshed side). These are good suggestions. Instead of the chairs declaring consensus = earlier, we preferred to give the editors a lot of discretion about = merging changes. Maybe the chairs need to become more involved in cases = where there is disagreement amongst some editors. Lars > I have no objection to updating the milestone delivery date to = something more reasonable, but I do think elevating schedule to be a = higher order concern than consensus on the RFC content is wrong. >=20 > I think your second suggestion, scoping around HTTP for v1, is more = likely to get us to a successful finish. As we get later in this = process, it will be more important. >=20 >=20 > * Discussion of anything else (including issues, drafts, proposals) = that doesn't address the needs of HTTP-over-QUIC will be postponed until = after V1 has shipped. >=20 >=20 > Browsing through the archives I actually don't see very many issues = that are totally non-http (certainly < 10%). But there probably are = quite a few that are simpler to resolve if only http is taken into = account. >=20 > -P >=20 --Apple-Mail=_9BAEAC02-3691-46D6-8560-CB8D5515516E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On = 2017-10-27, at 17:13, Patrick McManus <pmcmanus@mozilla.com> wrote:
On Fri, Oct 27, = 2017 at 2:26 AM, Mark Nottingham <mnot@mnot.net> wrote:

To address this, we think two things are necessary:

Just for clarification, you're suggesting these 2 bullets as = updates in some form to the wg charter?
 
1) Our Milestone for delivering the "core" QUIC documents (plus = applicability and manageability statements) to the IESG should be moved = to December 2018, with the understanding that this is a deadline we = intend to meet.

2) V1 of QUIC should *only* address the use case of HTTP.
I haven't synced with Mark on this, but my = personal view is that neither of these affect the charter text. (1) = changes the date of our milestones. (2) is - in my view at least - = already what the charter expresses: it doesn't talk about applications = other than HTTP as something that work is occurring on.

This has a few = implications:

* Proposals for changes that are not realistically achievable in the = timeline of #1 will be rejected on that basis, because the WG has = consensus that the schedule is important.

This needs to be = severely unpacked and I do not support it in the way I'm interpreting = it.

I think the only = way we're going to finish quickly and still create a good product is if = all the participants are focused on getting to yes. A shot clock process = fix isn't going to get a high quality result - we need an attitude fix = :)

Agreed.

The current charter says "Note that consensus is required = both for changes to the current protocol mechanisms and retention of = current mechanisms. In particular, because something is in the initial = document set does not imply that there is consensus  around the = feature or around how it is specified." This remains an important = property for the evolution of IETF QUIC. We need to work through all = the details as a working group.. I think we can do it faster, but not by = inventing an arbitrary forcing = function.

Reading your comment, I can now see how the = original text could be interpreted this way. However, at least my = understanding of what we were trying to express that there is an urgency = to deliver, and we hope that by narrowing the discussion on what is = important for H2 we can avoid going down some ratholes that are = unrelated, or at least avoid going down them quite as = deeply.

But if there are design = choices that the WG has consensus on that are important for H2, and they = would postpone shipping v1 *and* the WG is OK with that, too, then = that's what it'll be. But we should all be conscious of the quality vs. = time tradeoff.

A firm timebox severely undermines the consensus process via = simple gamificiation to 'run out the clock' in favor of existing text. = That is not in the interest of the end result or getting consensus in a = multi-stakeholder process. Indeed it probably increases the chances for = a disastrous last call period. However, getting to yes is in everybody's = interest. That's a much better = motivator.

Full agreement. 

I think a better path would be for = the chairs to more aggressively declare rough consensus at an earlier = stage of discussion than is typically done. I'm not suggesting a = different threshold of consensus, just less indulgence in letting issues = play all the way out in hopes of convergence. Perhaps also an appeal to = all WG members to consider the implications of expressing an opinion on = a topic .. Every issue does not need to be a poll for everyone's = opinion.. save it for places where your opinion makes a material = difference to you. (i.e. acknowledge that two people will disagree on = what is a bikeshed vs what is meaningful and stay out of it in the name = of progress if you are on the bikeshed = side).

These are good suggestions. Instead of the chairs = declaring consensus earlier, we preferred to give the editors a lot of = discretion about merging changes. Maybe the chairs need to become more = involved in cases where there is disagreement amongst some = editors.

Lars

I have no objection to updating = the milestone delivery date to something more reasonable, but I do think = elevating schedule to be a higher order concern than consensus on the = RFC content is wrong.

I think your second suggestion, scoping around HTTP for v1, = is more likely to get us to a successful finish. As we get later in this = process, it will be more important.

 
* Discussion of anything else (including issues, drafts, proposals) that = doesn't address the needs of HTTP-over-QUIC will be postponed until = after V1 has shipped.


Browsing through the archives I actually don't see very many = issues that are totally non-http (certainly < 10%). But there = probably are quite a few that are simpler to resolve if only http is = taken into account.

-P


= --Apple-Mail=_9BAEAC02-3691-46D6-8560-CB8D5515516E-- --Apple-Mail=_05D63C3E-DC0C-4581-AB63-5F78324A0029 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlnzeysACgkQVLXDCb9w wVeI8xAAosJsEZ652+GP9G64gmAwEdX1j61Oa7vJGpqYJi65yRgmS7IrmfAEu1xc RsgVJx4Mjhqvl4ZCWXXzPeRXT0V1cI10iVGQW88SZXb4bbMwRM1B1+ZHETetTUrJ 71PqsUdt/SNplObbc7sfO7n9rajyF5ppeoJbXYg7vjn9YVltEnnaIhKaYS0kRtLM 7BaIygGSltHkHVJiFKMhTrPrTyRA+45AV6ar2rV9mHLGLhAyN1QGd+wRjoTq2CvJ cgLoDm8mk9DH1Qhh0lGQFBx832Xy4TWksy91XmY2diGIh0a07u5pMfNObLbeSC8K JjaLNe60ZGILO4T6m7KBlWZ8MaW87jE2pOxRp7uMVrmdqY6hopgdF+G1t3yQ44Kz k52jP0QosevOEc1GOVpBd2rvg/id+DasXaX41AjjjQrtHkBaAP/I6A+lYwRveygT a3JsUxz/Nkn8Z8TkpxzUHlNWYUVArt+nwZZNkwbjhuY50iLsyOszr8IVmNw01yY+ Kxl531UCTtJH9jrua39hQfVuYItgXUi7/w7AAvj+LWKs0YYEg1xs0MCoT98FuQeB ZrWMn5mWn4G+45bTjUhG5yz69NcMcg1d1I3I0pjBfdyDEy0A0JCOdgYHed6SYIrC LuOfiSLY+CHG0zVKDu3jkf+HtCkWc2XEQ59zdJ5zqdyMA+vN4n0= =pRYe -----END PGP SIGNATURE----- --Apple-Mail=_05D63C3E-DC0C-4581-AB63-5F78324A0029-- From nobody Fri Oct 27 11:35: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 4601213F5BB for ; Fri, 27 Oct 2017 11:35:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 D0pB5D7QEmn3 for ; Fri, 27 Oct 2017 11:35:54 -0700 (PDT) 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 DFBD313A65C for ; Fri, 27 Oct 2017 11:35:53 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.44,304,1505804400"; d="asc'?scan'208,217";a="219192094" Received: from hioexcmbx03-prd.hq.netapp.com ([10.122.105.36]) by mx142-out.netapp.com with ESMTP; 27 Oct 2017 11:06:24 -0700 Received: from VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) by hioexcmbx03-prd.hq.netapp.com (10.122.105.36) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 27 Oct 2017 11:35:53 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.120.60.153) by VMWEXCCAS10-PRD.hq.netapp.com (10.122.105.28) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Fri, 27 Oct 2017 11:35:53 -0700 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=8KYpBLv8gxG9jusiYXpek60Jkg09dF6kIfbIpT+gvaI=; b=RLsD/tMtdNt3vw1jaQNs4ZbbNo/fjvtQqwMKT0WRrQSHmM1E7FjpSq7tURT5BCrzwdY/hdn1aVdsThSTFdhU0fY7Ht+V/iCXyuqmcl+zCQvHnNAdItZqLbG1+CADqZc3yrP1TZvPLd6CvV+dRFDLtP9VSvxNt8XA0R6Q1RUIuas= 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.178.6; Fri, 27 Oct 2017 18:35: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.0178.007; Fri, 27 Oct 2017 18:35:51 +0000 From: "Eggert, Lars" To: Lucas Pardue CC: Mark Nottingham , QUIC WG , "Spencer Dawkins at IETF" Subject: Re: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuylSIJRNvocE0WivHlzUsNNn6L35buAgAAhPYA= Date: Fri, 27 Oct 2017 18:35:50 +0000 Message-ID: <75D920C9-8901-440C-ACC5-6A4B93ED6645@netapp.com> References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3445.1.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2001:a61:3189:6f01:40c:53bf:cda8:32b4] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:heuI7ws6HRY2k+kRRx707ziEQqkg89iWkr1Qk41XHe9FEwmYsMxaY75W0a9772Ak6paSu3RatcN+TB2xi0QwkA4UAkTfXebkKO7zNg6fVccpPvirwXp6Wc9k8g1nQaBJJStgF9y+VLf+mtWY/W9jwtnfTA0Oi7s21G67mYEOjtkv0GBEu2KW89Rn2tmsw5d8n5GVluDyZIn+FD5zSDhaJnY7qo6FIWZimFigr+ePPGlkoUcrnIpuQL9woyIGsgx6MMlbOBTxR2NPKwVInqI80RVZjcp05MwFkA+7L0hEbFwpYVope6XxEDKRshPnfRNPmMrl94yIBq46CKNxxE2fGStyjDipgJb3sDr0o4Mq8VM=; 5:G8rBgo3Xs+c5TtgRztEofS1pkrmqn9SIzKexSlNL7pVtyvpx38jQK1JARakq+Td8VYuZHHeQESIYPDWYD+Aymbo0UHYymI1oVLe3QCemG0crsnNcPeD/KS/mrEG1mj+1LM3DkXvdhhJatKhaJFUE0ggCymA49ToNByqCtzwbbns=; 24:SCAUAfkXVZR0e1FNTNmxQGjgsNrek5K4TQBD11d7vebQK89Z6fAkxm067eEQOIcjdt/a7NwxhnXMQeAdbwrYSyjjO2d3sxvFJgsyDLZwAtY=; 7:9PvUxZ6L9WC56jVs8Gt31y1Tiwtys1URciDiApOnUG0WyH1CH0jBTP5t3LWtXl6TqaXxgwwGyI6hlBy4yzh4OrTQ+ty4AM4oa8fQLix70ExdZPBEKHprE4cAa9xovQoR9FuYqdHOKdm3dXZsPEofMed0mf/siK3lmbobwtiM3kodwkMC6c3GK3WHidKAeMMLnkoNaWelbTmTySLMTFkH//w8ecRwHBS+fE1T4TAPB4v/7X8dBmavmZhPmbBLslEh x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 164469c4-7719-47c7-3a7b-08d51d698c9a x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199)(49563074); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-exchange-antispam-report-test: UriScan:(127952516941037); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3231020)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(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: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(377424004)(199003)(24454002)(189002)(2906002)(106356001)(76176999)(7736002)(105586002)(14454004)(33656002)(189998001)(25786009)(8676002)(86362001)(6506006)(81156014)(77096006)(6486002)(6916009)(3280700002)(101416001)(6436002)(99936001)(3660700001)(478600001)(8936002)(229853002)(81166006)(4326008)(6246003)(102836003)(68736007)(50986999)(5660300001)(6116002)(97736004)(2900100001)(4001150100001)(316002)(39060400002)(54896002)(99286003)(36756003)(2950100002)(83716003)(82746002)(50226002)(53936002)(57306001)(53546010)(54906003)(236005)(6512007); 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=_D2737A04-EEB4-4222-A6E3-C321DBD33484"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 164469c4-7719-47c7-3a7b-08d51d698c9a X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 18:35:50.8451 (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: Fri, 27 Oct 2017 18:35:55 -0000 --Apple-Mail=_D2737A04-EEB4-4222-A6E3-C321DBD33484 Content-Type: multipart/alternative; boundary="Apple-Mail=_5070C984-9152-48EB-88D9-0D3A5828F85E" --Apple-Mail=_5070C984-9152-48EB-88D9-0D3A5828F85E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-10-27, at 18:36, Lucas Pardue wrote: > Can you be more explicit on how your proposals affect the current = Multipath extension document dates? I could infer that the proposed = changes to the core docs are independent of the extension doc, or more = realistically the rescheduling also punts Multipath off another ~6 = months (minimum) or until QUIC V2. What is more aligned with your = current thinking? I'd prefer to not take on multipath as part of v1. I know we have a = milestone about adopting a document on it just about now, but the WG = simply hasn't had the cycles to dive into the topic, and doing so will = IMO definitely delay shipping v1. So my preference would be to push the = multipath milestones back as well. Lars --Apple-Mail=_5070C984-9152-48EB-88D9-0D3A5828F85E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

On = 2017-10-27, at 18:36, Lucas Pardue <Lucas.Pardue@bbc.co.uk> wrote:
Can you be more explicit on how your = proposals affect the current Multipath extension document dates? I could = infer that the proposed changes to the core docs are independent of the = extension doc, or more realistically the rescheduling also punts = Multipath off another ~6 months (minimum) or until QUIC V2. What is more = aligned with your current thinking?

I'd prefer to not take on multipath as part of v1. I know we = have a milestone about adopting a document on it just about now, but the = WG simply hasn't had the cycles to dive into the topic, and doing so = will IMO definitely delay shipping v1. So my preference would be to push = the multipath milestones back as well.

Lars
= --Apple-Mail=_5070C984-9152-48EB-88D9-0D3A5828F85E-- --Apple-Mail=_D2737A04-EEB4-4222-A6E3-C321DBD33484 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAlnzfIUACgkQVLXDCb9w wVcPghAAqarQVoWSGNoGIb6QEUyCD1q1vzHsRz+4Z+FmsRkCjTas8tTowsKmVUC6 xn2uw5vb3kkG4GAuwJYu2spTBryC/0AGdANUf4AzJXtzoer1tLduN3D4qYDgLBTf Gvfe8NjDHv742XLhXif2sfPt9mN04XKfgy/AJGbXE3mMRb69nTeLp58KipCf5khT AxBDEWCTGQPzgo99TlhNMcp3SM23rFTH4J3QZ2hauO3CJCmEJgBXpQBbq2klNTGs QAwmq9I93u7zKHHfJNIjDRicwD1+7S2v9jGnPwigz4RIkqBGDQH4y2lGB+numeRc n1VnYjTHDtLVXM5ZdzHcqHbkqAD8faKKlYNmkniBt4ZVkxk/AOBQXaGEXae2cSUI VKTZt471QSBvIJ3yOrtzDe2DD0K/3dASWs51Lb8VlQJbzjQsyP3aUSojDmt7ZBm1 5oXLqbMKayPbAjSEj2Sd5TKEpIje/MY4vIr+5Y/daSANdVmSCQeX3aPNVGEo42is Oyj4utKhbWIvhfGx5VVkeMHrHRquYdVFT34AjQkLTUybjMAetbl/tMp5592KVkuW +4vkajsl1FSJPNArwgbLNIx2AXUlCaYErbdILJjaRsWhHUOE6seh+P5ec7NY5Oei gGhZiDR6H+DlRM/Xtps/73M9gUZ1R2zDXHMMYcGdZPWxA1vGYfQ= =0NdE -----END PGP SIGNATURE----- --Apple-Mail=_D2737A04-EEB4-4222-A6E3-C321DBD33484-- From nobody Fri Oct 27 12:13: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 811FD13F5C1 for ; Fri, 27 Oct 2017 12:13:22 -0700 (PDT) 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 EigTvRTXMpaj for ; Fri, 27 Oct 2017 12:13:20 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 3122213F42B for ; Fri, 27 Oct 2017 12:13:20 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v9RJDECf001000; Fri, 27 Oct 2017 21:13:14 +0200 Date: Fri, 27 Oct 2017 21:13:14 +0200 From: Willy Tarreau To: Patrick McManus Cc: Mark Nottingham , QUIC WG , Lars Eggert , Spencer Dawkins at IETF Subject: Re: QUIC - Our schedule and scope Message-ID: <20171027191314.GA997@1wt.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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, 27 Oct 2017 19:13:22 -0000 On Fri, Oct 27, 2017 at 11:13:42AM -0400, Patrick McManus wrote: > A shot > clock process fix isn't going to get a high quality result - we need an > attitude fix :) I agree. It's also important to keep in mind that there are periods in the year where people are more busy by their work than other periods and this can give the impression that everything stalls, but participating less does not necessarily imply not thinking to come back later with clearer views or more willingness to accept others' proposals. > I think a better path would be for the chairs to more aggressively declare > rough consensus at an earlier stage of discussion than is typically done. > I'm not suggesting a different threshold of consensus, just less indulgence > in letting issues play all the way out in hopes of convergence. Perhaps > also an appeal to all WG members to consider the implications of expressing > an opinion on a topic . That's exactly what I was thinking as well. I'm fine with delaying a release for a very good reason, but in general very good reasons more easily achieve a rough consensus. It's the same with accepting not to delay because the reason is not very good. If all WG members keep in mind that they take a responsibility for delaying stuff by opening issues, it can get better. > I have no objection to updating the milestone delivery date to something > more reasonable, but I do think elevating schedule to be a higher order > concern than consensus on the RFC content is wrong. Agreed as well, we all know a few minor design mistakes that ended up in H2 and HPACK for the sole reason that we stubbornly refused to play with a few bits at the end. It makes none of us suffer, but it makes implementations slightly more painful to write and the protocol slightly less efficient. I tend to consider that important design must be defined first and that small variations must be considered at the end. But we must just accept the fact that a deployed beta version doesn't count as a good reason for not fixing the last bits at the end, otherwise everyone will still bikeshed to ensure the small bits that matter to them are committed first to prevent the H2 process from happening again. > I think your second suggestion, scoping around HTTP for v1, is more likely > to get us to a successful finish. As we get later in this process, it will > be more important. I think it's reasonable as well, it's hard to try to design for everything at once, especially in such a very new area. > > * Discussion of anything else (including issues, drafts, proposals) that > > doesn't address the needs of HTTP-over-QUIC will be postponed until after > > V1 has shipped. In fact we should start to speak about QUICv1 (Q1?) and not QUIC to make this clear for everyone. Just my two cents, Willy From nobody Fri Oct 27 14:29: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 80BB7139567 for ; Fri, 27 Oct 2017 14:29:41 -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, 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 uZCOdGXrdd0Y for ; Fri, 27 Oct 2017 14:29:39 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3AE13875A for ; Fri, 27 Oct 2017 14:29:39 -0700 (PDT) X-AuditID: c1b4fb2d-bddff7000000268d-eb-59f3a54196b2 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A0.A8.09869.145A3F95; Fri, 27 Oct 2017 23:29:37 +0200 (CEST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.45) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 27 Oct 2017 23:29:36 +0200 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=VkdEy2zJay6Qjvg4qCU3zsNJ2mMcCntzN0XL7fwy0pw=; b=OLu+KpnGGTsYBjz5YFXq7/0n8ljxuDQmzQWGiFdGmluAFIWtV90/4sQ14OmdlUtCbzI/krRKn0YYZrqtRrxB9/XhsozSkZfjKn+Z3rizFgkeMqMk04IsvnSpqrXb8yp74JyQIsyUmQ/7d9tOb2yoy4eJxaICedu/3Am9+yDYsNM= Received: from DB6PR07MB3256.eurprd07.prod.outlook.com (10.175.233.27) by DB6PR07MB3254.eurprd07.prod.outlook.com (10.175.233.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.197.4; Fri, 27 Oct 2017 21:29:35 +0000 Received: from DB6PR07MB3256.eurprd07.prod.outlook.com ([fe80::cd0f:2aca:8b7b:14a]) by DB6PR07MB3256.eurprd07.prod.outlook.com ([fe80::cd0f:2aca:8b7b:14a%13]) with mapi id 15.20.0197.004; Fri, 27 Oct 2017 21:29:35 +0000 From: =?utf-8?B?R8O2cmFuIEVyaWtzc29uIEFQ?= To: Patrick McManus , Mark Nottingham CC: QUIC WG , Lars Eggert , "Spencer Dawkins at IETF" Subject: Re: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuy0G2Gng6rmDU2bUSkBtkiT4aL3zn8AgABpBAA= Date: Fri, 27 Oct 2017 21:29:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-GB 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=goran.ap.eriksson@ericsson.com; x-originating-ip: [78.70.160.3] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB6PR07MB3254; 6:Fe7o+CZsrL/VOrN52Kr/DREsaQqNUxZz5IV/QVzm7qKBlct0dNUGjHVUKHzOjhLvDm5k251A5aITt4R/67R24PNjevLXt9VXnyGwm2TkOmmtRpt3EqVwKIKdIM7+WGZtFX1+gPJUoXuaPbBg2pNPwch2ifiX8xsVL2Xy74/T42ZCUNzAgX3kV5kCuNXkrMaNtT0Tp2xs4RC5g0hUCRdv5fPuIo0XYkC/ZPc+XV+o80OLjXJBWNHTQGptWGiyZ0MiVBmAs3JQ8L+hOVJA5GgVL5XHLXvz3+8qcY+zy/2lDnv4fTBreGeewbj6btBj5EVx9RCBJDZQL0dp1RqeCsv9i1vaOcKS9OHaV5S39cxISy4=; 5:vwxTd8lcRV7acRdV6EmJ/zthoc+kEk+UIfEBO6TgpmmJuBe/UaGZLHvigr0yPbJIGqq2ZBJKpAsMOWtt8oy+FxAXO5CGF4IetgZ0u7yuzxTHQ91VqgNBQF+3dJAQxSABUyzrcNuMeCeSeAg6PRsEkC9J9FLNNqVGbgaDnibgwWg=; 24:S3KbsaLVagvrZJ+kFwik6NaqF7ICEZVIrJR5ffGXpnwIKLeXvE562RY3MimMdgKBDFIASzQQjKVb4jMvhWItZoDbCLzeoX6Irm+GQZ+kQ/k=; 7:Tbz9Pn3py5JLM0dmfaorjeGVDR0VzZJMDpbLF+UZpGmwfbyMfLMUV8TPRo1I8O9ylIDdXnyb2ZNOidOPy+WYnuJi1oAI0mUka6kkgOQ/KjACNqS16e0aHrn94BV3kdJIFU5T6E0iFGbQNRfN7WCcOJhBE9e06FIQ5X6PdwDRHyG2j0QxAQl3itNWbHtURc37c7nMDUFHK3JMUzgZOwn4w07bdMD/aOhra8BlGay55nqIlTLDMrUMO+87BQ1GQImV x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 5fc27105-55ad-4b15-a540-08d51d81d20f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:DB6PR07MB3254; x-ms-traffictypediagnostic: DB6PR07MB3254: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); 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)(100000703101)(100105400095)(3231020)(3002001)(10201501046)(6041248)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123555025)(20161123560025)(20161123562025)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB6PR07MB3254; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB6PR07MB3254; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(39860400002)(24454002)(199003)(377424004)(189002)(66066001)(81156014)(8676002)(81166006)(3280700002)(229853002)(97736004)(39060400002)(85182001)(50986999)(54356999)(2906002)(82746002)(83716003)(86362001)(5250100002)(14454004)(316002)(54906003)(110136005)(8936002)(53546010)(5660300001)(76176999)(83506002)(58126008)(25786009)(53936002)(478600001)(102836003)(6306002)(6116002)(3846002)(6486002)(33656002)(9326002)(36756003)(101416001)(68736007)(6436002)(189998001)(6512007)(4326008)(4001150100001)(54896002)(6246003)(2900100001)(3660700001)(99286003)(105586002)(236005)(7736002)(85202003)(106356001)(6506006)(2950100002); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3254; H:DB6PR07MB3256.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_EBE78B5480734C8C96FF271DCAB60CB8ericssoncom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5fc27105-55ad-4b15-a540-08d51d81d20f X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 21:29:35.3614 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3254 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTYRTHee7L7nU5elyaJ6PU9UJOXFp+GCLmIHFkptELGoENvampU3aX Zh9CJIeoiZZYSqHpDF8C00ytJG2FqBm+FKRpiFmpaVAqrDSr3d0Ffvudc/7nf54/PCwpH6Y9 2GS9kTPodakKiZSqiOnw89PULcf6j1f5qOcWiih189IMUnd3rTPqoupN6ntlXWQorX1c+YHR ms2/CG1LrZXWFvcU0NpbSyuSaPqMNDiBS03O5Az7Q85Jk6ZGxokMc/ilmqU8JgfVhhUgJxZw IDyt+UEXICkrxy8RNJjqkFj0IRj50SERCgpfI2FsapURJ+UETPetOGTTCF69n6IFMwmOANPV F5TArjbuN/UjgUmcBd2znYTAW7ASVk0rNlvWpvGF2YJsUR4EvYtrpMAU3gP5v8fsLMOH4OdA KSXeykUw/a7Y7uOEj8NMh4URGOGtYB24T4i33CF3pYEWw2Ewdw2RIrvB/Mwfe98Nq2Ctd96x q4PCnF5G1HhC42QFIfIOGK0qtIcEbGGgt+EhEgcqeFT6DQkBAEfCYI1ERD0MjnmJCiVYc687 LCPg680vjs0UWH/zgBAt39LwfWqdKEGqyg3PFjkeJkbHmUp7fhfor/hEVdpOkNgHmp/sFyXe UFY4zYi8D/Ju33GwFto+32U2aqoR24jceI7n0xIPHFRxhuR4nk/Xq/ScsRXZ/tnztjW/TtS0 oLEgzCKFs2ygdDlWTusy+ew0CwKWVLjKhtNtLVmCLvsyZ0iPM1xM5XgL2s5SCndZ6LPhGDlO 1Bm5FI7L4Az/pwTr5JGDNG35n7yafE7v0f/t8Dmj2Y0Dgies5WXNJYMaeci+BM/6w9LwpydP sX2b+6PdFs2DvlktVFBL3Odjylb/qEcT7lFndzWWbS8+OtTsvHcL89q6PNvTuhpU7xsYtrPh xLaSyPkTSe2H2ovDriiNbx/euPAx3sPlyKao896jcxmjIZN5iwqKT9IFKEkDr/sH9tXHiGMD 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: Fri, 27 Oct 2017 21:29:41 -0000 --_000_EBE78B5480734C8C96FF271DCAB60CB8ericssoncom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCkJlaW5nIGEga2VlbiBsaXN0ZW5lciBhbmQgb2JzZXJ2ZXIgb2YgUVVJQyBXRyAoc28g ZmFyIHBhc3NpdmVseSksIGFuZCBzb21lb25lIGl0Y2hpbmcgdG8gbW92ZSBvbiB0byBhcHBseSBh ICJRVUlDdjEiIGluIGRpZmZlcmVudCBjb250ZXh0cyBhcyB3ZWxsIGFzIHRha2luZyB0aGUgbmV4 dCBzdGVwcywgc3VjaCBhcyBtdWx0aXBhdGggYW5kIFJUQ1dFQiwgV2ViU29ja2V0IGFuZCBnUlBD b25RVUlDLCBnZXR0aW5nIGEgIlFVSUN2MSIgd2l0aCBIVFRQIFJGQyBpbiBwbGFjZSBpcyB2ZXJ5 IGRlc2lyYWJsZS4gSWYgd2UgZmFpbCB0byBkZWxpdmVyIGEgInYxIiwgdGhlbiBRVUlDIGZ1dHVy ZSBjb3VsZCBwZXJoYXBzIGJlIHNlZW4gYnkgc29tZSB0byBiZSBpbiBkb3VidCwgYW5kIHRoaXMg bm90IGEgZ29vZCBzaWduYWwgdG8gc2VuZC4NCg0KSSBzdXBwb3J0IHRoZSBjaGFpcnMgaW50ZW50 IGFuZCBmaW5kIFBhdHJpY2sgdmlld3MgdmVyeSBjb252aW5jaW5nLiBJbiBzaG9ydDoNCg0KLSBF eHByZXNzIGludGVudCB0byB0YXJnZXQgZW9mIDIwMTggd2l0aCAiUVVJQ3YxIiBmb2N1cyBhcyBh IHNpZ25hbCB0byBXRyBtZW1iZXJzIHRvIGZvY3VzLg0KLSBMaW1pdCBzY29wZSB0byBIVFRQIG9u IFFVSUMuDQotIEEgc3Ryb25nICsxIG9uIE1jTWFudXMgY29tbWVudHMgb24gY2hhaXIgYWN0aW9u cy4NCg0KQmVzdCBSZWdhcmRzDQpHw7ZyYW4NCg0KT24gMjAxNy0xMC0yNywgMTc6MTQsICJRVUlD IG9uIGJlaGFsZiBvZiBQYXRyaWNrIE1jTWFudXMiIDxxdWljLWJvdW5jZXNAaWV0Zi5vcmc8bWFp bHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIHBtY21hbnVzQG1vemlsbGEu Y29tPG1haWx0bzpwbWNtYW51c0Btb3ppbGxhLmNvbT4+IHdyb3RlOg0KDQpJIHRoaW5rIGEgYmV0 dGVyIHBhdGggd291bGQgYmUgZm9yIHRoZSBjaGFpcnMgdG8gbW9yZSBhZ2dyZXNzaXZlbHkgZGVj bGFyZSByb3VnaCBjb25zZW5zdXMgYXQgYW4gZWFybGllciBzdGFnZSBvZiBkaXNjdXNzaW9uIHRo YW4gaXMgdHlwaWNhbGx5IGRvbmUuIEknbSBub3Qgc3VnZ2VzdGluZyBhIGRpZmZlcmVudCB0aHJl c2hvbGQgb2YgY29uc2Vuc3VzLCBqdXN0IGxlc3MgaW5kdWxnZW5jZSBpbiBsZXR0aW5nIGlzc3Vl cyBwbGF5IGFsbCB0aGUgd2F5IG91dCBpbiBob3BlcyBvZiBjb252ZXJnZW5jZS4gUGVyaGFwcyBh bHNvIGFuIGFwcGVhbCB0byBhbGwgV0cgbWVtYmVycyB0byBjb25zaWRlciB0aGUgaW1wbGljYXRp b25zIG9mIGV4cHJlc3NpbmcgYW4gb3BpbmlvbiBvbiBhIHRvcGljIC4uIEV2ZXJ5IGlzc3VlIGRv ZXMgbm90IG5lZWQgdG8gYmUgYSBwb2xsIGZvciBldmVyeW9uZSdzIG9waW5pb24uLiBzYXZlIGl0 IGZvciBwbGFjZXMgd2hlcmUgeW91ciBvcGluaW9uIG1ha2VzIGEgbWF0ZXJpYWwgZGlmZmVyZW5j ZSB0byB5b3UuIChpLmUuIGFja25vd2xlZGdlIHRoYXQgdHdvIHBlb3BsZSB3aWxsIGRpc2FncmVl IG9uIHdoYXQgaXMgYSBiaWtlc2hlZCB2cyB3aGF0IGlzIG1lYW5pbmdmdWwgYW5kIHN0YXkgb3V0 IG9mIGl0IGluIHRoZSBuYW1lIG9mIHByb2dyZXNzIGlmIHlvdSBhcmUgb24gdGhlIGJpa2VzaGVk IHNpZGUpLg0K --_000_EBE78B5480734C8C96FF271DCAB60CB8ericssoncom_ Content-Type: text/html; charset="utf-8" Content-ID: <76436AB397E1BB4E94BAAC9DB73ACC93@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eTotd2Via2l0LXN0YW5kYXJkOw0KCXBhbm9zZS0xOjAgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29O b3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlu a0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjU5 NS4wcHQgODQyLjBwdDsNCgltYXJnaW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9 DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8 L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZs aW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+SGksPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMi PkJlaW5nIGEga2VlbiBsaXN0ZW5lciBhbmQgb2JzZXJ2ZXIgb2YgUVVJQyBXRyAoc28gZmFyIHBh c3NpdmVseSksIGFuZCBzb21lb25lIGl0Y2hpbmcgdG8gbW92ZSBvbiB0byBhcHBseSBhICZxdW90 O1FVSUN2MSZxdW90OyBpbiBkaWZmZXJlbnQgY29udGV4dHMgYXMgd2VsbCBhcyB0YWtpbmcgdGhl IG5leHQgc3RlcHMsIHN1Y2ggYXMgbXVsdGlwYXRoIGFuZA0KIFJUQ1dFQiwgV2ViU29ja2V0IGFu ZCBnUlBDb25RVUlDLCBnZXR0aW5nIGEgJnF1b3Q7UVVJQ3YxJnF1b3Q7IHdpdGggSFRUUCBSRkMg aW4gcGxhY2UgaXMgdmVyeSBkZXNpcmFibGUuIElmIHdlIGZhaWwgdG8gZGVsaXZlciBhICZxdW90 O3YxJnF1b3Q7LCB0aGVuIFFVSUMgZnV0dXJlIGNvdWxkIHBlcmhhcHMgYmUgc2VlbiBieSBzb21l IHRvIGJlIGluIGRvdWJ0LCBhbmQgdGhpcyBub3QgYSBnb29kIHNpZ25hbCB0byBzZW5kLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVT Ij5JIHN1cHBvcnQgdGhlIGNoYWlycyBpbnRlbnQgYW5kIGZpbmQgUGF0cmljayB2aWV3cyB2ZXJ5 IGNvbnZpbmNpbmcuIEluIHNob3J0OjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4tIEV4cHJlc3MgaW50ZW50IHRvIHRhcmdldCBl b2YgMjAxOCB3aXRoICZxdW90O1FVSUN2MSZxdW90OyBmb2N1cyBhcyBhIHNpZ25hbCB0byBXRyBt ZW1iZXJzIHRvIGZvY3VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+LSBMaW1pdCBzY29w ZSB0byBIVFRQIG9uIFFVSUMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPi0gQSBzdHJv bmcgJiM0MzsxIG9uIE1jTWFudXMgY29tbWVudHMgb24gY2hhaXIgYWN0aW9ucy48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+QmVz dCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5Hw7ZyYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt bGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjM2LjBwdCI+T24gMjAx Ny0xMC0yNywgMTc6MTQsICZxdW90O1FVSUMgb24gYmVoYWxmIG9mIFBhdHJpY2sgTWNNYW51cyZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnF1aWMtYm91bmNlc0BpZXRmLm9yZyI+cXVpYy1ib3Vu Y2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpwbWNtYW51c0Bt b3ppbGxhLmNvbSI+cG1jbWFudXNAbW96aWxsYS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1sZWZ0OjM2LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDozNi4wcHQiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTMuNXB0O2ZvbnQtZmFtaWx5OiZxdW90Oy13ZWJraXQtc3RhbmRhcmQmcXVvdDss c2VyaWY7Y29sb3I6YmxhY2siPkkgdGhpbmsgYSBiZXR0ZXIgcGF0aCB3b3VsZCBiZSBmb3IgdGhl IGNoYWlycyB0byBtb3JlIGFnZ3Jlc3NpdmVseSBkZWNsYXJlIHJvdWdoIGNvbnNlbnN1cyBhdCBh biBlYXJsaWVyIHN0YWdlIG9mIGRpc2N1c3Npb24gdGhhbg0KIGlzIHR5cGljYWxseSBkb25lLiBJ J20gbm90IHN1Z2dlc3RpbmcgYSBkaWZmZXJlbnQgdGhyZXNob2xkIG9mIGNvbnNlbnN1cywganVz dCBsZXNzIGluZHVsZ2VuY2UgaW4gbGV0dGluZyBpc3N1ZXMgcGxheSBhbGwgdGhlIHdheSBvdXQg aW4gaG9wZXMgb2YgY29udmVyZ2VuY2UuIFBlcmhhcHMgYWxzbyBhbiBhcHBlYWwgdG8gYWxsIFdH IG1lbWJlcnMgdG8gY29uc2lkZXIgdGhlIGltcGxpY2F0aW9ucyBvZiBleHByZXNzaW5nIGFuIG9w aW5pb24gb24NCiBhIHRvcGljIC4uIEV2ZXJ5IGlzc3VlIGRvZXMgbm90IG5lZWQgdG8gYmUgYSBw b2xsIGZvciBldmVyeW9uZSdzIG9waW5pb24uLiBzYXZlIGl0IGZvciBwbGFjZXMgd2hlcmUgeW91 ciBvcGluaW9uIG1ha2VzIGEgbWF0ZXJpYWwgZGlmZmVyZW5jZSB0byB5b3UuIChpLmUuIGFja25v d2xlZGdlIHRoYXQgdHdvIHBlb3BsZSB3aWxsIGRpc2FncmVlIG9uIHdoYXQgaXMgYSBiaWtlc2hl ZCB2cyB3aGF0IGlzIG1lYW5pbmdmdWwgYW5kIHN0YXkgb3V0IG9mDQogaXQgaW4gdGhlIG5hbWUg b2YgcHJvZ3Jlc3MgaWYgeW91IGFyZSBvbiB0aGUgYmlrZXNoZWQgc2lkZSkuPC9zcGFuPjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_EBE78B5480734C8C96FF271DCAB60CB8ericssoncom_-- From nobody Fri Oct 27 15:54: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 1868913F5FA for ; Fri, 27 Oct 2017 15:54:44 -0700 (PDT) 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=aXHw9+lj; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=BdR5PQDU Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r38XqRVqgpDX for ; Fri, 27 Oct 2017 15:54:41 -0700 (PDT) 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 01A011397F3 for ; Fri, 27 Oct 2017 15:54:41 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 3F2B52064E; Fri, 27 Oct 2017 18:54:40 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 27 Oct 2017 18:54:40 -0400 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=wDoShxZa3v5Zfy+n4C4UOtijcwtca 3o08S/W4v8+H2Q=; b=aXHw9+lj7FmG37nphtq1HE1vXvqQGm2Uayrzj3YIPN3ZS Af2+pAX6SieB4WfOumqQ1tMSEfIZu//CawGUdDI9VQJatPinnimHwBwdtP56NIto vTMSlH08kwgYcNo/8k+LP2lrW/EVeu3iw+ZjniBDbYfhkPAt+xJw+MU0P8wyN3Nb MbTCrp1vWTAu+V2Lk8MVJpL9uiVQyS7k/1Jpr0CGo5qY5/yjVZtxD9bgCLTp6H/N DiWjhMcjQKabt1Xutzh4vVzt1yurgfcQH9xbRX2bl4WSayDKRfiee8J1UZUSnS06 dSkDQ/AtYWT4feaRPfrLgM7jo5u+21H46D5W9jsSw== 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=wDoShx Za3v5Zfy+n4C4UOtijcwtca3o08S/W4v8+H2Q=; b=BdR5PQDUhN61R7bg+6UH7v qtMhZZlN8dzBJFWKTCt7EEpAWZl2LObErVVkhliuURS34szsUafTQTASEafFCS2o dyxuFLfUaTZHBrVdnZWqQeo1iUeQJn9cr8hcBYJJtA36rXyebYLpKOhbEviDG3T0 HGo1F3G+1IE9HmNyIWU7slFy7kdhIAVre8WKaMJTrWcAXmc9ry6V0oMOYfF2EjNr 7LagyN/Uq/Ud2rVTZiW1eZheE6IYjXJHSivQ/JA59FhBdMvEVumRdrVshCj4EZYv y7BAtHavB+HkLMs4AhbhPVYOt0N9YC5TB7ZtIJYeJROtvD/0qRSxdO/Jqu92DPog == 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 907237FA81; Fri, 27 Oct 2017 18:54:38 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: QUIC - Our schedule and scope From: Mark Nottingham In-Reply-To: Date: Sat, 28 Oct 2017 09:54:34 +1100 Cc: QUIC WG , Lars Eggert , Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <52293976-62BE-4420-B0D1-27BAE3A3A556@mnot.net> References: To: Patrick McManus X-Mailer: Apple Mail (2.3445.1.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: Fri, 27 Oct 2017 22:54:44 -0000 Hi Patrick, > On 28 Oct 2017, at 2:13 am, Patrick McManus = wrote: >=20 > Hi All, >=20 > First, the observation that elapsed time impacts participation and = participation impacts quality is a good observation. Finishing faster (I = personally want to go way way faster) is consistent with that and we = should look at how we're organized to help make that a reality. Thanks = for doing that. >=20 > I'm also not quite as pessimistic as the chairs are. I don't really = think this is a linear process - as we get more input from more = implementations I think the process will naturally accelerate. The = challenge at that later stage will be on not re-opening issues that we = have reached consensus on. That's different than the challenge we've = been going through for the last year; for the last year we've been = building up the basic blocks from an explicitly 0-consensus starting = point. Its both not surprising, and a good thing, that many issues have = been given scrutiny during that phase. >=20 >=20 > On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham = wrote: >=20 >> To address this, we think two things are necessary: >=20 > Just for clarification, you're suggesting these 2 bullets as updates = in some form to the wg charter?=20 The milestones are a charter update, but chairs can submit revised = milestones with approval by the AD, as always.=20 I don't think (2) requires a charter update, but if that makes people = more comfortable, we can talk about it. >> 1) Our Milestone for delivering the "core" QUIC documents (plus = applicability and manageability statements) to the IESG should be moved = to December 2018, with the understanding that this is a deadline we = intend to meet. >>=20 >> 2) V1 of QUIC should *only* address the use case of HTTP. >>=20 >> This has a few implications: >>=20 >> * Proposals for changes that are not realistically achievable in the = timeline of #1 will be rejected on that basis, because the WG has = consensus that the schedule is important. >=20 > This needs to be severely unpacked and I do not support it in the way = I'm interpreting it. Understood. We anticipated some discussion. :) > I think the only way we're going to finish quickly and still create a = good product is if all the participants are focused on getting to yes. A = shot clock process fix isn't going to get a high quality result - we = need an attitude fix :) I agree, and that's a better way to say it. Thanks. For those who weren't there, HTTP/2 had a similar focus on "getting to = yes", through an understanding that our milestones were serious. It was = not "consensus at any cost", it was an agreement that we wanted to ship = something we agreed on in a reasonable amount of time. That agreement = informed the decisions of individual WG participants -- but in a = positive way, as you outline. > The current charter says "Note that consensus is required both for = changes to the current protocol mechanisms and retention of current = mechanisms. In particular, because something is in the initial document = set does not imply that there is consensus around the feature or around = how it is specified." This remains an important property for the = evolution of IETF QUIC. We need to work through all the details as a = working group.. I think we can do it faster, but not by inventing an = arbitrary forcing function. >=20 > A firm timebox severely undermines the consensus process via simple = gamificiation to 'run out the clock' in favor of existing text. That is = not in the interest of the end result or getting consensus in a = multi-stakeholder process. Indeed it probably increases the chances for = a disastrous last call period. However, getting to yes is in everybody's = interest. That's a much better motivator. If you see someone acting strategically like that, please bring it to = our attention; it indicates participation in bad faith, and will need to = be dealt with. > I think a better path would be for the chairs to more aggressively = declare rough consensus at an earlier stage of discussion than is = typically done. I'm not suggesting a different threshold of consensus, = just less indulgence in letting issues play all the way out in hopes of = convergence. Perhaps also an appeal to all WG members to consider the = implications of expressing an opinion on a topic .. Every issue does not = need to be a poll for everyone's opinion.. save it for places where your = opinion makes a material difference to you. (i.e. acknowledge that two = people will disagree on what is a bikeshed vs what is meaningful and = stay out of it in the name of progress if you are on the bikeshed side). >=20 > I have no objection to updating the milestone delivery date to = something more reasonable, but I do think elevating schedule to be a = higher order concern than consensus on the RFC content is wrong. To be clear -- this does not magically give the chairs the ability to = ignore or circumvent the process. We can't elevate anything higher than = consensus. We're asking for the WG to gain consensus that it wants to take the = milestone seriously, to inform its further discussions. We'll still need = to gather consensus on other things, and if the WG forms a new consensus = that a particular proposal merits exceeding the milestone, it can do so. = And of course we'll still need to gain consensus on what we put in the = documents (and what we leave out). > I think your second suggestion, scoping around HTTP for v1, is more = likely to get us to a successful finish. As we get later in this = process, it will be more important. >=20 > =20 >> * Discussion of anything else (including issues, drafts, proposals) = that doesn't address the needs of HTTP-over-QUIC will be postponed until = after V1 has shipped. >=20 > Browsing through the archives I actually don't see very many issues = that are totally non-http (certainly < 10%). But there probably are = quite a few that are simpler to resolve if only http is taken into = account. Indeed. -- Mark Nottingham https://www.mnot.net/ From nobody Fri Oct 27 15:55: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 312C91397F3 for ; Fri, 27 Oct 2017 15:55:34 -0700 (PDT) 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=Jf38bD3N; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=dvFmd75p Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8IY70Df2MHo for ; Fri, 27 Oct 2017 15:55:32 -0700 (PDT) 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 8D2C8139394 for ; Fri, 27 Oct 2017 15:55:32 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EA04720CB3; Fri, 27 Oct 2017 18:55:31 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 27 Oct 2017 18:55:31 -0400 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=vzelNtGkSrIi5DoiJboFNsFGAHK55 AS7uPSbBsPqI/U=; b=Jf38bD3NRlXDInDszXU/I5DJWrGUawVpfSJjm5ZpaqlqZ SbkT2ME9/VbnIirPQuoYp/EbGSZ4w84Sbf62aMuJHVd1FH+Qq7vEP0EBA26V0/Kt jjGrdRrdqlD7gxGe+D/la6o69nR0DA8C9aLsw/9JoAUqnYoBfurBealiLs5Be844 kghzUbJ6dufmAhFb6g3mGeEVl/a3GGs7zyGXwsFNdb5rF7vaG/qZqRQJmUJ6yk50 o3C5OflG4qlUoqI+UfI9EXGBeG9I/ToCM7mLbdlRZ+zUn56ah7CfBJ9jNp8fnaYS FKMBh28zZAR+mTCWoIzmymPufddta+N1YOXEwC6/Q== 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=vzelNt GkSrIi5DoiJboFNsFGAHK55AS7uPSbBsPqI/U=; b=dvFmd75pBSUsG7VyGucuCV 7Wolg9oaWpxcldArlG+NIDizvDIhyd3Oxj953cxWkvXOyEEAypyIS3oZgq/l7dRq 05PIdV7ZLZC5sebzy5vD8amFCQK3d8JokSStLRs7Cr+bvnGIqv+Is7bIBKqk/Ybd Dd8Vij/j9vfRyEavzjD8RLFpoetXWAiCOc+jt509R7uovWt0SfgsVXt5JuNcvoZI j217a2XAIw28UFyTQ8vnszGDWaPd1sW+OTRftv3xrCS5e4YrH4aiNg/8c7WWwMs5 QT2q3T7enZ/mX7YvZ4VQzywcEmbmDdNK3Uu87QGMqyPyn6N4SZtgEzpYM/noPRgw == 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 882917F96B; Fri, 27 Oct 2017 18:55:30 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: QUIC - Our schedule and scope From: Mark Nottingham In-Reply-To: <17E462A6-FC87-47BA-8B31-88D47F8378E9@akamai.com> Date: Sat, 28 Oct 2017 09:55:29 +1100 Cc: QUIC WG , Lars Eggert , Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <5B4934A8-310F-40DE-9F69-0E23AC49C15D@mnot.net> References: <17E462A6-FC87-47BA-8B31-88D47F8378E9@akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.3445.1.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: Fri, 27 Oct 2017 22:55:34 -0000 Hi Rich, > On 28 Oct 2017, at 3:20 am, Salz, Rich wrote: >=20 > You might also want to consider what TLS 1.3 is going through and = allow an escape hatch if you=E2=80=99ve got a good protocol but current = Internet conditions prevent it from getting acceptably-wide deployment. = And then, the follow-on question: what *would* be an acceptable level of = interference/blockage =E2=80=93 1, 5, 10%? Doubtless we'll deal with that if and when it comes.=20 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Oct 27 15:57: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 1715E1397F3 for ; Fri, 27 Oct 2017 15:57:37 -0700 (PDT) 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=CUxKLPkJ; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ACb5WSbT Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Qs_zjNAe_bn for ; Fri, 27 Oct 2017 15:57:35 -0700 (PDT) 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 82DB1139394 for ; Fri, 27 Oct 2017 15:57:35 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id E068C20B60; Fri, 27 Oct 2017 18:57:34 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 27 Oct 2017 18:57:34 -0400 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=3ORuFrACHCR3tGRb3i85h8YTWdvxY jOO6A1EABAKyWo=; b=CUxKLPkJdc0l/xinnDXiQFBvHN8l11VSExZyBQdr8UldZ Q7n/bq38utnswe4/EVIzGfTLY2DA/llTmZAgs1j5B3pgEo/TyuuITQjPCFCvbsku 9v1//Y46ODzrjxHPs7AYKQlZHQJ3zMao5St7q+a9LoRPDnUwQAHJT+B09Z1DUMOv 5Y5EMZytG3e2DT5jPapBPGtshnk9cXLCLi06S2EzBbJa+MbdAyFJMWPdw6DmrTQN WuhDzI+NfafRl9G0/maeMXsOx8gJMetVpa096lk+M0AXiOxWIyRhSZFT7ENSV1O6 tQJzgSQf/m4y6LsirNCWRN0Sxv7IxcRjvOntGn5gA== 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=3ORuFr ACHCR3tGRb3i85h8YTWdvxYjOO6A1EABAKyWo=; b=ACb5WSbTX3TyU39/uNNXUD IXgI0B+KiwbInBE0PAhd1OznT4Cvjb1kO4yibv5QiEp7M3U6OIecar0h1v8FzeZl Rrh7WSu3neI3EPflTI/xLIm3npIEzf0YPLU5NbvXfGp5lpSVHYMlSEaV236LlMNp hREScaSqvGBQegUir6J9GUQq1kYxKnZiO0rzEmOODxpoEXV3hNQs27EYdtnj8bR+ MWcpFaAj+lsRkCG4O5A+p0Wk4JzxhhorZoB8CznhMfv3YENiQ5SlVJtbbFTj887f gBH5G3mQyr5/uZrTJiVdeP/MjDuOG8SUW9w3DuV8jeBlzPAXoRvq8khuENq+lMAw == 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 7C71A7E13B; Fri, 27 Oct 2017 18:57:33 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: QUIC - Our schedule and scope From: Mark Nottingham In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> Date: Sat, 28 Oct 2017 09:57:30 +1100 Cc: QUIC WG , Lars Eggert , Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> To: Lucas Pardue X-Mailer: Apple Mail (2.3445.1.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: Fri, 27 Oct 2017 22:57:37 -0000 Hi Lucas, > On 28 Oct 2017, at 3:36 am, Lucas Pardue = wrote: >=20 > To date, I've tried to avoid mentioning Multipath on list and bring it = up now only as it relates to the WG Charter Milestones. >=20 > Can you be more explicit on how your proposals affect the current = Multipath extension document dates? I could infer that the proposed = changes to the core docs are independent of the extension doc, or more = realistically the rescheduling also punts Multipath off another ~6 = months (minimum) or until QUIC V2. What is more aligned with your = current thinking? I think multipath would remain a post-V1 activity, which implies that = the dates would be pushed out. Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Fri Oct 27 16:52: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 E9AD013AF2F for ; Fri, 27 Oct 2017 16:52:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_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 gIovvJPRtF89 for ; Fri, 27 Oct 2017 16:52:31 -0700 (PDT) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0137.outbound.protection.outlook.com [104.47.41.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E30713F487 for ; Fri, 27 Oct 2017 16:52:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=51kDdC1ACXTjh8fU7/s8GYDFJZ8apOGvdGS+hxo4+uY=; b=DnMsHdluS2L6OTTyyM7z2H/hFEEMPrVPjfRsk/LYpbvHF9uGvctMjhwV82P1RbC3my+EOH7uryUKJ7tGVx46wJN2uk/krwiV5L2Bq1FxlE/vGp0p3wwYg9L2c60y4s4g75uonS7kBH0R7Ns0ri3PPXeuhhGYMrCJ5gwqOptN900= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.197.0; Fri, 27 Oct 2017 23:52:28 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0197.006; Fri, 27 Oct 2017 23:52:28 +0000 From: Mike Bishop To: Mark Nottingham , Patrick McManus CC: QUIC WG , Lars Eggert , "Spencer Dawkins at IETF" Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuyheooSNpGQN0mRPLjjogNQzqL3zoAAgACAwwCAAA224A== Date: Fri, 27 Oct 2017 23:52:28 +0000 Message-ID: References: <52293976-62BE-4420-B0D1-27BAE3A3A556@mnot.net> In-Reply-To: <52293976-62BE-4420-B0D1-27BAE3A3A556@mnot.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [2001:4898:80e8:2::51f] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0191; 6:cf0pOPfRSlxcr/QwB9XLHIY1kfIJ4JVLlAYf2fbkzdA6dyqW/T2HGslU7ccd6A5Xut9incQSLyglgPvjJQIb8UKTJCKKSSWU6rWYDxgtbFbNiORsmX8u4Rs/RscybKQxQ+9ZD5kTeGlWjdIqgfP5scvUht9jwUNul/EBhcwC1HtwabFmKExELy1lOa4EzDLoGth3sq0fDNp5xa9CBR3jokwHb45Khq3a1o94/U5TQkOVti8CD8VMmmvjeCKFhAHNJ+5zS3srAzu4i1r13eF+H2mN7+Rro6MUnJ7FReXtV0SiHSU16VcyJomBUkTGdJTNcHc/RHCCouFRgreKBV4bBSczRSI7ZplSX6ZqCqkonpA=; 5:ukaKdzzX2CF4atxct8BPbXksyf/RM0aJeFv2slPpcB6k+Gh3zkzysex5cuhbdRY+oLYBQvATZ1YI223PLOF3pDo8/fYdqW8jf8Xr6tVEWc6T93plfaasENePiAq14oXKQVnVEXHScb35g0id/v7v3cx1II6O8Wjeep/M6kYLJDg=; 24:MvN1Ea563zu9GVTOme/YJq16mdhB65KaZKoq1i/u+3m/FoZoarL4hH0cvrprr5lgmLSEw5MRhWX/Y9I+A5EdSkHLoObXZM0D5sdJD4Q3vDY=; 7:Ftc2csQJOXJVy16vJT+CL87x5+y6ARwdAJuj2hQoEFUPUnHTWoNs/n+CEuEn3DdeGxT3F5NauHVIZGjxjU3kLMFAD/SPF4XjErkD6Sv/R70YuTY1Wz+JfYae2x61UIXp6Hf3MmGXlbqPkVsFTiOjMZyJwGMZ+grvLsHvlldysx/nbdoMz528ADOXF5aP5RmRLp3+sIfa0kMI4BEqDv1b7lHs9wEm3R/a3UdEHQHQMe1yvmcwboWUADX6q07yr9lw x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 841d6ffa-0ee9-46b7-459d-08d51d95c822 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:MWHPR21MB0191; x-ms-traffictypediagnostic: MWHPR21MB0191: x-exchange-antispam-report-test: UriScan:(189930954265078)(100405760836317)(219752817060721); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(3002001)(3231020)(6055026)(61426038)(61427038)(6041248)(20161123555025)(20161123560025)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0191; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0191; x-forefront-prvs: 0473A03F3F x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(346002)(376002)(39860400002)(47760400005)(53754006)(199003)(189002)(13464003)(24454002)(7520500002)(81166006)(561944003)(10090500001)(478600001)(25786009)(3280700002)(86612001)(5660300001)(3660700001)(76176999)(8676002)(54356999)(81156014)(2950100002)(101416001)(6306002)(97736004)(99286003)(102836003)(6116002)(189998001)(68736007)(106356001)(74316002)(53546010)(229853002)(9686003)(8936002)(7696004)(50986999)(22452003)(105586002)(39060400002)(33656002)(72206003)(966005)(2906002)(316002)(55016002)(8990500004)(6436002)(14454004)(54906003)(6506006)(110136005)(7736002)(4326008)(53936002)(86362001)(6246003)(575784001)(10290500003)(305945005)(77096006)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0191; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: 841d6ffa-0ee9-46b7-459d-08d51d95c822 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Oct 2017 23:52:28.6493 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0191 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, 27 Oct 2017 23:52:34 -0000 I'm with Patrick. While I do believe that HTTP/2 stayed on the right side = of the line most of the time, I have heard other people in the HTTP communi= ty who very vocally expressed their opinion that we put finishing on time a= bove being willing to re-examine issues as broader experience arose. To so= me extent, that's self-fulfilling -- the longer the process takes, the less= something we reached consensus on 20 months ago is guaranteed to represent= the consensus of the currently-active participants, and we'll naturally ha= ve to rehash the same discussions whenever the composition of the group cha= nges too much. I'm supportive of reiterating that our "first and best" customer for v1 wil= l be HTTP, and implementing a policy of tabling non-HTTP-blocking issues un= til v2. I don't believe that's inconsistent with our current charter, othe= r than to recognize that there may be more such issues than just multipath.= As the saying goes, shipping is a feature, and it's going to be more impo= rtant than some other features in our backlog. But the right path is to re= ach consensus on that prioritization, not to set a date (even a revised one= ) and say we're going to the IESG on that date come what may. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham Sent: Friday, October 27, 2017 3:55 PM To: Patrick McManus Cc: QUIC WG ; Lars Eggert ; Spencer Dawkins= at IETF Subject: Re: QUIC - Our schedule and scope Hi Patrick, > On 28 Oct 2017, at 2:13 am, Patrick McManus wrote: >=20 > Hi All, >=20 > First, the observation that elapsed time impacts participation and partic= ipation impacts quality is a good observation. Finishing faster (I personal= ly want to go way way faster) is consistent with that and we should look at= how we're organized to help make that a reality. Thanks for doing that. >=20 > I'm also not quite as pessimistic as the chairs are. I don't really think= this is a linear process - as we get more input from more implementations = I think the process will naturally accelerate. The challenge at that later = stage will be on not re-opening issues that we have reached consensus on. T= hat's different than the challenge we've been going through for the last ye= ar; for the last year we've been building up the basic blocks from an expli= citly 0-consensus starting point. Its both not surprising, and a good thing= , that many issues have been given scrutiny during that phase. >=20 >=20 > On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham wrote: >=20 >> To address this, we think two things are necessary: >=20 > Just for clarification, you're suggesting these 2 bullets as updates in s= ome form to the wg charter?=20 The milestones are a charter update, but chairs can submit revised mileston= es with approval by the AD, as always.=20 I don't think (2) requires a charter update, but if that makes people more = comfortable, we can talk about it. >> 1) Our Milestone for delivering the "core" QUIC documents (plus applica= bility and manageability statements) to the IESG should be moved to Decembe= r 2018, with the understanding that this is a deadline we intend to meet. >>=20 >> 2) V1 of QUIC should *only* address the use case of HTTP. >>=20 >> This has a few implications: >>=20 >> * Proposals for changes that are not realistically achievable in the tim= eline of #1 will be rejected on that basis, because the WG has consensus th= at the schedule is important. >=20 > This needs to be severely unpacked and I do not support it in the way I'm= interpreting it. Understood. We anticipated some discussion. :) > I think the only way we're going to finish quickly and still create a goo= d product is if all the participants are focused on getting to yes. A shot = clock process fix isn't going to get a high quality result - we need an att= itude fix :) I agree, and that's a better way to say it. Thanks. For those who weren't there, HTTP/2 had a similar focus on "getting to yes"= , through an understanding that our milestones were serious. It was not "co= nsensus at any cost", it was an agreement that we wanted to ship something = we agreed on in a reasonable amount of time. That agreement informed the de= cisions of individual WG participants -- but in a positive way, as you outl= ine. > The current charter says "Note that consensus is required both for change= s to the current protocol mechanisms and retention of current mechanisms. I= n particular, because something is in the initial document set does not imp= ly that there is consensus around the feature or around how it is specifie= d." This remains an important property for the evolution of IETF QUIC. We n= eed to work through all the details as a working group.. I think we can do = it faster, but not by inventing an arbitrary forcing function. >=20 > A firm timebox severely undermines the consensus process via simple gamif= iciation to 'run out the clock' in favor of existing text. That is not in t= he interest of the end result or getting consensus in a multi-stakeholder p= rocess. Indeed it probably increases the chances for a disastrous last call= period. However, getting to yes is in everybody's interest. That's a much = better motivator. If you see someone acting strategically like that, please bring it to our a= ttention; it indicates participation in bad faith, and will need to be deal= t with. > I think a better path would be for the chairs to more aggressively declar= e rough consensus at an earlier stage of discussion than is typically done.= I'm not suggesting a different threshold of consensus, just less indulgenc= e in letting issues play all the way out in hopes of convergence. Perhaps a= lso an appeal to all WG members to consider the implications of expressing = an opinion on a topic .. Every issue does not need to be a poll for everyon= e's opinion.. save it for places where your opinion makes a material differ= ence to you. (i.e. acknowledge that two people will disagree on what is a b= ikeshed vs what is meaningful and stay out of it in the name of progress if= you are on the bikeshed side). >=20 > I have no objection to updating the milestone delivery date to something = more reasonable, but I do think elevating schedule to be a higher order con= cern than consensus on the RFC content is wrong. To be clear -- this does not magically give the chairs the ability to ignor= e or circumvent the process. We can't elevate anything higher than consensu= s. We're asking for the WG to gain consensus that it wants to take the milesto= ne seriously, to inform its further discussions. We'll still need to gather= consensus on other things, and if the WG forms a new consensus that a part= icular proposal merits exceeding the milestone, it can do so. And of course= we'll still need to gain consensus on what we put in the documents (and wh= at we leave out). > I think your second suggestion, scoping around HTTP for v1, is more likel= y to get us to a successful finish. As we get later in this process, it wil= l be more important. >=20 > =20 >> * Discussion of anything else (including issues, drafts, proposals) that= doesn't address the needs of HTTP-over-QUIC will be postponed until after = V1 has shipped. >=20 > Browsing through the archives I actually don't see very many issues that = are totally non-http (certainly < 10%). But there probably are quite a few = that are simpler to resolve if only http is taken into account. Indeed. -- Mark Nottingham https://na01.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fwww.mnot.net%2F&data=3D02%7C01%7Cmichael.bishop%40microsoft.com%7= C0ceb5fbd79e84c7e3b1e08d51d8dba4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 0%7C636447416919107375&sdata=3DegqQsHDuy89iTrPcB%2FdMnBaTMFJPn4%2F%2Ftw5Znc= LRmgk%3D&reserved=3D0 From nobody Sat Oct 28 01:04: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 4697313FAC6 for ; Sat, 28 Oct 2017 01:04:43 -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 puEcvh1cLTgZ for ; Sat, 28 Oct 2017 01:04:41 -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 1AB5313B10E for ; Sat, 28 Oct 2017 01:04:40 -0700 (PDT) Received: from gozo.iway.ch (localhost [127.0.0.1]) by localhost (Postfix) with ESMTP id C26853407BA; Sat, 28 Oct 2017 10:04:38 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by localhost (ACF/18338.18860); Sat, 28 Oct 2017 10:04:38 +0200 (CEST) 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; Sat, 28 Oct 2017 10:04:38 +0200 (CEST) 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 34182765; Sat, 28 Oct 2017 10:04:38 +0200 From: "Brian Trammell (IETF)" Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_0110ECF2-6FD2-443A-8F2A-CBBEA161A627"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: QUIC - Our schedule and scope Date: Sat, 28 Oct 2017 10:04:37 +0200 In-Reply-To: Cc: QUIC WG , Lars Eggert , Spencer Dawkins at IETF 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: Sat, 28 Oct 2017 08:04:43 -0000 --Apple-Mail=_0110ECF2-6FD2-443A-8F2A-CBBEA161A627 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 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: >=20 > 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? Thanks, cheers, Brian --Apple-Mail=_0110ECF2-6FD2-443A-8F2A-CBBEA161A627 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----- iQIzBAEBCgAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAln0OhUACgkQihK3vwvq RqPN0BAAtuuc5BSqcUZCb/bJwrkwkCA4f0ZjVc7heqIXRp3YxUW9oNbo3kIU9snZ B2fLG76pD851OscHEcCY99tZgZRCSxs7TSkhxRtAOBW2SVjMNkk7CiFl23+OcRKo 8vBwEtlEpkGxAh4j5mZgD8+5FgrbMFIUX0ESi7eFcbuvQYLqsMZ7V+ENXN1Jfoyv 7PSGEOBlctuhK/p7W7hT70+1NNNDeca/f4h2aTTUd+gn+LxeAH7dELgTJGIShE9L khJXb3jNxsn9z/AI/sTciBGi2j8mYAFixHDkl1UTzQt4ojaDuBR2Sw8gBmWfvcJw DXBxEyE+jnY9M4aUCKnKs6RiY8cud/cR3AgbrQHs/rwz+WRL3TlvTuIySMATrZB+ Ec44lmPK0SjjNgghth5210g0HJI5AeWjn4eX1OEdfgvv9vn8suvlPOmP9KPVZ53B dxxgBGM44uijrQEXVPL8ZBIYphyedud6taAOcpYmRHJ/l/J8Bp6u8j8z/UxKXSd7 8M6oosnnJdEs2RzLyzmDreZoIr/FeQHqMI0wjbysJA+o+bP31ccZcm0HmPtLi6Z4 VqZvyicEZMk4kZDLOi1eoXfkw8OjLOu3W1ctiNl76BSrl5Yp+GQQFwbZX7hT/kpD V/MewF6mMxC4soIGBXJbDK9tTUFq+bcZUeVg3IyyzawMe4bi0qU= =0UGW -----END PGP SIGNATURE----- --Apple-Mail=_0110ECF2-6FD2-443A-8F2A-CBBEA161A627-- From nobody Sat Oct 28 04:12: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 5BD89139436 for ; Sat, 28 Oct 2017 04:12:25 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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=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 8VSxGn0uPhWG for ; Sat, 28 Oct 2017 04:12:23 -0700 (PDT) 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 BD85C13F542 for ; Sat, 28 Oct 2017 04:12:22 -0700 (PDT) X-AuditID: c1b4fb3a-de7ff70000006897-b7-59f466146a17 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 14.D4.26775.41664F95; Sat, 28 Oct 2017 13:12:20 +0200 (CEST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.60) with Microsoft SMTP Server (TLS) id 14.3.352.0; Sat, 28 Oct 2017 13:12:20 +0200 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=6Buq6ffPQVNRN6Pb4nssypRRkFI50i0+HiMPdoZbnTI=; b=iwCMSX2BBxG3euoH4a0t6VAEWECB5eqP7iUgShm7XmdThi4k3SHYiia+NgpiEMaIFQZSKj5dHsl0DtrMBnqMo+nYNCmsOhiYEFzKRjZXZsHajNDtqtFpqTQrBKMHIAsoSsZUm/WtludzqhS7fNiqrI0jT0jHaRwGCTfoZRUTNLA= Received: from AM2PR07MB0563.eurprd07.prod.outlook.com (10.160.32.21) by AM2PR07MB0563.eurprd07.prod.outlook.com (10.160.32.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.156.4; Sat, 28 Oct 2017 11:12:18 +0000 Received: from AM2PR07MB0563.eurprd07.prod.outlook.com ([fe80::2cfd:d7f5:6359:3c2e]) by AM2PR07MB0563.eurprd07.prod.outlook.com ([fe80::2cfd:d7f5:6359:3c2e%14]) with mapi id 15.20.0156.007; Sat, 28 Oct 2017 11:12:18 +0000 From: Salvatore Loreto To: Mike Bishop , Mark Nottingham , Patrick McManus CC: QUIC WG , Lars Eggert , "Spencer Dawkins at IETF" Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuy0shgNKpikw0ymPKjNG1l9PaL3zn8AgACAxACAABAuAIAAuUIg Date: Sat, 28 Oct 2017 11:12:18 +0000 Message-ID: References: <52293976-62BE-4420-B0D1-27BAE3A3A556@mnot.net> 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: [94.137.111.23] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; AM2PR07MB0563; 6:d07JaUd4bklZm/PnY9eOOd9et9SQ8lFeLN08wVA58hNv2qvCIEnHBtMHiEeiHjuVafO60v9FLvCqvxEER5qv/GxdFczIjZl6hzGR20anvPHihirpEBz1Zpw+G+1vR0e4/8dl8egtgS9VEC5ulyskfak7d+ekqfXGbnCTuvcIxU7PU1uqhbo96Eeu7T9VkAHmxOEQLupMBoxzLq7Xaf/swqTGllim4OfXIg8Y3yNkvYAYCDUPIFLOwbenIluYyW3IL6ayIVfKQRa22Wv5l9t/jwQ/dnX2qoPNKWcVNMiqR1NmtVxygow35v23hNZZJgWbuXb5wl+8jw5AXXnxzaJLUA==; 5:CgF2N3f2pdCnjM2xiHir7H4dqLcW/nODVTX8cC9YAMPrQkI0K7vRUCOgiH1r20qgur2UmEMSP57+i94KTmtNim6B82j03FpUZzJZ/12jChHH7bcgikwhhtkGDzFDk+JDRgau0rVA1RGccC/fhVIw/Q==; 24:BPZynsEWnLstdTn4MxZT60lvtCtxeMwnw86dK0RyC9iTJq/eEJc/8FE1/7kXemIoIqXgMgKw9O/WPhGe6iI+IHVidRxBPEhBnKMnAWvXiYo=; 7:S5uO7giMU6jlUSnMloecOcjl2CxYc/2/sNOM38clohY3c1Xr3uCkx1Zc+8uf6dVLOOUY159cYkbLzSco4lIp2aMOlvtOSb/t9DmvAwwe8f5Cc3bn07r2w4nrwowvbvUCxQwoDwu98K+ve6Q39frCUtGLuxzvxb4v48169EvQlCvD5Zd1KVWsyTIh9yKZGmIgj5Lv//78GbZm3HeMDMLVWogLWUATw1xuXOlnB+CLHoM= x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 9ed38b95-1be3-4955-6da5-08d51df4c099 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:AM2PR07MB0563; x-ms-traffictypediagnostic: AM2PR07MB0563: x-exchange-antispam-report-test: UriScan:(189930954265078)(100405760836317)(219752817060721); 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)(3231020)(93006095)(93001095)(100000703101)(100105400095)(3002001)(10201501046)(6041248)(20161123562025)(20161123558100)(20161123564025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:AM2PR07MB0563; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:AM2PR07MB0563; x-forefront-prvs: 04740D25F1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(346002)(376002)(13464003)(199003)(24454002)(189002)(53754006)(478600001)(561944003)(2421001)(105586002)(106356001)(76176999)(55016002)(50986999)(33656002)(25786009)(101416001)(2900100001)(54356999)(45080400002)(8666007)(305945005)(6306002)(2561002)(7736002)(99286003)(39060400002)(68736007)(93886005)(6506006)(7520500002)(6246003)(9686003)(189998001)(74316002)(229853002)(966005)(5250100002)(102836003)(53936002)(97736004)(14454004)(6436002)(54906003)(110136005)(2950100002)(7696004)(3280700002)(316002)(3846002)(53546010)(8676002)(6116002)(66066001)(3660700001)(1511001)(86362001)(575784001)(81156014)(4326008)(81166006)(2906002)(5660300001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM2PR07MB0563; H:AM2PR07MB0563.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 9ed38b95-1be3-4955-6da5-08d51df4c099 X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2017 11:12:18.1893 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM2PR07MB0563 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SWUwTURSGczsz7YA2uRaQw+IDTYgIWIEQaZAAJoI1YtxewIC2yrAIFOwg UjUGHopagYgiayJbBXEJUYpW2RdFeVEMaoIBQ9hLXVIqBBEiw2Di23fP/91zzk0uTUgaKFc6 WZ3JaNSqVKnQniyPfh6y0zHBFuPXagiSz8zlk/KaXj2SN1nHkbyzbUUkz6/eJK8vbiPChYoX FSMihcGwJFDoTCsixZO6RUpR2KWnFGVWm/CI8IR9SDyTmpzFaHaFKu2T8qwNKEMfkT3aUirI QeYgPbKjAQfCJ8tvUo/saQnuQ9CaWynkAgl+g6Bx1Z8LSFxAQH9zyYZVLIA789cI/jCOYKa4 iOKuCPFumB4zEhw7Yi0YGucRxwS+AJ3TJgHHDtgbSussaz695vjAtF7L65Fgvr+8rpDYE8pt TUJOEeNYGHoVx4+6KgCzcWm9vR2Og1+FpvWxCG+FxYFHAn6UMwxPVAn4p2EwtL0jeHaC2fHV DV8J1ddXRFx/wB4wmRvMK9vgQ9UNxM0CnCcC2+0fiA9k0FL0DfH+ITB/PMqX1dDf3ryheEPv lzKKV+KgL28PX04BnfHzxgZDFDy0ZPPsDouDtdRNJKv4b2mefaG61Srk2Qfqa+YIjsV4C7wt nyCrEfkAObEMy6YlBgTIGE3yGZZNV8vUTOZTtPZ9uo3LwSbUPb23B2EaSTeLj+2zxUgoVRar TetBQBNSR/Fg1FpJHK/SXmQ06ac051MZtge50aTUWRze8T5aghNVmUwKw2Qwmn+pgLZzzUER U6FKtyQqV97QXKIbiQ1rv1V+b7//6dW5kEKZO1FwYICZel2rm1Q1UoVWhyKXoe+lifV/dEYX u9FLhq/ILz0raSjs2UlfzwKlhV26e/DssEtA5M8xbcdhZ01sD1Nm6dpyvPHKY6+E9tmwoh3n Js2XX1YyJV7bF8ajAhf6PErnpSSbpPL3JjSs6i8Dng0jOgMAAA== 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, 28 Oct 2017 11:12:25 -0000 I do support the intent to target Dec 2018 with QUICv1 and limiting its sco= pe to HTTP I am confident that we can reach that I want also to give a strong +1 on Patrick and Mike comments on chair actio= ns, especially on finding in the process the right balance between the deliver= y date and consensus on the RFC content -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mike Bishop Sent: den 28 oktober 2017 01:52 To: Mark Nottingham ; Patrick McManus Cc: QUIC WG ; Lars Eggert ; Spencer Dawkins= at IETF Subject: RE: QUIC - Our schedule and scope I'm with Patrick. While I do believe that HTTP/2 stayed on the right side = of the line most of the time, I have heard other people in the HTTP communi= ty who very vocally expressed their opinion that we put finishing on time a= bove being willing to re-examine issues as broader experience arose. To so= me extent, that's self-fulfilling -- the longer the process takes, the less= something we reached consensus on 20 months ago is guaranteed to represent= the consensus of the currently-active participants, and we'll naturally ha= ve to rehash the same discussions whenever the composition of the group cha= nges too much. I'm supportive of reiterating that our "first and best" customer for v1 wil= l be HTTP, and implementing a policy of tabling non-HTTP-blocking issues un= til v2. I don't believe that's inconsistent with our current charter, othe= r than to recognize that there may be more such issues than just multipath.= As the saying goes, shipping is a feature, and it's going to be more impo= rtant than some other features in our backlog. But the right path is to re= ach consensus on that prioritization, not to set a date (even a revised one= ) and say we're going to the IESG on that date come what may. -----Original Message----- From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham Sent: Friday, October 27, 2017 3:55 PM To: Patrick McManus Cc: QUIC WG ; Lars Eggert ; Spencer Dawkins= at IETF Subject: Re: QUIC - Our schedule and scope Hi Patrick, > On 28 Oct 2017, at 2:13 am, Patrick McManus wrote: >=20 > Hi All, >=20 > First, the observation that elapsed time impacts participation and partic= ipation impacts quality is a good observation. Finishing faster (I personal= ly want to go way way faster) is consistent with that and we should look at= how we're organized to help make that a reality. Thanks for doing that. >=20 > I'm also not quite as pessimistic as the chairs are. I don't really think= this is a linear process - as we get more input from more implementations = I think the process will naturally accelerate. The challenge at that later = stage will be on not re-opening issues that we have reached consensus on. T= hat's different than the challenge we've been going through for the last ye= ar; for the last year we've been building up the basic blocks from an expli= citly 0-consensus starting point. Its both not surprising, and a good thing= , that many issues have been given scrutiny during that phase. >=20 >=20 > On Fri, Oct 27, 2017 at 2:26 AM, Mark Nottingham wrote: >=20 >> To address this, we think two things are necessary: >=20 > Just for clarification, you're suggesting these 2 bullets as updates in s= ome form to the wg charter?=20 The milestones are a charter update, but chairs can submit revised mileston= es with approval by the AD, as always.=20 I don't think (2) requires a charter update, but if that makes people more = comfortable, we can talk about it. >> 1) Our Milestone for delivering the "core" QUIC documents (plus applica= bility and manageability statements) to the IESG should be moved to Decembe= r 2018, with the understanding that this is a deadline we intend to meet. >>=20 >> 2) V1 of QUIC should *only* address the use case of HTTP. >>=20 >> This has a few implications: >>=20 >> * Proposals for changes that are not realistically achievable in the tim= eline of #1 will be rejected on that basis, because the WG has consensus th= at the schedule is important. >=20 > This needs to be severely unpacked and I do not support it in the way I'm= interpreting it. Understood. We anticipated some discussion. :) > I think the only way we're going to finish quickly and still create a goo= d product is if all the participants are focused on getting to yes. A shot = clock process fix isn't going to get a high quality result - we need an att= itude fix :) I agree, and that's a better way to say it. Thanks. For those who weren't there, HTTP/2 had a similar focus on "getting to yes"= , through an understanding that our milestones were serious. It was not "co= nsensus at any cost", it was an agreement that we wanted to ship something = we agreed on in a reasonable amount of time. That agreement informed the de= cisions of individual WG participants -- but in a positive way, as you outl= ine. > The current charter says "Note that consensus is required both for change= s to the current protocol mechanisms and retention of current mechanisms. I= n particular, because something is in the initial document set does not imp= ly that there is consensus around the feature or around how it is specifie= d." This remains an important property for the evolution of IETF QUIC. We n= eed to work through all the details as a working group.. I think we can do = it faster, but not by inventing an arbitrary forcing function. >=20 > A firm timebox severely undermines the consensus process via simple gamif= iciation to 'run out the clock' in favor of existing text. That is not in t= he interest of the end result or getting consensus in a multi-stakeholder p= rocess. Indeed it probably increases the chances for a disastrous last call= period. However, getting to yes is in everybody's interest. That's a much = better motivator. If you see someone acting strategically like that, please bring it to our a= ttention; it indicates participation in bad faith, and will need to be deal= t with. > I think a better path would be for the chairs to more aggressively declar= e rough consensus at an earlier stage of discussion than is typically done.= I'm not suggesting a different threshold of consensus, just less indulgenc= e in letting issues play all the way out in hopes of convergence. Perhaps a= lso an appeal to all WG members to consider the implications of expressing = an opinion on a topic .. Every issue does not need to be a poll for everyon= e's opinion.. save it for places where your opinion makes a material differ= ence to you. (i.e. acknowledge that two people will disagree on what is a b= ikeshed vs what is meaningful and stay out of it in the name of progress if= you are on the bikeshed side). >=20 > I have no objection to updating the milestone delivery date to something = more reasonable, but I do think elevating schedule to be a higher order con= cern than consensus on the RFC content is wrong. To be clear -- this does not magically give the chairs the ability to ignor= e or circumvent the process. We can't elevate anything higher than consensu= s. We're asking for the WG to gain consensus that it wants to take the milesto= ne seriously, to inform its further discussions. We'll still need to gather= consensus on other things, and if the WG forms a new consensus that a part= icular proposal merits exceeding the milestone, it can do so. And of course= we'll still need to gain consensus on what we put in the documents (and wh= at we leave out). > I think your second suggestion, scoping around HTTP for v1, is more likel= y to get us to a successful finish. As we get later in this process, it wil= l be more important. >=20 > =20 >> * Discussion of anything else (including issues, drafts, proposals) that= doesn't address the needs of HTTP-over-QUIC will be postponed until after = V1 has shipped. >=20 > Browsing through the archives I actually don't see very many issues that = are totally non-http (certainly < 10%). But there probably are quite a few = that are simpler to resolve if only http is taken into account. Indeed. -- Mark Nottingham https://na01.safelinks.protection.outlook.com/?url=3Dhttp= s%3A%2F%2Fwww.mnot.net%2F&data=3D02%7C01%7Cmichael.bishop%40microsoft.com%7= C0ceb5fbd79e84c7e3b1e08d51d8dba4a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C= 0%7C636447416919107375&sdata=3DegqQsHDuy89iTrPcB%2FdMnBaTMFJPn4%2F%2Ftw5Znc= LRmgk%3D&reserved=3D0 From nobody Sat Oct 28 23:34: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 D3ED71389E1 for ; Sat, 28 Oct 2017 23:34:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PC-0M1TU2mjJ for ; Sat, 28 Oct 2017 23:34:17 -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 6DD8213F68D for ; Sat, 28 Oct 2017 23:34:16 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DRP33192; Sun, 29 Oct 2017 06:33:59 +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; Sun, 29 Oct 2017 06:33:58 +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; Sun, 29 Oct 2017 14:33:45 +0800 From: Roni Even To: Mark Nottingham , QUIC WG CC: Lars Eggert , Spencer Dawkins at IETF Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuyjzH0XqhPpaUudBuwTgSLIsqL6XnCQ Date: Sun, 29 Oct 2017 06:33:44 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD828A1A@DGGEMM506-MBS.china.huawei.com> References: 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="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59F57657.0068, 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: 73aff86652512fdbc8e3bb994ff03907 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, 29 Oct 2017 06:34:20 -0000 Hi, I am OK with the proposal and support the need to focus on what is relevant= for the first release supporting HTTP/2 over QUIC. I have some concerns about "* 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 b= y V2 and beyond." My understanding is that the objective is to design a general Transport Pro= tocol that is not only for HTTP/2. HTTP/2 is a one specific use case (client server case) while there are alre= ady other use cases in the pipe described in individual drafts (RTP, DNS, M= ulticast, unreliable streams,...).=20 I think we must be very careful when defining the "invariants" to allow for= other uses. For example look at https://tools.ietf.org/id/draft-aboba-avtc= ore-quic-multiplexing-00.txt that tries to discuss one issue in the QUIC p= oint to point case. Roni=20 > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Mark Nottingham > Sent: =E9=E5=ED=A0=E5 27 =E0=E5=F7=E8=E5=E1=F8 2017 09:27 > To: QUIC WG > Cc: Lars Eggert; Spencer Dawkins at IETF > Subject: QUIC - Our schedule and scope >=20 > Working Group Participants, >=20 > Since the Working Group is now approximately one year old, it's a good ti= me > to step back and consider how well our work is proceeding. >=20 > As chairs, we've been concerned about successfully delivering QUIC since = we > started this effort. Introducing what is effectively a new transport prot= ocol > for the Internet that incorporates not only reliability, congestion contr= ol and > multiplexing, but also encryption and key exchange, 0RTT handshakes, and > what is effectively yet another version of HTTP is a tall order, especial= ly when > we started without broad implementation or deployment experience > beyond a single vendor. >=20 > The nature of our discussions has also caused us some concern, since we > seem to range over a variety of topics that are difficult to pin down, th= anks to > the interdependencies between them. We've explicitly given the editors > license to make bold changes in this start-up period as a way to move > forward, but even with that, we've struggled to manage our workload -- > currently at 170 open issues, with every sign of growing. >=20 > Our charter instructs us to deliver the "core" four documents in March 20= 18, > five months away. Many in the Working Group have viewed that milestone > as aspirational, but it's becoming clear that on our current course, we'l= l be > lucky to deliver QUIC in 2019. >=20 > In our considered view that is unacceptable, because it requires a > commitment (in time and effort) that many implementers and engineers will > be unwilling to make -- thus impacting the quality of participation we se= e, > and therefore the quality (and success) of QUIC. >=20 > To address this, we think two things are necessary: >=20 > 1) Our Milestone for delivering the "core" QUIC documents (plus applicabi= lity > and manageability statements) to the IESG should be moved to December > 2018, with the understanding that this is a deadline we intend to meet. >=20 > 2) V1 of QUIC should *only* address the use case of HTTP. >=20 > This has a few implications: >=20 > * Proposals for changes that are not realistically achievable in the time= line of > #1 will be rejected on that basis, because the WG has consensus that the > schedule is important. >=20 > * 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. >=20 > * Discussion of anything else (including issues, drafts, proposals) that = doesn't > address the needs of HTTP-over-QUIC will be postponed until after V1 has > shipped. >=20 > It's important to understand that this approach is predicated on the noti= on > that QUIC is not the one chance that we have to evolve transport protocol= s; > rather, it represents the start of an evolution, to be followed by any nu= mber > of new versions that are enabled by assuring that the extensibility and > versioning mechanisms are appropriately "greased" (i.e., we take measures > to assure that they are available in the future; in other words, counter- > ossification). >=20 > Please discuss on-list; we'll also be covering this in Singapore, and wil= l call for > consensus after gathering further input there. >=20 > Regards, >=20 > - Your Chairs, Lars Eggert and Mark Nottingham From nobody Sat Oct 28 23:36: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 34F84139435 for ; Sat, 28 Oct 2017 23:36:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5PrX_ftAFPyv for ; Sat, 28 Oct 2017 23:36:32 -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 54D701389E1 for ; Sat, 28 Oct 2017 23:36:30 -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 DYV31418; Sun, 29 Oct 2017 06:36:28 +0000 (GMT) Received: from DGGEMM403-HUB.china.huawei.com (10.3.20.211) by LHREML713-CAH.china.huawei.com (10.201.108.36) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 29 Oct 2017 06:36:27 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM403-HUB.china.huawei.com ([10.3.20.211]) with mapi id 14.03.0361.001; Sun, 29 Oct 2017 14:36:24 +0800 From: Roni Even To: "Brian Trammell (IETF)" , Mark Nottingham CC: QUIC WG , Lars Eggert , "Spencer Dawkins at IETF" Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuyjzH0XqhPpaUudBuwTgSLIsqL4YtaAgAH/mLA= Date: Sun, 29 Oct 2017 06:36:23 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD828A2F@DGGEMM506-MBS.china.huawei.com> References: 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="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59F576EC.003C, 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: 7c2ad93f9370a4c512b2ebd712b97e60 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, 29 Oct 2017 06:36:33 -0000 Hi, Sorry for raising the same issue again, I only noticed this email after I s= ent my feedback Roni > -----Original Message----- > From: QUIC [mailto:quic-bounces@ietf.org] On Behalf Of Brian Trammell > (IETF) > Sent: =F9=E1=FA 28 =E0=E5=F7=E8=E5=E1=F8 2017 11:05 > To: Mark Nottingham > Cc: QUIC WG; Lars Eggert; Spencer Dawkins at IETF > Subject: Re: QUIC - Our schedule and scope >=20 > hi Mark, all, >=20 > Broadly, I support Patrick's intepretation here. I'll point out that ther= e seems > to be some inconsistency between two points below: >=20 > > On 27 Oct 2017, at 08:26, Mark Nottingham wrote: > > > > 2) V1 of QUIC should *only* address the use case of HTTP. >=20 > and >=20 > > * 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. >=20 > That QUIC's handshake, pre-version-negotiation wire image, and ossificati= on- > prevention features will be "baked in" in V1 is clear, and I thought it a= lready > had been, though thanks for calling it out here. >=20 > 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 exp= licitly > asymmetric protocol, with different roles for client and server well beyo= nd > the initial handshake, and as it is presently most commonly deployed, wil= dly > 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 thi= s > focus lead to invariants that will make less asymmetric applications hard= er to > build and deploy? Should we be concerned about that at this point? >=20 > Thanks, cheers, >=20 > Brian From nobody Sat Oct 28 23:45: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 B0CCB13F68F for ; Sat, 28 Oct 2017 23:45:13 -0700 (PDT) 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 FVPcWl0KtbdR for ; Sat, 28 Oct 2017 23:45:12 -0700 (PDT) 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 81EC113F68B for ; Sat, 28 Oct 2017 23:45:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.44,313,1505804400"; d="asc'?scan'208";a="223722713" Received: from hioexcmbx02-prd.hq.netapp.com ([10.122.105.35]) by mx144-out.netapp.com with ESMTP; 28 Oct 2017 23:13:01 -0700 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx02-prd.hq.netapp.com (10.122.105.35) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sat, 28 Oct 2017 23:45:11 -0700 Received: from NAM03-BY2-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; Sat, 28 Oct 2017 23:45:11 -0700 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=o9ivK9eTRyfcsWy6TH0jNUqwqDX8RdqGgaw5QTu1cqk=; b=eIp/zqgUIgYwrPCOKHFkczj/4Q9l0lMFb+hBkWefjonTUfy+HfjP5IkyVCdmAX6W+uaJdUWM59J04EtWY6U94apUDKZOUDUbmPJBkWzrFiPveO0CQOb3YrnC9IbcBG+1RCcu5GGM13tuMiEBFhWMfYZUPOjxICudRwfTTKR2EuU= 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.178.6; Sun, 29 Oct 2017 06:45: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.0178.012; Sun, 29 Oct 2017 06:45:09 +0000 From: "Eggert, Lars" To: Roni Even CC: Mark Nottingham , QUIC WG , "Spencer Dawkins at IETF" Subject: Re: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuylSIJRNvocE0WivHlzUsNNn6L6YeIAgAADMAA= Date: Sun, 29 Oct 2017 06:45:08 +0000 Message-ID: References: <6E58094ECC8D8344914996DAD28F1CCD828A1A@DGGEMM506-MBS.china.huawei.com> In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD828A1A@DGGEMM506-MBS.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.1.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2a02:120b:2c4a:92d0:9c1a:4b15:efd1:1047] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1762; 6:dm8R2iJuzh3UWchPDXkFkChT5gqD9nhJWIxDuWF6dRe/V24bQjQpcJjbrxzp2CmLJAAO2Gjx3TwJLPfecCJO8H+2WcNdYAntwpl1PqbzW6D+MtaBPvmY3ESM9nJTcDKaejlWTcZ6tTMSnoRrWYF4peUui+01aKyv/T26A6HQ2ct67TVlLzJE3CtNOTd3+6gqOiCIdDClz/bAmdDicLU6vgBD/TKCc1oJbv6RFoI9SOTvuhLYB9I4H5e0OC+0qEGbw8K4ObUCDlOAvuhSkxuweY24CP0nfvbdvbiSf/erzYSTPEN2Vf0AGN4WbXd64XhUBZO4kFCtNxonQzSkitUZO3fO7Wt3Ty53CfcJVLNSJ7Q=; 5:6Ou9BnPE1Jc2HuODe5i34GHG8Zc9N6TclS4ii9rbqgiJq5p2OI0hx2J+DWBkuSkGPIc/WY7ottAoZnbddWEMdr5uV+QAxHpABuYKCm11Zw8zL5+p2PBOwfqGlAEzMOnEVCFIOoFIiYnLHzMKwqe4nTbhvbXheIAsYSCYPi3xg1U=; 24:mNxV3ZFf/StNBsdsTjniu70L9Wp84ZrPlOsOkSUWzpQFBgbIH3bL7yFpKjhNwDrjc8WpW/eimPRHGouCyHSr0O6sRvSZcliMfWH9BmOrv/Q=; 7:qC65dNAm6wny17PCGgKc+2FWOcGW48YdfmBK8gd4LIauy2h0dkq5ED8cq9X52f5YIzlzBfkjGQ4pCWTc3ziAy3kMngpSwBgV9yCrEtNqoyNcOgT4TBjU/0/FPitNWV4pvf974UBLUOYSmDMJwhXvV4N3GOzIIDlQUfbQtGCD1Pzj2N5tiT9bwJmyvliisg+hpuR9X/7js+JAIbv9R9RcpEGKLUt9yyjtd7Et7LWq8gza5Gdk8CPQbsUinsPSIiCx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: fdc7cf1a-0914-4d69-527b-08d51e9898df x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199)(49563074); SRVR:BLUPR06MB1762; x-ms-traffictypediagnostic: BLUPR06MB1762: x-exchange-antispam-report-test: UriScan:(50582790962513); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(3231020)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041248)(20161123558100)(20161123555025)(20161123564025)(20161123562025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(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: 0475418F50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(376002)(346002)(39830400002)(377424004)(189002)(24454002)(199003)(53546010)(478600001)(25786009)(53936002)(6246003)(3280700002)(2900100001)(99286003)(6512007)(76176999)(54906003)(86362001)(83716003)(97736004)(50986999)(4001150100001)(36756003)(14454004)(3660700001)(99936001)(50226002)(229853002)(81166006)(101416001)(7736002)(561944003)(6506006)(8676002)(33656002)(106356001)(8936002)(6486002)(81156014)(77096006)(39060400002)(4326008)(6436002)(2906002)(305945005)(189998001)(68736007)(316002)(5660300001)(102836003)(82746002)(57306001)(6116002)(105586002)(2950100002)(6916009); 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=_3E8346FA-8816-4FE1-A4B8-0C8D6F268ED5"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fdc7cf1a-0914-4d69-527b-08d51e9898df X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2017 06:45:08.8771 (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: Sun, 29 Oct 2017 06:45:14 -0000 --Apple-Mail=_3E8346FA-8816-4FE1-A4B8-0C8D6F268ED5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On 2017-10-29, at 7:33, Roni Even wrote: > I think we must be very careful when defining the "invariants" to = allow for other uses. agreed. And, we must be very careful to not make future extensions like = multipath, partial reliability, etc. more difficult to support than = necessary. So to me personally, that kind of forward-looking discussion - to ensure = we retain the extensibility needed for the future - remains fully in = scope. But there is a fine line between a general extensibility argument = and an argument that says "my proposal for future extension X is this, = and therefore QUICv1 needs to do Y now". Lars --Apple-Mail=_3E8346FA-8816-4FE1-A4B8-0C8D6F268ED5 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAln1ePQACgkQVLXDCb9w wVekLRAAk/ea6ehZVJ7duRx4Pz388w/cjwXNK+XDtZOxyhleT1Hoqa96BqtYut/u 17b5VG6gezQk2ehTxD1R7cnGy/brYAuiL/l2wvAzKv5V40QgXT3jMjAVqRKAmcqY tjJo2sXgZ0i3Y/E2FAQZm2JAxa8TOIv9J1DWPnc+lOn8sE2NckmppCbqAaImETXc LohUuQZyW1LRPC1z3zW0/+CifxZe+8efZFYRvs/CAMRww4NkI+BFFIalE8vN1f20 f40hHSxNC7nP8bFLjHKHjswkver6dCHdzUayxMVH1sFd4PVHqdHVGdAY3omUjg9d ob14xNB7QA9ui30iLB2UJVFuJVbAxSf+sgE4WhpytiMOHdWW3DgOmIyu/1cNmFI3 XdxxX3jp2VUV6PBirKi3PS5yTq4CxQTeUZoWqnbC91hEcwjxS8y8XXnf0UGt18sv m0kjro+WplqHAv/jyVukyulPwy8HA5eMxY6CjCs6kFqG5IGmefYU2nf+5aobMbBw bBEYEhHXGUEiSkroPsQ+TicZe8QV6BRUi4dkql+01gQh3itMT1arlNUwYOQGXQ++ IbaUVLEjlmCzeg9FoKIUFZOnIKE7WHeDLUq1J9OeSTOx84j/ChRFSlaAkmEfkQBZ aE/IHcWXV3FEIE+hl3IE34SEvZuG1P9sSpbXaFt9WpzMsv3fT6o= =aAAl -----END PGP SIGNATURE----- --Apple-Mail=_3E8346FA-8816-4FE1-A4B8-0C8D6F268ED5-- From nobody Sun Oct 29 00:01: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 A0BB513F5E6 for ; Sun, 29 Oct 2017 00:01:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.501 X-Spam-Level: X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 AuppuSP0N25Z for ; Sun, 29 Oct 2017 00:01:38 -0700 (PDT) Received: from unina.it (fmvip.unina.it [IPv6:2001:760:3403:ffff::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6230D13F6CC for ; Sun, 29 Oct 2017 00:01:38 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by leas1.unina.it with ESMTP id v9T71XBI002482-v9T71XBK002482 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Oct 2017 08:01:33 +0100 Received: from [192.168.1.69] (93-44-59-94.ip95.fastwebnet.it [93.44.59.94]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id v9T71XrG015459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Oct 2017 08:01:33 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) Subject: Re: QUIC - Our schedule and scope From: Simon Pietro Romano X-Mailer: iPhone Mail (15A432) In-Reply-To: <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> Date: Sun, 29 Oct 2017 08:01:32 +0100 Cc: Lucas Pardue , QUIC WG , Lars Eggert , Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> To: Mark Nottingham 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, 29 Oct 2017 07:01:41 -0000 The sad thing about multipath is that there have been people who have worked= , more than one year ago, on implementing it in a v1-compliant way. Though, t= he group has never wanted to give multipath a real chance to survive and has= always treated it as a =E2=80=9Cpotential future extension=E2=80=9D. This h= as been made so clear in the mailing list that we have stopped trying to pus= h for it. Simon Inviato da iPhone > Il giorno 28 ott 2017, alle ore 00:57, Mark Nottingham ha s= critto: >=20 > Hi Lucas, >=20 >=20 >> On 28 Oct 2017, at 3:36 am, Lucas Pardue wrote: >>=20 >> To date, I've tried to avoid mentioning Multipath on list and bring it up= now only as it relates to the WG Charter Milestones. >>=20 >> Can you be more explicit on how your proposals affect the current Multipa= th extension document dates? I could infer that the proposed changes to the c= ore docs are independent of the extension doc, or more realistically the res= cheduling also punts Multipath off another ~6 months (minimum) or until QUIC= V2. What is more aligned with your current thinking? >=20 > I think multipath would remain a post-V1 activity, which implies that the d= ates would be pushed out. >=20 > Cheers, >=20 > -- > Mark Nottingham https://www.mnot.net/ >=20 >=20 From nobody Sun Oct 29 00:18: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 3D77213F713 for ; Sun, 29 Oct 2017 00:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qbpxfgq7-J5r for ; Sun, 29 Oct 2017 00:18:10 -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 700F113F704 for ; Sun, 29 Oct 2017 00:18:10 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML710-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DYV34372; Sun, 29 Oct 2017 07:18:08 +0000 (GMT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.361.1; Sun, 29 Oct 2017 07:18:07 +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; Sun, 29 Oct 2017 15:17:50 +0800 From: Roni Even To: "Eggert, Lars" CC: Mark Nottingham , QUIC WG , "Spencer Dawkins at IETF" Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuylSIJRNvocE0WivHlzUsNNn6L6YeIAgAADMACAAAaB8A== Date: Sun, 29 Oct 2017 07:17:49 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD829ADC@DGGEMM506-MBS.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD828A1A@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="windows-1255" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.59F580B0.0481, 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: 7c2ad93f9370a4c512b2ebd712b97e60 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, 29 Oct 2017 07:18:12 -0000 Hi, Just to put the focus The relevant text in section 5.8 in the transport document is=20 "Between different versions the following things are guaranteed to remain c= onstant: o the location of the header form flag, o the location of the Connection ID flag in short headers, o the location and size of the Connection ID field in both header forms= , o the location and size of the Version field in long headers, o the location and size of the Packet Number field in long headers,=20 o the type, format and semantics of the Version Negotiation packet." This is what we need to agree on. Roni > -----Original Message----- > From: Eggert, Lars [mailto:lars@netapp.com] > Sent: =E9=E5=ED=A0=E0 29 =E0=E5=F7=E8=E5=E1=F8 2017 08:45 > To: Roni Even > Cc: Mark Nottingham; QUIC WG; Spencer Dawkins at IETF > Subject: Re: QUIC - Our schedule and scope >=20 > Hi, >=20 > On 2017-10-29, at 7:33, Roni Even wrote: > > I think we must be very careful when defining the "invariants" to allow= for > other uses. >=20 > agreed. And, we must be very careful to not make future extensions like > multipath, partial reliability, etc. more difficult to support than neces= sary. >=20 > So to me personally, that kind of forward-looking discussion - to ensure = we > retain the extensibility needed for the future - remains fully in scope. = But > there is a fine line between a general extensibility argument and an > argument that says "my proposal for future extension X is this, and there= fore > QUICv1 needs to do Y now". >=20 > Lars From nobody Sun Oct 29 01:25: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 4BE2D13F8E5 for ; Sun, 29 Oct 2017 01:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 t0zPK9GHOvcP for ; Sun, 29 Oct 2017 01:25:12 -0700 (PDT) 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 0B8BC13F8EE for ; Sun, 29 Oct 2017 01:25:11 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.44,313,1505804400"; d="asc'?scan'208,217";a="223731265" Received: from hioexcmbx07-prd.hq.netapp.com ([10.122.105.40]) by mx144-out.netapp.com with ESMTP; 29 Oct 2017 00:52:58 -0700 Received: from VMWEXCCAS05-PRD.hq.netapp.com (10.122.105.21) by hioexcmbx07-prd.hq.netapp.com (10.122.105.40) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 29 Oct 2017 01:25:07 -0700 Received: from NAM01-BN3-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; Sun, 29 Oct 2017 01:25:07 -0700 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=QZJ6lETCfwM1SCgu/Q1DNBV9jnwITM+asH+Z7ifFIeY=; b=dKPidmaen1pTkqLTFv1kz+zkAPyHXgJdmWIHXE9vvJHqtHO4H8WvqzLDP/frTZVGgmi+1eNXgDWa5T5tEMdjz1rWr5f1eIc+rom1n7ShwcJnQXAWTcGK3z5fUwqrpKMnM5k0MAw4GKemH5788AMNE7dqQmLttx3AzRSkcGmVn/o= 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.178.6; Sun, 29 Oct 2017 08:25:04 +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.0178.012; Sun, 29 Oct 2017 08:25:03 +0000 From: "Eggert, Lars" To: Simon Pietro Romano CC: Mark Nottingham , Lucas Pardue , QUIC WG , Spencer Dawkins at IETF Subject: Re: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuylSIJRNvocE0WivHlzUsNNn6L35buAgABqWgCAAhmSAIAAF1OA Date: Sun, 29 Oct 2017 08:25:03 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> 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.1.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2a02:120b:2c4a:92d0:8d30:54ac:23a3:d951] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1763; 6:Hf92oOYakXWPvxGFEAJa2UrE3k9QNF6VyZlkbOV1DkmbBAw5Kh/vdMY3ooXsduvnRch/vTy6PYUNaeINGwq54NMsA1wn1GhezHlRcXi8Zh3Szv9fOQgZi/btjlW4dI8Tiak3IUm1z/8wODsMEZIsoTecfHaGqrKGa91bJWwwGyoN5IaH/y54FCIEVyFKDfK1wQPPRS0fbnAoGTCZLaW1kGNNm7W+9NPfsa/nDF8V5aKhpWb2fliboDE+MFoSxn+unyxeQT/xOw6jFJ1jysdJ1/TtgTUrCTqjTk4aXOk/5Kh86U9GR2QhLMbavZvQDyouiJ6rDVXk/lScuo6SwOlEg/O7/nbMdKCun1hB2nYK3CU=; 5:hkDv1OLjb3hgecbPtinjMmKSZuWxsVXr7rdHooV4qyJXcNap3SwnyUrCCqkZSdpDLtpcMuNfNG2+WUgoWla/9DEZ49BGYFuep4PUxPYqCqRgFDjICmQmsQg0gIpREVJ3dkELZTg8BTJ9l6miTzpHHz4CKl9lPQO+W3tYK2T8nZs=; 24:JUtLExnGilwenFAbzrYqdHUIKFF6T0Ad52UKTU62M68W5vOnybQIpz//EJiZ4YOEeE0/fxyWZ4G8J17AxaFoG97RkScSM91x+P4g3PgVxVg=; 7:PQ3FDrj6iNM4YxihJH1B+v1LtBYyQ+NgybT4Kgp0PcmKdfES4KV0VZXuvwXuxuh8buoHgmOj/v/33AyJL8mJqOLEhYK3IcK5R+0izSauMQ0+hTZCgeMcjLcwFV7xN/GeO4iowSTwOE06N+MbUE2wKpcwqSSW4L1G21oeslV6bypjwLt9CQ61rOHfN+TePwqIWzDht+fGTQKmR/S0MtORemKSycgvrlPS9y5z2/GfL2dxxSVNnglyX6MAJ2IFvyX+ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 60db3e79-6330-4709-4869-08d51ea68db2 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199)(49563074); SRVR:BLUPR06MB1763; x-ms-traffictypediagnostic: BLUPR06MB1763: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3002001)(100000703101)(100105400095)(3231020)(10201501046)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(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: 0475418F50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(377424004)(24454002)(199003)(189002)(14454004)(53546010)(4001150100001)(316002)(54906003)(93886005)(5660300001)(68736007)(2900100001)(97736004)(2950100002)(6916009)(83716003)(6436002)(6246003)(229853002)(6486002)(8676002)(77096006)(6506006)(4326008)(86362001)(36756003)(39060400002)(7736002)(105586002)(189998001)(33656002)(25786009)(81166006)(106356001)(81156014)(8936002)(53936002)(50986999)(99286003)(2906002)(6512007)(236005)(99936001)(54896002)(82746002)(76176999)(50226002)(478600001)(3660700001)(3280700002)(101416001)(57306001)(102836003)(6116002); 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=_586A2881-7AA5-4B5E-92C2-3D24A2AA679F"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 60db3e79-6330-4709-4869-08d51ea68db2 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2017 08:25:03.0812 (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: Sun, 29 Oct 2017 08:25:14 -0000 --Apple-Mail=_586A2881-7AA5-4B5E-92C2-3D24A2AA679F Content-Type: multipart/alternative; boundary="Apple-Mail=_796384CA-1403-4CFB-A237-C65B71292320" --Apple-Mail=_796384CA-1403-4CFB-A237-C65B71292320 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2017-10-29, at 8:01, Simon Pietro Romano wrote: > The sad thing about multipath is that there have been people who have = worked, more than one year ago, on implementing it in a v1-compliant = way. Though, the group has never wanted to give multipath a real chance = to survive and has always treated it as a =E2=80=9Cpotential future = extension=E2=80=9D. This has been made so clear in the mailing list that = we have stopped trying to push for it. I don't think that's a fair summary. First, there is no v1. We're busy specifying it at the moment, and many, = many fundamental things are still changing. These are taking all the = cycles the WG has at the moment, and we're still not progressing at a = satisfactory pace. (Which was the message that started this thread.) I = also don't think that the implementations are at a stage where they can = realistically think about adding multipath - most haven't even really = looked at recovery in detail. Multipath *is* in the charter, and we're fully committed to supporting = it. I simply can't see how getting the WG working on the details at = multipath at this time will help speed up work on the protocol = fundamentals. And it seems that we'd need to continuously rework = multipath while we're still changing protocol fundamentals, which would = create additional busy work. Lars --Apple-Mail=_796384CA-1403-4CFB-A237-C65B71292320 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

On = 2017-10-29, at 8:01, Simon Pietro Romano <spromano@unina.it> = wrote:
The sad thing about = multipath is that there have been people who have worked, more than one = year ago, on implementing it in a v1-compliant way. Though, the group = has never wanted to give multipath a real chance to survive and has = always treated it as a =E2=80=9Cpotential future extension=E2=80=9D. = This has been made so clear in the mailing list that we have stopped = trying to push for it.

I don't think that's a fair = summary.

First, = there is no v1. We're busy specifying it at the moment, and many, many = fundamental things are still changing. These are taking all the cycles = the WG has at the moment, and we're still not progressing at a = satisfactory pace. (Which was the message that started this thread.) I = also don't think that the implementations are at a stage where they can = realistically think about adding multipath - most haven't even really = looked at recovery in detail.

Multipath *is* in the charter, and = we're fully committed to supporting it. I simply can't see how getting = the WG working on the details at multipath at this time will help speed = up work on the protocol fundamentals. And it seems that we'd need to = continuously rework multipath while we're still changing protocol = fundamentals, which would create additional busy work. 

Lars
= --Apple-Mail=_796384CA-1403-4CFB-A237-C65B71292320-- --Apple-Mail=_586A2881-7AA5-4B5E-92C2-3D24A2AA679F 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAln1kF0ACgkQVLXDCb9w wVd5qw//XykkBiFHV9oNSDeHZWaNZUhFRDomcMwl088XlDqmi3Sc6pgFm2IR+7ac xT7Gy3kwfEstlpiwY7YyJkysIEpYsp+h3V0lLkxb2fsfVhuLx8M1dzueOBrzwsVJ +DiA+MKY0NYp853iLO/Gu9jfLxEPf/YT6msOj8OT3DVDLAoVoc9ZeDF7dL7lGS9m IcM4wFFUrHhGa04AlR2dc0yPvr/kZFa1XJ0Vb/pfH3GMkUdroqFup+WF/dNPuWoD 54UPgOwqnSr0EFeo3x2V4o6dF4LTuxQzFRWBjZ4ois8NVSia3u9fQ9m7Kt4xBNRa trOKFeM9ev1bD0xeXyuMdOhDrDPqDWR7mi/QL5SZL6oPqzPU6tWstvB/9ZTk9+FP rdN8i1mG6bBLPSe85IUTHnMBhnA/2vWR3B+9Pgyituqe7HdKw0KSdjB7VAh10AVt eZuig0vosdNtqrnBtpZba9izeqMusRCO72n0bZW3TCtgWv5NY/tkHWSoxElUHEvX TlTOm0NkI6AJA27+uZEbIz27QxevG9ugE005LG1NFbNemDV7OPp1l9/OvNr0kavg kxzodlANjw7O+snO/uhEAM7gC+RFBRL4HTSWmYhO/L+jEjxnSblz6zJlHm2dmBNV V4uklaxYu43XlCc03VApfXsfKOKp7RWy8aogqvcFj/ekDwDNp7w= =wtBD -----END PGP SIGNATURE----- --Apple-Mail=_586A2881-7AA5-4B5E-92C2-3D24A2AA679F-- From nobody Sun Oct 29 03: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 8FA8013FE2A for ; Sun, 29 Oct 2017 03:26:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id etYw2dekBeXk for ; Sun, 29 Oct 2017 03:26:43 -0700 (PDT) Received: from unina.it (fmvip.unina.it [IPv6:2001:760:3403:ffff::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C26213AB34 for ; Sun, 29 Oct 2017 03:26:43 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by leas1.unina.it with ESMTP id v9TAQcSk002961-v9TAQcSm002961 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Oct 2017 11:26:38 +0100 Received: from [192.168.1.65] (93-44-59-94.ip95.fastwebnet.it [93.44.59.94]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id v9TAQb2E021785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Oct 2017 11:26:37 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_6E86E5CF-2EE7-4A0C-8A56-CED9CAC9370C" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: QUIC - Our schedule and scope From: Simon Pietro Romano In-Reply-To: Date: Sun, 29 Oct 2017 11:26:32 +0100 Cc: Mark Nottingham , Lucas Pardue , QUIC WG , Spencer Dawkins at IETF Message-Id: References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3124) 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, 29 Oct 2017 10:26:45 -0000 --Apple-Mail=_6E86E5CF-2EE7-4A0C-8A56-CED9CAC9370C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, > I don't think that's a fair summary. =E2=80=A6it=E2=80=99s "my" summary. BTW, the mailing list logs are = there. The IETF is a tough place to be, we all know. If it weren=E2=80=99t= a contradiction in terms, I=E2=80=99d call it an =E2=80=9Coligarchic = democracy=E2=80=9D. Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it = <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > On 29 Oct 2017, at 09:25, Eggert, Lars wrote: >=20 > Hi, >=20 > On 2017-10-29, at 8:01, Simon Pietro Romano > wrote: >> The sad thing about multipath is that there have been people who have = worked, more than one year ago, on implementing it in a v1-compliant = way. Though, the group has never wanted to give multipath a real chance = to survive and has always treated it as a =E2=80=9Cpotential future = extension=E2=80=9D. This has been made so clear in the mailing list that = we have stopped trying to push for it. >=20 > I don't think that's a fair summary. >=20 > First, there is no v1. We're busy specifying it at the moment, and = many, many fundamental things are still changing. These are taking all = the cycles the WG has at the moment, and we're still not progressing at = a satisfactory pace. (Which was the message that started this thread.) I = also don't think that the implementations are at a stage where they can = realistically think about adding multipath - most haven't even really = looked at recovery in detail. >=20 > Multipath *is* in the charter, and we're fully committed to supporting = it. I simply can't see how getting the WG working on the details at = multipath at this time will help speed up work on the protocol = fundamentals. And it seems that we'd need to continuously rework = multipath while we're still changing protocol fundamentals, which would = create additional busy work.=20 >=20 > Lars --Apple-Mail=_6E86E5CF-2EE7-4A0C-8A56-CED9CAC9370C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi,

I don't think that's a fair = summary.

=E2=80=A6it=E2=80=99s "my" summary. BTW, the mailing = list logs are there. The IETF is a tough place to be, we all know. If it = weren=E2=80=99t a contradiction in terms, I=E2=80=99d call it an = =E2=80=9Coligarchic democracy=E2=80=9D.

Simon



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

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



On 29 Oct 2017, at 09:25, Eggert, Lars <lars@netapp.com> = wrote:

Hi,

On 2017-10-29, at 8:01, Simon Pietro = Romano <spromano@unina.it> wrote:
The sad thing about multipath is that = there have been people who have worked, more than one year ago, on = implementing it in a v1-compliant way. Though, the group has never = wanted to give multipath a real chance to survive and has always treated = it as a =E2=80=9Cpotential future extension=E2=80=9D. This has been made = so clear in the mailing list that we have stopped trying to push for = it.

I = don't think that's a fair summary.

First, there is no v1. We're busy = specifying it at the moment, and many, many fundamental things are still = changing. These are taking all the cycles the WG has at the moment, and = we're still not progressing at a satisfactory pace. (Which was the = message that started this thread.) I also don't think that the = implementations are at a stage where they can realistically think about = adding multipath - most haven't even really looked at recovery in = detail.

Multipath *is* in the charter, and we're fully committed to = supporting it. I simply can't see how getting the WG working on the = details at multipath at this time will help speed up work on the = protocol fundamentals. And it seems that we'd need to continuously = rework multipath while we're still changing protocol fundamentals, which = would create additional busy work. 

Lars

= --Apple-Mail=_6E86E5CF-2EE7-4A0C-8A56-CED9CAC9370C-- From nobody Sun Oct 29 03:33: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 205A113FE2D for ; Sun, 29 Oct 2017 03:33:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nyu3NWpp5-SF for ; Sun, 29 Oct 2017 03:33:43 -0700 (PDT) Received: from unina.it (fmvip.unina.it [IPv6:2001:760:3403:ffff::7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 419AB138FA0 for ; Sun, 29 Oct 2017 03:33:43 -0700 (PDT) Received: from smtp1.unina.it (smtp1.unina.it [192.132.34.61]) by leas1.unina.it with ESMTP id v9TAXdGh007868-v9TAXdGj007868 (version=TLSv1.0 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Oct 2017 11:33:39 +0100 Received: from [192.168.1.65] (93-44-59-94.ip95.fastwebnet.it [93.44.59.94]) (authenticated bits=0) by smtp1.unina.it (8.14.4/8.14.4) with ESMTP id v9TAXcfK023126 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 29 Oct 2017 11:33:39 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_2A31D696-2C39-416F-B070-04754BE76DED" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: QUIC - Our schedule and scope From: Simon Pietro Romano In-Reply-To: Date: Sun, 29 Oct 2017 11:33:38 +0100 Cc: Mark Nottingham , Lucas Pardue , QUIC WG , Spencer Dawkins at IETF Message-Id: References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> To: "Eggert, Lars" X-Mailer: Apple Mail (2.3124) 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, 29 Oct 2017 10:33:45 -0000 --Apple-Mail=_2A31D696-2C39-416F-B070-04754BE76DED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello Lars, last comment and I=E2=80=99ll shut up, promised! > Multipath *is* in the charter, and we're fully committed to supporting = it. I simply can't see how getting the WG working on the details at = multipath at this time will help speed up work on the protocol = fundamentals. And it seems that we'd need to continuously rework = multipath while we're still changing protocol fundamentals, which would = create additional busy work.=20 Which is exactly what I=E2=80=99d call adding multipath capabilities to = a protocol =E2=80=9Cby design=E2=80=9D, rather than trying to add = multipath after the protocol has been specified. I think that security = should have taught us a lot, when it comes to distinguishing the "patch = it=E2=80=9D vs =E2=80=9Cthink of it at design time=E2=80=9D approach. Simon _\\|//_ ( O-O ) ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~ Simon Pietro Romano Universita' di Napoli Federico = II Computer Engineering Department=20 Phone: +39 081 7683823 -- Fax: +39 081 7683816 e-mail: spromano@unina.it = <>. = Magritte. oooO ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~ \ ( = ( ) \_) ) = / = (_/ > On 29 Oct 2017, at 09:25, Eggert, Lars wrote: >=20 > Hi, >=20 > On 2017-10-29, at 8:01, Simon Pietro Romano > wrote: >> The sad thing about multipath is that there have been people who have = worked, more than one year ago, on implementing it in a v1-compliant = way. Though, the group has never wanted to give multipath a real chance = to survive and has always treated it as a =E2=80=9Cpotential future = extension=E2=80=9D. This has been made so clear in the mailing list that = we have stopped trying to push for it. >=20 > I don't think that's a fair summary. >=20 > First, there is no v1. We're busy specifying it at the moment, and = many, many fundamental things are still changing. These are taking all = the cycles the WG has at the moment, and we're still not progressing at = a satisfactory pace. (Which was the message that started this thread.) I = also don't think that the implementations are at a stage where they can = realistically think about adding multipath - most haven't even really = looked at recovery in detail. >=20 > Multipath *is* in the charter, and we're fully committed to supporting = it. I simply can't see how getting the WG working on the details at = multipath at this time will help speed up work on the protocol = fundamentals. And it seems that we'd need to continuously rework = multipath while we're still changing protocol fundamentals, which would = create additional busy work.=20 >=20 > Lars --Apple-Mail=_2A31D696-2C39-416F-B070-04754BE76DED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello Lars,

last comment and I=E2=80=99ll shut up, promised!

Multipath *is* in the charter, and we're fully = committed to supporting it. I simply can't see how getting the WG = working on the details at multipath at this time will help speed up work = on the protocol fundamentals. And it seems that we'd need to = continuously rework multipath while we're still changing protocol = fundamentals, which would create additional busy = work. 

Which is exactly what = I=E2=80=99d call adding multipath capabilities to a protocol =E2=80=9Cby = design=E2=80=9D, rather than trying to add multipath after the protocol = has been specified. I think that security should have taught us a lot, = when it comes to distinguishing the "patch it=E2=80=9D vs =E2=80=9Cthink = of it at design time=E2=80=9D approach.

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

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



On 29 Oct 2017, at 09:25, Eggert, Lars <lars@netapp.com> = wrote:

Hi,

On 2017-10-29, at 8:01, Simon Pietro = Romano <spromano@unina.it> wrote:
The sad thing about multipath is that = there have been people who have worked, more than one year ago, on = implementing it in a v1-compliant way. Though, the group has never = wanted to give multipath a real chance to survive and has always treated = it as a =E2=80=9Cpotential future extension=E2=80=9D. This has been made = so clear in the mailing list that we have stopped trying to push for = it.

I = don't think that's a fair summary.

First, there is no v1. We're busy = specifying it at the moment, and many, many fundamental things are still = changing. These are taking all the cycles the WG has at the moment, and = we're still not progressing at a satisfactory pace. (Which was the = message that started this thread.) I also don't think that the = implementations are at a stage where they can realistically think about = adding multipath - most haven't even really looked at recovery in = detail.

Multipath *is* in the charter, and we're fully committed to = supporting it. I simply can't see how getting the WG working on the = details at multipath at this time will help speed up work on the = protocol fundamentals. And it seems that we'd need to continuously = rework multipath while we're still changing protocol fundamentals, which = would create additional busy work. 

Lars

= --Apple-Mail=_2A31D696-2C39-416F-B070-04754BE76DED-- From nobody Sun Oct 29 04:14: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 6071313FE66 for ; Sun, 29 Oct 2017 04:14:22 -0700 (PDT) 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 7nrceVWflJcZ for ; Sun, 29 Oct 2017 04:14:21 -0700 (PDT) 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 2435A13FE61 for ; Sun, 29 Oct 2017 04:14:21 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.44,314,1505804400"; d="asc'?scan'208";a="223737809" Received: from vmwexchts02-prd.hq.netapp.com ([10.122.105.23]) by mx144-out.netapp.com with ESMTP; 29 Oct 2017 03:42:08 -0700 Received: from VMWEXCCAS12-PRD.hq.netapp.com (10.122.105.30) by VMWEXCHTS02-PRD.hq.netapp.com (10.122.105.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Sun, 29 Oct 2017 04:14:20 -0700 Received: from NAM02-BL2-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; Sun, 29 Oct 2017 04:14:20 -0700 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=PuH/O6SAKaclz7JXEkUp+H346YiT6OV0vR1NYBDClg8=; b=pGE0HciOqonVResh41BtIsLr7w8mn76Wa5h40+n/Sg6amzH+lHb5h4XNzYw95rQMPregNFXBIjWP23Az/W+zRpBkW5nDdvn4ejpUbh1sA6MFDCzzvtt2bRScTM7bz/hrp520j0EIf83GhbliUNmtQ6JG+gf8GmVsq9IQAa5mouk= 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.178.6; Sun, 29 Oct 2017 11:14:18 +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.0178.012; Sun, 29 Oct 2017 11:14:18 +0000 From: "Eggert, Lars" To: Simon Pietro Romano CC: Lucas Pardue , Mark Nottingham , QUIC WG , Spencer Dawkins at IETF Subject: Re: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuylSIJRNvocE0WivHlzUsNNn6L35buAgABqWgCAAhmSAIAAF1OAgAAj7wCAAAtbAA== Date: Sun, 29 Oct 2017 11:14:17 +0000 Message-ID: <45E4CBC6-720A-4C36-AEBD-40E889138B73@netapp.com> References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> 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.1.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2a02:120b:2c4a:92d0:71f6:91e4:d2ec:1510] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:LU6MbGk13zhGXsXumEcBfLYH9AEq2HDZfUKOsncsfTAYSPuj3Gyi0kuzG3eoa9rUzVTf6qjQj8zSf3RcSFiNLTB0CjIJeBWnt+is40sV22JL9dSnw3DAOXO3w+d/H42oqfd2wbKDPNJAzDpp40G5dGptKy4u42PIH9I/n1qdotcBCqF7i3Cvxch9hPblZpU+OkAbM7TkimxRjhv3WAe3g0BR1iIiN51OBowvL3cd3UVdpOWkzcuZuBWr5TxOldM4lvjekP8BmRns4gAOHdueqAPdi4AmAl68zbUfFavUCZoZaapd8zXxHegoFZoQC4wlyb+Gmnrm/HygBPr8rWDa/eaNq6aT1bdwOSDowX8AFI0=; 5:tqxvTq0gssk/C9IfVPABb209x8soahtZNBrBawUiTKUsbpq+PphD41F2DI54lY9iHFs3vXakBM9W7KVy0LxLYENAfUkbSxAvWQoEnLCKPciVXZtybJJwNZOaMADZ+pFbeARqGZl7J5ytS/Uw8TazONm2ZgmDiu+gSailnghs99U=; 24:rm2tjCvAUEFWwxalkKCgh8eDcV0o8Wr0KzeiLCpyae9fbqrzfuhwrP234wJb7ibX7dbJavAcwIwAN1ni8DjTPqWNF5cc7c3du2MLyPB9f/U=; 7:Dy1mZOKT2L7wtJoGHzPTYO/wVmWZU6xzFA3yaXvum6pe3RfYAe2i1vVApB1ril+rVaXXoin317Sh52IiMvtmMzE4ct+HOggzxg/Ih1APB3bL2vVbqJNuELrHNrZLORGuk27ArWjQLvT0jef5Ns35T1VqZBHt0ACTp+Vyr4hFQR0mCTaubPRY7i9XqXZq9YHBBdakmMcz3SRMr9YMTIoCtZZnUgzmvpprmh2izYZ9F34VMXpjbL7xj1Ms1RF4nm8N x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: de82c5b2-2f9c-4098-2c77-08d51ebe326c x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199)(49563074); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-exchange-antispam-report-test: UriScan:(192374486261705); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(8121501046)(5005006)(3231020)(3002001)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123562025)(20161123564025)(20161123555025)(20161123560025)(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: 0475418F50 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(346002)(376002)(199003)(377424004)(24454002)(51444003)(189002)(101416001)(3280700002)(3660700001)(6436002)(6506006)(14454004)(478600001)(2906002)(229853002)(81156014)(8676002)(81166006)(33656002)(6486002)(97736004)(105586002)(8936002)(106356001)(77096006)(102836003)(4001150100001)(316002)(6116002)(53546010)(5660300001)(93886005)(2900100001)(2950100002)(6916009)(57306001)(25786009)(82746002)(36756003)(189998001)(50986999)(86362001)(76176999)(54906003)(305945005)(53936002)(83716003)(99936001)(39060400002)(6246003)(50226002)(99286003)(7736002)(6512007)(68736007)(4326008); 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=_8B739115-94A6-4195-92BD-D2515527D1D5"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: de82c5b2-2f9c-4098-2c77-08d51ebe326c X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Oct 2017 11:14:18.0112 (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: Sun, 29 Oct 2017 11:14:22 -0000 --Apple-Mail=_8B739115-94A6-4195-92BD-D2515527D1D5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, On 2017-10-29, at 11:33, Simon Pietro Romano wrote: > Which is exactly what I=E2=80=99d call adding multipath capabilities = to a protocol =E2=80=9Cby design=E2=80=9D, rather than trying to add = multipath after the protocol has been specified. I think that security = should have taught us a lot, when it comes to distinguishing the "patch = it=E2=80=9D vs =E2=80=9Cthink of it at design time=E2=80=9D approach. so we did add multipath to TCP later, and it was painful, but not = because we had issues extending TCP's design - it was painful, because = the Internet had ossified around a pretty detailed set of assumption = about what TCP would look like on the wire. With, QUIC, if we get the greasing right, that danger is mostly off the = table. Now, we can still mess up the design of QUICv1 so that adding multipath = later would be harder than it needed to be, but I'm pretty confident = it's enough on our mind that that won't happen. Lars --Apple-Mail=_8B739115-94A6-4195-92BD-D2515527D1D5 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAln1uAkACgkQVLXDCb9w wVcUyg/+Nt4midjOQF+jOdeth3rrUPvJY6H4b994JOBT/xHmXSJZGJMoASOJtv3p MY+O95DFSGmRzKlMrVt/SWh575hC/868auG2p5jVstXZv23A5MUCJctbfYLwop3O U5jg+FpL7T0ls6CRuLkKzxWnWJRYe4+T/1p5MiV1LKbDGbXXMmt91OpSJrxte6US /TFqwQjaBATtnQu1+7kQCOtuFb7gSTtRmgE6Xs8r0f0Hms9xepJ2v+FWsSTJmKCP 639dPCS/BDH8BwLzm+28wIWrXDUHMoedmkT5/NWCK83dA5Hs/UrvGdrBor0ETXsy hB/NmnbtF2OCgIRfAZOQAsJhgaBAybfvB0H7bclxmD4T06QEFdSDch2dttdipM1Y wLsnN30LXlt+e7EFpi8kJGV22TLx0hLC/RI1/2UKgPchXFXnLTboov/6fYjtQAMz N9qLPwAWDGfVIUXc2uTSq+XT243chmba1Fp6jEFIrDP4wRyP4cr5vVRY9fjO6rUM pItuea6PKfAybSeVkoDQdbLflDC/hsFsw2jcDAn5E7/ivxnj1/gvCLfaOPrA9TGS hn5V+G+tzzXYutrUXYCb0+TGl/FflPom7zg08vOoiYbndwgIvEy+n2uxKnXRX0vD p2GpCf3DSjSVeNpUucgSOwBrz5/mM75PnbpUIkvI6E88tzbWg00= =XUrH -----END PGP SIGNATURE----- --Apple-Mail=_8B739115-94A6-4195-92BD-D2515527D1D5-- From nobody Sun Oct 29 05:35: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 D66AC13FD62 for ; Sun, 29 Oct 2017 05:35:46 -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, 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 E7OIie2Qutoj for ; Sun, 29 Oct 2017 05:35:45 -0700 (PDT) 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 C6E7B13F48D for ; Sun, 29 Oct 2017 05:35:44 -0700 (PDT) Received: from xsmtp02.mail2web.com ([168.144.250.215]) by mx18.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.89) (envelope-from ) id 1e8moX-0005K9-4b for quic@ietf.org; Sun, 29 Oct 2017 13:35:42 +0100 Received: from [10.5.2.49] (helo=xmail11.myhosting.com) by xsmtp02.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1e8moS-0002Te-EC for quic@ietf.org; Sun, 29 Oct 2017 08:35:40 -0400 Received: (qmail 15085 invoked from network); 29 Oct 2017 12:35:34 -0000 Received: from unknown (HELO [172.30.8.11]) (Authenticated-user:_huitema@huitema.net@[83.110.18.56]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Oct 2017 12:35:34 -0000 To: "Eggert, Lars" , Simon Pietro Romano References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> <45E4CBC6-720A-4C36-AEBD-40E889138B73@netapp.com> Cc: Lucas Pardue , Mark Nottingham , QUIC WG , Spencer Dawkins at IETF From: Christian Huitema Message-ID: <4d867d88-12c4-1629-a766-c4b4984bf73f@huitema.net> Date: Sun, 29 Oct 2017 05:35:11 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <45E4CBC6-720A-4C36-AEBD-40E889138B73@netapp.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lHPURVLIPspfqAmnjfBxpE69m4O8MoNTp" Subject: Re: QUIC - Our schedule and scope X-Originating-IP: 168.144.250.215 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.11) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5je/4L+6mKtyxfUxlPmI88EXv9krsgRhBn0ayn6qsUc7A2kcKDr1fzRm ksYYe0sWHrgNzB/4Jkrw1eDLcif59fskaiXrBVQ334ehSs2QpY88B98yDTitFWvbHwz9vKZpm4b3 Kv7PcFSfRyFbnU/eNYc8zYOZy1SS6ohN09nxrcu5ZsQEbaxxISMHgJxrdMdSS4B6hVJPXxgisa+g wkHvC+OlqTWdUBHTyoJG+mqGBYi8bWhnKPmUW/oWx9V3wTBfG4Y+ZnfomCI+rgOtA8u12EwuwjY+ quNh23liqqeOwMwwqy4lE5s79uoGaeHjfOqnzPcqs5RcLqZ0NIAm9sCHr2eyNIkhDia+jiI1x+25 WhJqOf3+cMSJJ9Vk8Y6lSpImWOFtQUIkkMAnR5eEArf6zd8XhA0UizXQaOxPdjju+1r1qq9IJIue NdZ12JJe7t4cD3McN6qoXPjenLhIOF1oeRYYaUQ6nbKS9Ik+txsc3YPtwSyQd76LvsiWbyPh2PwK 2KlWGv3esfm0EuJEorvoTUf+T9qKOv0z7nCHc/5d+MbcfJlbZZh01urflxdd2g4lVOY9YUFS+gfc BkEmyHl54sn3Y80OmAux3oN13+ztUzneH089dpeDLQX8vIaBEMXklLrGhxr0ZQNhHrBZkFm8Vpbj ymSZyai1orCbj1dqjXPqHXUNlykTTc0R1ecbzfsiMlFfEoXm0/FPF8PR0w363lnt6T5WeMaFYj2j FLtCivZ6DSkuIeRLz0UwfxFtWYR5gu8VjNzz0BoRxXlr+NDM3A/1u9D5+kYfpqdXeMasp+XD3jR5 NeVaJQBh0uawl0Cg8rdbWpE2ux+VrvYecZwKGQXQngcHaWeBIrVwdQfI6RxMYKPh1lHgUEF4t8hJ zRZ/yYkd2x35zAiBFPp64JaIysAhPltDTcKNRvi2K+1UJ6NK 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: Sun, 29 Oct 2017 12:35:47 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lHPURVLIPspfqAmnjfBxpE69m4O8MoNTp Content-Type: multipart/mixed; boundary="poqL4cwhtUlirQQEEtNfNNwiod57gpkhI"; protected-headers="v1" From: Christian Huitema To: "Eggert, Lars" , Simon Pietro Romano Cc: Lucas Pardue , Mark Nottingham , QUIC WG , Spencer Dawkins at IETF Message-ID: <4d867d88-12c4-1629-a766-c4b4984bf73f@huitema.net> Subject: Re: QUIC - Our schedule and scope References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> <45E4CBC6-720A-4C36-AEBD-40E889138B73@netapp.com> In-Reply-To: <45E4CBC6-720A-4C36-AEBD-40E889138B73@netapp.com> --poqL4cwhtUlirQQEEtNfNNwiod57gpkhI Content-Type: multipart/alternative; boundary="------------5F0BA1F73A03474FE2C5902F" This is a multi-part message in MIME format. --------------5F0BA1F73A03474FE2C5902F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10/29/2017 4:14 AM, Eggert, Lars wrote: > On 2017-10-29, at 11:33, Simon Pietro Romano wrote:= >> Which is exactly what I=E2=80=99d call adding multipath capabilities t= o a protocol =E2=80=9Cby design=E2=80=9D, rather than trying to add multi= path after the protocol has been specified. I think that security should = have taught us a lot, when it comes to distinguishing the "patch it=E2=80= =9D vs =E2=80=9Cthink of it at design time=E2=80=9D approach. > so we did add multipath to TCP later, and it was painful, but not becau= se we had issues extending TCP's design - it was painful, because the Int= ernet had ossified around a pretty detailed set of assumption about what = TCP would look like on the wire. > > With, QUIC, if we get the greasing right, that danger is mostly off the= table. > > Now, we can still mess up the design of QUICv1 so that adding multipath= later would be harder than it needed to be, but I'm pretty confident it'= s enough on our mind that that won't happen. I would like to see good multipath support in QUIC, but I think we are right delaying the work. True multipath support would most probably require a separation between path variables, such as packet sequence number and acknowledgements, and per connection variables, such as stream data and control. It will also require serious work on connection ID and privacy, not to mention a requirement to separate path ID and connection ID. None of that is impossible, or even very hard, but taken together it is a set of very disruptive changes for applications. From a schedule point of view, it seems much more reasonable to wait until V1 is stable. -- Christian Huitema --------------5F0BA1F73A03474FE2C5902F Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 10/29/2017 4:14 AM, Eggert, Lars wrote:

On 2017-10-29, at 11:33, Simon Pietro Romano <spromano@unina.it> wrote:

Which is exactly what I=E2=80=99d call adding mult=
ipath capabilities to a protocol =E2=80=9Cby design=E2=80=9D, rather than=
 trying to add multipath after the protocol has been specified. I think t=
hat security should have taught us a lot, when it comes to distinguishing=
 the "patch it=E2=80=9D vs =E2=80=9Cthink of it at design time=E2=80=9D a=
pproach.

so we did add multipath to TCP later, and it was pai=
nful, but not because we had issues extending TCP's design - it was painf=
ul, because the Internet had ossified around a pretty detailed set of ass=
umption about what TCP would look like on the wire.

With, QUIC, if we get the greasing right, that danger is mostly off the t=
able.

Now, we can still mess up the design of QUICv1 so that adding multipath l=
ater would be harder than it needed to be, but I'm pretty confident it's =
enough on our mind that that won't happen.

I would like to see good multipath support in QUIC, but I think we are right delaying the work. True multipath support would most probably require a separation between path variables, such as packet sequence number and acknowledgements, and per connection variables, such as stream data and control. It will also require serious work on connection ID and privacy, not to mention a requirement to separate path ID and connection ID. None of that is impossible, or even very hard, but taken together it is a set of very disruptive changes for applications. From a schedule point of view, it seems much more reasonable to wait until V1 is stable.

-- Christian Huitema
--------------5F0BA1F73A03474FE2C5902F-- --poqL4cwhtUlirQQEEtNfNNwiod57gpkhI-- --lHPURVLIPspfqAmnjfBxpE69m4O8MoNTp 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 iQEcBAEBCAAGBQJZ9csQAAoJELba05IUOHVQTuQIAJPnUR6BiHXXwygMVbSEK4ER fbJgHapIGH2pqoPTk1oNyauZDupXh4MLcVk0LbAfcvBV8LF6Q385p4SzjGuUnBLW DyVXQB3/NWrvaEZH4oeN+Sibp3u5iaQxgeoee7KG1GY64Rzc33Q9KEiYMnAui0wA rt1LG8/ee08WnwKxHOl3hR9yF8vcYNttKLLFQUFEKQ4NspHeoMjjet8i2hum9h4w bvNXosWiKm4qRUQW68o+SzfyeitheJRCRAKnFkGMhxAkXKOcKJCW948/tuT4YWmA h2fGYdDJq1m6CStOnBmfLOpregPLc5cwUbybQ19MiW3Bzvu7YgDeFEYPcxFoE8Y= =52Lu -----END PGP SIGNATURE----- --lHPURVLIPspfqAmnjfBxpE69m4O8MoNTp-- From nobody Sun Oct 29 11:08: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 EE9A013F5C6 for ; Sun, 29 Oct 2017 11:08:39 -0700 (PDT) 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 L6A6Ji3YsGal for ; Sun, 29 Oct 2017 11:08:38 -0700 (PDT) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86: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 10E2613F5BA for ; Sun, 29 Oct 2017 11:08:38 -0700 (PDT) Received: from [81.187.2.149] (port=45367 helo=[192.168.0.71]) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from ) id 1e8s0h-0007rZ-BR; Sun, 29 Oct 2017 18:08:35 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: QUIC - Our schedule and scope From: Colin Perkins In-Reply-To: Date: Sun, 29 Oct 2017 18:08:23 +0000 Cc: Mark Nottingham , QUIC WG , Lars Eggert , Spencer Dawkins at IETF Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Brian Trammell (IETF)" X-Mailer: Apple Mail (2.3273) X-BlackCat-Spam-Score: 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: Sun, 29 Oct 2017 18:08:40 -0000 > On 28 Oct 2017, at 09:04, Brian Trammell (IETF) = wrote: >=20 > hi Mark, all, >=20 > Broadly, I support Patrick's intepretation here. I'll point out that = there seems to be some inconsistency between two points below: >=20 >> On 27 Oct 2017, at 08:26, Mark Nottingham wrote: >>=20 >> 2) V1 of QUIC should *only* address the use case of HTTP. >=20 > and >=20 >> * 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. >=20 > 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. >=20 > 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. --=20 Colin Perkins https://csperkins.org/ From nobody Sun Oct 29 16:55: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 2ADDB13F5EC for ; Sun, 29 Oct 2017 16:55:57 -0700 (PDT) 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=qH23Cs8s; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=gZ8bqX7I Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3n9rqTkBPevq for ; Sun, 29 Oct 2017 16:55:54 -0700 (PDT) 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 2DDA113F42D for ; Sun, 29 Oct 2017 16:55:53 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 975FA20C0A; Sun, 29 Oct 2017 19:55:52 -0400 (EDT) Received: from frontend2 ([10.202.2.161]) by compute3.internal (MEProxy); Sun, 29 Oct 2017 19:55:52 -0400 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=/9sjEEnY1YwsDgRnH0nD8rt48a4yHr82x5hStrtE4jc=; b=qH23Cs8s 7kUoKy57AFS0w/QJ0rnvOproi/bbS4DwPFzdfSQFZH5C6OFLmNAglngjPav4rXie QHBl/ZJi6QKeVGLMmChTIoaBYIhLNvFiM0uxdFBeH1ZbwqBQZn149Qoiunqzt4hW /2YfbQAlc4h7M76eakQwEMrlu3SxaOobTmWIAeM3Ac/B6v8IlGAIBcw3to2RU0Y/ b5CdYvLXY8CKxEMIGrCNVZ0y6CzW6ZXdknrFHzXnYi5jWPeUEJfcZ9JUKy84bTSo 4b8sqDYaE7LKaWvRGePtrl6+R7Kf/+8Gsof4o5WVYx5l27wtvURH4PI3uvuqowJJ lHDCjvLcfCFkig== 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=/9sjEEnY1YwsDgRnH0nD8rt48a4yH r82x5hStrtE4jc=; b=gZ8bqX7IUV7wkZHHAdPTnUYP0hky4ctqKTe1IUSgGq8Zg d+BRgrRvo79V1jtWWfIcvQlv8PCxdaSMpi9/CrqASzNevSif1b5lT5W1XdLMFiRd 9jDEonSJU5fhnVW8zwzuuUcFKxmP8xveMeuuDtvFo+3uX9dhN/Gm/UcMupKTb1eo Pl0/BTeKiEEPvCz1xIEwvBUer0LXwMGvaJ8LtzC+WOrkUWLl2IKFOV/8zBSzqqof MeU8CkVxH85GgPcPUdmPjFb1AdlxAOFCRFVaDoZD2fD8DfEwR0bEj68jv+ZOyOSS Mh5GZ1tMu4EhRM/2qdbkyYrmvlBTo2B4tZDCvu0kA== 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 ACE8E247D9; Sun, 29 Oct 2017 19:55:51 -0400 (EDT) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: DRAFT agenda for IETF100 - Singapore Message-Id: Date: Mon, 30 Oct 2017 10:55:48 +1100 Cc: Lars Eggert To: QUIC WG X-Mailer: Apple Mail (2.3445.1.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, 29 Oct 2017 23:55:57 -0000 ... is at: https://github.com/quicwg/wg-materials/blob/master/ietf100/agenda.md As always, suggestions appreciated. -- Mark Nottingham https://www.mnot.net/ From nobody Sun Oct 29 18:53: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 2EE581394EB for ; Sun, 29 Oct 2017 18:53:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UynaB2ppicud for ; Sun, 29 Oct 2017 18:53:52 -0700 (PDT) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BB93138B5E for ; Sun, 29 Oct 2017 18:53:52 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id y75so10245742ywg.0 for ; Sun, 29 Oct 2017 18:53:52 -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=UBxozt4KOm9ASemvkkzgutO37nn/Wg8KIpMZjWFoMx8=; b=CojVeIafuUo1lKyGG2WLhQDEE4s2uZs0dRiHyEfoD3U2ZslLUU7aq1iuGrnXeOuWdM MazP2AArLYl5MNTy/+Lxlmm///wLnV1X2IFC9m7eO9MG0cl4I7DOU9vN0dR9zZNIBn2+ 7RH+HVuQDdxvsJ7deVPT5/hMq4QFD049S+z7ENx4/B7LO5V4bY9+e+AQIg+eIEPwMu7W 7c4qyxEc+LmZggExLO05eTT0n5ppHOW3L6mr4DltwnI8d6Hw18Cx0zK9ArC/xq5liK1+ VwkQTJfonew9FK+lVXHFai15EdUti8c1OkHaNWWf7T/2dw+nXGjxeDY1ZmHpF9vRhj4/ jHHA== 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=UBxozt4KOm9ASemvkkzgutO37nn/Wg8KIpMZjWFoMx8=; b=uZrHjJlFIw9kw6AOQs9jVbDPvTuIH8IHSn12LmAF9z8qvuSq6rSAPiih481RjFgkwB Hf855Zmpb4TPsYpgezCu8kdWFzIPCL0/UH8Jxr84aBuIpqP6ZOQMkCrYmn11i47cCssg IqTg8w0ZX95T4XH6UXIXxN2w9hWy1QgdRGls/XzIo1LDfEyksPRvbexVP+F14kDBo6OI umfMAb6j7+ixvDPAJ87aFLN9kZnguGQjEckWYTB/lrGg5fhQpNWAn0ItRXXaeqfjfnjH CwW/5csTe+z7Y9cAbe+YGlP9M+bdf3FiLnG6S8maKPz+TaQsiw35WNq6770bEwnfxoQ5 NOxw== X-Gm-Message-State: AMCzsaXZqDjU3Alwu4ULngG2qXBEBopow39pQDVl525pTVhh5PutwMhQ t0U+o2r49Rjd6nKIM8dCek2VKkijnOrVxDvEB3A= X-Google-Smtp-Source: ABhQp+TxuHDA0CWy96nyrkO61y440BQ9E3sdrWvoDPYTmUJ4ak5hoxqs0useAJ02VXEujXJylEy+52Vw4bsAFeLSl68= X-Received: by 10.37.162.41 with SMTP id b38mr4793416ybi.195.1509328431251; Sun, 29 Oct 2017 18:53:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.162.204 with HTTP; Sun, 29 Oct 2017 18:53:50 -0700 (PDT) In-Reply-To: References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> From: Spencer Dawkins at IETF Date: Sun, 29 Oct 2017 20:53:50 -0500 Message-ID: Subject: Re: QUIC - Our schedule and scope To: "Eggert, Lars" Cc: Simon Pietro Romano , Mark Nottingham , Lucas Pardue , QUIC WG Content-Type: multipart/alternative; boundary="94eb2c197f86fe8700055cb9e8b9" 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, 30 Oct 2017 01:53:54 -0000 --94eb2c197f86fe8700055cb9e8b9 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Just to chime in on one point (and remembering that my responsibilities do not include telling working groups what to think), On Sun, Oct 29, 2017 at 3:25 AM, Eggert, Lars wrote: > Hi, > > On 2017-10-29, at 8:01, Simon Pietro Romano wrote: > > The sad thing about multipath is that there have been people who have > worked, more than one year ago, on implementing it in a v1-compliant way. > Though, the group has never wanted to give multipath a real chance to > survive and has always treated it as a =E2=80=9Cpotential future extensio= n=E2=80=9D. This > has been made so clear in the mailing list that we have stopped trying to > push for it. > > > I don't think that's a fair summary. > > First, there is no v1. We're busy specifying it at the moment, and many, > many fundamental things are still changing. These are taking all the cycl= es > the WG has at the moment, and we're still not progressing at a satisfacto= ry > pace. (Which was the message that started this thread.) I also don't thin= k > that the implementations are at a stage where they can realistically thin= k > about adding multipath - most haven't even really looked at recovery in > detail. > > Multipath *is* in the charter, and we're fully committed to supporting it= . > I simply can't see how getting the WG working on the details at multipath > at this time will help speed up work on the protocol fundamentals. And it > seems that we'd need to continuously rework multipath while we're still > changing protocol fundamentals, which would create additional busy work. > When we were discussing the QUIC charter, I was very reluctant to charter a new transport protocol in 2016 that didn't address multipath (other people have suffered more while adding multipath to a protocol that didn't anticipate multipath than I have, but I've seen enough suffering). That may be the point I pressed on most strongly while editing the current charter. So even though we wanted to minimize the initial charter scope, I included multipath in the charter I took to the IESG. I had assumed (without asking anyone) that - Enabling multipath and forward error correction extensions (listed as one of the key goals in the current charter) would put "making sure that extensions were possible" in scope for v1. I don't have an opinion about how "making sure" happens, of course. - If the working group was convinced that "greasing" in v1 is sufficient to enable extensions (at appropriate points in time), I would support th= at. - If the working group was convinced that something else is required, I'd listen, of course. Thanks, Spencer, speaking as responsible AD Lars > --94eb2c197f86fe8700055cb9e8b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Just to chime in on one point (and remembering that my res= ponsibilities do not include telling working groups what to think),

On Sun, Oct 29, 2017 at 3= :25 AM, Eggert, Lars <lars@netapp.com> wrote:
Hi= ,

On 2017-10-29, at 8:01, Simon P= ietro Romano <spr= omano@unina.it> wrote:
The sad thing about multipath is that there have been = people who have worked, more than one year ago, on implementing it in a v1-= compliant way. Though, the group has never wanted to give multipath a real = chance to survive and has always treated it as a =E2=80=9Cpotential future = extension=E2=80=9D. This has been made so clear in the mailing list that we= have stopped trying to push for it.

I don't think that's a fair summary.

<= /div>
First, there is no v1. We're busy specifying it at the moment= , and many, many fundamental things are still changing. These are taking al= l the cycles the WG has at the moment, and we're still not progressing = at a satisfactory pace. (Which was the message that started this thread.) I= also don't think that the implementations are at a stage where they ca= n realistically think about adding multipath - most haven't even really= looked at recovery in detail.

Multipath *is* in t= he charter, and we're fully committed to supporting it. I simply can= 9;t see how getting the WG working on the details at multipath at this time= will help speed up work on the protocol fundamentals. And it seems that we= 'd need to continuously rework multipath while we're still changing= protocol fundamentals, which would create additional busy work.=C2=A0=C2= =A0

When we were discussing the= QUIC charter, I was very reluctant to charter a new transport protocol in = 2016 that didn't address multipath (other people have suffered more whi= le adding multipath to a protocol that didn't anticipate multipath than= I have, but I've seen enough suffering). That may be the point I press= ed on most strongly while editing the current charter. So even though we wa= nted to minimize the initial charter scope, I included multipath in the cha= rter I took to the IESG.

I had assumed (without as= king anyone) that

- Enabling multipath and forward error correction e= xtensions

= (listed as one of the key goals in the current charter) would put "mak= ing sure that extensions were possible" in scope for v1.=C2=A0
I don't have an opinion about how "making sure" h= appens, of course.
  • If the working group was convinced that &quo= t;greasing" in v1 is sufficient to enable extensions (at appropriate p= oints in time), I would support that.
  • If the working group was conv= inced that something else is required, I'd listen, of course.
=
Thanks,

Spencer, speaking as re= sponsible AD

La= rs
--94eb2c197f86fe8700055cb9e8b9-- From nobody Sun Oct 29 23:27: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 9B98013968C for ; Sun, 29 Oct 2017 23:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 m-hZqlRl64tA for ; Sun, 29 Oct 2017 23:27:25 -0700 (PDT) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0130.outbound.protection.outlook.com [104.47.33.130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B401313F641 for ; Sun, 29 Oct 2017 23:27:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Mk6AVyjYd1xksigRoIl1Wpo2qvA4+Hc0nQp9EcI/M1I=; b=IU5LlLCq2aFg0VQaSHuKUDhADol+BTRwhYjzM+44jL86oaKenh1xrPFyMKD8q9OpAxyBE2EvRc/IemPAvbSx3Y7HXCV6ZEQ/AX4xGetasmDEyB8Yjk8bbXfk6nrpgLMT6wv7qhV+z18HaVLKs207ZlTRIHsGU1/AP5Gl0hV41C8= Received: from MWHPR21MB0141.namprd21.prod.outlook.com (10.173.52.11) by MWHPR21MB0191.namprd21.prod.outlook.com (10.173.52.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.197.0; Mon, 30 Oct 2017 06:27:21 +0000 Received: from MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) by MWHPR21MB0141.namprd21.prod.outlook.com ([10.173.52.11]) with mapi id 15.20.0197.006; Mon, 30 Oct 2017 06:27:21 +0000 From: Mike Bishop To: Spencer Dawkins at IETF , "Eggert, Lars" CC: Lucas Pardue , Simon Pietro Romano , QUIC WG , Mark Nottingham Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuyheooSNpGQN0mRPLjjogNQzqL35buAgABqWgCAAhmSAIAAF1WAgAElBwCAAEo14A== Date: Mon, 30 Oct 2017 06:27:21 +0000 Message-ID: References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> In-Reply-To: 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=michbish@microsoft.com; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2017-10-30T06:27:20.4379674Z; 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: [2601:600:8080:5a28:3106:d30:7235:8929] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR21MB0191; 6:rtPbNQreGWfrhWHSesmDFFvXs1EV6a1hd7tlNdXLMVz7v7gdQ6CXkZGcdFAujnIC/wXLZJFxQGonmEMTRrU+8Jrn/yLUOrh1CwH9TyspoPflin8iHLDSKbh71VhsqWtO2SY+UC9nfDwtv9W4X08EdCOw1GEFZvITA9NGUm9JnwvDsO0H9pxVvgNcedtUIDjq94BMmNAWM2lKT0fwwT/InYE/Oj12qCgnLdg7pifttrIecYuCZcXesKwwUj6HFF7mojsUXEDW0CfncUUw09vXKhB1NH6W7ugDGNx0bQZVw3fIjQouDjd1g7dQxxT79KMMOcbtkQUr8zj00wdTDZYcuHIisnAbLk8gmDxBM1kpn/0=; 5:LPYKSUQAI7MnV65QEW6b0+0woZxDEyESyNBOWNdSt24rkKRpAzXkLMhdPNCEEvWGoFUnZwJSc/Y8CoxdzxdDT7UgHXL1cb0VDZCx4Eg6YL3hdqmw2ikurUdh0EF+o+iiraWZMRx5D8EdYEio5R7cQ4zWgPh9EXz1W33VrrqBJAA=; 24:pj+c6ku64ptn9rVsTUwJdaRG+6K+5NwMEPKmQPtq4/F+0ufZjop9f/rwbUn0xa/N9/uHVZ+PgODUQRx3jZqx/i1hYm1vEnqVsJI2XOYGPn0=; 7:rOsel+DNQjM4VSn9Q/YBv1t8rYYEda8RJz9Su5heO52G+IkqaeKTRaFlUJUkuVN10+B6ub0NK37iq61A4bsxpRBOIlNy/5v9YAO2q1Pk3necvrht9BDLH+fb7NpexAVBqxk37kMF6YMvPY/5xYt7Kl+K4iunUXzHPEvJa+euewhw6I+p4rlRVNq/Cxt1NkAdLUhKF8M1+RuJwN43mIDNqs2/+dnzjrQJLbBxPnXt2IMxxnvsX82q0MQW4ImcXY+8 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: db4f3df8-fc9e-4601-6e17-08d51f5f4706 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081)(4534020)(4602075)(2017052603238); SRVR:MWHPR21MB0191; x-ms-traffictypediagnostic: MWHPR21MB0191: x-exchange-antispam-report-test: UriScan:(127952516941037)(21748063052155); x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(2401047)(5005006)(8121501046)(3002001)(3231020)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123562025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:MWHPR21MB0191; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:MWHPR21MB0191; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39860400002)(47760400005)(199003)(189002)(24454002)(377424004)(53936002)(3280700002)(5660300001)(3660700001)(76176999)(25786009)(86612001)(8676002)(54356999)(81156014)(102836003)(790700001)(81166006)(74316002)(8936002)(99286003)(6116002)(2950100002)(6306002)(7696004)(106356001)(77096006)(10090500001)(478600001)(54896002)(9686003)(229853002)(4001150100001)(53546010)(22452003)(50986999)(105586002)(39060400002)(316002)(8990500004)(55016002)(6436002)(68736007)(101416001)(6506006)(97736004)(33656002)(2906002)(72206003)(110136005)(7736002)(4326008)(236005)(189998001)(86362001)(14454004)(6246003)(19609705001)(54906003)(93886005)(2900100001)(10290500003); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR21MB0191; H:MWHPR21MB0141.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Bishop@microsoft.com; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_MWHPR21MB0141B0A4082BFB6B7A714B2887590MWHPR21MB0141namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-Network-Message-Id: db4f3df8-fc9e-4601-6e17-08d51f5f4706 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 06:27:21.5640 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR21MB0191 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, 30 Oct 2017 06:27:28 -0000 --_000_MWHPR21MB0141B0A4082BFB6B7A714B2887590MWHPR21MB0141namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SW4gSDIsIEkgYXJndWVkIGZvciB0aGUgYWJpbGl0eSB0byBuZWdvdGlhdGUgaW5kaXZpZHVhbCBl eHRlbnNpb25zIHJhdGhlciB0aGFuIHJlbHlpbmcgb24gdGhlIEFMUE4gdG9rZW4sIGJlY2F1c2Ug dGhlcmUgd291bGQgYmUgbWFueSBwb3RlbnRpYWwgZXh0ZW5zaW9ucyBhbmQgYSByZXN1bHRpbmcg ZXhwbG9zaW9uIGluIEFMUE4gdG9rZW5zIHRyeWluZyB0byBleHByZXNzIGFsbCB0aGUgY29tYmlu YXRpb25zIHlvdSBtaWdodCBzdXBwb3J0LiAgQnV0IGZvciB0aGluZ3MgYXMgZnVuZGFtZW50YWwg dG8gdGhlIGRlZmluaXRpb24gb2YgYmFzaWMgY29uY2VwdHMgYXMgbXVsdGlwYXRoLCBJ4oCZbSBw ZXJmZWN0bHkgY29udGVudCBtYWtpbmcgdGhhdCBhIHZlcnNpb24gbnVtYmVyIGRpZmZlcmVuY2Uu ICBBbmQgSSB0aGluayB3ZSBoYXZlIGEgdmVyc2lvbi1uZWdvdGlhdGlvbiBtZWNoYW5pc20gdGhh dOKAmXMgcm9idXN0IGVub3VnaCB0aGF0IGFkdmVydGlzaW5nIGFuZCBzZWxlY3RpbmcgZm9yIHRo YXQgdmVyc2lvbiB3aWxsIGJlIHJlYXNvbmFibGUgYW5kIGNvbXBhdGlibGUuICBTbyBvbiB0aGUg bXVsdGlwYXRoIGZyb250LCBJIGFjdHVhbGx5IHdvdWxkbuKAmXQgYmFjayBteXNlbGYgaW50byB0 aGUgZGVzaWduIGFzc3VtZWQgaW4gdGhlIGNoYXJ0ZXIg4oCTIHdlIG1pZ2h0IGRlY2lkZSB0aGF0 IHZlcnNpb24tbmVnb3RpYXRpb24gaXMgYSBzdWZmaWNpZW50IG1lYW5zIG9mIGVuYWJsaW5nIGZ1 dHVyZSBncm93dGggYW5kIHVzZSB0aGF0IGZvciBtdWx0aXBhdGguDQoNCkFsdGVybmF0aXZlbHks IG9yIGV2ZW4gaWYgd2UgZG8sIEZFQyBtaWdodCBiZSBhIGdvb2QgcGxhY2UgdG8gdHJ5IG91dCBh biBpbi12ZXJzaW9uIGV4dGVuc2lvbiBtb2RlbCwgc2luY2UgaXQgc2VlbXMgbGVzcyBvZiBhIGZ1 bmRhbWVudGFsIG1pbmRzZXQgc2hpZnQuDQoNCkZyb206IFFVSUMgW21haWx0bzpxdWljLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTcGVuY2VyIERhd2tpbnMgYXQgSUVURg0KU2VudDog U3VuZGF5LCBPY3RvYmVyIDI5LCAyMDE3IDY6NTQgUE0NClRvOiBFZ2dlcnQsIExhcnMgPGxhcnNA bmV0YXBwLmNvbT4NCkNjOiBMdWNhcyBQYXJkdWUgPEx1Y2FzLlBhcmR1ZUBiYmMuY28udWs+OyBT aW1vbiBQaWV0cm8gUm9tYW5vIDxzcHJvbWFub0B1bmluYS5pdD47IFFVSUMgV0cgPHF1aWNAaWV0 Zi5vcmc+OyBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5uZXQ+DQpTdWJqZWN0OiBSZTogUVVJ QyAtIE91ciBzY2hlZHVsZSBhbmQgc2NvcGUNCg0KSnVzdCB0byBjaGltZSBpbiBvbiBvbmUgcG9p bnQgKGFuZCByZW1lbWJlcmluZyB0aGF0IG15IHJlc3BvbnNpYmlsaXRpZXMgZG8gbm90IGluY2x1 ZGUgdGVsbGluZyB3b3JraW5nIGdyb3VwcyB3aGF0IHRvIHRoaW5rKSwNCg0KT24gU3VuLCBPY3Qg MjksIDIwMTcgYXQgMzoyNSBBTSwgRWdnZXJ0LCBMYXJzIDxsYXJzQG5ldGFwcC5jb208bWFpbHRv OmxhcnNAbmV0YXBwLmNvbT4+IHdyb3RlOg0KSGksDQoNCk9uIDIwMTctMTAtMjksIGF0IDg6MDEs IFNpbW9uIFBpZXRybyBSb21hbm8gPHNwcm9tYW5vQHVuaW5hLml0PG1haWx0bzpzcHJvbWFub0B1 bmluYS5pdD4+IHdyb3RlOg0KVGhlIHNhZCB0aGluZyBhYm91dCBtdWx0aXBhdGggaXMgdGhhdCB0 aGVyZSBoYXZlIGJlZW4gcGVvcGxlIHdobyBoYXZlIHdvcmtlZCwgbW9yZSB0aGFuIG9uZSB5ZWFy IGFnbywgb24gaW1wbGVtZW50aW5nIGl0IGluIGEgdjEtY29tcGxpYW50IHdheS4gVGhvdWdoLCB0 aGUgZ3JvdXAgaGFzIG5ldmVyIHdhbnRlZCB0byBnaXZlIG11bHRpcGF0aCBhIHJlYWwgY2hhbmNl IHRvIHN1cnZpdmUgYW5kIGhhcyBhbHdheXMgdHJlYXRlZCBpdCBhcyBhIOKAnHBvdGVudGlhbCBm dXR1cmUgZXh0ZW5zaW9u4oCdLiBUaGlzIGhhcyBiZWVuIG1hZGUgc28gY2xlYXIgaW4gdGhlIG1h aWxpbmcgbGlzdCB0aGF0IHdlIGhhdmUgc3RvcHBlZCB0cnlpbmcgdG8gcHVzaCBmb3IgaXQuDQoN CkkgZG9uJ3QgdGhpbmsgdGhhdCdzIGEgZmFpciBzdW1tYXJ5Lg0KDQpGaXJzdCwgdGhlcmUgaXMg bm8gdjEuIFdlJ3JlIGJ1c3kgc3BlY2lmeWluZyBpdCBhdCB0aGUgbW9tZW50LCBhbmQgbWFueSwg bWFueSBmdW5kYW1lbnRhbCB0aGluZ3MgYXJlIHN0aWxsIGNoYW5naW5nLiBUaGVzZSBhcmUgdGFr aW5nIGFsbCB0aGUgY3ljbGVzIHRoZSBXRyBoYXMgYXQgdGhlIG1vbWVudCwgYW5kIHdlJ3JlIHN0 aWxsIG5vdCBwcm9ncmVzc2luZyBhdCBhIHNhdGlzZmFjdG9yeSBwYWNlLiAoV2hpY2ggd2FzIHRo ZSBtZXNzYWdlIHRoYXQgc3RhcnRlZCB0aGlzIHRocmVhZC4pIEkgYWxzbyBkb24ndCB0aGluayB0 aGF0IHRoZSBpbXBsZW1lbnRhdGlvbnMgYXJlIGF0IGEgc3RhZ2Ugd2hlcmUgdGhleSBjYW4gcmVh bGlzdGljYWxseSB0aGluayBhYm91dCBhZGRpbmcgbXVsdGlwYXRoIC0gbW9zdCBoYXZlbid0IGV2 ZW4gcmVhbGx5IGxvb2tlZCBhdCByZWNvdmVyeSBpbiBkZXRhaWwuDQoNCk11bHRpcGF0aCAqaXMq IGluIHRoZSBjaGFydGVyLCBhbmQgd2UncmUgZnVsbHkgY29tbWl0dGVkIHRvIHN1cHBvcnRpbmcg aXQuIEkgc2ltcGx5IGNhbid0IHNlZSBob3cgZ2V0dGluZyB0aGUgV0cgd29ya2luZyBvbiB0aGUg ZGV0YWlscyBhdCBtdWx0aXBhdGggYXQgdGhpcyB0aW1lIHdpbGwgaGVscCBzcGVlZCB1cCB3b3Jr IG9uIHRoZSBwcm90b2NvbCBmdW5kYW1lbnRhbHMuIEFuZCBpdCBzZWVtcyB0aGF0IHdlJ2QgbmVl ZCB0byBjb250aW51b3VzbHkgcmV3b3JrIG11bHRpcGF0aCB3aGlsZSB3ZSdyZSBzdGlsbCBjaGFu Z2luZyBwcm90b2NvbCBmdW5kYW1lbnRhbHMsIHdoaWNoIHdvdWxkIGNyZWF0ZSBhZGRpdGlvbmFs IGJ1c3kgd29yay4NCg0KV2hlbiB3ZSB3ZXJlIGRpc2N1c3NpbmcgdGhlIFFVSUMgY2hhcnRlciwg SSB3YXMgdmVyeSByZWx1Y3RhbnQgdG8gY2hhcnRlciBhIG5ldyB0cmFuc3BvcnQgcHJvdG9jb2wg aW4gMjAxNiB0aGF0IGRpZG4ndCBhZGRyZXNzIG11bHRpcGF0aCAob3RoZXIgcGVvcGxlIGhhdmUg c3VmZmVyZWQgbW9yZSB3aGlsZSBhZGRpbmcgbXVsdGlwYXRoIHRvIGEgcHJvdG9jb2wgdGhhdCBk aWRuJ3QgYW50aWNpcGF0ZSBtdWx0aXBhdGggdGhhbiBJIGhhdmUsIGJ1dCBJJ3ZlIHNlZW4gZW5v dWdoIHN1ZmZlcmluZykuIFRoYXQgbWF5IGJlIHRoZSBwb2ludCBJIHByZXNzZWQgb24gbW9zdCBz dHJvbmdseSB3aGlsZSBlZGl0aW5nIHRoZSBjdXJyZW50IGNoYXJ0ZXIuIFNvIGV2ZW4gdGhvdWdo IHdlIHdhbnRlZCB0byBtaW5pbWl6ZSB0aGUgaW5pdGlhbCBjaGFydGVyIHNjb3BlLCBJIGluY2x1 ZGVkIG11bHRpcGF0aCBpbiB0aGUgY2hhcnRlciBJIHRvb2sgdG8gdGhlIElFU0cuDQoNCkkgaGFk IGFzc3VtZWQgKHdpdGhvdXQgYXNraW5nIGFueW9uZSkgdGhhdA0KDQotIEVuYWJsaW5nIG11bHRp cGF0aCBhbmQgZm9yd2FyZCBlcnJvciBjb3JyZWN0aW9uIGV4dGVuc2lvbnMNCg0KKGxpc3RlZCBh cyBvbmUgb2YgdGhlIGtleSBnb2FscyBpbiB0aGUgY3VycmVudCBjaGFydGVyKSB3b3VsZCBwdXQg Im1ha2luZyBzdXJlIHRoYXQgZXh0ZW5zaW9ucyB3ZXJlIHBvc3NpYmxlIiBpbiBzY29wZSBmb3Ig djEuDQoNCkkgZG9uJ3QgaGF2ZSBhbiBvcGluaW9uIGFib3V0IGhvdyAibWFraW5nIHN1cmUiIGhh cHBlbnMsIG9mIGNvdXJzZS4NCg0KICAqICAgSWYgdGhlIHdvcmtpbmcgZ3JvdXAgd2FzIGNvbnZp bmNlZCB0aGF0ICJncmVhc2luZyIgaW4gdjEgaXMgc3VmZmljaWVudCB0byBlbmFibGUgZXh0ZW5z aW9ucyAoYXQgYXBwcm9wcmlhdGUgcG9pbnRzIGluIHRpbWUpLCBJIHdvdWxkIHN1cHBvcnQgdGhh dC4NCiAgKiAgIElmIHRoZSB3b3JraW5nIGdyb3VwIHdhcyBjb252aW5jZWQgdGhhdCBzb21ldGhp bmcgZWxzZSBpcyByZXF1aXJlZCwgSSdkIGxpc3Rlbiwgb2YgY291cnNlLg0KVGhhbmtzLA0KDQpT cGVuY2VyLCBzcGVha2luZyBhcyByZXNwb25zaWJsZSBBRA0KDQpMYXJzDQo= --_000_MWHPR21MB0141B0A4082BFB6B7A714B2887590MWHPR21MB0141namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Ok1lbmxvLVJlZ3Vs YXI7DQoJcGFub3NlLTE6MCAwIDAgMCAwIDAgMCAwIDAgMDt9DQovKiBTdHlsZSBEZWZpbml0aW9u cyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7 bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1h cmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxl ZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7fQ0Kc3Bhbi5nbWFpbC0NCgl7bXNvLXN0eWxlLW5hbWU6Z21haWwtO30NCnNwYW4uZ21h aWwtaG9lbnpiDQoJe21zby1zdHlsZS1uYW1lOmdtYWlsLWhvZW56Yjt9DQpzcGFuLkVtYWlsU3R5 bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlz dC1pZDoxNTQyMjA5NTcyOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotOTU2NjMzNTEyO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4t Ym90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SW4gSDIsIEkgYXJndWVkIGZvciB0aGUgYWJpbGl0eSB0byBuZWdvdGlhdGUgaW5k aXZpZHVhbCBleHRlbnNpb25zIHJhdGhlciB0aGFuIHJlbHlpbmcgb24gdGhlIEFMUE4gdG9rZW4s IGJlY2F1c2UgdGhlcmUgd291bGQgYmUgbWFueSBwb3RlbnRpYWwgZXh0ZW5zaW9ucyBhbmQgYSBy ZXN1bHRpbmcgZXhwbG9zaW9uIGluIEFMUE4gdG9rZW5zIHRyeWluZyB0byBleHByZXNzIGFsbCB0 aGUgY29tYmluYXRpb25zIHlvdQ0KIG1pZ2h0IHN1cHBvcnQuJm5ic3A7IEJ1dCBmb3IgdGhpbmdz IGFzIGZ1bmRhbWVudGFsIHRvIHRoZSBkZWZpbml0aW9uIG9mIGJhc2ljIGNvbmNlcHRzIGFzIG11 bHRpcGF0aCwgSeKAmW0gcGVyZmVjdGx5IGNvbnRlbnQgbWFraW5nIHRoYXQgYSB2ZXJzaW9uIG51 bWJlciBkaWZmZXJlbmNlLiZuYnNwOyBBbmQgSSB0aGluayB3ZSBoYXZlIGEgdmVyc2lvbi1uZWdv dGlhdGlvbiBtZWNoYW5pc20gdGhhdOKAmXMgcm9idXN0IGVub3VnaCB0aGF0IGFkdmVydGlzaW5n IGFuZCBzZWxlY3RpbmcNCiBmb3IgdGhhdCB2ZXJzaW9uIHdpbGwgYmUgcmVhc29uYWJsZSBhbmQg Y29tcGF0aWJsZS4mbmJzcDsgU28gb24gdGhlIG11bHRpcGF0aCBmcm9udCwgSSBhY3R1YWxseSB3 b3VsZG7igJl0IGJhY2sgbXlzZWxmIGludG8gdGhlIGRlc2lnbiBhc3N1bWVkIGluIHRoZSBjaGFy dGVyIOKAkyB3ZSBtaWdodCBkZWNpZGUgdGhhdCB2ZXJzaW9uLW5lZ290aWF0aW9uIGlzIGEgc3Vm ZmljaWVudCBtZWFucyBvZiBlbmFibGluZyBmdXR1cmUgZ3Jvd3RoIGFuZCB1c2UgdGhhdCBmb3IN CiBtdWx0aXBhdGguPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsdGVybmF0aXZlbHksIG9yIGV2 ZW4gaWYgd2UgZG8sIEZFQyBtaWdodCBiZSBhIGdvb2QgcGxhY2UgdG8gdHJ5IG91dCBhbiBpbi12 ZXJzaW9uIGV4dGVuc2lvbiBtb2RlbCwgc2luY2UgaXQgc2VlbXMgbGVzcyBvZiBhIGZ1bmRhbWVu dGFsIG1pbmRzZXQgc2hpZnQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9iPiBR VUlDIFttYWlsdG86cXVpYy1ib3VuY2VzQGlldGYub3JnXSA8Yj5PbiBCZWhhbGYgT2YNCjwvYj5T cGVuY2VyIERhd2tpbnMgYXQgSUVURjxicj4NCjxiPlNlbnQ6PC9iPiBTdW5kYXksIE9jdG9iZXIg MjksIDIwMTcgNjo1NCBQTTxicj4NCjxiPlRvOjwvYj4gRWdnZXJ0LCBMYXJzICZsdDtsYXJzQG5l dGFwcC5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBMdWNhcyBQYXJkdWUgJmx0O0x1Y2FzLlBhcmR1 ZUBiYmMuY28udWsmZ3Q7OyBTaW1vbiBQaWV0cm8gUm9tYW5vICZsdDtzcHJvbWFub0B1bmluYS5p dCZndDs7IFFVSUMgV0cgJmx0O3F1aWNAaWV0Zi5vcmcmZ3Q7OyBNYXJrIE5vdHRpbmdoYW0gJmx0 O21ub3RAbW5vdC5uZXQmZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBRVUlDIC0gT3VyIHNj aGVkdWxlIGFuZCBzY29wZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SnVzdCB0byBj aGltZSBpbiBvbiBvbmUgcG9pbnQgKGFuZCByZW1lbWJlcmluZyB0aGF0IG15IHJlc3BvbnNpYmls aXRpZXMgZG8gbm90IGluY2x1ZGUgdGVsbGluZyB3b3JraW5nIGdyb3VwcyB3aGF0IHRvIHRoaW5r KSw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBTdW4sIE9jdCAyOSwg MjAxNyBhdCAzOjI1IEFNLCBFZ2dlcnQsIExhcnMgJmx0OzxhIGhyZWY9Im1haWx0bzpsYXJzQG5l dGFwcC5jb20iIHRhcmdldD0iX2JsYW5rIj5sYXJzQG5ldGFwcC5jb208L2E+Jmd0OyB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxl ZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGksPHNwYW4gY2xhc3M9ImdtYWlsLSI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMjAxNy0xMC0yOSwgYXQgODowMSwgU2ltb24gUGlldHJv IFJvbWFubyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnNwcm9tYW5vQHVuaW5hLml0IiB0YXJnZXQ9Il9i bGFuayI+c3Byb21hbm9AdW5pbmEuaXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxk aXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01lbmxvLVJlZ3VsYXImcXVvdDssc2VyaWYiPlRoZSBz YWQgdGhpbmcgYWJvdXQgbXVsdGlwYXRoIGlzIHRoYXQgdGhlcmUgaGF2ZSBiZWVuIHBlb3BsZSB3 aG8gaGF2ZSB3b3JrZWQsIG1vcmUgdGhhbiBvbmUgeWVhciBhZ28sIG9uIGltcGxlbWVudGluZyBp dCBpbiBhIHYxLWNvbXBsaWFudCB3YXkuIFRob3VnaCwgdGhlIGdyb3VwIGhhcyBuZXZlcg0KIHdh bnRlZCB0byBnaXZlIG11bHRpcGF0aCBhIHJlYWwgY2hhbmNlIHRvIHN1cnZpdmUgYW5kIGhhcyBh bHdheXMgdHJlYXRlZCBpdCBhcyBhIOKAnHBvdGVudGlhbCBmdXR1cmUgZXh0ZW5zaW9u4oCdLiBU aGlzIGhhcyBiZWVuIG1hZGUgc28gY2xlYXIgaW4gdGhlIG1haWxpbmcgbGlzdCB0aGF0IHdlIGhh dmUgc3RvcHBlZCB0cnlpbmcgdG8gcHVzaCBmb3IgaXQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBk b24ndCB0aGluayB0aGF0J3MgYSBmYWlyIHN1bW1hcnkuPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZpcnN0LCB0aGVyZSBpcyBubyB2MS4gV2Un cmUgYnVzeSBzcGVjaWZ5aW5nIGl0IGF0IHRoZSBtb21lbnQsIGFuZCBtYW55LCBtYW55IGZ1bmRh bWVudGFsIHRoaW5ncyBhcmUgc3RpbGwgY2hhbmdpbmcuIFRoZXNlIGFyZSB0YWtpbmcgYWxsIHRo ZSBjeWNsZXMgdGhlIFdHIGhhcyBhdCB0aGUgbW9tZW50LCBhbmQgd2UncmUgc3RpbGwgbm90IHBy b2dyZXNzaW5nIGF0IGEgc2F0aXNmYWN0b3J5IHBhY2UuIChXaGljaA0KIHdhcyB0aGUgbWVzc2Fn ZSB0aGF0IHN0YXJ0ZWQgdGhpcyB0aHJlYWQuKSBJIGFsc28gZG9uJ3QgdGhpbmsgdGhhdCB0aGUg aW1wbGVtZW50YXRpb25zIGFyZSBhdCBhIHN0YWdlIHdoZXJlIHRoZXkgY2FuIHJlYWxpc3RpY2Fs bHkgdGhpbmsgYWJvdXQgYWRkaW5nIG11bHRpcGF0aCAtIG1vc3QgaGF2ZW4ndCBldmVuIHJlYWxs eSBsb29rZWQgYXQgcmVjb3ZlcnkgaW4gZGV0YWlsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NdWx0aXBhdGggKmlzKiBpbiB0aGUgY2hhcnRl ciwgYW5kIHdlJ3JlIGZ1bGx5IGNvbW1pdHRlZCB0byBzdXBwb3J0aW5nIGl0LiBJIHNpbXBseSBj YW4ndCBzZWUgaG93IGdldHRpbmcgdGhlIFdHIHdvcmtpbmcgb24gdGhlIGRldGFpbHMgYXQgbXVs dGlwYXRoIGF0IHRoaXMgdGltZSB3aWxsIGhlbHAgc3BlZWQgdXAgd29yayBvbiB0aGUgcHJvdG9j b2wgZnVuZGFtZW50YWxzLiBBbmQgaXQgc2VlbXMgdGhhdCB3ZSdkDQogbmVlZCB0byBjb250aW51 b3VzbHkgcmV3b3JrIG11bHRpcGF0aCB3aGlsZSB3ZSdyZSBzdGlsbCBjaGFuZ2luZyBwcm90b2Nv bCBmdW5kYW1lbnRhbHMsIHdoaWNoIHdvdWxkIGNyZWF0ZSBhZGRpdGlvbmFsIGJ1c3kgd29yay4m bmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGVuIHdlIHdlcmUgZGlzY3Vzc2luZyB0 aGUgUVVJQyBjaGFydGVyLCBJIHdhcyB2ZXJ5IHJlbHVjdGFudCB0byBjaGFydGVyIGEgbmV3IHRy YW5zcG9ydCBwcm90b2NvbCBpbiAyMDE2IHRoYXQgZGlkbid0IGFkZHJlc3MgbXVsdGlwYXRoIChv dGhlciBwZW9wbGUgaGF2ZSBzdWZmZXJlZCBtb3JlIHdoaWxlIGFkZGluZyBtdWx0aXBhdGggdG8g YSBwcm90b2NvbCB0aGF0IGRpZG4ndCBhbnRpY2lwYXRlIG11bHRpcGF0aA0KIHRoYW4gSSBoYXZl LCBidXQgSSd2ZSBzZWVuIGVub3VnaCBzdWZmZXJpbmcpLiBUaGF0IG1heSBiZSB0aGUgcG9pbnQg SSBwcmVzc2VkIG9uIG1vc3Qgc3Ryb25nbHkgd2hpbGUgZWRpdGluZyB0aGUgY3VycmVudCBjaGFy dGVyLiBTbyBldmVuIHRob3VnaCB3ZSB3YW50ZWQgdG8gbWluaW1pemUgdGhlIGluaXRpYWwgY2hh cnRlciBzY29wZSwgSSBpbmNsdWRlZCBtdWx0aXBhdGggaW4gdGhlIGNoYXJ0ZXIgSSB0b29rIHRv IHRoZSBJRVNHLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5JIGhhZCBhc3N1bWVkICh3aXRob3V0IGFza2luZyBhbnlvbmUpIHRoYXQ8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h cmdpbi1sZWZ0OjMwLjBwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+LSBFbmFibGluZyBtdWx0aXBhdGggYW5kIGZvcndhcmQgZXJyb3IgY29y cmVjdGlvbiBleHRlbnNpb25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Js b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4obGlzdGVkIGFzIG9uZSBvZiB0aGUga2V5 IGdvYWxzIGluIHRoZSBjdXJyZW50IGNoYXJ0ZXIpIHdvdWxkIHB1dCAmcXVvdDttYWtpbmcgc3Vy ZSB0aGF0IGV4dGVuc2lvbnMgd2VyZSBwb3NzaWJsZSZxdW90OyBpbiBzY29wZSBmb3IgdjEuJm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGRvbid0 IGhhdmUgYW4gb3BpbmlvbiBhYm91dCBob3cgJnF1b3Q7bWFraW5nIHN1cmUmcXVvdDsgaGFwcGVu cywgb2YgY291cnNlLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjx1bCB0eXBlPSJkaXNjIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSWYgdGhlIHdv cmtpbmcgZ3JvdXAgd2FzIGNvbnZpbmNlZCB0aGF0ICZxdW90O2dyZWFzaW5nJnF1b3Q7IGluIHYx IGlzIHN1ZmZpY2llbnQgdG8gZW5hYmxlIGV4dGVuc2lvbnMgKGF0IGFwcHJvcHJpYXRlIHBvaW50 cyBpbiB0aW1lKSwgSSB3b3VsZCBzdXBwb3J0IHRoYXQuPG86cD48L286cD48L2xpPjxsaSBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPg0KSWYgdGhlIHdvcmtpbmcg Z3JvdXAgd2FzIGNvbnZpbmNlZCB0aGF0IHNvbWV0aGluZyBlbHNlIGlzIHJlcXVpcmVkLCBJJ2Qg bGlzdGVuLCBvZiBjb3Vyc2UuPG86cD48L286cD48L2xpPjwvdWw+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlNwZW5jZXIsIHNwZWFraW5nIGFzIHJlc3Bv bnNpYmxlIEFEPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5MYXJz PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_MWHPR21MB0141B0A4082BFB6B7A714B2887590MWHPR21MB0141namp_-- From nobody Mon Oct 30 03:35: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 6B1C613F4E9 for ; Mon, 30 Oct 2017 03:35:14 -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, 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 yrNgahvPbYrb for ; Mon, 30 Oct 2017 03:35:12 -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 4BAA813AB2B for ; Mon, 30 Oct 2017 03:35:10 -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 v9UAYLKY008308 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2017 11:34:21 +0100 Received: from hedwig.net.t-labs.tu-berlin.de ([130.149.220.89]) by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e97OE-0002sr-1R; Mon, 30 Oct 2017 11:33:54 +0100 From: "Philipp S. Tiesel" Message-Id: <76E33E22-AFEC-481F-AF0A-99EBE92E645E@in-panik.de> Content-Type: multipart/alternative; boundary="Apple-Mail=_F2617A88-AAC1-4BF1-80A8-2F3F0031C773" Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Re: QUIC - Our schedule and scope Date: Mon, 30 Oct 2017 11:34:20 +0100 In-Reply-To: Cc: Roni Even , Mark Nottingham , QUIC WG , Spencer Dawkins at IETF To: "Eggert, Lars" References: <6E58094ECC8D8344914996DAD28F1CCD828A1A@DGGEMM506-MBS.china.huawei.com> X-Mailer: Apple Mail (2.3445.1.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, 30 Oct 2017 10:35:14 -0000 --Apple-Mail=_F2617A88-AAC1-4BF1-80A8-2F3F0031C773 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi > On 29. Oct 2017, at 07:45, Eggert, Lars wrote: >=20 > Hi, >=20 > On 2017-10-29, at 7:33, Roni Even wrote: >> I think we must be very careful when defining the "invariants" to = allow for other uses. >=20 > agreed. And, we must be very careful to not make future extensions = like multipath, partial reliability, etc. more difficult to support than = necessary. >=20 > So to me personally, that kind of forward-looking discussion - to = ensure we retain the extensibility needed for the future - remains fully = in scope. But there is a fine line between a general extensibility = argument and an argument that says "my proposal for future extension X = is this, and therefore QUICv1 needs to do Y now=E2=80=9D. For the sake of getting things done, I totally agree with this = statement. But, as someone working on the yet-out-of-scope feature, I think the WG = should find a gentle way to include these projects, and make sure it = does to move towards squishing them. Therefore, I propose 15min yet-out-of-scope feature report in the = meetings. I also think a kind of guideline how yet-out-of-scope features should = give input could help, something along: - Have a separate daft on the feature with importing considerations and = lessons learned from implementation. - Have a 4-line TL;DR regarding whether=20 1-2) how difficult implementing the feature is (given the current = drafts) 3-4) roughly what changes would be needed to add the feature - Don=E2=80=99t file pull-requests on the current drafts, but maybe = have a fork with diffs ready. - Raise hands if changes under discussion would totally block / = significantly complicate adding the feature later on =20 - Raise hands if changes under discussion would enable / ease = implementation of this feature - these arguments might be tie breakers. Based on that, I will continue to submit = draft-tiesel-quic-unreliable-streams-01 today AVE! Philipp S. Tiesel / phils=E2=80=A6 --Apple-Mail=_F2617A88-AAC1-4BF1-80A8-2F3F0031C773 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi

On 29. Oct 2017, at 07:45, Eggert, Lars <lars@netapp.com> = wrote:

Hi,

On 2017-10-29, at 7:33, Roni = Even <roni.even@huawei.com> wrote:
I think we must be very careful when defining = the "invariants" to allow for other uses.

agreed. And, we must be very careful to not make future = extensions like multipath, partial reliability, etc. more difficult to = support than necessary.

So to me = personally, that kind of forward-looking discussion - to ensure we = retain the extensibility needed for the future - remains fully in scope. = But there is a fine line between a general extensibility argument and an = argument that says "my proposal for future extension X is this, and = therefore QUICv1 needs to do Y now=E2=80=9D.

For = the sake of getting things done, I totally agree with this = statement.

But, as someone working = on the yet-out-of-scope feature, I think the WG should find a gentle way = to include these projects, and make sure it does to move towards = squishing them.

Therefore, I = propose 15min yet-out-of-scope feature report in the meetings.

I also think a kind of = guideline how yet-out-of-scope features should give input could help, = something along:
 - Have a separate daft on the feature = with importing considerations and lessons learned from = implementation.
 - Have a 4-line TL;DR regarding = whether 
   1-2) how difficult implementing the = feature is (given the current drafts)
   3-4) = roughly what changes would be needed to add the = feature
 - Don=E2=80=99t file pull-requests on the = current drafts, but maybe have a fork with diffs = ready.
 - Raise hands if changes under discussion = would totally block / significantly complicate adding the feature later = on  
 - Raise hands if changes under = discussion would enable / ease implementation of this feature - = these arguments might be tie breakers.

Based on that, I will continue to submit = draft-tiesel-quic-unreliable-streams-01 today

AVE!
  Philipp S. Tiesel / phils=E2=80=A6
= --Apple-Mail=_F2617A88-AAC1-4BF1-80A8-2F3F0031C773-- From nobody Mon Oct 30 04:47: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 5F63413F660 for ; Mon, 30 Oct 2017 04:47:40 -0700 (PDT) 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 HFphH3-Fu0LL for ; Mon, 30 Oct 2017 04:47:39 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id B737713F447 for ; Mon, 30 Oct 2017 04:47:38 -0700 (PDT) Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.190]) by Forcepoint Email with ESMTP id 71933BB91A4CE; Mon, 30 Oct 2017 11:47:35 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 30 Oct 2017 11:43:01 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0361.001; Mon, 30 Oct 2017 19:42:57 +0800 From: Roni Even To: "Philipp S. Tiesel" , "Eggert, Lars" CC: Mark Nottingham , QUIC WG , "Spencer Dawkins at IETF" Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTUWq4OYwD1bY2Q025S94sx4OA0aL8RNeg Date: Mon, 30 Oct 2017 11:42:56 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD829F41@DGGEMM506-MBS.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD828A1A@DGGEMM506-MBS.china.huawei.com> <76E33E22-AFEC-481F-AF0A-99EBE92E645E@in-panik.de> In-Reply-To: <76E33E22-AFEC-481F-AF0A-99EBE92E645E@in-panik.de> 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_6E58094ECC8D8344914996DAD28F1CCD829F41DGGEMM506MBSchina_" 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: Mon, 30 Oct 2017 11:47:40 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD829F41DGGEMM506MBSchina_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpNYXliZSB3ZSBjYW4gc2F5IHRoYXQgZnV0dXJlIHZlcnNpb25zIG1heSBoYXZlIGEgZGlm ZmVyZW50IGhlYWRlciBzaXplIHNpZ25hbGVkIGZvciBleGFtcGxlIGJ5IHRoZSBtZXNzYWdlIHR5 cGUgLiBTbyB0aGUgbG9jYXRpb24gb2YgdGhlIHBheWxvYWQgaXMgbm90IGZpeGVkIGJhc2VkIG9u IGhhdmluZyAxIG9yIDAgaW4gdGhlIGhlYWRlciBmb3JtIGJpdC4NClJvbmkNCg0KRnJvbTogUGhp bGlwcCBTLiBUaWVzZWwgW21haWx0bzpwaGlsc0Bpbi1wYW5pay5kZV0NClNlbnQ6INeZ15XXnSDX kSAzMCDXkNeV16fXmNeV15HXqCAyMDE3IDEyOjM0DQpUbzogRWdnZXJ0LCBMYXJzDQpDYzogUm9u aSBFdmVuOyBNYXJrIE5vdHRpbmdoYW07IFFVSUMgV0c7IFNwZW5jZXIgRGF3a2lucyBhdCBJRVRG DQpTdWJqZWN0OiBSZTogUVVJQyAtIE91ciBzY2hlZHVsZSBhbmQgc2NvcGUNCg0KSGkNCg0KDQpP biAyOS4gT2N0IDIwMTcsIGF0IDA3OjQ1LCBFZ2dlcnQsIExhcnMgPGxhcnNAbmV0YXBwLmNvbTxt YWlsdG86bGFyc0BuZXRhcHAuY29tPj4gd3JvdGU6DQoNCkhpLA0KDQpPbiAyMDE3LTEwLTI5LCBh dCA3OjMzLCBSb25pIEV2ZW4gPHJvbmkuZXZlbkBodWF3ZWkuY29tPG1haWx0bzpyb25pLmV2ZW5A aHVhd2VpLmNvbT4+IHdyb3RlOg0KDQpJIHRoaW5rIHdlIG11c3QgYmUgdmVyeSBjYXJlZnVsIHdo ZW4gZGVmaW5pbmcgdGhlICJpbnZhcmlhbnRzIiB0byBhbGxvdyBmb3Igb3RoZXIgdXNlcy4NCg0K YWdyZWVkLiBBbmQsIHdlIG11c3QgYmUgdmVyeSBjYXJlZnVsIHRvIG5vdCBtYWtlIGZ1dHVyZSBl eHRlbnNpb25zIGxpa2UgbXVsdGlwYXRoLCBwYXJ0aWFsIHJlbGlhYmlsaXR5LCBldGMuIG1vcmUg ZGlmZmljdWx0IHRvIHN1cHBvcnQgdGhhbiBuZWNlc3NhcnkuDQoNClNvIHRvIG1lIHBlcnNvbmFs bHksIHRoYXQga2luZCBvZiBmb3J3YXJkLWxvb2tpbmcgZGlzY3Vzc2lvbiAtIHRvIGVuc3VyZSB3 ZSByZXRhaW4gdGhlIGV4dGVuc2liaWxpdHkgbmVlZGVkIGZvciB0aGUgZnV0dXJlIC0gcmVtYWlu cyBmdWxseSBpbiBzY29wZS4gQnV0IHRoZXJlIGlzIGEgZmluZSBsaW5lIGJldHdlZW4gYSBnZW5l cmFsIGV4dGVuc2liaWxpdHkgYXJndW1lbnQgYW5kIGFuIGFyZ3VtZW50IHRoYXQgc2F5cyAibXkg cHJvcG9zYWwgZm9yIGZ1dHVyZSBleHRlbnNpb24gWCBpcyB0aGlzLCBhbmQgdGhlcmVmb3JlIFFV SUN2MSBuZWVkcyB0byBkbyBZIG5vd+KAnS4NCg0KRm9yIHRoZSBzYWtlIG9mIGdldHRpbmcgdGhp bmdzIGRvbmUsIEkgdG90YWxseSBhZ3JlZSB3aXRoIHRoaXMgc3RhdGVtZW50Lg0KDQpCdXQsIGFz IHNvbWVvbmUgd29ya2luZyBvbiB0aGUgeWV0LW91dC1vZi1zY29wZSBmZWF0dXJlLCBJIHRoaW5r IHRoZSBXRyBzaG91bGQgZmluZCBhIGdlbnRsZSB3YXkgdG8gaW5jbHVkZSB0aGVzZSBwcm9qZWN0 cywgYW5kIG1ha2Ugc3VyZSBpdCBkb2VzIHRvIG1vdmUgdG93YXJkcyBzcXVpc2hpbmcgdGhlbS4N Cg0KVGhlcmVmb3JlLCBJIHByb3Bvc2UgMTVtaW4geWV0LW91dC1vZi1zY29wZSBmZWF0dXJlIHJl cG9ydCBpbiB0aGUgbWVldGluZ3MuDQoNCkkgYWxzbyB0aGluayBhIGtpbmQgb2YgZ3VpZGVsaW5l IGhvdyB5ZXQtb3V0LW9mLXNjb3BlIGZlYXR1cmVzIHNob3VsZCBnaXZlIGlucHV0IGNvdWxkIGhl bHAsIHNvbWV0aGluZyBhbG9uZzoNCiAtIEhhdmUgYSBzZXBhcmF0ZSBkYWZ0IG9uIHRoZSBmZWF0 dXJlIHdpdGggaW1wb3J0aW5nIGNvbnNpZGVyYXRpb25zIGFuZCBsZXNzb25zIGxlYXJuZWQgZnJv bSBpbXBsZW1lbnRhdGlvbi4NCiAtIEhhdmUgYSA0LWxpbmUgVEw7RFIgcmVnYXJkaW5nIHdoZXRo ZXINCiAgIDEtMikgaG93IGRpZmZpY3VsdCBpbXBsZW1lbnRpbmcgdGhlIGZlYXR1cmUgaXMgKGdp dmVuIHRoZSBjdXJyZW50IGRyYWZ0cykNCiAgIDMtNCkgcm91Z2hseSB3aGF0IGNoYW5nZXMgd291 bGQgYmUgbmVlZGVkIHRvIGFkZCB0aGUgZmVhdHVyZQ0KIC0gRG9u4oCZdCBmaWxlIHB1bGwtcmVx dWVzdHMgb24gdGhlIGN1cnJlbnQgZHJhZnRzLCBidXQgbWF5YmUgaGF2ZSBhIGZvcmsgd2l0aCBk aWZmcyByZWFkeS4NCiAtIFJhaXNlIGhhbmRzIGlmIGNoYW5nZXMgdW5kZXIgZGlzY3Vzc2lvbiB3 b3VsZCB0b3RhbGx5IGJsb2NrIC8gc2lnbmlmaWNhbnRseSBjb21wbGljYXRlIGFkZGluZyB0aGUg ZmVhdHVyZSBsYXRlciBvbg0KIC0gUmFpc2UgaGFuZHMgaWYgY2hhbmdlcyB1bmRlciBkaXNjdXNz aW9uIHdvdWxkIGVuYWJsZSAvIGVhc2UgaW1wbGVtZW50YXRpb24gb2YgdGhpcyBmZWF0dXJlIC0g dGhlc2UgYXJndW1lbnRzIG1pZ2h0IGJlIHRpZSBicmVha2Vycy4NCg0KQmFzZWQgb24gdGhhdCwg SSB3aWxsIGNvbnRpbnVlIHRvIHN1Ym1pdCBkcmFmdC10aWVzZWwtcXVpYy11bnJlbGlhYmxlLXN0 cmVhbXMtMDEgdG9kYXkNCg0KQVZFIQ0KICBQaGlsaXBwIFMuIFRpZXNlbCAvIHBoaWxz4oCmDQo= --_000_6E58094ECC8D8344914996DAD28F1CCD829F41DGGEMM506MBSchina_ 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 MUY0OTdEIj5NYXliZSB3ZSBjYW4gc2F5IHRoYXQgZnV0dXJlIHZlcnNpb25zIG1heSBoYXZlIGEg ZGlmZmVyZW50IGhlYWRlciBzaXplIHNpZ25hbGVkIGZvciBleGFtcGxlIGJ5IHRoZSBtZXNzYWdl IHR5cGUgLiBTbyB0aGUgbG9jYXRpb24gb2YgdGhlIHBheWxvYWQgaXMgbm90IGZpeGVkDQogYmFz ZWQgb24gaGF2aW5nIDEgb3IgMCBpbiB0aGUgaGVhZGVyIGZvcm0gYml0LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj5Sb25pPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0K PGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3Bh ZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90OyI+IFBoaWxpcHAgUy4gVGllc2VsIFttYWlsdG86cGhpbHNAaW4tcGFuaWsuZGVdDQo8 YnI+DQo8Yj5TZW50OjwvYj4gPHNwYW4gbGFuZz0iSEUiIGRpcj0iUlRMIj7XmdeV150mbmJzcDvX kSAzMCDXkNeV16fXmNeV15HXqCAyMDE3IDEyOjM0PC9zcGFuPjxicj4NCjxiPlRvOjwvYj4gRWdn ZXJ0LCBMYXJzPGJyPg0KPGI+Q2M6PC9iPiBSb25pIEV2ZW47IE1hcmsgTm90dGluZ2hhbTsgUVVJ QyBXRzsgU3BlbmNlciBEYXdraW5zIGF0IElFVEY8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFFV SUMgLSBPdXIgc2NoZWR1bGUgYW5kIHNjb3BlPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+SGk8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5PbiAyOS4gT2N0IDIwMTcsIGF0IDA3OjQ1LCBFZ2dlcnQsIExhcnMgJmx0OzxhIGhy ZWY9Im1haWx0bzpsYXJzQG5ldGFwcC5jb20iPmxhcnNAbmV0YXBwLmNvbTwvYT4mZ3Q7IHdyb3Rl OjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPGJyPg0K PGJyPg0KT24gMjAxNy0xMC0yOSwgYXQgNzozMywgUm9uaSBFdmVuICZsdDs8YSBocmVmPSJtYWls dG86cm9uaS5ldmVuQGh1YXdlaS5jb20iPnJvbmkuZXZlbkBodWF3ZWkuY29tPC9hPiZndDsgd3Jv dGU6PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIHRo aW5rIHdlIG11c3QgYmUgdmVyeSBjYXJlZnVsIHdoZW4gZGVmaW5pbmcgdGhlICZxdW90O2ludmFy aWFudHMmcXVvdDsgdG8gYWxsb3cgZm9yIG90aGVyIHVzZXMuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48YnI+DQphZ3JlZWQuIEFuZCwgd2UgbXVzdCBiZSB2ZXJ5IGNhcmVm dWwgdG8gbm90IG1ha2UgZnV0dXJlIGV4dGVuc2lvbnMgbGlrZSBtdWx0aXBhdGgsIHBhcnRpYWwg cmVsaWFiaWxpdHksIGV0Yy4gbW9yZSBkaWZmaWN1bHQgdG8gc3VwcG9ydCB0aGFuIG5lY2Vzc2Fy eS48YnI+DQo8YnI+DQpTbyB0byBtZSBwZXJzb25hbGx5LCB0aGF0IGtpbmQgb2YgZm9yd2FyZC1s b29raW5nIGRpc2N1c3Npb24gLSB0byBlbnN1cmUgd2UgcmV0YWluIHRoZSBleHRlbnNpYmlsaXR5 IG5lZWRlZCBmb3IgdGhlIGZ1dHVyZSAtIHJlbWFpbnMgZnVsbHkgaW4gc2NvcGUuIEJ1dCB0aGVy ZSBpcyBhIGZpbmUgbGluZSBiZXR3ZWVuIGEgZ2VuZXJhbCBleHRlbnNpYmlsaXR5IGFyZ3VtZW50 IGFuZCBhbiBhcmd1bWVudCB0aGF0IHNheXMgJnF1b3Q7bXkgcHJvcG9zYWwgZm9yDQogZnV0dXJl IGV4dGVuc2lvbiBYIGlzIHRoaXMsIGFuZCB0aGVyZWZvcmUgUVVJQ3YxIG5lZWRzIHRvIGRvIFkg bm934oCdLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkZvciB0aGUgc2FrZSBvZiBnZXR0aW5nIHRoaW5ncyBkb25lLCBJIHRvdGFs bHkgYWdyZWUgd2l0aCB0aGlzIHN0YXRlbWVudC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QnV0LCBhcyBzb21lb25lIHdvcmtpbmcgb24gdGhl IHlldC1vdXQtb2Ytc2NvcGUgZmVhdHVyZSwgSSB0aGluayB0aGUgV0cgc2hvdWxkIGZpbmQgYSBn ZW50bGUgd2F5IHRvIGluY2x1ZGUgdGhlc2UgcHJvamVjdHMsIGFuZCBtYWtlIHN1cmUgaXQgZG9l cyB0byBtb3ZlIHRvd2FyZHMgc3F1aXNoaW5nIHRoZW0uPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZWZvcmUsIEkgcHJvcG9z ZSAxNW1pbiB5ZXQtb3V0LW9mLXNjb3BlIGZlYXR1cmUgcmVwb3J0IGluIHRoZSBtZWV0aW5ncy48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGFsc28gdGhpbmsgYSBraW5kIG9mIGd1aWRlbGluZSBob3cgeWV0LW91dC1vZi1zY29w ZSBmZWF0dXJlcyBzaG91bGQgZ2l2ZSBpbnB1dCBjb3VsZCBoZWxwLCBzb21ldGhpbmcgYWxvbmc6 PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDstIEhhdmUgYSBzZXBhcmF0ZSBkYWZ0IG9uIHRoZSBmZWF0dXJlIHdpdGggaW1wb3J0aW5nIGNv bnNpZGVyYXRpb25zIGFuZCBsZXNzb25zIGxlYXJuZWQgZnJvbSBpbXBsZW1lbnRhdGlvbi48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOy0g SGF2ZSBhIDQtbGluZSBUTDtEUiByZWdhcmRpbmcgd2hldGhlciZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOzEtMikg aG93IGRpZmZpY3VsdCBpbXBsZW1lbnRpbmcgdGhlIGZlYXR1cmUgaXMgKGdpdmVuIHRoZSBjdXJy ZW50IGRyYWZ0cyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOyAmbmJzcDszLTQpIHJvdWdobHkgd2hhdCBjaGFuZ2VzIHdvdWxkIGJlIG5l ZWRlZCB0byBhZGQgdGhlIGZlYXR1cmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDstIERvbuKAmXQgZmlsZSBwdWxsLXJlcXVl c3RzIG9uIHRoZSBjdXJyZW50IGRyYWZ0cywgYnV0IG1heWJlIGhhdmUgYSBmb3JrIHdpdGggZGlm ZnMgcmVhZHkuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOy0gUmFpc2UgaGFuZHMgaWYgY2hhbmdlcyB1bmRlciBkaXNjdXNz aW9uIHdvdWxkIHRvdGFsbHkgYmxvY2sgLyBzaWduaWZpY2FudGx5IGNvbXBsaWNhdGUgYWRkaW5n IHRoZSBmZWF0dXJlIGxhdGVyIG9uICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7LSBSYWlzZSBoYW5kcyBpZiBjaGFuZ2VzIHVu ZGVyIGRpc2N1c3Npb24mbmJzcDt3b3VsZCBlbmFibGUgLyBlYXNlIGltcGxlbWVudGF0aW9uIG9m IHRoaXMgZmVhdHVyZSAtIHRoZXNlIGFyZ3VtZW50cyBtaWdodCBiZSB0aWUgYnJlYWtlcnMuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJhc2Vk IG9uIHRoYXQsIEkgd2lsbCBjb250aW51ZSB0byBzdWJtaXQgZHJhZnQtdGllc2VsLXF1aWMtdW5y ZWxpYWJsZS1zdHJlYW1zLTAxIHRvZGF5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5BVkUhPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+ DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyBQaGlsaXBwIFMuIFRpZXNlbCAvIHBoaWxz4oCmPG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_6E58094ECC8D8344914996DAD28F1CCD829F41DGGEMM506MBSchina_-- From nobody Mon Oct 30 05:33: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 3A4EB13F665 for ; Mon, 30 Oct 2017 05:33:11 -0700 (PDT) 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 6c2S1MEJ_has for ; Mon, 30 Oct 2017 05:33:08 -0700 (PDT) Received: from dfwrgout.huawei.com (dfwrgout.huawei.com [206.16.17.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D05FC13F7B7 for ; Mon, 30 Oct 2017 05:33:04 -0700 (PDT) Received: from 172.18.9.243 (EHLO LHREML712-CAH.china.huawei.com) ([172.18.9.243]) by dfwrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DSS30662; Mon, 30 Oct 2017 07:33:04 -0500 (CDT) Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by LHREML712-CAH.china.huawei.com (10.201.108.35) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 30 Oct 2017 12:33:03 +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; Mon, 30 Oct 2017 20:32:45 +0800 From: Roni Even To: QUIC WG Subject: Middlebox Latency Measurement Design Team Report Thread-Topic: Middlebox Latency Measurement Design Team Report Thread-Index: AdNReSfzIqhLm+94QvCthk9c6o1vfw== Date: Mon, 30 Oct 2017 12:32:44 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD829F76@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_6E58094ECC8D8344914996DAD28F1CCD829F76DGGEMM506MBSchina_" 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: Mon, 30 Oct 2017 12:33:11 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD829F76DGGEMM506MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I saw that we will have 15 minutes in Singapore for this topic. Since the discussion in this DT are not public and there was a request to n= ot discuss the topic while the DT is active , I am wondering what is the pu= rpose of the presentation, is it just an update or will we need to make dec= isions at the meeting. This is a very important issue to our service provider customers and we sub= mitted a document describing their requirements (https://tools.ietf.org/id= /draft-even-quic-troubleshooting-video-delivery-00.txt ) Thanks Roni Even --_000_6E58094ECC8D8344914996DAD28F1CCD829F76DGGEMM506MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I saw that we will have 15 minutes in Singapore for = this topic.

Since the discussion in this DT are not public and t= here was a request to not discuss the topic while the DT is active , I am w= ondering what is the purpose of the presentation, is it just an update or w= ill we need to make decisions at the meeting.

This is a very important issue to our service provid= er customers and we submitted a document  describing their requirement= s (https://tools.ietf.org/id/draft-even-quic-troubleshooti= ng-video-delivery-00.txt )

Thanks

Roni Even

 

--_000_6E58094ECC8D8344914996DAD28F1CCD829F76DGGEMM506MBSchina_-- From nobody Mon Oct 30 06:34: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 971DF13F8F1 for ; Mon, 30 Oct 2017 06:34:22 -0700 (PDT) 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 azdH64AWqtSp for ; Mon, 30 Oct 2017 06:34:18 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 666FB13F950 for ; Mon, 30 Oct 2017 06:34:18 -0700 (PDT) X-AuditID: c1b4fb2d-bf5ff7000000268d-36-59f72a58562f Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.183.63]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id AC.2E.09869.85A27F95; Mon, 30 Oct 2017 14:34:16 +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, 30 Oct 2017 14:34:15 +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=tluymlO7miO4mGeg2CuTAmemjkEKq+Fp1dwAenpx0tE=; b=SIZzrb1fqeP1bV6mN9jNuLc6KgQdnHqNDPeyYaZQ3mbo2wAQfTgeMdQJ2ft8rlB3HWx41q0co+J93lSSs9efFm2LpQbYaRus3gs+uNe7uoXUeXA7D70g36gt4mBX0R7iysZ1iGOPg0NWjBoT8dsjMQJWFBfmImRQlAxMx4yEU+o= 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.197.4; Mon, 30 Oct 2017 13:34:14 +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.0197.007; Mon, 30 Oct 2017 13:34:14 +0000 From: Ingemar Johansson S To: QUIC WG Subject: ECN for QUIC, updated wiki Thread-Topic: ECN for QUIC, updated wiki Thread-Index: AdNRgVGCHLS8YBoWQtO1lAEswASjyQ== Date: Mon, 30 Oct 2017 13:34:14 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ingemar.s.johansson@ericsson.com; x-originating-ip: [192.176.1.92] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DB4PR07MB347; 6:D5a8KdH990I/PZy7EdUiLSynLpMerTFQzCS8Mn8AZQWQnSmIJYeNbnhWpwgwFqlpRgEHLYMoV8cwLbyZ7rVe5Ieh/YWK2QF4JY1ZUPSfuhZyTwIHVfE+Wstx903Ak/9sgeCoLVrgOOFuaMoKQtWP754PltwTFQUrtskPva1GavDXmkYg50UKpR2NOZMsXQoKjkG3+dojbNhIA8omXHyGWAZ1qq2AiTxU+fHywTxb+WGYW4HGF5ee97e94gFlAmH0qUOj5Q4CUFXg/bYvB0ETg95fngTaeKaCNMIDPyM2uvCLtiq4C95LPosskIB2I4Zq5VicVtuixJCqcKxmWo5CnMMkEeTHewVXA11o2xwPwO8=; 5:JeS6/nhel9PyMfriw6AtlE2BZrZFp3Pj+ffUJRdJxIlkCBY+fGIV/GSbS8KtZ2F+Xv6aRUG9qRNHAQtWeF4zqFtye2FFMFe8y6uXYpboBSpySGYA0TsfVqtMZx0uDNlaphaUcIQEDTFNNWb2fQdqX6ojrsLQvf3cYi9YnPlCsOI=; 24:piMrJ6vlrmosmx6txp3quWmLW1sS+KfdaNWwzhE3mJhM0OUgFnINzkQx9xFfGPQlLpSMmN72J5dyv/JCCreRiyo/RUSQfabPeekF0BSHGrA=; 7:tKRy1J9kHZw5VC1RXKP8Y7ne/CrEP6ViAi2MlcF4zExqKRwIQcxeQ9rbhlvJrQw0xovMw60yximjszEfglM16jlAbGCCPpfRD+ZqPq0+hlBZpNFFIqj8EmKhSfTAuDQGN8Y9azOtjJP8Z+BavSADBvNZhCWO3aItfS2sv5hn+QQfimtHhDGyvDqEyESHIU/6V47EbTV7shT+ZCRELe0Zch9v33no+dWVK77v+uvwyREmJHyLqXTRd/TmUKNHejQx x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 923ab912-d6e0-4089-e9ac-08d51f9ae997 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199); SRVR:DB4PR07MB347; x-ms-traffictypediagnostic: DB4PR07MB347: x-exchange-antispam-report-test: UriScan:(37575265505322)(166708455590820)(202460600054446)(21748063052155); 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)(3002001)(10201501046)(3231020)(93006095)(93001095)(100000703101)(100105400095)(6041248)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123560025)(20161123562025)(20161123558100)(20161123564025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DB4PR07MB347; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DB4PR07MB347; x-forefront-prvs: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(189002)(199003)(74316002)(53936002)(2906002)(66066001)(55016002)(33656002)(7736002)(54896002)(236005)(99286003)(5250100002)(8936002)(54356999)(50986999)(3280700002)(105586002)(101416001)(3660700001)(8676002)(6116002)(102836003)(9686003)(790700001)(3846002)(561944003)(2900100001)(68736007)(81156014)(81166006)(478600001)(2420400007)(966005)(15650500001)(7696004)(86362001)(106356001)(316002)(14454004)(25786009)(7110500001)(6916009)(6306002)(10710500007)(5660300001)(9326002)(19609705001)(606006)(6436002)(97736004)(189998001)(6506006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB4PR07MB347; 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_DB4PR07MB348BB36D181501E08D9695FC2590DB4PR07MB348eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 923ab912-d6e0-4089-e9ac-08d51f9ae997 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 13:34:14.6327 (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: H4sIAAAAAAAAA03SbUhTURgHcM7uvdt1NjlNxaepvSzMWmyZCRZIWfZBCcOP6gdr6FVH25Td ZRkUE7R0aiXkfCPUnC85LZGiffAFJ6FR0FoaZbZwmSkmmWCzJpbXu8Bvv/M//8N5DhyakDZR MlqjNzIGvVorF4rJhvRnp5TpCm9GzEpbzPGqlsBElGy1/hakoUxxQg6j1RQxhiMnL4rzB4am qUJr/NVxu50woZexZkTTgOOgy5dtRmJaikcRPP47SfCLcQQPrPeF3ILE1QS4zI8Qv2MRgLv0 m782g6BvaXizFkALcQI8dHgR5xAcDv09P4XcHcF4P4y+zeHjg3C7aZXirQJL/QTJmcRRYPHZ RVxdgjOhb1nCxQhHwmeve6tC4DCYmm0WcAaMwTrwmuAdCgtfNii+nw0rH6opPt8L6y6PkHck uJort+YHPCKCtXKn/7AKntYsId6p0Dg75c91MFrnJHkfgkq33W8tzD0fE/HWwJths7/voqCp Q8Y7ApZ90/5BlygYfIU5SzEDnb1lW3cFYxl8mqhAd5GicdvbeBfAzdJ5EWcJ3gkvGmZJPlfB +9p7Qt6HoaN1keCthPoNB7k9b0GibhTKMiyry4s9pmIMmmyWLdCr9IyxH21+mZEnPqUd2RZP OxCmkXyHZEzuzZBS6iK2WOdAQBPyEEn3vs1IkqMuvsYYCi4YLmsZ1oHCaVIeJkkccqZLcZ7a yFximELG8H9XQAfITKgr9URE1oGZoD1t5V87PYO1Udr5sWlnd03s2T9xOomg80eI7lcJZVqf k3rYvElfdou0uWfC5s4quZL7Pa49d7cto8pjUS7MExG7rptutIckjwelJukLhZMp4rQ1Y1L5 GXPguXflgyilLHrW1kuszsQzda13KqI/BhW4zysUt+Qkm68+qiAMrPof4Fbbcy4DAAA= 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, 30 Oct 2017 13:34:22 -0000 --_000_DB4PR07MB348BB36D181501E08D9695FC2590DB4PR07MB348eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi The ECN wiki is now updated with a proposal for the wire formats for ECN su= pport in QUIC. Please see https://github.com/quicwg/base-drafts/wiki/ECN-in-QUIC /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_DB4PR07MB348BB36D181501E08D9695FC2590DB4PR07MB348eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi

The ECN wiki is now updated with a proposal for the = wire formats for ECN support in QUIC.

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

 

/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_DB4PR07MB348BB36D181501E08D9695FC2590DB4PR07MB348eurprd_-- From nobody Mon Oct 30 09:23: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 D56116992 for ; Mon, 30 Oct 2017 09:23:07 -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 2J-LB677BAb4 for ; Mon, 30 Oct 2017 09:22:58 -0700 (PDT) Received: from mail-wr0-x235.google.com (mail-wr0-x235.google.com [IPv6:2a00:1450:400c:c0c::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 BF8F74E35 for ; Mon, 30 Oct 2017 09:12:16 -0700 (PDT) Received: by mail-wr0-x235.google.com with SMTP id g90so13168586wrd.6 for ; Mon, 30 Oct 2017 09:12:16 -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=Sxds8kxzs8qhYxTptjWnwirkNu5HDYSGLL7uaDJs3B4=; b=QPTApzZLCbgOkYIWhEKTw9BBgg82cxhHNH96Az/S8TOeuS4gf9HpiZt3/BPxVcv/77 Z8IZxPTQbDZZNdUy9ACSMrIwkConpFJx3UXWczLRT0NJdzcki84xMZlJdrJlW33GTL6L jzsW9QnpVrDkbV3hUyH8IhEKjLeXK133c8GhCyOGZYy7Ee9tftRWCwm0HTrJsh7tcoR4 fHO3IUppfGsqs+dj2GThb7J/ayKPdjhE2SIM8G/Sn4eJeG4FCD4+bk3oNzZ1SVPD4GeE t+zumeekJ/NlizEie8Nj6L2hwFtLsq/SaDdRgW7sApNM7HSFsp/PB4lgKaGAiCUEdi2F suBA== 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=Sxds8kxzs8qhYxTptjWnwirkNu5HDYSGLL7uaDJs3B4=; b=W1tses9Wxuh9RprTf3lFbcl2APDL8vVlZ8NtAQBxGpraUfGe/+firsmtywseAsfI3L HIzYEmGR/v+XpX6l/SrrcPgGwBFqyw8dQtR7M9ZvcZ3vNJC6fqJuxheS5zzewxrUWP4i BQKIGHH4QSmer317EsnKdh1n0yZAVVpNDz3aBD+zgA7GkChoDoXr3pgpFdoPchsYJuKz e7lcNi+/ubPv9d3VLBdqjoFCHpsqngcd5FXOxX/o76sNQbD6biMrThzfaV2nTf2PR9su 7IuomnvaKs3nvjJ1tgT2z4MhMuC7hKnPAG6TNf+JNgUVg0dbPmQlHWVqXG72KWvoFLqK C7wA== X-Gm-Message-State: AMCzsaUVrHeZuZCNkar+rzUUGJCVQPRksSuMchLHA8bn3RelojzwHPR1 gNi7jZ06rymeC8M0jhRC700LdRY/HIytp4PzvKA= X-Google-Smtp-Source: ABhQp+RJsfnfPVEQTVIKjTXyvD3OSZ00cEAwCWMQmKWi2N8+4HyQzM7zDelFEH6Z3I5kvjJXM5J/PR8ME0DxylTy6XE= X-Received: by 10.223.199.15 with SMTP id k15mr8640241wrg.111.1509379935271; Mon, 30 Oct 2017 09:12:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.135.60 with HTTP; Mon, 30 Oct 2017 09:12:14 -0700 (PDT) In-Reply-To: <6E58094ECC8D8344914996DAD28F1CCD829F41@DGGEMM506-MBS.china.huawei.com> References: <6E58094ECC8D8344914996DAD28F1CCD828A1A@DGGEMM506-MBS.china.huawei.com> <76E33E22-AFEC-481F-AF0A-99EBE92E645E@in-panik.de> <6E58094ECC8D8344914996DAD28F1CCD829F41@DGGEMM506-MBS.china.huawei.com> From: Martin Duke Date: Mon, 30 Oct 2017 09:12:14 -0700 Message-ID: Subject: Re: QUIC - Our schedule and scope To: Roni Even Cc: "Philipp S. Tiesel" , "Eggert, Lars" , Mark Nottingham , QUIC WG , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="089e0824490cdf9dea055cc5e6d7" 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, 30 Oct 2017 16:23:08 -0000 --089e0824490cdf9dea055cc5e6d7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Lars and Mark, I'm comfortable with being a little more aggressive with respect to the schedule, as you suggest. One practical suggestion: can we create an issue category for "deferred" stuff? There are probably a dozen or issues that are good ideas floating around (a couple of mine) that we may not have time to address in 2018, but shouldn't be lost. I would feel a lot better about my stuff being punted if I knew the WG would formally consider it in v2. Martin On Mon, Oct 30, 2017 at 4:42 AM, Roni Even wrote: > Hi, > > Maybe we can say that future versions may have a different header size > signaled for example by the message type . So the location of the payload > is not fixed based on having 1 or 0 in the header form bit. > > Roni > > > > *From:* Philipp S. Tiesel [mailto:phils@in-panik.de] > *Sent:* =D7=99=D7=95=D7=9D =D7=91 30 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91= =D7=A8 2017 12:34 > *To:* Eggert, Lars > *Cc:* Roni Even; Mark Nottingham; QUIC WG; Spencer Dawkins at IETF > *Subject:* Re: QUIC - Our schedule and scope > > > > Hi > > > > On 29. Oct 2017, at 07:45, Eggert, Lars wrote: > > > > Hi, > > On 2017-10-29, at 7:33, Roni Even wrote: > > I think we must be very careful when defining the "invariants" to allow > for other uses. > > > agreed. And, we must be very careful to not make future extensions like > multipath, partial reliability, etc. more difficult to support than > necessary. > > So to me personally, that kind of forward-looking discussion - to ensure > we retain the extensibility needed for the future - remains fully in scop= e. > But there is a fine line between a general extensibility argument and an > argument that says "my proposal for future extension X is this, and > therefore QUICv1 needs to do Y now=E2=80=9D. > > > > For the sake of getting things done, I totally agree with this statement. > > > > But, as someone working on the yet-out-of-scope feature, I think the WG > should find a gentle way to include these projects, and make sure it does > to move towards squishing them. > > > > Therefore, I propose 15min yet-out-of-scope feature report in the meeting= s. > > > > I also think a kind of guideline how yet-out-of-scope features should giv= e > input could help, something along: > > - Have a separate daft on the feature with importing considerations and > lessons learned from implementation. > > - Have a 4-line TL;DR regarding whether > > 1-2) how difficult implementing the feature is (given the current > drafts) > > 3-4) roughly what changes would be needed to add the feature > > - Don=E2=80=99t file pull-requests on the current drafts, but maybe have= a fork > with diffs ready. > > - Raise hands if changes under discussion would totally block / > significantly complicate adding the feature later on > > - Raise hands if changes under discussion would enable / ease > implementation of this feature - these arguments might be tie breakers. > > > > Based on that, I will continue to submit draft-tiesel-quic-unreliable-str= eams-01 > today > > > > AVE! > > Philipp S. Tiesel / phils=E2=80=A6 > --089e0824490cdf9dea055cc5e6d7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Lars and Mark,

I'm comfortable with= being a little more aggressive with respect to the schedule, as you sugges= t.

One practical suggestion: can we create an issu= e category for "deferred" stuff? There are probably a dozen or is= sues that are good ideas floating around (a couple of mine) that we may not= have time to address in 2018, but shouldn't be lost. I would feel a lo= t better about my stuff being punted if I knew the WG would formally consid= er it in v2.

Martin

On Mon, Oct 30, 2017 at 4:42 AM, Ron= i Even <roni.even@huawei.com> wrote:

Hi,<= /p>

Maybe we can say that fut= ure versions may have a different header size signaled for example by the m= essage type . So the location of the payload is not fixed based on having 1 or 0 in the header form bit.

Roni=

=C2=A0

From: Philipp = S. Tiesel [mailto:ph= ils@in-panik.de]
Sent: =D7=99=D7=95=D7=9D=C2=A0=D7=91 3= 0 =D7=90=D7=95=D7=A7=D7=98=D7=95=D7=91=D7=A8 2017 12:34
To: Eggert, Lars
Cc: Roni Even; Mark Nottingham; QUIC WG; Spencer Dawkins at IETF
Subject: Re: QUIC - Our schedule and scope

=C2=A0

Hi



On 29. Oct 2017, at 07:45, Eggert, Lars <lars@netapp.com> wrote= :

=C2=A0

Hi,

On 2017-10-29, at 7:33, Roni Even <roni.even@huawei.com> wrote:

I think we must be very careful when defining the &q= uot;invariants" to allow for other uses.


agreed. And, we must be very careful to not make future extensions like mul= tipath, partial reliability, etc. more difficult to support than necessary.=

So to me personally, that kind of forward-looking discussion - to ensure we= retain the extensibility needed for the future - remains fully in scope. B= ut there is a fine line between a general extensibility argument and an arg= ument that says "my proposal for future extension X is this, and therefore QUICv1 needs to do Y now=E2=80= =9D.

=C2=A0

For the sake of getting things done, I totally agree= with this statement.

=C2=A0

But, as someone working on the yet-out-of-scope feat= ure, I think the WG should find a gentle way to include these projects, and= make sure it does to move towards squishing them.

=C2=A0

Therefore, I propose 15min yet-out-of-scope feature = report in the meetings.

=C2=A0

I also think a kind of guideline how yet-out-of-scop= e features should give input could help, something along:

=C2=A0- Have a separate daft on the feature with imp= orting considerations and lessons learned from implementation.

=C2=A0- Have a 4-line TL;DR regarding whether=C2=A0<= u>

=C2=A0 =C2=A01-2) how difficult implementing the fea= ture is (given the current drafts)

=C2=A0 =C2=A03-4) roughly what changes would be need= ed to add the feature

=C2=A0- Don=E2=80=99t file pull-requests on the curr= ent drafts, but maybe have a fork with diffs ready.

=C2=A0- Raise hands if changes under discussion woul= d totally block / significantly complicate adding the feature later on =C2= =A0

=C2=A0- Raise hands if changes under discussion=C2= =A0would enable / ease implementation of this feature - these arguments mig= ht be tie breakers.

=C2=A0

Based on that, I will continue to submit draft-tiese= l-quic-unreliable-streams-01 today

=C2=A0

AVE!

=C2=A0 Philipp S. Tiesel= / phils=E2=80=A6


--089e0824490cdf9dea055cc5e6d7-- From nobody Mon Oct 30 09:46: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 085F313FE73 for ; Mon, 30 Oct 2017 09:46:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 ElW32tVOB2C1 for ; Mon, 30 Oct 2017 09:46:18 -0700 (PDT) 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 811387B6E for ; Mon, 30 Oct 2017 09:40:13 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.44,320,1505804400"; d="asc'?scan'208,217";a="219599118" Received: from vmwexchts04-prd.hq.netapp.com ([10.122.105.32]) by mx142-out.netapp.com with ESMTP; 30 Oct 2017 09:10:29 -0700 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; Mon, 30 Oct 2017 09:40:12 -0700 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; Mon, 30 Oct 2017 09:40:12 -0700 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=jIz3DRpBfYW/HSF1IRbKZnOLM63T2LnaZqLvZq3BTIk=; b=J+rN6lTi75Mt9RWYpwGIKunV09fYr+c3tgv5+QoDBPxdxx5wPWsGO1fOLmr/xcnxM5rf22xzUZDPkHoz2/fZ0TlKA5tg/dRUn+rmGMc1DVuCt7uQ1LIuqcFWd4Y5gXZioTeZwqK56JXIr9l/eRW5jJTViu7mVs198Nz2HyxhtMU= 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.178.6; Mon, 30 Oct 2017 16:40: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.0178.012; Mon, 30 Oct 2017 16:40:09 +0000 From: "Eggert, Lars" To: Martin Duke CC: Roni Even , "Philipp S. Tiesel" , Mark Nottingham , QUIC WG , "Spencer Dawkins at IETF" Subject: Re: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuylSIJRNvocE0WivHlzUsNNn6L6YeIAgAADMACAAdJeAIAAEysAgABLPgCAAAfLAA== Date: Mon, 30 Oct 2017 16:40:09 +0000 Message-ID: <9500F7AE-D042-43B6-A663-2307D8983A8C@netapp.com> References: <6E58094ECC8D8344914996DAD28F1CCD828A1A@DGGEMM506-MBS.china.huawei.com> <76E33E22-AFEC-481F-AF0A-99EBE92E645E@in-panik.de> <6E58094ECC8D8344914996DAD28F1CCD829F41@DGGEMM506-MBS.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.1.7) authentication-results: spf=none (sender IP is ) smtp.mailfrom=lars@netapp.com; x-originating-ip: [2a02:120b:2c4a:92d0:317b:b616:d17d:cefa] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; BLUPR06MB1764; 6:tET/0VhsaHx5bZAjRdORuRXLBylWePrByUH+izuAG1oAz7iAZuoaTe6nsYTn11jYBKjdnUY5/nKEfY7Syk9Ck26a0c1RwUVvhdHAAh07z8J2SZ502W6e4yktU+LIu8e7sieJJQNm2SfBWKnMl9nnsAW0niYCMWEorMKBNMgGmCh2Zxz8SMvTuDK2Tl5eZiSgDjb5NwLkVh1VI0JZ36D4UCDjjoa8x5WSoOmYXB2t8659aYU+6x6/DvpNAAy2LCNY6XlJigfg1NwFoSjYF9LbAJOlley5x+l+/6LkqPriiX5aXqQ8+otIPVoEMZ33CBf/n5+ZY0O4H5facN7IuzsYmPGDQYwUDw1MbMYYYF5V5b8=; 5:0wfvOkLY0mglKQWzw4sDvhEKy7hsjdc7wTcWIIA2XhQqo0Mi9RRzuzGEXJbWfkzXLSAQzwJR8NMKAw8ryQbtVeedgZVX0KdDVpr+PTA5p6TFd/O4nNd6srGI1XMJZF4sYr0iONYNcujfmqzAGGsCLgFLEjNytBl/MSbkaeAoP/U=; 24:VdXLXAjNGhZpAc6NY33IkVSSArlrvM3dQMQNHgsKKzID5WSvNhLWX8Zng1/acr43YqSR12MdJOyQelmcMczfzR107R3M0CGeLIIBqS1FPhc=; 7:wY0s+XJMG+BwLBamSvGd19ei/zdmp/xPFSRsa0i7mrs7Ta2onz5r40Ja90TJrxf0s+EC6XZ13skqg2/vnVH0UlwHytFv/YBftb3YjajREp2Ms3/AGGGo49zZxjMo2AT5rcQIhJmoVJTjphLFWr2y8HY4lxuaiWDdgtPjXGwNrmK4hwk/fIDh4meTR4Hu6Pw2bDRy7uTlxjIolYqsWYLCplECxcXSDhmmtqvlsJLeeBFkZztaVZr5hubuVPGGcN+6 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: 53e459e1-bf2c-4b1c-0322-08d51fb4e26d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(2017052603199)(49563074); SRVR:BLUPR06MB1764; x-ms-traffictypediagnostic: BLUPR06MB1764: x-exchange-antispam-report-test: UriScan:; x-microsoft-antispam-prvs: x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(102415395)(6040450)(2401047)(5005006)(8121501046)(100000703101)(100105400095)(10201501046)(3002001)(3231020)(93006095)(93001095)(6055026)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(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: 0476D4AB88 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(199003)(377424004)(24454002)(189002)(101416001)(86362001)(3660700001)(3280700002)(6436002)(14454004)(229853002)(2906002)(478600001)(81166006)(8676002)(81156014)(33656002)(6486002)(97736004)(105586002)(8936002)(106356001)(77096006)(6506006)(6116002)(102836003)(316002)(53546010)(5660300001)(2900100001)(93886005)(4001150100001)(2950100002)(57306001)(6916009)(25786009)(82746002)(189998001)(54906003)(39060400002)(76176999)(36756003)(83716003)(53936002)(99936001)(54896002)(236005)(50986999)(6246003)(50226002)(99286003)(7736002)(6512007)(68736007)(4326008); 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=_D9A81FDC-0682-4CE2-A675-9C8B60B4CAC6"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 53e459e1-bf2c-4b1c-0322-08d51fb4e26d X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Oct 2017 16:40:09.4287 (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: Mon, 30 Oct 2017 16:46:20 -0000 --Apple-Mail=_D9A81FDC-0682-4CE2-A675-9C8B60B4CAC6 Content-Type: multipart/alternative; boundary="Apple-Mail=_915FDB2C-D138-4564-A321-CB235661528A" --Apple-Mail=_915FDB2C-D138-4564-A321-CB235661528A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi On 2017-10-30, at 17:12, Martin Duke wrote: > One practical suggestion: can we create an issue category for = "deferred" stuff? There are probably a dozen or issues that are good = ideas floating around (a couple of mine) that we may not have time to = address in 2018, but shouldn't be lost. I would feel a lot better about = my stuff being punted if I knew the WG would formally consider it in v2. that is a good suggestion, and I will add that tag in GitHub shortly. I would like to request that the proposers of such deferred issues bring = them back at an appropriate time, rather than putting this load on the = editors, who are already spread to thinly. Lars --Apple-Mail=_915FDB2C-D138-4564-A321-CB235661528A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi

On = 2017-10-30, at 17:12, Martin Duke <martin.h.duke@gmail.com> wrote:
One practical suggestion: can we create = an issue category for "deferred" stuff? There are probably a dozen or = issues that are good ideas floating around (a couple of mine) that we = may not have time to address in 2018, but shouldn't be lost. I would = feel a lot better about my stuff being punted if I knew the WG would = formally consider it in v2.

that is a good suggestion, and I will = add that tag in GitHub shortly.

I would like to request that the = proposers of such deferred issues bring them back at an appropriate = time, rather than putting this load on the editors, who are already = spread to thinly.

Lars
= --Apple-Mail=_915FDB2C-D138-4564-A321-CB235661528A-- --Apple-Mail=_D9A81FDC-0682-4CE2-A675-9C8B60B4CAC6 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----- iQIzBAEBCgAdFiEEmpq0ZpSoejRmyhheVLXDCb9wwVcFAln3VegACgkQVLXDCb9w wVemHxAAqoOZPfH2ZNJD/RYAXTpB9rcLg733YeasW3vntOiWGWaO7LQvrMuXlFBy vrRhg1W4vKr8xd2PKk2U8K0+7FxQ4RrrFGm5lCX/f1Zza0pkLDNLTH1cwX5cRuN5 pIrtsr1iw4ArtM90S4DLy3B9mgGCdkeZTgOTXhNVOueLWI4NhNasEEd3gjvTHbQ1 YbLg1+/ViStNWgPlU+ih0s/OT1UuybxTAqRjeCHuqnoP0eOn+GalOGA2RwynKf4M C4n3Or0qQJvzIb1MBmjH52gwCfA19c5WVF4CbI5fPu4c/qvyI5FojyWxhA9JiE+f RiQ+HHpIEVFGMHNksdyLjqMv5YOqkneG5Z8IHzEwsexVSp/gz2N/7H655GQJMjNB ZgCrZ3MPdYZ8i+VE9P55Ou5UsD1jxHnypak50cIPGZHa0p2gCMAk5Su+M4UJL/lN CSbcbqorVhPn1gGP4UGDXxSBEmuvjLL8e0W+bzgTiBhXWmBNgJM9MmzaFVVE5K6L ERmrgYpAuLnHDoWzYTdDUjgZHLlOkrNAvzbu3x9vtFGbCidMIWMK2mosDPSdOHU/ tzCuEh7AqiC1N34+jNGcqzu7Dvj3lHHBn4gjjNnfsWRkDxPlhDwvFg9mUxT7Ci54 jQw2wf23uiyUo9a3by4K4HqlT6EHnwSldXhvAtwNyKkSOBR3dO8= =FD/W -----END PGP SIGNATURE----- --Apple-Mail=_D9A81FDC-0682-4CE2-A675-9C8B60B4CAC6-- From nobody Mon Oct 30 10:19: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 BA02513FD72 for ; Mon, 30 Oct 2017 10:19:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 mXGLhClOwmSH for ; Mon, 30 Oct 2017 10:19:22 -0700 (PDT) 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 9A73413FD86 for ; Mon, 30 Oct 2017 10:19:22 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id y80so10520102wmd.0 for ; Mon, 30 Oct 2017 10:19:22 -0700 (PDT) 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=fSRlvJis//hlK40YNdQstrdOa66nwAG2bOiMTbXi7ts=; b=cDSuFYuoi67KX6Cf8a2oJNOmZL8/1dnMYbEeCnG2yuxG7ycUGxNDGtk6Us4uSM52nT xwzcDRj3j7TJbC9pgD/qgdz/IE5441bvD42cI3hItSsqjGE8jKsX6GorZHI05N7bclZn ata+2laywPegrIonFgd01qf1hzlE2Oow11aIxfAdIWzIolls+YlULElKlelozM8thQWU tMn/tkQ64u4cRV4beFQKJnnRmSlDq310ZeSWJLP8FOBQPda3CDpyK6ZhEC7nJ8+PkLop nhXK0xD1xBCqMz9bo6qfwTQMYYTvvADs3mvG9radK2NQkcYqeDzAzC2H+489kWzISnkN uF6A== 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=fSRlvJis//hlK40YNdQstrdOa66nwAG2bOiMTbXi7ts=; b=imPLCodmJQSDD/LuY5f+AjLpw4FRtmK82Z2X7QfZDp+dgqgEis3dEUerkbSGxkN346 RFuTZRvBfLfRffAUz4IQG8lSjez90JqFjvxOYFSeMzGoZvkGiptFgo07VaIPdcaDPn3Q meWlxDwZjK9BHbbdGd1FyIM5ir3pxdyLSPCV90bV9p01CSYvG+9CBN3lUEOo0bqsNbon 2aCGnIGse9gNH6sJ1lkfK7FFPhLEO4BEH1j1wux4ZPOpaOto6FufvC8dUqO8q8dfyVRe GqHSpRWsfIHufA/cwLhauuJHV8x3sYcvXlx0F5aYsUD6+aBShOttq0piYlB+pWV1cyRh i9Eg== X-Gm-Message-State: AMCzsaXjsPpeurc9GYdceeLQcWFuAu9vNxWBfx9yzX+mXFoDTDs4gDaH Xnpy2gIAwOk+EM/Ixkl6fE5MTpapMYsEkYsvw70QiiPxc4xIMHWMbBmVQVSBw3ZQcn40Rw3oTMW l7Q== X-Google-Smtp-Source: ABhQp+RhgfqImcHi/z/qvbFrqBPCOzbjkAU90YZCZeN6Rim977iD/QcbqhcD4lCZAgmRvIm/Y6OzPA== X-Received: by 10.80.143.98 with SMTP id 89mr12527130edy.273.1509383961034; Mon, 30 Oct 2017 10:19:21 -0700 (PDT) Received: from mbpobo.local ([2001:6a8:308f:2:51c2:8e12:5ae7:efd]) by smtp.gmail.com with ESMTPSA id l4sm12685486edc.20.2017.10.30.10.19.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Oct 2017 10:19:20 -0700 (PDT) Subject: Re: QUIC - Our schedule and scope To: Spencer Dawkins at IETF , "Eggert, Lars" Cc: Lucas Pardue , Simon Pietro Romano , QUIC WG , Mark Nottingham , Quentin De Coninck References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> From: Olivier Bonaventure Message-ID: Date: Mon, 30 Oct 2017 18:19:19 +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, 30 Oct 2017 17:19:26 -0000 Spencer, > When we were discussing the QUIC charter, I was very reluctant to > charter a new transport protocol in 2016 that didn't address multipath > (other people have suffered more while adding multipath to a protocol > that didn't anticipate multipath than I have, but I've seen enough > suffering). That may be the point I pressed on most strongly while > editing the current charter. So even though we wanted to minimize the > initial charter scope, I included multipath in the charter I took to the > IESG. > > I had assumed (without asking anyone) that > > - Enabling multipath and forward error correction extensions > > (listed as one of the key goals in the current charter) would put > "making sure that extensions were possible" in scope for v1. Having spent many cycles at making sure that Multipath TCP can work and be deployed, I confirm that it is important to take multipath into account early in the design of a new protocol like QUIC. Quentin De Coninck has been working on Multipath QUIC and has submitted a draft that proposes minimal changes to QUIC v1 to support multipath capabilities. This could be a good starting point for the working group to ensure that the QUIC v1 design does not get stuck in a state where middlebox ossification makes multipath much more difficult than it should be. Name: draft-deconinck-multipath-quic Revision: 00 Title: Multipath Extension for QUIC Document date: 2017-10-30 Group: Individual Submission Pages: 20 URL: https://www.ietf.org/internet-drafts/draft-deconinck-multipath-quic-00.txt Status: https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/ Htmlized: https://tools.ietf.org/html/draft-deconinck-multipath-quic-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-deconinck-multipath-quic-00 Abstract: Multipath TCP has shown how a reliable transport protocol can efficiently use multiple paths for a given connection. We leverage the experience gained with Multipath TCP to propose simple extensions that enable QUIC to efficiently use multiple paths during the lifetime of a QUIC connection. The draft shows that with small extensions and the ability to encode a path identifier in the public header, it is possible to have a Multipath QUIC design that is both clean and extensible. Quentin also has an implementation of Multipath QUIC as an extension of the QUIC-go implementation (thus not totally aligned with QUIC v1). His measurements that will appear in a forthcoming paper show that Multipath QUIC provides very good performance compared with Multipath TCP. Best regards, Olivier Bonaventure -- ------------------------------ 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 Oct 30 12:19: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 505AA138D8F for ; Mon, 30 Oct 2017 12:19:01 -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 QGG9-E9MDF79 for ; Mon, 30 Oct 2017 12:18:59 -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 2F399138A38 for ; Mon, 30 Oct 2017 12:18:59 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v9UJFbX1010885; Mon, 30 Oct 2017 19:18:54 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-transfer-encoding : mime-version; s=jan2016.eng; bh=dtmw30RFT8ZmSLucktHftWRtDEMTxYwW+vOGdeayhYQ=; b=MytE8JZ8pdFFXDqzXVrg4ee9C5Nl6++fqQcJeXgnOthYFhfvVoACQpOduxL7deUYEOFx YY5JCqv4Px8LQwX3QshhX5Wl4Vo1M9pEw39OVjb6TluSVUKkwpZTiOzj48ll1dx3DKte xotSmvVoONAq6xki45CB3RWuESQ+C1cxl9lEq9ECMbxSJxO1TMA5AawjRpa7yUtsj9tA 8BMiMPxvqGJ8w3ROeqBdE9XK1fAgR7qwUj3tWX+69Ld5NojYohJ9ob2KQYX3lCP18+3k 8tYwrRAHs9A6Mo6o09nh6uYHpUdtznpQdxizhC3wYBqj/TLe7uf/uEO2usyReSVc4Kah dg== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050093.ppops.net-00190b01. with ESMTP id 2dvmwdfxfg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2017 19:18:54 +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 v9UJD3Gv029217; Mon, 30 Oct 2017 15:18:51 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dvn7twv9q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 30 Oct 2017 15:18:51 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb5.msg.corp.akamai.com (172.27.123.55) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Mon, 30 Oct 2017 12:18:51 -0700 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; Mon, 30 Oct 2017 15:18:50 -0400 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; Mon, 30 Oct 2017 15:18:50 -0400 From: "Lubashev, Igor" To: Olivier Bonaventure , "Spencer Dawkins at IETF" , "Eggert, Lars" CC: Lucas Pardue , Simon Pietro Romano , QUIC WG , Mark Nottingham , Quentin De Coninck Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuyf6V6ciOlU90OGaSvkCp/hUKL4KMmAgABqWgCAAhmSAIAAF1WAgAElBwCAAQKUgP//yE5A Date: Mon, 30 Oct 2017 19:18:50 +0000 Message-ID: <54d92bde12844ec1a2d470bd1982f66e@usma1ex-dag1mb5.msg.corp.akamai.com> References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.213] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-30_06:, , 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-1710300255 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-30_06:, , 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-1710300255 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, 30 Oct 2017 19:19:01 -0000 PiBodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZGVjb25pbmNrLW11 bHRpcGF0aC1xdWljLTAwLnR4dA0KDQpNeSBjb21tZW50IG9uIHRoaXMgbXVsdGljYXN0IGRlc2ln biBpcyB0aGF0IEkgZG8gbm90IHRoaW5rIHRoaXMgQUREX0FERFJFU1MgY2FuIHdvcmsgd2VsbCBk dWUgdG8gTkFUcyAoYXMgdGhlIGNsaWVudCBpcyBub3QgYXdhcmUgb2YgaXRzIGV4dGVybmFsIGFk ZHJlc3NlcykuDQoNCi0gSWdvcg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTog T2xpdmllciBCb25hdmVudHVyZSBbbWFpbHRvOm9saXZpZXIuYm9uYXZlbnR1cmVAdGVzc2FyZXMu bmV0XSANClNlbnQ6IE1vbmRheSwgT2N0b2JlciAzMCwgMjAxNyAxOjE5IFBNDQpUbzogU3BlbmNl ciBEYXdraW5zIGF0IElFVEYgPHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPjsgRWdnZXJ0 LCBMYXJzIDxsYXJzQG5ldGFwcC5jb20+DQpDYzogTHVjYXMgUGFyZHVlIDxMdWNhcy5QYXJkdWVA YmJjLmNvLnVrPjsgU2ltb24gUGlldHJvIFJvbWFubyA8c3Byb21hbm9AdW5pbmEuaXQ+OyBRVUlD IFdHIDxxdWljQGlldGYub3JnPjsgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0PjsgUXVl bnRpbiBEZSBDb25pbmNrIDxxdWVudGluLmRlY29uaW5ja0B1Y2xvdXZhaW4uYmU+DQpTdWJqZWN0 OiBSZTogUVVJQyAtIE91ciBzY2hlZHVsZSBhbmQgc2NvcGUNCg0KU3BlbmNlciwNCg0KPiBXaGVu IHdlIHdlcmUgZGlzY3Vzc2luZyB0aGUgUVVJQyBjaGFydGVyLCBJIHdhcyB2ZXJ5IHJlbHVjdGFu dCB0byANCj4gY2hhcnRlciBhIG5ldyB0cmFuc3BvcnQgcHJvdG9jb2wgaW4gMjAxNiB0aGF0IGRp ZG4ndCBhZGRyZXNzIG11bHRpcGF0aCANCj4gKG90aGVyIHBlb3BsZSBoYXZlIHN1ZmZlcmVkIG1v cmUgd2hpbGUgYWRkaW5nIG11bHRpcGF0aCB0byBhIHByb3RvY29sIA0KPiB0aGF0IGRpZG4ndCBh bnRpY2lwYXRlIG11bHRpcGF0aCB0aGFuIEkgaGF2ZSwgYnV0IEkndmUgc2VlbiBlbm91Z2ggDQo+ IHN1ZmZlcmluZykuIFRoYXQgbWF5IGJlIHRoZSBwb2ludCBJIHByZXNzZWQgb24gbW9zdCBzdHJv bmdseSB3aGlsZSANCj4gZWRpdGluZyB0aGUgY3VycmVudCBjaGFydGVyLiBTbyBldmVuIHRob3Vn aCB3ZSB3YW50ZWQgdG8gbWluaW1pemUgdGhlIA0KPiBpbml0aWFsIGNoYXJ0ZXIgc2NvcGUsIEkg aW5jbHVkZWQgbXVsdGlwYXRoIGluIHRoZSBjaGFydGVyIEkgdG9vayB0byANCj4gdGhlIElFU0cu DQo+IA0KPiBJIGhhZCBhc3N1bWVkICh3aXRob3V0IGFza2luZyBhbnlvbmUpIHRoYXQNCj4gDQo+ ICAgICAtIEVuYWJsaW5nIG11bHRpcGF0aCBhbmQgZm9yd2FyZCBlcnJvciBjb3JyZWN0aW9uIGV4 dGVuc2lvbnMNCj4gDQo+IChsaXN0ZWQgYXMgb25lIG9mIHRoZSBrZXkgZ29hbHMgaW4gdGhlIGN1 cnJlbnQgY2hhcnRlcikgd291bGQgcHV0IA0KPiAibWFraW5nIHN1cmUgdGhhdCBleHRlbnNpb25z IHdlcmUgcG9zc2libGUiIGluIHNjb3BlIGZvciB2MS4NCg0KDQpIYXZpbmcgc3BlbnQgbWFueSBj eWNsZXMgYXQgbWFraW5nIHN1cmUgdGhhdCBNdWx0aXBhdGggVENQIGNhbiB3b3JrIGFuZCBiZSBk ZXBsb3llZCwgSSBjb25maXJtIHRoYXQgaXQgaXMgaW1wb3J0YW50IHRvIHRha2UgbXVsdGlwYXRo IGludG8gYWNjb3VudCBlYXJseSBpbiB0aGUgZGVzaWduIG9mIGEgbmV3IHByb3RvY29sIGxpa2Ug UVVJQy4NCg0KUXVlbnRpbiBEZSBDb25pbmNrIGhhcyBiZWVuIHdvcmtpbmcgb24gTXVsdGlwYXRo IFFVSUMgYW5kIGhhcyBzdWJtaXR0ZWQgYSBkcmFmdCB0aGF0IHByb3Bvc2VzIG1pbmltYWwgY2hh bmdlcyB0byBRVUlDIHYxIHRvIHN1cHBvcnQgbXVsdGlwYXRoIGNhcGFiaWxpdGllcy4gVGhpcyBj b3VsZCBiZSBhIGdvb2Qgc3RhcnRpbmcgcG9pbnQgZm9yIHRoZSB3b3JraW5nIGdyb3VwIHRvIGVu c3VyZSB0aGF0IHRoZSBRVUlDIHYxIGRlc2lnbiBkb2VzIG5vdCBnZXQgc3R1Y2sgaW4gYSBzdGF0 ZSB3aGVyZSBtaWRkbGVib3ggb3NzaWZpY2F0aW9uIG1ha2VzIG11bHRpcGF0aCBtdWNoIG1vcmUg ZGlmZmljdWx0IHRoYW4gaXQgc2hvdWxkIGJlLg0KDQpOYW1lOgkJZHJhZnQtZGVjb25pbmNrLW11 bHRpcGF0aC1xdWljDQpSZXZpc2lvbjoJMDANClRpdGxlOgkJTXVsdGlwYXRoIEV4dGVuc2lvbiBm b3IgUVVJQw0KRG9jdW1lbnQgZGF0ZToJMjAxNy0xMC0zMA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1 Ym1pc3Npb24NClBhZ2VzOgkJMjANClVSTDogDQpodHRwczovL3d3dy5pZXRmLm9yZy9pbnRlcm5l dC1kcmFmdHMvZHJhZnQtZGVjb25pbmNrLW11bHRpcGF0aC1xdWljLTAwLnR4dA0KU3RhdHVzOiAN Cmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRlY29uaW5jay1tdWx0aXBh dGgtcXVpYy8NCkh0bWxpemVkOiANCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1k ZWNvbmluY2stbXVsdGlwYXRoLXF1aWMtMDANCkh0bWxpemVkOiANCmh0dHBzOi8vZGF0YXRyYWNr ZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZGVjb25pbmNrLW11bHRpcGF0aC1xdWljLTAwDQoN Cg0KQWJzdHJhY3Q6DQogICAgTXVsdGlwYXRoIFRDUCBoYXMgc2hvd24gaG93IGEgcmVsaWFibGUg dHJhbnNwb3J0IHByb3RvY29sIGNhbg0KICAgIGVmZmljaWVudGx5IHVzZSBtdWx0aXBsZSBwYXRo cyBmb3IgYSBnaXZlbiBjb25uZWN0aW9uLiAgV2UgbGV2ZXJhZ2UNCiAgICB0aGUgZXhwZXJpZW5j ZSBnYWluZWQgd2l0aCBNdWx0aXBhdGggVENQIHRvIHByb3Bvc2Ugc2ltcGxlIGV4dGVuc2lvbnMN CiAgICB0aGF0IGVuYWJsZSBRVUlDIHRvIGVmZmljaWVudGx5IHVzZSBtdWx0aXBsZSBwYXRocyBk dXJpbmcgdGhlDQogICAgbGlmZXRpbWUgb2YgYSBRVUlDIGNvbm5lY3Rpb24uDQoNCg0KVGhlIGRy YWZ0IHNob3dzIHRoYXQgd2l0aCBzbWFsbCBleHRlbnNpb25zIGFuZCB0aGUgYWJpbGl0eSB0byBl bmNvZGUgYSBwYXRoIGlkZW50aWZpZXIgaW4gdGhlIHB1YmxpYyBoZWFkZXIsIGl0IGlzIHBvc3Np YmxlIHRvIGhhdmUgYSBNdWx0aXBhdGggUVVJQyBkZXNpZ24gdGhhdCBpcyBib3RoIGNsZWFuIGFu ZCBleHRlbnNpYmxlLiBRdWVudGluIGFsc28gaGFzIGFuIGltcGxlbWVudGF0aW9uIG9mIE11bHRp cGF0aCBRVUlDIGFzIGFuIGV4dGVuc2lvbiBvZiB0aGUgUVVJQy1nbyBpbXBsZW1lbnRhdGlvbiAo dGh1cyBub3QgdG90YWxseSBhbGlnbmVkIHdpdGggUVVJQyB2MSkuIEhpcyBtZWFzdXJlbWVudHMg dGhhdCB3aWxsIGFwcGVhciBpbiBhIGZvcnRoY29taW5nIHBhcGVyIHNob3cgdGhhdCBNdWx0aXBh dGggUVVJQyBwcm92aWRlcyB2ZXJ5IGdvb2QgcGVyZm9ybWFuY2UgY29tcGFyZWQgd2l0aCBNdWx0 aXBhdGggVENQLg0KDQoNCkJlc3QgcmVnYXJkcywNCg0KDQpPbGl2aWVyIEJvbmF2ZW50dXJlDQoN Ci0tIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkRJU0NMQUlNRVIuDQpUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiANCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRo aXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgc3lzdGVtIG1hbmFnZXIuIA0KVGhp cyBtZXNzYWdlIGNvbnRhaW5zIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBhbmQgaXMgaW50ZW5k ZWQgb25seSBmb3IgdGhlIGluZGl2aWR1YWwgbmFtZWQuIElmIHlvdSBhcmUgbm90IHRoZSBuYW1l ZCBhZGRyZXNzZWUgeW91IHNob3VsZCBub3QgZGlzc2VtaW5hdGUsIGRpc3RyaWJ1dGUgb3IgY29w eSB0aGlzIGUtbWFpbC4gUGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5IGJ5IGUt bWFpbCBpZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGUtbWFpbCBieSBtaXN0YWtlIGFuZCBkZWxl dGUgdGhpcyBlLW1haWwgZnJvbSB5b3VyIHN5c3RlbS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVu ZGVkIHJlY2lwaWVudCB5b3UgYXJlIG5vdGlmaWVkIHRoYXQgZGlzY2xvc2luZywgY29weWluZywg ZGlzdHJpYnV0aW5nIG9yIHRha2luZyBhbnkgYWN0aW9uIGluIHJlbGlhbmNlIG9uIHRoZSBjb250 ZW50cyBvZiB0aGlzIGluZm9ybWF0aW9uIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuDQoNCg== From nobody Mon Oct 30 13: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 8EA6A13FB58 for ; Mon, 30 Oct 2017 13:37:28 -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 amSVAbyJu5Br for ; Mon, 30 Oct 2017 13:37:26 -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 412F213FB40 for ; Mon, 30 Oct 2017 13:37:26 -0700 (PDT) X-Envelope-From: phils@in-panik.de X-Envelope-To: 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 v9UKb4va023198 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Mon, 30 Oct 2017 21:37:04 +0100 Received: from [2001:bf0:c801:101:c5c2:5a20:ca4:2e26] by x-berg.in-berlin.de with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1e9GnV-0006Kl-40 for quic@ietf.org; Mon, 30 Oct 2017 21:36:37 +0100 From: "Philipp S. Tiesel" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.7\)) Subject: Fwd: New Version Notification for draft-tiesel-quic-unreliable-streams-01.txt Message-Id: References: <150938406623.7809.7336682702011129979.idtracker@ietfa.amsl.com> To: QUIC WG Date: Mon, 30 Oct 2017 21:37:02 +0100 X-Mailer: Apple Mail (2.3445.1.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, 30 Oct 2017 20:37:28 -0000 Hi, as promised, we just updated our Internet Draft on Considerations for = Unreliable Streams in QUIC. TL;DR for those who want to spend minimal time on yet-out-of-scope = features: - Given draft-ietf-quic-transport-07 + PR 885, partially-reliable / = unreliable streams can be added quite nicely. - Our implementation proposal uses the third least significant bit of = the Stream ID to signal whether a stream is reliable or partial reliable / = unreliable, in analogy to the way PR 885 signals unidirectional streams. No other wire format = changes. The draft itself contains many considerations for unreliable streams and = some open questions, but nothing that blocks a fast adoption, e.g. for = v2. We are currently working on a quic-go based implementation of the draft. Happy to take comments or questions =20 > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-tiesel-quic-unreliable-streams-01.txt > Date: 30. October 2017 at 18:21:06 CET > To: "Joerg Ott" , "Balakrishnan Chandrasekaran" = , "Philipp S. Tiesel" = , "Mirko Palmer" , = "Philipp Tiesel" , "Anja Feldmann" = >=20 >=20 > A new version of I-D, draft-tiesel-quic-unreliable-streams-01.txt > has been successfully submitted by Philipp S. Tiesel and posted to the > IETF repository. >=20 > Name: draft-tiesel-quic-unreliable-streams > Revision: 01 > Title: Considerations for Unreliable Streams in QUIC > Document date: 2017-10-30 > Group: Individual Submission > Pages: 10 > URL: = https://www.ietf.org/internet-drafts/draft-tiesel-quic-unreliable-streams-= 01.txt > Status: = https://datatracker.ietf.org/doc/draft-tiesel-quic-unreliable-streams/ > Htmlized: = https://tools.ietf.org/html/draft-tiesel-quic-unreliable-streams-01 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-tiesel-quic-unreliable-streams= -01 > Diff: = https://www.ietf.org/rfcdiff?url2=3Ddraft-tiesel-quic-unreliable-streams-0= 1 >=20 > Abstract: > This memo outlines how to support unreliable streams as well as > partially-reliable streams within QUIC. The intention of this > document is to collect requirements and considerations, to frame the > design space, and to give an example how unreliable stream support > could be realized. >=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 --=20 Technische Universit=C3=A4t Berlin =E2=80=93 FG Internet Network = Architectures (INET) office: MAR 4.024 / Sekr.: MAR 4.4, Marchstr. 23, 10587 Berlin e-mail: philipp@inet.tu-berlin.de =E2=80=A2 phone: +49-30-314-75763 From nobody Tue Oct 31 01:51: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 5852713F6EA for ; Tue, 31 Oct 2017 01:51:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id za4SV6YgxdHx for ; Tue, 31 Oct 2017 01:51:08 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1934E13F640 for ; Tue, 31 Oct 2017 01:51:08 -0700 (PDT) Received: from [130.104.228.12] (1o0-328.dhcp.info.ucl.ac.be [130.104.228.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: qdeconinck@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 7306867DFDE; Tue, 31 Oct 2017 09:50:56 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp4.sgsi.ucl.ac.be 7306867DFDE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1509439856; bh=a5ffwRmeAm75OFX6fW9GJa59sas/Y6Y+3J15wfYPob4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=fLyxn/t5k1sSKxyjsPwerpUyANQzjjV4AIcjVVAuZcfucZMEfar83DrCpMVNESqLJ gWUnOVuwDXHh2RtSgDovS9nZ4RGE4qsMPFERZ+F1kgEScKou/Auvqi9X+dVMEesbW7 DPE+xIrFYUPAd2jRUzSgI5GKAsL+nyokZZmLuPJU= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-4 Subject: Re: QUIC - Our schedule and scope To: "Lubashev, Igor" , Olivier Bonaventure , Spencer Dawkins at IETF , "Eggert, Lars" Cc: Lucas Pardue , Simon Pietro Romano , QUIC WG , Mark Nottingham References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> <54d92bde12844ec1a2d470bd1982f66e@usma1ex-dag1mb5.msg.corp.akamai.com> From: Quentin De Coninck Message-ID: Date: Tue, 31 Oct 2017 09:50:56 +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: <54d92bde12844ec1a2d470bd1982f66e@usma1ex-dag1mb5.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 7306867DFDE.A750A X-SGSI-MailScanner: Found to be clean X-SGSI-From: quentin.deconinck@uclouvain.be X-SGSI-Spam-Status: No 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, 31 Oct 2017 08:51:11 -0000 Hello Igor, Le 30/10/17 à 20:18, Lubashev, Igor a écrit : >> https://www.ietf.org/internet-drafts/draft-deconinck-multipath-quic-00.txt > My comment on this multicast design is that I do not think this ADD_ADDRESS can work well due to NATs (as the client is not aware of its external addresses). This design is similar to the ADD_ADDRESS Multipath TCP option, and the current Multipath TCP deployments are using this to advertise the public addresses of the peer. The ADD_ADDRESS frame can be used to advertise other server public addresses, such that the NAT'd client can initiate path usage over those public addresses. Quentin > > - Igor > > -----Original Message----- > From: Olivier Bonaventure [mailto:olivier.bonaventure@tessares.net] > Sent: Monday, October 30, 2017 1:19 PM > To: Spencer Dawkins at IETF ; Eggert, Lars > Cc: Lucas Pardue ; Simon Pietro Romano ; QUIC WG ; Mark Nottingham ; Quentin De Coninck > Subject: Re: QUIC - Our schedule and scope > > Spencer, > >> When we were discussing the QUIC charter, I was very reluctant to >> charter a new transport protocol in 2016 that didn't address multipath >> (other people have suffered more while adding multipath to a protocol >> that didn't anticipate multipath than I have, but I've seen enough >> suffering). That may be the point I pressed on most strongly while >> editing the current charter. So even though we wanted to minimize the >> initial charter scope, I included multipath in the charter I took to >> the IESG. >> >> I had assumed (without asking anyone) that >> >> - Enabling multipath and forward error correction extensions >> >> (listed as one of the key goals in the current charter) would put >> "making sure that extensions were possible" in scope for v1. > > Having spent many cycles at making sure that Multipath TCP can work and be deployed, I confirm that it is important to take multipath into account early in the design of a new protocol like QUIC. > > Quentin De Coninck has been working on Multipath QUIC and has submitted a draft that proposes minimal changes to QUIC v1 to support multipath capabilities. This could be a good starting point for the working group to ensure that the QUIC v1 design does not get stuck in a state where middlebox ossification makes multipath much more difficult than it should be. > > Name: draft-deconinck-multipath-quic > Revision: 00 > Title: Multipath Extension for QUIC > Document date: 2017-10-30 > Group: Individual Submission > Pages: 20 > URL: > https://www.ietf.org/internet-drafts/draft-deconinck-multipath-quic-00.txt > Status: > https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/ > Htmlized: > https://tools.ietf.org/html/draft-deconinck-multipath-quic-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-deconinck-multipath-quic-00 > > > Abstract: > Multipath TCP has shown how a reliable transport protocol can > efficiently use multiple paths for a given connection. We leverage > the experience gained with Multipath TCP to propose simple extensions > that enable QUIC to efficiently use multiple paths during the > lifetime of a QUIC connection. > > > The draft shows that with small extensions and the ability to encode a path identifier in the public header, it is possible to have a Multipath QUIC design that is both clean and extensible. Quentin also has an implementation of Multipath QUIC as an extension of the QUIC-go implementation (thus not totally aligned with QUIC v1). His measurements that will appear in a forthcoming paper show that Multipath QUIC provides very good performance compared with Multipath TCP. > > > Best regards, > > > Olivier Bonaventure > From nobody Tue Oct 31 07:17: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 EE0EA13F46A for ; Tue, 31 Oct 2017 07:17:55 -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, 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 QCSGta8gf2cA for ; Tue, 31 Oct 2017 07:17:53 -0700 (PDT) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001: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 78EE713F44D for ; Tue, 31 Oct 2017 07:17:53 -0700 (PDT) Received: by mail-io0-x236.google.com with SMTP id 134so35404857ioo.0 for ; Tue, 31 Oct 2017 07:17:53 -0700 (PDT) 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=KR2Usa/xEynZedD82Ncg3lRvmHs7hU6XYUu36hmOeoA=; b=F5AGnT01cw/pPux2DGCIr4YnwFmTSk6b/WQueHcqsz1ct7L7s8LFmNIPAPcrC++6d4 VrK5i0R7yYYfwyySRAFsiM3us9cWTL55RWQg2F1/r/SDaweQP6I0zwtrM22a0O32D6BO Dp7LCkqsgnjxzIFH2x4yscQ9lBkxlDdWh/sArVIWbhJy5yhHIjKMrwE9bGjXZmlOmo7y QU4HPnl33YproNC2x8RQykSp+hj6DkwHEVtlTL18ObwOSmyeHVACoyV5Z2GbGry7tPOe g4ejBKe/UNDCJTAWmKVwQHRWG5wj53i6t4J07ydWF2fIz5hF13P2aIpAgzVehcTQeK3C UFWg== 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=KR2Usa/xEynZedD82Ncg3lRvmHs7hU6XYUu36hmOeoA=; b=DI/eBcZnaRAXgFjD8e8JPC5J59OxK+ggm/eufDpdrtq6EfEOyEJPB9A1Dew8WF5/1I 41fYIu+ygyOoG4YNDbb/3BfmEouLDw7BY3bwSD/5MN47U5yxJOEagYQktBRypof2iXCz JDvPWrvi/DKDimjfrjhszWznTEzpfYjt8ZhDZ2yXt1Rnmvv3AQUtGZA/Ynd9zv0wGNr6 ms9AYj4jFj/xztLpfpXuI9LDOJ87jPIUTZegKOWRKKX8DkA5DUKCGOdfrUIH6X0Jml5Z WOIjIeB/LjLck/oiVWJ8ntnz/0sVvUY92gICtUYzDOoiPPW6Kzi/z8G19ylLNMiOhCC4 eBMg== X-Gm-Message-State: AMCzsaXWooGcflaIN6wYg/s5rUkUoGB2obl9Oj6m9jsXy8sDf2IEkK4G JiM4KARz+Eo8lEz0s2VVlvXTPkTv0VrTr0rn+UGpXw== X-Google-Smtp-Source: ABhQp+SrewIUtrYXoq2LZEfiRKYUSVZI854NTOP/nKaiWkY2V4pEL5E8TxJzaLhs2l5YoE34KZmG2lYzgqcHPeE540w= X-Received: by 10.36.227.7 with SMTP id d7mr3218488ith.141.1509459472444; Tue, 31 Oct 2017 07:17:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.221 with HTTP; Tue, 31 Oct 2017 07:17:31 -0700 (PDT) In-Reply-To: <9500F7AE-D042-43B6-A663-2307D8983A8C@netapp.com> References: <6E58094ECC8D8344914996DAD28F1CCD828A1A@DGGEMM506-MBS.china.huawei.com> <76E33E22-AFEC-481F-AF0A-99EBE92E645E@in-panik.de> <6E58094ECC8D8344914996DAD28F1CCD829F41@DGGEMM506-MBS.china.huawei.com> <9500F7AE-D042-43B6-A663-2307D8983A8C@netapp.com> From: Ian Swett Date: Tue, 31 Oct 2017 10:17:31 -0400 Message-ID: Subject: Re: QUIC - Our schedule and scope To: "Eggert, Lars" Cc: Martin Duke , "Philipp S. Tiesel" , Roni Even , QUIC WG , Mark Nottingham , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="94eb2c111b06a92bf6055cd86b80" 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, 31 Oct 2017 14:17:56 -0000 --94eb2c111b06a92bf6055cd86b80 Content-Type: text/plain; charset="UTF-8" Excellent suggestion Martin. Lars, what is the name of the new label? I have at least one issue I'd like to tag as nonblocking(or ponies, or deferred...). On Mon, Oct 30, 2017 at 12:40 PM, Eggert, Lars wrote: > Hi > > On 2017-10-30, at 17:12, Martin Duke wrote: > > One practical suggestion: can we create an issue category for "deferred" > stuff? There are probably a dozen or issues that are good ideas floating > around (a couple of mine) that we may not have time to address in 2018, but > shouldn't be lost. I would feel a lot better about my stuff being punted if > I knew the WG would formally consider it in v2. > > > that is a good suggestion, and I will add that tag in GitHub shortly. > > I would like to request that the proposers of such deferred issues bring > them back at an appropriate time, rather than putting this load on the > editors, who are already spread to thinly. > > Lars > --94eb2c111b06a92bf6055cd86b80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Excellent suggestion Martin.

Lars= , what is the name of the new label?=C2=A0 I have at least one issue I'= d like to tag as nonblocking(or ponies, or deferred...).

On Mon, Oct 30, 2017 at 12:40 = PM, Eggert, Lars <lars@netapp.com> wrote:
Hi

On 2017-10-30, at 17:12, Martin = Duke <marti= n.h.duke@gmail.com> wrote:
One practical suggestion: can we create = an issue category for "deferred" stuff? There are probably a doze= n or issues that are good ideas floating around (a couple of mine) that we = may not have time to address in 2018, but shouldn't be lost. I would fe= el a lot better about my stuff being punted if I knew the WG would formally= consider it in v2.

th= at is a good suggestion, and I will add that tag in GitHub shortly.

I would like to request that the proposers of such deferr= ed issues bring them back at an appropriate time, rather than putting this = load on the editors, who are already spread to thinly.

Lars

--94eb2c111b06a92bf6055cd86b80-- From nobody Tue Oct 31 09:09: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 A736B13F935 for ; Tue, 31 Oct 2017 09:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-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 ZzHokNDsnpQF for ; Tue, 31 Oct 2017 09:09:46 -0700 (PDT) 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 95D7513F900 for ; Tue, 31 Oct 2017 09:07:41 -0700 (PDT) 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 v9VFph4m003947; Tue, 31 Oct 2017 16:07:36 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-transfer-encoding : mime-version; s=jan2016.eng; bh=CnnnzFQ/PjoX4wb+HtuT7OyvXuQNrEuTEIOdI5rlD1k=; b=VvYwkq5+cLO3NRrh8Wuz5PoXArqve/+oAWrfp4KD2UchRvh2Nu5aVVwmPf4Gy3OHCE3v dxqBp/iLJoXpkrTMfvCEM5H9vyfMTMZ7QYKoLG02eMQprt3qzr9S8n0JKp/SEUwm/yVG wr1qbxYMXfmk6fiUofOnUGp//kF2RW2KFVMRkeucOusmpxH20I/2zUURqQLOTV0RSqzV kOe8x1fybCZA2qQ64J0RwM2utA965xJNCcA5M8/dDCled/oHpn7MxoClxzuUgbFJcSTj wQq+M1pv2sj4xV9YCV2eS/KBR15imQeLiBt+2N8iv0up1UMoOG6mQNqUOBmkC90GUcaK ng== Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0b-00190b01.pphosted.com with ESMTP id 2dvmnhay3v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 31 Oct 2017 16:07:36 +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 v9VG1Jsh017547; Tue, 31 Oct 2017 12:07:35 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2dvn7u0m98-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 31 Oct 2017 12:07:35 -0400 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag3mb1.msg.corp.akamai.com (172.27.123.60) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Tue, 31 Oct 2017 12:07:35 -0400 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, 31 Oct 2017 12:07:34 -0400 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, 31 Oct 2017 12:07:34 -0400 From: "Lubashev, Igor" To: Quentin De Coninck , Olivier Bonaventure , Spencer Dawkins at IETF , "Eggert, Lars" CC: Lucas Pardue , Simon Pietro Romano , QUIC WG , Mark Nottingham Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTTuyf6V6ciOlU90OGaSvkCp/hUKL4KMmAgABqWgCAAhmSAIAAF1WAgAElBwCAAQKUgP//yE5AgAE7/ACAADWIsA== Date: Tue, 31 Oct 2017 16:07:34 +0000 Message-ID: <97addd5eae884ce3a8fe50d64e8fc293@usma1ex-dag1mb5.msg.corp.akamai.com> References: <7CF7F94CB496BF4FAB1676F375F9666A3BA7361D@bgb01xud1012> <49DC61C7-9E31-4049-84E3-112F129CBE50@mnot.net> <54d92bde12844ec1a2d470bd1982f66e@usma1ex-dag1mb5.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-31_06:, , 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-1710310203 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-10-31_06:, , 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=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1710310200 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, 31 Oct 2017 16:09:53 -0000 VGhhbmtzLCB5ZXMsIHRoYXQgZG9lcyBtYWtlIHNlbnNlIGZvciB0aGUgc2VydmVyIHRvIGRvLCBz aW1pbGFyIHRvIHRoZSBNSUdSQVRFIGZyYW1lIChodHRwczovL2dpdGh1Yi5jb20vcXVpY3dnL2Jh c2UtZHJhZnRzL2lzc3Vlcy81NjApLg0KDQotIElnb3INCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCkZyb206IFF1ZW50aW4gRGUgQ29uaW5jayBbbWFpbHRvOnF1ZW50aW4uZGVjb25pbmNr QHVjbG91dmFpbi5iZV0gDQpTZW50OiBUdWVzZGF5LCBPY3RvYmVyIDMxLCAyMDE3IDQ6NTEgQU0N ClRvOiBMdWJhc2hldiwgSWdvciA8aWx1YmFzaGVAYWthbWFpLmNvbT47IE9saXZpZXIgQm9uYXZl bnR1cmUgPG9saXZpZXIuYm9uYXZlbnR1cmVAdGVzc2FyZXMubmV0PjsgU3BlbmNlciBEYXdraW5z IGF0IElFVEYgPHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPjsgRWdnZXJ0LCBMYXJzIDxs YXJzQG5ldGFwcC5jb20+DQpDYzogTHVjYXMgUGFyZHVlIDxMdWNhcy5QYXJkdWVAYmJjLmNvLnVr PjsgU2ltb24gUGlldHJvIFJvbWFubyA8c3Byb21hbm9AdW5pbmEuaXQ+OyBRVUlDIFdHIDxxdWlj QGlldGYub3JnPjsgTWFyayBOb3R0aW5naGFtIDxtbm90QG1ub3QubmV0Pg0KU3ViamVjdDogUmU6 IFFVSUMgLSBPdXIgc2NoZWR1bGUgYW5kIHNjb3BlDQoNCkhlbGxvIElnb3IsDQoNCg0KTGUgMzAv MTAvMTcgw6AgMjA6MTgsIEx1YmFzaGV2LCBJZ29yIGEgw6ljcml0wqA6DQo+PiBodHRwczovL3d3 dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtZGVjb25pbmNrLW11bHRpcGF0aC1xdWlj LTANCj4+IDAudHh0DQo+IE15IGNvbW1lbnQgb24gdGhpcyBtdWx0aWNhc3QgZGVzaWduIGlzIHRo YXQgSSBkbyBub3QgdGhpbmsgdGhpcyBBRERfQUREUkVTUyBjYW4gd29yayB3ZWxsIGR1ZSB0byBO QVRzIChhcyB0aGUgY2xpZW50IGlzIG5vdCBhd2FyZSBvZiBpdHMgZXh0ZXJuYWwgYWRkcmVzc2Vz KS4NClRoaXMgZGVzaWduIGlzIHNpbWlsYXIgdG8gdGhlIEFERF9BRERSRVNTIE11bHRpcGF0aCBU Q1Agb3B0aW9uLCBhbmQgdGhlIGN1cnJlbnQgTXVsdGlwYXRoIFRDUCBkZXBsb3ltZW50cyBhcmUg dXNpbmcgdGhpcyB0byBhZHZlcnRpc2UgdGhlIHB1YmxpYyBhZGRyZXNzZXMgb2YgdGhlIHBlZXIu IFRoZSBBRERfQUREUkVTUyBmcmFtZSBjYW4gYmUgdXNlZCB0byBhZHZlcnRpc2Ugb3RoZXIgc2Vy dmVyIHB1YmxpYyBhZGRyZXNzZXMsIHN1Y2ggdGhhdCB0aGUgTkFUJ2QgY2xpZW50IGNhbiBpbml0 aWF0ZSBwYXRoIHVzYWdlIG92ZXIgdGhvc2UgcHVibGljIGFkZHJlc3Nlcy4NCg0KUXVlbnRpbg0K Pg0KPiAtIElnb3INCj4NCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogT2xp dmllciBCb25hdmVudHVyZSBbbWFpbHRvOm9saXZpZXIuYm9uYXZlbnR1cmVAdGVzc2FyZXMubmV0 XQ0KPiBTZW50OiBNb25kYXksIE9jdG9iZXIgMzAsIDIwMTcgMToxOSBQTQ0KPiBUbzogU3BlbmNl ciBEYXdraW5zIGF0IElFVEYgPHNwZW5jZXJkYXdraW5zLmlldGZAZ21haWwuY29tPjsgRWdnZXJ0 LCANCj4gTGFycyA8bGFyc0BuZXRhcHAuY29tPg0KPiBDYzogTHVjYXMgUGFyZHVlIDxMdWNhcy5Q YXJkdWVAYmJjLmNvLnVrPjsgU2ltb24gUGlldHJvIFJvbWFubyANCj4gPHNwcm9tYW5vQHVuaW5h Lml0PjsgUVVJQyBXRyA8cXVpY0BpZXRmLm9yZz47IE1hcmsgTm90dGluZ2hhbSANCj4gPG1ub3RA bW5vdC5uZXQ+OyBRdWVudGluIERlIENvbmluY2sgPHF1ZW50aW4uZGVjb25pbmNrQHVjbG91dmFp bi5iZT4NCj4gU3ViamVjdDogUmU6IFFVSUMgLSBPdXIgc2NoZWR1bGUgYW5kIHNjb3BlDQo+DQo+ IFNwZW5jZXIsDQo+DQo+PiBXaGVuIHdlIHdlcmUgZGlzY3Vzc2luZyB0aGUgUVVJQyBjaGFydGVy LCBJIHdhcyB2ZXJ5IHJlbHVjdGFudCB0byANCj4+IGNoYXJ0ZXIgYSBuZXcgdHJhbnNwb3J0IHBy b3RvY29sIGluIDIwMTYgdGhhdCBkaWRuJ3QgYWRkcmVzcyANCj4+IG11bHRpcGF0aCAob3RoZXIg cGVvcGxlIGhhdmUgc3VmZmVyZWQgbW9yZSB3aGlsZSBhZGRpbmcgbXVsdGlwYXRoIHRvIA0KPj4g YSBwcm90b2NvbCB0aGF0IGRpZG4ndCBhbnRpY2lwYXRlIG11bHRpcGF0aCB0aGFuIEkgaGF2ZSwg YnV0IEkndmUgDQo+PiBzZWVuIGVub3VnaCBzdWZmZXJpbmcpLiBUaGF0IG1heSBiZSB0aGUgcG9p bnQgSSBwcmVzc2VkIG9uIG1vc3QgDQo+PiBzdHJvbmdseSB3aGlsZSBlZGl0aW5nIHRoZSBjdXJy ZW50IGNoYXJ0ZXIuIFNvIGV2ZW4gdGhvdWdoIHdlIHdhbnRlZCANCj4+IHRvIG1pbmltaXplIHRo ZSBpbml0aWFsIGNoYXJ0ZXIgc2NvcGUsIEkgaW5jbHVkZWQgbXVsdGlwYXRoIGluIHRoZSANCj4+ IGNoYXJ0ZXIgSSB0b29rIHRvIHRoZSBJRVNHLg0KPj4NCj4+IEkgaGFkIGFzc3VtZWQgKHdpdGhv dXQgYXNraW5nIGFueW9uZSkgdGhhdA0KPj4NCj4+ICAgICAgLSBFbmFibGluZyBtdWx0aXBhdGgg YW5kIGZvcndhcmQgZXJyb3IgY29ycmVjdGlvbiBleHRlbnNpb25zDQo+Pg0KPj4gKGxpc3RlZCBh cyBvbmUgb2YgdGhlIGtleSBnb2FscyBpbiB0aGUgY3VycmVudCBjaGFydGVyKSB3b3VsZCBwdXQg DQo+PiAibWFraW5nIHN1cmUgdGhhdCBleHRlbnNpb25zIHdlcmUgcG9zc2libGUiIGluIHNjb3Bl IGZvciB2MS4NCj4NCj4gSGF2aW5nIHNwZW50IG1hbnkgY3ljbGVzIGF0IG1ha2luZyBzdXJlIHRo YXQgTXVsdGlwYXRoIFRDUCBjYW4gd29yayBhbmQgYmUgZGVwbG95ZWQsIEkgY29uZmlybSB0aGF0 IGl0IGlzIGltcG9ydGFudCB0byB0YWtlIG11bHRpcGF0aCBpbnRvIGFjY291bnQgZWFybHkgaW4g dGhlIGRlc2lnbiBvZiBhIG5ldyBwcm90b2NvbCBsaWtlIFFVSUMuDQo+DQo+IFF1ZW50aW4gRGUg Q29uaW5jayBoYXMgYmVlbiB3b3JraW5nIG9uIE11bHRpcGF0aCBRVUlDIGFuZCBoYXMgc3VibWl0 dGVkIGEgZHJhZnQgdGhhdCBwcm9wb3NlcyBtaW5pbWFsIGNoYW5nZXMgdG8gUVVJQyB2MSB0byBz dXBwb3J0IG11bHRpcGF0aCBjYXBhYmlsaXRpZXMuIFRoaXMgY291bGQgYmUgYSBnb29kIHN0YXJ0 aW5nIHBvaW50IGZvciB0aGUgd29ya2luZyBncm91cCB0byBlbnN1cmUgdGhhdCB0aGUgUVVJQyB2 MSBkZXNpZ24gZG9lcyBub3QgZ2V0IHN0dWNrIGluIGEgc3RhdGUgd2hlcmUgbWlkZGxlYm94IG9z c2lmaWNhdGlvbiBtYWtlcyBtdWx0aXBhdGggbXVjaCBtb3JlIGRpZmZpY3VsdCB0aGFuIGl0IHNo b3VsZCBiZS4NCj4NCj4gTmFtZToJCWRyYWZ0LWRlY29uaW5jay1tdWx0aXBhdGgtcXVpYw0KPiBS ZXZpc2lvbjoJMDANCj4gVGl0bGU6CQlNdWx0aXBhdGggRXh0ZW5zaW9uIGZvciBRVUlDDQo+IERv Y3VtZW50IGRhdGU6CTIwMTctMTAtMzANCj4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24N Cj4gUGFnZXM6CQkyMA0KPiBVUkw6DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRy YWZ0cy9kcmFmdC1kZWNvbmluY2stbXVsdGlwYXRoLXF1aWMtMDANCj4gLnR4dA0KPiBTdGF0dXM6 DQo+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWRlY29uaW5jay1tdWx0 aXBhdGgtcXVpYy8NCj4gSHRtbGl6ZWQ6DQo+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9k cmFmdC1kZWNvbmluY2stbXVsdGlwYXRoLXF1aWMtMDANCj4gSHRtbGl6ZWQ6DQo+IGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtZGVjb25pbmNrLW11bHRpcGF0aC1x dWljLTANCj4gMA0KPg0KPg0KPiBBYnN0cmFjdDoNCj4gICAgICBNdWx0aXBhdGggVENQIGhhcyBz aG93biBob3cgYSByZWxpYWJsZSB0cmFuc3BvcnQgcHJvdG9jb2wgY2FuDQo+ICAgICAgZWZmaWNp ZW50bHkgdXNlIG11bHRpcGxlIHBhdGhzIGZvciBhIGdpdmVuIGNvbm5lY3Rpb24uICBXZSBsZXZl cmFnZQ0KPiAgICAgIHRoZSBleHBlcmllbmNlIGdhaW5lZCB3aXRoIE11bHRpcGF0aCBUQ1AgdG8g cHJvcG9zZSBzaW1wbGUgZXh0ZW5zaW9ucw0KPiAgICAgIHRoYXQgZW5hYmxlIFFVSUMgdG8gZWZm aWNpZW50bHkgdXNlIG11bHRpcGxlIHBhdGhzIGR1cmluZyB0aGUNCj4gICAgICBsaWZldGltZSBv ZiBhIFFVSUMgY29ubmVjdGlvbi4NCj4NCj4NCj4gVGhlIGRyYWZ0IHNob3dzIHRoYXQgd2l0aCBz bWFsbCBleHRlbnNpb25zIGFuZCB0aGUgYWJpbGl0eSB0byBlbmNvZGUgYSBwYXRoIGlkZW50aWZp ZXIgaW4gdGhlIHB1YmxpYyBoZWFkZXIsIGl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgYSBNdWx0aXBh dGggUVVJQyBkZXNpZ24gdGhhdCBpcyBib3RoIGNsZWFuIGFuZCBleHRlbnNpYmxlLiBRdWVudGlu IGFsc28gaGFzIGFuIGltcGxlbWVudGF0aW9uIG9mIE11bHRpcGF0aCBRVUlDIGFzIGFuIGV4dGVu c2lvbiBvZiB0aGUgUVVJQy1nbyBpbXBsZW1lbnRhdGlvbiAodGh1cyBub3QgdG90YWxseSBhbGln bmVkIHdpdGggUVVJQyB2MSkuIEhpcyBtZWFzdXJlbWVudHMgdGhhdCB3aWxsIGFwcGVhciBpbiBh IGZvcnRoY29taW5nIHBhcGVyIHNob3cgdGhhdCBNdWx0aXBhdGggUVVJQyBwcm92aWRlcyB2ZXJ5 IGdvb2QgcGVyZm9ybWFuY2UgY29tcGFyZWQgd2l0aCBNdWx0aXBhdGggVENQLg0KPg0KPg0KPiBC ZXN0IHJlZ2FyZHMsDQo+DQo+DQo+IE9saXZpZXIgQm9uYXZlbnR1cmUNCj4NCg0K From nobody Tue Oct 31 15:38: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 E3ED513F788 for ; Tue, 31 Oct 2017 15:38:36 -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, 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 F25_tUYEpvyA for ; Tue, 31 Oct 2017 15:38:35 -0700 (PDT) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001: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 1EB8613F769 for ; Tue, 31 Oct 2017 15:38:35 -0700 (PDT) Received: by mail-io0-x234.google.com with SMTP id 189so2231996iow.10 for ; Tue, 31 Oct 2017 15:38:35 -0700 (PDT) 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=kE4wq4tbh7ewgwx8oLqE3LDHVqv6222MDCcpsHNybNg=; b=RLe4SKuDpAEmu4rhmmGmw9NMQ6g9Kpd1FeEtcSMc92nPTgjpJrdLChs1VRHPg8jCbL DqmOEpSJ0QVO0PiSiuztsP+hug/VZNwKAakeu0odGf8vOoW4loQ7EIuAtGCnp9IsGE3W xHMvhTPApPClapErftF5+Cgw3553/E4gHDb8VVXkWu6mZVYGgoE1D7olFCGhULps0wSQ HRALHS5blD23+jUYZlL1ge7zyyEVrCjcZDlIK9PMAQaxkYi0zqczYqnrR5A4gOmobgev mYS/SJ30suTd+0d/dCyig/qYTdJ3+n/jvqnVqcTRvfFhCjl/SKriTTaZpN+hM6jGXLYZ MXvw== 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=kE4wq4tbh7ewgwx8oLqE3LDHVqv6222MDCcpsHNybNg=; b=Qmn0F31H1bEgg4BEpkoyEESLCpI8n/fTdhXTrjOUwf1KtieOaNPccGXUiMJFd/aVs3 i/P+sDSZuUwiFh1Ysfu2MdYUgw6wr/8dC4dH4Rg3jYPVxgZJlPNa5NJH7oVzjhJAqizt YhHFTQ0DT8rRD1vSQMQ+keUUJ2JaFvlt9kg74gkIoG1RappXZF76WyruC57kAz2I2YNN HiEs6MRvZs1QlHZH3oTDrMp4apjq1l1SAqZ8FScnS7P1hdnTVpoBMt0Kvavtvhezv7cn iHMvZ3A4jJWlqB/8xR3Dv0MKsIWlgv+0lQDCXNbFSjs29uGKFC5ypC8/rD8woLgCTRWu bXrg== X-Gm-Message-State: AMCzsaXmM5CBIJy57BSQ/b6tWE8iYi79Q8znGcc2Ro6ZarHPtu62BvZ/ tmuQo6kvzs0ZYMl28FpvuoWqr0pMrN+6N+GzpDzEIg== X-Google-Smtp-Source: ABhQp+S9gK8awTHiMG8InkScFCVvJRibW7IwJaRrNRa6GkgLjagcjA6E9qtG4ymguQ3fUkpDSzPVVCIhCXQMG7rTCdM= X-Received: by 10.36.105.65 with SMTP id e62mr5249946itc.16.1509489514065; Tue, 31 Oct 2017 15:38:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.130.221 with HTTP; Tue, 31 Oct 2017 15:38:13 -0700 (PDT) In-Reply-To: References: <6E58094ECC8D8344914996DAD28F1CCD828A1A@DGGEMM506-MBS.china.huawei.com> <76E33E22-AFEC-481F-AF0A-99EBE92E645E@in-panik.de> <6E58094ECC8D8344914996DAD28F1CCD829F41@DGGEMM506-MBS.china.huawei.com> <9500F7AE-D042-43B6-A663-2307D8983A8C@netapp.com> From: Ian Swett Date: Tue, 31 Oct 2017 18:38:13 -0400 Message-ID: Subject: Re: QUIC - Our schedule and scope To: "Eggert, Lars" Cc: Martin Duke , "Philipp S. Tiesel" , Roni Even , QUIC WG , Mark Nottingham , Spencer Dawkins at IETF Content-Type: multipart/alternative; boundary="001a1144528447de4c055cdf6a93" 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, 31 Oct 2017 22:38:37 -0000 --001a1144528447de4c055cdf6a93 Content-Type: text/plain; charset="UTF-8" I have created a new quicv2 label. Anyone who created issues that are not critical to resolve before QUIC v1 should tag the issue with the new QUICv2 tag. Editors will also tag some issues as quicv2, but it'd be better if the issue creators did so themselves. As an example, my Message frame issue: https://github.com/quicwg/base-drafts/issues/814 Thanks, Ian On Tue, Oct 31, 2017 at 10:17 AM, Ian Swett wrote: > Excellent suggestion Martin. > > Lars, what is the name of the new label? I have at least one issue I'd > like to tag as nonblocking(or ponies, or deferred...). > > On Mon, Oct 30, 2017 at 12:40 PM, Eggert, Lars wrote: > >> Hi >> >> On 2017-10-30, at 17:12, Martin Duke wrote: >> >> One practical suggestion: can we create an issue category for "deferred" >> stuff? There are probably a dozen or issues that are good ideas floating >> around (a couple of mine) that we may not have time to address in 2018, but >> shouldn't be lost. I would feel a lot better about my stuff being punted if >> I knew the WG would formally consider it in v2. >> >> >> that is a good suggestion, and I will add that tag in GitHub shortly. >> >> I would like to request that the proposers of such deferred issues bring >> them back at an appropriate time, rather than putting this load on the >> editors, who are already spread to thinly. >> >> Lars >> > > --001a1144528447de4c055cdf6a93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have created a new quicv2 label.=C2=A0 Anyone who create= d issues that are not critical to resolve before QUIC v1 should tag the iss= ue with the new QUICv2 tag.=C2=A0 Editors will also tag some issues as quic= v2, but it'd be better if the issue creators did so themselves.
As an example, my Message frame issue:=C2=A0https://github.com/quicwg/base-dr= afts/issues/814

Thanks, Ian

On Tue, Oct 31, 2017 at = 10:17 AM, Ian Swett <ianswett@google.com> wrote:
Excellent suggestion Martin.=

Lars, what is the name of the new label?=C2=A0 I have = at least one issue I'd like to tag as nonblocking(or ponies, or deferre= d...).

On Mon, Oct 30, 2017 at 12:40 PM, Eggert= , Lars <lars@netapp.com> wrote:


--001a1144528447de4c055cdf6a93-- From nobody Tue Oct 31 23:45: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 E60E313FDCB for ; Tue, 31 Oct 2017 23:45: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, 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 rskvH-ua5Fj8 for ; Tue, 31 Oct 2017 23:45: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 CA08213F618 for ; Tue, 31 Oct 2017 23:45:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml703-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DZB19636; Wed, 01 Nov 2017 06:45:02 +0000 (GMT) Received: from DGGEMM406-HUB.china.huawei.com (10.3.20.214) by lhreml703-cah.china.huawei.com (10.201.108.44) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 1 Nov 2017 06:45:01 +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; Wed, 1 Nov 2017 14:42:32 +0800 From: Roni Even To: Colin Perkins , "Brian Trammell (IETF)" CC: Mark Nottingham , QUIC WG , Lars Eggert , Spencer Dawkins at IETF Subject: RE: QUIC - Our schedule and scope Thread-Topic: QUIC - Our schedule and scope Thread-Index: AQHTUOD5OYwD1bY2Q025S94sx4OA0aL/FxEw Date: Wed, 1 Nov 2017 06:42:32 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD82A677@DGGEMM506-MBS.china.huawei.com> References: 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.0A020206.59F96D6F.0032, 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: 7c2ad93f9370a4c512b2ebd712b97e60 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 06:45:08 -0000 QWdyZWUgd2l0aCBDb2xpbiBhbmQgdGhpcyBpcyBvbmUgcmVhc29uIGZvciBteSBjb25jZXJuIGFi b3V0IHRoZSAiaW52YXJpYW50IiBpbiBWMSBiYXNlZCBvbmx5IG9uIHRoZSBIVFRQIHVzZSBjYXNl Lg0KUm9uaQ0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFFVSUMgW21h aWx0bzpxdWljLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBDb2xpbiBQZXJraW5zDQo+ IFNlbnQ6INeZ15XXncKg15AgMjkg15DXlden15jXldeR16ggMjAxNyAyMDowOA0KPiBUbzogQnJp YW4gVHJhbW1lbGwgKElFVEYpDQo+IENjOiBNYXJrIE5vdHRpbmdoYW07IFFVSUMgV0c7IExhcnMg RWdnZXJ0OyBTcGVuY2VyIERhd2tpbnMgYXQgSUVURg0KPiBTdWJqZWN0OiBSZTogUVVJQyAtIE91 ciBzY2hlZHVsZSBhbmQgc2NvcGUNCj4gDQo+IA0KPiA+IE9uIDI4IE9jdCAyMDE3LCBhdCAwOTow NCwgQnJpYW4gVHJhbW1lbGwgKElFVEYpIDxpZXRmQHRyYW1tZWxsLmNoPiB3cm90ZToNCj4gPg0K PiA+IGhpIE1hcmssIGFsbCwNCj4gPg0KPiA+IEJyb2FkbHksIEkgc3VwcG9ydCBQYXRyaWNrJ3Mg aW50ZXByZXRhdGlvbiBoZXJlLiBJJ2xsIHBvaW50IG91dCB0aGF0IHRoZXJlDQo+IHNlZW1zIHRv IGJlIHNvbWUgaW5jb25zaXN0ZW5jeSBiZXR3ZWVuIHR3byBwb2ludHMgYmVsb3c6DQo+ID4NCj4g Pj4gT24gMjcgT2N0IDIwMTcsIGF0IDA4OjI2LCBNYXJrIE5vdHRpbmdoYW0gPG1ub3RAbW5vdC5u ZXQ+IHdyb3RlOg0KPiA+Pg0KPiA+PiAyKSBWMSBvZiBRVUlDIHNob3VsZCAqb25seSogYWRkcmVz cyB0aGUgdXNlIGNhc2Ugb2YgSFRUUC4NCj4gPg0KPiA+IGFuZA0KPiA+DQo+ID4+ICogVjEgd2ls bCBuZWVkIHRvIGRvY3VtZW50IHRoZSAiaW52YXJpYW50cyIgb2YgUVVJQyAtLSBpLmUuLCB0aGUg cGFydHMgb24NCj4gdGhlIHdpcmUgdGhhdCB3aWxsIG5vdCBjaGFuZ2UgLS0gdG8gYWxsb3cgb3Ro ZXIgdXNlIGNhc2VzIHRvIGJlIGFkZHJlc3NlZCBieQ0KPiBWMiBhbmQgYmV5b25kLg0KPiA+DQo+ ID4gVGhhdCBRVUlDJ3MgaGFuZHNoYWtlLCBwcmUtdmVyc2lvbi1uZWdvdGlhdGlvbiB3aXJlIGlt YWdlLCBhbmQNCj4gb3NzaWZpY2F0aW9uLXByZXZlbnRpb24gZmVhdHVyZXMgd2lsbCBiZSAiYmFr ZWQgaW4iIGluIFYxIGlzIGNsZWFyLCBhbmQgSQ0KPiB0aG91Z2h0IGl0IGFscmVhZHkgaGFkIGJl ZW4sIHRob3VnaCB0aGFua3MgZm9yIGNhbGxpbmcgaXQgb3V0IGhlcmUuDQo+ID4NCj4gPiBGb2N1 c2luZyBvbiAqb25seSogYWRkcmVzc2luZyBIVFRQIGluIHRoaXMgd2lyZSBpbWFnZSwgdGhvdWdo LCBzZWVtcyBsaWtlDQo+IGl0IG1pZ2h0IGJlIGRhbmdlcm91cyBpbiB3YXlzIEkgY2FuJ3QgZnVs bHkgYXJ0aWN1bGF0ZSB5ZXQuLi4gSFRUUCBpcyBhbiBleHBsaWNpdGx5DQo+IGFzeW1tZXRyaWMg cHJvdG9jb2wsIHdpdGggZGlmZmVyZW50IHJvbGVzIGZvciBjbGllbnQgYW5kIHNlcnZlciB3ZWxs IGJleW9uZA0KPiB0aGUgaW5pdGlhbCBoYW5kc2hha2UsIGFuZCBhcyBpdCBpcyBwcmVzZW50bHkg bW9zdCBjb21tb25seSBkZXBsb3llZCwgd2lsZGx5DQo+IGRpZmZlcmVudCBhcmNoaXRlY3R1cmVz IGZvciBjbGllbnQtc2lkZSBhbmQgc2VydmVyLXNpZGUgaW1wbGVtZW50YXRpb25zLg0KPiBNYW55 IG9mIHRoZSB0aGluZ3MgdGhhdCB3ZSBzdXNwZWN0IHdlJ2xsIHdhbnQgdG8gYnJpbmcgb24gdG9w IG9mIFFVSUMgaW4gdGhlDQo+IGZ1dHVyZSBhcmUgbGVzcyBzbzsgZXZlbiBXZWIgcHJvdG9jb2xz IGxpa2UgV2ViU29ja2V0cyBmaXQgaGVyZS4gV2lsbCB0aGlzDQo+IGZvY3VzIGxlYWQgdG8gaW52 YXJpYW50cyB0aGF0IHdpbGwgbWFrZSBsZXNzIGFzeW1tZXRyaWMgYXBwbGljYXRpb25zIGhhcmRl ciB0bw0KPiBidWlsZCBhbmQgZGVwbG95PyBTaG91bGQgd2UgYmUgY29uY2VybmVkIGFib3V0IHRo YXQgYXQgdGhpcyBwb2ludD8NCj4gDQo+IA0KPiBJIGRvIHRoaW5rIHRoYXQgcGVlci10by1wZWVy IHVzZXMgb2YgUVVJQyBuZWVkIGF0dGVudGlvbiBwcmUtVjEsIGlmIHRoZXnigJlyZSB0bw0KPiBi ZSBzdXBwb3J0ZWQgY2xlYW5seS4gQXQgbWluaW11bSwgd2UgbmVlZCB0byBhcnJhbmdlIHRoZSBR VUlDIGhlYWRlcnMgdG8NCj4gZWFzaWx5IGRlbXVsdGlwbGV4IHdpdGggU1RVTiBvbiB0aGUgc2Ft ZSBVRFAgcG9ydCwgb3RoZXJ3aXNlIHdl4oCZbGwgZW5kLXVwDQo+IHJlLWludmVudGluZyBTVFVO IHdpdGhpbiBRVUlDLiBGb2N1c3Npbmcgc29sZWx5IG9uIEhUVFAgaXMgZ29pbmcgdG8gbWFrZQ0K PiB0aGlzIGRpZmZpY3VsdC4NCj4gDQo+IFNlZSBkcmFmdC1hYm9iYS1hdnRjb3JlLXF1aWMtbXVs dGlwbGV4aW5nLTAwIGZvciBtb3JlIGRpc2N1c3Npb24uDQo+IA0KPiAtLQ0KPiBDb2xpbiBQZXJr aW5zDQo+IGh0dHBzOi8vY3NwZXJraW5zLm9yZy8NCj4gDQo+IA0KPiANCg0K From nobody Tue Oct 31 23:50: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 EE58C13FDFD for ; Tue, 31 Oct 2017 23:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7 X-Spam-Level: X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 Oiy3OU48gAtz for ; Tue, 31 Oct 2017 23:50:14 -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 5EB5413F8CD for ; Tue, 31 Oct 2017 23:50:14 -0700 (PDT) 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 DZB20280; Wed, 01 Nov 2017 06:50:12 +0000 (GMT) Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml702-cah.china.huawei.com (10.201.108.43) with Microsoft SMTP Server (TLS) id 14.3.361.1; Wed, 1 Nov 2017 06:50:12 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.18]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0361.001; Wed, 1 Nov 2017 14:50:09 +0800 From: Roni Even To: QUIC WG Subject: Comment on draft-aboba-avtcore-quic-multiplexing - SHIM byte Thread-Topic: Comment on draft-aboba-avtcore-quic-multiplexing - SHIM byte Thread-Index: AdNS3akbOK6F+T0JQWy2vKDLbmEvow== Date: Wed, 1 Nov 2017 06:50:09 +0000 Message-ID: <6E58094ECC8D8344914996DAD28F1CCD82A68C@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_6E58094ECC8D8344914996DAD28F1CCD82A68CDGGEMM506MBSchina_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.59F96EA5.0029, 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: 5efdde1dfe1ddf76a57ee3708a290872 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 06:50:16 -0000 --_000_6E58094ECC8D8344914996DAD28F1CCD82A68CDGGEMM506MBSchina_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I think that the proposal to add a SHIM byte in section 2.2 can be describe= d as making QUIC first byte as a two bytes allowing more flexibility notici= ng other requests for bits in the first byte. Roni --_000_6E58094ECC8D8344914996DAD28F1CCD82A68CDGGEMM506MBSchina_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I think that the proposal to add a SHIM byte in sect= ion 2.2 can be described as making QUIC first byte as a two bytes allowing = more flexibility noticing other requests for bits in the first byte.

 

Roni

--_000_6E58094ECC8D8344914996DAD28F1CCD82A68CDGGEMM506MBSchina_--